RE: [sv-ac] ballot result on 2089

Hi Tom,

This version is OK with me.

One minor comment: at the bottom of page 1, delete a space between "code" and the comma: "final procedure, encapsulating immediate assertions, display statements, or other procedural code ," -> "final procedure, encapsulating immediate assertions, display statements, or other procedural code,"

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Thomas Thatcher
Sent: Friday, January 11, 2008 2:14 AM
To: Korchemny, Dmitry
Cc: john.havlicek@freescale.com; sv-ac@server.eda.org
Subject: Re: [sv-ac] ballot result on 2089

Hi Dmitry,

I have uploaded a new proposal to address your comments.
It is named 2089_finalInChecker_20080110.pdf.

See my comments below:

Tom

Korchemny, Dmitry wrote:
> Hi Tom,
> 
>  
> 
> Please, see my comments below.
> 
>  
> 
> Thanks,
> 
> Dmitry
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Thomas.Thatcher@Sun.COM [mailto:Thomas.Thatcher@Sun.COM]
> *Sent:* Tuesday, January 08, 2008 11:20 PM
> *To:* john.havlicek@freescale.com
> *Cc:* sv-ac@eda.org; Korchemny, Dmitry
> *Subject:* Re: [sv-ac] ballot result on 2089
> 
>  
> 
> Hi Dmitry,
> 
> I have made the following changes to 2089 in response to the feedback:
> 
> 1.  I have made the following change to the definition of /checker body/:
> 
> Action blocks of assertions within a checker will be referred to as 
> /checker action blocks/, and the rest of the checker, with the exception 
> of any final block code, will be referred to as /checker body/.
> 
> [Korchemny, Dmitry] 1. “final procedure” should be used instead of 
> “final block”. “final block” is also mentioned at the bottom of page 3.
> 
Done.
>  
> 
> 2. It is written in the checker proposal (page 9):
> 
> “A checker body may contain the following elements:
> 
> ¾      Declaration of *let*, sequences, properties and functions.
> 
> ¾      Concurrent assertions.
> 
> ¾      Checker variables and their assignments (see 16.18.5).
> 
> ¾      Default clocking and disable declarations.
> 
> ¾      *initial_check* and *always_check* procedures (see 16.18.4).
> 
> ¾      Generate blocks, containing any of the above elements.”
> 
>  
> 
> and there is no mention of final procedures here.
> 
I did have a change for this section in the proposal:  See page 3.
(I just saw a spacing problem here:  I'll fix it the next time around)
>  
> 
> 3. It is written in the checker proposal (page 9):
> 
> “Each formal argument used in this way may be assigned a value either in 
> a checker body or in checker action blocks.” This sentence needs to be 
> modified to allow assigning the output argument value in final 
> procedures as well.
> 
Fixed:  p 3 of the proposal.
>  
> 
> 2.  To clarify that variable declaration that appear within a final 
> block are local to the final block, I have added the following:
> 
> Any variables defined within *final* procedures obey all the normal 
> scope rules (see 22.8).
> 
>  
> 
> [Korchemny, Dmitry] Usually the common rules are not repeated for 
> special cases in the LRM. I would modify an example on page 13 from the 
> checker proposal to:
> 
I modified the paragraph.  Also, I added to the example on page 13 of 
the checker proposal.
>  
> 
> checker c;
> 
>             // Illegal: non-checker variables shall not be declared in a 
> checker body
> 
>             bit a;
> 
>             …
> 
>             final begin
> 
>                         checkvar bit b1; // Illegal: checker variable 
> not in a checker body
> 
>                         bit b2;   // OK
> 
>                         …
> 
>             end
> 
> endchecker : c
> 
> 
> 3.  I think I have fixed some of the font problems, but other instances 
> may still be lurking.  I have attached both the Word document and the PDF.
> 
> [Korchemny, Dmitry] PDF looks fine now.
> 
> 
> Is this sufficient?
> 
>  
> 
> [Korchemny, Dmitry] It is written in the 2089 proposal (page 1): “- 
> final procedure, encapsulating immediate assertions or display 
> statements, for reporting status at the end of simulation.”, but the 
> final procedures in checkers may contain any stuff that the final 
> procedures in modules can, and not only immediate assertions and display 
> statements. This is only a suggested usage.
> 
I added some more inclusive language here.

>  
> Tom
> 
> John Havlicek wrote:
> 
> Hi Folks:
> 
>  
> 
> Our ballot on 2089 failed due to negative vote.
> 
>  
> 
> See the results below.
> 
>  
> 
> J.H.
> 
>  
> 
> ----------------------------------------------------------------------------------
> 
> Ballot on Mantis 2089
> 
>  
> 
> - Called on 2007-12-20, final ballots due by 2007-12-30 T 23:59-08:00.
> 
>  
> 
> yv[xxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
> 
> yv[xxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)     
> 
>  n[--------------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
> 
> yv[xxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
> 
>  t[xx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
> 
> nv[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair)
> 
>  v[xxx-xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha (Mentor Graphics)
> 
>  n[----------------------------xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
> 
>  n[-------x------------x--xxx.....................] Joseph Lu (Altera)
> 
>  v[xxxxxxxxxxxxxxxxx..............................] Johan Martensson (Jasper)
> 
>  n[-------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
> 
>  v[xxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
> 
> yv[xxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
> 
>  n[-----x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
> 
> yv[xxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
> 
> yv[xxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun Microsystems)
> 
>    |----------------------------------------------- attendance on 2007-12-18
> 
>  |------------------------------------------------- voting eligibility for this ballot
> 
> |-------------------------------------------------- email ballots 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
> 
>  
> 
>  
> 
> ----------------------------------------------------------------------------------
> 
> Rationale for Negative Vote
> 
>  
> 
> [DK]
> 
>  
> 
> * A refinement of "checker body" is needed. Currently "checker body" is
> 
> defined as everything in the checker except of assertion action blocks.
> 
> Apparently, final procedure imposes different limitations than other
> 
> stuff from "checker body" does. This also includes the argument passing:
> 
> if a formal argument is used in a final procedure, a corresponding
> 
> actual argument cannot depend on checker variables, etc.=20
> 
> * Do you want to make a declaration of regular variables legal in
> 
> checkers since they may be used in final procedures, or shall they
> 
> remain illegal, and the variables used in final procedures should be
> 
> declared there locally (I prefer the latter option)? This needs to be
> 
> explicitly mentioned.
> 
> * Friendly amendment: The new text should be in Times New Roman, and not
> 
> in Arial (page 3).
> 
>  
> 
> ----------------------------------------------------------------------------------
> 
> Friendly Amendments
> 
>  
> 
> [BT]
> 
>  
> 
> - Add pointer to 2182 for VPI
> 
> - Remove mention of VPI "may need change" -- "final" is covered in
> 
> "process"
> 
>  
> 
>   
> 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

-- 
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.