Why model a JPEG decoder in C++ first?
Because the C++ model is the reference the RTL is verified against, and the place the design's behaviour on real, varied files is pinned down before the Verilog is trusted.
IMAGE PROCESSING
A high-throughput JPEG decoder in RTL, modelled first in C++.
Decoding a JPEG sounds solved until it has to happen at line rate, in hardware, on arbitrary files. The standard allows a range of chroma subsampling modes and carries its own quantisation and Huffman tables in every image, so a real decoder cannot assume a fixed configuration — it has to read the file and adapt.
CONTEXT
Where this started.
The programme built a high-throughput JPEG decoder as a streaming pipeline: parse the format, Huffman-decode the entropy-coded symbols, reorder, dequantise, inverse-transform, reassemble blocks with chroma upsampling, and convert back to RGB — all fed and drained over AXI-Stream.
It was modelled in C++ first. The model is not a formality: it is the reference the RTL is verified against, and the place where the design's behaviour on real, varied files is pinned down before a line of Verilog is trusted.
CHALLENGES
4 problems, named.
Stated before they had answers.
01
Real files, not a fixed configuration
The decoder had to handle different chroma subsampling modes and the quantisation and Huffman tables carried inside each image.
02
High throughput as a first constraint
The design targets real-time processing, so the pipeline had to stream, not stall on the entropy stage.
03
Entropy decode is inherently serial
Huffman decoding resists parallelism, and it sits upstream of everything, so it sets the pace of the whole decoder.
04
A reference to verify against
Correctness across varied files needed a golden model, built in C++, before the RTL could be trusted.
ARCHITECTURE
How the system was built.
An encoded image arrives over AXI-Stream. The format parser extracts the image configuration and the DHT/DQT tables; Huffman decoding recovers the coded symbols and minimum coded units; the stream is reordered, dequantised and inverse-transformed; blocks are reassembled with chroma upsampling; and colour-space conversion produces an RGB image out over AXI-Stream. Quantisation and Huffman tables are taken from the file, per image.
CONTRIBUTION
What Faststream did.
The specific scope, rather than a capability list.
- High-throughput JPEG decoder — a streaming decode pipeline designed for real-time processing.
- C++ model — a reference model for system validation and design verification.
- Verilog RTL — the decoder implemented in RTL and verified against the model.
- Chroma subsampling support — handling the standard's different subsampling modes.
- Configurable tables — quantisation (DQT) and Huffman-coded symbols (DHT) taken from each image.
- AXI-Stream interfaces — encoded image in, decoded RGB out, as a streaming block.
WHAT WAS HARD
The parts that consumed the schedule.
Written out because a reader facing the same programme gets more from this than from a summary of what went well.
01
Entropy decode paces the pipeline
Huffman decoding is serial and sits upstream of everything, so throughput is won or lost there, not in the arithmetic stages.
02
Adapting to each file
Reading the DQT and DHT tables from every image, and supporting several chroma modes, meant the decoder configures itself rather than assuming a format.
03
Streaming a block-based algorithm
JPEG works in 8×8 blocks and minimum coded units; keeping those flowing over AXI-Stream without stalls took care at every stage boundary.
04
A model worth verifying against
The C++ reference had to be faithful enough that matching it actually proved the RTL correct across varied files.
OUTCOME
What resulted.
A high-throughput JPEG decoder in RTL
A streaming decode pipeline from AXI-Stream encoded input to AXI-Stream RGB output.
Verified against a C++ model
The Verilog RTL checked against a faithful reference across varied, real files.
Configurable per image
Support for different chroma subsampling modes and image-carried DQT and DHT tables.
A reusable decode core
A parameterised decoder reusable across formats and platforms rather than tuned to one file type.
Confidentiality
Customer projects are presented at property, capability, outcome and integration level. Customer names, internal architecture and confidential deliverables are not disclosed. Where a figure would identify a customer or a design, it is omitted rather than approximated. More detail is available under a non-disclosure agreement, within the limits each customer has agreed.
CAPABILITY USED
What this was built from.
Every item links to its own page.
PLATFORM
Faststream Vision
Machine vision and edge inference.
SERVICEFPGA Design
Architecture, HDL, timing closure.
CAPABILITYVerification methodology
Model-based verification.
SOLUTIONImage Processing & FPGA Vision
The wider body of imaging work.
CASE STUDYComplete image pipeline
The encode side of the same chain.
CASE STUDYH.264 Video Decoder
A moving-image codec in hardware.
WHERE THIS APPLIES
Industries this serves.
COMMON QUESTIONS
Questions this programme gets asked.
What limits JPEG decode throughput?
Huffman entropy decoding, which is inherently serial and sits upstream of the arithmetic stages, so it paces the whole pipeline.
What are DQT and DHT?
The quantisation tables (DQT) and Huffman tables (DHT) carried inside each JPEG. A general decoder reads them per image rather than assuming a fixed configuration.
Is chroma subsampling handled?
Yes — the decoder supports the standard's different chroma subsampling modes, upsampling during block assembly before colour conversion.
KEEP READING
Related work.
BUILD WITH FASTSTREAM
Bring us the difficult part.
Tell us the format, the throughput target and the platform. Codec datapaths that stream at line rate are core Faststream work.