What is a software-defined radio modem?
A modem whose signal processing is implemented in reconfigurable logic rather than fixed hardware, so waveform, modulation and coding can change after deployment as standards evolve.
COMMUNICATIONS
A satellite modem where the waveform is a configuration, not a design.
A demanding filtering, synchronisation and error-correction chain closed inside the device that was budgeted for — where above eighty per cent utilisation, timing stops being a tool problem.
CONTEXT
Where this started.
A satellite link is long, noisy and geometrically variable. The modem has to acquire and track a signal at low signal-to-noise ratio, correct errors aggressively, and hold the link while the geometry changes underneath it.
Making it software-defined adds a second constraint. The waveform must be changeable after deployment, because standards evolve and a terminal in service for a decade will outlive the specification it shipped with. That rules out committing the datapath to fixed silicon.
Which produces the real problem. A demanding chain on a fixed device is a resource and timing problem, and the temptation to specify a larger device is expensive in both unit cost and power — on a product where both are already constrained.
CHALLENGES
4 problems, named.
Stated as the customer stated them, before any of them had an answer. A challenge that is only described after it was solved is a description of the solution.
01
A demanding chain, a fixed device
Specifying a larger FPGA was available and expensive. Closing the design in the budgeted device was the requirement, not the aspiration.
02
Acquisition at low signal-to-noise ratio
Carrier and timing recovery had to acquire and hold at the ratios the link budget actually implied, not at comfortable ones.
03
Error correction dominates the device
The forward error correction block consumed a disproportionate share of both logic and memory, effectively setting device size for the whole design.
04
Reconfigurability without paying for it
Parameterisation that is genuinely useful after deployment, without carrying unused flexibility in area and timing, is a design discipline rather than a feature.
ARCHITECTURE
How the system was built.
The filter chain and the error correction block are marked because they set the device size between them. Per-stage precision analysis on the decimation chain recovered a significant share of the DSP and memory budget, which is what made closing in the budgeted device possible at all.
CONTRIBUTION
What Faststream did.
The specific scope, rather than a capability list. Where a stage was shared with the customer’s team, it is described as shared.
- Architecture — partitioning between FPGA fabric, DSP resources and embedded processing.
- Datapath design — the filtering, synchronisation and correction chain, with per-stage precision analysis.
- HDL development — structured for timing closure at high utilisation rather than for readability alone.
- Resource optimisation — fitting the design into the budgeted device instead of specifying a larger one.
- Timing closure — constraint development, critical path analysis and the pipelining that resolved it.
- High-speed interfaces — data and control paths to the host system.
- Verification — simulation and hardware validation against reference waveforms.
- Bring-up and characterisation — board-level integration, debug and link validation.
WHAT WAS HARD
The parts that consumed the schedule.
Rarely the subsystem that sounds difficult. Written out because a reader facing the same programme gets more from this than from a summary of what went well.
01
Utilisation above eighty per cent
Past that point the router has little freedom and timing closure becomes an architecture problem rather than a tool-settings one. Pipelining was added at specific stages and one clock domain restructured to resolve it.
02
Precision as an area lever
Uniform precision across a datapath wastes resources at both ends. Per-stage analysis of required dynamic range recovered significant DSP and memory capacity with no measurable performance loss.
03
Error correction setting the device size
One block consuming a disproportionate share of logic and memory meant its architecture effectively chose the FPGA for the entire design, so it was settled first.
04
Configurability that does not cost area
Parameterisation useful after deployment, without paying for unused flexibility in area and timing, required deciding which axes would genuinely change and which would not.
OUTCOME
What resulted.
Closed in the budgeted device
The processing chain fitted the FPGA that was specified, rather than forcing a larger and more expensive part.
Validated against reference waveforms
Simulation and hardware validation against references, with link behaviour characterised rather than assumed.
Reconfigurable where it matters
Waveform, rate and coding parameterised on the axes likely to change during the terminal's service life.
A demonstration of where FPGA is correct
Performance a processor cannot reach, at volumes that do not justify an ASIC, in an application whose standards will change mid-life.
Confidentiality
Customer projects are presented at property, capability, outcome and integration level. Customer names, internal architecture, register maps, state machines 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.
PRODUCTS AND CAPABILITY USED
What this was built from.
Every item links to its own page, with characteristics, applications and the maturity status stated honestly for that item.
PLATFORM
Faststream Radio
5G, O-RAN, SDR and satellite.
PRODUCTSatellite Modem & SDR Platform
The platform product.
PRODUCT18-bit Pipeline DSP Slice IP
The datapath building block.
CAPABILITYFPGA design
Architecture, HDL, closure and bring-up.
TECHNOLOGYWireless and RF architecture
Link budget and the physics above it.
TECHNOLOGYHigh-speed interfaces
The host data path.
WHERE THIS APPLIES
Industries this serves.
COMMON QUESTIONS
Questions this programme gets asked.
Why FPGA rather than ASIC?
Volumes rarely justify mask cost, the processing exceeds general-purpose processor capability, and terminals in service for a decade outlive the standards they ship with. Reconfigurability is a product requirement here, not a convenience.
What causes timing closure difficulty at high utilisation?
Routing congestion. Above roughly eighty per cent the router has limited freedom, so closure depends on architectural changes — added pipelining, restructured clock domains, altered memory access — rather than tool settings.
How was the design fitted into the budgeted device?
Principally by per-stage precision analysis on the datapath. Sizing each stage to its actual required dynamic range, rather than applying a uniform width, recovered significant DSP and memory capacity.
FOUND THIS USEFUL?
Pass it on.
Written for engineers. Share it with one.
KEEP READING
Related work.
BUILD WITH FASTSTREAM
Bring us the difficult part.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.