FPGA work spans production systems where the FPGA is the product, prototyping ahead of an ASIC, and signal-processing platforms where reconfigurability is the point. Faststream covers architecture, HDL, timing closure, resource optimisation and hardware bring-up — including the high-speed interfaces that are usually where the difficulty actually is.
Zynq pairs an ARM processing system (PS) with FPGA fabric (PL), and the work that earns its keep sits on the boundary: interfaces built in the programmable logic that the processor configures and drives at runtime over AXI. A few examples from recent Zynq work — and the Linux that runs on top.
| Capability | What it does | Why it matters |
|---|---|---|
| Software-configurable UART | A UART in the PL whose baud rate is set at runtime by PS software, over an AXI4-Lite register — standard rates from 9600 to 921600 and custom divisors, with 16× oversampled receive. | One bitstream serves every rate. The application changes baud live to match whatever device it is talking to, with no re-synthesis and no board change. |
| Configurable PCIe 2.0 — root complex or endpoint | A PCIe 2.0 (5 GT/s) link on the integrated block and GTX transceivers, selectable as root complex or endpoint, with the AXI bridge and DMA into the PS and PL. | One design is host or device by configuration — the same board can enumerate a bus or present itself to a host, which a fixed-role part cannot do. |
| Reliable full-duplex data link | Simultaneous transmit and receive, with configurable framing, flow control and error handling — CRC checking, acknowledgement and retransmission when a frame is lost or corrupted. | Transfers complete reliably: the link detects a dropped or corrupted frame and recovers it rather than passing bad data on, and the configuration adapts it to the channel. |
Both are hardware/software co-design: the capability lives in the fabric, but the control and the flexibility live in the software that drives it over AXI.
And the Linux that drives it. A Zynq design is only as useful as the software that boots on it, so we build that too — the embedded Linux for the exact hardware, generated and maintained with PetaLinux (Xilinx’s tool, Yocto underneath): the first-stage bootloader, U-Boot, the Linux kernel, the device tree that describes the PL peripherals, and the root filesystem. The device tree is where the two halves meet, and a Linux device driver is what makes a fabric peripheral usable: the configurable UART above, for instance, gets a device-tree node and a kernel driver with its user-space interface, so the application opens it like any other device. That is device driver development in its hardest form — written for custom hardware that has no off-the-shelf driver.
| Situation | Better choice | Why |
|---|---|---|
| Low to moderate volume, high performance | FPGA | No mask cost, and the performance a processor cannot reach |
| Requirements still moving | FPGA | Reconfigurable after deployment |
| High volume, stable function | ASIC | Unit cost and power dominate once volume is real |
| Signal processing with evolving standards | FPGA | Field-updatable datapath as standards move |
| Modest performance, cost-sensitive | MCU or SoC | An FPGA is over-specified for the job |
| Proven FPGA design going to volume | FPGA-to-ASIC conversion | Function already validated in hardware, so risk is lower |
A design that will not close timing at 90 per cent utilisation rarely closes because someone found a better tool setting. It closes because the architecture changes — pipelining added at the right stage, a clock domain restructured, a memory access pattern altered so the router has somewhere to go.
That is worth knowing early, because the cost of restructuring rises sharply once the design is integrated. Faststream budgets timing and resource utilisation at architecture, and treats a design sitting above roughly 80 per cent utilisation as a risk to manage rather than a milestone to celebrate.
When volume is high enough that unit cost and power dominate, and the function is stable enough that fixing it in silicon is not a bet. Because the design has already been validated in hardware, conversion carries less risk than a new ASIC from scratch.
Insufficient pipelining on critical paths, high utilisation leaving the router no room, poorly structured clock domain crossings, and constraints that do not describe the real timing intent. Most are architectural and cheapest to fix early.
Yes. That starts with an assessment of the HDL, constraints, verification state and utilisation, so the work plan reflects the design's actual condition.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.