Hi NSS, I have a few comments/questions about the proposal: 1. Section 1, "Verification Units" In (b), you say "A verification task related to a design ... , at least one of which is bound to a design module or instance" I am a bit confused what does it mean when unbound vunit inherits a bound one. I can think about two different approachs, but both are bad: 1) Signals in the bound inherited vunit are considered to be signals from the design according to the binding, while other signals in the inheriting vunit are considered to be unbound This approach is bad, since it provides a way to violate inheritance restriction about hierarchy relationship of instances. Consider vunit A is bounded to u1, vunit B is not bounded and vunit C is bounded to u2. Instances u1 and u2 are not related - neither u2 is an instance within u1, nor u1 is an instance within u2. Then, B can inherit C (B is not bounded) and A can inherit B (B is not bounded). From the transitivity of inheritance we get that A inherits C, while A can not inherit C directly, since they are bounded to unconnected instances - we have an inconsistency 2) Inheriting vunit inherits also the binding of the inherited vunit This approach is also bad, since if in the previous example B inherits both A and C we can not determine the binding of B. Therefore, I think we should limit the inheritance between unbound and bound vunit to only the possibility of an unbound vunit to be inherited by a bound vunit. In this case, all signals in the inherited unbounded vunit should get the binding of the closest inheriting one. If you agree, then in (b) a top level vunit has to be bound. 2. Section 1.2, "Vpkg" You say "A vpkg must not contain modeling layer code". Didn't we agree that a vpkg must not contain overriding of signals, but still can contain definitions of auxilliary variables? I think auxilliary variables are very useful (counters etc.) when writing reusable properies, since their behaviour can also rely on formal parameters 3. Section 1.2, "Vpkg", Notes: You say: "Since a vpkg cannot be bound, either the vpkg as a whole must be parametrized ... " From this statement, one can conclude that every verification unit that is not bound must be parametrized or contain only parametric definitions. However, we allow unbound verification units that are not parametrized - they are just abstract. I suggest to remove "Since a vpkg cannot be bound". 4. Section 1.3, "Vmode" You say: "A default verification unit may not inherit or instantiate other verification units of any type" There is a reason while vmode default may not inherit other verification unit - since it is considered as to be explicitly inherited by all other verification units, if it inherits any of them then a circular inheritance is produced, which is disallowed. However, what is the reason not to allow instantiation of parametrized vunits in vmode default? 5. Section 2, "Verification units instantiation" Shouldn't we add here a note about cross-language semantics for instantiating/instantiated vunits written using different flavors, like you do for inheritance and binding? 6. Section 4, "Verification unit inheritance" If you agree to what I proposed about inheritance relationship between bound and unbound verification units, then in the restrictions the following restriction should be added: "an unbound verification unit can inherit only unbound verification unit" 7. Section 4, "Verification unit inheritance", example of valid use models: - Is it correct that for every use model a reverse version is also valid if the original one is valid and invalid if the original one is invalid, i.e. if in the example we replace X and Y the valid and invalid use models remain the same? If yes, we should mention it. - The last invalid example is no more invalid because the restriction on binding to modules was relaxed. 8. Section 9.3, "Direct and indirect name references", Restrictions: The first restriction is "A vunit may not be both inherited or instantiated in any given vunit" a. Why is this restriction appear in this section? b. This restrictions seems to be not exact since it can be understood from it that a vunit can be at the same time instantiated in one vunit and inherited in another one, which is not correct. I think it will be better to say: "A vunit can be either inherited or instantiated, but not both". c. Since only parameterized vunit can be instantiated (vunit with empty parameters list is still a parametrized one), and only non-parametrized vunit can be instantiated, do we need this restriction? Regards, Dmitry Dmitry Pidan Formal Verification Group IBM Haifa Research Lab. Lotus Notes: Dmitry Pidan/Haifa/IBM@IBMIL E-mail: pidan1@il.ibm.com Phone: 972-4-8296036 "N.S. Subramanian" <subns@cadence.co To m> <ieee-1850@server.eda.org> Sent by: cc owner-ieee-1850@s erver.eda.org Subject [$ieee-1850] Vunit_proposal_6.0.doc 23/04/08 17:03 <<Vunit_proposal_6.0.doc>> Hi SC, Please find attached version 6.0 of the vunit proposal. This revision addresses the following. a) Dmitry concerns on transitive closure of inherited vunits. b) Cindly's concerns on inheritance restrictions when binding of vunits to modules versus instances. c) Sitvanit's comments on pending items (mail dated 3/24) The following is not addressed in not addressed by this revision. a) Verification task - Cadence does not agree to Cindy's proposal here. A separate email will discuss that. b) abstract keyword - After Dmitry's email we feel that the abstract keyword is redundant. It does not break backward compatibility as the current LRM only mentions that tools are free to choose the binding of unbound vunits, not that they are bound to the top module of the design hierarchy. Please review and send your comments. We can discuss the same in the issues SC on 4/28. thanks and regards, nss -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. [attachment "Vunit_proposal_6.0.doc" deleted by Dmitry Pidan/Haifa/IBM] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun Apr 27 08:28:17 2008
This archive was generated by hypermail 2.1.8 : Sun Apr 27 2008 - 08:28:21 PDT