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 MailScanner <http://www.mailscanner.info/> , 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. 

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