[sv-ac] ballot result on 1900 -- revised

Hi Folks:

1900 passed with exactly 50% of eligible votes.  There was a friendly
amendment.

In my previous message, I neglected to add comments from Lisa and Shalom.

See below.

J.H.

----------------------------------------------------------------------------------
Ballot on Mantis 1900

- Called on 2008-02-21, final ballots due by 2008-02-24 T 23:59-08:00.
- Please ensure that John Havlicek receives your ballot.

yv[x-xxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
yv[xxxxxxxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)     
 n[---------------------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
 v[xxx-xxxxxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
 t[xxxxxxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
yv[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair)
 v[-xxxxxxxxx-xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha (Mentor Graphics)
 n[--x-x-------------------------------------------------] Ah-Lam Lee (Qualcomm)
 n[-----------------------------------xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
 n[--------------x------------x--xxx.....................] Joseph Lu (Altera)
 v[x-x--xxxxxxxxxxxxxxxxxxx..............................] Johan Martensson (Jasper)
 n[--------------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
 v[xxxxxxxxxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
 v[-xxxxxxxxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
 n[------------x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
yv[-xxx-xxxxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
yv[xxxxxxxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun Microsystems)
   |------------------------------------------------------ attendance on 2008-02-19
 |-------------------------------------------------------- voting eligibility for this ballot
|--------------------------------------------------------- e-mail votes received

        Legend:
                x = attended
                - = missed
                r = represented
                . = not yet a member
                v = valid voter (2 out of last 3 or 3/4 overall)
                n = not a valid voter
                t = chair eligible to vote only to make or break a tie


----------------------------------------------------------------------------------
Friendly Amendments:

[TT]

In the section which talks about where a checker may be instantiated,
There should be a sentence that says that the same placement 
restrictions for concurrent assertions also apply to checkers.  And put 
a reference to 16.4.


----------------------------------------------------------------------------------
Comments:

[LP]

1)	page 26 in the last example, s.triggered should be s1.triggered
2)	page 36 and page 40 - module common item: A.6.2 page 43 now
includes always_check  in always_construct and initial_check in
initial_construct, though these are not allowed in a module.  I think
you need to list them separately now.
3)	22.10 bind:  I noticed that you are not allowing checkers to be
bound to program blocks.  It is not clear if this was intentional.
Program blocks don't allow instances of anything, except checkers.
Also, I think you have changed the meaning of the sentence on page 5 in
the second part of 3.9.  It would be better to state:  "Programs,
primitives, and checkers cannot instantiate other building blocks, with
the exception of checkers; they are leaves in a hierarchy tree."
4)	Page 42: I don't think that the definition of
"concurrent_assertion_item" should include checker instantiation.
Concurrent assertions may be in a checker, but the checker itself is not
a concurrent assertion item.  Note that in module_common_item for
example, checker_instatiation and concurrent_assertion_item are both
listed. I think there would be other changes needed if a
checker_instantiation was a concurrent assertion item. (like the
overview of concurrent assertions for one)
5)	On page 23, you state: "Simulators shall assign arbitrary values
to the free checker variables provided that these values are consistent
with the free checker variable assignments; they also may use the
assumptions to constrain these values if they have the capability to do
so."  I don't understand what is meant by "assignments".  Do you mean it
needs to be consistent with the "type" of the checker variable. For
example it should assign a 1 or 0 to a "checkvar bit x" versus assigning
a "x" or "z"?
6)	Also on page 23, "It is safer to use restricted checker
variables when the determinism is required since they enforce a check
for the determinism."  What does that mean - they enforce a check?
7)	On page 32, the section number references are incorrect, for
example there is no section 16.8.5.1.
8)	I feel very uncomfortable saying that "continuous check bits are
never sampled either in assignments or in concurrent assertions."   I
don't like that within an assertion, some variables are sampled and some
are not.  Even if you contend that checkers will be libraries, the user
is still going to have to debug issues, and having to know how the var
was assigned to know how to interpret the results is not desirable.=20=20

[SB]

The footnotes on initial_keyword and always_keyword are placed
differently in A.6.2 from in 9.2 and in 16.18.2.=20
=20
But if initial_check and always_check appear in
checker_or_generate_item, they may not be needed in initial_keyword and
always_keyword.

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