Subject: RE: [vhdl-200x] Implicit conversion, Overloading, & Strong Typin g
From: Bailey, Stephen (SBailey@model.com)
Date: Fri Dec 19 2003 - 08:24:18 PST
Gabe,
What Scott suggested may be neither less nor more robust. However, if others on this list can complain that, in their opinion, it is less robust, then Scott is entitled to express his opinion. At least he observed that, for him:
if we then
is a more common error than getting the active polarity of a signal wrong.
People today use naming conventions to indicate the active polarity. They do this for good reason:
At the interface, there is no other way to determine this information other than by inserting a comment. Naming convention is more powerful as it is always staring you in the face.
This fact combined with the fact that there is no proposal that the language incorporate naming convention in its semantics, indicates that the naming conventions discussion is irrelevant to the proposal.
Mistakes can be made today and mistakes can be made after the (assumed) adoption of the proposal. The proposal has not been directly tied to any increase in errors (within other languages, since VHDL does not have this today). If early PSL users were struggling with this, I'm sure Accellera's FVTC would have proposals on changing this in PSL.
I can see how it might decrease common errors. The main benefits of the proposal come from:
- Typing efficiency
- Eliminating the current syntactic errors that Scott indicates he is prone to. I think the most value will be for more complex expressions (not simple we = '1' simple expressions) and the full benefits would only kick in with the boolean, std_ulogic returning std_ulogic operator overloadings that Jim has proposed.
- PSL already supports this. If we do not support it, then we will make it difficult to incorporate PSL into VHDL. (The reality being that most tool vendors will allow -- already do allow -- this for VHDL-flavor PSL. For those who are concerned about language inconsistency, ponder how consistent it would be if it is legal in PSL contexts, illegal in normal VHDL contexts. Please note, by definition of the PSL language, all the PSL contexts are what is allowed in a VHDL *condition* plus certain boolean equivalences. That is the PSL context is always a boolean context.)
- No one has yet to refute the fact that the number of errors per lines of code is essentially independent of the language or abstraction level. Therefore, typing efficiency is a very important factor WRT decreasing bugs. Yes, this proposal may be modest in that regard, but any improvement is an improvement.
It remains that the argument against is based in subjective opinion of whether this is readable/maintainable.
-Steve Bailey
> What Scott suggests is not a robust solution. In fact what would
> (if (we_n) then
> mean? Who is going to infer that we_n is a negative active signal? I
> certainly would not count on the "_n" portion of the name.
> And I would not
> want a compiler to infer that all signals ending with "_n"
> are negative
> acting.
> Gabe
> ----- Original Message -----
> From: "Scott Thibault" <thibault@gmvhdl.com>
> To: "Jay Lawrence" <lawrence@cadence.com>; "VHDL-200x"
> <vhdl-200x@eda.org>
> Sent: Friday, December 19, 2003 10:04 AM
> Subject: RE: [vhdl-200x] Implicit conversion, Overloading, &
> Strong Typing
>
>
> > >
> > > I think that in VHDL in general this does not save
> significant typing
> > > and does not add much value, however when you consider
> PSL assertions
> > >
> >
> > I don't think typing is the real benefit here. I don't
> think I have ever
> > mistakenly typed:
> > if (we = '0') then
> > or
> > if (we_n = '1') then
> >
> > However, I have many many times typed:
> > if (we) then
> >
> > The result being that when I finally compile the design,
> I'm met with a
> long
> > list of compiler errors. This is frustrating and reduces
> productivity.
> >
> > --Scott Thibault
> > Green Mountain
> > Computing Systems, Inc.
> > http://www.gmvhdl.com
> >
> >
>
>
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 08:27:39 PST