Clocking Block assignment bug in IUS583?

Hello Davy.

I had a look at your test case, and can confirm that I see the same behaviour. In fact it can be shown with a much simpler case.
The issue here is that the LRM is not very clear about how the clocking blocks should work in the given example. Your code is waiting for the posedge CLK associated with the clocking block, then assigning signals to the clocking block outputs. Now the tricky bit - when does the clocking block apply the outputs?

In IUS the implementation has been to apply them after the next clock (after all, the signals could be assigned at any point in the cycle, not just on the posedge CLK). Hence you see the effect of the assignment delayed by one cycle. Now it appears that VCS chose to apply the values after the current posedge CLK, so that the extra cycle delay isn't there.

Unfortunately this is just another example of the problems in the SV LRM - it's a huge standard and has a number of gaps where interpretations can differ.

For the example here, Cadence has decided that to follow the scheduling seen in VCS.
I don't have details of when the change will happen though. I suggest that if you are severely impacted by this, that you file a service request such that Cadence R&D get visibility of the relative urgency.

Regards.
Steve H.

interface my_if;
  logic CLK;
  logic in;
  logic out;
  logic out_shadow;

  clocking wr_cb @(posedge CLK);
    default input #1 output #2;
    input in;
    output out;
  endclocking

endinterface : my_if

module tb;
  my_if if_inst();

  initial begin : clkgen
    if_inst.CLK = 1'b0;
    forever #5 if_inst.CLK = ~if_inst.CLK;
  end : clkgen

  initial begin : test
    $display("%m\t: starting @%0t", $time);

    @(if_inst.wr_cb);  // wait for sampling event of interface clocking block
    $display("%m\t: out <= 1 @%0t", $time);
    if_inst.wr_cb.out <= 1'b1;    // "out" will be updated after the wr_cb delay
    if_inst.out_shadow <= 1'b1;   // "out_shadow" will be updated immediately

    @(if_inst.wr_cb);  // wait for sampling event of interface clocking block
    $display("%m\t: out <= 0 @%0t", $time);
    if_inst.wr_cb.out <= 1'b0;    // "out" will be updated after the wr_cb delay
    if_inst.out_shadow <= 1'b0;   // "out_shadow" will be updated immediately

    repeat( 3) @(if_inst.wr_cb);  // wait for sampling event of interface clocking block
    $display("%m\t: ended @%0t", $time);
    $stop;
  end : test

  always @(if_inst.out) begin : mon
    $display("%m\t: out changed to %b @%0t", if_inst.out, $time);
  end : mon

  always @(posedge if_inst.CLK) begin : clk
    $display("%m\t: CLK posedge @%0t", $time);
  end : clk

endmodule : tb

    tb.test : starting @0
    tb.clk  : CLK posedge @5
    tb.test : out <= 1 @5
    tb.clk  : CLK posedge @15
    tb.test : out <= 0 @15
    tb.mon  : out changed to 1 @17
    tb.clk  : CLK posedge @25
    tb.mon  : out changed to 0 @27
    tb.clk  : CLK posedge @35
    tb.clk  : CLK posedge @45
    tb.test : ended @45

Hello Davy.

I had a look at your test case, and can confirm that I see the same behaviour. In fact it can be shown with a much simpler case.
The issue here is that the LRM is not very clear about how the clocking blocks should work in the given example. Your code is waiting for the posedge CLK associated with the clocking block, then assigning signals to the clocking block outputs. Now the tricky bit - when does the clocking block apply the outputs?

In IUS the implementation has been to apply them after the next clock (after all, the signals could be assigned at any point in the cycle, not just on the posedge CLK). Hence you see the effect of the assignment delayed by one cycle. Now it appears that VCS chose to apply the values after the current posedge CLK, so that the extra cycle delay isn't there.

Unfortunately this is just another example of the problems in the SV LRM - it's a huge standard and has a number of gaps where interpretations can differ.

For the example here, Cadence has decided that to follow the scheduling seen in VCS.
I don't have details of when the change will happen though. I suggest that if you are severely impacted by this, that you file a service request such that Cadence R&D get visibility of the relative urgency.

Regards.
Steve H.

interface my_if;
  logic CLK;
  logic in;
  logic out;
  logic out_shadow;

  clocking wr_cb @(posedge CLK);
    default input #1 output #2;
    input in;
    output out;
  endclocking

endinterface : my_if

module tb;
  my_if if_inst();

  initial begin : clkgen
    if_inst.CLK = 1'b0;
    forever #5 if_inst.CLK = ~if_inst.CLK;
  end : clkgen

  initial begin : test
    $display("%m\t: starting @%0t", $time);

    @(if_inst.wr_cb);  // wait for sampling event of interface clocking block
    $display("%m\t: out <= 1 @%0t", $time);
    if_inst.wr_cb.out <= 1'b1;    // "out" will be updated after the wr_cb delay
    if_inst.out_shadow <= 1'b1;   // "out_shadow" will be updated immediately

    @(if_inst.wr_cb);  // wait for sampling event of interface clocking block
    $display("%m\t: out <= 0 @%0t", $time);
    if_inst.wr_cb.out <= 1'b0;    // "out" will be updated after the wr_cb delay
    if_inst.out_shadow <= 1'b0;   // "out_shadow" will be updated immediately

    repeat( 3) @(if_inst.wr_cb);  // wait for sampling event of interface clocking block
    $display("%m\t: ended @%0t", $time);
    $stop;
  end : test

  always @(if_inst.out) begin : mon
    $display("%m\t: out changed to %b @%0t", if_inst.out, $time);
  end : mon

  always @(posedge if_inst.CLK) begin : clk
    $display("%m\t: CLK posedge @%0t", $time);
  end : clk

endmodule : tb

    tb.test : starting @0
    tb.clk  : CLK posedge @5
    tb.test : out <= 1 @5
    tb.clk  : CLK posedge @15
    tb.test : out <= 0 @15
    tb.mon  : out changed to 1 @17
    tb.clk  : CLK posedge @25
    tb.mon  : out changed to 0 @27
    tb.clk  : CLK posedge @35
    tb.clk  : CLK posedge @45
    tb.test : ended @45