Hi again Bassam, Another question below (in orange). Thanks! Lisa ________________________________ From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] Sent: Monday, October 29, 2007 4:41 PM To: Lisa Piper; Bassam Tabbara Cc: sv-ac@eda-stds.org; sv-cc@eda-stds.org; john.havlicek@freescale.com Subject: RE: VPI issues Hi Lisa, my comments in purple and prefixed with [Bassam] Thx. -Bassam. ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Monday, October 29, 2007 8:59 AM To: Bassam Tabbara Cc: sv-ac@eda-stds.org; sv-cc@eda-stds.org; john.havlicek@freescale.com Subject: RE: VPI issues Hi Bassam, I would like to get 1503 reassigned to myself and move it to SV-AC. I think that SV-AC should create and approve it and then it should move to SV-CC. These clarifications are significant and should make the 2008 release. [Bassam] I assigned to you and deleted the old proposal there. As far as moving category, I agree with you, it's reasonable for AC to decide on/make initial proposal on the needed clarifications and then CC can review. Charles can you change category ? If we need a committee vote please schedule for next meeting. BTW Lisa SV-CC discussed this a bit last meeting and people who commented (I recall JimV not sure who else) agree with me that "vpiArgument" iteration should only be on the class definition clause not anywhere else -- we can delete the "extra" one we already have for sequence. You state that the callbacks should apply to sequence instances and property instances. Please be more specific. Below is the list of possible callbacks. - cbAssertionStart. An assertion attempt has started. For most assertions, one attempt starts each and every clock tick. - cbAssertionSuccess. An assertion attempt reaches a success state. - cbAssertionFailure. An assertion attempt fails to reach a success state. [Bassam Tabbara] Only above, success == match , failure == no match. - cbAssertionStepSuccess. Progress one step an attempt. By default, step callbacks are not enabled on any assertions; they are enabled on a per-assertion/per-attempt basis (see 38.5.2), rather than on a per-assertion basis. - cbAssertionStepFailure. Fail to progress by one step along an attempt. By default, step callbacks are not enabled on any assertions; they are enabled on a per-assertion/per-attempt basis (see 38.5.2), rather than on a per-assertion basis. [Bassam Tabbara] Above two only meant for assertion level "progress". - cbAssertionDisable. The assertion is disabled (e.g., as a result of a control action). - cbAssertionEnable. The assertion is enabled. - cbAssertionReset. The assertion is reset. - cbAssertionKill. An attempt is killed (e.g., as a result of a control action). - cbAssertionDisablePassAction. The pass action is disabled for vacuous and nonvacuous success for the assertion (e.g., as a result of control action). - cbAssertionEnablePassAction. The pass action is enabled for vacuous and nonvacuous success for the assertion (e.g., as a result of control action). - cbAssertionDisableFailAction. The fail action is disabled for the assertion (e.g., as a result of control action). - cbAssertionDisableVacuousAction. The pass action is disabled for vacuous success of the assertion (e.g., as a result of control action). - cbAssertionEnableNonvacuousAction. The pass action is enabled for nonvacuous success of the assertion (e.g., as a result of control action). [Bassam Tabbara] Rest are already clarified in your proposal that you cannot register control CBs to begin with, so you won't get these calls. If you think we need another clarification to be sure in this CB listing section, I'm ok with that. These callbacks are specific to a given assertion; placing such a callback on one assertion does not cause the callback to trigger on an event occurring on a different assertion. If the callback is successfully placed, a handle to the callback is returned. This handle can be used to remove the callback via vpi_remove_cb(). If there were errors on placing the callback, a NULL handle is returned. As with all other calls, invoking this function with invalid arguments has unpredictable effects. In the above statement, why wouldn't you say it should be ignored, versus unpredictable affects. [Bassam Tabbara] I do not recall roots of sentence. I think we should strike out the entire last sentence and remain silent (much like vpi_register_cb is in 37.34.1.1), meaning it will fall into the general VPI specification. Note sure now if there is language that speaks to this in VPI but VPI implementations do ignore handles that have no registered CB for example. In 39.5.3 (coverage API), do you agree that the coverable entities are assertions that are not property and sequence instances? [Bassam Tabbara] There is nothing technically that precludes the coverage API from being applied to property/seq inst in a similar fashion to assertions to obtain counts, however as the clause stands today (I don't remember why, may be deadlines forced limiting discussion scope and examples) it talks of *assertions* as coverable entities meaning the directive level yes and provides examples of same. [Lisa Piper >>>] Where does it say that an "assertion_handle" is not a property or seq instance? 38.1 clause describes "Obtaining assertion handles" , which includes sequence instances and property instances. Then 39.5.3 describes vpi_get(vpiCovered, assertion_handle) which unfortunately uses the same terminology. I don't see how it is currently precluded, though I think it should be precluded because I can't think of an application for it. If I remember correctly, "let" has been applied as an assertion too. Do you agree that "let instances" should follow the same behavior as sequence and property instances relative to all of the above? [Bassam Tabbara] Yes I do. Lisa ________________________________ From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] Sent: Sunday, October 21, 2007 4:07 PM To: Lisa Piper; Bassam Tabbara Cc: sv-ac@eda-stds.org; sv-cc@eda-stds.org; john.havlicek@freescale.com Subject: RE: VPI issues Hi Lisa, Comment on your question can be found below and yes 1503 is a good mantis item to use, old proposal there can be deleted. Overall, the proposal looks good and is mostly consistent with our cleanup discussion -- thx for putting in the diagramming effort. The one change I do not agree with is that of 38.4.2 which disallows CBs to seq/inst. As I explained in some detail before you do need to get the result of sequence/property inst, otw the data is lacking -- each inst has a unique handle instance so there is no issue here. Thx. -Bassam. ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Saturday, October 20, 2007 7:28 PM To: Bassam Tabbara Cc: sv-ac@eda-stds.org; sv-cc@eda-stds.org; john.havlicek@freescale.com Subject: VPI issues Hi Bassam, I have drafted a proposal for the issues we have been discussing. I would like to push to get this approved for the 2008 release of the standard. I think it would be good to combine this with the existing 1503 since there is a lot of overlap. The changes of 1503 are included in the attached with the exception of the changes to the property spec. Regarding the property spec, I question whether you need to make the change (that is, add vpiArgument to the property inst box) since this is shown in the property declaration diagram. [Bassam Tabbara] I don't think it's needed, should be on the definition diagram really -- I had added there on the 1503 mini proposal to be somewhat consistent with the sequence version. Actually, if you look at 36.48 you can see it's actually there is a weird way in 36.48 (that iteration to "arguments" !). Not sure exactly what the policy should be (I would think it needs to be on the *definition* diagram not on rest), so will leave it up to CC to discuss and figure out exactly the cleanup needed including 36.48. And if it is needed, then I would think you would also need it for the sequence expr, which can be a sequence instance. I would appreciate if you could review the attached so we can jointly get this to the point of being able to vote on it. Review the top part where I point out the things I'm not sure of. I will be on the road until Wednesday and may not be able to check email. <<vpiIdentifier.doc>> Lisa P.S. note that 1503 has not been updated to reflect draft 4 so it will likely be easier to start from the attached -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Oct 29 20:23:19 2007
This archive was generated by hypermail 2.1.8 : Mon Oct 29 2007 - 20:23:34 PDT