[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.