Combinational RTL Interview Questions

Give idx and valid defaults first, so there is no latch. Then list wildcard items from the top bit down: 4'b1???, 4'b01??, 4'b001?, 4'b0001. Items are checked in order, so the first match gives the highest set bit. Use case inside, or casez if your tools lack it, and never casex. Test all 16 values.

Wildcard case statements mask bits on both sides of the comparison. casex ignores X and Z wherever they appear, so the X in req matches the 1. casez does the same for Z, so z001 matches 1??? and this prints idx=3. In silicon the floating line is a real 0 or 1, so the gates may do something else.

case inside compares with the wildcard equality operator, so only X, Z or ? bits in the items are masked. An unknown bit in req then fails every item and falls to default. It synthesizes to the same 5 cells as the casez version on this flow. Icarus 12 does not parse case inside, so check your tools first.

Use a for loop that walks from bit 0 up and overwrites idx on every set bit. The last write wins, so the highest set bit wins. Set the defaults before the loop. Synthesis unrolls the loop into a chain. On this flow the 16-bit version is 40 cells and 12 levels, so depth grows with width.

Split the bus into four groups of four. Each group has a small encoder and a "busy" bit. A top encoder picks the highest busy group, and its number forms the upper bits of idx. The run proves the two versions equal on all inputs. On this flow the grouped one has 8 levels instead of 12, for about the same cells.

Both promise that some arm matches when there is no default. unique also promises at most one arm matches, so synthesis may ignore the order. priority keeps the order, and the first match wins. The simulator checks the promise each time the statement runs, while synthesis simply assumes it. If the promise is false, RTL and gates can disagree.

The RTL runs the first matching arm, so it passes one data word. The netlist was built on the promise of one request at a time. Each data word is ANDed with its request and the results are ORed. With two requests, two words mix: 0010 | 0100 = 0110. The false promise became a functional bug.

Run RTL simulation with the unique checks on. The simulator reports a violation when two items match, or when none does. Also assert $onehot0(req) at the block boundary, so the caller's side is checked. Formal can then prove that assertion from the requesters' logic.

priority keeps the order and only promises that something matches. Use it when overlaps are legal and the spec says who wins. unique promises exactly one match without a default. unique0 promises at most one and allows no match. Use unique0 for a decode where "nothing selected" is normal.

Allow it only where the inputs are exclusive by construction, such as a one-hot state register or a decoded address. Back each use with a one-hot assertion and a formal proof or a test that tries the overlap. Run regressions on a simulator that checks unique. Treat every violation as a design bug, not a warning.

Not here. Every condition compares the same 2-bit sel with a different constant, so at most one can be true. Synthesis sees that and builds a plain 4:1 mux. On this flow the chain is 27 cells and 4 levels, the same depth as the case. Priority is real only when conditions can be true together.

The case version has the same 4 levels but 60 cells, against 27 for the chain. The tool built it as decoders plus an AND-OR, not as a mux tree. Another synthesizer may give other numbers. The lesson is to measure your own flow, not to trust a style rule.

When the conditions test different signals that can be true together, such as separate request bits. Then the order is part of the function, because it decides who wins. Synthesis must keep it, and each extra condition adds a stage. That is the selector in the twin: 5 levels, not 3.

The pragma is a comment that only synthesis reads. It makes the same promise as unique: the items never overlap. But the simulator ignores it, so nothing checks the promise. If it is false, RTL and gates disagree with no warning. Use unique, which makes the same promise and gets checked.

full_case tells synthesis that unlisted values never happen, so it builds no latch for them. Simulation ignores the comment and still holds the old value for those values, as a latch would. So the RTL holds a value that the gates do not. A default assignment, or unique, makes both agree.

A binary select feeds a tree of 2:1 muxes, about six deep for 64 inputs. If the select is already one-hot, an AND-OR structure avoids the decode. If the path is still too long, register the select early or split the mux across a pipeline stage. Lesson R5.5 measures these choices.

With en at 0, y is simply 1. With en at 1, y = ~y, which has no stable value. Real gates oscillate at a rate set by their delay, like a ring oscillator. A zero-delay simulator keeps re-evaluating in the same time step, so it hangs or hits an iteration limit. The synthesis check reports a combinational loop.

STA adds delays along paths from a start point, such as a flop or an input, to an end point. Around a loop, a path comes back to where it started, so the arrival time has no limit. STA tools report loops for that reason. A tool that cuts a loop to continue may hide a real path.

Functionally it may never cycle. But the structural checks and STA see wires, not select values, so they still report a loop. Every team must then waive it and re-check it after each change. Recode it so no structural loop exists, for example by sharing one mux.

A latch is feedback with two stable states and a defined way to open and close it. In silicon it is one library cell, so timing tools know its checks. An accidental loop is built from ordinary gates. Its feedback may have no stable state, or two that nothing controls. Write a latch on purpose with always_latch so tools map it to a latch cell.

That is the common case. Each module has a legal input-to-output path, and the two paths close a loop at the top. Per-module lint cannot see it. Run lint and the synthesis check on the connected design. Lesson R3.3 measured both tools finding such a loop through two modules.

The source drives valid = have_data && ready, and the sink drives ready = valid && !full. Each waits for the other through logic, so the two ANDs form a combinational loop. Both 0 and both 1 are stable, and nothing picks one, so simulation shows X. The rule is that valid must not depend on ready. The sink may wait for valid.

One side must be allowed to go first without waiting, or a deadlock is possible. The rule picks the sender. A sender that has data raises valid on its own. Then any receiver works, whether it waits for valid or raises ready early.

That is allowed and often faster, because a beat moves in the first cycle valid rises. The sink must then be able to take a beat in any cycle where ready is high. Nothing transfers until both are high at the same edge.

A combinational ready can depend on what happens downstream in the same cycle. In a chain of stages it becomes one long path that grows with every stage. A registered ready cuts that path and every loop through it. But it arrives a cycle late, so the stage needs a spare entry, a skid buffer, to keep full rate.

Write it down as an interface rule. No port has a combinational path from an input to an output, and valid never waits for ready. Check it on the joined design at every integration drop. Use lint and the synthesis check. Bind assertions on every port, such as valid staying high until the transfer.

Simulation re-runs the block only when a or b changes. So when only sel changes, y stays stale. Synthesis builds logic from the expression, not from the list, so it gives a plain 2:1 mux. The RTL simulation now shows behaviour the chip does not have. Use always_comb, which wakes on every signal the block reads.

Gates have no event list. A gate output follows its inputs all the time. Synthesis reads the assignments to learn the function, and the function of sel ? b : a is a mux. A sensitivity list only tells a simulator when to re-run the code.

The block runs more often than needed, which costs a little simulation time. Each run computes the same value, so the output never goes stale. There is no mismatch with the gates. The real danger is always a missing signal, never an extra one.

Icarus prints y=3 and the FAIL line. always @* waits only on what the block names, including function arguments, and shift_en is read inside the function. always_comb also waits on signals read inside called functions, so it gives 6. It also runs once at time zero, and it forbids other writers.

Run lint to list every incomplete sensitivity list. Convert combinational blocks to always_comb, which also checks for latches and second writers. Re-run the full regression, because a fixed list can change what the old tests saw. Then run an equivalence check of the old netlist against the new one, which should match.

An if whose condition is X takes the else branch. So the output shows a clean value from the else side, and the unknown select disappears. In silicon the select is a real 0 or 1, and nobody knows which. RTL simulation looks fine while the chip may pick either branch. The ternary operator is less optimistic: it gives X wherever the two inputs differ.

Because pessimism breaks real circuits in simulation. Take a synchronous reset that ANDs the data with an active-low reset. If an X data input made the AND output X, the flop would never reset in simulation. Silicon resets fine, because 0 AND anything is 0. Optimism matches silicon in cases like that and hides bugs in others.

Reset every control flop, and allow reset-less flops only in the datapath where a valid bit guards them. Add assertions that control signals are never unknown after reset. Run a formal X-propagation check, or gate-level simulation on the boot and reset tests. Some simulators also offer X-propagation modes that make RTL less optimistic.

The usual sources are flops with no reset and memories never written. Others are two drivers fighting on a net, an index out of range, and a missing input connection. An X on a control signal is the dangerous kind, because optimism can hide it. An X in a data word guarded by a valid bit is often harmless.

Optimism turns an unknown into a known value, so RTL looks better than silicon. Pessimism keeps X where silicon would have a real value, so simulation looks worse than silicon. Gate-level models are often pessimistic. An X that silicon would resolve can then spread and never clear, and the test fails for no real reason.

Zero delay rules out timing, so these are mismatches between RTL and netlist. A wrong value where RTL was right points to a sensitivity problem, such as always @* with a function. An X in gates where RTL showed 0 points to a missing reset. Either an inline initializer acted as the reset, or X optimism hid an unreset flop. Fix the RTL, not the netlist.

Verilator does not follow every event rule of the standard. On this example it recomputed y as plain logic, so it printed 6. Icarus follows the @* rule and keeps 3. A design whose result depends on the simulator is depending on code the gates do not have. Fix the code.

Lint reads the RTL and flags risky constructs, such as short sensitivity lists, inline initializers and blocking writes in clocked blocks. It runs in seconds and needs no test. Gate-level simulation finds a mismatch only when a test exercises it, and it runs slowly. Use lint as the gate on every commit, and a small gate-level set as the net.

Zero-delay gates still have no setup or hold time, so metastability and clock crossings look perfect. Real timing faults need static timing analysis, not simulation. Power-up values and analog effects are absent too. Gate simulation catches netlist mismatches, not the physics.

Synthesis cannot build a print or a check as logic. Tools ignore such code, reject it, or keep it as a cell with no output. Wrap simulation-only code in translate_off and translate_on pragmas, or in an ifndef SYNTHESIS guard. Then synthesis sees exactly the design.