[sv-ac] New Proposal for 2089

Hi John,

Attached is a new proposal for 2089.  The changes are pretty simple:  A 
few added sentences in one paragraph.  We could try to voice-vote it 
tomorrow, although I haven't gotten confirmation from Gord that the 
added text satisfies his objections.

Tom

John Havlicek wrote:
> 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.