When a casting design misses its performance target, the first suspect is the radio. In our experience the radio is rarely the problem. The memory subsystem was sized from a specification sheet rather than from the pixel pipeline, and the gap appears only when the source sends content harder to decode than the demo clip.

A receiver does three memory-intensive things at once: buffering compressed frames, decoding them into reference and output frames, and scanning out to the display. Each carries a capacity cost and a bandwidth cost, and they compete for the same DDR channel. Getting the arithmetic roughly right at the schematic stage is far cheaper than discovering it in a customer demo.

Start with the frame

One uncompressed 1080p frame in YUV 4:2:0 at 8 bits occupies about 3.1 MB: 1920 × 1080 pixels at 1.5 bytes per pixel. Everything else scales from it.

• Double-buffered output: about 6.2 MB. Triple-buffered, which you want if tearing is unacceptable: about 9.3 MB.

• A decoder holding eight reference frames for H.264: about 25 MB.

• At 60 fps, scan-out alone reads 186 MB/s, and the decoder writes a comparable amount.

Against that, a single x16 DDR3 at 1600 MT/s offers 6.4 GB/s theoretical across a 16-bit bus. Real efficiency on a mixed read-write workload with refresh overhead lands at 55 to 70 percent, so 3.5 to 4.5 GB/s usable. For a pipeline needing 600 to 900 MB/s sustained, comfortable. For four concurrent 4K sessions, not.

The point is not precision. It is establishing the order of magnitude before choosing a density, because 1Gb versus 2Gb changes the BOM and the layout.

Capacity and bandwidth are separate budgets

Capacity failures are visible and early. If frame buffers, decoder workspace, OS, application and network buffers exceed the density, the system fails to allocate at init or starts swapping, which destroys latency. These surface in bring-up and are fixed by moving up a density.

Bandwidth failures are intermittent and late. When aggregate demand exceeds what the controller can deliver at acceptable latency, the symptoms are dropped frames, audio desync, occasional freezes and underruns under load that never appear on the bench. These turn up in the field, on specific content, often after the design has been approved.

A budget that only lists capacity is half a budget. The useful version has two columns: megabytes required, and megabytes per second sustained. For one 1080p60 session on a mid-range casting SoC:

Consumer of memory	Capacity	Sustained bandwidth
Display output frames (triple buffered)	~9 MB	~190 MB/s read
Decoder reference and workspace	20–30 MB	~200–300 MB/s read/write
Operating system and application	40–60 MB	~100 MB/s
Network receive buffers	4–8 MB	~20 MB/s
Graphics and scaling	8–16 MB	~100 MB/s
Total	~90–130 MB	~600–700 MB/s

A 1Gb device provides 128 MB. That fits with very little margin, and the margin disappears the moment a second session opens or the application grows. 2Gb provides 256 MB and enough headroom that the design does not need revisiting for every feature.

Where 1Gb stops being enough

1Gb is a legitimate choice, and much of the shipping 1080p30 volume uses it. It stops being right in three situations.

Resolution steps up. A 4K30 frame is 12.4 MB uncompressed, so triple buffering alone is 37 MB and reference frames scale with it. Bandwidth roughly doubles. Capacity is not a 4x problem, but a 2x problem leaves no room for the operating system.

Session count increases. Two simultaneous casters need two decode pipelines: capacity and bandwidth both roughly double. Contention becomes a scheduling problem, and the controller's QoS configuration starts to matter as much as raw bandwidth.

The application grows. Casting products rarely stay casting products. A browser, a media player, an animated pairing UI or a screenshot feature each consumes memory the original budget did not include. A 128 MB design with 90 MB committed has nowhere to go.

The thermal interaction

DDR3 timing margins shrink as temperature rises, more so near the top of the speed bin. A design validated at 25 °C on a bench may run for hours at 70 °C in a chamber and then produce occasional correctable errors, or uncorrectable ones if the margin was thin.

Two consequences. Validate the timing budget at the temperature extremes the product will see, not at room temperature with a fan pointed at the board. And if the design already runs near the bandwidth limit, the controller pushes the channel harder and the margin gets thinner, so bandwidth headroom and thermal margin are not independent.

A casting dongle in a closed plastic housing behind a television is one of the less forgiving thermal environments in consumer electronics. Sizing with 30 to 40 percent bandwidth headroom rather than 10 percent buys tolerance for both temperature and firmware growth.

1866 over 1600, and when it matters

DDR3-1866 on a 32-bit bus gives about 7.5 GB/s theoretical against 6.4 GB/s at 1600, roughly 17 percent more, and usable bandwidth scales similarly. That matters for a single 4K30 session, two concurrent 1080p60 sessions, and any design where the display controller scales or composes in memory rather than in a dedicated block. It matters little for one 1080p30 session.

The cost is real. Faster bins narrow the pool of qualified devices, cost more per gigabit, and tighten layout: a board that runs at 1600 may show margin problems at 1866 if traces and reference planes were designed to the looser specification. A reasonable default for a new 1080p60 design is to lay out for 1866, populate with what the supply chain supports, and validate both bins at bring-up.

Bus width is a separate lever

Bandwidth comes from bus width and clock, not density. One x16 device at 1866 delivers half the bandwidth of two x8 devices at 1866 on a 32-bit bus, at the same total capacity if the densities are chosen correctly.

Above 1080p30, 32-bit is the usual choice because it adds headroom without a faster clock. The trade is two devices, more routing and slightly more board area: difficult on a two-layer dongle, straightforward on a four-layer set-top box. Matched trace lengths across both devices and controlled impedance on the shared command and address bus are easiest to design in from the first revision.

The practical checklist

1. Highest resolution and frame rate in the field, not in the demo?

1. How many simultaneous sessions, and does the SoC support independent decode pipelines?

1. Sustained bandwidth of the worst-case content, and what fraction of usable DDR bandwidth?

1. Temperature at the memory device in the actual enclosure under continuous load?

1. Memory the application will need after two years of firmware updates?

1. Second source for the device, and does the layout accept it?

If the answers leave under 30 percent headroom in either capacity or bandwidth, the design is sized for today and will be revisited. That can be the right commercial decision. It should be a decision, not an oversight.

We work with casting and display teams on memory configuration, from density and bus width through qualification across temperature. If you are at the schematic stage and want a second opinion on the budget, that conversation is short and occasionally saves a board revision.