A Check for Unknown Bits

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItBreak ItCompareScale It

1. A Check for Unknown Bits
2. CompareThree Ways to Ask Whether a Value Is UnknownL1 Junior

   Compare $isunknown(r), r === 'x and r == 'x as checks for an unknown bus.

   Reveal the Model Answer

   $isunknown is true when any bit is x or z, which is the check you want. === compares x and z bits literally, so r === 'x is true only when every bit is x and misses a half-driven bus. == returns x whenever an operand has an x bit, so it never gives a clean true. The run shows all three on xxxx0101.

   Check	Result	Why
   $isunknown(r)	1	At least one bit is x or z
   r === 'x	0	True only if every bit is x
   r == 'x	x	Any x bit makes == return x

   The values are the output of the run on this question.

   RUNIcarus Verilog · in your browser

   Edit the code, then run it

   OutputWaves

   RunReset codeExpected: isunknown=1 case_eq_all_x=0 logic_eq=x

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 $isunknown is true when any bit is x or z, which is the check you want. Key point 2 === compares x and z bits literally, so r === 'x is true only when every bit is x and misses a half-driven bus. Key point 3 == returns x whenever an operand has an x bit, so it never gives a clean true. Key point 4 The run shows all three on xxxx0101.

   What Interviewers Listen For (Junior)

   A good junior answer predicts all three results for a partly unknown value before running the code.

   Misconception

   "Write if (r == 'x) to catch an unknown bus."

   == with an x operand yields x, and if treats x as false, so that branch can never run. The run prints logic_eq=x.

   Source IEEE 1800-2017 §11.4.5

   • Lesson 1.1Four-State vs Two-State Types
   • Problem 1.1.1Unknown-Bit Counter
3. Break ItAn Unknown Check That Fires Every Idle CycleL1 JuniorL2 Mid-Level

   You add assert property (@(posedge clk) !$isunknown(rdata)); and it fails on almost every cycle of a passing test. What is wrong with the check?

   t=15 a_known failed: rdata=xxxxxxxx rvalid=0
   t=25 a_known failed: rdata=xxxxxxxx rvalid=0
   t=35 rvalid=1 rdata=3c  (scoreboard OK)
   t=45 a_known failed: rdata=xxxxxxxx rvalid=0

   Reveal the Model Answer

   The bus is allowed to be unknown when nothing is being transferred; only data that rvalid marks as valid must be known. Write rvalid |-> !$isunknown(rdata), and check the qualifier itself with a separate unconditional !$isunknown(rvalid) after reset.

   In cycles 0 to 3, rdata is x while rvalid is 0, which is legal. A check gated by rvalid fails only at cycle 4.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 The bus is allowed to be unknown when nothing is being transferred; only data that rvalid marks as valid must be known. Key point 2 Write rvalid |-> !$isunknown(rdata), and check the qualifier itself with a separate unconditional !$isunknown(rvalid) after reset.

   Wrong Altitude

   "Reset rdata in the DUT so the assertion stays quiet."

   That adds reset logic to a datapath to satisfy a wrong check. Many designs leave data unreset on purpose to save area; the protocol only promises known data when it is valid.

   • Lesson 1.7Debug Case: The X That Became Zero
   • Lesson A1.3Implication and Vacuous Success
4. WhyWhy Teams Assert That Data Is KnownL1 Junior

   Why add !$isunknown checks at all, if the scoreboard compares the data anyway?

   Reveal the Model Answer

   A scoreboard may convert the data to a two-state type, where x becomes 0, or compare with !=, where x hides. An X check at the interface catches an undriven or unreset bus at the cycle it appears. It also points straight at the interface instead of at a later data mismatch.

   The DUT drives x, the monitor copies it into an int, and the checker compares 0 with 0. A !$isunknown check on the DUT side would fire at the read.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A scoreboard may convert the data to a two-state type, where x becomes 0, or compare with !=, where x hides. Key point 2 An X check at the interface catches an undriven or unreset bus at the cycle it appears. Key point 3 It also points straight at the interface instead of at a later data mismatch.

   Half-Truth

   "X bugs are only an RTL simulation artefact."

   An x in RTL often marks a real missing reset or undriven signal, which becomes a random value in silicon.

   Source Sutherland, RTL Modeling with SystemVerilog for Simulation and Synthesis, appendix C

   • Lesson 1.7Debug Case: The X That Became Zero
5. What IfLimiting Active Bits with CountonesL1 Junior

   Asked if they mention $onehot

   What if up to two of eight channels may be active at once? $onehot no longer fits.

   Reveal the Model Answer

   Write $countones(active) <= 2. $countones returns the number of 1 bits, so any limit works. Pair it with a cover for exactly two active channels, so the test shows that the limit case really happened.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Write $countones(active) <= 2. Key point 2 $countones returns the number of 1 bits, so any limit works. Key point 3 Pair it with a cover for exactly two active channels, so the test shows that the limit case really happened.

   Misconception

   "Write active inside {0, 1, 2}."

   That compares the vector's value, not its number of set bits. Value 3 has two bits set but is rejected, and value 2 has one bit set.

   Source IEEE 1800-2017 §20.9

   • Lesson A5.1Assertions in Procedures, Sequences as Events
6. Scale ItKeeping Unknowns Visible Across a Chip-Level BenchL3 Senior

   At chip level much of the environment is two-state, and the emulation runs are two-state too. How do you stop X bugs from escaping?

   Reveal the Model Answer

   Draw the line at the DUT boundary: interfaces and monitors stay four-state, and every bus gets a valid |-> !$isunknown(data) assertion bound to it. Reset and power-up scenarios run on a four-state simulator as a sign-off item. Emulation normally runs two-state; X modes exist but cost speed, so reset-state X checks belong in four-state simulation. Two-state is allowed only behind that boundary, where speed matters and nothing samples the DUT.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Draw the line at the DUT boundary: interfaces and monitors stay four-state, and every bus gets a valid |-> !$isunknown(data) assertion bound to it. Key point 2 Reset and power-up scenarios run on a four-state simulator as a sign-off item. Key point 3 Emulation normally runs two-state; X modes exist but cost speed, so reset-state X checks belong in four-state simulation. Key point 4 Two-state is allowed only behind that boundary, where speed matters and nothing samples the DUT.

   What Interviewers Listen For (Senior)

   A good senior answer says which runs can see an x and which cannot. It makes the four-state reset run a sign-off item, not a hope.

   Half-Truth

   "Emulation covers it; it runs a million times more cycles."

   Emulation normally runs two-state, so a missing reset reads as 0 or 1. X modes exist but cost speed, so treat reset-state X checks as a four-state simulation item.

   Source ASIC Point engine notes (Verilator 5.052 SVA probes), row "x/z values" (how a two-state engine reads an X)

   • Lesson 1.7Debug Case: The X That Became Zero
7. Prove ItSolve 1.1.1: Unknown-Bit CounterSimulator-graded

   Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

   Open Problem 1.1.1