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

From: Fais Yaniv <yaniv.fais_at_.....>
Date: Tue Jan 08 2008 - 01:00:06 PST
 Hi Dmitry,

what if you define a global clock to be a clock which is slower than the
"clk" ? (I know this isn't the intention but we never said this isn't
allowed).

in this case the always_check would be updated in a faster rate than the
assign looking at "$past_gclk(b) && c", this can cause inconsistency if
"b" would be changing not a the global clock rate.


The source of the problem isn't with the "clk" however but with all
signals which can change in between ticks of the global clock - this
shouldn't happen in formal verification if indeed the global clock is
the fastest system clock but in simulation you can have time step
delays, now since the "assign" is always evaluated it can get to look at
"c" not at a global clock tick time point, if at this time point the
value of "c" is different than the future value at the next global clock
tick than an inconsistency can occur.


Regards,
Yaniv


always_check @clk
a <= b && $future_gclk(c);

assign a = $changed_gclk(clk) ? $past_gclk(b) && c : $past_gclk(a);


-----Original Message-----
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
Sent: Tuesday, January 08, 2008 09:25
To: Fais Yaniv; Havlicek John; sv-ac@eda.org
Subject: RE: [sv-ac] RE: call to vote on 1900

Hi Yaniv,

Please, see my comments below.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Fais Yaniv
Sent: Monday, January 07, 2008 8:02 PM
To: Havlicek John; sv-ac@server.eda.org
Subject: [sv-ac] RE: call to vote on 1900

 
I vote yes with the following minor amendment:

page 7:
checker_instantiation ::=
checker_identifier name_of_instance ([list_of_port_connections]) ;

should be same as page 32:
checker_identifier name_of_instance ([list_of_checker_port_connections])
;

[Korchemny, Dmitry] Fixed.

also, on page 23 it is written:
always_check @clk
a <= b && $future_gclk(c);
The equivalent form after rewriting is:
assign a = $changed_gclk(clk) ? $past_gclk(b) && c : $past_gclk(a);


I think it should be added that there is an assumption that all those
signals do not change between edges of the global clock , otherwise in
simulation a bad definition of global clock (that is a definition of an
event which isn't necessarily the fastest one) means the above isn't
equivalent (since if you look at the value of "a" thus by the assign the
values of  "clk" or "c" between edges of the global clock you can see
different values than those in the actual edge of the global clock).

[Korchemny, Dmitry] I think this definition is consistent with the
definition of $future_gclk in simulation for assertions. $future_gclk(c)
means the value of c at the next tick of gclk, even if c changed before
that.

Yaniv



-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com]
Sent: Monday, December 31, 2007 18:58
To: sv-ac@eda.org
Cc: doron.bustan@intel.com; eduard.cerny@synopsys.com; Fais Yaniv;
Havlicek John; dmitry.korchemny@intel.com;
Manisha_Kulshrestha@mentor.com; johan.martensson@jasper-da.com;
piper@cadence.com; erik.seligman@intel.com; bassam.tabbara@synopsys.com;
thomas.thatcher@sun.com
Subject: call to vote on 1900

Hi Folks:

Since my last call to vote on 1900 did not reach the reflector, I am
calling for a new, 1-week vote.  This is that call.

I have copied the eligible voters individually because the reflector
seems unreliable.

Please send your ballot both to the reflector and to me individually.

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

J.H.

------------------------------------------------------------------------
----------
Ballot on Mantis 1900

- Called on 2007-12-31, final ballots due by 2008-01-07 T 23:59-08:00.

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

--
This message has been scanned for viruses and dangerous content by
MailScanner, 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 8 01:17:43 2008

This archive was generated by hypermail 2.1.8 : Tue Jan 08 2008 - 01:18:51 PST