[sv-ac] notes on 1648

Hi Folks:

I was looking over the proposal for 1648 prior to 
calling for a vote.

I noticed some things that I think should be addressed
before we vote.

Please see the notes below.

J.H.


JH Notes on 1648:  2007-06-11
-----------------------------

. The section numbering needs to be updated to align with Draft3.  
  - References to Clause 17 should be to Clause 16.
  - The proposal needs to say precisely where in Clause 16 to insert
    this text.  In 1800-2005, Subclause 17.14 was "Clock resolution",
    so it seems that this proposal should say that the new subclause should
    be 16.15 and shift the others down.
  - References to Subclause 15.11 should be to Subclause 14.12.  Please check 
    other references to 1800-2005 Clause 15 (e.g., "Syntax 15-3") and update.

. I think we can do a better job with the following language:

     Only one default disable may be specified anywhere in a module,
     interface, or program. Specifying a default disable more than once in
     the same module, interface, or program shall result in a compilation
     error.
     
     A default disable is valid only within the scope containing the
     default disable specification. This scope includes the module,
     interface or program that contains the declaration as well as any
     nested modules or interfaces. It does not include instantiated modules
     or interfaces. Furthermore, modules, interfaces or programs that are
     declared within the scope where a default disable is specified may
     redefine the default disable expression.

  The problems I perceive are with apparent conflicts, e.g. between saying
  that "only one default disable may be specified anywhere in a module" and
  saying that "modules, interfaces or programs that are declared within 
  the scope where a default disable is specified may redefine the default
  disable expression."

     A default disable may be declared as an item within a module,
     interface, or program.  The scope of the default disable does not
     depend on the position of the declaration item with the module,
     interface, or program.  Declaring more than one default disable
     item within the same module, interface, or program shall result
     in a compilation error.

     A default disable is valid only within its scope.  The scope of a
     default disable includes the module, interface, or program in
     which it is declared as an item.  The scope also includes any
     nested module, interface, or program declaration.  The scope does 
     not include instantiated modules or interfaces.  

     If a nested module, interface, or program declaration itself has
     a default disable declaration, then that default disable applies
     within the nested declration and overrides any default disable
     from without.

. Under "The following rules apply for the disable condition resolution:", 
  change

     this is equivalent to the inference of a 1'b0 reset value

  to

     this is equivalent to the inference of a 1'b0 disable condition

  Rationale:  We are describing rules for resolving the "disable condition",
  not the "reset value".

. I recommend changing

     In assertion a8 the inferred enabling condition is from the else
     clause of the if-else statement and thus it has to respects the
     interpretation of a four-valued expression in the if condition. One of
     such forms is as indicated in a8, however other forms may be used. For
     example, ((rst != 'b0) !== 1'b1). 

  to 

     In assertion a8 the inferred enabling condition is from the else
     clause of the if-else statement, and thus it has to represent the
     complementary interpretation of the four-valued expression in the
     if condition.  One such form is as indicated in a8.  Other
     equivalent forms may be used, such as ((rst != 'b0) !== 1'b1).

  Rationale:  English grammar and minor improvements in clarity.

. I am not happy with the following:

     For synthesizable forms of the enabling condition where only
     two-valued interpretation of signals is used, the enabling
     condition for the assertion can be !rst.

  This seems to be introducing into the LRM the notion of a standard
  synthesizable form of an inferred enabling condition.  If this is 
  the goal, then I think it needs to be described more generally along 
  with inference of enabling conditions.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.