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

Hi Arturo,
Please see comments inserted below.
we still need 'while loop' even if we have 'if', that's a close analogy
to our proposal.
-Eugene

-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Wednesday, October 06, 2004 4:40 PM
To: eugene zhang; 'Surrendra Dudani'; sv-ec@eda.org
Subject: Re: [sv-ec] Errata 238 and 240 and a suggestion for a BNF
change

Eugene,
 
Currently, SystemVerilog does not allow expressions to block (only
statements). Allowing a sequence instance as the predicate expression of
an if-statement is an enhancement that seems to do two things: First, it
enhances sequences to behave as a function that returns a (Boolean?)
result, and second, it introduces blocking expressions (functions) to
the language. Allowing blocking expressions is a big enhancement that
will become a new source of indeterminacy. The rules for blocking
expression evaluation do not exist today, and I believe there may be no
"correct" evaluation order, only arbitrary rules that may or may not be
appropriate for modeling hardware or systems. Consider the following
example:
 
    if( F(a + b) == G(a) + F(b) + H(a) )
 
If both F, G and H are blocking expressions, when is the relational
expression evaluated? When are the additions performed? When are the
arguments used by the expressions evaluated? What happens if the
arguments change during the lifetime of the expressions? Are
sub-expressions evaluated in left-to-right odrer, or in execution
termination order? How do the new rules modify operator precedence,
associativity, and commutativity, etc...
 
 -----------------
I guess you get confused with the 'monitor' behavior of the 'assertion'
mechanism. There's no concurrent evaluation mechanism as you are
questioning among the binary expression.
 
Evaluation of expression is quite simply done when the execution reaches
the point, and complete with a result when it's done (does not matter if
it's blocking or non-blocking). The execution of the code will be
blocked at the point of execution. If it is combined with operators, it
strictly follows the precedence rule, as:
 
1) Each expression (blocking or non blocking) follows the rule of
precedence.
2) evaluation of expression that use the result of precedence expression
will be blocked until the result is determined.
3) binary expression will evaluate left operand first, then right
operand
 
So, the order of evaluation is:
 
a + b
F(a+b)
G(a)
F(b)
G(a) + F(b)
H(a)
(G(a)+F(b)) + H(a)
F(a+b) == ( (G(a)+F(b))+H(a) )
----------------------
 
 
 Also, I don't understand how the expressive power of your proposal
improves upon the expect statement. Your example can be rewritten as
shown below. The only difference is the use of an expect-statement
instead of an if-statement.
 
program test;
logic[31:0] data;
logic[31:0] value;
logic success;

initial begin
    expect( @(posedge clk) ##[1:10] (data==value) ) success = 1; else
success = 0;
end
endprogram
 
 
 --------------
Using the 'if' statement case was not a good example to show the
difference to 'expect' statement, as the 'expect' statement is a limited
version of 'if' statement in some sence. But It is quite obvious that
the generic expression has more expressive power. A simple case is use
it in 'while' statement:
 
while( @(posedge clk) ##[1:10] (data==value) ) begin
do_something() ;
end
 
To do the same with expect statement, you need to wrap your 'expect'
statement within a while loop as:
 
int success = 1 ;
 
while( success == 1 ) begin
expect( @(posedge clk) ##[1:10] (data==value) ) success = 1; else
success = 0;
if( success == 1 ) begin
do_something() ;
end
end
 
It seems that the code is not intuitive to read, as we have to follow
the value of 'success' to understand the behavior .
 
 
--------------------------
 

----- Original Message -----
From: eugene zhang <mailto:eugene@jedatechnologies.com>
To: 'Surrendra Dudani' <mailto:Surrendra.Dudani@synopsys.COM> ;
sv-ec@eda.org
Sent: Wednesday, October 06, 2004 2:23 PM
Subject: RE: [sv-ec] Errata 238 and 240 and a suggestion for a BNF
change

Surrendra,
 
I'd like you think out side of the 'assertion' box a bit, testbench
embedded, flexible, effective checkers are more fundamental than
'Assertion'. There are companies taping out first-working-silicon with
just self-checking testbenches, with testbenches plus assertions.
Probably you would agree nobody tape out chips solely relying on
assertions.
 
That's why it should be a priority for SV to have sequence based
checkers to in par with the basics in today's HVLs. by definition, it
should be more powerful and more flexible than assertion can provide. (
Here, it's the 'expect')
 
If syntax is a concern to you, maybe the following code will help,
although they don't look prettier:

program test;
logic[31:0] data;
logic[31:0] value;
logic success;
 
sequence s1(data, value);
  @(posedge clk);
  (##[1:10] (data==value));
endsequence
 
initial begin
  if(s1(data, value)) success = 1 ;
  else success=0;
end
 
endprogram
   
-Eugene
 
 
 From: Surrendra Dudani [mailto:Surrendra.Dudani@synopsys.com]
Sent: Tuesday, October 05, 2004 7:22 AM
To: sv-ec@eda.org
Subject: RE: [sv-ec] Errata 238 and 240 and a suggestion for a BNF
change

Hi Eugene,
Your example doesn't seem to follow sequence_expr syntax or semantics
associated with sequence_expr. Please explain in detail what semantics
you are proposing.
In addition, ! operator would imply complementing a sequence, which is
not supported by assertions due to its complexity and unintended
evaluations resulting from the complement sequences.
Surrendra
 
At 01:06 AM 10/5/2004 -0700, you wrote:

Surrendra,
 
Some examples are below. ( for errata 255). We propose they should be
supported under 'program'.

"Is your intention to use assertion syntax with different semantics?"
 
Actually from history point of view, self-checking mechanism ( like '==
' in Vera ) were widely
used long before people started to call them assertions. Today, the
number of users who write
'embedded' self-checking testbenches ( using HVLs) are way more than the
number who just
use 'assertions' to tape out. Or assertions are used for additional
checking on top of testbenches.
Good testbenches should cover all assertion goals at DUT interface.
 
Our view is that SV testbench should provide flexible and powerful
self-checking mechanisms first,
it should not be restricted to 'expect' in the assertion chapter.
 
-Eugene
 
----------------------------------------------------------------------

if( ##[1:10] @(posedge clk ) data == value ) success = 1 ;

else success = 0 ;

Also, we can use '!' (not) to construct 'else' part more naturally as:

if ( ! ( ##[1:10] @(posedge clk) data == value ) ) $error( " data check
failed" ) ;

It will also expand the flexibility to write various checking condition

as:

while( !( ##[1:10] @(posedge clk) data == value ) )

{ error_count++ ; if( error_count > 1000 ) ..

}

------------------------------------------------------------------------

-----Original Message-----

From: Surrendra Dudani [mailto:Surrendra.Dudani@synopsys.com]

Sent: Monday, October 04, 2004 10:43 AM

To: sv-ec@eda.org

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

Hi Eugene,

Please see my response in comments.

Surrendra

At 12:40 PM 10/1/2004 -0700, you wrote:

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).

The "expect" statement evaluates a property to be true or false. A
sequence may be part of the property.

A sequence evaluation can fork of different threads of evaluation,
creating in a way multiple processes, all of them possibly ending at
different times, or failing at different times. Seems rather complex.

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.

Is your intention to use assertion syntax with different semantics?

Let's me if you'd like more information or example code. Hope you can
vote for this errata ( 255).

Please give some concrete examples to clarify your ideas.

-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

**********************************************

**********************************************
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
**********************************************

**********************************************
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 Wed Oct 6 22:11:44 2004