[sv-ac] RE: Mantis 2008: Glitches and Unique/Priority constructs (was in 2005)

Hi Tom,

I like your suggestion to introduce a clock for conditional statements.
Note, however that if a conditional statement is written in a function,
you will face exactly the same problem as in case of concurrent
assertions as defined in 2005: it is not known in a function whether it
is called from the clocked or from the unclocked context.

As for the simulation efficiency in case when the clock is the
simulation tick, it will not be necessarily very bad, since the
simulation tick clock in context of boolean assertions is actually
equivalent to its sensitivity list. Consider the following example:

assert property (@$tick a && b);

where $tick corresponds to a simulation tick event.

It is equivalent to

assert property (@($sampled(a) or @($sampled(b)) a && b);

Thanks,
Dmitry

-----Original Message-----
From: Thomas.Thatcher@Sun.COM [mailto:Thomas.Thatcher@Sun.COM] 
Sent: Thursday, September 27, 2007 11:50 PM
To: Seligman, Erik
Cc: Korchemny, Dmitry; sv-ac@eda-stds.org; Bresticker, Shalom
Subject: Mantis 2008: Glitches and Unique/Priority constructs (was in
2005)

Hi Erik,


I have been thinking about the issue of glitches and the Unique/Priority
constructs.

I think that the proper way to fix this is to change the syntax of the
unique
and priority constructs to allow for a event to serve as a clocking
mechanism
for example:

	unique (@posedge clk) case (a)

		0,1: $display("0 or 1");
		2: $display("2");
		4: $display("4");
	endcase

The clocking event would allow the unique or priority assertions to be
treated
as concurrent assertions that are clocked by a reasonable clock.  The
real
problem is when these constructs appear in an always_comb block.  An
always_ff
block is not going to have the same glitch problem.  But to create a
concurrent assertion in an always_comb block, you'll need a clock.
Otherwiase, You'll have to create some equivalent clock that ticks every
simulation time step, and that will kill simulation performance.

Tom

-- 
------------------
Thomas J. Thatcher
Sun Microsystems
------------------
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.