Is READY allowed to assert before VALID?

Yes. A destination may assert READY whenever it has capacity. No transfer occurs until VALID and READY are sampled high together. READY describes destination capacity, not a request. Early READY permits a zero-wait transfer when VALID arrives. The prohibited dependency is the source waiting for READY before asserting VALID, because two waiting endpoints can deadlock.

May a source drop VALID if READY stays low?

No. Once VALID advertises a beat, the source must preserve VALID and its payload until an edge accepts that beat. The destination is allowed to sample on any later edge where it raises READY. Changing or withdrawing the offer makes the observed transaction phase-dependent. After the accepted edge, the source may deassert VALID or replace the payload with the next beat.

Does ready/valid guarantee that every offered beat eventually transfers?

Not by itself. The handshake defines safe acceptance; eventual READY needs a system-level fairness assumption, service bound or timeout policy. The destination may apply indefinite backpressure unless the surrounding specification forbids it. A liveness property must encode the relevant assumption or architectural bound. Age monitors and latency coverage reveal starvation without confusing a long legal stall with data corruption.

What must remain stable while PREADY is low?

During an ACCESS wait, the master keeps PSEL, PENABLE and the complete request—address, direction and write-side attributes—stable until completion. The peripheral is extending one transfer, not requesting a replacement. Changing the request would make the eventual response ambiguous. A monitor should retain one pending object across all wait cycles.

Can APB remain in ACCESS for a back-to-back transfer?

No. After one ACCESS completes, the next transfer uses a fresh SETUP cycle with PENABLE low, even if PSEL remains asserted. SETUP identifies the next request and gives the peripheral a distinct phase boundary. PSEL may remain high when the next transfer targets the same peripheral. The transition is ACCESS → SETUP, not ACCESS → ACCESS for a new request.

When is PSLVERR meaningful?

PSLVERR is consumed with the final ACCESS cycle, when PSEL, PENABLE and PREADY are all high. Wait cycles have not completed the transfer. The master samples read data and the error result at the completion boundary. A scoreboard records the response once, alongside the completed request.

Why can an AHB monitor not combine the current address and current data?

Because AHB pipelines them. The current data phase normally belongs to the previously accepted address/control phase. The next address phase overlaps the active data phase. HREADY can stretch that data phase for multiple cycles. The monitor therefore needs retained phase state rather than one same-cycle sample.

How should a checker think about HREADY and HREADYOUT?

HREADY is the bus-level completion seen by the manager and all phase logic. A selected subordinate drives its own HREADYOUT, which interconnect logic contributes to HREADY. The selected subordinate controls completion of its active data phase. Bus-level HREADY also qualifies address/control advancement. A block-level checker may see both signals, but their ownership and scope differ.

What does AHB-Lite remove compared with full AHB?

AHB-Lite is the single-manager subset, so it removes multi-manager arbitration while retaining the pipelined address/data transfer model. The address, data, HTRANS and HREADY reasoning still applies. A single manager simplifies ownership and interconnect control. Optional features remain version- and implementation-dependent and should be taken from the interface specification.

Part 1 · Transfer contracts

Ready/valid, APB, and AHB contracts

Count acceptance on exact clock edges and reconstruct phase-oriented protocols without inventing transfers or losing pipeline history.

Reading path: 1 of 3
Concept chapters: 3
Practice links: 14

Question-first preparation

Practice the mechanisms on this page.

Each question maps directly to one of the chapters below, so you can test the contract before reading the explanation.

Recommended start

One representative prompt from each major mechanism. Open any card in the live question bank.

Complete question directoryFilter every stable practice link by mechanism.14 questions

Showing 14 questions across every track.Choose a track to narrow the practice set without changing its stable question links.

01 · One sampled contract

Ready/valid is simple only when every edge is counted correctly.

A source offers one beat with VALID, a destination accepts it with READY, and state changes only when both are sampled high on the same rising edge.

Rule to say firstTransfer = VALID && READY at the sampling edge. If VALID && !READY, the source must keep VALID and every payload field stable until acceptance.

Handshake trace

One offer can wait for several cycles but transfers exactly once.

Cycle

C0C1C2C3

Each column represents one rising sampling edge.

VALID

1111 or 0

The source keeps the offer asserted through the stall.

READY

0010 or 1

The destination chooses when it can accept.

PAYLOAD

AAAB or idle

Payload A cannot change before its accepted edge.

TRANSFER

——Adepends

Only the conjunction produces an accepted beat.

01OfferVALID=1
The source presents beat A without waiting for the destination.
02StallREADY=0
No transfer occurs. VALID and every field of beat A remain stable.
03AcceptVALID && READY
Beat A transfers once at this rising edge; both endpoints may advance.
04ContinueNext beat or idle
After acceptance, the source may present beat B immediately or deassert VALID.

OfferVALID=1

The source presents beat A without waiting for the destination.

Acceptance: VALID ∧ READY; Both signals are sampled high on one edge.
Source obligation: Persist; VALID and payload remain stable while stalled.
Peak rate: 1 beat / cycle; Continuous VALID and READY sustain full throughput.
Progress: Separate policy; The base handshake does not guarantee READY eventually arrives.

READY may be high before VALID, and either endpoint may sustain its signal. The only architectural event is the sampled conjunction; waveform appearance between edges does not create an extra transfer.

Observe

Sample VALID, READY and the complete payload at rising edges; distinguish offered cycles, stalled cycles and accepted beats.

Decide

Assign ownership: the source owns VALID and payload persistence, while the destination owns READY and backpressure.

Failure

Data is dropped, duplicated or changed under stall because logic advanced on VALID alone or treated a cycle as a transaction.

Prove

Assert stall stability, count only accepted beats, compare monitor transactions and cover sustained backpressure plus full-throughput traffic.

Separate an offer, a stall and an accepted beat

Most protocol bugs come from collapsing three different states into one. VALID says a source has a meaningful beat. READY says a destination has capacity. Their sampled conjunction commits the beat.

Source state, counters, addresses and payload generators advance only on VALID && READY.
Destination occupancy advances only when an offered beat is accepted.
READY-before-VALID is legal and reduces latency; it is not an unsolicited transaction.
Back-to-back transfers require VALID && READY on each edge, even when neither signal toggles.

Four sampled combinations and their obligations
VALID	READY	Meaning	Next-cycle obligation
0	0	Idle or both sides unavailable	Neither endpoint commits a beat.
0	1	Destination is ready early	Source may offer later; no transfer has occurred.
1	0	Offered beat is stalled	Source holds VALID and payload stable.
1	1	Beat is accepted	Both sides may advance after this edge.

Prove persistence, not merely coincidence

A useful assertion starts when an offered beat is not accepted and checks the next sampled state. Include every field that identifies or qualifies the beat, not only DATA.

Do not require payload stability after an accepted edge; a new beat may legally appear immediately.
A driver calls item_done only after acceptance, not when it first asserts VALID.
A passive monitor publishes one transaction per accepted edge and never from VALID alone.

Stall stability and accepted-beat countingsystemverilog

property p_hold_while_stalled;
  @(posedge clk) disable iff (!rst_n)
    valid && !ready |=> valid &&
      $stable({data, keep, id, last});
endproperty

assert property (p_hold_while_stalled);

always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n)
    accepted_beats <= '0;
  else if (valid && ready)
    accepted_beats <= accepted_beats + 1'b1;
end

Treat latency and forward progress as separate questions

Handshake safety can be proven locally. Eventual acceptance needs an environmental assumption, an architectural bound or a watchdog policy; otherwise READY may legally remain low forever.

Measure latency from first offer to accepted edge, and state whether the first offered cycle counts as zero or one.
Cover zero-wait acceptance, long stalls, READY toggling before VALID and continuous throughput.
Use a skid buffer when a registered READY path needs one-beat elasticity; verify occupancy, bypass, stall stability and no loss or duplication.

Explain it out loud

Interview reasoning checkpoints

Strong answer

Yes. A destination may assert READY whenever it has capacity. No transfer occurs until VALID and READY are sampled high together.

Reason it through

READY describes destination capacity, not a request.
Early READY permits a zero-wait transfer when VALID arrives.
The prohibited dependency is the source waiting for READY before asserting VALID, because two waiting endpoints can deadlock.

Interviewer lens

This tests whether the candidate understands independent endpoint ownership rather than memorizing one preferred waveform.

Common trap

Calling READY-before-VALID a protocol violation or counting it as an empty transaction.

Strong answer

No. Once VALID advertises a beat, the source must preserve VALID and its payload until an edge accepts that beat.

Reason it through

The destination is allowed to sample on any later edge where it raises READY.
Changing or withdrawing the offer makes the observed transaction phase-dependent.
After the accepted edge, the source may deassert VALID or replace the payload with the next beat.

Interviewer lens

Interviewers use this to expose off-by-one drivers and pipelines that advance their source pointer too early.

Common trap

Holding DATA but dropping VALID, or holding VALID while changing LAST, ID, KEEP or another qualifier.

Strong answer

Not by itself. The handshake defines safe acceptance; eventual READY needs a system-level fairness assumption, service bound or timeout policy.

Reason it through

The destination may apply indefinite backpressure unless the surrounding specification forbids it.
A liveness property must encode the relevant assumption or architectural bound.
Age monitors and latency coverage reveal starvation without confusing a long legal stall with data corruption.

Interviewer lens

This distinguishes protocol safety from forward-progress reasoning.

Common trap

Writing an unconditional bounded-response assertion that fails legal backpressure or silently assuming fairness.

02 · Deliberately unpipelined

APB verification is a phase machine, not just a PREADY check.

Every transfer uses a SETUP cycle followed by one or more ACCESS cycles, with request information frozen while a peripheral extends the transfer.

Rule to say firstSETUP is PSEL && !PENABLE. ACCESS is PSEL && PENABLE. Completion occurs only when PSEL && PENABLE && PREADY are sampled high.

APB lifecycle

Wait states extend ACCESS; they never create a second SETUP.

Cycle

C0C1C2C3C4

PSEL

01111 or 0

PENABLE

00110

PREADY

——01—

Phase

IDLESETUPACCESSCOMPLETESETUP or IDLE

01IdlePSEL=0
No peripheral transfer is selected.
02SetupPSEL=1 · PENABLE=0
Address, direction and write information become valid.
03AccessPSEL=1 · PENABLE=1
The selected peripheral evaluates the request.
04WaitPREADY=0
ACCESS repeats and every request field remains stable.
05CompletePREADY=1
Read data or error is sampled on this ACCESS edge.

IdlePSEL=0

No peripheral transfer is selected.

Minimum length: 2 cycles; One SETUP plus one completing ACCESS.
Wait behavior: Hold request; PREADY low extends ACCESS with stable controls.
Response sample: Completion edge; PRDATA and PSLVERR matter when PREADY is high.
Back-to-back: New SETUP; The next transfer returns PENABLE low for one cycle.

APB is intentionally simple and unpipelined. A peripheral can add any required ACCESS wait cycles, but it cannot remove the SETUP phase or ask the master to change a request mid-transfer.

Observe

Track PSEL, PENABLE, PREADY, address, direction, write data, strobes, protection and response at each edge.

Decide

Model IDLE, SETUP and ACCESS explicitly; sample read data and errors only on the completing ACCESS edge.

Failure

A master skips SETUP, changes controls during a wait, drops PSEL early or treats a wait-state response as complete.

Prove

Assert legal phase transitions and wait-state stability, publish only completed transfers and cover no-wait, multi-wait, error and back-to-back accesses.

Verify the state machine at sampled edges

A monitor should create a pending transaction in SETUP and publish it only when ACCESS completes. Keeping those two events separate makes waits, errors and back-to-back traffic unambiguous.

APB phase ownership
Phase	Required signals	What may change next
IDLE	PSEL low	A selected transfer may enter SETUP.
SETUP	PSEL high, PENABLE low, request valid	Next cycle must enter ACCESS for that request.
ACCESS wait	PSEL and PENABLE high, PREADY low	Only the peripheral response may progress; request stays stable.
ACCESS complete	PSEL, PENABLE and PREADY high	Next cycle is IDLE or a new SETUP.

Bind checks to waits and phase transitions

The most valuable APB properties target errors that directed software-style accesses rarely expose: skipped setup, unstable controls and an early select drop.

Parameterize optional APB4/APB5 fields rather than assuming every interface has PSTRB or PPROT.
Check the selected-slave vector is legal for the integration topology.
Do not sample PSLVERR on an arbitrary wait cycle; qualify it with transfer completion.

APB setup and wait-state propertiessystemverilog

property p_setup_enters_access;
  @(posedge PCLK) disable iff (!PRESETn)
    PSEL && !PENABLE |=>
      PSEL && PENABLE &&
      $stable({PSEL, PADDR, PWRITE, PWDATA, PSTRB, PPROT});
endproperty

property p_hold_during_wait;
  @(posedge PCLK) disable iff (!PRESETn)
    PSEL && PENABLE && !PREADY |=>
      PSEL && PENABLE &&
      $stable({PSEL, PADDR, PWRITE, PWDATA, PSTRB, PPROT});
endproperty

assert property (p_setup_enters_access);
assert property (p_hold_during_wait);

Make the agent reusable without hiding the protocol

An active agent drives phase-accurate transfers and models configurable waits on the peripheral side. A passive monitor remains the source of truth for scoreboards and coverage.

Randomize zero and long waits, reads and writes, back-to-back slave changes, byte strobes, protection attributes and errors.
Publish a transaction only after completion so coverage never counts attempted accesses.
For a bridge, compare one upstream request with one completed APB transfer and map the APB error into the upstream response.

Explain it out loud

Interview reasoning checkpoints

Strong answer

During an ACCESS wait, the master keeps PSEL, PENABLE and the complete request—address, direction and write-side attributes—stable until completion.

Reason it through

The peripheral is extending one transfer, not requesting a replacement.
Changing the request would make the eventual response ambiguous.
A monitor should retain one pending object across all wait cycles.

Interviewer lens

This tests sampled protocol ownership and whether the candidate can write a meaningful stability assertion.

Common trap

Checking only PADDR while allowing PWRITE, PWDATA, PSTRB, PPROT or the selected peripheral to change.

Strong answer

No. After one ACCESS completes, the next transfer uses a fresh SETUP cycle with PENABLE low, even if PSEL remains asserted.

Reason it through

SETUP identifies the next request and gives the peripheral a distinct phase boundary.
PSEL may remain high when the next transfer targets the same peripheral.
The transition is ACCESS → SETUP, not ACCESS → ACCESS for a new request.

Interviewer lens

The question reveals implementations that mistake a held select for a continuously pipelined bus.

Common trap

Toggling address while PENABLE remains high and calling it a new APB transaction.

Strong answer

PSLVERR is consumed with the final ACCESS cycle, when PSEL, PENABLE and PREADY are all high.

Reason it through

Wait cycles have not completed the transfer.
The master samples read data and the error result at the completion boundary.
A scoreboard records the response once, alongside the completed request.

Interviewer lens

This tests whether the candidate qualifies response signals with the real transaction event.

Common trap

Reporting an error seen during a wait cycle or forgetting that a completed error is still a completed transfer.

03 · Overlapped phases

AHB pipelines addresses and data, so the monitor must remember history.

The address and control phase of transfer N+1 can overlap the data phase of transfer N; HREADY determines when the current data phase and the next address acceptance may advance.

Rule to say firstAssociate each data phase with the previously accepted address/control phase. When HREADY is low, extend that data phase and do not accept a replacement address phase.

AHB phase pipeline

Address N+1 overlaps data N until HREADY stretches the pipeline.

Cycle

C0C1C2C3C4

Address/control

A0A1A2A2 heldA2 accepted

A1 was accepted before the wait. The following address A2 is presented, then held until HREADY permits acceptance.

Data phase

—D0D1D1 heldD1 completes

Each data phase is owned by an earlier address phase.

HREADY

11001

Monitor action

Accept A0Complete D0 + accept A1Hold D1 / A2Hold D1 / A2Complete D1 + accept A2

01Address NNONSEQ
Capture HADDR and controls when the prior transfer permits advance.
02Data NHWDATA / HRDATA
The payload belongs to the preceding accepted address phase.
03Address N+1SEQ or NONSEQ
The next address may overlap data N.
04WaitHREADY=0
Data N remains active and the address/control pipeline cannot advance.
05CompleteHREADY=1
Sample data and HRESP, then promote the accepted next phase.

Address NNONSEQ

Capture HADDR and controls when the prior transfer permits advance.

Pipeline: Address ahead of data; Current bus fields do not all describe one transfer.
Advance: HREADY high; Completion releases the phase pipeline.
Valid transfer: NONSEQ / SEQ; IDLE and BUSY do not create data transactions.
AHB-Lite: Single manager; The subset removes multi-manager arbitration complexity.

AHB performance comes from overlapping phases rather than independent AXI-style channels. A checker must retain accepted address/control information until its later data phase completes.

Observe

Track HTRANS, HADDR and controls at accepted address phases, then pair HWDATA or HRDATA and HRESP at the corresponding completed data phase.

Decide

Use a one-entry phase pipeline or queue, with explicit handling for IDLE, BUSY, NONSEQ and SEQ.

Failure

A monitor pairs current-cycle address and data, advances through an HREADY stall or treats BUSY/IDLE as real transfers.

Prove

Assert control and write-data stability through waits, compare completed transfers and cover bursts, inserted BUSY cycles, wait states, errors and bridge backpressure.

Decode HTRANS before creating a transaction

HTRANS distinguishes real address phases from bus occupancy. NONSEQ starts a transfer or burst, SEQ continues a burst, BUSY preserves burst ownership without transferring data, and IDLE carries no transfer.

On a dedicated subordinate port, accept an address phase only when HSEL && HREADY && HTRANS[1] is true.
A bus-wide monitor must apply the interconnect decode that identifies the selected subordinate; a manager-side global interface can document selection as implicit.
Retain the accepted address, control, and selection context until its later data phase completes.

HTRANS intent
HTRANS	Meaning	Monitor behavior
IDLE	No transfer required	Do not enqueue a request.
BUSY	Manager pauses within a burst	Preserve burst context but do not enqueue data.
NONSEQ	First or standalone transfer	Capture address/control when accepted.
SEQ	Following transfer in a burst	Capture and validate burst progression.

Let HREADY own phase advancement

HREADY reports completion of the active data phase and qualifies when address/control can advance. Integration logic commonly combines a selected subordinate's HREADYOUT into the bus-level HREADY seen by the manager.

Hold write data stable through an extended write data phase.
Treat read data as valid for sampling on the completing edge.
Sample HRESP with completion. In AHB-Lite, ERROR is a two-cycle response: first HRESP=ERROR with HREADYOUT low, then HRESP=ERROR with HREADYOUT high so the manager can cancel the following transfer.
Check HSIZE, address alignment, HBURST progression and lane placement as well as the handshake.

Bridge AHB into one APB transfer at a time

An AHB-to-APB bridge captures the accepted AHB address/control phase, later captures or supplies its data phase, emits APB SETUP and ACCESS, and holds the upstream AHB transfer until the APB result is available.

Apply backpressure upstream while APB waits.
Do not pair current AHB address with current AHB write data.
Inject APB waits and errors while sending consecutive AHB requests.

Bridge responsibility chain
Boundary	State retained	Proof target
AHB address acceptance	Address, size, direction and controls	Exactly one legal upstream request is captured.
APB SETUP	Translated peripheral request	Correct decode and field mapping.
APB ACCESS	Stable request through waits	No early upstream completion.
AHB response	Read data or mapped error	One response corresponds to the captured request.

Explain it out loud

Interview reasoning checkpoints

Strong answer

Because AHB pipelines them. The current data phase normally belongs to the previously accepted address/control phase.

Reason it through

The next address phase overlaps the active data phase.
HREADY can stretch that data phase for multiple cycles.
The monitor therefore needs retained phase state rather than one same-cycle sample.

Interviewer lens

This is the central AHB observation problem and a frequent bridge-checker bug.

Common trap

Building a transaction from every signal visible in one clock column.

Strong answer

HREADY is the bus-level completion seen by the manager and all phase logic. A selected subordinate drives its own HREADYOUT, which interconnect logic contributes to HREADY.

Reason it through

The selected subordinate controls completion of its active data phase.
Bus-level HREADY also qualifies address/control advancement.
A block-level checker may see both signals, but their ownership and scope differ.

Interviewer lens

The distinction tests whether the candidate understands an integrated AHB bus rather than only a subordinate port.

Common trap

Treating HREADYOUT as an unrelated ready signal or using it without accounting for subordinate selection.

Strong answer

AHB-Lite is the single-manager subset, so it removes multi-manager arbitration while retaining the pipelined address/data transfer model.

Reason it through

The address, data, HTRANS and HREADY reasoning still applies.
A single manager simplifies ownership and interconnect control.
Optional features remain version- and implementation-dependent and should be taken from the interface specification.

Interviewer lens

This checks whether the candidate can identify the defining architectural simplification without claiming the bus becomes APB-like.

Common trap

Saying AHB-Lite is unpipelined or has no bursts simply because it has one manager.

Ready/valid, APB, and AHB contracts

One offer can wait for several cycles but transfers exactly once.

Observe

Decide

Failure

Prove

Separate an offer, a stall and an accepted beat

Prove persistence, not merely coincidence

Treat latency and forward progress as separate questions

01Is READY allowed to assert before VALID?−

02May a source drop VALID if READY stays low?+

03Does ready/valid guarantee that every offered beat eventually transfers?+

Wait states extend ACCESS; they never create a second SETUP.

Observe

Decide

Failure

Prove

Verify the state machine at sampled edges

Bind checks to waits and phase transitions

Make the agent reusable without hiding the protocol

01What must remain stable while PREADY is low?−

02Can APB remain in ACCESS for a back-to-back transfer?+

03When is PSLVERR meaningful?+

Address N+1 overlaps data N until HREADY stretches the pipeline.

Observe

Decide

Failure

Prove

Decode HTRANS before creating a transaction

Let HREADY own phase advancement

Bridge AHB into one APB transfer at a time

01Why can an AHB monitor not combine the current address and current data?−

02How should a checker think about HREADY and HREADYOUT?+

03What does AHB-Lite remove compared with full AHB?+