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.

Must AXI write address arrive before write data?

No. AW and W are independent channels, so write data may be accepted before, after or with the write address. Each channel has its own VALID/READY handshake. A subordinate or interconnect retains enough state to associate the accepted components legally. The write response waits for both the address and the final data beat.

May a subordinate wait for BREADY before asserting BVALID?

No. As the response source, it asserts BVALID when the response is available and holds it until BREADY accepts it. VALID ownership always belongs to the source of that channel. Waiting for READY can create a circular dependency. BRESP must remain stable while BVALID is stalled.

Why split channel monitors from the AXI transaction scoreboard?

Channel monitors preserve independent handshake truth, while the transaction scoreboard joins those events using AXI’s explicit dependencies, IDs and beat rules. Local monitors can report payload stability and channel timing precisely. A transaction assembler can tolerate legal channel reordering. The scoreboard remains focused on end-to-end data, response and ordering correctness.

If AxLEN is 7, how many beats are in the burst?

Eight. AXI encodes the burst length as beats minus one, so the count is AxLEN + 1. Accepted beat indices run from zero through AxLEN. LAST must coincide with accepted index AxLEN. Wait cycles do not increment the index.

When should a checker detect a burst crossing 4 KiB?

At address acceptance, because AxADDR, AxLEN, AxSIZE and AxBURST already determine the complete transfer window. The rule concerns the whole burst, not a later data-channel surprise. Early detection gives a precise request-side error. Boundary-adjacent starts and unaligned first beats need arithmetic based on actual transferred byte addresses.

What happens if a LAST beat is stalled?

It remains the same final beat. VALID, LAST and the rest of the payload stay stable until READY accepts it. LAST is a payload qualifier on W and R. The burst does not finish merely because LAST is visible. Completion state advances only on the LAST handshake.

Can responses for different AXI IDs return out of request order?

Yes. Different IDs allow independent ordering domains, so a later request on another ID can complete first. The response ID associates the result with its request stream. A global FIFO would report a false failure. The scoreboard still checks data, response, beat count and legal routing.

Can two same-ID responses simply be matched by associative lookup?

Not if that lookup ignores order. Same-ID transactions in the applicable ordering domain must be compared in the required order, normally through a queue. Both transactions share the same visible identifier. Returning the second first can violate the protocol even if its data matches. The checker needs both association and order, not one of them.

Why might an interconnect extend an AXI ID?

It can append manager identity or routing context so overlapping source IDs remain unique inside the merged fabric, then remove that extension on the response path. Two managers may legally issue the same local ID. The subordinate-facing ID must retain enough context to return each response correctly. Verification checks extension, routing, ordering and restoration together.

Is a commercial protocol checker enough to verify an interface?

No. It is valuable for signal-level legality, but the environment still needs independent transaction reconstruction, functional prediction, data and ordering comparison, coverage and progress checks. Legal bus activity can carry wrong data or target the wrong destination. A local checker does not necessarily understand the product's reset, timeout, QoS or end-to-end contract. Coverage must show the required scenarios actually occurred.

Should coverage sample an offered transfer or an accepted transfer?

Sample architectural transaction coverage on acceptance or completion. Offered traffic can be useful stimulus coverage, but it must be labeled separately. A stalled offer has not changed architectural state. Counting it every cycle inflates bins and duplicates one transaction. Phase-specific coverage may intentionally observe attempts, waits and retries as separate events.

What is the fastest way to debug a protocol scoreboard mismatch?

Start at accepted events: verify the monitor's sampled handshake and retained state, then check association and ordering before investigating payload prediction. A wrong transaction boundary corrupts every downstream comparison. Channel or phase history often explains apparent data mismatches. Stable transaction IDs, beat indices and timestamps connect assertion failures to scoreboard entries.

Sampled transfers to system-level proof

AXI, APB, AHB & Ready/Valid Verification

Learn how to verify ready/valid flow control, APB, AHB and AXI with precise handshake rules, protocol assertions, transaction scoreboards and coverage.

Follow each transaction from a sampled handshake through wait states, bursts, IDs, responses and end-to-end checking—then practice the exact failure modes interviewers use.

32 direct practice links7 connected chaptersReviewed July 2026

Protocol analyzerCount accepted edges, not busy-looking cycles.

Sampled edge

C0 · offerVALID=1 · READY=0

Beat A is visible, but no transfer occurs at this sampled edge.

Question-first preparation

Start with a curated practice sequence.

Begin with one representative question from each mechanism, then expand the complete directory when you need a targeted drill. Premium status is shown before you leave this guide.

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.32 questions

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

One transaction · four proof boundaries

Follow acceptance before you reason about completion.

A protocol transaction becomes trustworthy only when the verifier can connect the sampled signal event to reconstructed state, legal association, and an end-to-end result.

01Sample
Identify the exact edge that accepts work.
02Reconstruct
Retain phases, beats, IDs, and waits without inventing events.
03Associate
Reconnect independent channels only through legal dependencies.
04Close
Prove data, ordering, progress, reset, and zero outstanding work.

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.

04 · Five independent handshakes

AXI verification must preserve channel independence and transaction dependencies.

AXI separates read address, read data, write address, write data and write response traffic so each channel can stall independently while the transaction remains coherent.

Rule to say firstTreat AW, W, B, AR and R as separate ready/valid channels. Reconnect them only through explicit transaction rules—not same-cycle assumptions.

AXI transaction ledger

Independent channel events converge at explicit completion gates.

Write address

offerstallaccept——

Write data

accept beat 0accept last———

Write response

blockedblockedeligibleBVALIDaccept

Read path

AR acceptR beat 0stallR lastcomplete

01AWWrite address
Address and attributes transfer whenever AWVALID && AWREADY.
02WWrite data beats
Data may arrive before or after AW; accepted WLAST closes the stream.
03B gateAW seen ∧ final W seen
The write response becomes eligible only after both dependencies.
04BWrite response
BVALID persists independently until BREADY accepts it.
05AR → RRead request to beats
An accepted read address creates a response stream ending in RLAST.

AWWrite address

Address and attributes transfer whenever AWVALID && AWREADY.

Channels: 5; AW, W, B, AR and R each own a handshake.
AW versus W: Either order; A legal monitor cannot require same-cycle arrival.
Write completion: AW + WLAST + B; The response depends on both accepted request components.
Stall rule: Per channel; VALID and payload persist independently on every channel.

Channel independence improves concurrency but moves complexity into bookkeeping. Verification needs one local handshake checker per channel and one transaction-level model that joins the legal dependencies.

Observe

Record every channel handshake independently, including IDs, attributes, beat counts, LAST and responses.

Decide

Maintain channel-local state plus a transaction ledger that expresses dependencies such as AW accepted and final W accepted before B.

Failure

A design couples AW to W, changes payload under stall, emits B too early or a monitor loses transactions when channels arrive in an unexpected order.

Prove

Bind ready/valid properties to all channels, reconcile channel events in a scoreboard and cover every arrival order, independent stall pattern and outstanding depth.

Give every channel its own monitor state

The five channels use the same ready/valid contract but carry different roles. A robust monitor observes them independently before a transaction assembler or scoreboard joins related events.

AXI channel responsibilities
Channel	Direction	Transaction role	Key terminal event
AW	Manager → subordinate	Write address and attributes	AW handshake
W	Manager → subordinate	Write data and byte strobes	Accepted WLAST beat
B	Subordinate → manager	Write completion response	B handshake
AR	Manager → subordinate	Read address and attributes	AR handshake
R	Subordinate → manager	Read data and response	Accepted RLAST beat

Encode the write-response dependency explicitly

For AXI4 and AXI5, a subordinate issues a write response only after the write address and the final write data beat have both been accepted. The example below illustrates one-outstanding bookkeeping; multi-outstanding designs need queues keyed by the architectural association.

Do not make BVALID combinationally dependent on BREADY.
Do not infer AW/W order from waveform habit; test W-first, AW-first and simultaneous acceptance.
This one-outstanding ledger must reject a second AW, a second terminal W beat, or same-cycle response turnover unless the implementation explicitly adds queueing for those cases.
AXI4 removed WID and write-data interleaving. Write-data bursts remain associated in AW transaction order even though an individual W burst may begin before its AW handshake.
A multi-outstanding checker can keep ordered AW and completed-W-burst queues, then join their fronts; independent channel timing does not permit arbitrary address/data pairing.

One-outstanding write dependency ledgersystemverilog

always_ff @(posedge ACLK or negedge ARESETn) begin
  if (!ARESETn) begin
    aw_seen    <= 1'b0;
    wlast_seen <= 1'b0;
  end else begin
    if (AWVALID && AWREADY) aw_seen    <= 1'b1;
    if (WVALID  && WREADY && WLAST)
      wlast_seen <= 1'b1;
    if (BVALID && BREADY) begin
      aw_seen    <= 1'b0;
      wlast_seen <= 1'b0;
    end
  end
end

assert property (@(posedge ACLK) disable iff (!ARESETn)
  BVALID |-> aw_seen && wlast_seen);

assert property (@(posedge ACLK) disable iff (!ARESETn)
  AWVALID && AWREADY |-> !aw_seen);

assert property (@(posedge ACLK) disable iff (!ARESETn)
  WVALID && WREADY && WLAST |-> !wlast_seen);

assert property (@(posedge ACLK) disable iff (!ARESETn)
  BVALID && !BREADY |=> BVALID && $stable(BRESP));

Use reset to terminate protocol obligations deliberately

Reset clears interface VALID state and local channel trackers, but a system-level environment must also decide what happens to already accepted work beyond the reset boundary.

Flush or epoch-tag expected transactions according to the architectural reset scope.
Reject unmatched late responses rather than allowing them to alias a newly reused ID.
Randomize reset during every channel stall and between dependent write events.
After release, verify all output VALID signals start from the required reset state before new traffic begins.

Explain it out loud

Interview reasoning checkpoints

Strong answer

No. AW and W are independent channels, so write data may be accepted before, after or with the write address.

Reason it through

Each channel has its own VALID/READY handshake.
A subordinate or interconnect retains enough state to associate the accepted components legally.
The write response waits for both the address and the final data beat.

Interviewer lens

This exposes testbenches that accidentally constrain AXI into a simpler same-cycle protocol.

Common trap

Writing a monitor or slave driver that ignores WVALID until AW has already handshaken.

Strong answer

No. As the response source, it asserts BVALID when the response is available and holds it until BREADY accepts it.

Reason it through

VALID ownership always belongs to the source of that channel.
Waiting for READY can create a circular dependency.
BRESP must remain stable while BVALID is stalled.

Interviewer lens

The question checks whether the candidate applies the same handshake rule consistently in the reverse direction.

Common trap

Remembering the manager-side VALID rules but treating response channels as special.

Strong answer

Channel monitors preserve independent handshake truth, while the transaction scoreboard joins those events using AXI’s explicit dependencies, IDs and beat rules.

Reason it through

Local monitors can report payload stability and channel timing precisely.
A transaction assembler can tolerate legal channel reordering.
The scoreboard remains focused on end-to-end data, response and ordering correctness.

Interviewer lens

This tests verification architecture, not only protocol memorization.

Common trap

One monolithic monitor that assumes a fixed AW/W/B sequence and silently misses unusual but legal timing.

05 · Address arithmetic becomes protocol state

A burst is one request with a beat-by-beat proof obligation.

At address acceptance, the verifier can derive beat count, bytes per beat, legal addresses, byte lanes, terminal beat and 4 KiB legality before any data arrives.

Rule to say firstBeats = AxLEN + 1 and bytes per beat = 2^AxSIZE. Advance state only on accepted data beats, and require LAST exactly on the final accepted beat.

INCR burst derivation

Derive the complete legal window before accepting beat zero.

Accepted beat

0123complete

INCR address

startaligned + B+ 2B+ 3B—

B is bytes per beat; the first beat may be unaligned.

LAST

0001—

Stall effect

holdholdholdholdnone

A cycle without handshake never advances the ledger.

01AddressAxADDR
Record the first transfer address and its 4 KiB page.
02ShapeLEN + SIZE + BURST
Compute beat count, bytes per beat and address progression.
03Boundary gateSame 4 KiB region
Reject a burst whose highest transferred byte enters another 4 KiB block.
04Beat ledger0 … AxLEN
Advance the index only on a data-channel handshake.
05TerminalLAST at final beat
Exactly one accepted beat closes the burst.

AddressAxADDR

Record the first transfer address and its 4 KiB page.

Beat count: AxLEN + 1; LEN is encoded as beats minus one.
Beat width: 2^AxSIZE bytes; Bus width can be larger than the requested transfer.
Boundary: 4 KiB; No single burst may cross the address boundary.
Terminal: WLAST / RLAST; LAST aligns with the final accepted beat.

The burst request is a compact program for the following data stream. A predictor should expand it once, then use accepted-beat events to compare the actual stream.

Observe

Capture AxADDR, AxLEN, AxSIZE, AxBURST, ID and attributes, then count only W or R handshakes.

Decide

Precompute the legal beat sequence, byte-lane mask, wrap boundary and final-beat index for each accepted request.

Failure

LAST is early or late, an address crosses 4 KiB, a narrow or unaligned transfer uses illegal lanes, or wait cycles are counted as beats.

Prove

Compare every accepted beat with the derived model, assert terminal placement and cover burst type, length, alignment, stalls, lanes and boundary-adjacent starts.

Calculate from the address request, not the waveform

For an INCR burst, align the start down to the transfer size for subsequent address progression. The first beat may use only the legal lanes at or above an unaligned start address.

beats = AxLEN + 1
bytes_per_beat = 1 << AxSIZE
aligned_start = floor(AxADDR / bytes_per_beat) × bytes_per_beat
For INCR, last_byte = aligned_start + beats × bytes_per_beat − 1; compare the first and last byte's upper address bits for the 4 KiB rule.
For WRAP, derive the wrap span from beats × bytes_per_beat and enforce the protocol's legal lengths and alignment.

Burst-type model
AxBURST	Address behavior	Key checks
FIXED	Every beat uses the same address	Length limit, lane legality and terminal beat.
INCR	Address advances by bytes per beat	Alignment progression and 4 KiB boundary.
WRAP	INCR progression wraps within a fixed span	Legal length, alignment and wrap boundary.

Count accepted beats and validate LAST on that event

VALID cycles are not beats when READY is low. The terminal rule therefore belongs inside the handshake branch, where the accepted index and observed LAST are compared together.

The snippet shows one stream; a complete checker associates burst state according to the interface's outstanding and ordering rules.
Apply the same accepted-beat discipline to RLAST.
Keep LAST stable with the rest of the payload during a stall.

Accepted-beat terminal checksystemverilog

always_ff @(posedge ACLK or negedge ARESETn) begin
  if (!ARESETn) begin
    beat_index <= '0;
  end else if (WVALID && WREADY) begin
    assert (WLAST == (beat_index == expected_beats - 1));

    if (WLAST)
      beat_index <= '0;
    else
      beat_index <= beat_index + 1'b1;
  end
end

assert property (@(posedge ACLK) disable iff (!ARESETn)
  WVALID && !WREADY |=>
    WVALID && $stable({WDATA, WSTRB, WLAST}));

Check byte lanes as data semantics

A correct address sequence can still corrupt memory if WSTRB marks illegal lanes or if a narrow transfer is shifted incorrectly. Model the lane mask for each beat and compare final memory effects.

Cross transfer size with address offset, bus width, burst type and WSTRB pattern.
Exercise unaligned first beats and boundary-adjacent legal and illegal bursts.
Distinguish a protocol-legal strobe pattern from the product's narrower functional constraints.
For reads, compare only bytes architecturally transferred and interpret response errors per beat.

Explain it out loud

Interview reasoning checkpoints

Strong answer

Eight. AXI encodes the burst length as beats minus one, so the count is AxLEN + 1.

Reason it through

Accepted beat indices run from zero through AxLEN.
LAST must coincide with accepted index AxLEN.
Wait cycles do not increment the index.

Interviewer lens

This is a small arithmetic check that often reveals off-by-one scoreboards and LAST assertions.

Common trap

Using AxLEN directly as the number of beats.

Strong answer

At address acceptance, because AxADDR, AxLEN, AxSIZE and AxBURST already determine the complete transfer window.

Reason it through

The rule concerns the whole burst, not a later data-channel surprise.
Early detection gives a precise request-side error.
Boundary-adjacent starts and unaligned first beats need arithmetic based on actual transferred byte addresses.

Interviewer lens

This tests whether the candidate derives protocol state rather than waiting for symptoms.

Common trap

Reporting the violation only when a later beat appears across the boundary.

Strong answer

It remains the same final beat. VALID, LAST and the rest of the payload stay stable until READY accepts it.

Reason it through

LAST is a payload qualifier on W and R.
The burst does not finish merely because LAST is visible.
Completion state advances only on the LAST handshake.

Interviewer lens

This combines ready/valid persistence with burst terminal semantics.

Common trap

Clearing LAST after one cycle even though the destination never accepted it.

06 · Latency tolerance without lost order

AXI scoreboards need per-ID order, not one global FIFO.

AXI permits useful concurrency and response reordering while preserving required order within the applicable ID and destination relationship.

Rule to say firstDifferent IDs may complete out of request order. Transactions with the same ID and destination retain their required order, so compare through per-ID queues or an equivalent legal-order model.

Ordering-domain explorer

Cross-ID reordering can be legal while same-ID reversal is not.

Request order

A · ID3B · ID8C · ID3——

Legal response

B · ID8A · ID3C · ID3—pass

Illegal response

C · ID3A · ID3B · ID8—same-ID reversal

Queue heads

ID3=AID8=BID3=C after Adrainempty

01Request 0ID 3 · A
Queue A at the tail of ordering domain ID 3.
02Request 1ID 8 · B
Queue B independently in ordering domain ID 8.
03Request 2ID 3 · C
C follows A in the same ID 3 queue.
04ResponseID 8 · B
B may complete before A because the IDs differ.
05ID 3 responsesA then C
The head of the ID 3 queue must complete first.

Request 0ID 3 · A

Queue A at the tail of ordering domain ID 3.

Different IDs: May reorder; Do not impose a global response FIFO.
Same ordering domain: Preserve order; Compare against the domain's queue head.
Interconnect: May extend IDs; Master identity can be appended and later removed.
End of test: Zero outstanding; Every request must resolve, abort or be accounted for.

The scoreboard should accept every architecturally legal completion order and reject only real ordering, association, duplication, loss or data errors.

Observe

Track accepted requests by channel, ID, destination, burst shape and reset epoch; observe responses with their RID or BID.

Decide

Use a queue per ordering domain, plus a transaction map when the interconnect extends, remaps or routes IDs.

Failure

A global FIFO rejects legal cross-ID reordering, or an associative lookup accidentally allows same-ID responses to reverse.

Prove

Constrain comparison to legal ordering domains, check unmatched and duplicate responses, drain all outstanding work and cover reorder depth across IDs.

Define the ordering key before choosing a data structure

An ID is part of the ordering domain, not automatically a globally unique transaction handle. The complete key depends on the manager, direction, destination and interconnect transformations.

Keep read and write response bookkeeping separate.
Use the response ID to choose a queue, then compare the queue head.
Track every beat within the selected burst before retiring the request.
Model any interconnect-added master bits and verify they are stripped on the correct return path.

What each structure proves
Structure	Use	Characteristic mistake
One global FIFO	Only a globally ordered interface	Rejects legal AXI cross-ID reordering.
Queue per ID/domain	Preserve order inside each domain	Needs a complete routing key.
Associative transaction map	Find independent outstanding work	Can hide illegal same-ID reversal if used alone.
Age or deadline map	Progress and timeout policy	Must distinguish legal latency from starvation.

Make reordering explicit in the scoreboard

The pseudocode below uses one queue for each response ordering key. A production model also retains expected beat data, responses, destination and reset epoch.

Report unknown IDs, empty-queue responses, duplicate terminal beats and missing responses separately.
Do not retire a burst until its final response beat is accepted.
If the architecture permits additional reordering within an ID, encode that exact rule rather than weakening all comparisons.

Per-ID response matching modeltext

on_request(req):
  key = {direction, manager, destination, req.id, reset_epoch}
  expected[key].push_back(predict(req))

on_response(rsp):
  key = {direction, manager, destination, rsp.id, reset_epoch}
  require expected.exists(key) and !expected[key].empty()
  exp = expected[key].front()
  compare_current_beat(exp, rsp)
  if rsp.is_last_accepted_beat:
    expected[key].pop_front()

end_of_test:
  require every expected queue is empty

Prevent reset and ID reuse from creating aliases

Reset may discard work in one scope while another fabric segment remains alive. A checker needs an explicit flush, abort or epoch policy rather than silently clearing every map.

Tag expected work with a reset epoch when late responses can remain visible.
Delay ID reuse or reject stale-epoch responses according to the product contract.
Cover maximum outstanding depth, repeated IDs, mixed destinations and long response inversions.
At end of test, classify every nonempty queue as a DUT loss, legal outstanding work or intentional reset abort.

Explain it out loud

Interview reasoning checkpoints

Strong answer

Yes. Different IDs allow independent ordering domains, so a later request on another ID can complete first.

Reason it through

The response ID associates the result with its request stream.
A global FIFO would report a false failure.
The scoreboard still checks data, response, beat count and legal routing.

Interviewer lens

This tests whether the candidate understands why AXI has IDs and how a latency-tolerant checker uses them.

Common trap

Answering that any order is legal and forgetting same-ID constraints.

Strong answer

Not if that lookup ignores order. Same-ID transactions in the applicable ordering domain must be compared in the required order, normally through a queue.

Reason it through

Both transactions share the same visible identifier.
Returning the second first can violate the protocol even if its data matches.
The checker needs both association and order, not one of them.

Interviewer lens

This exposes scoreboards that are flexible enough to accept a real DUT bug.

Common trap

Searching all expected items for any payload match and removing whichever happens to compare.

Strong answer

It can append manager identity or routing context so overlapping source IDs remain unique inside the merged fabric, then remove that extension on the response path.

Reason it through

Two managers may legally issue the same local ID.
The subordinate-facing ID must retain enough context to return each response correctly.
Verification checks extension, routing, ordering and restoration together.

Interviewer lens

This connects pin-level protocol knowledge to a multi-port interconnect implementation.

Common trap

Assuming an ID is globally unique across all managers without inspecting the fabric's transformation.

07 · From local rules to end-to-end confidence

Protocol closure needs assertions, transactions, scoreboards and coverage.

No single checker proves a bus. Local safety properties find cycle-accurate violations, while monitors, predictors, scoreboards, coverage and progress tracking prove the complete transaction lifecycle.

Rule to say firstCheck each invariant at the lowest layer that can observe it independently, then reconcile accepted transactions at the architectural boundary.

Verification evidence chain

Different tools answer different protocol questions.

01AgentsDrive legal and hostile timing
Create requests, responses, waits, backpressure, errors and resets.
02AssertionsLocal cycle rules
Check stability, sequencing, terminal beats and forbidden states.
03MonitorsAccepted transactions
Publish only architecturally completed channel or bus events.
04Predictor + scoreboardEnd-to-end result
Model data, response, ordering, routing and transaction lifetime.
05Coverage + performanceClosure evidence
Demonstrate feature combinations, stress depth and progress behavior.

AgentsDrive legal and hostile timing

Create requests, responses, waits, backpressure, errors and resets.

Assertions: Local truth; Best for sampled signal invariants.
Scoreboard: Transaction truth; Best for data, ordering and lifecycle.
Coverage: Intent evidence; Counts meaningful accepted scenarios.
Outstanding audit: Must reach zero; Loss and starvation cannot hide at test end.

A strong strategy layers independent evidence. A protocol checker can prove legal pins and still miss wrong data, a misrouted response, starvation or an expected transaction left in the scoreboard.

Observe

Inventory interfaces, optional features, ordering domains, outstanding limits, reset scopes, errors, performance targets and legal backpressure.

Decide

Partition safety into SVA, reconstruction into monitors, functional prediction into models, comparison into scoreboards and intent into coverage.

Failure

A team relies on one vendor checker, counts attempted traffic, compares in the wrong order or reaches end of test with silent outstanding work.

Prove

Trace requirements into checkers and coverage, run negative and disruption tests, audit unmatched work and trend latency, throughput and starvation evidence.

Choose the protocol that matches the architectural job

Protocol selection is a design tradeoff, and it shapes the verification problem. Preserve the implemented version and optional-feature list in configuration rather than teaching one interface as a universal superset.

Protocol intent and verification focus
Interface	Best fit	Primary verification risk
Ready/valid	A local streaming or decoupled channel	Stall persistence, throughput and buffering.
APB	Low-bandwidth registers and peripherals	SETUP/ACCESS phase legality and wait stability.
AHB/AHB-Lite	Pipelined memory-mapped transfers	Address/data phase association and HREADY stalls.
AXI4-Lite	Simple memory-mapped control without bursts	Independent channel joins despite reduced features.
AXI4/AXI5	High-throughput outstanding traffic	Bursts, channel independence, IDs, ordering and backpressure.

Partition the environment by evidence ownership

Reusable VIP separates active behavior from passive truth. Drivers honor the protocol; passive monitors independently reconstruct what the DUT actually accepted.

Use one agent per interface role, configurable as active or passive.
Publish monitor transactions only from accepted bus events.
Use a predictor or reference model independent of the DUT implementation.
Key the scoreboard by the real ordering domain and retain per-beat state.
Bind assertions close to the interface and parameterize widths and optional features.
Add age tracking for bounded requirements, fairness policies and testbench watchdogs.

Stress timing, errors and lifecycle—not only payload values

A protocol testplan should make every legal timing relationship happen and every prohibited relationship fail in a controlled negative test.

Cross channel or phase, burst type, size, alignment, ID, response, backpressure length and outstanding depth.
Inject waits and errors at the first, middle and terminal beat or phase.
Reset during every independent AXI channel, APB wait and AHB stretched data phase.
Exercise maximum throughput, long stalls, many-to-one contention and repeated ID reuse.
Track latency distributions, bandwidth, occupancy, starvation and fairness separately from correctness.
At end of test, require all monitor, predictor and scoreboard queues to be empty or explicitly classified.

Build an interview answer around mechanism and proof

A strong protocol answer starts with the sampled rule, names state ownership, identifies the failure mode and finishes with independent evidence.

Reusable answer frame
Step	Question to answer	Protocol example
Contract	What exact edge commits state?	VALID && READY, APB completion or HREADY-qualified phase.
State	What must the checker remember?	Pending offer, APB request, AHB phase or AXI burst/ID queue.
Failure	What characteristic bug appears?	Early advance, unstable wait, wrong association or illegal reorder.
Proof	Which independent evidence catches it?	SVA plus monitor, scoreboard, coverage and outstanding audit.

Explain it out loud

Interview reasoning checkpoints

Strong answer

No. It is valuable for signal-level legality, but the environment still needs independent transaction reconstruction, functional prediction, data and ordering comparison, coverage and progress checks.

Reason it through

Legal bus activity can carry wrong data or target the wrong destination.
A local checker does not necessarily understand the product's reset, timeout, QoS or end-to-end contract.
Coverage must show the required scenarios actually occurred.

Interviewer lens

This tests whether the candidate can design a complete verification strategy instead of naming a tool.

Common trap

Equating protocol compliance with functional correctness.

Strong answer

Sample architectural transaction coverage on acceptance or completion. Offered traffic can be useful stimulus coverage, but it must be labeled separately.

Reason it through

A stalled offer has not changed architectural state.
Counting it every cycle inflates bins and duplicates one transaction.
Phase-specific coverage may intentionally observe attempts, waits and retries as separate events.

Interviewer lens

This reveals whether the coverage model is tied to the real protocol event.

Common trap

Sampling whenever VALID or PSEL is high and calling every sampled cycle a transaction.

Strong answer

Start at accepted events: verify the monitor's sampled handshake and retained state, then check association and ordering before investigating payload prediction.

Reason it through

A wrong transaction boundary corrupts every downstream comparison.
Channel or phase history often explains apparent data mismatches.
Stable transaction IDs, beat indices and timestamps connect assertion failures to scoreboard entries.

Interviewer lens

This tests practical debug prioritization across waveform and transaction layers.

Common trap

Immediately changing the reference model before proving that the monitor reconstructed the bus correctly.

Standards and primary references

Check the contract at its source.

Arm AMBA AXI and ACE Protocol Specification · IHI 0022Normative AXI channel, handshake, burst, dependency, ID and ordering requirements. Confirm the revision implemented by the DUT.Arm Introduction to AMBA AXI4Arm's architecture guide to AXI channels, ready/valid transfer behavior, bursts and transaction IDs.Arm AMBA APB Protocol Specification · IHI 0024Normative APB SETUP, ACCESS, wait-state, response and optional-signal behavior.Arm AMBA AHB Protocol Specification · IHI 0033Normative AHB and AHB-Lite address/data phasing, HTRANS, HREADY, responses and burst behavior.

Continue preparing

ASIC.FYI guideSystemVerilog Assertions (SVA)

Turn handshake, stability, response and terminal-beat rules into sampled temporal properties.

ASIC.FYI guideUVM

Build reusable agents, passive monitors, predictors and scoreboards around protocol transactions.

ASIC.FYI guideCoverage and Closure

Map protocol features, timing combinations, outstanding depth and errors into meaningful closure evidence.

ASIC.FYI guideRTL Design

Connect protocol verification to skid buffers, arbiters, FIFOs, bridges and flow-controlled pipelines.

ASIC.FYI guideCDC and Reset

Handle reset interruption, clock boundaries and transaction cleanup without stale or duplicated traffic.

AXI, APB, AHB & Ready/Valid Verification

Follow acceptance before you reason about completion.

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?+

Independent channel events converge at explicit completion gates.

Observe

Decide

Failure

Prove

Give every channel its own monitor state

Encode the write-response dependency explicitly

Use reset to terminate protocol obligations deliberately

01Must AXI write address arrive before write data?−

02May a subordinate wait for BREADY before asserting BVALID?+

03Why split channel monitors from the AXI transaction scoreboard?+

Derive the complete legal window before accepting beat zero.

Observe

Decide

Failure

Prove

Calculate from the address request, not the waveform

Count accepted beats and validate LAST on that event

Check byte lanes as data semantics

01If AxLEN is 7, how many beats are in the burst?−

02When should a checker detect a burst crossing 4 KiB?+

03What happens if a LAST beat is stalled?+

Cross-ID reordering can be legal while same-ID reversal is not.

Observe

Decide

Failure

Prove

Define the ordering key before choosing a data structure

Make reordering explicit in the scoreboard

Prevent reset and ID reuse from creating aliases

01Can responses for different AXI IDs return out of request order?−

02Can two same-ID responses simply be matched by associative lookup?+

03Why might an interconnect extend an AXI ID?+

Different tools answer different protocol questions.

Observe

Decide

Failure

Prove

Choose the protocol that matches the architectural job

Partition the environment by evidence ownership

Stress timing, errors and lifecycle—not only payload values

Build an interview answer around mechanism and proof

01Is a commercial protocol checker enough to verify an interface?−

02Should coverage sample an offered transfer or an accepted transfer?+

03What is the fastest way to debug a protocol scoreboard mismatch?+