How to Choose an FPGA Design Company: What to Check Before You Outsource

An FPGA design company builds digital hardware in code, and that single fact should drive how you choose one. A supplier can be excellent at embedded software or board design and still be the wrong partner for programmable logic. This guide sets out the checks that separate the two, written so you can apply them to every supplier on your shortlist.

Key Takeaways

• FPGA design is its own discipline: you are describing a circuit, not writing instructions for a processor, so embedded software references do not prove FPGA capability.
• Buyers commission three kinds of FPGA work: a custom IP core or function, a port or mid-life upgrade, or ASIC prototyping on FPGA. Know which one you need before you talk to anyone.
• Ask who will actually do the work, and get the named engineer before you sign.
• Check toolchain experience separately from HDL skill, and check verification against your own regime, not the supplier's habit.
• Ask about year eight: what happens when the device family is withdrawn.

What an FPGA design company actually does

FPGA design is not a variant of hardware design, and it is not a variant of software development. Field programmable gate arrays contain a matrix of unspecialized logic that you configure with code, telling it what to connect to and what to do. Writing RTL means creating gates, registers and connections and attaching clocks to them. The result behaves like physical hardware.

Adam Szychulec, Head of Hardware / Embedded at InTechHouse, puts the shift plainly: you are not writing instructions for a processor; you are writing hardware in code. For a buyer, the consequence is direct. FPGA design services are a separate competence from firmware, embedded Linux or board design, even when one company offers all of them. An excellent embedded software supplier is not automatically an FPGA supplier, and the reference that impressed you may be evidence of a different discipline. When you check a reference, ask what was delivered in programmable logic specifically.

FPGA design company or FPGA vendors? Two different things

The phrase "FPGA companies" covers two different groups, and readers land here looking for both. FPGA vendors manufacture the chips: AMD/Xilinx, Intel/Altera, Lattice, Microchip and Gowin are the names you will meet across the market. Each defines its own FPGA technology, device families and design tools.

An FPGA design company designs the logic that runs on those chips: the FPGA architecture, the RTL, the verification, and the integration with the rest of the product. It turns a vendor's silicon into FPGA solutions for a specific system.

This page is about choosing a design company. Check this article if you are choosing a chip family.

Why FPGA development gets outsourced

If your company is struggling to staff FPGA development, it is not failing. FPGA engineers are few, expensive and hard to hire, and the need inside most companies is episodic: one project, one function, or a mid-life upgrade once in a decade or two. Building an in-house engineering team for that does not add up.

The scarcity also persists rather than correcting itself. The entry barrier is high, learning material is thin, and most embedded engineers never move into the area. Adam notes this is true even inside his own department, where most people are strong on processors and do not sit in FPGAs.

The realistic question is how to find outside FPGA developers with extensive experience in the kind of work you need. Complex projects fail in specific, predictable places, covered in FPGA design mistakes. The checks below are built around them.

The three things buyers commission from FPGA services

Almost every request for FPGA services falls into one of three categories, and knowing yours narrows the shortlist immediately:

1. A custom IP core, or a function implemented in FPGA or on a SoC platform. New intellectual property: a block of logic that does something specific, built on a standalone FPGA or on FPGA and SoC platforms such as Xilinx Zynq.
2. Porting an existing design, or a mid-life upgrade. Moving working logic onto a supported device, often with incomplete documentation.
3. ASIC prototyping on FPGA. Using programmable logic to validate a chip design before fabrication. InTechHouse offers the first two categories and does not offer this one.

Adam's observation from the demand side helps here. A customer searching for a supplier usually already knows what they want: most often an unusual IP core for something better done in programmable logic, something no off-the-shelf part performs, or something a processor does inefficiently. If your project needs fit one of those descriptions, you are in category one. The FPGA & High-Performance Embedded Systems service page describes the first two in more detail.

What to check before you sign: seven questions for any FPGA engineering team

These checks give you the technical details you need to make informed decisions. Each one ends with the question to ask.

1. Who will actually do the work, and who decides?

Get the named engineer before you sign, not a role title. Ask how a scope change is approved and how long it takes. On an episodic specialist project, you are buying access to a particular person's time, and an account layer between you and them is a cost, not a service. Expert guidance only helps if it reaches you directly. Ask: "Which engineer are you proposing, and who approves a change in scope?"

2. Which toolchains and which FPGA vendors have they actually shipped on?

Design flows look similar across vendors, but names, tools and failure modes differ. The tools carry real bugs and are in constant development, and what works at one vendor does not at another. Adam also separates two competences: the FPGA logic itself, and how software is loaded onto the device and with which tools. Ask: "Which device families and toolchains have you shipped production designs on?" Not which HDLs they know.

3. How do they verify, and to whose standard?

This check separates a supplier that has been audited by a regulated customer from one that has not.

"There are additional requirements on top. Beyond the fact that it has to work, it has to be testable, things have to be repeatably tested, and it has to be written in the prescribed way, in line with the requirements."

‍

Adam Szychulec, Head of Hardware / Embedded, InTechHouse, on what a rail customer required

Verification and validation should follow your regime, not the supplier's habit. Where verification sits in the flow is covered in FPGA design flow. Ask: "Which customers held you to a code standard and test evidence, and what did you deliver?"

4. Which device families, and what happens to FPGA fabric headroom?

The device chosen at the start decides whether a later feature fits or forces a new board. Ask which device families they have shipped, and whether they plan spare fabric for hardware-level changes after launch. Ask: "How much headroom do you plan for, and why?"

5. What sits around the FPGA?

Capabilities pages tend to list everything. Ask which of these a candidate has actually shipped: digital signal processing or other signal processing pipelines; machine learning or artificial intelligence workloads on fabric; high level synthesis; formal verification, RTL simulation practice and functional verification, and which verification tools they use; timing closure on a congested design; architecture design; PCB layout and power distribution around the device; system integration and hardware validation; high speed communications interfaces; edge computing deployment. A capabilities page lists all of these; a reference call tells you which two they have shipped. Ask: "Which of these have you delivered, and can I speak to that customer?"

6. What happens in year eight?

Long term support and device availability belong on the selection list. Industrial manufacturers, rail suppliers and aerospace companies often run products that outlive the device families they were built on. The plan for that moment decides the long-term reliability of supply, and whether you face a planned migration or an emergency. See FPGA vs ASIC vs SoC and FPGA obsolescence and mid-life upgrade. Ask: "What is your plan when this device family is withdrawn?"

7. What can you verify without asking them?

Procurement teams check what does not depend on the supplier's word: management-system certifications, registered designations with decision numbers, company registry data, directory profiles, and whether the website and the references tell the same story. Standard contracting questions apply too: IP ownership, source and documentation hand-over, escrow, change control and acceptance testing. Ask for the documents, then check them independently.

How InTechHouse answers these checks

The engineering evidence comes first, because for an engineering lead it matters more than company size:

• SoC depth: several projects on Zynq and Zynq UltraScale+, the high performance SoC families where processor and FPGA fabric share one device.
• Custom IP core: a Precision Time Protocol v2 IP core for an aerospace customer (Developing a High-Precision FPGA IP Core for Aerospace Navigation Systems).
• Mid-life upgrade: a legacy Spartan-3 safety design migrated to a supported platform for a UK rail supplier (see the case study below).

InTechHouse has delivered FPGA or SoC work in telecom, aerospace, oil & gas and rail, a broad range of production systems, including FPGA logic delivered under a rail customer's safety-integrity (SIL), code-standard and testability requirements. The framing is testing, pre-compliance and certification support; InTechHouse is not a certification body. Toolchains the team has shipped on: Vivado, Vitis, Quartus, Lattice Radiant and Lattice Diamond.

On the first check: you know which engineer is being proposed before you sign, and you deal with the Head of Hardware / Embedded directly.

Company facts you can check independently: ISO 9001:2015 and ISO/IEC 27001:2017-06 (management-system certifications for quality and information security). The status of Research and Development Centre, granted by the Polish ministry, Decision No. 7/CBR/16 of 29 August 2016. 20 years in business, over 220 customers, a 91.2% client retention rate, and around 200 software and hardware specialists. Based in Poland (EU), in Bydgoszcz and Warsaw, with a US office in Richardson, TX, and over 5,000 square meters of R&D space.

InTechHouse case study: migrating a legacy Spartan-3 safety design

A UK rail supplier needed a legacy FPGA safety design, built on the Spartan-3 family, moved to a platform that is still supported. The work began with reverse engineering of the existing design, followed by selection of the target platform. InTechHouse then ported the logic and verified the new implementation across two hardware variants of the product. The safety documentation was preserved through the migration.

‍