Subject: Re: [vhdl-200x] Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Jim Lewis (Jim@synthworks.com)
Date: Wed Dec 10 2003 - 08:15:57 PST
> Hamish > to_string seems to duplicate 'image to some extent; could 'image be improved instead?
Some of the requirements for a string conversion are:
Work for both scalar and composite objects
Be intuitive in usage
Be able to specify a base (hex, decimal, binary).
These are all very easily met by to_string.
To_String is also easy to implement.
To make 'image work, it would need:
Be extended to work for composite objects
Be less verbose: as suggested: F'image rather than integer'image(F)
Be extended to specify a base (hex, decimal, binary)
Be overloadable
Like Jonas, I teach VHDL. To me, to_string is easier to teach
than 'image ever will be.
'image was proposed. It is/was issue FT6. So far, the core of the
working group has decided that to_string is the way to go.
To go forward with 'image, we would need someone to volunteer to
work on the proposal. Any volunteers?
With that said, if you have time to volunteer, there are lots of
other things to work on.
Cheers,
Jim
Matthias Wächter wrote:
> On Wed, 10 Dec 2003, Jonas Nilsson wrote:
>
>
>>Hamish Moffatt wrote:
>>
>>>to_string seems to duplicate 'image to some extent; could 'image be
>>>improved instead?
>>
>>I agree.
>>Augmenting 'image to be a more universal attribute (not
>>only an attribute on types) would be a big improvement.
>>
>>a'IMAGE would be much easier to use and understand than
>>INTEGER'IMAGE(a). I give VHDL courses, and have seen this
>>mistake made by students thousands of times. a'IMAGE
>>is a very reasonable thing to try to do.
>
>
> Sorry for sneaking in, I have not attended to the San Jose meeting and am
> not a (voting) member, but I have some input to this one. I included some
> general San Jose critics below as well.
>
> 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".
>
>
>
> 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 natural range
> RANGE_SIG'low+NIBBLE_WIDTH-1 downto RANGE_SIG'low;
> subtype RANGE_SIG_HIGHNIBBLE is natural range
> RANGE_SIG_LOWNIBBLE'high+NIBBLE_WIDTH downto RANGE_SIG_LOWNIBBLE'high+1;
> constant RANGE_SIG_PARITY: natural :=
> 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;
>
> --------------
>
> 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) as well as the requirement for the
> simulation tool to make delta cycles visible for making data flow over
> software interfaces visible; But I think that we cannot discuss this topic
> just as a reply to the discussion about the San Jose meeting, I'm a little
> bit off-topic already :-)
>
> ==============================================================
>
> My opinion about the San Jose paper in general:
>
> What I very much appreciate about the proposal is the introduction of
> combining direction information and records at the entity level,
> although type generics (see above) are missing that could improve this a
> lot. But let's start with the direction records and continue afterwards.
> Btw, using direction records and Signal Spy has some interesting
> implications on whether driver or spy is used on such a record.
> Additionally, there are a lot of issues about support for records in the
> tools, so I expect a lot of tool iterations when this new feature is
> frequently used.
>
> Second, adding Signal Spy as a VHDL feature is very much appreciated, it's
> used at our side already, and having it tool vendor independent in the
> future is very good. However, I think that actually _using_ Signal Spy
> breaks a feature that makes VHDL superior over Verilog: Guaranteed
> encapsulation. For applications where this has to be assured, maybe a tool
> switch or a configuration ("for my_component feature
> signal_spy(unit_no_driver, input_no_driver, unit_no_spy); end for;")
> statement can make assure that Signal Spy is _not_ used in special
> hierarchy levels or compilation/design loading will stop with an error
> otherwise. Note that, given the example above, for failure-free testing,
> spying into a component may be allowed, but no spy/driver usage within the
> unit (and all sub-units). For testing of failures, also driving into the
> unit may be given as a configuration feature for a different
> configuration. If someone agrees here, this has to be worked out in a
> better way, it's just a rough statement here.
>
> Another word to Signal Spy: Please add a way of 'relative' addressing,
> like with file system pathes that can be addressed relative to the current
> one using '..'. Otherwise you have to write a lot of function or pass a
> lot of generics to get from one branch of the tree to another one.
>
> Another word about ternary operators: Why write
>
> AReg <= A when rising_edge(Clk);
>
> and not
>
> AReg <= A when rising_edge(Clk) else AReg;
>
> This would not be much overhead but would specify all pathes
> unambiguously. And, I _don't_ like the
>
> AReg <= A if rising_edge(Clk);
>
> approach, I agree that this is already implemented well with 'when', and
> differentiating between the always-when meaning 'when' and the
> situation-if meaning 'if' is a major step to understanding the
> parallelisms in VHDL concurrent statements versus the sequential
> statements within procedures, functions and processes.
>
> Finally, I don't like Boolean Equivalence. The designer should clearly
> state what he wants and not let the tool guess. Being a little bit more
> verbose clears the issue whether A='1', (A='1' or A='H') or nA='0' is
> meant. If someone wants to use a signal as a boolean, then he has to
> declare it as a boolean (of course, then all the cool std_logic stuff like
> 'X', 'L', 'H' is lost).
>
> Thanks for reading,
>
> Yours,
> - Matthias Waechter
> TTChip Entwicklungs-GesmbH
> Vienna, Austria
> www.ttchip.com
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Wed Dec 10 2003 - 08:18:39 PST