Subject: Re: [vhdl-200x] Implicit conversion, Overloading, & Strong Typing
From: Gabe Moretti (gmoretti@comcast.net)
Date: Fri Dec 19 2003 - 06:06:29 PST
Jay,
what about writing:
assert always to_boolean(
{master_state = WRITE} |->
{{slave_accept = '1'} | {master_state = WRITE [*];
master_state = WRITE and slave_accept = '1'}});
It would mean that the to_boolean function would have to understand PSL, but
that is doable and still keeps the flexibility of the assert statement to
handle non boolean conditions.
Gabe
----- Original Message -----
From: "Jay Lawrence" <lawrence@cadence.com>
To: "VHDL-200x" <vhdl-200x@eda.org>
Sent: Friday, December 19, 2003 8:21 AM
Subject: RE: [vhdl-200x] Implicit conversion, Overloading, & Strong Typing
>
>
> I've been silently watching this debate for the last few days and was
> unconvinced by either side until this post by Steve (I have read the
> rest of the thread after this).
>
> The conditional context provides a clear delineation that a boolean
> value is required and if a type conversion operator from a given type to
> boolean is provided it is reasonable to apply it.
>
> 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
> the readability of an assertion will be greatly reduced without this
> functionality. The current assertions only take a single conditional
> expression so it is no big deal to just write
>
> assert to_boolean( ... );
>
> However, PSL temporal properties will have lots of conditions with
> intervening operators.
>
> An example would be an assertion that says that once a bus master has
> issued a write, the write state must continue until the slave has
> accepted the write;
>
> always {master_state = WRITE} |->
> {{slave_accept = '1'} | {master_state = WRITE [*];
> master_state = WRITE and slave_accept = '1'}};
>
> Each of the {} above surrounds a sequential regular expression that is
> composed of a series of boolean terms. To rewrite this requiring
> booleans at each location would look like:
>
> always {to_boolean(master_state = WRITE)} |->
> {{to_boolean(slave_accept = '1')} |
> {to_boolean(master_state = WRITE [*]);
> to_boolean(master_state = OCP_WRITE and slave_accept =
> '1')}};
>
> (NOTE: the | operator above is a PSL "or" operator on sequences, not a
> VHDL operator so it does not need to be wrapped in to_boolean()).
>
> I find the second one much harder to understand. This property only has
> 4 boolean conditions. Properties with booleans above 10 will not be
> uncommon.
>
> For what its worth, I think that in a boolean context, when an
> appropriate overloaded function is available, the implicit application
> of the function will greatly enhance writing and reading of properties.
>
> Jay
>
> ===================================
> Jay Lawrence
> Senior Architect
> Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
>
> > -----Original Message-----
> > From: Bailey, Stephen [mailto:SBailey@model.com]
> > Sent: Friday, December 19, 2003 1:36 AM
> > To: VHDL-200x
> > Subject: RE: [vhdl-200x] Implicit conversion, Overloading, &
> > Strong Typing
> >
> >
> > Hamish,
> >
> > > Jim Lewis wrote:
> > > > Actually, I believe you are comfortable with this
> > > > behavior, you are just stuck on "implicit".
> > > > Let me give an example:
> > > >
> > > > signal A, Y : unsigned (8 downto 0) ;
> > > >
> > > > Y <= A + "000001111" ;
> > > > vs.
> > > > Y <= A + 15 ;
> > > >
> > > > This is overloading. The compiler picks the right "+" operator
> > > > to call based on the equation and we are happy. It only knows
> > > > which one to call based on type of the operands.
> > > >
> > > >
> > > > Likewise:
> > > > if Cs = '1' and Cs2 = '1' then -- if1
> > > > vs.
> > > > if Cs1 and Cs2 then -- if2
> > > >
> > > > Here the compiler also picks the right "COND" operator for the
> > > > expression. For the first one (if1), it sees the top
> > > > expression is boolean so it realizes it does not need to
> > > call "COND".
> > >
> > > In the first example, you specifically called "+" and expected the
> > > compiler to find the right one. In the second example you
> > > called AND it
> > > find the right one too. That's fine and quite logical.
> > >
> > > But you didn't explicitly called "COND" at all. That's
> > > foreign to VHDL.
> >
> > The point Jim was trying to make is that you are calling COND
> > because the condition context requires a boolean value and a
> > COND that matches is visible. Remember that VHDL's syntax
> > defines the following contexts (and only these contexts) that
> > *condition* can occur (this is documented in the proposal):
> >
> > - assert *condition* ...
> > - if *condition* (if statement and if-generate)
> > - elsif *condition*
> > - wait [...] until *condition* [...]
> > - when *condition* ... (conditional signal assignment, exit, next)
> > - while *condition*
> > - to be defined PSL expressions
> >
> > We actually discussed an alternative way to arrive at the
> > same functionality. Since people seem to be hung up on this
> > implicit call and cannot make the connection to how it is
> > just a tiny extension to operator overloading capabilities
> > already in the language:
> >
> > - What if assert, if, elsif, until, when and while were
> > defined in the language as operators.
> >
> > - Users could then overload the operators to take a parameter
> > of any type and return boolean.
> >
> > - Tools would apply subprogram overload resolution just as
> > they do today to select which visible if, etc. operator to apply.
> >
> > This would work exactly like today's subprogram overloading
> > capabilities. We thought the COND proposal would be easier
> > to digest and accept. We may have been wrong in that regard
> > as the if, etc. as operators proposal should not lead to
> > people misinterpreting the proposal as Hamish (and others)
> > have done by trying to apply it to contexts in which it isn't
> > allowed (see next comment).
> >
> > (Note: The idea of if, etc. being overloaded operators would
> > not impact how branching, etc. work. Only how the expression
> > is interpreted as TRUE/FALSE.)
> >
> > > By the way, does the implicit "COND" call only apply to if?
> > > What about
> > > assignments to boolean, as in
> > >
> > > signal z: boolean;
> > > signal x, y: bit;
> > >
> > > begin
> > > z <= x and y;
> > > end if;
> > >
> > > Logically this should work too, if it works with if.
> >
> > No, it does not logically work because this is NOT a
> > condition context. There is no explicit context (nothing in
> > the syntax that indicates that the LHS is boolean) which
> > makes it obvious that the result of the RHS should be
> > converted to boolean.
> >
> > We did not want the proposal to apply to this situation and
> > it does not.
> >
> > -Steve Bailey
> >
>
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 06:09:22 PST