RE: [sv-ac] call to vote on 2089

I agree!  I still think that the checker body should be the entire
contents, including the final block, and the text should be worded with
exceptions.

 

Lisa

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Fais
Yaniv
Sent: Monday, January 21, 2008 5:01 AM
To: Korchemny, Dmitry; john.havlicek@freescale.com; sv-ac@eda.org
Subject: RE: [sv-ac] call to vote on 2089

 

Thanks,

I understand why this exception on checker body is required and final
procedure not being part of checker body.

 

 

How about not using "checker body" in those problematic paragraphs I've
mentioned, for example:

The following elements may be defined inside a checker (except inside
checker action blocks):

* Declaration of let, sequences, properties and functions.

* Concurrent assertions.

* Free variables and their assignments (see 16.18.5).

* Default clocking and disable declarations.

* initial_check, and always_check, and final procedures (see 16.18.4).

* Generate blocks, containing any of the above elements.

and

 

The following procedures may be defined inside a checker (except inside
a checker action block):

* initial_check procedure, and

* always_check procedure

* final procedure

 

Yaniv

 

________________________________

From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
Sent: Monday, January 21, 2008 11:33
To: Fais Yaniv; Havlicek John; sv-ac@eda.org
Subject: RE: [sv-ac] call to vote on 2089

Hi Yaniv,

 

Lisa also mentioned this, but it is not easy to find a good wording for
this, at least it is not enough to drop the exception as you suggest.

 

There are several limitations in the checker proposal (1900) applied to
the checker body, e.g., only checker variables may be declared there,
only initial_check and always_check may be used, etc. The code in the
assertion action blocks is not affected by these limitations and follows
regular SV rules. This proposal (2089) introduces a new entity in the
checker: a final procedure, and this procedure may be put in the checker
body. But the contents of this procedure are not a checker body: you
cannot declare checker variables there, for example.

 

I agree that the current definition is confusing, and everybody is
welcome to suggest a more intuitive one.

 

Thanks,

Dmitry

 

________________________________

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Fais Yaniv
Sent: Monday, January 21, 2008 11:12 AM
To: Havlicek John; sv-ac@server.eda.org
Subject: RE: [sv-ac] call to vote on 2089

 

I vote No on 2089 due the following reason:

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.

 

Regards,

Yaniv



-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John
Havlicek
Sent: Wednesday, January 16, 2008 03:56
To: sv-ac@eda.org
Subject: [sv-ac] call to vote on 2089

Hi Folks:

This is the call to vote on the revised proposal for Mantis 2089.

The document on Mantis is

   2089_finalInChecker_20080115.pdf

Please vote if you are eligible.  See the details below.

J.H.

------------------------------------------------------------------------
----------
Ballot on Mantis 2089

- Called on 2008-01-15, final ballots due by 2008-01-21 T 23:59-08:00.

 v[xxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan
(Intel)
 v[xxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny
(Synopsys)    
 n[----------------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani
(Synopsys)  v[xxxxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv
Fais (Freescale)  t[xxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
John Havlicek (Freescale - Chair)
v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny
(Intel - Co-Chair)  v[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)  v[xxxxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa
Piper (Cadence)  v[xxxxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................]
Erik Seligman (Intel)
n[-------x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor
Graphics)  v[xxxxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam
Tabbara (Synopsys)  v[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

--
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 <http://www.mailscanner.info/> , and is

believed to be clean. 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

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