Hi Lisa, Yes on both counts, name would be simple, I just added to clarify my reply -- the name is not a good means to differentiate even if you decompile fully. Yes you can have multiple insts -- You would have to traverse from top expression (assert for example) to know the inst/handle in expression structure. Thx. -Bassam. ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Monday, October 15, 2007 1:19 PM To: Bassam Tabbara; sv-ac@eda-stds.org; sv-cc@eda-stds.org Cc: Charlie Dawson Subject: RE: [sv-ac] Re: [sv-cc] question on Assertion iterators Thanks Bassam, I have another question below. I will file some Mantis items but need to figure out what they are first. Lisa -----Original Message----- From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] Sent: Monday, October 15, 2007 3:49 PM To: Lisa Piper; sv-ac@eda-stds.org; sv-cc@eda-stds.org Cc: Charlie Dawson Subject: RE: [sv-ac] Re: [sv-cc] question on Assertion iterators Hi Lisa, My input below with BT>>. Note that my aim is to explain the intent, some things are in my opinion clear, others seem not and I recommend adding clarification. For any and all though, please feel free to create clarification mantis items. Thx. -Bassam. -----Original Message----- From: Lisa Piper [mailto:piper@cadence.com] Sent: Monday, October 15, 2007 10:41 AM To: Bassam Tabbara; sv-ac@eda-stds.org; sv-cc@eda-stds.org Cc: Charlie Dawson Subject: RE: [sv-ac] Re: [sv-cc] question on Assertion iterators Hi Bassam, I looked for references to instances in chapter 38, I don't see any. It is vague in that it says "sequence", not sequence instance or sequence declaration. BT>> Please file mantis item if you feel this clarification is needed, albeit as I mention below, this really should be not be debatable, insts are what has data -- there is a one liner note (right before 38.3.2) "As with all VPI handles, assertion handles are handles to a specific instance of a specific assertion." If 38 has a fault (also 39 has this failing) is that "assertion" (may be ok in 36.42 diagram "assertion" vs. "assert" but not so much in text) is used loosely to mean all the "types" of insts (see 38.3.2) so confusing a bit on first read. It simply says CB and control routines are for assertion handles. So what's an assertion? It sounds like you're saying sequence and property instances are assertions on their own (making it consistent with 36.42 diagram). But what is the "handle" for an instance of a property or sequence? There is no name provided. There is a name provided for the "declaration" of a sequence or property. BT>> Yes on first part for 36.42 "Assertion" (covers types: assert, cover...) also see 38.3.2. Again for CBs intent is to apply to all that make sense e.g. for success/fail CBs (used in coverage clause 39) a debugging application for example would want to track the prop/seq inst *matches* (aka success). For on/off/enable/disable control, the text is meant to be explicit to talk about directives, but I think a clarification here is worthwhile indeed , since "assertion"/"attempt" are used loosely throughout. I only skimmed now forget if this really made explicit, seems not. ** The vpiName is missing from diagram you are right (**also Immediate needs one**). The name would be a simple name here. A concrete example will help me. module M; reg a,b,c,d,e,f, clock; default clocking CB1 @(clock); endclocking sequence S1(XX); a ##1 XX; endsequence property P1(YY); b |=> S1(c) ##1 YY; endproperty assert1: assert property ( if(f) (S1(d) |=> P1(f))); endmodule What do I get from vpiAssertion iterator over module M? BT>> For the instance M (see 36.9) you would get Assert1, its vpiType is vpiAssert P1 (of assert1), its vpiType is vpiPropertyInst S1 (of assert1), its vpiType is vpiSequenceInst [Lisa Piper >>>] wouldn't I also get S1 (of P1)? I could also provide an example that instantiates S1 twice in P1. How would I distinguish these? How does the VPI indicate "s1 (of P1)"? Is this the string that is returned? (I don't think so but I don't know how it gets distinguished.) BT>> ** Note: A similar example (albeit simpler -- pick off covers) is found in 38.3.1 note (d). BT>> ** Note: A traditional traversal would be as you say way below, a top down, look for asserts and walk expression to pick off the used insts within assert. And for each handle, I can use vpi_register_cb() and vpi_control()? BT>> ** Yes on Start/Result CB/Coverage Control: Clause 39 makes use of this notion. For the on/off/enable/... CB/Control in 38, they are meant to apply only at directive level (e.g. turning off a sequence has no good semantics), this should be clarified, seems missing. Lisa -----Original Message----- From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Bassam Tabbara Sent: Friday, October 12, 2007 5:15 PM To: Lisa Piper; Bassam.tabbara@synopsys.com; sv-ac@eda-stds.org; sv-cc@eda-stds.org Cc: Charlie Dawson Subject: [sv-ac] Re: [sv-cc] question on Assertion iterators Hi Lisa, CB registration would be in 1 too. Now what I think you are missing is again *instances* that is what data -- note that you can register and query results for prop/seq insts (hence the diagram and the API where "assertion" also can mean prop/seq insts) too. So not agreed :). Yes the flow you have at bottom works and inside it you did say insts. Make sense ? A def is just that and you have many insts. Also on top of that you have attempts. When it comes to results you need instances, for structural checks you need the def. It's not a question of "might" each has a purpose :). The name is what the syntax has where instantiated. THX. -Bassam -----Original Message----- From: Lisa Piper <piper@cadence.com> To: Bassam Tabbara <Bassam.Tabbara@synopsys.COM>; sv-ac@eda-stds.org <sv-ac@eda-stds.org>; sv-cc@eda-stds.org <sv-cc@eda-stds.org> CC: Charlie Dawson <chas@cadence.com> Sent: Fri Oct 12 12:49:10 2007 Subject: RE: [sv-cc] question on Assertion iterators Thanks Bassam! Can you help me to understand the flow? Let's say I have a list of all the VPI iterators. I can do two things: 1) Turn assertions on/off or check the states/statistics of them. 2) Do RTL checks Is this correct? Do we agree that instances of properties and sequences are of no value for application #1. Instances of properties and sequences "might" be of value for RTL checks: a) to check that the formal arguments are correctly typed? b) I can work my way back to the definition of that instance and do RTL checks on it too, but that MIGHT not be as efficient as just doing it once on the property definition, unless there are formal arguments. If it has formal arguments, you'd need the substitute the formal arguments which means that you'd need the instance. But then doesn't this need to be checked in the context of the assertion definition too? I would have thought the flow would be to get a list of all assertions, that being all concurrent and all immediate assertions, and then for each, you'd work your way down to determine the property spec, property expressions/instances, and sequence expressions/instances. One other question, what is the name of a sequence instance? Is it just a pointer where the name is NULL? Lisa ________________________________ From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] Sent: Friday, October 12, 2007 2:38 PM To: Lisa Piper; sv-ac@eda-stds.org; sv-cc@eda-stds.org Cc: Charlie Dawson Subject: RE: [sv-cc] question on Assertion iterators Hi Lisa, The diagram corresponds directly to the Assertion API (see the assertion API clause in the respective draft). This should have *instances* of course (to register/get CBs, control etc...). The decls are just the *def* and you can get to that from the instance if needed. Thx. -Bassam. ________________________________ From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Lisa Piper Sent: Friday, October 12, 2007 8:26 AM To: sv-ac@eda-stds.org; sv-cc@eda-stds.org Cc: Charlie Dawson Subject: [sv-cc] question on Assertion iterators Hi all, Why is sequence instance and property instance listed as members of the vpiAssertion iterator instead of sequence decl and property decl? (Section 27.31 of existing std and 36.42 of draft 4) It is the declarations that would be in the module/package scopes and members of the iterator. Lisa -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses anddangerous content by MailScanner, and isbelieved to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Oct 15 13:33:47 2007
This archive was generated by hypermail 2.1.8 : Mon Oct 15 2007 - 13:33:57 PDT