Subject: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Jim Lewis (Jim@synthworks.com)
Date: Tue Dec 09 2003 - 17:51:46 PST
Thanks for all the feedback so far. A couple of
people have noted some issues with some of the
Any inconsistency you see is probably an omission or
oversight (by me). Please keep pointing them out so
we can get closure on the proposals sooner.
Most of the proposals here are to become fast-track proposals.
To be a fast-track proposal, it must be non-controversial.
If a proposal is controversial (or requires more work or
discussion), it will be demoted to the appropriate group
(which for some is modeling and productivity).
> - Arrays of Unconstrained Arrays
> I agree with Ben, that the declaration should be the same as for
> other array types.
type std_logic_matrix is array of std_logic_vector ;
type std_logic_matrix is array (natural range<>) of std_logic_vector;
type std_logic_matrix2 is array (natural range<>, natural range<>)
of std_logic_vector ;
Ironically the inconsistency is an omission on my part.
However, do we need a default range of integer or natural for arrays?
For FT I think we should go forward with Ben's modification.
We can handle picking a default in either data types and
abstractions or in Modeling and productivity at a later date.
I am not sure if it is worth the effort as if we provide one,
two, and perhaps three dimensional arrays of arrays in each
of the standard packages, then I suspect we have covered
many of the typical cases.
Any issues with the signal declaration?
signal A : std_logic_matrix(7 downto 0)(5 downto 0) ;
This would also imply that it is ok to do a subtype as follows:
subtype Matrix_5x5 is std_logic_matrix(4 downto 0)(4 downto 0) ;
> Records & Interfaces (after meeting)
I am putting this here as I added it after the meeting
and the people at the meeting did not see it.
Note I corrected the end so it is end mode rather than
Proposal 3: add mode
Mode IfRecType_Mode_Model1 : IfRecType := (
Sig1 => in,
Sig2 => out
Mode IfRecType_Mode_Model2 : IfRecType := (
Sig1 => out,
Sig2 => in
end Mode ;
Entity Model1 is
IfRec1 : IfRecType_Model_Model1 : IfRecType ;
. . .
> - Context Clause Design Unit
> Inheritance, anyone? We might want to propagate project settings
> down to lower levels. Something to think about. Let the compiler
> figure how much we screwed up ;-)
Your comment seems to imply something bad, but I don't quite
understand it. Can you clarify or provide an example.
As a design unit, the context clause is compilable into a library.
By default each design unit references the context clause named
default_context (name negotiable).
In the meeting we agreed that each design unit is only allowed to
reference one context clause, but context clauses are allowed to
reference other context clauses.
Hence, if a design unit references the a named context clause,
this reference replaces the default context clause.
> - To_String
> Please. Just don't use the shorter names.
Good feedback. I like ti
> Hamish > to_string seems to duplicate 'image to some extent; could 'image be improved instead?
'image does not apply to composite objects.
'image has a verbose usage model (integer'image(F) vs. to_string(F))
'image does not currently have a way to specify a base (hex, decimal, binary)
> - Signal Spy
> I like the alternative using aliases. Whether ':' (colon) is the
> best option for a path separator is arguable. Are not most
> simulators using either '.' (dot) or '/' (slash)? Why another one?
I originally had '/' in there. Ironically VHDL already has a
notation for referencing things through the hierarchy (see the
I see signal spy as non-controversial.
I like alias. I am concerned that alias may be controversial.
If it is, it will have to be demoted to modeling and productivity.
> - Make conditional signal assignment a ternary operator
> Why not for variables as well? Did I miss anything?
Variables were not intentionally left out.
> Hamish > How about for constants?
Example of this is in the slides.
It is intended to cover initialization of signals and variables too.
> - Read Output Ports
> Can we keep that restricted to non-synthesis? If we get native
> signal spy features into VHDL, why not use that instead?
Why would I not want to do this in synthesizable code?
We need it for assertions (and OVL).
Since assertions can be in synthesizable code,
I think it would be unreasonable to restrict it.
> Read output ports
> Value read will be locally driven value
> ?Erroneous if additional drivers outside local block?"
> Helpful for writing assertions
> Ben: The read should return the current value of the local drivers of
> teh architecture, and not the resolved value of the signal at the higher
> Thus if within architecture, S<= '1', and in instantiation S at the port
> is driven with '0' (resolved to 'X'), then
> a read of the out port from within the architecture should return
> the driving value '1'.
Agreed. Same accessment was made at the meeting.
Basically if you want to read the internal value, you are
free to do so. If you need to read the resolved value,
you would use inout rather than out.
> - Boolean Equivalence
> Please don't. Implicitly assuming a boolean value leads to
> confusion. We should not trade the type-safe nature of VHDL for
> (debatable) convenience. Is it really so much better to type "if
> (<signal>)", than "if (<signal> = '1')"? How about the less-obvious
> case "if (resetn)"? Should that read as "resetn = '1'" or "resetn is
> active (low)". VHDL would have to assume the former, while users
> browsing the sources would be tempted reading the latter statement
> into the code.
Currently it is needed/desired in the PSL context.
We are evaluating whether it makes sense in a wider context.
I am kind of leaning in the same direction you are.
Other members of the group are pushing in this direction.
To me it has not hit my
> Short function names, reading of output ports and boolean equivalence
> are not something I spend my day on wishing I had them. Code
> completion (e.g. Emacs VHDL mode) helps mitigating a lot of the
> "inconveniences" VHDL users have to face. I see that some proposals
> would help gaining acceptance among users of The Other HDL, but that
> shouldn't be driving us.
This feedback is more helpful than you may think.
If others also feel this way, it would be helpful
to express this in an email to the reflector.
This group has alot of pressure on it to make
syntax and names shorter.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 : Tue Dec 09 2003 - 17:53:46 PST