Subject: Re: [sv-ec] Comments on updated event proposal
From: Stefen Boyd (stefen@boyd.com)
Date: Thu Mar 13 2003 - 13:57:43 PST
Arturo,
The SV3.0 assertions were procedural... but regardless,
it seems that the choices for syntax ("=>" vs "else")
hinges on what the most likely use of the failure check
is going to be:
1) Set a variable to use later
2) immediately call a routine to deal with error
If uses were simply going to set a variable that they
might use later, then the '=>' syntax would make sense.
I would think that users would want to use it for two
purposes:
a) Custom error
wait_order(a,b,c) else $error(...);
OR
wait_order(a,b,c) else my_error(...);
b) Ignore error
wait_order(a,b,c) else;
If this is the more common use (and I suspect it would
be), "then" would be a better choice. Given an "else"
syntax, I would doubt most users would try to set
variables in the else clause.
And just for fun, here's what '=>' looks like with $error:
bit status;
wait_order(a,b,c) => status;
if (!status) $error(...);
Stefen
At 01:03 PM 3/13/2003 -0800, Arturo Salz wrote:
>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 - 14:03:21 PST