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 08:58:29 2007
This archive was generated by hypermail 2.1.8 : Mon Dec 17 2007 - 08:58:39 PST