Subject: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4,2003
From: Marcus Harnisch (marcus_harnisch@mint-tech.com)
Date: Wed Dec 10 2003 - 09:43:43 PST
Jim Lewis writes:
> For FT I think we should go forward with Ben's modification.
Great!
> 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) ;
No issues.
> > - 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.
I have no objections to that feature. Quite the contrary actually. But
this scheme will make it easier to unknowingly create conflicting
situations. Visibility is probably an issue to think about when
implementing new contexts. Think of a global context referencing
numeric_std, and a local context adding std_logic_unsigned for
instance. Strictly speaking, before implementing a context a user
would have to examine all included contexts and track changes to them.
> > - Signal Spy
> I originally had '/' in there. Ironically VHDL already has a
> notation for referencing things through the hierarchy (see the
> attribute 'instance_path).
I don't have time to check right now. What is being used there? Is
that implementation dependent? Can we standardize on one way?
> 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.
Agreed.
> > 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
> > level.
> [...]
>
> 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.
I'm convinced :-)
> > - 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.
Unless it is a requirement, I would stay away from it. Even if it was
a requirement, I would provide additional to_boolean() functions and
consider the implicit stuff bad practice.
> 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.
Well, I am German so I am used to really long words. The only occasion
where I (secretly) wished I had shorter names in VHDL is when I spend
time thinking about formating my source code. Never when writing
code. I could also print landscape of course. But then, even that
might not be enough. How about legal-landscape then?
Best regards,
Marcus
-- Marcus Harnisch | Mint Technology, a division of LSI Logic marcus_harnisch@mint-tech.com | 200 West Street, Waltham, MA 02431 Tel: +1-781-768-0772 | http://www.lsilogic.com
This archive was generated by hypermail 2b28 : Wed Dec 10 2003 - 09:46:24 PST