RE: [sv-cc] mantis 1503

Bassam and Lisa,

Now that I've started actually looking at the proposal, I have some 
concerns.

I think that unfortunately when we included VPI support for assertions 
as part of IEEE Std 1800-2005, none of us were really familiar both 
with assertions and with the basic approaches of VPI, nor did we have 
time to learn.  So we wound up with some inconsistencies.  Now would be 
a good time to clean those up.

1. vpiDefFile and vpiDefLineNo

The proposal is trying to clarify what vpiDefFile and vpiDefLineNo mean 
for assertion related constructs, but I'm having a hard time 
understanding why they're there in the first place.

Back in the old days, the VPI model failed to distinguish between 
definitions and instances of models, or between declarations and 
instances of nets and variables.  Cadence already has clients for which 
this is a problem.  Be that as it may, in other cases we have separated 
function calls from function declarations, task calls from task 
declarations, and soon (I hope) class defns from class specializations.

Once we make such a separation, as the API model has already done for 
properties and sequences, then there is no reason to have a separate 
vpiDef<whatever>.  One simply obtains the decl from the inst, and gets 
the file and line info from the decl directly.

For this reason, rather than clarifying that vpiLineNo and vpiFile for 
a property decl mean the same thing as vpiDefLineNo and vpiDefFile, I 
would prefer to deprecate the latter properties altogether.  I also 
would remove them from property insts, and not add them to sequence 
insts at all, since one can get the information from the corresponding 
decls.

Finally, I don't know enough about the concurrent assertions to know 
what vpiDefFile and vpiDefLineNo refer to for them.  The vpiLineNo and 
vpiFile properties are enough to indicate where the assertions 
themselves are.  Is there a separate definition somewhere?

2. Handles for assertions in assertion callbacks

In the descriptions of individual callbacks, there are a whole buncha 
statements saying "This does not apply to property or sequence 
instances."  This is confusing for two reasons:

(a) It's not clear what "This" refers to.  It seems most likely to mean 
that you can't apply the particular callback to a property inst or 
sequence inst, but it could instead refer to the described action not 
happening.

(b) In a standard in general, it would be better to say what the 
callbacks do apply to rather than what they do not.

Could I suggest instead adding a paragraph following the descriptions 
that says something more precise, such as:

"Each of these callbacks may be registered on either a concurrent 
assertion (See 36.43) or an immediate assert (See 36.<whatever>).  The 
cbAssertionStart, cbAssertionSuccess, and cbAssertionFailure callbacks 
may also be applied to a sequence inst (See 36.47) or property inst 
(See 36.48)."

Does that in fact accurately describe what's possible?

3.  The canonical decompiler application

This is probably outside the scope of the present proposal, but one of 
the canonical applications that we keep testing the VPI object model 
against is the decompiler application.  Can we reconstruct an 
equivalent form of the source code using our existing constructs?

It appears to me that this is not the case for a property decl or 
sequence decl.

-- You can't get to a property decl unless you get there via a property 
inst.  So if the source declares a property but doesn't create an 
instance of it anywhere, the decompiler cannot find that property decl.

-- Even if an instance exists, you can't tell what scope the property 
declation occurs in.  It could be the immediate scope of the instance 
or any superior scope.

-- You can't iterate over the variables declared in the property 
declaration.

The same is true, of course, for sequence declarations.

These shortcomings should (eventually) be remedied.  For example, we 
could add an iteration from scopes to, say, a vpiAssertionDecl that 
would comprise both property decls and sequence decls.  And one could 
fairly easily add an iteration to the variables declared in either 
form.  Or perhaps, property decls and sequence decls could be added as 
scopes to the diagram in "36.11 Scope," with enough details added to 
indicate any limitations.

I hope this is helpful.

Regards,
Jim Vellenga

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Software Architect                     (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information." 
----------------------------------------------------------  

]-----Original Message-----
]From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
]Behalf Of John Havlicek
]Sent: Thursday, December 13, 2007 9:45 AM
]To: sv-cc@eda.org
]Cc: sv-ac@eda.org
]Subject: [sv-cc] mantis 1503
]
]Hi SV-CC:
]
]SV-AC passed the proposal for 1503 (VPI diagram of propertyinst has no
]vpiArgument).  This proposal should now be reviewed and modified or
]approved by SV-CC.
]
]Best regards,
]
]John H.
]
]-- 
]This message has been scanned for viruses and
]dangerous content by MailScanner, and is
]believed to be clean.
]
]

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