RE: [sv-ac] Mantis 2091 feedback needed

Lisa,
 
You did not add foreach in this paragraph:
 
"automatic variables and members or elements of dynamic variables cannot
be referenced in an assertion.   This includes class properties,
dynamically sized variables, data in automatic tasks, functions, or
blocks, and for loop variables (see 12.7.1) "
 
Also, you left the xref as 12.7.1. That is correct for for loop, but
foreach is in 12.7.3.
 
Regard,s
Shalom



________________________________

	From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org] On Behalf Of Lisa Piper
	Sent: Thursday, December 06, 2007 1:06 AM
	To: Lisa Piper; Bassam Tabbara; sv-ac@server.eda.org
	Subject: RE: [sv-ac] Mantis 2091 feedback needed
	
	

	Hi again Bassam,

	 

	Thanks for the feedback.  There are more answers and questions
below.  Thanks!

	 

	Lisa

	 

	
________________________________


	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Lisa Piper
	Sent: Wednesday, December 05, 2007 5:58 PM
	To: Bassam Tabbara; sv-ac@eda.org
	Subject: RE: [sv-ac] Mantis 1898 feedback needed

	 

	Hi Bassam,

	 

	Sorry - it is Mantis 2091.

	 

	 

	 

	
________________________________


	From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
	Sent: Wednesday, December 05, 2007 1:20 PM
	To: Lisa Piper; sv-ac@eda.org
	Subject: RE: [sv-ac] Mantis 1898 feedback needed

	 

	Hi Lisa,

	 

	I don't think it's 1898, which proposal is it ? Some comments
below.

	 

	Thx.

	-Bassam.

	 

	 

	
________________________________


	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Lisa Piper
	Sent: Tuesday, December 04, 2007 2:42 PM
	To: sv-ac@eda.org
	Subject: [sv-ac] Mantis 1898 feedback needed

	Mantis 1898 says a clarification is needed where concurrent
assertions may appear and what kind of variables they may use. The
Mantis item states that the following restrictions should apply:

	* concurrent assertions shall not use automatic variables

	* concurrent assertions may not appear in a fork-join block

	I have created the following text to insert. I just want
agreement on the concept at this point. I would like to also address the
issue for immediate assertions which I think is more vague. Note that I
have allowed for the for loop index variable which is an automatic
variable since 1995 assertions in loops would require this.

	================================================

	All data referenced in a concurrent assertion, with the
exception of local variables(see 16.9)  and for and foreach loop indices
(see 12.7.1), must have a static lifetime (exist for the whole
elaboration and simulation time).  Similarly, concurrent assertions may
only exist in blocks whose lifetime is also static.  So for example, 

	*	automatic variables and members or elements of dynamic
variables cannot be referenced in an assertion.   This includes class
properties, dynamically sized variables, data in automatic tasks,
functions, or blocks, and for loop variables (see 12.7.1) 
		[Bassam Tabbara] I think this is too broad a restriction
on dynamic vars. A class object for example may be persistent for
duration of sim or some part of it so disallowing use of properties is
overkill. 

	[Lisa Piper >>>] what do others think? My problem is that I
can't think of an example.

	*	Class methods (see Clause 8) are only active for the
lifetime of the call.  Similarly, the lifetime of a fork...join,
fork...join_any, or fork...join_none block is limited to the execution
of all processes spawned by the block, and the lifetime of a scope
enclosing any fork block includes the lifetime of the fork block.  Class
methods and fork...join, fork...join_any, or fork...join_none blocks
therefore may not contain concurrent assertions or have its elements
referenced by a concurrent assertion. 

	All variables in an assertion use the sampled value with the
exception that local variables and for and foreach loop variables use
the current value.

	Because immediate assertions are procedural, they may exist in
automatic tasks, functions, and blocks, however because they are not
static, assertion control tasks(see 19.10)and assertion action control
tasks(see 19.11) and VPI do not apply.  Only assertion system controls
in VPI apply to immediate assertions that are not static.
	[Bassam Tabbara] I don't understand this, if the assertion is
allowed why not control.

	[Lisa Piper >>>] The assertion does not always exist and I'm not
sure if it can have a hierarchical name to which address it by.  How
does the VPI handle other dynamic properties?

	
	-- 
	This message has been scanned for viruses and 
	dangerous content by <http://www.mailscanner.info/> MailScanner,
and is 
	believed to be clean. 


	-- 
	This message has been scanned for viruses and 
	dangerous content by <http://www.mailscanner.info/> MailScanner,
and is 
	believed to be clean. 
	-- 
	This message has been scanned for viruses and 
	dangerous content by MailScanner <http://www.mailscanner.info/>
, and is 
	believed to be clean. 

---------------------------------------------------------------------
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.