As opposed to not using them at all, I assume?
The answer really depends on your knowledge of the Verilog scheduling mechanism - do you know how to code to prevent race conditions, and do you know how to deal with bidirectional buses from the testbench. If you don’t understand this, then clocking blocks simplify the problem. However, they do come with several additional guidelines that you need to follow
- All samples and drives to clocking block inputs and outputs respectively must be synchronized to the clocking block event (cb). Do not use any other events or waits other than @cb or @(cb iff signal==1)
- The clock event used to trigger the clocking block must not come from a program. (we do not recommend using program blocks anyways)
- Once you start using clocking blocks in an interface, do not reference those signals from anything other than the clocking block in your testbench.
However, if you already understand how to code to prevent race conditions and deal with bidirectional buses, then clocking blocks are an additional level of complexity that can be avoided.