RE: [sv-ac] ballot result for 2089

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Thomas Thatcher
Sent: Wednesday, January 23, 2008 8:55 PM
To: sv-ac@server.eda.org
Subject: Re: [sv-ac] ballot result for 2089

Hello Everyone,

I have made a few changes to 2089.

1.  I have re-phrased the following sentence as follows:

     Checker action blocks or final procedures shall not write into free
     variables, but each of these constructs may contain any other code
     which is normally allowed when that construct appears in a module"

Hopefully that solves the clarity problem.

[Korchemny, Dmitry] Yes, this explanation is clear.

2.  I agree that assigning values to a checker formal arguments from 
final procedures serves no purpose.  I put that in just to show that 
there was nothing special about final blocks when they appeared in 
checkers.  However, explicitly permitting something may give the 
impression that it might be useful for something.  I can take out the 
mention of final procedures from that sentence.  What do people think?

[Korchemny, Dmitry] I think it should be unambiguously stated what is legal and what is not. Either decision will do as long as it is clearly stated. In case of the doubt, it is always better to prohibit a construct than to allow it in order to be backward compatible in the future.

3.  The distintion of "checker body", where checker body does not 
include the internals of final procedures, came out of Dmitry's no vote 
in the last round. In 1900, there was already the distinction that 
checker action blocks were not included in the checker body.  He wanted 
to clarify that the final procedure code was also not part of the 
checker body.  In the "checker body"  only checkvar definitions are 
allowed. Also, checkvar definitions are ONLY allowed in a checker body.

One thing that even I thought would be confusing was that the code of 
initial_check and always_check procedures was considered "part of the 
checker body", while the final procedure code was considered not part of 
the checker body.

One possibility is to talk only about what may appear inside a checker, 
then explicitly talk about what may appear inside an always_check, 
initial_check, final, checker action block, etc.

[Korchemny, Dmitry] Yes, this is the only alternative to the term "checker body" I see.

  NOrmally, when I see 
the sentence "a checker may contain the following elements", I don't 
assume that the sentence is including the internals of constructs that 
appear in that scope.

Dmitry, was it your understanding that always_check procedures could 
contain let declarations, checkvar declarations, default clocking and 
disable declarations and other always_check or initial_check procedures?

[Korchemny, Dmitry] This follows the regular rules: e.g., checker variable declarations cannot appear directly in an always_check exactly as regular variables cannot appear directly in an always procedure. But they can appear in a begin...end block within the always_check. I.e., every construct may appear only where it is allowed by the language grammar.

Tom

John Havlicek wrote:
> Hi Folks:
> 
> Our ballot on 2089 failed due to negative votes.
> 
> See the results below.
> 
> J.H.
> 
> ----------------------------------------------------------------------------------
> Ballot on Mantis 2089
> 
> - Called on 2008-01-15, final ballots due by 2008-01-21 T 23:59-08:00.
> 
> yv[xxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
>  v[xxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)     
>  n[----------------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
> nv[xxxxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
>  t[xxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
> yv[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair)
> nv[xxxxx-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[xxxxxxxxxxxxxxxxxxx..............................] Johan Martensson (Jasper)
>  n[---------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
> nv[xxxxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
> yv[xxxxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
>  n[-------x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
> yv[xxxxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
> yv[xxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun Microsystems)
>    |------------------------------------------------- attendance on 2008-01-15
>  |--------------------------------------------------- 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
> 
> [MK]
> 
> 1. I think the following statement (page 2) should be re-phrased.I
> assume the intention is to say that that checker action blocks may
> contain any code which is normally allowed in action blocks and final
> blocks may contain any code which is normally allowed in final blocks.
> By combining the two together, it gives the impression that final blocks
> may contain the code which is normally allowed in action blocks or final
> procedures. Which is incorrect.=20
> 
> "Checker action blocks or final procedures shall not write into free
> variables, but they may contain any other code which is normally allowed
> in action blocks or final procedures in modules."
> 
> 2. I do not understand allowing assignments to formal arguments in final
> blocks in a checker. Since these final blocks run at the end and their
> order is non-deterministic, what will be the use of this ? Since the
> formal may be a checker variable of an upper level checker, the
> following contradicts with a statement in 16.18.4 where it says that
> writing to a checker variable is not allowed in final procedure:
> "However declarations of other variable types, which are not allowed
> within a checker body are allowed, and code within a final procedure is
> allowed to read from (but not write to) checker variables declared in
> the checker body which contains the procedure."
> 
> "Checkers may assign values to their formal arguments, treating them as
> output arguments, though no explicit
> notation of this is required in the checker declaration statement. Each
> formal argument used in this way may
> be assigned a value either in a checker body, or in checker action
> blocks, or in a final procedure. If a formal
> argument is written in the checker body, its corresponding actual
> argument shall be a checker variable or a
> formal argument in another checker. If a formal argument is assigned a
> value in a checker, it shall be
> untyped. The output actual argument shall have a static lifetime."
> 
> [MK]
> 
> Please ignore my comment about contradiction in (2) as I did not
> understand that part properly.
> 
> [YF]
> 
> in page 2 it is said:
> 
> 
> 
> 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 procedure code, will be referred to as checker body
> 
>  
> 
> but the following page has this section:
> 
> A checker body may contain the following elements:
> 
> ... 
> 
> ï'¾ initial_check, and always_check, and final procedures
> 
> Also page 3 (16.18.4 Checker procedures) says:
> 
> The following procedures are allowed inside a checker body:
> 
> ï'¾ initial_check procedure, and
> 
> ï'¾ always_check procedure
> 
> ï'¾ final procedure
> 
>  
> I think this is contradictory (or at least I don't understand it) , what is the reason for the exception mentioned in page 2 ? if there isn't any I think it should simply be removed.
> 
> [LP]
> 
> 1. I find it confusing that a "final procedure" is in a checker body but
> is not part of the checker body. I'm not sure why this distinction is
> needed. It adds unnecessary confusion.
> 
> =20
> 
> 2.   "Checker action blocks or final procedures shall not write into
> free variables, but they may contain any other
> 
> code which is normally allowed in action blocks or final procedures in
> modules."
> 
> =20
> 
> I am wondering if it would be better to say the following so that there
> is no question whether things like action block controls apply:
> 
> =20
> 
> Checker action blocks are almost the same as non-checker action blocks.
> They may contain any code that is allowed in an action block outside of
> a checker, have the same default characteristics, and are impacted by
> the same action block controls.  An additional restriction is that a
> checker action block shall not write into free variables.  Similarly, a
> final procedure in a checker follows all the same rules and regulations
> as a final procedure in a module, with the additional restriction that
> it shall not write info free variables.=20
> 
> ----------------------------------------------------------------------------------
> Friendly Amendments
> 
> [ES]
> 
> Minor friendly amendment near end of 16.18.4:  "However declarations of
> other variable types, which are not allowed within a
> checker body are allowed, ..." =3D=3D>
> "However declarations of other variable types, which are not allowed
> within a
> checker body, are allowed, ..." =3D=3D>
> 
> [DK]
> 
> Top of page 5: "end" should be in bold.
> 

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