-------- 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 Gaislers
> 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 2003s 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-typed, resulting
> in a worst-case interface definition. Note that array typed 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 2003s 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
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Mon Mar 8 06:59:50 2010
This archive was generated by hypermail 2.1.8 : Mon Mar 08 2010 - 07:02:33 PST