Latches and Scheduling Interview Questions

It describes one flop, not three. A blocking assignment updates its variable at once, so s2 reads the new s1 and q reads the new s2. In one edge, d reaches q, so s1 and s2 are just wires. Write the three lines with <=. Then each right-hand side reads the value from before the edge, and you get three flops.

Real flops on one clock all sample their inputs at the same edge, before any of them changes. A nonblocking assignment copies that. Its right-hand side is read when the statement runs, and the update happens later, in the NBA region. So every flop sees the values from before the edge, whatever order the code runs in.

With =, a becomes 2 first, then b copies the new a, so both are 2. With <=, both right-hand sides read the old values, so c and d swap to 2 and 1. No temporary variable is needed. This is the shortest proof of the old-value rule.

Both give three flops in this block. The reversed version only works because of the line order, so a later edit can break it silently. The blocking writes also update at once, so another block reading s1 at the same edge has a race. With <= the order does not matter and readers elsewhere see the old value.

A flop has one D input, so two writers describe hardware that cannot exist. In simulation, the last write in a time step wins, which depends on block order. always_ff makes this a compile error, because a variable it writes may not be written anywhere else. Plain always @(posedge clk) gives no such check.

Neither simulator has a bug. The design has a race. Both blocks wake at the same edge, and the standard lets a simulator run them in any order. Because a is written with =, the reader sees the old or the new value depending on that order. Write a with <=, so every reader at that edge sees the old value in any tool.

With <=, the write to a waits for the NBA region. Every block that wakes at the edge runs before that, in the Active region. So the reader always sees the old a, whichever block runs first. The order still varies, but it no longer changes the result.

Start with lint: report blocking writes in clocked blocks and variables written by more than one process. Convert clocked blocks to always_ff, so the compiler rejects a second writer. Run regressions on two simulators and treat any difference as a bug. Then make the lint rules a commit gate, so new code stays clean.

Lint reads the code and flags the pattern, such as a blocking write in a clocked block. It works even if no test shows a wrong value. A second simulator finds only races that change a result in the tests you run. Lint is cheaper and more complete for coding races. Two simulators also catch other order-dependent behaviour.

It is the same race. The bench write and the flop read both run in the Active region. So the flop may capture the old or the new din. Drive inputs away from the sampling edge, for example on the falling edge or through a clocking block. Then the design always samples a settled value.

It is legal, and it builds 8 flops, all for avg. sum is written with = before it is read, so the next line sees the new sum. It needs no memory, so synthesis makes it a wire from the adder. Keep sum local to the block. Another block that reads it at the same edge would race.

Some clocked blocks need an intermediate value inside the same edge, such as a temporary or a loop variable. A blocking write gives that value at once. The rules for always_ff limit timing controls and other writers. They do not ban =, so lint is where the house rule gets enforced.

Then the two blocks race. sum changes in the Active region at the edge, and the reader runs in the same region in either order. It may get this edge's sum or the last one. Declare the temporary inside the block, so nothing outside can read it.

No. The standard lets the two blocks run in either order inside the Active region. Two tools agreeing only means they chose the same order today. A new version, an extra block or a different file order can change it. Lint for a blocking variable read outside its block, and declare the temporary locally.

Both give the same hardware. A separate always_comb keeps each block to one kind of assignment, so lint rules stay simple. It also makes sum visible in waveforms. The inline form keeps the logic in one place but mixes = and <=. Many style guides choose the separate block for that reason.

When en is 0, sum keeps the value from the last enabled edge, so it is memory now. The run prints avg=15, from the old inputs. On this flow Yosys did not add 9 flops for sum. It folded the memory into an enable on the 8 avg flops. Another tool may build it differently, so read the report.

A combinational block must give every output a value on every path. If one path assigns nothing, the output must keep its old value. Keeping a value needs memory, so synthesis builds a level-sensitive latch. Fix it by assigning every output on every path: a default at the top, an else, or a default arm. Then write the block as always_comb, so lint and synthesis report any path you missed.

The latch is memory the spec never asked for, so the output can show a stale value. While its enable is active the latch is transparent, so glitches on its input pass straight through. Static timing and test tools treat latches specially, so many teams avoid them to keep those steps simple. The design may work in RTL simulation and still fail in the lab.

The latch follows d while the clock is high, so it shows 1 at t=13 and 0 at t=18. The flop changes only at rising edges. It took 0 at t=10 and holds it until t=30, when it takes 1. When the clock is low, the latch holds. Designers use latches on purpose in clock gating cells and in some latch-based pipelines.

No. Simulation behaves the same, and the output still holds its value when en is low. The difference is in the tools that read the intent. Lint names the latch, and many synthesizers warn or stop. On this site's flow, synthesis refuses the block with a logic-loop error. Either way, you still have to add the missing assignment yourself.

The default removes the latch, but it also gives a value to any arm you forgot. A missing arm then outputs the default quietly, often zero, and no tool complains. Choose a default that the spec allows, and make the testbench cover every input value. Some teams use unique case, so that simulation reports a value no arm matches.

Make always_comb mandatory for combinational blocks and always_latch for the rare intended latch. Run lint on every commit, with a latch inference message as an error. Make the synthesis latch count a gate in the flow, with a reviewed waiver list for intended latches. Review default values against the spec, because removing a latch can hide a missing case.

Yes, one latch, on valid. The default arm covers values of op that no other arm lists. It does not cover outputs that a listed arm forgets. In the op == 2 arm nothing assigns valid, so it keeps its last value. res is assigned in every arm, so it has no latch.

Latch inference is decided per variable, per path. The default arm adds one path: the case values no other arm lists. Each listed arm is still its own path. If a listed arm skips an output, that path still holds the output.

Defaults at the top give every output a value on every path, so the latch goes away. unique only makes promises about which arms match. It does not assign valid in the op == 2 arm, so the latch stays. Use the defaults to remove the latch, and add unique only if the arms truly cannot overlap.

The latch goes away, because every path now assigns something. Synthesis reads X as "don't care" and may pick any value that gives smaller logic. Simulation shows X, which helps catch a path that should never run. The guideline today is unique or priority instead, because they give the same freedom with built-in checks.

Downstream logic such as if (valid) treats X as false and takes the else branch. So the path that should never run looks harmless in simulation. Synthesis may choose 1 for that X, and the gates then assert valid there. An assertion that valid is never unknown catches it at the source.