We build the board around the datapath

What we do

Every FPGA and ASIC programme spends months on work that is not the product. Data has to arrive from a converter with a latency that survives a reset. It has to cross to the host without losing half the link rate. Clocks have to be crossed without a race that appears once a week in the field. Registers have to mean the same thing in the RTL, the driver and the document.

None of that differentiates the end product, and all of it has to be right. We license it so that a team can spend its schedule on the part that is actually theirs.

Why PCI Express is our lead product

Because it is the one most often bought twice. A generic controller trains the link and enumerates cleanly, and the design then runs at a fraction of the bandwidth it was specified for — the descriptor handling stalls, small transfers collapse the efficiency, the driver and the hardware disagree about a register. The fix is rarely the controller; it is everything around it.

ALF-CR-PCIE is built as one thing: transaction layer, DMA engine and host drivers designed, verified and released together, and signed off for compliance at every supported lane width and link rate. That is the whole reason it holds the rate.

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 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. Where a hard block has to be used — a transceiver, a PCIe block — it sits behind a thin, replaceable wrapper, and the wrapper is the only file that changes between targets.
• 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.
• Proven, not just tested. Anything that can deadlock or lose data is proven rather than sampled: formal proofs of deadlock freedom on the interconnect and the DMA, and of the clock crossings inside them, delivered with the proof scripts so you can re-run them.
• Verification included. The environment we sign off with is the environment you receive. Re-run it on your own farm.
• Software counts as deliverable. Drivers, register headers and the UVM register abstraction layer are generated from the same description as the RTL and versioned with it. A register cannot move in hardware without moving in the driver.
• Built to be left in. Trace, counters and telemetry are designed to ship inside the product rather than be stripped out after bring-up, because the failures worth instrumenting are the ones that happen at a customer site.

How those claims are 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.

• Accelerator and offload cards. Compute, storage and network offload boards. The binding constraint is usually sustained host bandwidth at small transfer sizes.
• Data acquisition and instrumentation. Multi-channel converter front ends and capture systems. The binding constraint is usually deterministic latency and not dropping a sample.
• Radio and defence platforms. The board underneath a software-defined radio, frequently alongside AlfaRF signal processing. The binding constraint is usually timing determinism and a defensible evidence package.
• Industrial and telecom systems. Distributed systems that need a shared time base and line-rate transport. The binding constraint is usually synchronisation accuracy across many devices.

One group, two catalogues

AlfaRF and alfacores are sister companies with shared engineering practice: the same coding conventions, the same register discipline, the same verification sign-off criteria and the same deliverable set. The split is by subject, not by standard — AlfaRF takes the signal, we take the board it travels across.

In practice most radio platforms use both catalogues, and they are built to be used that way: a modem core and a PCIe core in the same design need no translation layer between them. Visit AlfaRF for the signal-processing side.

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.

Careers

We hire digital design and verification engineers who are interested in interconnect, high-speed interfaces and the unglamorous parts of a chip. The work is unusually deep: you will own a core end to end — architecture, RTL, formal properties, verification, driver, hardware validation, datasheet.

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@alfacores.com. We read every one and we reply.