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

That's a good point.  I think this is basically the same issue we're
facing whenever we want to have a glitch-free assertion in an unclocked
context; this will be on our f2f discussion agenda next week.  Some of
the options to consider are checking these every time step, or each
global clock tick; if we have global clocking anyway, this may not be
that different from a @$global_clock assertion.



-----Original Message-----
From: Thomas.Thatcher@Sun.COM [mailto:Thomas.Thatcher@Sun.COM] 
Sent: Thursday, September 27, 2007 2: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
------------------

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