RE: [sv-ac] Re: [sv-cc] question on Assertion iterators

Hi Lisa, 

My input below with BT>>. Note that my aim is to explain the intent,
some things are in my opinion clear, others seem not and I recommend
adding clarification. For any and all though, please feel free to create
clarification mantis items.

Thx.
-Bassam.

-----Original Message-----
From: Lisa Piper [mailto:piper@cadence.com] 
Sent: Monday, October 15, 2007 10:41 AM
To: Bassam Tabbara; sv-ac@eda-stds.org; sv-cc@eda-stds.org
Cc: Charlie Dawson
Subject: RE: [sv-ac] Re: [sv-cc] question on Assertion iterators

Hi Bassam,

I looked for references to instances in chapter 38, I don't see any. It
is vague in that it says "sequence", not sequence instance or sequence
declaration. 

BT>> Please file mantis item if you feel this clarification is needed,
albeit as I mention below, this really should be not be debatable, insts
are what has data -- there is a one liner note (right before 38.3.2) "As
with all VPI handles, assertion handles are handles to a specific
instance of a specific assertion." If 38 has a fault (also 39 has this
failing) is that "assertion" (may be ok in 36.42 diagram "assertion" vs.
"assert" but not so much in text) is used loosely to mean all the
"types" of insts (see 38.3.2) so confusing a bit on first read.

It simply says CB and control routines are for assertion handles.
So what's an assertion?  It sounds like you're saying sequence and
property instances are assertions on their own (making it consistent
with 36.42 diagram).  But what is the "handle" for an instance of a
property or sequence? There is no name provided. There is a name
provided for the "declaration" of a sequence or property. 

BT>> Yes on first part for 36.42 "Assertion" (covers types: assert,
cover...) also see 38.3.2.  Again for CBs intent is to apply to all that
make sense e.g. for success/fail CBs (used in coverage clause 39) a
debugging application for example would want to track the prop/seq inst
*matches* (aka success). For on/off/enable/disable control, the text is
meant to be explicit to talk about directives, but I think a
clarification here is worthwhile indeed , since "assertion"/"attempt"
are used loosely throughout. I only skimmed now forget if this really
made explicit, seems not.

** The vpiName is missing from diagram you are right (**also Immediate
needs one**). The name would be a simple name here.

A concrete example will help me.

module M;

reg a,b,c,d,e,f, clock;

default clocking CB1 @(clock);
endclocking

sequence S1(XX);
 a ##1 XX;
endsequence

property P1(YY);
 b |=> S1(c) ##1 YY;
endproperty

assert1: assert property ( if(f) (S1(d) |=> P1(f)));

endmodule

What do I get from vpiAssertion iterator over module M?

BT>> For the instance M (see 36.9) you would get
Assert1, its vpiType is vpiAssert
P1 (of assert1), its vpiType is vpiPropertyInst
S1 (of assert1), its vpiType is vpiSequenceInst

BT>> ** Note: A similar example (albeit simpler -- pick off covers) is
found in 38.3.1 note (d).

BT>> ** Note: A traditional traversal would be as you say way below, a
top down, look for asserts and walk expression to pick off the used
insts within assert.

And for each handle, I can use vpi_register_cb() and vpi_control()?

BT>> ** Yes on Start/Result CB/Coverage Control: Clause 39 makes use of
this notion. For the on/off/enable/... CB/Control in 38, they are meant
to apply only at directive level (e.g. turning off a sequence has no
good semantics), this should be clarified, seems missing.

Lisa

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bassam Tabbara
Sent: Friday, October 12, 2007 5:15 PM
To: Lisa Piper; Bassam.tabbara@synopsys.com; sv-ac@eda-stds.org;
sv-cc@eda-stds.org
Cc: Charlie Dawson
Subject: [sv-ac] 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.


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