[sv-ac] Sketch for the new version of 1756

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Tue Oct 30 2007 - 06:13:56 PDT
Hi all,

 

Since there were objections regarding the solution proposed in 1756 I
had an action item to send a sketch of other potential solutions for
this enhancement.

 

The problem:

 

All concurrent assertions belonging to initial procedures, are
suppressed in case that at the initial time $asserton or $assertkill
control tasks was issued. However, this behavior is not always
desirable, and there should be a method to start checking these
assertions as soon as an appropriate $asserton control task has been
called.

 

Consider the following scenario:

 

The assertion is written to check that a eventually happens

 

initial a1; assert property(@clk ##[*0:$] a);

 

but $assertoff has been issued for all assertions at the beginning of
the simulation to skip the reset sequences. When $asserton is issued,
the above assertion is lost.

 

The original proposal suggested that in case the assertions have
initially been disabled, start checking them when they are enabled for
the first time.

 

The objection claimed that this enhancement is not backward compatible,
and also, there is a problem when the user intention was indeed to
suppress the assertions in the initial procedures.

 

Here are two possible backward compatible solutions:

 

1.	Introduce a new directive $assertdelay. If it has been issued at
the beginning of simulation, all assertion checks are suspended until
the first $asserton.
2.	Introduce an additional optional argument to the control tasks
$assertoff and $assertkill. If it is 0, then their behavior is as it is
described currently in the LRM. If it is 1, and these directives were
issued at the beginning of the simulation, the concurrent assertions in
initial procedures are checked when they become first enabled.
	E.g., $assertoff(a1) - initially issued disables the assertion
a1 forever, $assertoff(a1, 1) delays checking  the assertion a1 until
the first $asserton(a1) is issued.

 

What is your opinion?

 

Thanks,

Dmitry

 

---------------------------------------------------------------------
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.
Received on Tue Oct 30 06:14:35 2007

This archive was generated by hypermail 2.1.8 : Tue Oct 30 2007 - 06:15:11 PDT