RE: [sv-ac] notes on 1648

Hello John et al,

please find attached a modified proposal based on John's
recommendations. Let me know if it is acceptable. I also uploaded that
to Mantis and deleted the old proposals.

Best regards,
ed 

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of John Havlicek
> Sent: Monday, June 11, 2007 1:55 PM
> To: sv-ac@eda-stds.org
> Subject: [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.
> 
> 

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