Subject: Assertion Committee Meeting Minutes
From: Tom Fitzpatrick (fitz@co-design.com)
Date: Fri Mar 08 2002 - 10:56:23 PST
Meeting was held: 3/8/02, 9am PST
Attendees:
Gail Dagan (Intel)
Tom Fitzpatrick (Co-Design)
Tom Anderson (0-in)
Peter Flake (Co-Design)
Prakash Narain (Real Intent)
David Lacey (HP)
Simon Davidmann (Co-Design)
Rajeev Ranjan (Real Intent)
Adam Krolnik (LSI)
Next meeting: Wed. 3/13/02, 9am PST. Location to be announced
conf. call number: (405)244-5555 x3715
Agenda:
Prioritize and schedule the sections of the donation document.
Begin discussing things in-depth.
Thursday's (3/14) Accellera meeting is not required to keep Assertions
voting rights.
Remaining meetings tentatively scheduled for Thursdays, 3/21-4/25, 9am PST.
Conf. call number: (405)244-5555 x3715
Issue1: for discussion
@(posedge clk)(a;b;c)
vs.
(a;b;c) @@(posedge clk);
Discuss whether @(posedge clk) before should block or not. If it doesn't
block, then that breaks Verilog semantics since other places where
"@(posedge clk) is encountered, it blocks.
Is there another token besides '@@' to mark the clock on the end? Peter to
review.
Other point: Prakash's preference
If the sequence is always evaluated immediately, you can just use (1;a;b) to
wait until next clock to look at 'a', with @@(posedge clk) always at the
end. Using this convention, the @(posedge clk) is never needed before the
sequence.
Issue2: Examples for Clocked Assertions
Give examples of implicit clock vs. explicit clock
Explicit clock in combinational block
Include fail statements in nested assert statements
Show nested assertions with different clocks
Issue3: Antecedent and Consequent
use @@(posedge ck1) instead of @@(ck1)
Add example to show ck1 as named event (back in "clocked assertions"
section)
Issue4: Reset examples
assert reject(!busy)(a;b;c) => assert(a&&busy;b&&busy;c&&busy)
Rajeev to provide another example
Issue5: reject/accept
Could accept/reject be used from other blocks, similar to disable?
if(foo) accept asrt1;
Issue6: Controlling assertions
"started" means that the assert statement has been executed.
Adam suggested that $assertoff should turn off even assertions that have
been started. Peter to consider $assert_kill or something.
Should you be able to specify a module name, not just an instance name, to
$assertoff? Should we follow $dumpvar() rules?
Can we allow wildcards?
Issue7: Controlling the steps
Change rst to enable in the example.
This is most applicable to gated clocks.
What is the utility of this vs. using a derived clock? Many users find it
easier to use 'iff' rather than having to create an explicit derived clock
signal.
Issue8:
Further Enhancements sections to be removed.
Issue9:
Assertion committee will recommend useful system functions, as another
section to the document. This will have to be included in SystemVerilog.
I'll go back and tally the attendance from previous meetings to make sure
that everyone is elibible to vote.
Thanks Everyone!
-Fitz
+----------------------------+------------------------------------------+
| Tom Fitzpatrick | Tel: 1 978 448 8797 |
| Technical Product Manager | Mobile: 1 978 337 7641 |
| Co-Design Automation, Inc. | email: fitz@co-design.com |
+----------------------------+------------------------------------------+
| Web: www.co-design.com | Latest News: |
| www.superlog.org | http://www.co-design.com/news/index.htm |
+----------------------------+------------------------------------------+
| SUPERLOG = Faster, Smarter Verilog |
+-----------------------------------------------------------------------+
This archive was generated by hypermail 2b28 : Fri Mar 08 2002 - 10:55:45 PST