A few months ago, I was involved in writing a couple of tests that had to be run using RTL netlists with scan chains in them. Since this involved a lot of gate level signals, it was already cumbersome to debug. The idea was to enter the scan mode and shift out values in the chain and then be able to observe the value of a particular flop, after so many cycles at the output pad. So, there was a need to check if we got the right value at the pin after scan entry.
Scan chains are normally inserted after synthesis as a part of the design for testability (DFT) flow which do not affect functionality of a design and hence are normally not exercised during functional verification. We wanted to put a sample pattern on the Nth flop from the pad, and then check if the same pattern can be seen at the output pin after clocking the flop N times. One way to do so would be to use the typical
release keywords to force a 1 or 0 onto the flop's Q pin and then release it a cycle later. But, there is another alternative called
$deposit which enables you to simply place a value onto any net or register within the design.
// Sample code initial begin if ([at_some_event]) $deposit ([path to net_or_reg], 1'b1); end // Based on the diagram shown above initial begin $deposit (`PATH_TO_BLOCK.dff0.q, 1'b0); $deposit (`PATH_TO_BLOCK.dff1.qb, 1'b0); end
When you place it using
$deposit, you don't have to worry about releasing the value since it will then be set or cleared based on design functionality. Essentially it behaves like a procedural assignment to a
reg type variable. Consider a scenario where you want to verify if a particular flop is being reset properly. Yes, you would have UVM reset sequences and assertions to verify that. But if you wanted to ascertain that this flop is cleared on reset to see a 1->0 toggle, especially in gate level simulations, a test is required where sample values are placed on the flop, reset is applied and check later whether value on the flop was changed to the default value.