waiting for next clk edge, interfaces and clocking blocks

[ljepson74]

Q1) I'd like confirmation that the following waits for a posedge of clk are identical.  (The code it refers to is far below.)

  1) @(posedge my_play_if.clock);  or  @(posedge clk);
  2) @(my_play_if.cb1);

Q2) I'd also like to confirm that input and output clocking_skew of a clocking block have no effect on the inputs of the interface.  They only affect the inputs and outputs of that clocking block.

 

 

I'm pretty confident about both of these and the SystemVerilog LRM seems clear, but I want to confirm while I am cleaning up some inherited code which is not currently working.

 

Reference: SystemVerilog Standard 1800-2012.pdf, Section "14. Clocking blocks"

 

Below is some sample code I was hacking around with.

//Interface, clocking blocks, and waiting for clock edge

interface play_if(input bit clock);
   clocking cb1 @(posedge clock);
      default input #2 output #2; //clocking_skew is irrelevant to interface inputs, right?
   endclocking
endinterface


module top;
   bit      clk;
   play_if  my_play_if(.clock(clk));

   always #5 clk=~clk;

   initial begin
      $monitor($time," clk=%1b",clk);
      clk=1;
      #100 $finish;
   end

   task tclk();
      $display($time,"     pre-clk");
      @(posedge my_play_if.clock);
      $display($time,"     post-clk");
   endtask

   task tcb1();
      $display($time,"     pre-cb1");
      @(my_play_if.cb1);
      $display($time,"     post-cb1");
   endtask

   initial begin
      #23;
      $display($time," --------------START");
      tclk();
      @(posedge my_play_if.clock);
      tclk();
      #3;
      tcb1();
      tcb1();
      @(posedge my_play_if.clock);
      tcb1();
      tclk();
      tcb1();
      #3;
      @(posedge my_play_if.clock);
      $display($time," --------------FINISH");
   end
endmodule : top

[dave_59]

Hi Linc,

 

No to your first query. There is a difference when interacting with clocking block inputs ##0 delays. The clocking block event cb1 is guaranteed to happen after the clocking block inputs have been updated with sampled values,and ##0 will never block. My general rule when you have a process interacting with clocking block inputs and outputs, always synchronize that process to the clocking block event.

 

And yes to your second query, unless a clocking block output is driving an input to the interface.

[ljepson74]

Thanks, Dave.

 

To be clear, as I understand, "synchronize that process to the clocking block event" in this case means a call to 

@(my_play_if.cb1);

 

Good.  I'm moving to use such calls for the advancement of time (mostly in drivers and monitors/collectors), instead of calls like 

@(posedge my_play_if.clock);  or  @(posedge clk);.

 

 

Can you provide a pseudo-code example of "interacting with clocking block inputs ##0 delays"?

 

As I understand**, if there is a default clocking_block (and only if), we can use cycle delays (i.e. ## integral_number) and that will cause a wait for the specified number of clocking events (even if the first is in the current time step).  

But as long as the input clocking_skew specifies some time before the clocking event, I don't see where a problem would arise by using ##0;.

 

 

Note: Outside of assertions, I don't think I've ever used cycle delays.  Also, I don't use default clocking_blocks, for better or worse.

 

** 1800-2012.pdf  Section "14.11 Cycle delay: ##"

Note: I've updated the original post to highlight the querys with "Q1)" and "Q2)".