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
- **********************************************
This archive was generated by hypermail 2.1.8 : Thu Oct 07 2004 - 06:55:19 PDT