Subject: Re: [sv-ec] Comments on updated event proposal
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Thu Mar 13 2003 - 13:03:47 PST
Stefen,
You got it. See my earlier reply.
The reason why the assertions use the "else" construct
is because they need a mechanism to specify procedural
code form within the declarative context. On the other
hand, wait_order is in the procedural context so we can
do something much simpler. I did consider using the else
clause, but rejected it because it will no doubt lead to code like:
bit y = 1;
wait_order( a, b, c ) else y = 0;
if( ! y ) ...
else
or
wait_order( a, b, c ) y = 1; else y = 0;
It seems to me that the => based construct is simpler, but
I can be persuaded.
Arturo
----- Original Message -----
From: "Stefen Boyd" <stefen@boyd.com>
To: "Jay Lawrence" <lawrence@cadence.com>
Cc: "sv-ec" <sv-ec@eda.org>
Sent: Thursday, March 13, 2003 11:47 AM
Subject: Re: [sv-ec] Comments on updated event proposal
At 08:51 AM 3/13/2003 -0500, Jay Lawrence wrote:
>I think we should treat wait_order the same way we treated $cast. It is
>either a function or a task depending on how it is called. If used as a
>task then it prints an error. If used as a function it returns a status.
>So rather than inventing a new use for => you could just say.
>
> success = wait_order(a, b, c);
>Or
> success <= wait_order(a, b, c);
>
>Using existing assignment operators.
The only problem here is that everything else that behaves
as a function is not permitted to consume time. It seems
a little strange to have an NBA that blocks because the
expression on the rhs is blocking...
It would seem that substituting "else" for "=>" would be
a bit more natural. It's the way SV3.0 assertions worked:
wait_order ( event_identifier { , event_identifier } ) ;
| wait_order ( event_identifier { , event_identifier } ) else statement_or_null
Stefen
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 13:02:33 PST