Forwarding something to the list that bounced
-------- Original Message --------
Subject: Re: [vhdl-200x] [Fwd: Re: Time to start up?]
Date: Wed, 10 Mar 2010 21:23:52 +0100
From: Matthias Wächter <matthias.waechter@tttech.com>
To: Peter Ashenden <peter@ashenden.com.au>
CC: Jim Lewis <Jim@synthworks.com>, vhdl-200x@eda.org
References: <4B9510D3.1000208@SynthWorks.com> <4B978499.1000307@ashenden.com.au>
Peter,
Thanks for your reply. Indeed, the additions, or at least what I see in
the unofficial changelogs, are really promising. Canâ??t wait to see
someone start an OO thread to jump on :)
Re 1: Umm â?¦ havenâ??t thought about precedence. Actually I donâ??t mind as I
rarely rely on precedence. I built my own fab for parentheses, they
never run out. :)
Re 2: Wow, you actually *did* implement that ('subtype)! Great to see!
Re 4/7: Really good. Next task is to look for synthesis vendors that
claim full support for VHDL 2008.
Re 6: I am sorry for the cryptic wording, and itâ??s just an idea of a
sleepless night (in 2003), probably nothing for the standards committee
to work on.
Consider two unsynthesizable components, e.g. as part of a test bench. A
use case would be a pattern generator driven by the test bench file
parser module over a bus-like programming interface with address, data,
ready and so on. To avoid the loss of real time and clock cycles which
could affect simulation, the two blocks exchange information using delta
cycles (for a limited number of cycles per time). This data exchange is
typically not visible in wave windows of, e.g. ModelSim, as display of
changes is solely time-driven (except if one steps through the processes
as they are executed). Note that the textual listing of signals and
related time does make delta cycles transparent, but uses a rather
different UI, to say the least.
Possible solutions for vendors:
a) Allow all delta cycles to be enabled for display (e.g. toggle
button). Will make most of the time scale discontinuous. â??Timeâ?? spent in
delta cycles could be emphasized by a different background color of the
wave window.
b) Allow the user to selectively unzip/zip delta cycles at specific
times so the discontinuity is limited to that times and their delta cycles.
c) Somewhat crazy: Allow the user to set up a non-zero delta delay (e.g.
1 fs). Will most probably break simulations because of slightly changed
timing.
d) ignore the feature request.
Possible solution for me:
e) Imply (d) and continue coding :)
â?? Matthias
-- Matthias Wächter - Senior Chip Designer TTTech Computertechnik AG - Time-Triggered Technology Commercial Reg. No.: 165 664z, Commercial Court Vienna Schoenbrunner Strasse 7, A-1040 Vienna, Austria tel:+43-1-5853434;ext=36 fax:+43-1-5853434;ext=90 mailto:matthias.waechter@tttech.com http://www.tttech.com -- Am 10.03.2010 12:38, schrieb Peter Ashenden: > Replying to Matthias' questions: > > Glad to see you like the additions to the standard. > > Re 1: I guess we could think about an "in range" operator as a form of > expression. We'd need to think about how to integrate the syntax in the > existing expression syntax. Specifically, what should it's precedence be > compared to other operators? > > Re 2: I think you really want the subtype, rather than the base type, of > the object. The base type has no constraints, so you can't declare an > object of the base type. (Maybe I'm being too much of a language lawyer > here and misunderstanding your intended meaning.) We've added the > 'subtype attribute that does what I think you want. For example: > > variable var : std_ulogic_vector(RANGE_VAR); > variable var_mirror : var'subtype; > > This makes var_mirror have the same base type and same constraints as var. > > Re 4: Yes, you can now use a range as a choice in an aggregate. So your > example should now be legal. > > Re 6: Not sure what you mean by "delta cycle visibility in simulation". > Do you mean for a VHDL model to be able to determine how many delta > cycles have occurred at the current simulation time? If so, I'd be > interested to see an example of a use case. If not, could you please > clarify? > > Re 7: Yes, if/elsif/.../else generates and case generates both made it > into the standard. > > Hope this answers your questions. > > Cheers, > > PA > > > On 9/03/2010 01:29, Jim Lewis wrote: >> >> >> -------- Original Message -------- >> Subject: Re: Time to start up? >> Date: Mon, 08 Mar 2010 15:46:16 +0100 >> From: Matthias Wächter <matthias@waechter.wiz.at> >> To: Jim Lewis <Jim@synthworks.com> >> References: <4B83F088.4060609@SynthWorks.com> >> <4B94D3B5.4080801@waechter.wiz.at> >> >> Jim, >> >> I just found [http://www.synthworks.com/papers/vhdl_2008_DASC_s.pdf] and >> now I see there definitely _has_ been progress in VHDL. :) >> >> Great to see »Packages with Generic Clause«, »Composites with >> Unconstrained Elements«, »Signal Expressions in Port Maps« and »Unary >> Reduction Operators«, and »Slices in Array Aggregates«. >> >> I definitely have to try all there neat new features once I get my hands >> on a compliant simulator, not to speak of synthesis tools. >> >> Apparently some suggestions from my last mail remain: >> >> 1. item 'in' range >> >> 2. get base type of items >> >> 4. Allow ranges in aggregate assignments: is this covered by »Slices in >> Array Aggregates«? >> >> 6. � hard to specify. >> >> 7. if-then-else-case in generate: did that make it into the current >> release or is it still on the list? >> >> Regards, >> � Matthias >> >> Am 08.03.2010 11:38, schrieb Matthias Wächter: >>> Hi Jim, >>> >>> I am just on this list � no other VHDL subscriptions � and it is >>> actually very low-volume, so I am not up to recent developments, >>> including VHDL 2008. Is there a PDF of the full spec for review, maybe a >>> shorter document that summarizes the changes? >>> >>> Here is my list of changes I would love to see in VHDL, of which some >>> have already been proposed [http://www.vhdl.org/vhdl-200x/hm/0271.html] >>> and discussed and may have entered the standard already. >>> >>> Our coding style is software-oriented and heavily based on Gaisler�s >>> approach [http://www.gaisler.com/doc/vhdl2proc.pdf]. Consequently we >>> face limitations of VHDL regarding records. We make heavy use of ranges >>> and sub-ranges as well, as you can see in the examples below. >>> >>> 1. item 'in' range >>> >>> Add a syntax element 'in' that allows efficient use of ranges. >>> >>> --- >>> subtype RANGE_ALLTASK is natural range 0 to 7; >>> subtype RANGE_FIRST_HALF is RANGE_ALLTASK range 0 to 3; >>> subtype RANGE_SECOND_HALF is RANGE_ALLTASK range 4 to 7; >>> >>> signal x: RANGE_ALLTASK; >>> >>> ... >>> >>> -- this does not work >>> if x in RANGE_SECOND_HALF then >>> ... >>> -- this does work but is clumsy >>> if x >= RANGE_SECOND_HALF'low and >>> x <= RANGE_SECOND_HALF'high then >>> ... >>> --- >>> >>> 2. Get base type of an item (not only types) >>> >>> from my 2003�s post: >>> >>>> Similarly to Jonas's input, it would be a great benefit to have >>>> access to >>>> not only the base type of a type (using type'base or sub_type'base) but >>>> also to the type of a variable/constant or signal. This would improve >>>> object-oriented approaches and code re-use. Underlying ranges of the >>>> base >>>> type can already be taken from signals, but not the base type itself. >>>> >>>> For example: >>>> >>>> -------------- >>>> -- always use constants... >>>> constant VAR_WIDTH : natural := 8; >>>> >>>> -- just to make things more clear, declare some basic subtypes >>>> subtype RANGE_VAR is natural range VAR_WIDTH-1 downto 0; >>>> subtype UTYPE_VAR is std_ulogic_vector(RANGE_VAR); >>>> >>>> variable var: UTYPE_VAR; >>>> variable var_mirror: var'base; -- <--- this produces an error >>>> variable var_via_range : std_ulogic_vector(var'range); -- <-- this >>>> works >>>> -------------- >>>> >>>> Of course, if var and var_mirror are declared in subsequent lines >>>> like in >>>> the given example, referring to the type of var is not of much use, but >>>> assume in a block you have to declare additional variables or signals >>>> based on the type given in the main architecture, or even better, >>>> given on >>>> the entity using generics, then you have to know the type of var >>>> instead >>>> of defining "a variable/signal that has the same type as var". >>> >>> 3. Unconstrained elements of record types >>> >>> Allow a record type to contain unconstrained elements. Certainly, this >>> requires later specialization when signals and ports need a declaration, >>> but can be useful for functions and a more generic approach to >>> record-based interfacing. Support of this feature should include >>> unconstrained record elements, which are records as well. >>> >>> Considen a typical SoC bus. Solutions are typically scalable in terms of >>> address and data bus width. The use of records on the interfaces allows >>> abstraction, but currently such records must be single-type�d, resulting >>> in a worst-case interface definition. Note that array type�d signals on >>> entities can be constrained by entity generics, but not so arrays. >>> >>> This suggestion does not contain any syntax proposal. >>> >>> 4. Allow ranges in aggregate assignments >>> >>> Another idea from my 2003�s post: >>> >>>> Additionally, what I'd like to see in VHDL and what should be no big >>>> deal >>>> is a way of using ranges in aggregate assignments - the only range that >>>> can be used is the term 'others'. For example (sorry for the >>>> excessive use >>>> of subtypes/ranges): >>>> >>>> -------------- >>>> constant SIG_WIDTH : natural := 9; >>>> constant NIBBLE_WIDTH : natural := 4; >>>> >>>> subtype RANGE_SIG is natural range SIG_WIDTH-1 downto 0; >>>> subtype RANGE_NIBBLE is natural range NIBBLE_WIDTH-1 downto 0; >>>> subtype RANGE_SIG_LOWNIBBLE is RANGE_SIG range >>>> RANGE_SIG'low+NIBBLE_WIDTH-1 downto RANGE_SIG'low; >>>> subtype RANGE_SIG_HIGHNIBBLE is RANGE_SIG range >>>> RANGE_SIG_LOWNIBBLE'high+NIBBLE_WIDTH downto >>>> RANGE_SIG_LOWNIBBLE'high+1; >>>> constant RANGE_SIG_PARITY: RANGE_SIG := >>>> RANGE_SIG_HIGHNIBBLE'high+1; >>>> >>>> subtype UTYPE_SIG is std_ulogic_vector(RANGE_SIG); >>>> subtype UTYPE_NIBBLE is std_ulogic_vector(RANGE_NIBBLE); >>>> subtype UTYPE_PARITY is std_ulogic; >>>> >>>> signal sig: UTYPE_SIG; >>>> signal nibble_high, nibble_low : UTYPE_NIBBLE; >>>> signal parity : UTYPE_PARITY; >>>> >>>> ... >>>> >>>> -- the following gives an error (only the RANGE_SIG_PARITY works) >>>> >>>> sig <= (RANGE_SIG_HIGHNIBBLE => nibble_high, >>>> RANGE_SIG_LOWNIBBLE => nibble_low, >>>> RANGE_SIG_PARITY => parity, >>>> others => '0'); >>>> >>>> -- the following works but is unnecessarily verbose (currently used) >>>> >>>> P_SIG: process(nibble_high, nibble_low, parity) >>>> begin >>>> sig <= (others => '0'); >>>> sig(RANGE_SIG_HIGHNIBBLE) <= nibble_high; >>>> sig(RANGE_SIG_LOWNIBBLE) <= nibble_low; >>>> sig(RANGE_SIG_PARITY) <= parity; >>>> end process P_SIG; >>>> >>>> -- the following works but implies local knowledge of the precise >>>> layout >>>> -- of the signal and will be broken code when ranges or positions >>>> -- change, so deprecated for reusable code >>>> >>>> sig <= parity & nibble_high & nibble_low; >>>> >>>> -------------- >>> >>> 5. Types as first-class citizens >>> >>>> In general, what's missing (and may be a big deal) in VHDL for more >>>> sophisticated object-oriented approaches is type passing for >>>> functions and >>>> generics (component instantiation) [�] >>> >>> 6. Requirement for Delta cycle visibility in simulation >>> >>>> [�] as well as the requirement for the >>>> simulation tool to make delta cycles visible for making data flow over >>>> software interfaces visible; [�] >>> >>> 7. if-else-case in generate >>> >>> It appears that this has already been addressed. >>> >>> >>> regards, >>> � Matthias >> >> >> > > -- > Dr. Peter J. Ashenden peter@ashenden.com.au > Ashenden Designs Pty. Ltd. www.ashenden.com.au > PO Box 640 Phone: +61 8 7127 0078 > Stirling, SA 5152 Mobile: +61 414 70 9106 > Australia > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Mar 10 12:52:23 2010
This archive was generated by hypermail 2.1.8 : Wed Mar 10 2010 - 12:52:46 PST