RE: [sv-ac] New Proposal for 2089

Tom-- I was re-reading the proposal, and this sentence might be worth
rewording:  "It will be executed once at the end of simulation for every
unique instantiation statement of that checker."  

Does the word 'statement' need to be there?  It sounds like that could
make it sound like we're talking about all the statements *within* the
checker.  I think "every unique instantiation of that checker" might be
clearer.
 

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Thomas Thatcher
Sent: Monday, February 25, 2008 5:59 PM
To: john.havlicek@freescale.com
Cc: sv-ac@server.eda.org
Subject: [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.


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