AXI 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.