Subject: Re: Assertion Committee Meeting Minutes
From: Rajeev Ranjan (rajeev@realintent.com)
Date: Fri Mar 08 2002 - 18:07:05 PST
Hi Tom,
Here are a couple of examples:
always @(posedge clk)
if (fifoFsmState == READ)
assert accept(ack) (dataValid * [0:15]);
Once the fifo goes to READ state, the dataValid must be held high for 15
cycles or when the ack goes high, whichever comes first.
always @(arbiterState or request)
if (arbiterState == GRANT)
assert reject(~request) ((arbiterState==GRANT)*[0:5]) @@(posedge
clk)
Once the arbiter goes to GRANT state, it must stay in that state for at
least next 5 cycles during which the request signal cannot be lowered.
-rajeev
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Rajeev K. Ranjan + Tel: (408) 982-5418
Director, R&D + Fax: (408) 982-5443
Real Intent +
3910 Freedom Circle, Suite 102A + rajeev@realintent.com
Santa Clara, CA 95054 + http://www.realintent.com
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
----- Original Message -----
From: "Tom Fitzpatrick" <fitz@co-design.com>
To: <assertion@eda.org>
Sent: Friday, March 08, 2002 10:56 AM
Subject: Assertion Committee Meeting Minutes
> 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 - 18:12:45 PST