Subject: Re: problems with current definition/document
From: Bassam Tabbara (bassam@novas.com)
Date: Mon Jul 22 2002 - 11:54:27 PDT
Thanks Adam, for responding to Cindy. I include a clarification on one
item.
For the item below, please note that the assert does NOT block. Does
this answer your question Cindy ? Please refer to LRM, there is an
implicit "process" keyword in the form "process assert ..." i.e. a
separate thread (or instance of an FSM :-)!) is created.
-Bassam.
Adam Krolnik wrote:
[...]
> >4. the current definition seems to allow the use of assertions in such a
> >way that the design itself is affected. for instance, consider this example,
> >slightly modified from
> > page 46:
>
> > always @(posedge clk)
> > if (state == REQ)
> > b7: assert(req1)
> > @(posedge clk) assert(gnt)
> > @(posedge clk) assert(!req1);
> > state = #1 WAIT;
>
> > i am not sure if this is legal (and my verilog is very rusty, so
> > perhaps i have syntax
>
> There are certain advantages to using the temporal expression within
> assertions for verification codes. I have written monitors that used
> the temporal expressions from assertions to detect events in the
> hardware and send the proper data to the monitor. Another example is
> the use of coverage assertions that want to perform certain operations
> based on the event being found. Data may be collected, etc.
>
> But for hardware, you are correct, assertions are expected to have no
> side effects. A simulator may even choose to not implement assertion
> simulation if desired and this thus should have no negative effect on
> the proper outcome (though it may have negative effects when it comes
> to improper outcomes - that of taking longer to diagnose the problems.)
>
> ===========================================================================
-- Dr. Bassam Tabbara Technical Manager, R&DNovas Software, Inc. bassam@novas.com (408) 467-7893
This archive was generated by hypermail 2b28 : Mon Jul 22 2002 - 11:56:57 PDT