Ping Pong Buffer Design: The Handover Rules That Stop Tearing

A ping pong buffer looks trivial on a block diagram: two memory banks, one being written while the other is read, and a swap at the end of every frame. In practice almost every failure in such a design happens at the swap rather than inside the memory. The buffer is a scheduling problem wearing the costume of an addressing problem.

The purpose of the arrangement is that the reader never sees a partially written version. The bandwidth saving, the pipeline overlap and the smooth video all follow from that single guarantee. Where the handover is loose, the result is frame tearing: frames that appear intermittently torn, move when the input timing changes, and are hard to attribute to anything.

What the Two Banks Actually Buy You

Both banks together are not a faster memory. The total bandwidth the controller can deliver is unchanged, and the memory timing does not improve because there are two of them. What changes is that the read side and the write side work on different regions at the same time, so each stops waiting for the other.

That distinction matters when the load is unbalanced. If the average write rate is persistently higher than the read rate can drain, a second bank postpones overflow but cannot remove it. The system still needs a policy: drop a frame, overwrite the oldest, apply back pressure to the source, or add real depth. Choosing a buffer instead of a policy simply moves the failure later in the day.

The Cycle That Must Not Break

A safe ownership handover has five steps, and skipping any one of them is how tearing gets in. The writer updates only the bank that is currently free, using an address it owns outright. When the last word is actually committed, the writer raises a completion flag. A data driven flag is essential, because a software delay that guesses how long a frame takes will be wrong the moment the frame rate changes.

If the two sides run on different clocks, the clock domain crossing must be handled with a synchroniser, a handshake or an asynchronous FIFO rather than a bare register. A single control block then swaps ownership at a boundary both sides agree on. Finally, the writer waits until the reader confirms it has released the old bank before overwriting it.

The Four Ways Ownership Goes Wrong

The first is a completion flag raised too early. The control logic announces the frame as ready when the final burst is still in flight, and the reader starts on a bank whose tail is incomplete.

The second is a cross domain swap taken directly. The write side and the read side tick on different clocks, so the flag and the pointer must cross through synchronising logic. A register that happens to work on the bench will eventually produce a metastable read at temperature or at a different clock ratio.

The third is simultaneous ownership. Where both sides are allowed to update a flag, each can act on a stale copy and both may decide to write the same bank, or both may read it.

The fourth is a mismatch in the definition of a boundary. The writer swaps on a line, the reader assumes a frame, and the data is displaced by a constant offset that looks like a broken sensor.

None of these shows up in a static review of the block diagram. They show up under a clock ratio that differs from the one used in the lab, which is why the verification plan has to include a deliberately mismatched rate rather than only the nominal one.

Verification That Goes Past the Picture

A display that shows a moving image proves very little. A better test plan injects a monotonically increasing sequence number into each frame or block and then checks the received sequence at the far end. Any duplicate, gap or reordering is then a specific number rather than an impression.

Vary the rate deliberately in both directions. Run the writer slightly faster than the reader and confirm the drop policy behaves as documented; run it slightly slower and confirm that no stale half frame reaches the output. Then reset the system at random points, including a reset that lands in the middle of a handover, and check that both banks agree on ownership afterwards. A reset is the cheapest way to expose an ownership rule that was only implied.

Worth stating explicitly in the design review as well: what the flag means, who is allowed to set it, and what the reader is permitted to assume once it is set. Written that way, the buffer behaves like a small state machine, and the state machine can be reviewed. Left implicit, the same logic is a source of intermittent faults that no one can reproduce.

Where the Buffer Sits in the Hardware

The place the ping pong buffer is implemented matters as much as the logic. On an FPGA with embedded block memory, the banks cost nothing external and the swap is a few clock cycles, but the design is now tied to that device. On a processor with a frame placed in SDRAM, the buffer competes with every other memory access and must be accounted for in the memory budget rather than assumed.

Where the buffering runs at the board level, the choice of memory and the length of the traces carrying the pixel or sample stream become part of the timing budget. Length matched traces, a controlled impedance and a clean reference plane are what keep a wide parallel interface working at the rate the buffer needs, and they are the same high speed layout rules that apply across the rest of the board.

The practical test is to ask what happens at the frame rate you intend to ship with, not at the rate you are prototyping with. A buffer sized for a 1080p stream at 30 frames per second is not automatically adequate for the same camera running at 120, and the difference shows up as a drop policy firing constantly rather than as a clean failure.

FAQ

Does a ping pong buffer increase throughput? No. It increases overlap and removes waiting. The memory controller still sets the ceiling.

Can it remove frame drops completely? Only while the writer stays at or below the drain rate. Beyond that it needs a drop or back pressure policy.

Is a completion flag enough on its own? No. It has to be raised after the last write is committed and, across clock domains, passed through proper synchronising logic.

Why does the fault only appear sometimes? Because it usually depends on the relative clock ratio and on the exact moment a reset or a swap occurs.

Summary

A ping pong buffer is worth the extra bank only if the ownership rules are as explicit as the addresses. Decide who raises the completion flag, how that flag crosses a clock domain, which block arbitrates the swap, and when the old bank may be overwritten, then verify with sequence numbers and mismatched rates instead of a moving picture. Get those four rules into a state machine and the double buffer stops being a mystery and becomes a component you can review, measure and trust. The same discipline applies upstream: confirm the process and the quality records that stand behind the board the buffer runs on. The same discipline applies upstream: confirm the process and the quality records that stand behind the board the buffer runs on.