Yes, Tom said at the end of yesterday's mtg that there would be no 3/13 mtg. I think he just forgot to write it in the notes. -----Original Message----- From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Korchemny, Dmitry Sent: Wednesday, March 12, 2008 5:07 AM To: Thomas.Thatcher@sun.com; sv-ac@server.eda.org Subject: RE: [sv-ac] Notes from SV-AC meeting 3/10/2008 Hi all, As far as I understand there is no need to hold a meeting on 3/13/2008. Please, let me know ASAP if there are urgent issues to discuss. Otherwise I suggest meeting next time 3/17/2008. Thanks, Dmitry -----Original Message----- From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Thomas Thatcher Sent: Tuesday, March 11, 2008 8:34 PM To: sv-ac@server.eda.org Subject: [sv-ac] Notes from SV-AC meeting 3/10/2008 Notes from SV-AC meeting 3/10/2008 Agenda: ------ - Reminder of IEEE patent policy: 1769 Voice vote on friendly amendments. 2005 Voice vote to approve changes (SV-CC review) 2182 Voice vote to approve changes (SV-CC review) Discuss checker issues. Present: Tom, Erik, Doron, Ed, Lisa, John, Yaniv, Manisha - IEEE Patent policy. Reminder. - 1769 Passed the E-mail vote with 7 yes votes: There were friendly amendments. John says that the amendments have been compl Voice vote: Approved: 6 yes, 0 no , 0 abstain. - 2005 Minor changes based on SV-CC review, and on Shalom Questions about proper English usage: should be processes' (eriks original usage) or process' Shalom's suggestion Leave it to the editor to decide) Voice vote: Approved: 6 yes, 0 no, 0 abstain - 2182 Minor changes based on SV-CC review, Two changes: Technical problems with word document: Erik has fixed the document Manisha: In 36.75: Should "checker" be "checker instance" Erik: Need more feedback from CC on this Voice vote: Approved: 5 yes, 0 no , 0 abstain - 1900 Discussion of other groups' feedback/ issues w/ 1900 Ed: Even rules for nested module declarations not clear Things more complicated because of nested declarations. John: more comfortable w/ resolving names in declaration context. Consistent w/ properties & sequences. Manisha: How to $assert_off a checker in a loop John: It's one checker, so you can only turn all off or all on. Tom: What's the instance name of a checker in a procedure Does the procedure add to the instance name Doron: If you put an immediate assertion in a procedural block, even if labeled block, no addition to hierarchical instance name. Named block p. 558 of draft 4 John: We want names in checkers to sequences & properties We want name resolation in nested checker declarations should follow rules for nested modules unless a good reason not to We want references to checker instance follow rules for references to labeled items in procedural code. Should be consistent w/ modules - Thomas Thatcher wrote: > Hello Everyone, > > This is a reminder of the SV-AC regular meeting to be held tomorrow. > > > Dial-in Information: > > Tuesday, March 11, 2008, 09:00 AM US Pacific Time 916-356-2663 (U.S. > toll), 888-875-9370 (U.S. toll-free), Bridge: 4, > Passcode: 5983980 > > > Agenda: > ------ > > - Reminder of IEEE patent policy: > > > 1769 Voice vote on friendly amendments. > > Discuss checker issues. > > > Checker Issues: > =============== > > 1. Variable references in checkers. > > Is it legal to reference simple variables (or types) in a checker > that > may be defined externally. > > for example: > > int a > checker my_check (. . .); > checkvar c; > > always_check (. . .) > c <= a; > > endchecker > > NOTE: This is needed to be able to instantiate a covergroup. > Should obey same rules as anywhere else. > > [Korchemny, Dmitry] In 1900 it is written that the checkers should > resolve all the names in the declaration context (it was positively > requested by Gord, and I agree with it, otherwise checker > instantiation semantics becomes vague, and I doubt that it may be accepted). > > 2. Dotted names inside checkers > Are dotted name legal inside checkers? > Will they obey the same rules? > > [Korchemny, Dmitry] Yes, they are. They should be resolved in the > declaration context. > > 3. Dotted names into checkers. > May there be external references into checker internals using > dotted names? > > [Korchemny, Dmitry] Yes, they can. E.g., you can $assertoff an > assertion inside a checker (as you pointed it). The limitation is that > if the checker variable is referenced hierarchically, it cannot be > assigned to a regular variable (same as in assertion action blocks). > Hierarchical checker variable cannot be assigned, either. > > We had talked about using this as a work-around for no checker > outputs. It also may be required in order to set properties of > the covergroup. > It is also needed to enable/disable an assertion within a checker > > Should work the same as anywhere else. > > Will have extra rules for Single-Assignment-Rule for checker > variables. > [Korchemny, Dmitry] Why? I don't think so. > > For variables in final block: No special rules. > > > 4. Forces on checker variables > Forces: Should work the same as anywhere else. > Overrides SAR rule. > [Korchemny, Dmitry] I don't see how a checker variable may be forced. > The fact that the checker variables cannot be assigned a value outside > of the checker body should imply that they cannot be forced. > > 5. Mantis 2091 clarifies that concurrent assertions cannot appear in > fork- > join. Clarify this is the case for checkers too > [Proposal has been updated] > > [Korchemny, Dmitry] Agree. > > 6. Covergroups within checkers > 1. Only instantiations allowed within checkers. Definitions of > the > covergroup type must be defined externally. > 2. In checker, very limited capabilities. > 1. Can call new() in the declaration statement > 2. Can trigger the covergroup with clock event, or by assertion > action block, or sequence match item. > Not allowed to call sample() from always_check or > initial_check > > 3. Manipulating static properties must be done externally. > But this is easier now, because the covergroup definition is > external. > 4. could initial_check allow assignments to covergroup statics? > > [Korchemny, Dmitry] I should think more about it. > > 7. Checkers within interfaces > > From Gord: > Normally, one can have: > module m (some_interface i); > typedef i.T my_local_type; > my_local_type m = new; // assuming i.T is a class > endmodule > > Could we do something similar with checkers? > Our answer is probably no. We did not envision this kind of thing > > [Korchemny, Dmitry] I answered Gord that 1900 does not allow it (even > syntactically). Maybe this limitation can be lifted in the future, but > I would certainly not allowed it now. > > 8. Naming of checker instantiations. > > What are naming conventions for instances in procedural code? > > [Korchemny, Dmitry] What is a difference in this case between checkers > and other instances? > > 9. Checkers and Bind > > Is binding allowed? > Yes, we definitly intend that bind can be used to instantiate > checkers. > > [Korchemny, Dmitry] This is reflected in the proposal. > > 10. Assertions within checkers. > > Clarify that assertions within checkers are not a NEW kind of > assertion. > Concurrent assertions used inside checker > Immediate assertions used within final procedure > (Not sure if deferred assertions allowed within final procedure) > > What was it that gave people the impression that assertions within > checkers were different? > > [Korchemny, Dmitry] The question about assertions seems strange to me. > > 11. Checkers with untyped formals > > This creates new situations as to when certain information is > available > What are the issues with this? > > [Korchemny, Dmitry] If the names are resolved in a checker declaration > context, and hierarchical reference to objects in checkers are not > allowed in the actual arguments of the checkers (need to be added), I > don't know any other outstanding issues. > > 12. Coverage on a freevar > > Is this unreliable? > Need to clarify. In simulation context, this is simply a random > variable. > > [Korchemny, Dmitry] It may be allowed, but I don't see much sense in > using it. > > 13. New keywords that could clash with existing variable names > > Which ones will be a problem? > [Korchemny, Dmitry] The people are talking about next. We may replace > it with future (other suggestions?) > > 14. Inferred value functions: $inferred_clk, $inferred_enable, etc > 1. What does it produce in a type sense > 2. Can it be used with untyped formal > 3. What if in a loop? > 4. Could the enable be an automatic? > [Korchemny, Dmitry] See my recent answer to Gord. > > 14. Other issues within the following proposals > 1900 1549 1681 1648 1728 1682 2088 2089 > > > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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 Wed Mar 12 07:28:23 2008
This archive was generated by hypermail 2.1.8 : Wed Mar 12 2008 - 07:28:47 PDT