[sv-ac] Agenda for SV-AC meeting 3/10/2008

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.