[sv-ac] comments on 1361

From: John Havlicek <john.havlicek_at_.....>
Date: Mon Jul 23 2007 - 18:32:23 PDT
Hi All:

I have gone fairly carefully through the latest proposal for 1361,
and I think it is nearly ready for vote.  I have some comments below
that I would like to see addressed first.

Best regards,

John H.

Notes on 1361, 2007-07-23
-------------------------

- Throughout, check the indexing into Clause 19.  In Draft 3a,
  "Assertion control" is in 19.10, so the following subclause would
  be 19.11 rather than 19.12.  I'm not 100% sure where it is intended
  for the new subclause to go, but it seems to me that the right place
  is after the subclause on "Assertion control".  

  Maybe it is better to make a note to the editor at the beginning to
  explain where the new subclause is supposed to appear and make up a
  symbol to represent its subclause number.  Then that symbol could be
  used in the various change instructions, and the editor will know to
  adjust the symbol to the correct subclause number.

- There are two places in 16.14.3 that talk about executing
  statement_or_null, one for property coverage and one for sequence
  coverage.  I think the current proposal should show a change for
  each.  Also, 1768 will change this text.  It will be good to show
  how the 1361 changes will look if 1768 is passed.  I think this will
  help us quickly approve both 1361 and 1768 together.

- Change to Clause 19.1:  "Assertion control (19.12)" --> 
  "Assertion action control (19.11)".  Possibly, use the symbol suggested
  above to refer to the subclause number of the the new subclause.

- Text for subclause on "Assertion action control", change 
  
     control execution of assertion action block for concurrent assertions
  
  to 

     control execution of assertion action blocks for concurrent assertions

- The new subclause on "Assertion action control" in Clause 19 is not
  consistent with the use of phrases like "pass/fail statement" and
  "pass/fail action".  In Clause 16, the phrases "pass/fail statement"
  and "action block" are used.  However, I can see that, as a whole,
  this proposal prefers "pass/fail action", so I am simply asking to
  make the phrasing consistent.

  Also, I think the definite article "the" should be used when talking 
  about execution of "pass/fail action".  

  Taking into account both of these changes, I suggest 

     execution of pass action --> execution of the pass action

     execution of the pass statement --> execution of the pass action

  and similarly in a number of places.     

- I think that the language describing $assertpassoff is a little
  confusing because it seems to suggest that only a subsequent
  $assertpasson can re-enable the pass statement.  Of course, the
  intention is that a subsequent $assertpasson will re-enable the pass
  statement for both vacuous and nonvacuous successes, while a
  subsequent $assertnonvacuouson will enable the pass statement for
  only the non-vacuous successes.

  I would like to see a clearer description.  One possiblity is to
  change the first sentence for $assertpssoff to something like the
  following:

     $assertpassoff shall stop execution of the pass statement for both
     vacuous and nonvacuous success of all the specified assertions.  
     Executaion of the pass statement for both vacuous and nonvacuous successes
     can be re-enabled subsequently by $assertpasson, while execution of the 
     pass statement only for nonvacuous successes can be enabled subsequently
     by $assertvacuouson.

- We need to find the reference to $dumpvars in the integrated Draft 3a and 
  put it in place of 

    Please refer to IEEE P1364 ...

- For clarity, change

     These system tasks shall not affect the execution of pass or fail actions
     until the task is executed

  to

     These system tasks shall not affect the execution of pass or fail actions
     until the system task is executed

- Under vpiAssertionDisablePassAction usage example, add spaces:

     assertion.This  -->  assertion.  This


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Jul 23 18:32:45 2007

This archive was generated by hypermail 2.1.8 : Mon Jul 23 2007 - 18:32:58 PDT