Protocols Interview Questions

AW, W and B carry writes; AR and R carry reads. The manager drives AW, W and AR, and the subordinate drives B and R. Each channel has its own valid/ready handshake. The split lets a read and a write be in flight at once. It also lets write data move independently of its address. And you can add a register slice (a pipeline stage) to any one channel alone.

Accepting a beat only means the next stage had room, not that the write reached its target or succeeded. B is the completion response, and it carries the error code. The subordinate sends it only after it has the address and the last beat. For a Non-bufferable write, B also guarantees the write is visible to any manager. A manager that needs ordering waits for B.

No. AXI never orders a read against a write, whatever the IDs, so the read may return the old value. The manager's tool is to wait for the write's B response before issuing the read. Lesson P2.12 measured exactly this, with a posted write and a six-cycle write latency. The read issued after the last data beat returned the old word.

Before writing the flag, wait for the B responses of every buffer write. Only a completion response makes an access observable. Same-ID writes stay in order only to the same location, so one ID does not order the buffer against the flag. A Bufferable B can come from a buffer partway along the path. It then guarantees observability only inside the write's Domain, so the CPU must sit in that Domain.

AXI gains concurrency: reads and writes overlap, and many transactions can be outstanding (issued but not yet finished). Each channel can also be pipelined on its own. APB is not pipelined, and every transfer takes at least two cycles. The cost is wires and logic: five handshakes, ID tracking, reorder buffers and a much harder verification job. That is why register blocks often sit on APB or AXI4-Lite.

Yes. The protocol sets no order between AW and W, so data may come before, with or after its address. The subordinate may wait for either or both VALIDs before raising either READY. But the manager must never wait for a READY before raising AWVALID or WVALID. BVALID may rise only after both the address and the last data beat (WLAST) have been accepted. It must not wait for BREADY.

Someone has to move first, or two polite blocks wait forever. The spec picks the sender: VALID may never wait for READY. READY may wait for VALID, or be high early. So every handshake makes progress as long as the sender has something to send. Receivers can also save power or logic by raising READY only on demand.

Not by itself. On the wires, the illegal manager looks legal against a subordinate that raises AWREADY early. Against a subordinate that waits for WVALID, nothing moves, and no safety property fails on a bus where nothing moves. You need a watchdog or liveness check (a VALID is eventually accepted). You also need stimulus that includes a subordinate holding AWREADY until it sees WVALID.

Put a protocol checker on every manager and subordinate port. A fabric re-registers what it forwards, so it hides a subordinate's fault from the manager side. Add an end-to-end scoreboard keyed by manager and ID that checks routing, data, ID restore and same-ID order across subordinates. Test every region edge and hole for full-length DECERR. Stress with random back-pressure (READY held low), W before AW, maximum outstanding and racing exclusives, with watchdogs for deadlock.

Hold it. The interconnect cannot know which subordinate the data belongs to until it decodes the address. So it must realign data with request, and present WVALID only to the destination. That means buffering W, or holding WREADY low, until the matching AW is decoded, in AW order. AXI4 write data carries no ID, so it follows the address order.

Beat 0 is always the start address, and FIXED repeats it. INCR adds n times the size to the start aligned down to the size. WRAP does the same inside a window of size times length bytes, aligned to that total. It returns to the window's base when it reaches the top. So WRAP4 of 4 bytes at 0x38 has window 0x30 to 0x3F and visits 0x38, 0x3C, 0x30, 0x34.

Caches issue them: on a miss, the CPU wants the word it stalled on first (critical word first). But the cache still needs the whole line. A WRAP burst starts at the missing word and wraps around the line-aligned window. So the line is filled in one transaction that never leaves it. INCR from the missing word would run past the end of the line.

Both are illegal. A WRAP burst must be 2, 4, 8 or 16 beats long, so length 3 fails. It must also start aligned to its transfer size, so 0x102 with 4-byte beats fails. A checker flags both at the request handshake, before any data moves. FIXED is limited to 16 beats, and INCR may run to 256.

The burst lives in a window of beats times bytes per beat, aligned to that size. The lowest address of the window is the wrap boundary. With a power-of-two length, hardware finds the window by masking low address bits. An aligned start keeps every beat a whole transfer inside it.

At the top of the address space. With 32-bit unsigned arithmetic, a window that ends at 2^32 makes boundary + window overflow to 0. So the test is always true, and beat 1 is pulled down a whole window. Comparing the offset, a - boundary >= window, never overflows. The twin runs both forms at 0x108 and at 0xFFFFFFF8: they agree in the middle and disagree at the top.

The interconnect routes a burst using its first address only. So a burst that crossed the boundary could run into the next subordinate. The rule also limits how many address bits a subordinate must increment. The check compares the 4 KB page of the first byte with the page of the last byte, aligned_start + beats*size - 1. Using the address one past the end wrongly flags a burst that ends exactly on the edge.

Mainly the interconnect and the subordinate. The interconnect decodes the destination once, from the first address. So the tail of a crossing burst would land in whichever subordinate owns the next page. The subordinate computes later addresses itself, and the rule limits how far its address counter has to carry. The manager is the one that must obey the rule, by splitting its bursts.

The burst covers 128 bytes, from 0xFC0 to 0x103F. Beat 9 starts at 0x1000, on the next 4 KB page. The checker should flag the request at the address handshake. The first and last byte addresses must share every bit from bit 12 up.

No, because FIXED never changes address. A WRAP burst stays inside its window, at most 16 beats of 128 bytes (2 KB) and aligned to its own size. An aligned power-of-two window of 2 KB or less cannot cross a 4 KB edge. Only INCR, up to 256 beats, can cross. The checker still needs the WRAP length and alignment rules.

Cut at every 4 KB boundary first, then at the 256-beat limit. With 8-byte beats, a burst moves at most 2 KB. So here the bursts are 0x1F40 to 0x1FFF (24 beats), then 2 KB bursts of 256 beats, then the tail. Many DMAs also stop at a smaller Max_Transaction_Bytes that the system advertises, or at cache-line multiples. An unaligned start needs a strobed first beat.

The lanes come from the address: lane = address mod bus width. The 1-byte beats walk lanes 1, 2, 3, 0 with strobes 0010, 0100, 1000, 0001. The unaligned 4-byte burst uses lanes 2 to 3 on beat 0 (strobe 1100) and all four lanes after that. WSTRB may clear any lane inside the beat's lanes, but must be low outside them.

No. AXI is byte invariant: the byte at address word+n always travels on lane n, whichever core sent it. Endianness only decides which byte of a multi-byte value goes to which address, inside each core. So the bus never swaps lanes. A core that wants the other's view of a 32-bit value reverses the bytes in software or in its own interface.

Then byte invariance breaks on that path. A single byte written to word+1 now lands at word+2. Byte-wide software breaks, and the other core reads scrambled data. Endianness belongs inside each core, never on the bus.

WSTRB 0110 is illegal. The beat addresses only lane 1, so the lane 2 strobe lies outside the transfer and must be low. WSTRB 0000 is legal: inside the beat's lanes any pattern is allowed, including none, and that beat writes nothing. A manager uses all-zero strobes to finish a burst it no longer needs, because a burst cannot end early.

The data stayed in lanes 0 and 1, while the strobes moved to lanes 2 and 3 for the odd addresses. The strobes alone are legal, so no protocol rule fires. The subordinate writes whatever sits in the strobed lanes. Only a data check catches it: a scoreboard or read-back that compares bytes by address. Lesson P2.7 measured the result: 11 11 00 00 33 33 00 00.

A Non-modifiable transaction (AxCACHE[1] low) must not be split or merged. It keeps its address, size, length and burst type. So an upsizer steers each narrow beat into the right half of the wide word and leaves size and length alone. It may pack beats only when the transaction is Modifiable. A downsizer must split anyway when Size exceeds the narrow bus, a case the spec admits cannot meet the rule.

Responses with the same ID come back in request order. Different IDs carry no ordering, so they may complete in any order. Read data of different IDs may be interleaved beat by beat. The beats of one ID are never interleaved with each other. AXI4 write data has no ID and must follow the address order. AXI3 had WID and allowed write interleaving.

A response carries only the ID. With two transactions open on one ID, the manager can pair each response with its request only by order. Ordering per ID also lets a simple manager use one ID and never build a reorder buffer. A capable manager uses several IDs as several in-order streams.

Legal: different IDs may interleave beat by beat. Each transaction's beats must still stay in order and end with its own RLAST. The monitor must assemble beats per RID and file each beat under the oldest open read of that ID. It closes the transaction on RLAST. A monitor that assumes contiguous bursts glues beats of different reads together.

Not if the manager issues different IDs: such a manager must accept interleaved data. The Read_Interleaving_Disabled property only lets it switch interleaving off as an optimisation. That works only when the attached subordinate supports it. So the test plan must cover interleaved returns for every manager that uses several IDs.

Same-ID responses must return in order, so a short read queues behind a slow one (head-of-line blocking). Give independent streams their own IDs, so the subordinate or interconnect can answer the fast one first. Keep one ID only for accesses that must stay ordered. The cost is reorder storage in the manager and more tracking downstream. Lesson P2.10 measured a fast read waiting seven edges on a shared ID, and three on its own.

The scoreboard assumes responses return in issue order. The new fabric returns different IDs out of order, which is legal. So the expected and actual streams no longer line up. Key the expected queue by ID: one in-order queue per RID, popped when that ID's beat arrives. The twin shows the in-order version reporting two mismatches on legal traffic. The per-ID version still catches a real same-ID swap.

Only when the two reads have different lengths, because the first response's RLAST then lands on the wrong beat count. If the lengths are equal, every beat is legal on the wires, and only the data shows the swap. You need a scoreboard keyed by ID that knows which address each read asked for. Lessons P2.10 and P2.18 measured exactly this split.

Group it by channel handshakes, requests, data, responses and ordering, as in the table. The corners that matter most are bursts ending exactly at 4 KB and errors mid-burst. So do maximum outstanding depth, cross-ID reordering and W before AW. Cross only the pairs the design can actually produce, and close holes with directed tests.

About latency times rate: 8 cycles times one read per cycle, so 8 in flight. Throughput is outstanding transactions (issued but not yet answered) divided by latency, which is Little's law. So one read at a time gives one beat every 8 cycles. The run shows 32 reads taking 257 cycles with a window of 1, 68 with 4 and 40 with 8. A window of 16 is no faster, because then the clock is the limit.

Legal: READY may wait for VALID. But with a registered READY (driven from a flip-flop), it costs a cycle on every request. The handshake cannot happen in the cycle VALID first appears. The spec recommends READY high by default on request channels; the subordinate must then be able to accept any request presented. Lesson P2.5 measured RREADY-after-RVALID stretching four read beats from edges 14-17 to 21, 23, 25, 27.

Each stage adds a cycle of latency in its direction. It costs no bandwidth if the slice sustains one beat per cycle. The manager must then keep enough transactions outstanding to cover the longer round trip. VALID must go through as many stages as its payload, but different channels may get different numbers of stages. Lesson P2.5 measured two stages moving a write response from edge 10 to 14.

With READY from a flop, the sender sees the stall one edge late. So one extra beat is accepted on that edge. With only one register, that beat overwrites the held beat, and data is lost. A real slice adds a skid register, so it holds two beats and still passes one per cycle.

Cover latency times rate: about 200 beats in flight at one beat per cycle. With 16-beat bursts, that is about 13 outstanding reads, rounded up for latency spread. The manager must be able to accept all data it requested. So it needs about 200 × 16 bytes of read buffering, or a sink that always accepts data. Then check what the interconnect and memory controller actually accept; their limits, not the DMA's, often set the ceiling.

OKAY means normal success, and EXOKAY means a successful exclusive access only. SLVERR means the access reached a subordinate that failed it. DECERR means no subordinate was found at the address. A write gets one response on B after its last beat. A read gets one RRESP with every beat, so a 4-beat read has four, and they may differ. An error never shortens a burst.

You cannot tell from the response. SLVERR on B covers the whole write. The spec says the location might not be fully updated, so some beats may have landed and some not. Lesson P2.13 showed a write that returned SLVERR with bytes 0a and 0b already in memory. Software treats the whole buffer as suspect.

No. The subordinate still sends all four beats, up to RLAST, and the manager takes them. Each read beat carries its own response, so beats 1, 3 and 4 may be OKAY. Only the data of beat 2 is suspect.

DECERR normally comes from the interconnect. The address decoded to no subordinate, so the access never reached a target. SLVERR comes from a subordinate that received the access and could not complete it. Examples are a write to a read-only register, or an access to a powered-down block. For debug, DECERR points at the address map; SLVERR points at the target.

Complete the transaction like any subordinate. Accept the request, and return all 16 beats with DECERR on each and RLAST on the last. Echo the ID, and obey the same handshake and ordering rules. For writes, it must accept every beat up to WLAST before one DECERR on B. A default subordinate that answers with one beat hangs a manager waiting for RLAST.

The manager does an exclusive read. A subordinate that supports exclusives records the address and ID in a monitor (a small tracker) and answers EXOKAY. Later the manager does an exclusive write with the same ID, address and attributes. If no one wrote the location meanwhile, the write happens and gets EXOKAY. Otherwise the write is dropped and gets OKAY, and software retries. The bus is never locked in between.

The exclusive read returns OKAY instead of EXOKAY: the data is valid, but nothing is monitored. If the manager writes anyway, the exclusive write also gets OKAY. The location is updated as a normal write, so a lock "fails" yet changes memory. The spec recommends treating OKAY on the read as "not supported" and skipping the write.

On a memory without an exclusive monitor, both steps return OKAY, so two cores can both believe they hold the lock. On a memory with a monitor, OKAY on the exclusive write means it failed and nothing was written. Either way, only EXOKAY means success. The routine must retry on OKAY, or report that exclusives are not supported.

Races: two managers on one address must give exactly one EXOKAY, and a normal write in between must fail the sequence. ID handling: reusing the ID on a new address moves the monitor. A size or length mismatch between the read and the write may fail the write. Granule: the monitor may watch a wide block, so a write to a neighbouring byte may legally fail the sequence. Limits: test unaligned, non-power-of-two and over-16-beat exclusives too.

An exclusive pair needs two round trips, and it can fail and retry under contention. The data also travels to the manager and back. An atomic transaction sends the operation to the data instead. The subordinate or a near-memory agent does the read-modify-write in one transaction, so the location is unavailable for less time. The cost is ALU logic at the target and a more complex protocol.

Lite keeps the five channels, the handshakes, the addresses, write strobes, AxPROT and the responses. Every transaction is one transfer at the full data width, 32 or 64 bits. So the length, size, burst, WLAST and RLAST signals go. There are no IDs and no exclusive accesses, so no EXOKAY. Accesses are Non-modifiable and Non-bufferable. It may still have several transactions outstanding.

Control and status registers never need bursts, IDs or reordering. Supporting those costs logic and verification effort. Lite keeps the subordinate very simple (one beat, in order) while staying on the AXI fabric with no protocol bridge. Full AXI is for data movers: memories, DMAs, caches.

The block must copy AWID onto BID and ARID onto RID (ID reflection), because the manager pairs responses by ID. Also, either the system guarantees that the manager issues only Lite-shaped transactions, or a bridge converts them. The bridge breaks bursts into single transfers and combines their responses. Lesson P2.15 shows what happens otherwise: a four-beat read into the Lite block breaks the RLAST rule on its first beat.

Look at what the bench never sent. Its driver issued only single, full-width, aligned transfers, so every Lite assumption held. In the SoC, the block may see bursts, narrow sizes or partial strobes. Check whether a bridge sits in front, and whether the block honours or errors on partial strobes. Then extend the bench to drive what the real manager can issue, or assert that it never does.

APB is cheaper per peripheral: one shared, non-pipelined transfer at a time, at least two cycles each. Many slow peripherals can share one bridge. AXI4-Lite costs more logic, but allows parallel reads and writes and several outstanding transactions, with no bridge hop. Pick APB for many slow, low-traffic peripherals. Pick Lite for a few registers on a fast path, or where a bridge's latency hurts.

The interconnect appends the manager port number, so subordinates see 6-bit IDs. The fabric routes BID and RID back by those bits, and strips them on the way. Across subordinates, it must keep same-ID order. If a manager sends ID 3 to subordinate A, then ID 3 to B, B's response must not overtake A's. Usually the fabric stalls the second request, or keeps a per-ID destination table. Every added bit widens subordinate tracking and exclusive monitors.

Two managers may both use ID 0. Without a port tag, their transactions would merge into one ordering stream at the subordinate. The responses also could not be routed back. Appending the port number makes every ID unique system-wide, without managers coordinating. It also gives the fabric its return address.

The SRAM would answer first, which would break same-ID order at the manager. The common design tracks the outstanding count and its destination, per manager and ID. A new request with the same ID to a different destination stalls until the earlier responses return. The alternative, a reorder buffer, costs area. Lesson P2.10 measured the stall: the second ID-5 request was held from edge 4 to edge 13.

Stalling needs only a count and a destination per manager and ID. It costs speed when one manager reuses an ID across fast and slow targets. A reorder buffer lets both requests go and holds the early response until its turn. It must store every response that can arrive early, so it costs area and design risk.

Every level adds port bits. The memory controller's per-ID state, reorder logic and exclusive monitors grow with the IDs it must tell apart. One option is to remap IDs into a smaller set of in-flight tags, which is legal if the original ordering is kept. Others are capping outstanding transactions per manager, or using the unique-ID indicator so unordered requests need no tracking. Each trades area for stalls.

Every APB transfer starts with one SETUP cycle. In it PSEL is high, PENABLE is low, and the address, direction and write data are valid. One or more ACCESS cycles follow, with PENABLE high. The transfer completes at the edge where PSEL, PENABLE and PREADY are all high. So the minimum is two cycles, and each cycle of PREADY low adds one. Afterwards the bus returns to IDLE, or goes straight to SETUP for the next transfer, with PENABLE low again.

SETUP gives the completer a full cycle with a stable address and select. Then PENABLE marks the cycle that counts. The completer can decode in SETUP and act on a single edge with very little logic. APB trades speed for that simplicity. It is not pipelined and every transfer costs at least two cycles, which is fine for occasional register traffic.

Nothing it set in SETUP: PADDR, PWRITE, PSEL, PENABLE and PPROT stay unchanged. So do PWDATA and PSTRB for a write, and any user request signals. The hold lasts from the SETUP-to-ACCESS transition until PREADY is high. The only free signal in that window is the completer's own PREADY. Any number of wait states is legal, from zero upwards.

It is not a protocol violation, because APB allows any number of wait states. "Too long" is a system property, so a protocol checker cannot call it wrong. The bench uses a watchdog instead, with a limit taken from the peripheral's documented maximum. The watchdog reports a hang when the wait reaches that limit. In formal, the same requirement is a bounded response property, or a liveness property with fairness assumptions on the completer's inputs.

A timeout is system policy, not protocol. After a programmed limit, the bridge returns SLVERR so the CPU is not stuck forever. The risk is on the APB side: the requester must hold the transfer until PREADY, so the bridge cannot legally abandon it. It either keeps that segment blocked and fails every later access, or resets the completer. Specify which, raise an interrupt, and verify that recovery path.

Every bug that keeps the wires legal can remain, because a wire checker only proves the protocol. A completer that acts in every selected cycle still obeys the handshake. So does one that returns read data one transfer late, ignores PSTRB, acts without its PSEL, or raises PSLVERR a cycle early. A register model or scoreboard that predicts data and responses catches the rest. But it needs traffic with wait states, back-to-back transfers, sparse strobes and errors.

Register traffic is rare, small and tolerant of latency, so APB's simplicity wins. It runs one transfer at a time, with no bursts and no IDs. Each peripheral needs only a tiny state machine, and there are few wires to route. One bridge pays the AXI cost once for many peripherals. The price is throughput: at least two cycles per transfer, and one slow completer stalls the whole APB segment. So blocks that move real data stay on AXI or AHB.

APB3 added wait states and errors, through PREADY and PSLVERR. APB4 added protection and sparse writes, through PPROT and PSTRB. APB5 added wake-up signalling, user signals and parity protection. The current issue also adds Realm Management Extension support as an option. An APB2 completer has neither PREADY nor PSLVERR, so a bridge ties them off for it.

Every access behind that bridge waits, because APB carries one transfer at a time and nothing starts until the waiting one completes. One fix is to give the slow peripheral its own APB segment or bridge. Another is to make it answer at once with a busy bit that software polls. A third is posted writes: the bridge answers before APB finishes, so it loses PSLVERR for those writes. Pick by the latency budget of the time-critical peripherals.

The bridge is the AXI subordinate and the APB requester. It decodes PSELx and makes one APB transfer per AXI beat. Each transfer uses the aligned address, with WSTRB on PSTRB and AxPROT on PPROT. It maps PSLVERR to SLVERR: per beat in RRESP, and merged into the single BRESP. Your decisions are read/write arbitration, DECERR for unmapped addresses, a timeout policy and posted writes. Verify it with checkers on both sides and an end-to-end scoreboard.

Decode first, and answer DECERR without starting any APB transfer, because APB itself defines no decode error. With no PSELx asserted, nobody drives PREADY. So a transfer started to a hole never completes, unless a default responder answers it. DECERR also tells software that the address was wrong. SLVERR would instead suggest that a peripheral refused it.

The bridge maps PSLVERR to SLVERR, in the RRESP of the failing beat for a read and in BRESP for a write. A write has one completion response for the whole transaction. So the bridge must merge four APB results into one BRESP. Reporting SLVERR if any beat failed is the usual choice. The remaining beats still run: AXI never shortens a burst, and every read beat is returned whatever its response.

Protocol checkers on both ports catch rule breaks. An end-to-end scoreboard predicts the APB transfers (one per beat, with address, PSTRB and PPROT) and the AXI responses. Done means every check passes and the coverage model is closed. That model crosses burst type, length and size with unaligned and narrow beats and wait states. It also covers PSLVERR on the first, middle and last beat, unmapped addresses, and reads racing writes.

Check that each refused access errors: a write to read-only, an unmapped offset, or a wrong size or protection. Check that PSLVERR is read only at completion, and that register state after a failed write matches the documented policy. Cover read and write, crossed with error or not, crossed with zero, one and many wait states. Also cover an error followed straight by a good transfer to the same completer. Then check the error reaches software through the bridge.

At the edge where the read data is taken. PRDATA needs to be valid only at the completion edge, where PSEL, PENABLE and PREADY are all high. So a sampler at the first ACCESS edge reads data that is not ready yet. Zero-wait peripherals hide the bug, because their first ACCESS edge is the completion edge. Capture only when PREADY is high too, and run every regression with wait states.

It publishes once per transfer, at the edge where PSEL, PENABLE and PREADY are all high. Only then are PRDATA and PSLVERR valid. The item carries the address, direction, PPROT, PWDATA and PSTRB, all stable since SETUP. It also carries PRDATA or the error at completion, and the wait count: the ACCESS cycles with PREADY low. Sampling through a clocking block keeps the monitor free of races with the DUT.

PSLVERR counts only in the last cycle of the transfer, where PSEL, PENABLE and PREADY are all high. Elsewhere it is ignored, and driving it low there is only a recommendation. It says the transfer failed, not what happened inside. A failed write may or may not have changed the register. A failed read may return data that the requester still uses. PSLVERR is optional; without it the requester's input is tied low.

Completers differ, and the specification keeps them cheap. Some decide the error only after part of the access has taken effect; others refuse cleanly. Forcing "no side effect on error" would add buffering to every peripheral. So the error reports failure only. The register's behaviour on error belongs in the peripheral's documentation and its register model.

Then the mirror holds a value the register may not have. The next read check fails on a correct design, or passes on a wrong one. The adapter should return UVM_NOT_OK, so the model skips predicting that access. Then read the register back to learn what the peripheral really did.

Every transfer has an address phase of one cycle and a data phase of one or more cycles. The next transfer's address phase happens during the current transfer's data phase. With no wait states, the bus finishes one transfer per cycle. Each transfer still takes two cycles from address to data. So write data trails its address by a cycle. At most two transfers are on the bus at once: one in address, one in data.

It gains a full cycle between seeing the address and having to produce or take the data. That is time to decode and start a memory access. Meanwhile the bus still completes one transfer per cycle. Without the overlap, a bus must halve its throughput. Or it must force every subordinate to answer in the same cycle it sees the address.

The bus is pipelined. When a subordinate starts an ERROR, the next transfer's address phase is already on the bus. The first cycle (HRESP high, HREADYOUT low) holds that address phase and warns the manager. In the second cycle (HRESP high, HREADYOUT high), the manager can drive IDLE. That cancels the next transfer before anyone takes it. Wait states before the error carry HRESP low.

Beat 3's address phase was on the bus during the first error cycle. The manager turns it into IDLE in the second cycle. So no subordinate ever takes it, because it is never accepted as NONSEQ or SEQ with HREADY high. The manager need not rebuild the remaining beats later. During that waited cycle, it may also change the address, which the normal hold rule forbids.

It is legal: cancelling the rest of the burst is allowed, not required. So the checker must accept both IDLE in the second error cycle and a burst that carries on. The subordinate answers the later beats normally. A checker that flags the continued burst reports a false failure on a legal manager.

Check both directions. A first ERROR cycle (HRESP high, HREADYOUT low) must be followed by a second (HRESP high, HREADYOUT high). And a second cycle must be preceded by a first. The one-cycle error passes the first property vacuously: there is no first cycle to trigger it. It fails only the second, so a checker with just one of them misses it.

AHB has one response bit, so a decode error is ERROR from the default subordinate for unmapped NONSEQ or SEQ transfers. APB's PSLVERR counts only in the single completion cycle, and needs no second cycle because APB is not pipelined. AXI separates SLVERR (the end point refused) from DECERR (no end point). It reports per read beat and once per write, and never shortens a burst. Bridges map PSLVERR to HRESP or to RRESP/BRESP.

The wait states stretch the data phase of the read. They also stretch the address phase of the next transfer, which stays on the wires until HREADY is high. Each subordinate drives HREADYOUT for its own data phase. The multiplexor picks the HREADYOUT of the subordinate whose data phase is active. It sends that as HREADY to the manager and to every subordinate. A subordinate takes an address phase only at an edge where its HSEL and HREADY are both high.

The data phase in front may belong to another subordinate. HREADY says when that data phase ends. Only then does the address phase on the wires count as accepted. A subordinate that samples on HSEL alone may act too early. The address phase may still change, such as an IDLE becoming NONSEQ, or the manager may cancel it after an ERROR.

While the data phase in front is in a wait state, HSEL and the address can already point at this subordinate. It then takes a transfer the bus has not accepted yet. If the manager changes IDLE to NONSEQ, or cancels after an ERROR, the subordinate acts on the wrong transfer. Across a long wait it can even take one transfer twice.

Normally no, with three exceptions. IDLE may become NONSEQ, and in a fixed-length burst BUSY may become SEQ. In an undefined-length INCR burst, BUSY may become anything, and IDLE or NONSEQ ends the burst. After any such change, HTRANS is held until HREADY is high. The address may change only for IDLE, or after an ERROR has started.

Wait states stall the whole AHB interface. So the worst-case latency of every manager depends on the slowest subordinate it can reach. A known maximum per subordinate lets you compute that latency. Check it with a watchdog per subordinate, set to its documented bound. Add performance tests that hit the worst case and, for small blocks, a bounded-response property in formal.

An address phase is taken at an edge where HREADY is high and HTRANS is NONSEQ or SEQ. On a subordinate port, HSEL must be high too. Its data phase ends at the next edge where HREADY is high, and HWDATA, HRDATA and HRESP belong to it there. Monitors often log at the address phase and pair the wrong data. Others ignore HREADY and log a waiting transfer several times, or read HRESP as final in the first ERROR cycle.

AHB has one address and control path, with at most one transfer in address and one in data. Transfers complete in order, and a wait state stalls whatever is behind it. AXI has independent channels and IDs, so a manager can issue many requests without waiting. Responses with different IDs may return out of order. AHB wins on area and simplicity for a single manager with modest latency, such as a microcontroller memory bus.

The register block takes address phases without checking HTRANS. IDLE and BUSY must get a zero-wait OKAY and be ignored. But the manager may leave the last write's HADDR and HWRITE on the bus. A block that decodes only HSEL, HWRITE and HADDR treats each IDLE as another write. It stores whatever HWDATA holds. Take a write only when HSEL and HREADY are high and HTRANS is NONSEQ or SEQ.

IDLE means the manager wants no transfer. BUSY means a burst is continuing, but its next beat is not ready yet. Its address and control already describe that next beat. The subordinate answers both the same way: a zero-wait OKAY and no action.

It keeps the burst continuous. When the manager is ready, it turns BUSY into SEQ with the same address. So the subordinate can keep prefetching. Only an undefined-length INCR may end after BUSY, followed by IDLE or NONSEQ. Fixed-length INCR4/8/16 and WRAP4/8/16 must end with a SEQ beat, and BUSY may never follow a SINGLE.

No. Every wire was legal, because the manager may leave the address on the bus during IDLE. Only the data shows the bug. A scoreboard or register model that reads back after idle gaps catches it. Assertions own the wire rules (holds, two-cycle ERROR, SEQ addresses, 1 KB crossings). The scoreboard owns subordinate behaviour (data taken in the wrong phase, lanes HSIZE did not select, actions on IDLE).

These bugs need two subordinates at once. A mux select on the wrong phase shows only on back-to-back accesses to different subordinates. A HREADY fan-in that forwards the wrong HREADYOUT shows only when one subordinate waits while another is addressed. A region off-by-one shows only at a 1 KB edge, and a one-cycle default-subordinate error only on unmapped accesses. Expose them with back-to-back cross-subordinate traffic, random waits and address sweeps at every region boundary.

The decoder turns HADDR into one HSELx during the address phase. The multiplexor returns HRDATA, HRESP and HREADYOUT from the subordinate whose data phase is in progress. So its select is the decoder output, registered at every edge where HREADY is high. The live decoder output already names the next transfer. A default subordinate fills the holes in the map, so nothing hangs. It gives a zero-wait OKAY for IDLE and BUSY, and a two-cycle ERROR for NONSEQ and SEQ.

HBURST gives SINGLE, undefined-length INCR, and fixed INCR4/8/16 and WRAP4/8/16. The number counts beats, not bytes. A wrapping burst wraps inside a window of beats times size. So a WRAP4 of words from 0x34 visits 0x34, 0x38, 0x3C, 0x30. An incrementing burst must not cross a 1 KB boundary, because subordinate regions are at least 1 KB and 1 KB aligned. Every beat is aligned to its size.

Subordinate regions are at least 1 KB, and they start and end on 1 KB boundaries. So a burst that stays inside one 1 KB block never changes subordinate mid-burst. Subordinates can then treat SEQ beats as a continuation without decoding again. AXI applies the same idea with a 4 KB boundary. A wrapping burst stays inside its own aligned window, which on usual bus widths is far smaller than 1 KB.

The beats are 0x3F8, 0x3FC, 0x400 and 0x404. The third beat starts the next 1 KB block, which may belong to another subordinate. That subordinate sees a SEQ beat with no NONSEQ before it. The manager must split the request: two beats, then a new NONSEQ at 0x400.

The window is beats times size, aligned to its own size. Add the size to the address. For a wrapping burst, if that reaches the end of the window, go back to the window's base. The run reproduces the specification's WRAP4, INCR4, WRAP8 and halfword INCR8 examples. The classic bug is a window sized for the old burst length, which turns WRAP8 back at 16 bytes.

A manager may not end a fixed-length burst on its own, but two things can end it. After an ERROR, the manager may cancel the remaining beats. A multi-layer interconnect may also cut a burst to serve another manager. An INCR burst also ends whenever BUSY is followed by IDLE or NONSEQ. Subordinates must work correctly when a burst never completes, for example by dropping prefetched data.

An interconnect adds arbitration and routing, because the AHB interface itself stays single-manager. It stalls a waiting manager by holding its HREADY low. A multi-layer interconnect may cut a burst short to serve another manager, so subordinates must cope with unfinished bursts. Locked sequences need HMASTLOCK, and exclusives need HMASTER to tell managers apart. The plan adds per-port checkers, routing scoreboards, fairness coverage and terminated-burst coverage.

Idle is 1. The frame starts with a 0 start bit. Then come the eight data bits, least significant bit first, and a 1 stop bit. For A5h that is 0, then 1 0 1 0 0 1 0 1, then 1: ten bit-times. Even parity adds one bit before the stop bit, chosen so the count of 1s is even. A5h already has four 1s, so the parity bit is 0 and the frame takes eleven bit-times.

There is no clock wire, so the receiver needs one moment it agrees on with the transmitter. That moment is the high-to-low edge of the start bit. The receiver times every bit from that edge. The stop bit returns the line high. So the next frame always begins with a fresh falling edge, even when the last data bit was 0.

SPI sends the clock, so the receiver samples on an edge it is given, and the rate can change freely. A UART receiver must rebuild bit timing from the start edge and its own clock. So both ends must agree closely on the baud rate. Frames also carry start and stop overhead: 8N1 moves 8 data bits in 10 bit-times. The gain is fewer wires and no shared clock across a cable.

It catches any odd number of flipped bits in the data and parity bits. It passes any even number. So a burst that flips two adjacent bits passes. Parity also says nothing about a lost or extra frame. Systems that care add a checksum or CRC at the packet level, above the UART.

Parity stores one fact: whether the count of ones is even or odd. Flipping one bit changes that count by one, so the parity no longer matches. Flipping two bits changes the count by two or by zero, so it still matches. Any even number of flips cancels the same way.

There is no clock on the wire, so a fast local clock finds the start edge to within one tick. It then counts to the middle of every bit. A typical receiver rejects glitches in the middle of the start bit. There, 8 ticks after the edge, the line must still be low. After that it samples every 16 ticks, often with a 2-of-3 vote over ticks. At 16x a sample is off by at most a sixteenth of a bit; at 2x, by half a bit.

The ratio sets the quantisation error of finding the start edge: up to one tick, or 1/N of a bit. At 2x that is half a bit, which already uses the whole budget; at 16x it is about 6 %. Beyond that, the rate mismatch between the two clocks dominates. So 64x buys little and costs a faster clock and wider counters. Sixteen also leaves room for a centred vote over several ticks.

Two low ticks on two of the three vote ticks of one sample win the vote. One tick never does. The bench must time the glitch against the receiver's own sample ticks. A random glitch time rarely lands on two vote ticks, so the bench must know or sweep the sample position. The P6.5 bench did this and turned 55h into 45h with no flag.

Drift is zero at each start edge and grows with every bit. So the last sample, the stop bit, fails first. A receiver that samples exact bit centres has half a bit of slack over the nine bits before the stop. That is about ±5.6 %, shared by both ends. Real receivers do worse: the site's bench receiver first loses 8N1 frames at +4.5 % and −6 %. The 8E1 format fails earlier, because parity puts the stop bit one bit later.

The start edge is the only moment both ends agree on, and drift is zero there. Each later bit adds the same timing error. So the sample furthest from the start edge, the stop sample, has drifted most. This is also why the receiver restarts its count on every start edge. The error never carries from one frame to the next.

It helps only on the fast side, and only when frames stream back to back. There, with a fast transmitter, the stop sample comes late and can land in the next start bit. It then reads 0. A second stop bit puts idle time there instead. With idle time between frames it buys nothing: the P6.4 sweep shows 8N1 and 8N2 failing at the same steps.

Add up the error sources: this end's divisor rounding and clock tolerance, and the peer's oscillator tolerance over temperature and voltage. Compare the sum, in both directions, with the receiver's measured budget for the frame format in use, not a quoted 5 %. In simulation, sweep the peer rate in fine steps, both ways, in every supported format. Run frames back to back and with gaps. Record the first failing step as the sign-off number.

A rate error moves each sample further from its bit centre, and the stop bit moves most. The total room is about half a bit over the frame. A receiver that samples a little before the centre has less room on one side and more on the other. So quote the budget with its receiver, format and pacing.

A clean wire with lost bytes points inside the receiver, to an overrun. A frame completes before software read the previous byte, and the new byte overwrites it. Framing errors (the stop sample reads 0) and parity errors are visible on the wire; an overrun is not. A break is the line held low for longer than a whole frame. A correct receiver reports it once and delivers no byte. It hunts for a start only after the line is high again.

During a break the line is a continuous 0. A receiver that re-arms at once takes the low level as a new start every frame time. It delivers a stream of 00h framing errors. Waiting for the high level means the next frame begins on a real falling edge. A common bug that tests miss is a lost first frame after recovery: the receiver re-armed too late or too early.

The transmitter may send the next start bit soon after the line goes high. A receiver that waits a whole frame misses that falling edge. It loses the first byte, or starts in the middle of it and reads garbage. Re-arm on the first high level, then hunt for the next falling edge.

Each side drives RTS from its own receive FIFO level. The peer sees it as CTS and starts no new frame while CTS is deasserted. But frames already started, or already loaded in the transmitter, still arrive after RTS changes. So the trigger sits below full, and the room above it absorbs those frames. The P6.6 bench uses 12 of 16; a trigger at 16 left no room.

A flag is a bug only if it disagrees with what was sent. So the checker predicts flags from the stimulus. An injected short stop expects FE, a break expects one break and no byte, and a slow read expects overrun. It flags both a missing expected flag and an unexpected one. Banning all errors makes error tests impossible; ignoring flags misses a receiver that never sets them.

I use three independent parts. A wire monitor reports each frame after its stop sample. A reference model predicts bytes and flags from the stimulus and the read timing, and a scoreboard compares them. Stimulus sweeps the divisor and the peer rate error both ways, in every format, back to back and with gaps. It injects faults: parity, short stop, break, glitches, slow reads and CTS toggling. Before trusting the checker, I run it against a bank of known-faulty receivers.

After the stop sample. Until then there is no frame. The stop bit decides between a byte, a framing error and a break, and a break never gives a byte. A monitor that publishes at data bit 7 hands the scoreboard bytes that later turn out to be breaks or errors.

Run it against a bank of deliberately faulty receivers. Examples are a missing overrun flag, an off-centre sample, a one-tick start check and a broken break recovery. Add a legal variation, such as a rate error inside the budget. Every fault must make some check fire, and the legal case must stay silent. A fault that no test catches names the next test to write.

Rate tolerance worse than claimed: only a sweep to the first failing step catches it. A missing overrun flag: caught only when software reads slowly. The first frame lost after a break: caught by sending a frame right after recovery. An RTS trigger off by one: caught by filling the FIFO to exactly the trigger. Each needs a deliberate scenario; random traffic at the nominal rate rarely hits them.

CPOL is the clock's idle level. CPHA picks the sampling edge. CPHA 0 samples on the first edge after the clock leaves idle; CPHA 1 samples on the second. The other edge launches the next bit. So modes 0 (CPOL 0, CPHA 0) and 3 (1, 1) sample on rising edges, and modes 1 and 2 on falling edges. With CPHA 0, the first bit must already be on the line when CS falls.

At the falling edge of CS. With CPHA 0 there is no launch edge before the first sample. So both sides put bit 7 out as soon as they are selected. They launch every later bit on the trailing edge. A peripheral that waits for a clock edge to drive bit 7 delivers the byte one bit late.

Only the clock level while idle, at the CS edges: low in mode 0, high in mode 3. In both, the flash latches input on rising edges and drives output on falling edges. So data transfer is identical. It matters at the frame boundary: the controller must hold the idle clock level when it moves CS. The CS-to-clock setup and hold times still apply.

A clean one-bit shift is the signature of an SPI mode mismatch, not noise. Both sides move one bit per clock but disagree on which edge carries it. The controller samples each bit just before the peripheral launches it, so it gets the previous bit. The lost bit turns up in the next byte. With a mode-0 controller and a mode-1 peripheral, writes can still pass. But their only hold time is the launch delay.

Both sides still move one bit per clock and agree on the number of clocks. They disagree only on which of the two edges in a clock period carries the bit. Those edges are half a period apart. Sampling on the launch edge reads the value from before the launch, which is the previous bit. So every bit lands exactly one place late.

On the shared edge, the only hold time is the launching side's clock-to-output delay. So a model with no delays always takes the old bit and looks correct. In silicon, hold must beat the receiver's requirement, such as tCHDX of 2 ns on the W25Q128JV. For same-cycle reads, start from half a clock period. Subtract the peripheral's clock-to-output time (tCLQV) and the controller's input setup; the rest is the setup margin.

From configuration, never by guessing: rising when CPOL equals CPHA, falling otherwise. A monitor that infers the mode can be fooled by the very mismatch it should catch. On the wires alone, a checker can assert the idle clock level at CS edges and MISO released while deselected. It can also check stable data on the sample edge, whole bytes on writes and CS-to-clock times. Whether the bytes are right needs a reference model.

Use a wire monitor for every supported mode and lane width. Add wire checks that need no data: idle level, MISO and IO release, CS timing and whole bytes on writes. A strict flash model refuses what the datasheet forbids: programs without WEL, quad reads with QE clear, commands while BUSY. A scoreboard compares readback with a reference memory. Bugs escape through a lenient model, page-wrap writes, off-by-one dummy counts and turnaround timing.

Plant one fault per class, such as a missing WEL, a late IO release or a page-wrap error. Run every test against every fault and record which check fires. A fault with no mark is a hole, so add a program for it. On the lesson bench the wire checker caught 1 fault of 11, and readbacks caught the rest.

A deselected peripheral must put MISO in high impedance, so only the selected one drives it. The W25Q128JV floats its outputs whenever /CS is high. If a deselected device keeps driving, two outputs fight. Simulation shows x on the bits where they disagree. A board shows mid-rail levels, wrong bits and extra current. Clock, MOSI and MISO are shared; each device has its own active-low select.

Separate selects cost one pin per device, but let you talk to any device alone, at its own mode and length. A daisy chain uses one select, and each device's output feeds the next device's input. So the chain is one long shift register, and every update shifts through every device. One broken device breaks the chain, and every device must support pass-through. It suits strings of identical parts, such as LED drivers or shift registers.

The first device needs its output-disable time to let go of MISO: 7 ns maximum (tSHQZ) on the W25Q128JV. The next device's first driven bit must come later than that. The same device also has its own minimum deselect time before it accepts a new command. On that flash it is 10 ns after a read and 50 ns after a program, erase or write.

The controller sends EBh on IO0 alone for 8 clocks. Then it sends the 24-bit address on all four lanes in 6 clocks, and the mode byte in 2 more. Then come 4 dummy clocks, in which the controller must release the lanes. From clock 20 the flash drives one byte every 2 clocks, high nibble first, with the top bit on IO3. QE in status register 2 must be set, because IO2 and IO3 replace the /WP and /HOLD pins.

The flash needs time to fetch the first byte after the last address bit. Read Data (03h) gets that time by running slowly: on the W25Q128JV it is limited to 50 MHz. Fast Read (0Bh) adds eight dummy clocks so the whole frame can run at the full rated clock. That is 133 MHz in the 3.0 to 3.6 V range. The quad I/O read sends the mode byte and then only four dummy clocks.

The flash drives data only after its eighth dummy clock. The controller starts sampling two clocks early, so it reads two junk bits first. Every byte it returns is then shifted by two bits. Check the dummy count per command, because the quad reads use different counts.

Both drivers are on during the first data clock. Simulation shows x on lanes where they disagree; the board shows mid-rail levels and wrong bits. A bench catches it with a wire rule: no lane has two drivers. Or it checks that the controller's output enables are off before the first data clock. Waiting for a data mismatch is not enough, because matching bits hide the fight.

One EBh read of the line: 8 instruction, 6 address, 2 mode, 4 dummy and 64 data clocks, 84 in all. Burst wrap, set with 77h, does not reduce that. It starts at the byte that missed and wraps within the aligned section. So the CPU can resume while the rest of the line streams in.

Page Program writes within one 256-byte page. The low address byte wraps inside the page, so bytes 256 to 299 overwrite bytes 0 to 43. The next page is never touched. The driver must split writes at page boundaries. It must send Write Enable (06h) before every program, because WEL clears when a program finishes. It must also raise CS only after a whole byte, and poll BUSY before the next command.

Write Enable (06h) sets WEL, a guard against stray writes. The flash clears it after every program, erase or status write, so each one needs a fresh 06h. After CS rises, the operation runs on its own for milliseconds. Firmware polls status register 1 with 05h until BUSY, bit 0, reads 0. While BUSY, the flash ignores everything except status reads and suspend.

The model shared the driver's wrong belief, a linear address. So the two agreed, and the test checked nothing the datasheet says. Fix the model first: feed it stimulus the datasheet forbids or defines unusually, and expect the datasheet's result. Examples are a program past a page, a program without 06h and a quad read with QE clear. Then cover page offset × length, including lengths that cross the boundary.

The datasheet defines Page Program only on erased locations, which read FFh. So the result is not something to rely on. In practice, programming can only clear bits, never set them. To get 1s back you must erase, and the smallest erase on this flash is a 4 KB sector. So updating one byte means a read, a sector erase and a reprogram.

Each device can only pull a line low or let go. A pull-up resistor raises the line when every device lets go. So the line is the wired-AND of all devices, and two drivers never fight. That makes clock stretching, clock synchronisation and multi-controller arbitration possible. It also lets parts on different supplies share a bus. The cost is the rising edge: a resistor charges the bus capacitance, which limits speed and bus size.

The first time another device pulls SDA low while this one drives high, two outputs fight. In simulation the line resolves to x. On a board, the two transistors set a voltage, often between VIL and VIH, so receivers disagree. ACKs, arbitration and the controller's own bits all break. The fight can also damage drivers.

Two bounds. Rp(max) comes from the rise-time limit: tr = 0.8473 Rp Cb. With 300 ns and 100 pF, Rp is at most about 3.5 kΩ. Rp(min) comes from the sink current: (VDD − 0.4 V) / 3 mA, about 967 Ω. Pick inside that window, toward the high end if supply current matters. At 400 pF in Fast-mode the window is empty, so a resistor alone cannot work.

UM10204 lists four options. Run a slower SCL so the rise fits, or use higher-drive parts, such as Fm+ devices, with a stronger pull-up. Split the bus with buffers, multiplexers or switches so each segment stays under the limit, or add a switched pull-up. Buffers add delay to every edge and may bring their own VIL/VOL rules. Fm+ still stops at 550 pF and 1 MHz.

No. A digital checker measures edge-to-edge times such as tLOW, tHIGH, tSU;DAT and tBUF on 0/1 pins. Rise time, fall time, spike width and bus capacitance are analog. In RTL the pins switch instantly, so a pull-up that is far too weak still passes. Those rows need SPICE or a board measurement, plus the pull-up arithmetic.

The controller makes all nine clocks. In the ninth, the transmitter releases SDA. The receiver pulls it low (ACK) and holds it through the high phase; SDA left high is a NACK. On a write the target ACKs, and on a read the controller does. The controller NACKs the last read byte so the target stops driving. An ACK would tell the target to send the next byte, which may hold SDA low and block the STOP.

After an address, most likely no device answers at that address, or the target is busy with a real-time task. Later in a transfer, a NACK can mean the target did not understand the byte or cannot take more. A controller-receiver also NACKs on purpose to end a read. Whatever the reason, the controller ends with STOP or tries again with a repeated START. Software decides whether to retry.

A correct controller that sends a 1 and reads a 0 decides it lost arbitration. So the log says "arbitration lost", even on a single-controller bus. The wires alone cannot say who pulled. You need the driver view, meaning each device's pull-low enable. It shows the target's lane still active after the ninth clock.

The transmitter drives it. On a write, it is odd parity from the controller: the XOR of the eight data bits with 1. Parity lets the target detect a corrupted byte. On a read, it is end-of-data from the target: 0 ends the message, and 1 offers more. So the target decides how much it returns, though the controller may abort after a 1 with a repeated START.

It cannot NACK the byte, because the ninth bit belongs to the controller. Error type S2 says the target ignores the rest and waits for a STOP or a repeated START. The controller sees nothing on the wire. It learns of the error later, from the Protocol Error bit that GETSTATUS returns.

A target that needs time holds SCL low. SCL is a wired-AND, so the line stays low after the controller lets go. The controller must read SCL back, and start timing its HIGH only once SCL really is high. A controller that times HIGH from its own release samples SDA too early. The target still holds the clock, so the controller reads a wrong byte. Stretching is optional for targets and has no time limit in I2C.

On a wired-AND SCL, every controller starts counting LOW when the line falls. But the line rises only when the last one lets go. Each waits for SCL high before counting HIGH, and the first to finish HIGH pulls it low again. So the bus clock gets the longest LOW and the shortest HIGH of all controllers. A stretching target is just another device with a long LOW.

I2C sets no limit, so the controller IP should carry its own configurable time-out. It should give up and report, not hang. With SCL stuck low, clocking out is impossible, so UM10204 points to a hardware reset input or a power cycle. To verify, use a target model that never releases. Check that the controller times out, flags the error and leaves SCL released.

Any target whose datasheet allows a longer stretch. I2C sets no limit on stretching, so a 1 ms limit turns legal behaviour into a reported error. Set the limit from the slowest target's datasheet. Use SMBus's 35 ms only when the system really uses SMBus devices.

No. In I3C only the controller drives SCL, and legacy I2C targets on an I3C bus may not stretch. The controller may stall instead, holding SCL low in only four places. They are the ACK/NACK slot, a write's parity bit, a read's T-bit and the first bit of an assigned address in DAA. The absolute maximum stall is 15 ms.

Both drive SDA bit by bit, and compare the wired-AND line with what they sent while SCL is high. The first controller to send a 1 and read a 0 has lost, and it releases SDA at once. Until then both sent identical bits, so nothing is lost and the winner's message is intact. Address 0x58 loses on the fourth address bit. The loser may clock to the end of that byte, and retries when the bus is free.

It must switch to target mode at once and keep decoding the address. The winner may be addressing this very device. If it waits as an idle controller until the bus is free, it misses its own address. The winner then sees a NACK. Separately, it must not drive any more bits of its own message.

It must wait until the bus is free. The bus counts as busy from the START until a set time after the STOP, and a repeated START keeps it busy. So the loser waits for the winner's STOP and the bus-free time. A START any earlier breaks the winner's message.

Yes. UM10204 leaves three collisions undefined while arbitration is still running. In two of them, one controller sends a repeated START or a STOP while the other sends a data bit. In the third, one sends a repeated START against a STOP. Arbitration works only when both still send bits in the same position of the same format.

Build a two-controller bench with a reference controller and the DUT on wired-AND lines. Cover a loss at every address and data bit position and identical messages that complete together. Add a loss while addressed as a target, the clock-to-end-of-byte rule, and unequal LOW/HIGH periods for synchronisation. Check from the driver view that the loser never drives after losing. Back it with a formal proof on an abstraction.

The frame is S, 0x50 with W, ACK, the pointer 0x3C, ACK. Then comes a repeated START, 0x50 with R, ACK, the data byte, NACK, STOP. The write sets the target's internal pointer, and the read returns data from it. The repeated START changes direction without releasing the bus. A STOP would free the bus. On a multi-controller bus, another controller could then take it and move the pointer before the read.

After the STOP and the bus-free time, another controller may win the bus. It may access the same target, move its pointer or change the register. Your read then returns data from the wrong place, with no error anywhere. STOP then START works on a single-controller bus, with a target that keeps its pointer. Sr makes it safe without relying on either assumption.

The target does not detect the repeated START. It treats the Sr and the next address byte as more write data, and never answers the read address. So the controller reads the released line: 0xFF. UM10204 requires devices to reset their bus logic on any START or repeated START, and expect an address. A test that only writes, or reads with STOP plus START, never exercises it.

A combined-format read: write the register pointer, send Sr, send the read address, then read. Check that the target ACKs the read address and returns the register value, not 0xFF. Cover Sr in the monitor, so coverage shows that this format really ran.

The address takes two bytes: 1111 0XX plus W, then the low eight bits. Here XX are the top two address bits. Several targets may ACK the first byte, but only one ACKs the second. After the pointer write, the controller sends Sr and repeats only the first byte, with R. The target that matched both bytes earlier stays addressed and answers.

Sample data at SCL rises, and detect START and STOP as SDA edges while SCL is high. Close the current transaction at a repeated START or a STOP. A monitor that publishes at START publishes the previous transaction late. On the first START, it publishes a byte it shifted in before the address. Treat Sr as both the end of one transfer and the start of the next.

The controller reset in the middle of a read, while a target was sending a 0. The target waits for SCL edges to finish its byte. No STOP can form while it holds SDA low. To recover, clock SCL up to nine times, checking SDA before each pulse. Each falling edge moves the target to its next bit, and it lets go at a 1 or its ACK slot. Then send a STOP, and if SDA stays low, use a hardware reset or power cycle.

Every falling SCL edge moves a stuck transmitter to its next bit. Within a byte's eight bits and its acknowledge slot, it must reach a 1 or the ACK slot. There it lets go of SDA, so nine pulses cover any position. Stop as soon as SDA reads high. Extra pulses after that just clock a target further into a transfer the controller no longer wants.

Then the target is not just waiting for clocks; it may be hung. Stop pulsing and report the failure. UM10204 then points to the device's hardware reset input, or a power cycle to trigger its power-on reset.

No. The controller cannot make SCL pulses if something holds SCL low. UM10204 says to use the devices' hardware reset inputs. Or cycle their power to trigger the mandatory power-on reset. So the controller must detect the fault with a time-out and report it. The board also needs a reset path to the I2C devices, a system design decision made early.

One bug sends only eight pulses, one short for a target that needs nine. Another sends no STOP after SDA comes back, so devices still think a transfer is open. A third pulses without reading SDA, so it claims success while the line is still low. A fourth waits forever when SCL is held, instead of timing out. Each needs its own stuck-target scenario to show up.

I use four kinds of checking, starting with data checks against a model derived from the wire. The others are a timing checker for the Table 11 edge times, a driver-view checker and a two-controller bench. Directed programs target each fault: wrong addresses, pointer wraps, Sr, stretching, collisions and a stuck bus. Done means every seeded fault is caught, legal variations stay silent and coverage closes.

I3C keeps the two wires, START, STOP and the 7-bit address header, and legacy I2C targets can share the bus. Data moves to push-pull, at up to 12.5 MHz. Open drain stays only where several devices may drive: arbitration, ACKs and address assignment. Only the controller drives SCL, so targets cannot stretch the clock. I3C adds dynamic addresses, common command codes, in-band interrupts and hot-join. The ninth bit of a data byte becomes parity or end-of-data.

A push-pull 1 does not wait for a pull-up resistor to charge the bus. So bits get much shorter: 80 ns push-pull against 240 ns open drain on the lesson bench. Where several devices may drive at once, a 0 must win and a 1 must lose quietly, as in a wired-AND. So these stay open drain: the header after START, where targets may raise interrupts, plus ACK slots and address assignment. The header after a repeated START, and data, are push-pull.

It must be a target only, with a static address, Fast-mode support and no clock stretching. A true 50 ns spike filter on SCL hides the short I3C clock highs from it. Then the bus can run I3C at full speed, which is called a mixed fast bus. Without the filter, the device sees I3C traffic as clocks. The bus speed then drops to what the slowest unfiltered legacy device tolerates.

No. I3C Basic v1.0 leaves out the HDR (high data rate) modes themselves. But a full I3C controller may still put the bus into HDR for other devices. Every target must detect the HDR entry command and the HDR Exit Pattern, even one with no HDR support. A target that misses the exit treats HDR traffic as SDR and misreads what follows. Feature lists differ between I3C editions, so name the edition you quote.

The controller broadcasts ENTDAA, then runs rounds of Sr (repeated START) with 7E/R. Every target without an address ACKs and sends its 48-bit provisional ID, then BCR and DCR. These bits go out in open drain, with no ACKs in between. The lowest 64-bit value wins and gets a 7-bit address plus odd parity, which it ACKs. A loser stops driving and competes again in the next round. A round that nobody ACKs ends DAA.

Yes. In I3C a lower address means higher priority. Several targets may raise an in-band interrupt after the same START. The lowest address then wins the header arbitration, because 0 bits win on the wire. So the controller should give low addresses to targets with urgent interrupts. It can reassign addresses later with SETNEWDA or RSTDAA.

Either two targets sent identical ID, BCR and DCR, or one target kept driving after it lost. Both then ACK the same address. The controller knows how many devices need an address. It must compare that number with the count actually assigned, and fewer means a collision. It then resets the duplicate with RSTDAA (direct or broadcast) and runs DAA again.

With a vendor-fixed ID, two copies of one part share the maker and part bits. Only the 4-bit instance ID tells them apart. The system designer sets it, for example with straps or fuses. If two boards strap the same value, the IDs tie, so the controller must check after DAA.

The target NACKs when the parity bit is wrong. The controller moves on to the next round, and the same target wins again with the same ID. If it NACKs a second time, the controller must leave DAA. It then runs an error procedure that the system designer defines. So a target with a broken parity check blocks every target behind it.

No. With SETDASA, the controller gives one target at a time a dynamic address, using its known static address. SETAASA does it for all supporting targets at once, with no arbitration: each static address becomes the dynamic one. ENTDAA then handles targets that have only a provisional ID. In a mixed system, the controller sends SETAASA before ENTDAA.

The target puts its own address with R into the arbitrable header after a START. If the bus stays free for the Bus Available time, the target pulls SDA low itself. The controller then completes the START and drives the clock. The controller has three answers. It can ACK and read the mandatory byte, if BCR bit 2 promises one. Or it can NACK so the target retries later, or NACK and disable its events with DISEC.

IBI saves a host pin and a board trace per device. The interrupt carries the source's address and often a data byte, so the host need not poll to find who asked. The price is latency that depends on the bus. A request waits for a START or the Bus Available time, controller stalls add delay, and a lower-address target wins collisions. Keep a pin where worst-case latency must stay tightly bounded.

The header is open drain, so the lowest address on the wire wins. Any assigned dynamic address (0x03 to 0x7B) is lower than 7E. So an interrupting target always beats the controller's broadcast header. Between targets, the lower address wins. The losers may try again, but only after the next Bus Available condition, not on a repeated START.

A plain NACK refuses only this request, and the target tries again after the Bus Available condition. To stop the requests, the controller NACKs, sends a repeated START and then DISEC with DISINT set. A controller that NACKs forever without DISEC wastes the bus on retries.

After its ACK, the controller releases SDA and expects the target to drive the byte. Nobody drives, so the keeper or pull-up lets SDA rise while SCL is high. That is a STOP on the wire. A decoder closes the frame early, and a controller that carries on reads 0xFF. The fix is in the target, but only a checker that knows BCR[2] can flag it directly.

It needs several devices, because most I3C faults involve more than one device. Use two targets with near-identical IDs for DAA ties, and two simultaneous IBIs for header contention. Add a legacy I2C neighbour for the coexistence and no-stretch rules, and HDR enter and exit followed by an SDR read. Check with a wire checker and a driver view that shows who drives a 1, for push-pull faults. Also self-check effects such as addresses assigned and bytes read.

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.

I build four layers. A bound protocol checker catches illegal timing at the interface. Monitors feed a reference model and an ID-aware scoreboard, which catch wrong data, lost beats and illegal reordering. Constrained-random and directed stimulus add adversarial backpressure (stall patterns chosen to stress the design) on every channel. Functional coverage tracks attributes, concurrency and stalls. I call it done when no checker fires, coverage is closed with reviewed waivers, and the bug-find rate has flattened.

It replaces the protocol checker and much of the stimulus and protocol coverage. That holds only once it is configured to match the interface: widths, ID bits, outstanding limits and optional signals. It does not replace the reference model, the scoreboard, or the design-specific legal subset. It also does not replace a review of its own configuration. A misconfigured VIP silently checks a different interface from the one you built.

Break each rule once, on purpose, with a small fault in a test agent. Check that the VIP reports it, at the right edge. A checker whose antecedents never fired has checked nothing. Keep these fault tests in regression, so an upgrade or a config change that silences a rule shows up.

Random traffic misses corners that need one exact value, such as a burst ending exactly at a 4 KB edge. Others are a WRAP in the top address window and the longest burst at the largest size. So are every ID in flight at once, a stall on the last beat, and reset during a burst. Uniform randomness gives each of these about zero probability. Add weighted constraints toward edges, directed tests for the extremes, and coverage bins that name each corner.

Bind a checker on every port, and replace the per-port scoreboards with one end-to-end scoreboard. It models the address decode and the ordering per manager and ID. It also models the ID bits the interconnect adds on the way in and removes on the way out. Add system checks: no response to the wrong manager, decode errors for address holes, and bounds on fairness and starvation. Formal suits the decoder and ID logic, while simulation covers data integrity and performance.

I bring a plan-to-evidence table. It maps every spec rule to a property or scoreboard check, each passing in regression with its antecedent (trigger side) covered. Beside it go closed functional coverage with designer-signed waivers, and explained code coverage holes. I add open bugs at zero or deferred in writing, plus the recent bug-find rate. Then comes the honest part: what was not verified, and why the risk is accepted.

Sample from the passive monitor when a transaction completes, not from the driver when it is issued. Cover the attributes: burst, length, size, alignment, and distance to a 4 KB or wrap boundary. Cover concurrency: outstanding depth, ID reuse and interleaving. Add backpressure (stall length per channel, including the last beat), every response type, and reset mid-transaction. Cross only the fields that interact. A cross of every field gives thousands of bins that nobody closes.

Coverage should record what the design actually did. The monitor sees only accepted transactions, with their real response and timing. It also works the same when the agent is passive (only watching) in a larger environment. Sampling at completion lets a bin record the response and the stall pattern. The driver cannot know these when it sends the item.

Say a write is driven, but reset aborts it before the handshake. The driver has already counted a write of that kind. The bin closes, yet the design never completed it. Driver coverage measures what the stimulus asked for, not what the design did.

Code coverage finds RTL that no test reached, such as an error path or an unused state. Nobody has to think of these in advance. Functional coverage checks that the scenarios the spec and plan care about happened. That includes combinations and sequences that no single line of code represents. Code coverage cannot see a missing feature and functional coverage cannot see dead code, so you need both.

Start from the legal set, not the raw one. On a 32-bit bus Size is 1, 2 or 4 bytes, and INCR allows 256 lengths, FIXED 16 and WRAP 4. That gives 3 x (256 + 16 + 4) = 828 legal combinations, against 6,144 raw. Then bucket the lengths where behaviour does not change: 1, 2 to 15, 16, 17 to 255, and 256. That leaves a few dozen bins, and each one means something.

Most likely the bench kept BREADY and RREADY high, so the subordinate's response-side stall path never ran. Every stall rule then passed vacuously, because no stall ever happened. The coverage model also had no stall-length bins on B or R. Randomise ready with long low runs on every channel the testbench drives, and cover stall length per channel. Also count how often each checker antecedent matched.