Re: [sv-ac] 805 in draft3 review

Hi Stu:

I have attached the result of our Draft 3 review efforts.

There are instructions for fixing the two issues found
by Bassam with the 0805 implementation.

There were also a number of formatting issues found in 
Clause 16.

And there were two incorrect cross references in Annex F.
The first of these was a correct merge of what was in
1800-2005, but the reference makes no sense.  If you want 
us to make a mantis item for this, we can.  The second is
an index-off-by-one mistake that I think is due to the merge.

Best regards,

John H.

> X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda.org using -f
> Reply-To: <stuart@sutherland-hdl.com>
> From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
> Cc: "'Karen Pieper'" <Karen.Pieper@synopsys.com>
> Date: Tue, 29 May 2007 09:10:55 -0700
> Organization: Sutherland HDL, Inc.
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
> Thread-Index: AcehYXsh1BNMCmExSkO/3muSILGSbQAo5I4AAAF+kCA=
> X-Declude-RefID: 
> X-eda.org-MailScanner: Found to be clean, Found to be clean
> X-Spam-Status: No, No
> Sender: owner-sv-ac@eda.org
> X-eda.org-MailScanner-Information: Please contact the ISP for more information
> X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org
> X-OriginalArrivalTime: 29 May 2007 16:12:10.0730 (UTC) FILETIME=[1CA60CA0:01C7A20C]
> 
> AC committee,
> 
> I am preparing a draft 3a today, which is the draft that the IEEE will make
> available for sale.  If these two issues pointed out by Bassam are problems
> with how I implemented a Mantis item, I can correct them in draft 3a.  That
> will allow closing out the Mantis item (assuming I get it right in draft 3a.
> 
> If you want me to make these corrections, please send me explicit directions
> on what to change by the end of today.
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> Sutherland HDL, Inc.
> stuart@sutherland-hdl.com
> 503-692-0898
>  

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


- [Mantis 0805] F.3.3.1, p. 1029.  Change

    T is said to be disabled on w if w |=^{^d} T.

  to

    T is said to be disabled on w if w |=^d T.

  NOTE:  The problem is simply that the symbol "^" should not be part of 
  superscript that follows the symbol "|=".  The plain text shorthand
  is motivated from LaTeX, in which "^" is used as a formatting specifier
  to indicate superscript.

- [Mantis 0805] F.3.3.1, p. 1029.  Move the text 

     T is said to pass on w if w |= T. T is said to be disabled on w
     if w |=^d T. T is said to fail on w if T neither passes nor is
     disabled on w. It can be proved that T cannot both pass and be
     disabled on w.

  down so that it appears just before 

     Neutral satisfaction of properties is defined as follows:

  [Note that the text currently appears before a similar phrase that
  includes "top-level", but this is the wrong place.]

- [Clause 16] Tom Thatcher noted a number of indentation problems:

  1.  p. 342, subclause 16.9:  In item D, there is a paragraph with changed
      formatting.  The second through last lines of the paragraph were
      significantly indented from the first line.  It looks like this:
  
  	Paragraph text paragraph text paragraph text paragraph text paragraph
  			text paragraph text paragraph text.
  
  2.  p. 346, subclause 16.12:  Paragraphs in items B, C, D, E have the same
      formatting problems, as described above.
  3.  p 353,  subclause 16.12.4:  Paragraphs in Restrictions 1, 2, & 3 have the
      same formatting problems.
  4.  p 355		Another paragraph with same formatting problems.
  5.  p 377, subclause 16.15.1:   Same paragraph formatting problem in item a.
  
  It appears that one paragraph style has changed, and it is causing all these
  formatting differences.

- [Annex F] F.1, item c) 4), p. 1024.  The reference to 6.11.1 does
  not make sense.  This is a correct translation of the corresponding
  reference in 1800-2005, but 6.11.1 concerns integral types.  Here is
  the context from F.1:

    The abstract syntax does not allow explicit procedural enabling
    conditions for assertions. Procedural enabling conditions are
    utilized in the semantics definition (see 6.11.1), but the method
    for extracting such conditions is not defined in this annex.

  The reference should illustrate the use of the procedural enabling 
  condition in the semantics definition, and this is in F.3.3.1
  (neutral satisfaction), so the reference to 6.11.1 should be changed 
  to F.3.3.1.

- [Annex F] F.5, there is an incorrect cross reference.  CHANGE

    Below are precise versions of the four restrictions given in
    16.12.3 and the precise definition of recursive property.

  to

    Below are precise versions of the four restrictions given in
    16.12.4 and the precise definition of recursive property.