One RTL, Every Vendor: Inside RunX’s Multi-Vendor FPGA Strategy

In 2021, an engineering team building a radar subsystem got a number back from their Xilinx distributor that reshaped how they’d design hardware for the next decade: 52 weeks, for a mainstream FPGA that had shipped in volume for years.

Teams whose RTL only ran on Xilinx had one option: wait. Teams that could retarget to a Lattice or Microchip part sitting on a shelf with a two-week lead time kept shipping. Same market, same shortage, wildly different outcomes, and the difference was a design decision made years earlier, not luck.

That’s the case for a multi-vendor FPGA strategy, and it’s the one we build around at RunX. Not “vendor-agnostic” in the hand-wavy marketing sense (more on why that oversells things below), but a disciplined, engineering-first approach to writing RTL that moves between Xilinx, Altera, Lattice, and Microchip silicon without a redesign.

This is the long version: where it’s genuinely hard, where it’s a solved problem if you do it right, and why the extra effort is worth paying for before you need it, not after.

Fluency Across Every FPGA Family

Multi-vendor RTL starts with the team actually knowing the silicon, not just the datasheet. At RunX that means real design and tapeout history across all four:

• Xilinx/AMD deepest ecosystem for high-end SoC and AI-accelerator work, with the broadest hard-IP catalog and the most mature tooling for large designs.
• Altera a long-time strong hand in telecom and networking infrastructure; the Agilex generation is built around power efficiency at scale.
• Lattice owns the low-power, small-footprint edge and control-plane niche, where board space and standby current matter more than raw logic count.
• Microchip built substantially on the old Actel/Microsemi antifuse and flash-based lines; the call when radiation tolerance, security, and non-volatile configuration actually matter (aerospace, defense, anything that can’t tolerate a bitstream being read out of an SRAM-based part at power-up).

For cost-sensitive, high-volume work where a premium part isn’t the right call, we also carry hands-on experience with budget-tier options like Gowin.

That breadth isn’t a slide bullet. Each vendor earned its niche for real reasons, and knowing those reasons is what lets an architecture decision, which vendor’s DSP slice shape best fits this filter, which vendor’s security model actually satisfies the requirements, get made correctly on day one instead of discovered as a mistake at bring-up. Want the deeper primer on what actually differentiates these families? We wrote one: Choosing the Right FPGA Family.

The Honest Limit: Full Vendor-Agnosticism Doesn’t Exist

Plenty of marketing sells “write your RTL once, synthesize it anywhere” as a solved problem for any design. That’s roughly true for simple designs: glue logic, basic state machines, and low-speed peripherals port over with minimal fuss. Past a certain complexity it stops being true, and pretending otherwise is how a project discovers the gap during bring-up instead of during architecture, the most expensive possible time to find out.

Where it actually breaks down

• High-speed, PHY-touching interfaces. SerDes, PCIe, Aurora, and 10G/25G Ethernet MACs and PHYs are built from vendor-specific hard macros with completely different configuration, calibration, and electrical characteristics. There’s no generic RTL description of a SerDes transceiver; you instantiate vendor primitives directly and write at least a thin per-vendor abstraction layer around them.
• Board-level elements. External DDR controllers, clock trees, and power sequencing are physically different problems on physically different boards, no matter how similar the RTL looks on paper.
• Primitives that don’t map 1:1. Xilinx’s URAM, a large, low-latency “ultra RAM” block unique to its UltraScale+ parts, has no direct Altera equivalent. Altera’s ALM (which packs a pair of smaller look-up tables and adders more flexibly than a Xilinx LUT/MUX slice) doesn’t map cleanly back either.
• Fabric that isn’t the same shape. Altera’s ALM-based fabric can pack certain logic patterns more densely, and route them more cheaply, than Xilinx’s LUT/MUX-slice fabric, and the reverse is true for other patterns. A design that closes timing comfortably on one vendor can come in tight, or fail closure outright, on another, with zero RTL bugs involved anywhere.
• Soft IP that isn’t 1:1. Vendor-supplied memory controllers, PCIe cores, and DSP libraries differ in parameterization, latency, and protocol. Swapping a Xilinx MIG-based DDR controller for an Altera EMIF-based one is not a drop-in replacement.

This is why “just retarget it” is naive advice, and why we don’t sell false vendor-agnosticism. What we do instead is engineer specifically for portability at every layer where it’s actually achievable, and stay upfront with clients, before a contract is signed, about the layers where it isn’t. The next five sections are exactly that: the layers where the gap genuinely closes.

Standardizing on a Bus Architecture

One of the highest-leverage decisions in a multi-vendor design happens before a single line of vendor-specific RTL gets written: what interconnect standard your IP blocks actually speak to each other over.

AXI4, originated by ARM and dominant across the Xilinx/AMD ecosystem, and Avalon, Intel/Altera’s native standard tied to their Platform Designer (formerly Qsys) tooling, are the two real options. The easy-to-miss point: because ARM’s IP dominates embedded and SoC design broadly, AXI has become the de facto industry-standard interconnect well beyond Xilinx parts. Most third-party IP cores, most verification IP, and most SoC-level design flows assume it as the default.

So we standardize our internal RTL architecture on AXI, even for designs that primarily target Altera or Microchip parts, where Avalon would technically be the “expected” choice. Concretely, that means:

• Building custom IP blocks with AXI4 (or AXI4-Lite/Stream) interfaces by default.
• When a project lands on Altera hardware, using a thin, well-verified AXI-to-Avalon bridge at the boundary, rather than rewriting every block’s interface natively.

That keeps the reusable core of the design, the actual IP logic with real engineering value, completely vendor-neutral, and confines all vendor-specific translation to a single, well-understood boundary layer. It also means a standards-compliant block verifies against off-the-shelf AXI verification IP regardless of vendor, third-party and open-source IP integration is close to trivial, and every engineer who touches the design gets one consistent mental model for how blocks talk to each other.

Vendor-Tuned Design: Matching Behavior, IP by IP

Here’s the actual method we use to retarget a design between vendors, instead of hoping a re-synthesis run just works:

1. Start from the reference implementation a Xilinx-targeted design already validated in simulation and, ideally, proven on hardware.
2. Break it down IP by IP, rather than attempting one monolithic re-synthesis and chasing every mismatch blind through the whole system.
3. Re-implement and verify each block in isolation, against the exact same testbench and expected outputs used for the original, before it’s integrated back into the full system.

This beats “retarget and hope” for a simple reason: isolating verification to one block at a time gives a mismatch a small, bounded search space. You know immediately which block diverged and why, instead of debugging a system-level failure that could, in principle, have originated anywhere. And because each block is checked against the same testbench used to validate the original, what you get is an apples-to-apples behavioral proof, not just “it compiled without errors.”

Done this way, the retargeted design’s system-level behavior ends up almost identical to the original. Not automatically bit-for-bit in every respect (timing, reset sequencing, and edge cases can still differ meaningfully between vendors, which is exactly why the IP-by-IP checking matters), but verified thoroughly enough to trust with the same confidence as the one it came from.

Board-Level Reality: Why This Needs Hardware, Not Just a Simulator

Everything above assumes the design’s boundary is clean: RTL in, RTL out, provable inside a testbench. The moment a design has on-board elements, external DDR, clock distribution, power sequencing, other chips on the same PCB, no simulator closes that gap alone, because what you’re matching against isn’t a golden reference vector anymore. It’s physics: signal integrity, timing margins on a scope, thermal behavior, real silicon on real power rails.

The DDR width example makes this concrete. One vendor’s hard memory controller might interface to DDR at a straightforward data width; another might natively support a different width entirely, sixteen bits on one part, twenty-four (or a different burst/prefetch architecture) on another. Different RTL doesn’t fix that mismatch. It requires understanding each vendor’s controller architecture deeply enough to set the correct gearing ratio, the clock relationship between fabric and DDR interface, so bandwidth and timing margin still meet requirements on both parts.

Get the gearing ratio wrong, and the board boots, runs, and quietly corrupts data under load, exactly the kind of failure that never shows up in simulation and only appears hours into a hardware stress test, usually at the worst possible point in a schedule.

This is why board-level adaptation stays its own hands-on-hardware discipline, staffed by people who do bring-up, not handed off as a bitstream and a hope. An end-to-end team owns the board from power-on through signal integrity validation.

Smart Inferencing: Writing for the Tool, Not Against It

Inference, for readers who haven’t lived in a synthesis report: instead of manually instantiating a vendor-specific primitive by name, you write generic, well-structured RTL in a pattern each vendor’s synthesis tool recognizes and automatically maps onto its own best-fit hardware primitive. The same source might infer into a BRAM block on one vendor, a differently-shaped memory primitive on another, or plain LUT-based distributed memory if the array is small enough.

The “smart” part is knowing, block by block, the exact coding patterns, reset and enable structure, read-during-write behavior, array declaration style, that make the difference between a design cleanly inferring into the primitive you intended, and the same design accidentally getting built out of thousands of individual flip-flops and LUTs instead. That failure mode is both a massive area/timing penalty and genuinely easy to miss in a synthesis log if you aren’t specifically watching for it. RunX designers write RTL with each target vendor’s inference rules in mind from the start, and treat “did this infer correctly” as a checked step in every build.

Direct instantiation, naming a vendor primitive instead of inferring it, is sometimes unavoidable, typically for a very specific feature (like a particular URAM latency mode) that only exists on one part. But it’s the tool of last resort, not the default: it’s the one technique that’s inherently vendor-locked by construction.

PS-Level Discrepancies: When Even the Processor Differs

For SoC-class FPGAs, vendor differences don’t stop at the logic. Xilinx’s Zynq family pairs the fabric with a hard, ARM-based Processing System: a fixed set of Cortex core types, its own boot ROM, its own hardened peripheral controllers (specific UART, SPI, I2C, USB, and Ethernet MAC configurations), and a fixed way the PS and programmable logic talk over dedicated AXI ports. Altera’s SoC parts pair the fabric with their own Hard Processor System, also ARM-based, but with a different boot flow, peripheral mix, and PS-to-fabric interconnect entirely.

This matters because none of the RTL-level techniques above, bus standardization, IP-by-IP matching, smart inferencing, touch this layer at all. The PS or HPS is fixed silicon with its own boot process, its own configuration registers, and typically its own separate software and firmware stack (bootloader, device tree or board support package, drivers) that has to be built and validated independently per vendor.

A design that’s genuinely portable at the RTL level can still need substantial, vendor-specific software bring-up at the processor level. Treating that as a footnote instead of planned work is one of the most common ways a program’s timeline slips late, right when the team thinks the hard part is behind them. We plan for it explicitly as its own workstream from day one, with engineers who own PS and HPS bring-up on each target vendor.

Quick Recap

Layer	What has to be true for it to be portable
Bus architecture	IP blocks speak AXI by default; a single thin bridge handles Avalon at the boundary
Simulation-level matching	Each IP verified individually, IP by IP, against the original’s testbench and vectors
Board-level hardware	An on-hardware team owns gearing ratios, signal integrity, and power sequencing per board
Smart inferencing	RTL written to each vendor’s specific inference rules, checked in every build
PS-level bring-up	Boot flow, peripheral drivers, and firmware treated as their own per-vendor workstream

The Business Case: Why Pay for This Upfront?

None of the above is free. A genuine multi-vendor RTL strategy typically costs 10 to 20 percent more in non-recurring engineering cost and schedule than a single-vendor design of comparable complexity, because you’re deliberately not leaning on vendor-specific shortcuts: more of the design is written and verified in-house, IP-by-IP verification replaces a single synthesis pass, and hardware bring-up is staffed on more than one board instead of one.

That’s a real, quantifiable cost, and it’s exactly why most teams don’t pay it by default. It’s easy to defer, until a distributor quotes 52 weeks on the part the whole program depends on. That premium buys three things over a product’s life, typically measured in years or decades for industrial, aerospace, telecom, and defense markets, not the months-long cycles of consumer electronics:

What it buys	What that means
Supply chain resilience	Executing a “move it to Lattice” plan for real, not just hoping it’s theoretically possible
Obsolescence protection	A bounded, well-understood retargeting effort instead of a full redesign when a line gets end-of-lifed
Negotiating leverage	Not being a price-taker in supply negotiations when the vendor across the table knows you have somewhere else to go

The 52-week number from the opening of this post isn’t a one-off. Shortages and single-source risk are recurring facts of the semiconductor industry, not black-swan events, and teams that treat multi-vendor RTL as insurance bought early aren’t the ones renegotiating their whole program timeline the next time it happens. That’s the strategy we build into every multi-vendor design at RunX, from day one, not as a recovery plan.

Want to know whether your design is closer to portable than you think, or further? Talk to RunX about a multi-vendor readiness review.