INCR (Undefined-Length) Bursts

Chapter 8.2 covered SINGLE (a one-beat burst). This chapter covers INCR — the undefined-length incrementing burst. Unlike the fixed-length types (INCR4/8/16, WRAP4/8/16, chapters 8.4–8.6), INCR declares no length: it starts with a NONSEQ beat and continues with SEQ beats — each address incrementing by the beat size — for as long as the manager keeps issuing them. The manager signals the burst's end by stopping (issuing an IDLE or a new unrelated transfer), not by declaring a count. So INCR's defining trait is that its length is communicated by stopping, not by declaring. This open-endedness makes INCR ideal for variable or unknown-length streams — DMA transfers of arbitrary size, sequential copies — where the length isn't known up front or doesn't fit a fixed 4/8/16 count.

1. What Is It?

INCR is an undefined-length incrementing burst: it starts with a NONSEQ beat and continues with SEQ beats, each address incrementing by the beat size, with no declared length — it continues for as long as the manager issues beats, and ends when the manager stops.

The two defining facts: (1) the address increments linearly (each beat is the previous plus the beat size, like all INCR-family bursts), and (2) the length is undefined — HBURST=INCR doesn't encode a count (unlike INCR4/8/16). So the manager just keeps issuing SEQ beats until it has moved all the data it needs, then stops — by issuing an IDLE transfer or by starting a new, unrelated transfer (a fresh NONSEQ). The burst's length is exactly however many beats the manager issued before stopping. There's no count to declare and no count for the subordinate to count down — the burst simply runs until the manager ends it.

2. Why Does It Exist?

INCR exists because not all sequential transfers have a known, fixed length — many streams are of variable or arbitrary size — and the fixed-length bursts (4/8/16 beats) can't express those cleanly.

Consider a DMA engine copying a buffer of, say, 100 words, or a stream whose length depends on runtime data. The fixed-length bursts only come in 4, 8, and 16 beats — none of which is 100, and chaining fixed bursts to cover 100 words is awkward and inefficient. What's needed is a burst that can be any length — exactly INCR. So INCR exists to handle the common case of moving a sequential block whose length isn't a convenient 4/8/16 or isn't known in advance. It fills the gap the fixed-length types leave: arbitrary-length sequential movement. Without INCR, variable-length streams would have to be broken into awkward fixed-burst chunks plus leftover single transfers.

The reason the length is signalled by stopping (rather than declaring) is that, for an undefined-length burst, the manager itself may not know the length up front — it streams until done. So there's no count to declare; the natural way to end is to simply stop issuing beats. The manager issues SEQ beats while it has data to move, and when it's done, it stops (IDLE or a new transfer). So INCR's "signal by stopping" mechanism directly fits the use case: a stream whose length emerges as it runs. This is why INCR doesn't (and can't) declare a count — the count isn't necessarily known until the streaming ends.

The tradeoff INCR makes (versus fixed-length) is that the subordinate/memory knows less up front: it doesn't know how many beats are coming, so it can't prefetch an exact count (chapter 8.1). With a fixed-length burst, memory knows "exactly 8 beats" and can prefetch precisely; with INCR, it knows "an incrementing stream, length unknown" and must prefetch speculatively (fetch ahead and stop when the burst stops). So INCR trades the precise prefetch of a declared count for the flexibility of an open-ended length. This tradeoff is why both exist: INCR for flexibility (variable streams), fixed-length for precision (known blocks like cache lines). INCR exists to serve the variable-length case, accepting slightly less memory predictability for its flexibility.

3. Mental Model

Model INCR as pouring water from a jug until the glass is full — you don't announce "I'll pour exactly 8 ounces"; you just pour continuously and stop when done, and the amount is however much you poured.

A fixed-length burst is like ordering "exactly 8 ounces" — you declare the amount up front, and everyone knows precisely how much is coming (the bartender can measure exactly). An INCR burst is like pouring until the glass is full — you don't declare an amount; you just pour continuously (issue SEQ beats) and stop when the glass is full (stop when the data is moved). The amount poured is however much came out before you stopped — not declared, just whatever it ended up being. This suits situations where you don't know the exact amount up front (the glass size varies, the data length varies) — you just pour until done. The "stop when full" is the manager stopping; the "however much you poured" is the burst's emergent length.

This captures INCR: pour until full = stream SEQ beats until done; don't announce the amount = no declared length; stop when full = terminate by stopping (IDLE/new transfer); amount = however much you poured = length is however many beats issued. It fits variable amounts (variable glass sizes) the way fixed-length fits known amounts (a measured 8 ounces).

Watch an INCR burst stream and terminate:

The model's lesson: INCR pours until done — it streams SEQ beats and stops when the data is moved, the length emerging from when it stops. In the waveform, the burst ran three beats then terminated with IDLE; the length wasn't declared, it was however many beats the manager issued before stopping. Open-ended, ended by stopping.

4. Real Hardware Perspective

In hardware, an INCR burst is the manager driving HBURST=INCR and issuing NONSEQ-then-SEQ beats with linearly-incrementing addresses, terminating by changing HTRANS to IDLE (or starting a new NONSEQ) — with the subordinate tracking the burst by HTRANS rather than counting down a known length.

The manager's address generator produces the incrementing sequence: NONSEQ at the start address, then SEQ at start+size, start+2×size, etc., adding the beat size (HSIZE) each beat. This is the same linear increment as the fixed-length INCR types — the only difference is that there's no count, so the manager keeps incrementing until it decides to stop. So the hardware is a simple incrementer driven for as many beats as needed. When the manager has moved its data, it terminates the burst by driving HTRANS=IDLE (or by issuing a new, unrelated NONSEQ transfer). So termination is just the manager changing what it drives on HTRANS — there's no explicit "end of burst" signal.

The subordinate tracks the INCR burst by watching HTRANS, not by counting beats. For a fixed-length burst, a subordinate could count down (8 beats, 7, 6…); but for INCR, there's no count, so the subordinate knows the burst continues while it sees SEQ beats and ends when it sees a non-SEQ transfer (IDLE or a NONSEQ starting something new). So in hardware, the subordinate's burst-tracking for INCR is HTRANS-driven: SEQ means "continuation," and anything else means "this burst is over." This is why HTRANS (NONSEQ/SEQ) is essential — it's how the subordinate follows an undefined-length burst that has no count.

The prefetch behavior differs from fixed-length (chapter 8.1). A memory controller seeing INCR knows the addresses increment but not how many beats — so it prefetches speculatively: fetch ahead of the current beat (the next address is predictable — it's the increment), and stop prefetching when the burst stops (HTRANS goes non-SEQ). So the controller can still prefetch (the address pattern is known), just not a precise count — it fetches ahead and trims when the burst ends. This is slightly less efficient than a known-count prefetch (it might over-fetch by a beat or two when the burst ends), but it still captures most of the benefit. So INCR gets speculative prefetch, fixed-length gets exact prefetch.

A hardware note on HTRANS for the next beat after the last: when the manager terminates, the cycle after the last SEQ beat carries IDLE (or a new NONSEQ). Because of the pipeline (chapter 5.2), the manager drives this termination in the address phase following the last beat it wants. So the manager must know, one beat ahead, that it's ending the burst — it drives the last SEQ beat, then drives IDLE/NONSEQ in the next address phase. This is the same pipeline-ahead behavior as elsewhere: the manager controls the burst's continuation/termination via what it drives on HTRANS in each address phase, one step ahead of the data.

5. System Architecture Perspective

At the system level, INCR is the burst type for variable-length data movement — the bread-and-butter of DMA engines and bulk streaming — where the transfer length is arbitrary, runtime-determined, or simply not a convenient power-of-two.

INCR is the DMA workhorse. DMA engines move blocks of arbitrary size — a 100-word buffer, a packet of runtime-determined length, a scatter-gather segment — and INCR expresses exactly this: stream incrementing beats until the block is done. So INCR is the natural burst for DMA, which dominates bulk data movement in many systems. A DMA engine streams an INCR burst for as long as its transfer count lasts, terminating when done. So at the system level, INCR is how the bulk-movers handle variable-length transfers — the common case for DMA, networking, storage, and streaming. The fixed-length types serve the special case (cache lines); INCR serves the general case (arbitrary blocks).

INCR's flexibility is its system value: because it can be any length, it adapts to whatever the system needs to move, without forcing the data into fixed 4/8/16 chunks. So a system using INCR can move a block of any size in a single logical burst, rather than decomposing it into fixed bursts plus leftovers — simpler and often more efficient. This adaptability is why INCR is so widely used: real data comes in arbitrary sizes, and INCR handles them directly. The cost (slightly less precise memory prefetch) is usually worth the flexibility for variable-length traffic.

A system consideration is burst length management: while INCR can be arbitrarily long, very long bursts hold the bus/path for a long time, which can starve other masters or increase latency (chapter 8.1's length tradeoff). So systems often bound INCR burst length — a DMA engine might break a huge transfer into INCR bursts of a maximum length (e.g., bounded by an interconnect's limits or to allow arbitration fairness), rather than one enormous burst. So even though INCR is undefined-length, practical systems cap it for fairness and latency. This is a system-level policy on top of the protocol's open-endedness: INCR can be unbounded, but real systems bound it to balance throughput against responsiveness. (Related boundary rules — e.g., not crossing certain alignment boundaries — also constrain INCR length, detailed in later chapters and in AXI.)

So INCR's system role is the flexible, variable-length workhorse — serving DMA and bulk streaming with arbitrary-length transfers, adapting to real data sizes, with practical systems bounding its length for fairness. It's the most generally useful burst type, complementing the fixed-length types' specialized roles.

6. Engineering Tradeoffs

INCR embodies the flexibility-over-precision choice.

• Undefined-length (INCR) vs fixed-length. INCR handles any length (flexible, adapts to real data) at the cost of less-precise memory prefetch (speculative, not exact-count). Fixed-length gives exact prefetch but only in 4/8/16 beats. INCR for variable streams, fixed-length for known blocks — both exist for their respective cases.
• Signal-by-stopping vs declare-count. Signaling length by stopping fits streams whose length emerges at runtime (the manager may not know it up front) at the cost that the subordinate must track via HTRANS rather than counting. Declaring a count is more predictable but requires knowing the length in advance. INCR signals by stopping — fitting the variable-length use case.
• Speculative vs exact prefetch. INCR's known address pattern allows speculative prefetch (fetch ahead, trim at the end) but may over-fetch slightly at termination. Exact-count prefetch (fixed-length) never over-fetches. The small over-fetch is an acceptable cost for INCR's flexibility.
• Unbounded capability vs bounded practice. INCR can be arbitrarily long (maximal amortization) but very long bursts hurt fairness/latency, so systems bound it. The protocol allows unbounded; practice caps it — balancing throughput against responsiveness.

The throughline: INCR is the undefined-length incrementing burst — flexible enough to move any-length sequential block, with its length signalled by stopping rather than declared. It trades the exact-count prefetch precision of fixed-length bursts for open-ended flexibility, making it the workhorse for variable-length data movement (DMA, streaming). Real systems bound its length for fairness while keeping its flexibility. It's the general-purpose burst, complementing the specialized fixed-length types.

7. Industry Example

Trace INCR bursts across variable-length data movement.

A system's DMA engine, network controller, and storage controller all move variable-length blocks using INCR.

• DMA buffer copy — INCR of arbitrary length. The DMA engine copies a 100-word buffer. It issues an INCR burst, streaming SEQ beats with incrementing addresses, for 100 beats (or bounded chunks), then terminates. The length (100) isn't a fixed 4/8/16, so INCR is the natural fit — it streams exactly the needed length. A fixed-length burst couldn't express 100 cleanly.
• Network packet — INCR of runtime length. The network controller transfers a received packet whose length is determined at runtime (it depends on the packet). It streams an INCR burst for the packet's length, terminating when the packet is done. The length wasn't known until the packet arrived — INCR's signal-by-stopping handles this perfectly: stream until the packet ends.
• Storage block — INCR streaming. The storage controller reads a block of data, streaming it as an INCR burst. Again, variable/large length, handled by INCR.
• Speculative prefetch. The memory controller, seeing these INCR bursts, prefetches speculatively — fetching ahead along the known incrementing pattern, and trimming when each burst terminates. It gets most of the prefetch benefit despite not knowing the exact count. The bursts run at high bandwidth.
• Bounded for fairness. The DMA engine, copying a huge buffer, doesn't issue one enormous INCR burst (which would hold the bus too long and starve other masters); instead it breaks the transfer into bounded INCR bursts (e.g., capped length), re-arbitrating between them to allow fairness. So the system bounds INCR length in practice, balancing the DMA's throughput against other masters' latency.
• Contrast: a cache fill uses WRAP, not INCR. Meanwhile, a CPU cache fill (a known, aligned, fixed-size block) uses a WRAP burst (chapter 8.4), not INCR — because the cache line is a fixed size and wants wrapping. So INCR serves the variable-length movers (DMA, network, storage), while WRAP serves the fixed cache fills. Each burst type to its use case.

The example shows INCR as the variable-length workhorse: DMA copies of arbitrary size, runtime-length packets, storage blocks — all streamed as INCR bursts, with speculative prefetch and practical length-bounding for fairness. The fixed-length WRAP serves cache fills instead. INCR's flexibility is exactly what these variable-length movers need.

8. Common Mistakes

9. Interview Insight

INCR is a common interview topic — it tests whether you understand undefined-length bursts and the signal-by-stopping mechanism.

The answer that lands explains the open-endedness and its use: "INCR is the undefined-length incrementing burst. It starts with a NONSEQ beat and continues with SEQ beats, each address incrementing by the beat size, but it declares no length — it keeps streaming for as long as the manager issues beats, and ends when the manager stops, by issuing an IDLE or starting a new transfer. So the length is signalled by stopping, not by declaring a count — which is different from INCR4/8/16, which declare a fixed beat count. This open-endedness makes INCR ideal for variable or unknown-length streams: DMA copies of arbitrary size, runtime-length packets — anything that doesn't fit a fixed 4/8/16 or isn't known up front. The subordinate tracks the burst via HTRANS, since there's no count to count down, and memory prefetches speculatively off the known incrementing pattern." The signal-by-stopping mechanism, the variable-length use case, and the HTRANS-tracking are the senior signals.

10. Practice Challenge

Reason from INCR's open-endedness.

1. Define INCR. Explain what makes INCR an undefined-length burst.
2. Termination. Describe how an INCR burst ends and how the length is determined.
3. Read the waveform. From Figure 2, identify the burst's beats, its termination, and its length.
4. Subordinate tracking. Explain how a subordinate follows an INCR burst without a count.
5. Use case. Give an example where INCR is the right choice and explain why a fixed-length burst wouldn't fit.

11. Key Takeaways

• INCR is an undefined-length incrementing burst — NONSEQ then SEQ beats, each address += beat size, continuing as long as the manager issues beats.
• The length is signalled by stopping, not declared — the manager terminates by issuing an IDLE or a new transfer; the length is however many beats it issued.
• The subordinate tracks the burst via HTRANS (SEQ = continue, non-SEQ = ended), since there's no count to count down.
• Memory prefetches speculatively off the known incrementing address pattern (trimming at termination), versus the exact-count prefetch of fixed-length bursts.
• INCR is the workhorse for variable-length data movement — DMA, network, storage — where the length is arbitrary, runtime-determined, or not a convenient 4/8/16.
• Practical systems bound INCR length for arbitration fairness and latency, even though the protocol allows it unbounded.

12. What Comes Next

You now understand the undefined-length burst. The next chapters cover the fixed-length types and the wrapping behavior:

• 8.4 — WRAP4 & INCR4 Bursts (coming next) — the 4-beat fixed-length bursts, introducing the WRAP wrapping mechanics concretely.
• 8.5 / 8.6 (coming soon) — the 8-beat and 16-beat bursts.

To revisit the burst concept, see Burst Overview; for the base case, SINGLE Transfers. For the beat marking INCR relies on, see SEQ Transfers and NONSEQ Transfers. For the HBURST signal, see HBURST. For the broader protocol map, see the AMBA family overview.