The production choice for an FPGA design depends on expected shipment volume, how often the logic may change, and what evidence is needed to release each unit. Compare complete production plans, including engineering and support, before comparing component prices.
Start with a working requirements list, an estimated volume range and a versioned design. For the underlying logic and development process, see the FPGA fundamentals guide. This guide focuses on the move from prototype to production, including the historical Xilinx EasyPath approach.
What EasyPath illustrates
The 2004 Xilinx EasyPath sell sheet, preserved by the University of Tennessee describes application-specific testing of FPGA devices for volume production, with functionality and timing matched to the prototype design. It also advertises dual-design testing and certain logic/I/O changes, with family-specific restrictions and additional charges. Those details matter: production flexibility was defined by the program’s test coverage and terms.
Treat its prices, turnaround claims and supported families as historical. For a present procurement decision, request a dated quotation, exact ordering code, permitted bitstream changes, lifecycle status and written support terms. The EasyPath lesson is a general one: a cheaper production path can change what is guaranteed and how later revisions must be handled.
A product’s intended market also needs its own evidence. For an automotive design, obtain the applicable qualification information for the exact device and ordering code and determine the system-level obligations. A general production-cost program provides a different kind of information.
Calculate the crossover, then test its assumptions
Use total cost = fixed engineering and qualification cost + quantity × recurring cost per shipped unit. Include programming, test time, expected losses, fixtures, licenses and the work needed to support production. Keep one-time and recurring costs separate so volume changes are easy to evaluate.
Repeat the calculation at low, expected and high lifetime volumes. Then add a revision scenario: a field change may need a new bitstream, test program, tool version or board. Put the expected expense and schedule beside the component savings. An uncertain volume forecast can outweigh a small difference in unit cost.
Define what production must reproduce
On a narrow screen, scroll the table horizontally. Keyboard users can focus the table region and use the arrow keys.
| Decision | Record before release | Reason |
|---|---|---|
| Device | Full part number, package, speed and temperature grade | A family name leaves consequential variants unresolved |
| Design | Source revision, constraints, IP versions and bitstream hash | Connects the shipped configuration to its evidence |
| Build | Tool version, licenses, scripts and timing reports | Makes the released implementation reproducible |
| Test | Coverage, limits, fixtures and retained results | Shows what a passing unit has actually demonstrated |
| Change | Allowed substitutions and revalidation triggers | Keeps cost reductions tied to controlled requirements |
| Lifecycle | Supplier notices, last-buy terms and recovery plan | Supports continued production and service |
As one concrete compatibility dependency, AMD’s Soft Error Mitigation controller documentation identifies an EasyPath restriction for its correction-by-replace method. Check the documentation for the particular feature and device you intend to ship. A migration that preserves package and pins can still affect a system feature.
Use a release checklist with named evidence owners. A timing report proves something about the implemented design and stated constraints; a production fixture proves only the behaviors it exercises. Record remaining coverage gaps so the release decision is explicit.
Plan the next revision before the first shipment
- Freeze a candidate build and reproduce it from the retained source and tools. Resolve unexplained differences.
- Run acceptance tests against requirements, including power-up, configuration recovery and interfaces used by the product.
- Ask the supplier which design changes remain covered and which require new testing or commercial terms. Preserve the answer with the quotation.
- Define a change review for device substitutions, tool updates, IP revisions and bitstream changes. Repeat the tests affected by each change.
- Select the production path whose cost and revision plan remain workable at the low-volume forecast. Document why the alternatives were rejected.
The useful result is a release package someone else can reconstruct: design, build, test, supply assumptions and an owner for future changes. The custom-module requirements guide extends this approach when another company supplies the complete board or module.
Keep a working record
Download the fpga worksheet (editable text). Save a copy, fill in the fields for your situation and record exceptions as well as successful checks. The worksheet includes its purpose, source links and any example assumptions.