We build the digital half of the radio

What we do

Between an antenna and an application there is a large amount of digital signal processing: rate conversion, impairment correction, synchronisation, demodulation, error correction, transport. It is well-understood work in the sense that the mathematics is in textbooks, and it is difficult work in the sense that a correct implementation which also closes timing, fits the resource budget and behaves at low SNR takes a specialist team a long time to get right.

Most companies building radio products do not want that team. They want the block, verified, with a datasheet whose numbers hold in their design. That is what we sell.

How we are different

The semiconductor IP market has a credibility problem, and it comes from a recurring pattern: a headline specification measured in a favourable configuration, a delivery form the customer does not get to choose, and a verification package that arrives as a separate line item. The real integration cost turns up after the purchase order.

We took the opposite position on each of those points, deliberately:

• VHDL, and only VHDL. Every core is written in synthesisable VHDL-2008. We do not ship Verilog or SystemVerilog, which means one language to review, one set of coding conventions and no mixed-language simulation problem at your end.
• Source or closed box, your choice. Take the VHDL and read, debug and modify it inside the licence, or take an encrypted netlist and a protected model where the source cannot be released to your programme. The core, the verification and the documentation are the same either way.
• Portable, no vendor lock. No inferred vendor primitives: the same source builds on AMD, Altera, Lattice, Microchip and standard-cell ASIC flows, with technology mapping confined to a thin, replaceable wrapper layer.
• Characterised performance, not headline performance. Every datasheet gives resource, latency and throughput as functions of the parameters, so you can compute your configuration's numbers rather than ours.
• Bit-accurate golden models. Every core ships with a C++ or MATLAB reference model that matches the RTL bit for bit, so you can build your system-level simulation and fix your link budget before the hardware team writes a line of integration code.
• Verification included. UVM environment, constrained-random stimulus, coverage model and regression script. The environment we sign off with is the environment you receive — re-run it on your own farm rather than taking our numbers on trust.
• Configured, not forked. Cores are parameterised through a single package file and an elaboration-time consistency check, so you stay on the mainline release and keep receiving maintenance updates.
• Documented for the person doing the work. Datasheet, integration guide, register map, timing diagrams for every interface transaction, and closed-form resource and latency equations — not a single benchmark number from one favourable configuration.
• Engineers on the phone. Support is access to the people who wrote the core.

None of that is generosity. It is the shortest path to a customer who comes back for the second core, which is the only way a business like this works. How the claims are actually checked before a core ships is on the quality page; what arrives in the release archive is on licensing.

Markets we serve

Our cores ship in products across four broad areas, each with a different binding constraint — which is why the portfolio is parameterised rather than fixed.

• Satellite communications. Ground stations, VSAT terminals, gateway hubs and on-board processors. The binding constraint is usually performance at low SNR.
• Cellular infrastructure. O-RAN radio units, small cells, private networks and repeaters. The binding constraint is usually power efficiency at the amplifier.
• Defence and aerospace. Software-defined radios, tactical data links, electronic support receivers and radar back-ends. The binding constraint is usually deterministic timing and a defensible evidence package.
• Test, measurement and connectivity. Signal analysers, channel emulators, spectrum monitors and connectivity SoCs. The binding constraint is usually dynamic range, or silicon area.

How we work

We are a small engineering organisation and we intend to stay one. The practical consequence is that we decline work we are not equipped to do well, and we say so at the first conversation rather than discovering it at integration. If your requirement is better served by another vendor, or by your own team, we will tell you — a wrong-fit engagement costs us more in support and reputation than it earns in licence fees.

It also means our roadmap is driven by customer commitments rather than speculation. Cores marked in development or roadmap in the portfolio are there because a customer is funding them. If something you need is missing, that is the mechanism for getting it built.

Careers

We hire digital design and verification engineers with a background in communications or signal processing. The work is unusually deep: you will own a core end to end — algorithm, architecture, RTL, verification, hardware validation, datasheet — rather than being handed a block diagram and a deadline.

We are interested in engineers who are comfortable saying a specification is wrong, and who write documentation that another engineer can build from. If that describes you, send a CV and a short description of something you designed and what you would do differently now, to careers@alfarf.com. We read every one and we reply.