Burst Testing

After wait states, bursts are the second-richest source of subtle AHB bugs — and like waits, the bugs hide in corners a casual test never reaches. Burst testing systematically verifies every burst type (SINGLE, the undefined-length INCR, the fixed-length INCR4/8/16, the wrapping WRAP4/8/16) across every size (byte, halfword, word, larger) — because the address calculation interacts with the size. For each combination, a burst checker verifies: the address increments or wraps correctly beat by beat, the beat count matches the burst type, and the burst doesn't cross its boundary; meanwhile the scoreboard (17.4) checks the data. The highest-value corners — where burst bugs live — are: a wrapping burst starting at the top of its region (so it wraps on the first beat — the classic case), BUSY cycles between beats, early burst termination, and bursts combined with wait states. The classic bug is a wrong wrap boundary (the address increments past the boundary instead of wrapping) — which only shows if the burst starts near the top of its region (a bottom-start increments normally and never exercises the wrap). This chapter builds burst testing.

1. What Is It?

Burst testing is targeted verification of all burst types, sizes, and boundary corners. Its parts:

• Every type × size — SINGLE, INCR, INCR4/8/16, WRAP4/8/16, each at byte/halfword/word/larger (the address calc interacts with size).
• The burst checker — verifies the address sequence (increment/wrap), the beat count matches the type, and no boundary crossing, per beat.
• The corners — wrap-from-the-top (wraps on beat 1), BUSY between beats, early termination, bursts + waits.
• Checker + scoreboard — the burst checker checks the address pattern; the scoreboard checks the data.

So burst testing is the systematic exercise of AHB's most structurally complex transfers. A burst isn't one transfer — it's a sequence of beats with a specific address pattern (increment for INCR, wrap for WRAP) determined by the type, length, and size. The complexity is combinatorial: 8 burst types × several sizes × boundary positions × interactions (BUSY, waits, termination). And the address calculation — especially the wrap — is easy to get wrong (the classic wrap-boundary bug). So burst testing enumerates the type × size matrix, drives each combination (with the corner conditions), and checks both the address pattern (a burst checker — does the address increment/wrap per the expected pattern? does the beat count match?) and the data (the scoreboard). The key insight (mirroring wait-state testing) is that the bugs hide in corners: a wrap bug only shows if the burst starts near the top of its region; a BUSY bug only shows if BUSY is inserted. So burst testing deliberately drives those corners. So burst testing is the systematic exercise of every burst combination and corner. So it's how you find burst bugs.

2. Why Does It Exist?

Burst testing exists because bursts have combinatorial structural complexity (type × length × size × position) that can't be covered by casual tests, because the address calculation (especially wrap) is error-prone and its bugs hide in corners, and because the interactions (BUSY, waits, termination) add further corners — so systematic, corner-driven burst testing is the only way to verify them.

The combinatorial complexity is the root: a burst is defined by type (8 of them), length (implied by type), size (several), and start address (which determines the wrap behavior). That's a large combination space — and each combination has a specific expected address pattern. A casual test (a few bursts) covers a tiny fraction, missing most. So burst testing exists to systematically cover the matrix. So it's the combinatorial coverage. So complexity demands systematic testing.

The address calculation is error-prone drives the corner focus: the burst address calculation — especially the wrap (modular arithmetic within a region whose size depends on the burst length × beat size) — is easy to get wrong. And the wrap bug (wrong boundary) only manifests if the burst exercises the wrap — i.e., starts near the top of its region. A burst that starts at the bottom increments (never wraps), so it hides the bug. So burst testing must deliberately drive the corner (wrap-from-the-top) to expose the error-prone calculation. So it exists to target the address-calc corners. So it's corner-driven. So error-prone calc needs corner testing.

The interactions add corners is the completeness: bursts interact with other features — BUSY cycles (the master pausing mid-burst — does the slave hold?), wait states (the slave stalling mid-burst — does the burst resume correctly?), early termination (the burst ending early — does the slave handle it?). Each interaction is a corner with its own potential bugs. So burst testing must drive these interactions too. So it exists to cover the interaction corners. So it's comprehensive. So interactions need testing. So burst testing exists because: bursts have combinatorial structural complexity (type × length × size × position — too much for casual tests — the why); the address calculation (especially wrap) is error-prone and its bugs hide in corners (wrap-from-the-top — the targeting); and interactions (BUSY, waits, termination) add further corners (the completeness). So burst testing is the systematic, corner-driven verification of every burst combination and interaction — the second-highest-ROI targeted testing (after waits), exposing the error-prone address-calculation and interaction bugs that hide in the burst corners. So this chapter drives those corners. So test every combination, especially the corners.

3. Mental Model

Model burst testing as testing a delivery route planner that must visit a fixed set of addresses in a specific pattern — and especially testing the wrap-around routes. A simple route (increment: 12, 16, 20, 24) is easy to verify. But a wrap-around route (a loop that must return to the start of its zone after the boundary: 12, 0, 4, 8) is where the planner's boundary arithmetic gets tested — and you only test it by starting near the boundary so the wrap actually happens. A test that always starts a wrap route at the bottom of its zone never triggers the wrap, so the boundary bug never shows.

A delivery route planner (the burst address logic) that must visit a fixed set of addresses in a specific pattern determined by the route type. There are several route types. A single stop (SINGLE) is trivial. An open-ended sequential route (INCR — undefined length) just keeps incrementing. A fixed sequential route (INCR4/8/16) visits a fixed number of incrementing addresses. And — the tricky one — a wrap-around route (WRAP4/8/16) that must loop back to the start of its zone when it hits the boundary. Verifying the simple routes is easy: a sequential route from 12 visits 12, 16, 20, 24 — obviously correct. But the wrap-around route is where the planner's boundary arithmetic is really tested: a WRAP4 (word) route in the 0–15 zone, starting at 12, must visit 12, then wrap to 0, then 4, then 8 — returning to the start of its zone. This is easy to get wrong — a buggy planner might increment past the boundary (12, 16, 20, 24 — leaving the zone) instead of wrapping (12, 0, 4, 8). And here's the crux: you only test the wrap arithmetic by starting the route near the boundary (at 12, near the top of the 0–15 zone) so the wrap actually happens. If you always start a wrap route at the bottom of its zone (at 0), it just increments (0, 4, 8, 12) and never wraps — so the boundary bug never shows. So to test the planner, you must deliberately start wrap routes near the top of their zones, across every zone size (4/8/16 stops) and every stop size (byte/half/word), and verify each visited address against the expected pattern. And you also test interruptions — a pause mid-route (BUSY), a delay at a stop (wait state), an early end (termination).

This captures burst testing: the route planner = the burst address logic; the route types = the burst types (SINGLE/INCR/WRAP); the simple sequential route = INCR (easy to verify); the wrap-around route = WRAP bursts; the boundary arithmetic = the wrap calculation; incrementing past the boundary = the wrong-wrap bug; starting near the top so the wrap happens = driving wraps from the top of the region; always starting at the bottom hiding the bug = bottom-start never exercising the wrap; every zone size × stop size = every burst length × size; verifying each visited address = the burst checker; pause/delay/early-end = BUSY/wait/termination corners. Test the wrap routes by starting near the boundary, across every zone and stop size, verifying each stop.

Watch the burst checker catch a wrong-wrap bug:

The model's lesson: test the wrap routes by starting near the boundary, across every zone and stop size, verifying each stop. In the waveform, the WRAP4 burst starting at 12 (the top of its region) exposes the wrong-wrap bug — beat 1 should wrap to 0 but increments to 16, and the burst checker catches it. A bottom-start would have hidden it.

4. Real Hardware Perspective

In the testbench, burst testing is implemented by a burst-capable sequence (generating each type/size/start, biased to cover the matrix and corners), a burst checker (computing the expected address sequence and comparing per beat), the scoreboard (per-beat data), and coverage on the burst × size × corner crosses.

The burst-capable sequence: the stimulus generates bursts of every type and size, with constrained-random start addresses biased to include the top-of-region starts (to exercise wraps) — constraint c_wrap_top { burst inside {WRAP4,WRAP8,WRAP16} -> addr near top of region; }. It also interleaves BUSY cycles, wait states, and (where supported) early termination. So in the testbench, the sequence drives the matrix + corners. So it's burst generation. So that's the stimulus.

The burst checker: a burst checker (often part of the monitor/scoreboard, or a dedicated checker) computes the expected address sequence from the declared HBURST, HSIZE, and start address — for INCR, addr + n*size; for WRAP, the modular wrap within the (burst_len × size)-byte region — and compares each beat's actual HADDR against it, firing on a mismatch (with the beat, expected, actual). It also checks the beat count matches the type and the burst stays in bounds. So in the testbench, the burst checker validates the address pattern. So it's the address check. So that's the burst-specific check.

The scoreboard + coverage: the scoreboard (17.4) checks each beat's data (a burst is N writes/reads — each data value tracked/compared). And coverage (17.5) confirms the matrix was covered — cp_burst × cp_size (every type at every size), plus corner coverpoints (wrap-from-top, BUSY-in-burst, burst-with-wait). If the report shows a hole (e.g. WRAP16 × byte unhit), you bias toward it. So in the testbench, burst testing is a matrix+corner sequence + a burst checker (address pattern) + the scoreboard (per-beat data) + coverage (the burst crosses). The skill is computing the expected address pattern correctly (the checker must itself be right) and driving the corners (especially wrap-from-the-top). So in the testbench, check the address pattern, drive the corners, confirm via coverage. So that's the implementation.

5. System Architecture Perspective

At the system level, burst testing is essential because bursts are the performance-critical, structurally-complex heart of AHB traffic — and a burst bug corrupts bulk data transfers (the most consequential failures); the burst checker is a reusable VIP component, and burst testing is the second pillar (after waits) of thorough AHB verification.

The bulk-transfer criticality: bursts carry the bulk of a system's data (cache line fills, DMA transfers, block moves). So a burst bug — a wrong wrap, a miscounted beat — corrupts bulk data (a whole cache line loaded wrong, a DMA writing to wrong addresses). These are high-consequence failures. So at the system level, burst correctness is critical (it's the bulk data path). So bursts matter most for throughput-correctness. So test them thoroughly.

The reusable burst checker: the burst checker (compute-expected-pattern, compare-per-beat) is a reusable component — the same checker validates any AHB master/slave's burst behavior (configured for the burst types/sizes supported). It's part of the VIP (17.11). So at the system level, burst testing is a reusable capability. So it's VIP infrastructure. So build the checker once.

The second verification pillar: with waits (17.7) as the first pillar of targeted testing, bursts are the second — together they cover the two structurally-complex dimensions (timing variation and address sequencing) where most AHB bugs hide. So at the system level, burst testing is essential (bursts are the bulk-transfer, structurally-complex heart of AHB — burst bugs corrupt bulk data, the highest-consequence failures), a reusable VIP capability (the burst checker, configured per design), and the second pillar of thorough verification (with waits — together covering timing and address-sequencing). So burst testing is where the bulk data path is verified — the systematic, corner-driven stress that protects the most consequential transfers, completing (with wait-state testing) the core of high-quality AHB verification. So test the bursts thoroughly — the bulk data depends on it. So bursts are the second pillar.

6. Engineering Tradeoffs

Burst testing embodies the matrix-coverage, corner-driven, address-checked design.

• Full matrix vs sample. Covering the full type × size matrix catches combination-specific bugs (a burst wrong at one size); sampling misses them. Cover the full matrix (with coverage confirming).
• Wrap-from-the-top vs bottom-start. Starting wraps at the top of their region exercises the wrap (exposes wrap bugs); bottom-start increments (hides them). Always include top-of-region wrap starts.
• Burst checker (address pattern) vs scoreboard-only. A burst checker validates the address sequence/beat count (catches wrong-wrap/miscount); the scoreboard alone catches data errors but may miss a pattern error that happens to read consistent data. Use both.
• Corner conditions vs clean bursts. Driving corners (BUSY, waits, termination, top-start) finds interaction bugs; clean bursts miss them. Drive the corners.

The throughline: burst testing systematically verifies every burst type (SINGLE/INCR/INCR4-8-16/WRAP4-8-16) across every size, with a burst checker validating the address pattern (increment/wrap correct per beat, beat count matches the type, no boundary crossing) and the scoreboard validating the data — deliberately driving the corners where burst bugs hide. The highest-value corner is a wrapping burst starting at the top of its region (so it wraps on the first beat — exposing the classic wrong-wrap bug, which a bottom-start hides); others are BUSY between beats, early termination, and bursts + waits. It's driven by constrained-random (17.6, biased to the matrix/corners) and confirmed by coverage (17.5, on the burst × size crosses). It's essential (bursts carry the bulk data — burst bugs corrupt bulk transfers), a reusable VIP capability, and the second pillar of targeted testing (with waits).

7. Industry Example

Run burst testing on a memory slave and watch it catch a wrap bug a casual test missed.

You're verifying a memory slave (16.3) that supports all burst types. You set up matrix + corner burst testing.

• The matrix. Constrained-random (17.6) generates every burst type (SINGLE, INCR, INCR4/8/16, WRAP4/8/16) at every size (byte, halfword, word), covering the full cp_burst × cp_size matrix.
• Wrap-from-the-top. Critically, the stimulus is biased to start wrapping bursts near the top of their regions — so a WRAP4 word burst starts at offset 12 (in its 0–15 region), a WRAP8 at offset 28 (in its 0–31 region), etc. — exercising the wrap within the burst.
• The burst checker. A burst checker computes the expected address sequence from (HBURST, HSIZE, start) — the modular wrap for WRAP, the increment for INCR — and compares each beat's HADDR.
• A wrap bug caught. The memory slave's address generator (or a wrapping master) has the classic wrong-wrap bug — for a WRAP4 word from 12, it produces 12, 16, 20, 24 (incrementing past the boundary) instead of 12, 0, 4, 8. The burst checker fires at beat 1 (expected 0, actual 16). Critically, this only surfaced because the burst started at 12 (top of region); the earlier casual tests started WRAP bursts at 0, which incremented 0, 4, 8, 12 in both correct and buggy designs — hiding the bug.
• The corners. The test also drives BUSY between beats (the slave must hold the burst), wait states mid-burst (the burst must resume correctly), and early termination — each checked.
• Coverage confirmation. The cp_burst × cp_size matrix and the corner coverpoints (wrap-from-top, BUSY-in-burst, burst-with-wait) are closed — confirming the burst space was exercised, including the wrap corners.

The example shows burst testing catching the classic wrap bug — only because it deliberately started the wrap at the top of its region (which the casual bottom-start tests missed) — with the burst checker validating the address pattern and coverage confirming the matrix and corners. This is the bulk-data path verified. This is the second pillar.

8. Common Mistakes

9. Interview Insight

Burst testing is a high-signal verification interview topic — the wrap-from-the-top insight, the matrix coverage, and the independent-burst-checker discipline are the signals.

The answer that lands gives the wrap-from-the-top insight and the matrix: "Burst testing verifies every burst type across every size, plus the boundary corners. The types are SINGLE, the undefined-length INCR, the fixed-length INCR4, 8, 16, and the wrapping WRAP4, 8, 16. I test each at every size — byte, halfword, word — because the address calculation interacts with the size, so a burst that's correct at word can be wrong at byte. For each combination, I use a burst checker that computes the expected address sequence from the burst type, size, and start address — incrementing for INCR, modular wrapping for WRAP — and compares each beat's actual address against it, while the scoreboard checks the data per beat. The single most important thing is exercising the wrap. The classic burst bug is a wrong wrap boundary — the design increments past the boundary, like 12, 16, 20, 24, instead of wrapping, 12, 0, 4, 8. But this only shows if the burst actually wraps, which means it has to start near the top of its region. If you always start wrapping bursts at the bottom of their region, at address 0, they just increment and stay in bounds, so the correct and buggy designs produce the same sequence and the bug is invisible. So I deliberately start wrapping bursts at or near the top of their region, at various offsets, so the wrap happens within the burst. I also drive the interaction corners — BUSY cycles between beats, wait states mid-burst, early termination. And one subtlety: the burst checker itself has to compute the wrap arithmetic correctly and independently — if its wrap calculation has the same bug as the design, it'll false-pass, like a non-independent scoreboard. So I verify the checker against known-correct and known-buggy bursts. And I confirm via coverage that the full burst-by-size matrix and the corner cases were actually hit." The wrap-from-the-top insight, the matrix coverage, and the independent-checker discipline are the senior signals.

10. Practice Challenge

Build and reason from burst testing.

1. The matrix. List the burst types and explain why each must be tested at every size (the address calc interacts with size).
2. Wrap-from-the-top. Explain why wrapping bursts must start near the top of their region, and the bug a bottom-start hides.
3. Read the waveform. From Figure 2, explain how the burst checker catches the wrong-wrap bug (12,16,20,24 vs 12,0,4,8) at beat 1.
4. Checker + scoreboard. Explain why you need both a burst checker (address pattern) and a scoreboard (data), and why the checker must be independent.
5. The corners. Describe the interaction corners (BUSY, waits mid-burst, early termination) and why each matters.

11. Key Takeaways

• Burst testing covers every type × size — SINGLE/INCR/INCR4-8-16/WRAP4-8-16 at byte/halfword/word — because the address calculation interacts with the size (a burst correct at word can be wrong at byte).
• Drive wraps from the top of their region — the classic wrong-wrap bug (incrementing past the boundary) only shows if the burst actually wraps; a bottom-start increments and hides it. The single most important burst technique.
• Use a burst checker AND a scoreboard — the burst checker validates the address sequence/beat count (catches wrong-wrap/miscount); the scoreboard validates the data. Complementary.
• The burst checker must be independent and correct — a checker with the same wrap bug as the DUT false-passes (the non-independent-model trap from 17.4). Implement it independently and verify it.
• Drive the interaction corners — BUSY between beats (slave must hold), wait states mid-burst (burst must resume), early termination (clean handling). Each has its own bugs.
• It's the second pillar (with waits) — bursts carry the bulk data (cache fills, DMA), so burst bugs are high-consequence; confirm the matrix/corners via coverage (cp_burst × cp_size).

12. What Comes Next

You now can verify the bulk-transfer path. The next chapters target errors and the bridge, then assemble the VIP:

• Error-Response Testing (next) — drive and verify ERROR scenarios (and the two-cycle sequence).
• Bridge Verification and the UVM AHB Agent — verify the bridge end-to-end and package the reusable agent.

To revisit the burst rules this checks, see Burst Address Calculation, Boundary Wrapping, and BUSY Cycles Inside Bursts; for the stimulus and confirmation, see Constrained-Random AHB Traffic and AHB Functional Coverage.