Lisa, as I read the BNF (16.12 in Draft 4), the full property declaration has the form define property P1; { <assertion_variable_declaration> } <property_spec> endproperty Thus, you can have variables declared as part of the property declaration, but not as part of the property spec. So in the "assert1" form that you listed, isn't it true that the property spec cannot have any locally defined variables? 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: Lisa Piper ]Sent: Monday, December 17, 2007 2:13 PM ]To: Bassam Tabbara; Jim Vellenga; sv-cc@eda.org ]Cc: sv-ac@eda.org ]Subject: RE: [sv-ac] RE: [sv-cc] mantis 1503 ] ]I would think that it needs to be there in case you do not ]declare a standalone property. For example: ] ]define property P1; ] <property_spec> ]endproperty ]assert2: assert property P1; ] ]assert1: assert property <property_spec>; ] ]Lisa ] ]-----Original Message----- ]From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] ]Sent: Monday, December 17, 2007 11:57 AM ]To: Jim Vellenga; Lisa Piper; sv-cc@eda.org ]Cc: sv-ac@eda.org ]Subject: RE: [sv-ac] RE: [sv-cc] mantis 1503 ] ]Good point, no idea why it is so. ] ]Thx. ]-Bassam. ] ]-----Original Message----- ]From: Jim Vellenga [mailto:vellenga@cadence.com] ]Sent: Monday, December 17, 2007 8:51 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'll bite. Why are the variables attached to the property spec but ]to the sequence decl? That doesn't seem to match the BNF. ] ]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:34 AM ]]To: Jim Vellenga; Lisa Piper; sv-cc@eda.org ]]Cc: sv-ac@eda.org ]]Subject: 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.Received on Mon Dec 17 13:08:58 2007
This archive was generated by hypermail 2.1.8 : Mon Dec 17 2007 - 13:09:13 PST