Handshake Interview Questions

A beat moves at a rising clock edge where valid and ready are both high, and at no other edge. Once the source raises valid, it keeps it high until that edge, with the payload unchanged. The source must not wait for ready before raising valid. The sink may wait for valid, or raise ready early. valid is low during reset.

No. ready may rise in advance and fall again before valid is asserted; it carries no hold obligation. The only rule on ready is indirect: if it is high at an edge where valid is high, a beat moved. A checker must report the musts and can warn on the shoulds. It stays silent on freedoms like this one.

Write one parameterised checker module over clk, rst_n, valid, ready and the payload. Attach it with bind, so every instance gets it without touching the RTL. Make it count antecedent matches (cycles where the rule's trigger held) per link, and report links whose stall rule never started. A silent checker on a link that never stalled checked nothing. The same properties run as assertions in formal.

No. AXI requires valid to stay low at least until the rising edge after reset goes high. The earliest it may rise is at a rising edge after release. So a sink first sees it one edge later. Reset may be asserted asynchronously, but it is released synchronously. A source that raises valid too early can hand a beat to a sink that is still leaving reset.

A strobe is a one-way pulse that assumes the receiver can always take the data. If it cannot, data is lost. A four-phase req/ack handshake needs no shared clock: req rises, ack rises, req falls, ack falls. So it suits clock crossings, but costs four transitions per item. Valid/ready uses the shared clock to do this in one edge per beat, with backpressure (the sink can stall the source).

The requester always moves first, and the completer can only stretch the current transfer. APB holds the access phase while PREADY is low. AHB extends the data phase while HREADY is low. There is one flow-control point per transfer, not one per channel. So reads and writes cannot overlap independently, the way AXI channels do.

It is a circular wait. The engine raises valid only after seeing ready, and the controller raises ready only after seeing valid. The controller is legal, because a sink may wait for valid. The engine broke the rule that valid must not wait for ready. Its unit test passed because that bench kept ready high in advance. The run shows the same source moving 18 beats with one legal sink and 0 with another.

Someone has to move first, and the source is the side that knows a beat exists. Letting the sink wait is useful. An interconnect can decode the address carried with valid before it decides which target grants it. A sink can also keep ready low to save power. If either side could wait, two compliant blocks could deadlock, so the spec fixes the order.

Inside one block, a same-cycle ready = f(valid) works logically. But on an AXI interface, the spec forbids combinational paths from inputs to outputs. So the wait goes through a register, and ready rises the cycle after valid is seen. The rule stops timing paths from chaining across blocks. A combinational ready path would grow with every stage.

The two paths close a combinational loop through both blocks. Simulation can oscillate or hang in zero time, and timing tools cut the loop at a random point. AXI rules both halves out. A transmitter must not wait for READY before it asserts VALID, and no input may reach an output combinationally.

Test each source against an adversarial sink, one that keeps ready low until it sees valid. Assert that pending work produces valid within a bound while ready stays low. In every agent, randomise ready per cycle, including long low stretches. In formal, assume ready stays low until valid and prove that valid rises. A cover that never hits points at the circular wait.

No. It checks that valid stays high, but not that the payload stays stable during a stall. So a source that swaps data mid-stall passes. It has no reset rule. And "never fired" may mean "never started": if the tests never stall, the antecedent (the left side of |=>) never matches. Add $stable(payload) under the same antecedent, a reset property, and a count of stalled edges.

Because the sink may already have acted on it. For example, an interconnect may have decoded the address and started arbitration. A registered sink also samples whatever is on the wires at the handshake edge. If the payload can change, the beat the sink receives depends on exactly when ready rose. Neither side controls that.

Measure its antecedents. Count the edges where valid && !ready held, per link and per test, or write cover property (valid && !ready). Zero means the rule was vacuous: it passed without checking anything. Then make sure the agents create stalls. Use random ready with long low runs, and stall on the first beat and on a burst's last beat.

A traceability table that maps each must-rule in the spec to a property. Each property is bound on every instance of the interface. Every antecedent is covered in regression on every instance, and nothing fires at sign-off except reviewed waivers. Where the risk justifies it, cross-check with a commercial VIP or formal on the same rules. A rule nobody wrote cannot fire.

They answer different questions. The scoreboard catches beats lost, duplicated or corrupted inside the block, which no rule on the wires can see. The rule checker catches illegal timing at the exact edge, even when the data ends up right. For example, a beat withdrawn and offered again later still matches the scoreboard. But it breaks the hold rule.

The monitor is wrong. A held offer keeps valid high on every stalled cycle, so counting valid adds one phantom beat per stall. A beat is an edge where valid and ready are both high. In the twin, the link carries three beats with three stalled cycles. Counting valid gives 6, counting rising edges of valid gives 2, and counting handshakes gives 3.

With a last flag on the final beat, or by counting against a length sent with the request. last lets the receiver and the monitor find where transactions end without knowing the length. A checker spots a short or long burst by comparing the count at last with the requested length. AXI does both: AxLEN in the request, and WLAST or RLAST on the data.

The receiver and the monitor see one long transaction, and the next burst's beats join it. A checker that compares the beat count with the requested length catches it once the count passes the length. Without that check, the fault shows up later as a corrupted packet.

Because the driver reports what it meant to send, not what the wires carried. A driver bug, such as dropping valid during a stall, would be invisible. A passive monitor rebuilds transactions from the wires alone. So the same monitor also works at subsystem level, where the agent is passive and another block drives the link.

Have the monitor count handshakes, stalled cycles (valid && !ready) and idle cycles (!valid) over a window. Report beats per cycle for each link. Separate idles caused by the source from stalls caused by the sink, because they have different owners. Run it with the traffic profile the architects specify. Track it as a regression metric with a threshold.

A registered ready tells the stage about a stall one edge late. So the stage accepts a beat it has nowhere to put, and overwrites one. A slice that accepts only when empty is safe but halves throughput. The fix is a skid buffer: a second register that catches the one beat in flight when the stall arrives. It gives registered ready at full rate, for roughly twice the flops.

Functionally, it is a two-entry FIFO with registered ready. The library FIFO is a fine choice if two things hold. Its ready (not-full) must come from a flop. It must also pass data through without an extra cycle when empty. FIFO designs differ on both, so check them: a not-full computed from the pop brings back the combinational path.

Each slice adds a cycle to the round trip, so the requester must keep more requests outstanding. Throughput is roughly outstanding requests divided by round-trip latency. Re-check the initiator's outstanding limit, ID or tag count, and response buffering. Otherwise the link that met timing now runs slower. Slices on one AXI channel need not match those on another.

Choose credits when the answer takes cycles to travel: long wires, many register stages, chip-to-chip links or a network on chip. The receiver hands out one credit per free buffer entry in advance. The sender spends one credit per beat, so no per-cycle ready crosses the link. The cost is buffering. The receiver needs about as many entries as beats sent during a credit's round trip.

At least as many as the beats it can send during one credit's round trip. The round trip is the forward delay, the receiver's turnaround and the return delay. With fewer, the sender stops and waits while the receiver is empty. Measure the real round trip, including every register stage. Rounding it down is the usual mistake.

It must fit the beats it already holds when the pause starts, plus every beat that arrives during it. Subtract any beats that leave. With one held and one arriving per cycle for 20 cycles, that is 21 entries. A 16-deep FIFO loses 5. If the producer is faster on average than the consumer, no depth is enough; only flow control fixes that.

A credit leak: a credit returned during reset, dropped on a flush, or a beat sent without spending one. Each loss quietly shrinks the window until it reaches zero. Check conservation every cycle: sender credits plus beats in flight plus receiver free entries equals the configured total. Also check that the full count is back whenever the link is idle.

The receiver comes back with all its entries free, but the sender still holds its old credits. Those credits are now counted twice, so the sender can overrun the receiver. The spec gives the transmitter no credits and the receiver all of them in reset. So both sides must reset together, or re-start the link from that state.