RE: [sv-ac] call to vote on Mantis 1932

From: Bustan, Doron <doron.bustan_at_.....>
Date: Tue Jan 29 2008 - 01:59:15 PST
Hi Lisa, Manisha,

 

I think that a convincing argument for the consistency of weak LTL
operators in recursive properties is

that weak until can be implemented using recursive properties:

 

property r_until(p1,p2);

   p2 or (p1 and 1 |=> r_until(p1,p2));

endproperty

 

So everything that is expressed with recursive properties with until,
always, (weak ) eventually etc. 

can be easily translated to recursive properties without them

 

best regards

 

Doron

 

________________________________

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Bustan, Doron
Sent: Tuesday, January 29, 2008 8:43 AM
To: Lisa Piper; john.havlicek@freescale.com; sv-ac@server.eda.org
Subject: RE: [sv-ac] call to vote on Mantis 1932

 

Hi Lisa,

 

Thanks for the review.

 

My comments are below. I will try to write something about the recursive
properties.

 

Doron

 

4. this is more of a question.  I have become confused on the meaning of
followed-by. Should I be thinking along the lines of attempts, or is
this a one time thing as though it is in an initial block?

[[DB:]] It should be attempt based, (unless the assertion is in initial
block)

 

 I understood the description and examples, but not the equivalency
expressions to |-> and |=>. I am having trouble following what happens
at a specific clock tick when the sequence on the LHS is false - does
that attempt pass or fail? There is something missing here. 

[[DB:]]  For a specific attempt, if there is no match of the sequence on
the LHS, then the property evaluates to false. Comparing to |->,|=> the
universal quantifier (for every match) is replaced with an existential
quantifier (exists a match).

 

5. shouldn't examples p2 to p5 in the description of always have the
##[range] instead of range?.

property p3;

s_always [2:5] a;

endproperty

 

should be 

 

property p3;

s_always ##[2:5] a;

endproperty

 

I think this:

 

s_always [constant_range] property_expr (ranged strong form of s_always)

 

should be:

 

s_always ##[constant_range] property_expr (ranged strong form of
s_always)

 

I think it will be very strange if always uses the ## and s_always does
not which is what the current syntax shows.  In any case the examples
here are inconsistent with the syntax. The same issue exists with
eventually.

 

[[DB:]] Non of them have the ##, the only difference is that s_always
shall not use unbounded range

 

 

7. didn't Dmitry's 1683 change this: the

"clock for the end of the antecedent must be the same as the clock for
the beginning of the consequent."            

 

[[DB:]] There is a note: "Note to the editor: if 1683 does not pass
then"

8. I would like to discuss whether recursive support is necessary at
this time.

 

9. I would to understand whether this is dependent on the proposal for
the VPI changes, or whether this could get accepted without the VPI
getting accepted.

[[DB:]] I do not want it to depend on the vpi proposal. Giving the time
constraints, I think we should priorities this, have the main proposal
in the 2008, and fix the vpi latter.

 

 

 

 

 

 

 

 

 

 

 

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John
Havlicek
Sent: Tuesday, January 15, 2008 9:00 PM
To: sv-ac@eda.org
Subject: [sv-ac] call to vote on Mantis 1932

 

Hi Folks:

 

This is the call to vote on the proposal for Mantis 1932.  Note that

this ballot runs until 2008-01-28, but do not delay since we are

running out of time!

 

The documents on Mantis are

 

   LTL.1932.080115.pdf

   LTL_Formal.080115.pdf

 

Please vote if you are eligible.  See details below.

 

J.H.

 

------------------------------------------------------------------------
----------

Ballot on Mantis 1932

 

- Called on 2008-01-15, final ballots due by 2008-01-28 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. 
---------------------------------------------------------------------
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.
Received on Tue Jan 29 02:05:24 2008

This archive was generated by hypermail 2.1.8 : Tue Jan 29 2008 - 02:05:33 PST