FPGA, CPLD or SoC FPGA: Questions to Ask Before Shortlisting
Choose between an FPGA, CPLD and SoC FPGA by describing the work your system needs to perform. Start with control responsibilities, data movement, software and startup behavior. Then investigate specific families.
A category name helps organize a search. It does not establish a device's memory resources, boot timing or suitability for your board. The shortlisting worksheet below is an editorial method for narrowing candidates before detailed engineering approval.
Define the job before comparing device families
Write one sentence for each responsibility. For example: sequence supplies, translate a board interface, process a continuous data stream, or run a software application. Keep these responsibilities separate even if you hope to combine them in one component.
Next, attach measurable requirements. For control logic, record response deadlines and output states during reset. For a data path, state input rate, processing latency and buffering needs. For software, identify the existing application, operating environment and required peripherals.
Use those statements to decide what to investigate:
| System responsibility | Candidate direction to investigate | Question that can eliminate a candidate |
|---|---|---|
| Board control and sequencing | CPLD or another suitable programmable-logic family | Can required outputs behave correctly throughout power-up and reset? |
| Custom parallel processing | FPGA fabric with appropriate logic, memory and arithmetic resources | Can the workload fit and meet its timing target? |
| Software plus custom hardware | SoC FPGA, or a separate processor and programmable device | Which partition gives the team a supportable hardware/software interface? |
| Interface expansion or bridging | A family with the required I/O and interface functions | Are the needed signals and electrical standards available in the chosen package? |
These are starting directions, not universal assignments. Keep more than one architecture on the list when the evidence is incomplete.
Use real family examples to test assumptions
The examples below show why specifications must accompany the category label. They are not ranked recommendations.
| Manufacturer example | Documented architectural fact | What your shortlist still needs |
|---|---|---|
| AMD Zynq 7000 | Integrates an Arm Cortex-A9 processing system and programmable logic; variants include single- and dual-core devices. UG585 | Exact device, software requirements and PS/PL partition |
| Altera MAX V | Altera describes a non-volatile CPLD architecture and shows board-management uses in its development-kit documentation. MAX V documentation | Required control behavior and the selected device's resources |
| Lattice MachXO2 | The family data sheet describes non-volatile programmable devices built around LUT-based logic. MachXO2 data sheet | Variant-specific resources, startup conditions and package interfaces |
| Microchip PolarFire / PolarFire SoC | The fabric guide describes non-volatile FPGA families; the SoC family combines the fabric with a five-core, 64-bit RISC-V subsystem. PolarFire fabric guide | Whether the processor subsystem is needed and how software will use it |
The Microchip example alone is enough to reject a blanket assumption that all FPGAs use volatile configuration. Equally, do not transfer one family's startup characteristics to every CPLD or programmable device.
Make startup a sequence of observable events
Replace “must start immediately” with the events that matter on the board. Define when supplies become valid, when each output must reach its required state and when the application may begin using an interface.
Ask engineering to document the selected device's configuration process and any supporting components. Identify what happens during reset, interrupted programming and a failed update. Record whether the proposed recovery route is accessible in the assembled product.
Keep early board-control requirements separate from application readiness. A system may need an enable or reset signal before its main processing function is available. Confirm which component owns that signal during every stage.
For a hypothetical controller, the initial shortlist might place supply supervision in one device and signal processing in another. A SoC FPGA could also be evaluated for consolidation. The decision depends on the recorded startup and workload requirements, rather than a preference for fewer chips.
Decide who owns the software work
If a candidate includes a processor subsystem, define the software responsibilities before comparing prices. Record the required boot software, application code, drivers and update mechanism. Identify who can build, debug and maintain each item.
If you are considering a processor implemented in programmable logic, request its specific IP documentation and resource estimate. Keep it as a distinct option from an integrated processor subsystem. Ask for evidence of the interfaces and software environment your application needs.
A useful review question is whether existing code must move. If so, list the components expected to transfer, the components requiring changes and the tests needed to establish behavior. Leave uncertain portability claims open until the software owner assesses them.
Compare the complete implementation proposal
Request a candidate sheet for each architecture. Include the proposed device, external memories, clock sources, power requirements and programming access. Add package constraints and the tool/IP versions needed for development.
Then review the proposal against the same workload. A design that omits a required buffer or interface is not ready for a cost comparison, even if its headline logic count looks attractive.
Separate technical feasibility from commercial information. Record quoted price, quantity and delivery date alongside the technical record, with the quotation's conditions. Ask engineering to resolve architecture changes before purchasing treats a lower-cost candidate as equivalent.
Finish with a shortlisting decision
Before moving a candidate to detailed design, record:
- Assigned responsibilities: the hardware and software functions it will own.
- Mandatory conditions: interfaces, startup behavior and workload targets.
- Evidence obtained: applicable documents and any preliminary build results.
- Open work: missing analyses, software tasks and board validation.
- Decision: continue evaluating, reject with reason, or approve the next engineering stage.
An architecture shortlist is an early decision. Keep production approval tied to the exact ordering code and the completed design review.
For a sourcing enquiry to FPGAX, provide the specific parts your team is evaluating, quantity and required date. Explain which choices are already approved and which remain architecture candidates. This gives the quotation a clear technical context.
