ljepson74

waiting for next clk edge, interfaces and clocking blocks

3 posts in this topic

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)".

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now