Subject: RE: [Fwd: Re: [sv-ac] check: How will we do this?]
From: Bassam Tabbara (bassam@novas.com)
Date: Tue Feb 11 2003 - 17:43:54 PST
Hello Prakash,
I know DWG has spent a good deal of time considering the trade-offs
here, but I would like to make a comment on this issue. Food for thought
as it were :-)!
I think that may be here we have fallen into a trap of creating separate
constructs for separate scheduling mechanisms. "scheduling" is the
operative word here, may be we have hardwired (erroneously I believe)
scheduling into specific building blocks ("check" is the best example of
this, it is a construct that is inextricably linked to scheduling,
obvious by its name "immediate assertion"). I mean to say it would be
wise to think of assertions in terms of their expressiveness (i.e.
sequencing, evaluation constructs) -separate- from how they are
scheduled. Scheduling should be a layer on top that feeds the
assertions.
To restate: Using constructs i.e. check vs. property to create a
distinction in the scheduling/sampling does not seem right. I suggest
that we should step back and really consider the core we have worked on:
semantics of the assertions themselves (given a "sample of inputs" and a
scheduling (triggering) policy).
BTW, reason I bring this up now is as follows: Thinking of
scheduling/sampling as a separate (albeit -very- relevant of course!!!)
aspect would make it a lot easier for us to merge our part into the
"scheduling framework" that SystemVerilog has (for all its components:
design, assertion, testbench, PLI, and so on ).
Does this make sense ? Again my intent is not to open any issues but
rather to reflect on why some of us (Adam, Bassam, ??) have questioned
the utility of this construct. I do not disagree with you Prakash at
all, it is a solution for a "hole" but I am not sure it is the right
solution, I also suspect the "hole" is artificial, and likely when we
merge assertions into SV proper a good deal of this will be resolved....
-Bassam.
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.http://www.novas.com (408) 467-7893
> -----Original Message----- > From: owner-sv-ac@server.eda.org > [mailto:owner-sv-ac@server.eda.org] On Behalf Of Prakash Narain > Sent: Tuesday, February 11, 2003 11:27 AM > To: sv-ac > Subject: Re: [Fwd: Re: [sv-ac] check: How will we do this?] > > > It may also be reasonable to propose that for clearly identifiable > sequential > blocks, the scheduling should be allow evaluation of the first term > immediately. > > Best Regards, > > Prakash > > Adam Krolnik wrote: > > > > > > > Good morning Prakash; > > > > > > After considerations for and against the check statement > both by you > > and myself, here is my proposal and justification. > > > > > > I propose that the check statement be removed for the following > > reasons: > > > > 1. The functionality is very limited. > > a) You are only allowed a boolean expression argument > > b) Its use is limited to clocked RTL (design) procedural blocks > > [It has uses in the testbench, but still is limiting.] > > 2. I would prefer to have a unified "assert" statement with full > > support > > for properties and sequences to be used in all contexts. > > 3. It is easier to extend or add functionality than to remove it. > > We can work on this functionality for the next SystemVerilog > > release. > > > > > > In place of the check statement, one can always use > > > > if (! boolean_expr) $error(); > > > > > > Thanks > > > > Adam Krolnik > > Verification Mgr. > > LSI Logic Corp. > > Plano TX. 75074 > > > > > > > >
This archive was generated by hypermail 2b28 : Tue Feb 11 2003 - 17:44:52 PST