RE: [sv-ec] Errata 238 and 240 and a suggestion for a BNF change

Surrendra,
 
"Is your objective to allow a sequence expression anywhere a primary can
be used? "
 
Yes. this makes the testbench portion itself complete. for example,
sequences expressions can be used with 'if'.
I think you will agree that 'expect' already support this. So SV LRM
already provides this feature, we are recommending to
extend it ( into what you called simulation evaluation).
 
Why? To a verification engineer, writing self-checking testbench (
stimulus and checking ) is a requirement, on top of that,
additional Assertions can be added. If we make such a connection that
'simulation evaluation' is corresponding to stimulus,
'assertion evaluation' is corresponding to checking, then to a user,
there is no boundary. And there shouldn't be. That's our
strong belief. In other words, we believe 'checking' doesn't have to be
done by 'Assertion' code only.
 
Let's me if you'd like more information or example code. Hope you can
vote for this errata ( 255).
 
-Eugene
 

From: Surrendra Dudani [mailto:Surrendra.Dudani@synopsys.com]
Sent: Thursday, September 30, 2004 1:33 PM
To: sv-ec@eda.org
Subject: Re: [sv-ec] Errata 238 and 240 and a suggestion for a BNF
change

Hi Eugene,
I'm having difficulty understanding the semantics of this proposal. In
sv-ac we carefully and formally defined the semantics of sequence_expr
so that there is a clear semantic boundary between simulation and
assertion evaluation (This includes the observe region where assertions
are evaluated). Is your objective to allow a sequence expression
anywhere a primary can be used?
Can you please elaborate on the semantics?

Surrendra
At 11:34 AM 9/24/2004 -0700, you wrote:

The following suggestion is a follow-up to the discussion in the last
sv-ec meeting on Errata 238 ( Pipelined value access in clocking block)
and
Errata 240 ( Expression valuation in cycle delay), with comments from
Arturo.
 
In summary, 238 and 240 should be replaced by this proposal. as you can
see, the change is minimal, however it can bring benefits to users. From
our
experiences, writing self-checking testbenches, with embedded
assertions, is a natural process. Checking is usually done in
testbench, doesn't
have to be in code called "Assertions' only.
 
We'd like to hear your feedback, tells us why if you say no and try to
convince us. If we agree, the goal is to put this into the first IEEE
standard.
 
Below is a brief description:
 
We carefully examined the whole section 17, and found that the functions
we requested on SV-EC 238 (Pipelined value access) and 240 (delayed
expression) can also be realized with 'sequence_expr' and $past system
tasks in section 17 Assertions.

We agree that the basic functionality can be somewhat achieved by using
17.16 (expect statement), but in terms of the flexibility, we still
suggest to have 'sequence_expr' as a part of regular expression.

This provides an extremely flexible mechanism to express the cycled
sequences anywhere in the program statement. For example, it can be
used in the conditional qualifier for 'if' and 'while' statements .

Given that the the assertion mechanism must be implemented, we don't see
any major technical difficulty to include it as a part of the
primary. This extension raises the SystemVerilog's expression
capability to a totally different level.

Suggested Revised BNF: to add sequence_expre to primary

<?/x-tad-bigger><?/fontfamily><?/smaller><?fontfamily><?param Times New
Roman><?bigger> A.8.4 Primaries

   primary ::=
     .
     .
     sequence_expr
<?/bigger><?/fontfamily><?smaller>
 
 
Cheers,
-Eugene

**********************************************
Surrendra A. Dudani
Synopsys, Inc.
377 Simarano Drive, Suite 300
Marlboro, MA 01752

Tel: 508-263-8072
Fax: 508-263-8123
email: Surrendra.Dudani@synopsys.com
**********************************************
Received on Fri Oct 1 12:41:12 2004