RE: [sv-ac] RE: [sv-cc] mantis 1503

Hi Jim,

Thanks for the review some comments below with BT>>.

Thx.
-Bassam.

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Jim
Vellenga
Sent: Monday, December 17, 2007 8:09 AM
To: Bassam Tabbara; Lisa Piper; sv-cc@eda.org
Cc: sv-ac@eda.org
Subject: [sv-ac] 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

**BT>> Agreed on all counts. This is "known issue" (for property/seq
"def" variants are redundant-- decl available, for concurrent assertion
"def" are same as non), only kept because they were there. Deprecation
is ok by me if no extra hassle.

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

**BT>> Paragraph is correct, change is ok by me.

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

** BT>> Agreed that decompile is not addressed in general for prop/seq
decl, and yes outside scope of this proposal.

** BT>> One *can* iterate over variable declarations in prop/seq decl
with the --->> variables.

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.



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