[sv-ac] Reply to Adam on gated clocks

Subject: [sv-ac] Reply to Adam on gated clocks
From: Stephen Meier (Stephen.Meier@synopsys.com)
Date: Fri Mar 21 2003 - 18:16:03 PST

Adam:

I reviewed the Synopsys reccomended methodology for low power
clock gating:

In Verilog, the code utilizing the block-level enable may look like:
always @(posedge clock or negedge reset)
        if (reset == 1?b0)
                data_out <= ?b0;
        else if (block_enable == 1?b0)
                data_out <= data_in;

This is a synchronous enable gating condition.

My understanding is that this is the most prevalent
clock gating style in use for synthesizable designs.

I'll reply embedded in the text to the rest.

At 10:04 AM 3/21/2003 -0600, Adam Krolnik wrote:



Hi Steve, all;

We also talked briefly about support for enabled (gated) clocks.

The thought was that (clk & enable) would produce the desired effects and is supported
by the current methods.

However I do not believe that this is correct.

The question is are these two fragments equivalent.

always @(posedge (clk & enable))  q <= d;

vs.

always @(posedge clk) if (enable) q <= d; // q1 below

I'm not sure why this equivalence is important or needed.

I stated during the call that you can have a boolean expression as the
event control, but I did not state that these two forms were equivalent.

One issue that could happen is not being able to put a procedural
assertion if you have a non-synthesizable asynchronous clock
gating condition such as you wrote

always @(posedge(clk & enable)) q <= d;

Then I would be quite concerned about race conditions between
clk and enable.  Provide that there are no races or glitches
then you could write an concurrent assertion as follows:

always @(posedge (clk & enable) assert prop_x;

You cannot write a procedural assertion for this case.

Running a small program to test this theory, here are the results from Vcs 6.0
I stripped out the negedge clk changes...

Compiler version 6.0; Runtime version 6.0;  Mar 21 09:57 2003

 q uses clk & enable.
q1 uses clk iff enable.
      time clk d  e  q  q1
        10  1  1  1  0  x   early
        30  1  2  0  1  1   later
        50  1  3  0  1  1
        70  1  4  1  3  1   early
        90  1  5  0  4  4   later
       110  1  6  0  4  4
       130  1  7  1  6  4   early
       150  1  8  0  7  7   later
  ...

Notice that q and q1 are not the same. Q (clk & enable) changes when the enable is asserted. Q1 (clk iff enable) changes 1 clock later. For Q, this is because when the clock is asserted, the enable becomes the clocking event. However for Q1 the clocking
event is only based on clk and then Q1 is updated only if enable is asserted.

Thus I would recommend that the clocking proposal be updated to allow

  @@(posedge clk iff enable)

as legal syntax. This syntax is already part of SystemVerilog.

We will follow-up and investigate whether iff is still supported, at this point it
should be ok, but I would rather not require as only way to support boolean expressions
as sampling conditions.


Without this you will have a hole in multiple clock support. Clock gating/enable is becoming a more and more common technique especially in power sensitive designs. Proper
support will be necessary to for ease of use with properties.


    Adam Krolnik
    Verification Mgr.
    LSI Logic Corp.
    Plano TX. 75074





module enableclk;

reg clk;

reg enable;
reg [3:0] d, q, q1;

initial begin
  clk = 0;
  forever clk = #10 ~clk;
  end


initial
  begin
  $display(" q uses clk & enable.");
  $display("q1 uses clk iff enable.");
  $display("      time clk d  e  q  q1");
  $monitor($stime,,, clk,, d,,, enable,, q,, q1);
  end

always @(posedge clk)  if (enable) q1 <= d;
always @(posedge (clk & enable))   q <= d;

initial begin
  d = 0;
  repeat (20) @(posedge clk) d <= d + 1'b1;
  $finish;
  end

initial begin

  enable = 0;

  repeat (10)
    begin
    @(posedge clk);
    enable = 1'b1;
    @(posedge clk);
    enable = 1'b0;
    @(posedge clk);
    end
  end

endmodule

Steve Meier (stephen.meier@synopsys.com) W: 650-584-4476, Cell: 408-393-8246

This archive was generated by hypermail 2b28 : Fri Mar 21 2003 - 18:20:02 PST