1.

When using a clocking block, the testbench must access only its clockvars
and should never access the clocking signals directly.(CB_name.Clock_var_name)
clocking wr_cb@(posedge clock);
default input #1 output #1;
============Clocking Var s==============
output wr_address;
output data_in;
output write;
endclocking: wr_cb
2.
Testbench code should synchronize itself to a clocking block s clock event b
y waiting for the clocking block s own named event, NOT by waiting for the raw clo
ck event.
Testbench code that uses a clocking block should never synchronize itsel
f to the raw clock event such as @(posedge clock). This would give rise to unexp
ected behavior of input sampling.
// GOOD testbench procedural code
Wait on clocking block event
@ (IF_name.CB_name) //Do this
valid_result = IF_name.CB_name.Clock_var;
...
...
// BAD testbench procedural code Wait on raw event
@(posedge clock) // DON T DO THIS
unreliable_result = IF_name.CB_name.Clock_var;
REASON 1: The name of a clocking block (and, therefore, of its named eve
nt) can be chosen to reflect the testbench-facing effect of the clock.
Eg. clocking video_pixel_clk @(negedge vClk);
The clocking block hides the clock s edge polarity from the testbench. If
the testbench carefully uses @video_pixel_clock everywhere, instead of @(negedge
vClk), then future changes to the clock s name or polarity can be accommodated si
mply by changing our clocking block s definition.