Choosing an FPGA for an Embedded Product: PolarFire, Lattice or Xilinx

Start from the job, not from the logo

Teams often pick an FPGA family because it is the one they used last, or because the evaluation board was on the desk. The better order is to write down what the logic has to do, and let that point at a family. Seven questions settle most of it.

1. How much logic, memory and DSP? A few thousand logic elements for glue, bridging and simple protocols is a different class of device from a hundred thousand for image processing or a soft processor.
2. What is the power and thermal budget? A battery or a sealed, fanless enclosure rules out some families on static power alone, before any logic runs.
3. How must it start? Some FPGAs hold their configuration on chip and are running almost immediately; others load it from external flash at every power-up and need a boot sequence and an extra part.
4. What are the interface speeds? Multi-gigabit links (PCIe, high-speed serial, fast camera or sensor interfaces) need transceivers, which only some families and sizes have.
5. What are the security requirements? Protecting the design from copying, secure boot, tamper behaviour.
6. Which toolchain and IP will the team live in? Each vendor has its own design tool, and its own library of ready-made blocks.
7. How long must it be available, and how are you buying it? Lifecycle, lead time and distributor stock are product risks, not purchasing details.

Where the three families tend to fit

Lattice: small, low power, simple to place on a board

Lattice parts are strongest at the small end. For glue logic, level and protocol bridging, sensor aggregation and simple control, a small, low-power device with few supply rails and an easy package is often the right answer, and some of its families start almost instantly from on-chip configuration. We used a Lattice FPGA in a fiber signal communication board that pairs a 14-bit, 80 MSPS ADC with a 16-bit, 50 MSPS DAC over a 1000 m link with a signal-to-noise ratio above 50 dB. The FPGA's job there was deterministic, high-rate signal handling next to the converters, which is exactly where a small, predictable part earns its place.

Microchip PolarFire: mid-density, low power, security

PolarFire is flash-based: the configuration lives on the chip, so the device is running quickly after power-up and the configuration is not at risk from the single-event upsets that affect SRAM-based parts. It combines mid-range density and transceivers with low static power and a good security story, which suits industrial, medical, communications and any product that must be both efficient and protected. We built a PolarFire (MPF100T) core board as a reusable base for such products. The tradeoffs are a smaller ecosystem of ready-made IP than the largest vendor and a design tool you have to learn.

Xilinx (AMD): scale, performance and the broadest ecosystem

When the design needs large logic capacity, heavy DSP, many high-speed transceivers, or a tightly coupled processor on the same chip (the Zynq-style families), Xilinx parts and the Vivado toolchain have the widest selection and the largest base of IP, reference designs and community knowledge. The cost is power, board complexity (more rails, tight sequencing, demanding memory interfaces) and device price. We deliver on Xilinx as well, and the usual reason to choose it is not that it is better in general, but that the application genuinely needs that scale.

A rough rule of thumb

• Glue, bridging, simple control, tight power or tiny board: a small Lattice device.
• Mid-size logic with transceivers, low power, security or a long product life: PolarFire.
• Large logic, heavy signal processing, many fast links, or a processor integrated with the fabric: Xilinx.

A rule of thumb is not a design review. Constraints such as an existing team, a component already qualified by the customer or a supply agreement can legitimately override it.

The decisions that hurt later

• Pin planning after the board layout. Assign pins with the FPGA tool and the board layout together. Moving a bank or a clock input after the board is fabricated is a respin.
• Power sequencing and rails. Several supplies, each with its own ramp and order, are the usual reason an FPGA board works on the bench and not in the field. Read the power-up requirements early.
• Clocking. Choose the clock sources and which pins they enter on, and plan the jitter budget when transceivers or converters are involved.
• Configuration and updates. How the bitstream is stored, updated in the field and recovered when an update fails should be designed as a feature.
• Debug access. Reserve a JTAG header and a few spare pins, and plan on-chip logic analysers. They cost almost nothing at the start and a great deal later.
• Timing closure is a design activity. Write timing constraints at the beginning, not when the design fails them, and keep clock-domain crossings few and deliberate.

Where we can help

We design FPGA logic and the boards around it, on Lattice, Microchip PolarFire and Xilinx, from selection through timing closure and board bring-up. See our FPGA design service.