Back to top
The short answer: Bring in outside help to validate your CPU, FPGA, GPU and NPU partition when it is your team’s first heterogeneous design, when the partition is set but nobody has stress-tested it, or when a single-discipline team is building a multi-discipline system. Keep the architecture decision in-house when the heterogeneous architecture is your product, or while requirements are still moving. The best window for outside help is narrow: after requirements stabilize and before the board goes to layout.
The partition is the last decision on the program that can still be changed cheaply. Own it, then bring in outside help to prove it right before the board layout locks it in.
Which work runs on the CPU, which drops into programmable logic, which goes to the GPU and which goes to an NPU gets settled somewhere between the first architecture review and the first board spin. It is settled with less information than anyone would like, often by whoever is free that week.
The usual conversation about outside help starts with bandwidth, and bandwidth is the easier problem. Capacity problems get solved with people. Commitment problems do not, and a partition is a commitment: whatever it decides ends up soldered to a board with a ten-year service life.
The allocation of work across processing elements looks like a compute decision and behaves like a system decision.
Put sensor preprocessing in programmable logic rather than on the application processor and you have set the interface between the two. You have also set the memory map both sides agree on, the bandwidth the data path has to sustain, and the thermal budget the enclosure has to remove. Firmware teams then write drivers against those choices. The mechanical team sizes the heatsink around them.
Each of those commitments is cheap while it is still a line in a specification and expensive once it is copper.
A workload assigned to the engine that runs it fastest can still lose the system-level comparison. Moving the data there costs more time and more power than the computation saves.
Teams that profile kernels in isolation and assign them by execution time find this at integration, when the end-to-end path finally runs on real silicon. Transfer cost, memory contention and synchronization overhead were never in the benchmark.
Deterministic systems are bounded by tail latency and jitter rather than average performance. A pipeline with excellent average throughput can still miss deadlines often enough to destabilize a control loop.
A rare spike does more damage than a consistently slower path, and it is harder to find, because it does not show up until the system is under thermal steady state with background workloads running.
The block diagram and the spreadsheet where the partition gets recorded do not show any of this. It becomes visible during bring-up, and a hardware fix there means a redesign, a fabrication cycle, assembly and retest.
Every week spent there compresses the schedule for firmware, validation and certification downstream. The details of how the partition gets implemented matter enormously once the boundary is set, but by then the boundary is the thing you are living with.
Only partly. Engineering leaders often defer the partition on the grounds that programmable logic keeps the options open. Reconfigurability is real, and it reaches less far than the argument needs it to.
Partial reconfiguration (AMD calls it Dynamic Function eXchange) is the usual basis for that argument, and its constraint is that reconfigurable regions are defined in advance as part of the device design, with their number, placement and resource budgets fixed before the board exists. The interface between host and device, the memory map, and the path the data physically takes are board-level decisions, and no bitstream swap undoes them.
A team can change what a region computes. Moving a workload from the NPU to programmable logic after the board is laid out is a different proposition, because the bandwidth to feed it, the power delivery to sustain it and the thermal headroom to survive it were all sized for the original plan.
Flexibility inside the fabric is worth having. You still have to call the system-level partition early, because the information that would improve the call arrives after it is cheap to act on.
A heterogeneous design is a one-off for most product companies and a weekly occurrence for a firm that does nothing else. If your team partitions a system once every three years, you are making the decision for the first time every time, without the pattern library that comes from watching the same choice play out across dozens of programs.
Internal capability that gets exercised rarely does not compound, and that is a frequency problem rather than a shortage of good engineers.
A partition can be tested against real constraints only after requirements are stable enough to evaluate and before the board goes to layout. Outside help is most useful inside that window, which inverts how most teams buy it.
| Signal | What it looks like on the program | What to hand over |
| First heterogeneous design for the team | Debate about CPU, FPGA, GPU and NPU roles that nobody can settle with data | Architecture trade study and modelling against your requirements |
| Partition set, confidence low | A block diagram everyone agrees to and nobody has stress-tested | Independent validation across timing, power, signal integrity and thermal |
| Stable requirements, hard market window | Specification is firm, the schedule is the binding constraint | Implementation of defined blocks alongside your team |
| Single-discipline team, multi-discipline system | Strong FPGA group, no signal integrity or thermal coverage | The seams, with your architect owning the interfaces |
The question of when to outsource the firmware itself is a separate decision that follows this one, and it gets easier once the partition is settled.
When the heterogeneous architecture is the product, it stays inside. A company whose advantage is the way it maps a perception pipeline across a device is contracting out the thing customers pay for.
The same applies to a sustained pipeline. Firms building a family of products on one compute architecture over five years are better served by permanent capability, because the decision recurs and the knowledge has somewhere to accumulate.
Outsourcing a partition while requirements are still being argued converts a design problem into a contract-management problem. Contract management absorbs change far worse than a whiteboard does. The specification has to be firm enough that someone outside the building can be held to it.
Deferring can also be the right call, and it costs something specific. If you are uncertain, you can buy a larger device than the analysis calls for, keep a CPU fallback path for operators the NPU may not support, and leave thermal headroom for a partition that shifts late.
That approach pays for optionality in bill of materials cost, board area and power. For a product where unit economics are loose and the schedule is tight, it is often cheaper than getting the partition wrong.
The architecture decision and the criteria the partition will be judged against stay in-house in every version of this. They belong to the engineering leader who answers for the program. A partner who sets their own acceptance criteria is grading their own work.
Usually one. The silicon vendor question rides on the partition, and it is narrower than the industry conversation suggests.
Staying with one vendor is right more often than not: one toolchain, one set of qualified IP, one support channel and one obsolescence roadmap remove a standing tax on a small team. Much of the writing on heterogeneous compute comes out of the data centre, where an orchestration layer hides the differences between accelerators and hardware can be swapped underneath. Embedded programs have no such layer, and the commitment is physical.
Vendor-specific memory controllers, transceivers, clocking and DMA need replacement or revalidation, timing constraints have to be translated between formats with different semantics, and closure has to be achieved again against different place-and-route behaviour. Standard HDL and open IP cores reduce the exposure, though high-end designs cannot fully avoid vendor-specific blocks.
Whether you want one design partner or several is a separate question and answers differently.
Fidus is a 20-year AMD Premier Partner and an Altera Gold Partner, and works with Lattice and Microchip too, which mostly means being able to tell a client when a second vendor adds cost without adding capability. The engineering sits in North America, in your timezone and close to the lab. See it applied on AMD Versal in our Sidewinder and Mantyss reference designs.
A 99% first-pass success rate across more than 4,000 projects is the frequency argument above seen from the other side: partitions that held when the boards came back.
Partitioning a system across CPU, FPGA, GPU and NPU is a decision made early, on incomplete information, with consequences that surface at integration. It is a commitment problem rather than a capacity problem, and hiring does not fix it Keep the architecture call and the acceptance criteria with the leader who answers for the program, and bring in cross-functional depth to test the partition across timing, power, signal integrity and thermal while changing it is still cheap.
Talk to Fidus while the partition is still a line in a specification.
Heterogeneous computing design splits a system’s workloads across different processing elements, such as CPUs, FPGA programmable logic, GPUs and NPUs, often on a single adaptive SoC like AMD Versal. The goal is for each workload to run where it is most efficient at the system level, including the cost of moving data between engines.
Hardware/software partitioning is the decision about which functions run as software on a processor and which are implemented in hardware, such as programmable logic or a dedicated accelerator. In heterogeneous systems it extends to choosing among several accelerator types.
After requirements are stable enough to evaluate and before the board goes to layout. Earlier, the specification is too fluid to hold a partner to. Later, changing the partition means a board respin.
Only inside the fabric. Partial reconfiguration changes what a predefined region computes. It cannot change board-level decisions such as the host-to-device interface, the memory map, power delivery or thermal headroom.
One, in most embedded programs. A single toolchain, IP set, support channel and obsolescence roadmap lowers cost and risk. Add a second vendor only when one portfolio can’t cover the workload mix, supply risk justifies a qualified alternative, or one part is uniquely right for a leg of the system.
The architecture decision and the acceptance criteria. They belong to the engineering leader accountable for the program. A partner should test the partition against those criteria, not set them.
Verified numbers on satellite payload processing, from EO launch growth to space-grade silicon and thermal limits, each traced to the institution that published it. Plus six widely quoted figures that failed the check.
Engineering is the hardest role in aerospace and defense to fill. Three questions show whether your FPGA or RF gap needs a new hire or FPGA engineering services.
Earth observation launches are nearly tripling, but downlink capacity per spacecraft hasn't kept up. Deciding what to process in orbit is now a hardware decision made years before launch.
Trust us to deliver on time. That’s why 95% of our customers come back.
