RE: [sv-ac] Proposal updated for Mantis 2656 (Ballot Comment #84)

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Sun May 03 2009 - 12:58:50 PDT
From: ben cohen [mailto:hdlcohen@gmail.com]
Sent: Sunday, May 03, 2009 9:36 PM
To: Korchemny, Dmitry
Cc: Thomas.Thatcher@sun.com; sv-ac@server.eda.org
Subject: Re: [sv-ac] Proposal updated for Mantis 2656 (Ballot Comment #84)


[Korchemny, Dmitry] $falling_gclk(clk) is present in Table 16-2, and in your table it appears twice. I don't think that we need to consider all ticks of the global clock in this table. If you disagree, you are welcome to  open a Mantis item with your suggestion. Unfortunately, we are not authorized to address it now.
I have version IEEE P1800/D7a
Below is the heading of Table 16.2.  I see $falling_gclk(sig),but not $falling_gclk(clk)
Perhaps I am looking at an earlier version of the P1800-2009 .
page 334:
Time $sampled(sig) $future_gclk(sig) $rising_gclk(sig) $falling_gclk(sig) $changing_gclk(sig) $steady_gclk(sig)
[Korchemny, Dmitry] You are right regarding $falling_gclk(clk). But the LRM states: Table 16-2 shows the values returned by the global clocking future sampled value functions for sig at different time moments.



Since most designs use a single edge of the clock, rather thatn both edges, I suggest that we modify the example from:  global clocking @clk; endclocking

To the following    global clocking @ (posedge clk); endclocking

assert property(@$global_clock a);   // the assertion states that a is true at each tick of the global clock. In simulation, tThis assertion is logically equivalent to

assert property(@ (posedge clk)  a);

 [Korchemny, Dmitry] I think that global clocking @clk; endclocking also makes sense. The global clock reflects the primary clock, and the primary clock normally should tick at least at each change of clk. Consider the following assertion: the clock always ticks. You can implement it as:

assert property (@$global_clock $rising_gclk(clk)); (or $changing_gclk, $falling_gclk).

 According to the definition you suggest this assertion will be violated, since the sampled value of clk is always 0 @(posedge clk).
[Ben Cohen] I must have a misconception in the use of the @$global_clock. If my understanding is correct, if I have a portion of my design that is synchronous to one clock, I could in simulation and in formal verification declare a global clocking, and use the @$global_clock as my clocking event.  Thus, if my FF trigger on positive edge, I could state
 global clocking @ (posedge clk); endclocking
  p1: assert property (@$global_clock req |=> ack);
p1 may or may not necessarily hold on each edge of the clock.
[Korchemny, Dmitry] This is correct.

The use of "global clocking @clk; endclocking" may be implying that this is the way to use a global clocking.  Yet, from the 16.5 update: A reference to $global_clock  (see 14.14 ) is understood to be a reference to the clocking_event  defined in the global clocking  declaration. The global clock behaves just as any other clocking event. In formal verification, however, $global_clock  has additional significance, as it is considered to be the primary system clock (see F.5.1 ). Thus, in the following example
            global clocking @clk; endclocking
.           ..
            assert property(@$global_clock a);
the assertion states that a  is true at each tick of the global clock. In simulation, tThis assertion is equivalent to
            assert property(@clk a);


[Korchemny, Dmitry] Note that in formal verification the global clock is the finest granularity clock and all signal changes are synchronized with it. The definition   global clocking @ (posedge clk); endclocking works if you don't have to address anything that is not synchronized by @(posedge clk). In some cases it may be reasonable, in other cases it does not work, especially when you want to reason anything about the clock itself, for example to assume that it is fair. Therefore, I think that the definition of the global clock as @clk is at least as natural as @(posedge clk).
---------------------------------------------------------------------
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 Sun May 3 13:01:00 2009

This archive was generated by hypermail 2.1.8 : Sun May 03 2009 - 13:02:10 PDT