Common Burst Bugs

This chapter closes Module 8 by turning the burst knowledge into a debugging skill — the burst counterpart to the wait-state (6.7) and response (7.9) debugging chapters. Burst bugs cluster into two families: master-side address bugs (the master generates the wrong address sequence) and slave-side handling bugs (the slave mishandles termination or BUSY). The catalogue: wrong wrap (INCR for a cache fill, or a wrong boundary), wrong address increment (not scaling by the beat size), lost or extra beat (off-by-one count), bad SEQ/NONSEQ (wrong HTRANS marking), INCR crossing a decode boundary (not split at 1KB), assuming the full beat count (mishandling early termination), and confusing BUSY with IDLE. The guiding method: verify the address sequence against the burst type and beat size, and verify the slave tracks HTRANS for termination and BUSY.

1. What Is It?

The common burst bugs are a set of recurring mistakes, in two families:

• Master-side address bugs (the master drives the wrong address sequence): wrong wrap (INCR used for a cache fill, or wrapping at the wrong boundary), wrong address increment (stepping by the wrong amount, not the beat size), lost or extra beat (off-by-one in the beat count), bad SEQ/NONSEQ (wrong HTRANS on a beat), INCR crossing a decode boundary (a long INCR not split at a 1KB boundary).
• Slave-side handling bugs (the slave mishandles the burst): assuming the full beat count (not handling early termination), confusing BUSY with IDLE (dropping the burst context on a pause).

The two families differ in how they manifest: master-side bugs show as a wrong address sequence on the waveform (addresses that don't match the declared burst type and beat size), while slave-side bugs show as hangs or mishandled pauses (the slave waiting for beats that won't come, or mishandling a BUSY pause). So the debugging approach differs: for a suspected master bug, check the address sequence against the burst type (HBURST) and beat size (HSIZE); for a suspected slave bug, check the slave's HTRANS handling of termination and BUSY. Each bug maps to a fix established in earlier chapters of this module.

2. Why Does It Exist? (Why these bugs recur)

These bugs recur because bursts have several precise requirements — the exact address sequence, the beat marking, the boundary rules, the termination and pause handling — and missing any one produces a characteristic failure.

The master-side bugs come from the address-generation requirements (chapters 8.4–8.9): the address must increment by the beat size, wrap correctly for WRAP, not cross a decode boundary for INCR, and be marked with the right HTRANS (NONSEQ then SEQ). Each of these is a place the master's address generator can go wrong — a wrong increment, a missing wrap, an off-by-one count, a bad HTRANS, an unsplit INCR. So the master-side bugs recur because address generation has several exact requirements, each easy to get subtly wrong. The signature is always the same kind: the address sequence on the waveform doesn't match what the burst type and beat size dictate.

The slave-side bugs come from the handling requirements (chapters 8.10–8.11): the slave must track HTRANS to handle early termination (not assume the full count) and must distinguish BUSY (pause) from IDLE (end). Each is a place the slave's burst-tracking can go wrong — assuming the count (hangs on early termination), or treating BUSY like IDLE (mishandles the pause). So the slave-side bugs recur because burst handling has these handling requirements, each easy to miss if the slave naively assumes well-behaved, full-length bursts. The signature is a hang or a mishandled pause.

The reason these bugs are worth cataloguing is that, like the wait-state bugs (chapter 6.7), many are latent — they only manifest under specific conditions. A wrong-wrap bug only shows on a WRAP burst (not INCR); an early-termination bug only shows when a burst terminates early; a BUSY bug only shows when a master inserts BUSY. So a design can pass tests that don't exercise these conditions and still harbor the bug. The catalogue exists to make these conditions explicit — so verification deliberately exercises WRAP bursts, early termination, BUSY pauses, boundary-crossing INCR, etc. Knowing the catalogue tells you what to test and what signatures to look for, converting latent burst bugs into caught ones. So the catalogue is both a debugging reference (symptom → cause → fix) and a verification checklist (the conditions to exercise).

3. Mental Model

Model burst debugging as proofreading a numbered, structured document — the address sequence is the page numbering (must increment correctly, wrap at section ends), the beat marking is the heading structure (first beat = chapter heading, rest = section headings), and the reader (slave) must follow the structure, not assume a fixed page count.

A structured document (a burst) has rules: page numbers increment by the right amount (the address increments by the beat size), sections wrap their numbering at section boundaries (WRAP wraps at the block boundary), the first item is a chapter heading and the rest section headings (NONSEQ then SEQ), and a section shouldn't run past its allotted space into another (INCR shouldn't cross a decode boundary). Writer bugs (master-side) break these rules: wrong page increments (wrong address step), numbering that doesn't wrap (wrong wrap), a missing or extra page (lost/extra beat), a section heading where a chapter heading belongs (bad SEQ/NONSEQ), a section spilling into the next (INCR crossing a boundary). Reader bugs (slave-side) are about how the reader follows it: assuming a fixed page count and getting stuck when the document ends early (assuming the full count), or misreading a "pause, continued on next page" marker as "the end" (BUSY as IDLE). Proofreading checks both: the writer's structure (the sequence) and the reader's following of it.

This captures burst debugging: the page numbering/structure = the address sequence and beat marking (master must generate correctly); writer bugs = master-side address bugs (wrong sequence); reader bugs = slave-side handling bugs (mishandling termination/BUSY); proofread both = check the address sequence (master) and the HTRANS handling (slave). The structure must be both correctly written and correctly read.

See a wrong-increment bug directly:

The model's lesson: check the address sequence against the burst type and beat size — a mismatch is a master-side bug. In the waveform, HSIZE says word (4-byte steps expected), but the buggy address steps by 1 — the increment doesn't match the size. Proofread the structure: the addresses must follow what HBURST and HSIZE dictate.

4. Real Hardware Perspective

In hardware/simulation, burst debugging is assertion-assisted and waveform-driven: protocol assertions catch many burst bugs automatically, and for the rest, you verify the address sequence (against HBURST/HSIZE) and the slave's HTRANS handling on a waveform.

Protocol assertions catch a large fraction of burst bugs (foreshadowing the verification modules). A testbench with AHB burst assertions checks: the address increments by the beat size; WRAP bursts wrap at the correct boundary and stay in the aligned block; the beat count matches the fixed-length HBURST (unless terminated); the first beat is NONSEQ and the rest SEQ; INCR bursts don't cross a 1KB boundary. So assertions automatically flag a wrong increment, a missing wrap, an off-by-one count, a bad SEQ/NONSEQ, or a boundary-crossing INCR — pointing you straight to the offending beat. So in a well-instrumented environment, burst assertions catch most master-side bugs, localizing them to a specific beat and a specific violated rule.

The address-sequence check is the core master-side debugging step. Given a burst's HBURST, HSIZE, and start address, you compute the expected address sequence (chapter 8.7's formulas) and compare against the observed HADDR. A mismatch localizes the bug: wrong increment (steps don't match HSIZE), missing/wrong wrap (WRAP doesn't wrap or wraps wrong), off-by-one (wrong number of beats), boundary crossing (INCR address enters another region). So the formulas double as a debugging reference — compute the expected sequence, diff against observed. This is exactly the verification use noted in chapter 8.7. For each master-side bug, the fix is the corresponding chapter's rule (right increment 8.9, right wrap 8.4/8.8, right count, right HTRANS, split at boundaries 8.8).

The slave-side check is verifying the slave's HTRANS handling. For early termination (chapter 8.10), you check the slave handles a burst ending before its declared count — by terminating bursts early in simulation and checking the slave doesn't hang. For BUSY (chapter 8.11), you check the slave treats BUSY as a pause (retaining context) not IDLE (dropping it) — by inserting BUSY cycles and checking the slave resumes correctly. So slave-side debugging is about exercising the handling conditions (early termination, BUSY) and verifying correct behavior. These bugs don't show as a wrong address sequence (the master may be fine); they show as the slave hanging or mishandling — so you find them by testing the conditions and observing the slave's response.

A hardware note on latency of these bugs: like wait-state bugs, many burst bugs are latent — they only manifest under specific burst conditions. A wrong-wrap bug is invisible on INCR bursts (only shows on WRAP); an early-termination bug is invisible if bursts always complete; a BUSY bug is invisible if no BUSY is inserted. So verification must deliberately exercise these conditions: WRAP bursts of each length, early-terminated bursts, BUSY-paused bursts, boundary-crossing INCR. A test suite that only uses simple full-length INCR bursts would miss the wrap, termination, and BUSY bugs entirely. So the hardware lesson is to test the full range of burst behaviors — the catalogue tells you which.

5. System Architecture Perspective

At the system level, burst bugs are integration and corner-case bugs — they often surface when real masters (with their specific burst patterns) meet real slaves, and they motivate comprehensive burst verification across the full range of burst behaviors.

The integration emergence is common: a master and slave tested in isolation against simple bursts can each pass while harboring a latent burst bug that only surfaces when they interact under specific conditions. A master that generates correct INCR bursts might have a wrong-wrap bug that only appears when it does cache fills (WRAP); a slave that handles full-length bursts might hang on the first early-terminated burst. So burst bugs are classically integration bugs — they appear when the full range of burst behaviors is exercised, which often first happens at integration. This is why integration testing must include diverse bursts (all types, lengths, terminations, BUSY) — to surface these latent bugs before silicon.

The data-corruption risk makes burst bugs serious: a wrong address sequence (wrong increment, wrong wrap, off-by-one) means data goes to or comes from the wrong addresses — silent data corruption, which is among the worst bug classes (hard to detect, damaging). An INCR crossing a decode boundary hits the wrong slave entirely. So burst address bugs aren't cosmetic; they corrupt data. This is why they must be caught — a wrong-wrap cache fill loads the wrong words into the cache (corrupting program data); a wrong-increment DMA scatters data wrongly. So the system stakes are high: burst bugs cause data corruption, motivating rigorous burst verification.

The verification requirement that emerges is comprehensive burst coverage: a verification plan must exercise every burst type (SINGLE, INCR, INCR4/8/16, WRAP4/8/16), every beat size, early termination (by error, by master stop, by arbitration), BUSY insertion, and boundary-crossing INCR — checking the address sequences (against the formulas) and the slave's handling. So at the system level, the burst-bug catalogue defines a verification checklist: the conditions that must be tested to catch the latent bugs. A subordinate or master that passes this comprehensive burst verification is robust across burst behaviors; one tested only on simple bursts is fragile. So the catalogue drives the verification plan — it tells you what to cover. This is the same theme as the wait-state and response debugging chapters: the bug catalogue is the verification checklist inverted, ensuring robustness across the full protocol behavior.

6. Engineering Tradeoffs

Burst debugging reflects the verify-comprehensively, check-both-sides approach.

• Assertion-driven vs manual. Burst assertions catch most master-side bugs automatically (fast, reliable) at the cost of writing them; manual waveform checking needs no setup but is slow. Well-instrumented environments invest in burst assertions; the catalogue tells you which to write.
• Formula-based address checking. Computing the expected address sequence (from HBURST/HSIZE) and diffing against observed localizes master-side bugs precisely. This leverages chapter 8.7's formulas as a debugging/verification reference — the formula is the golden model.
• Exercise conditions vs assume well-behaved. Catching slave-side bugs requires exercising early termination and BUSY (not assuming bursts are simple and full-length). Testing only simple bursts misses these latent bugs. Comprehensive testing is the cost of catching them.
• Comprehensive coverage vs minimal testing. Covering all burst types, lengths, terminations, and BUSY catches the latent bugs but takes more verification effort. Minimal testing is cheaper but leaves latent bugs. For robustness, comprehensive burst coverage is worth it (burst bugs corrupt data).

The throughline: burst bugs split into master-side address bugs (wrong sequence — check addresses vs HBURST/HSIZE) and slave-side handling bugs (hangs/mishandled pauses — check HTRANS handling of termination and BUSY). Most are latent (only manifest under specific conditions) and can corrupt data, so they demand comprehensive burst verification — exercising all types, lengths, terminations, and BUSY, checked by assertions and the address formulas. The catalogue is both a debugging reference (symptom → cause → fix) and a verification checklist (conditions to cover).

7. Industry Example

Trace several burst-bug debugging sessions.

A team integrates masters and slaves and hits various burst bugs.

• Wrong wrap → corrupted cache fills. The CPU's cache fills return wrong data. The waveform shows the fill burst using INCR (not WRAP) — so starting at the critical word, it increments away from the line (fetching words outside the line, missing earlier ones, chapter 8.4). Root cause: the cache used INCR for a fill instead of WRAP. Fix: use WRAP for cache fills. The wrong-wrap bug corrupted the loaded line.
• Wrong increment → scattered DMA data. A DMA transfer places data at the wrong addresses. The waveform shows the address incrementing by 1 instead of the word size (4) — ignoring HSIZE (Figure 3). Root cause: the DMA's address generator doesn't scale the increment by the beat size. Fix: increment by 2^HSIZE (chapter 8.9). The wrong increment scattered the data.
• INCR crossing a boundary → wrong slave. A long INCR DMA burst corrupts data past a certain point. The waveform shows the burst crossing a 1KB decode boundary — the later beats addressing a different slave than the burst started with (chapter 8.8). Root cause: the DMA didn't split the INCR at the 1KB boundary. Fix: split long INCR bursts at decode boundaries. The boundary-crossing hit the wrong slave.
• Slave assumes full count → hang. A custom slave hangs on certain transfers. Investigation shows it hard-codes a fixed-length burst's beat count and waits for all beats — hanging when a burst terminates early (chapter 8.10). Root cause: the slave assumes the full count instead of tracking HTRANS. Fix: track HTRANS, complete on whatever beats arrive. The assume-the-count bug hung the slave.
• BUSY confused with IDLE → mishandled resume. Another slave mishandles bursts from a DMA with a bursty source. The waveform shows the DMA inserting BUSY (a pause), but the slave drops the burst context (treating BUSY like IDLE), then mishandles the resuming beats (chapter 8.11). Root cause: the slave doesn't distinguish BUSY from IDLE. Fix: treat BUSY as a pause (retain context). The BUSY-IDLE confusion mishandled the resume.
• Comprehensive verification caught them. The team's burst verification deliberately exercised WRAP bursts, wrong-size scenarios, boundary-crossing INCR, early termination, and BUSY — with assertions checking the address sequences and slave handling. This comprehensive coverage caught the latent bugs (wrong wrap, wrong increment, boundary crossing, assume-count, BUSY-IDLE) before silicon. Simple-burst testing would have missed most of them.

The example shows the catalogue in practice: each bug localized by its signature (wrong address sequence for master bugs, hangs/mishandled pauses for slave bugs), mapped to its root cause and fix from earlier chapters, and caught by comprehensive burst verification. The latent nature of these bugs (only manifesting under WRAP, wrong size, early termination, BUSY, boundary crossing) is why comprehensive coverage matters.

8. Common Mistakes

9. Interview Insight

Burst debugging is a synthesizing interview topic — organizing the bugs into master/slave families and knowing the signatures and fixes is the signal.

The answer that lands organizes and gives signatures: "Burst bugs split into two families. Master-side address bugs — where the master generates the wrong address sequence: wrong wrap (using INCR for a cache fill, or wrapping at the wrong boundary), wrong address increment (not scaling by the beat size, so the steps don't match HSIZE), lost or extra beat (off-by-one count), bad SEQ/NONSEQ marking, and a long INCR crossing a decode boundary (not split at 1KB, so it hits a different slave). These show as a wrong address sequence on the waveform, so you debug them by computing the expected sequence from HBURST and HSIZE and diffing against the observed HADDR. Slave-side handling bugs — where the slave mishandles the burst: assuming a fixed-length burst's full beat count and hanging on early termination, or confusing BUSY with IDLE and mishandling the resume. These show as hangs or mishandled pauses, so you debug them by exercising early termination and BUSY and checking the slave tracks HTRANS. And critically, most burst bugs are latent — they only show under specific conditions — so verification must deliberately exercise WRAP, early termination, BUSY, and boundary-crossing INCR." The master/slave organization, the signatures, and the latent-bug verification point are the senior signals.

10. Practice Challenge

Reason from the burst-bug catalogue.

1. Name the families. Give the two families of burst bugs and how each manifests.
2. Read the waveform. From Figure 2, identify the bug and its signature.
3. Map to fixes. For wrong wrap, wrong increment, and assume-the-count, give the fix (and the chapter).
4. Explain latency. Why is a wrong-wrap bug invisible on INCR bursts?
5. Verification plan. List the burst conditions a comprehensive verification plan must exercise.

11. Key Takeaways

• Burst bugs split into two families: master-side address bugs (wrong sequence) and slave-side handling bugs (hangs/mishandled pauses).
• Master-side bugs (wrong wrap, wrong increment, lost/extra beat, bad SEQ/NONSEQ, INCR crossing a decode boundary) show as a wrong address sequence — debug by computing the expected sequence from HBURST/HSIZE and diffing against observed HADDR.
• Slave-side bugs (assuming the full beat count, confusing BUSY with IDLE) show as hangs or mishandled pauses — debug by exercising early termination and BUSY and checking the slave tracks HTRANS.
• Most burst bugs are latent — they only manifest under specific conditions (WRAP, early termination, BUSY, boundary crossing) — so simple-burst testing misses them.
• Burst address bugs cause silent data corruption — data to/from wrong addresses — making them serious and worth rigorous verification.
• Verify comprehensively — exercise all burst types, beat sizes, early termination, BUSY, and boundary-crossing INCR, with assertions and the address formulas as a golden model. Each bug maps to a fix from earlier in the module.

12. What Comes Next

This completes Module 8 — Burst Transfers. You now understand bursts end-to-end: the concept and types, the address math and wrap boundary, the beat size, termination, BUSY, and the bugs. The next module covers the per-transfer size and alignment details:

• Module 9 — Transfer Size and Alignment (coming next) — the full HSIZE encoding, byte/halfword/word transfers and lane usage, alignment rules, and narrow transfers.

To revisit the burst topics these bugs come from, see Burst Overview, WRAP4 & INCR4, Burst Address Calculation, Boundary Wrapping, Burst Termination, and BUSY Cycles Inside Bursts. For the broader protocol map, see the AMBA family overview.