[sv-ec] Review of 2038/1900

2038 (concurrent assertion scheduling, etc) looks pretty good to
me.  I have no current issues with it.

For 1900, I have no substantive issues other than the valid uses of
const actuals that I raised separately.  I do have a bunch of
more minor notes, wording issues, etc. as follows.

1.  17.1 paragraph 2 -- "is limited by nonblocking".  I think "by"
     should be "to"

2.  Numerous occurrences of lists where we have text such as:
         .... of the following:
         item
         item
     For clarity, the items should be numbered or bulleted and
     preferably indented.

3.  17.2 doesn't include "covergroups".  We must make sure the end
     result of 1900 and 2088 is consistent.

4.  End of 17.2 -- "Variables used in a checker...."  should be
     "Variables referenced in a checker...."

5.  General concern -- the terminology of "passing" something to
     a checker is a bit troublesome to me as that implies something
     closer to an "assignment" style of association like a function
     or task.  I'd rather see "associating" or similar used instead.
     For example, "actual arguments are passed to the checker" might
     be "actual arguments are associated with the checker".  I'm not
     entirely sure about "associate" but I don't like "passing".

6.  Related to (5), towards the end of 17.3, there is the following:
       "...to be connected to their actual arguments, as in a module
        instantiation."
     I don't think that is really what we want to say.  Although I've
     used "module like" to describe the continuous behavior or the
     relationship, using that here could be read to imply things about
     implicit continuous assignments, conversions, modes, etc. that
     aren't really relevant.  The point here is the relationship or
     "association" to the child formal is direct.

7.  In 17.3.2, after the example, the "d[3]" is not in the correct font.

8.  In 17.5, we should add an example of an always in an "unreachable"
     checker instance to note that it is still live.  For example:
        checker c ....
           always ....
        endchecker
        ...
        initial begin
           if (0) c my_c();
        end

9.  In 17.5, we might want to note that the values of the checker variables
     and the preponed values of the sample vars may be out of sync since
     there is no guarantee that final blocks are evaluated after having
     gone through observed.  So assertion consistency is not quite the same.

10. In 17.6, there is the sentence:
        A free variable may assume any value at every point in time, similarly
        to an input of the design.
     While this may be how formal tools interpret an input to the design,
     all inputs have well defined non-random simulation semantics.  I'd
     like to strike the sentence entirely.

11. In 17.6, for at least one of the examples (preferably the first) where
     the comment is made "these two checkers are not equivalent in
     simulation", we should explain *why* they are not equivalent.

12. Towards the end of 17.6, we have:
        However at a given time step all occurrences of a non-constant checker
        variable have the same value,
     I think the intent here (at least by the example) is:
        However at a given time step a non-constant checker
        variable has only one value; all uses of the checker
        variable are equivalent.
     Even that is not really true -- if we go through obvserved more than
     once (the "big loop" cycle), we could end up having distinct solutions
     withing "a given time step".

     I'm not sure why we need this sentence and the example.  Is there any
     question about whether a checker variable could represent more than
     one instantaneous value in simulation?  If not, this whole thing
     could likely be struck which would remove potential confusion here.

13. In 17.6.1 we should explicitly note that assignments to const checker
     variables are illegal.  That is obvious I think but should still be
     stated.

14. In the SAR definition, we have "it shall be illegal to use ...".  I
     think "use" should be "assign to".

15. I'm not entire clear as to what constitutes "the next clock event of
     the assume set".  Is that just "the next event on any clock of the
     assume set"?

16. In 17.6.2, the text:
        Free checker variables are active or inactive at a packed granularity...
     should probably use the term "singular" instead.  So something like:
        Free checker variables are active or inactive for each singular
        element of the variable ...

17. In 17.6.2, the assume set description says:
        ...as well as those assume properties of child checker instances that
        involve active free checker variables passed as actuals to the child.
     I think the "involve" is meant to cover the situation in which an
     actual is something like (a+b) where "a" is active and
     "b" is not.  If that is the case, we might want an example of that.

18. I think that we should try to be a bit more clear in that if an
     assumption constraint set cannot be solved, that is not sufficient
     cause for an error.  A randomizer could just "guess", and if the guess
     satisfies the assumptions, that is fine.  It is only the firing of
     an assumption that indicates real failure, not the lack of the
     randomizer being able to incorporate all the constraints.  So, as an
     example, if a randomizer simply discarded constraints that were
     "too hard", it underconstrains the solution with is "an error" but
     it could get lucky with its particular choice.  That should be fine
     unless one of the assumptions actually fails in which case the
     tool might have to explain why it couldn't find a satisfying solution.

19. In 17.6.3, the sentence:
        The Re-NBA region is processed after the Reactive and Re-Inactive
        regions have been emptied of events.
     is really not necessary; I'd rather see a general reference back to
     the scheduling cycle.

20. In 17.7, we cloned the existing poor wording from 16.6 for functions.
     In particular, I don't like the phrasing that "Functions *should be*
     automatic ..."  Rather than modify 16.6 as well, I'd be happier to see
     just the appeal to 16.6 without cloning the wording.


Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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