Subject: Attribute Enhancement Request: was 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 - 10:50:30 PST
Matthias Wächter wrote:
> Sorry for sneaking in,
If you don't speak up, it is unlikely that your ideas will
ever be part of the standard. More volunteers to discuss
and work on issues is helpful.
>(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.
Added to modeling and productivity groups proposal list:
Extend 'base to allow use of variable/constant/signal
> 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):
Currently aggregates require that you are mapping an element.
As a result, when you specify a range, it receives an element
value and not an array or slice. So the following is legal:
Y <= (Y'range => '0') ; -- here same as (others => '0')
We can look at this in the context of MP.
I am not sure if anything can be done.
Aggregates are fairly general and are used for records.
Perhaps we need a second aggregate that applies only to
single dimensional arrays.
> In general, what's missing (and may be a big deal) in VHDL for more
> sophisticated object-oriented approaches is type passing ...
> My opinion about the San Jose paper in general:
> 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
in a> 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
> better way, it's just a rough statement here.
This is an interesting issue.
Key Point: Final check out of a design would require
that signal spy is not driving any internal signals in
Notes, early in the design phase, it is reasonable to
drive internal signals of a design to account for functions
not present, then later, replace these drivers with
the actual functionality.
How do we accomplish this?
1) Add procedures to disable driving, spying on units and IO
2) Depend on disciplined usage
> 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.
Good point. Some of this is provided with 'instance_name, but
to go up and back down would require some string processing
> Another word about [conditional signal assignment]: Why write
> AReg <= A when rising_edge(Clk);
> and not
> AReg <= A when rising_edge(Clk) else AReg;
This is more of a 1076.6 question (VHDL RTL Synthesis).
Both will be supported by 1076.6-200X.
I expect the first to be more popular as currently its
equivalent process is supported by 1076.6-1999:
RegProc : process(Clk)
if rising_edge(Clk) then
AReg <= A ;
end if ;
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 archive was generated by hypermail 2b28 : Wed Dec 10 2003 - 10:52:08 PST