Reading $display Output

A $display line prints a labelled value at a specific simulation time. In this course, a check line typically prints something like:

[t=25] FAIL  a=1,b=0  expected y=1 got y=0

That single line names three things: the input case (a=1, b=0), the expected value (y=1), and the actual value (y=0, printed as "got"). The simulation time tells you when in the test sequence the failure happened, which matters most once a design has state — a failure at t=45 happened after whatever the design did at t=15, t=25, and t=35.

One failing line rarely tells the whole story. Read it alongside the PASS lines around it: which input cases succeed, and which fail? A pattern across several lines — for example, every failure sharing one property of its inputs — is a strong clue, not a verdict, about which bug class to check first. A result that flips exactly where two operators would disagree is a good first hypothesis for a wrong operator. A result that is right for a while and then wrong from some point onward is a good first hypothesis for a sequential problem rather than a combinational one. Either way, the log narrows the search; only inspecting the RTL and rerunning the design confirms the actual cause. Reading the log first, and only then opening the design, is the same diagnose-before-fix habit this module builds throughout.