Re: [sv-cc] question on Assertion iterators

Hi Lisa,

CB registration would be in 1 too. Now what I think you are missing is again *instances* that is what data -- note that you can register and query results for prop/seq insts (hence the diagram and the API where "assertion" also can mean prop/seq insts) too. So not agreed :).

Yes the flow you have at bottom works and inside it you did say insts. Make sense ? A def is just that and you have many insts. Also on top of that you have attempts. 

When it comes to results you need instances, for structural checks you need the def. It's not a question of "might" each has a purpose :). The name is what the syntax has where instantiated.

THX. 
-Bassam

-----Original Message-----
From: Lisa Piper <piper@cadence.com>
To: Bassam Tabbara <Bassam.Tabbara@synopsys.COM>; sv-ac@eda-stds.org <sv-ac@eda-stds.org>; sv-cc@eda-stds.org <sv-cc@eda-stds.org>
CC: Charlie Dawson <chas@cadence.com>
Sent: Fri Oct 12 12:49:10 2007
Subject: RE: [sv-cc] question on Assertion iterators

Thanks Bassam!  Can you help me to understand the flow?  Let’s say I have a list of all the VPI iterators.  I can do two things:

 

1)     Turn assertions on/off or check the states/statistics of them.

2)     Do RTL checks

 

Is this correct?  

 

Do we agree that instances of properties and sequences are of no value for application #1.  

Instances of properties and sequences “might” be of value for RTL checks:

 

a)     to check that the formal arguments are correctly typed?

b)     I can work my way back to the definition of that instance and do RTL checks on it too, but that MIGHT not be as efficient as just doing it once on the property definition, unless there are formal arguments. If it has formal arguments, you’d need the substitute the formal arguments which means that you’d need the instance.  But then doesn’t this need to be checked in the context of the assertion definition too? 

 

I would have thought the flow would be to get a list of all assertions, that being all concurrent and all immediate assertions, and then for each, you’d work your way down to determine the property spec, property expressions/instances, and sequence expressions/instances.

 

One other question, what is the name of a sequence instance? Is it just a pointer where the name is NULL?

 

Lisa

 

 

 

________________________________

From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
Sent: Friday, October 12, 2007 2:38 PM
To: Lisa Piper; sv-ac@eda-stds.org; sv-cc@eda-stds.org
Cc: Charlie Dawson
Subject: RE: [sv-cc] question on Assertion iterators

 

Hi Lisa,

 

The diagram corresponds directly to the Assertion API (see the assertion API clause in the respective draft). This should have *instances* of course (to register/get CBs, control etc...). The decls are just the *def* and you can get to that from the instance if needed.

 

Thx.

-Bassam.

 

 

________________________________

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Lisa Piper
Sent: Friday, October 12, 2007 8:26 AM
To: sv-ac@eda-stds.org; sv-cc@eda-stds.org
Cc: Charlie Dawson
Subject: [sv-cc] question on Assertion iterators

Hi all,

Why is sequence instance and property instance listed as members of the vpiAssertion iterator instead

of sequence decl and property decl?  (Section 27.31 of existing std and 36.42 of draft 4) It is the declarations that would be in the module/package scopes and members of the iterator.

Lisa 


-- 
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 anddangerous content by MailScanner, and isbelieved to be clean.