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

36.45 property spec (from 36.44 ...) 

Thx.
-Bassam.

-----Original Message-----
From: Jim Vellenga [mailto:vellenga@cadence.com] 
Sent: Monday, December 17, 2007 8:32 AM
To: Bassam Tabbara; Lisa Piper; sv-cc@eda.org
Cc: sv-ac@eda.org
Subject: RE: [sv-ac] RE: [sv-cc] mantis 1503

OK, I see the iteration to variables from sequence decl, but which
diagram has it for the property decl?

Regards,
Jim

--------------------------------------------------------- 
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: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]
]Sent: Monday, December 17, 2007 11:26 AM
]To: Jim Vellenga; Lisa Piper; sv-cc@eda.org
]Cc: sv-ac@eda.org
]Subject: 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.