FPGA Production Release: Records for Engineering and Purchasing
Before an FPGA prototype becomes a production order, connect the approved hardware, design files and purchasing instructions in a single release record. A working demonstration is useful evidence, but the handoff also needs to identify exactly what engineering approved and what manufacturing should build.
The record should let another person answer practical questions: Which complete FPGA ordering code belongs on this board? Which programming file is released? What evidence supports the release? Who must approve a change? The checklist below is a proposed working method that teams can adapt to their own approval process.
Define the scope of the release
Give the release a unique identifier and name the product variant, board revision, BOM revision and source revision it covers. Record the complete FPGA ordering code, including its package and grade suffixes. Identify other configuration or boot components that belong to the approved design.
Review prototype deviations before release. A hand modification, substitute oscillator or different memory device can be easy to overlook when the prototype works. For each deviation, record whether it has been incorporated into the released design, removed or accepted under a documented limitation.
State the release decision precisely. “Approved for the named build” should point to the applicable evidence and authorized reviewer. Avoid expanding a limited demonstration into an unsupported claim about every operating condition or future production lot.
Preserve the engineering baseline
The engineering archive should contain the inputs needed to understand and maintain the released design: source files, constraints, IP settings, build scripts, tool identity and relevant reports. Give external dependencies an explicit location and owner.
AMD's UG892 describes the Vivado archive_project command, including options for sources and run results. It also calls out initialization scripts that affect the design. Use the documented archive options deliberately and record what was included. AMD UG892, Archiving Designs, 2026.1
Check the archive by restoring it in an approved environment and following the recorded build procedure. Retain the result and explain any differences that require review. An archive's existence and a demonstrated rebuild are separate entries in the release record.
Include a concise build note describing the starting revision, commands, dependencies and output locations. A future engineer should not need the original developer's memory to locate a constraint file or identify the intended output.
Prepare a controlled manufacturing package
Manufacturing needs clear instructions for the released operation. Provide the approved programming file, its identifier, the target device or memory, programming settings and applicable work instruction. Where multiple images or address regions are used, identify them explicitly.
Create a manifest containing each released filename, file size and a file hash using a named algorithm. Record the tool that produced the files and the date of approval. Keep superseded files out of the active production directory while preserving them in the controlled archive.
A file hash helps compare copies of a released file. It does not establish what was programmed into a particular device or prove that a board passed its functional checks. Record those outcomes with their own evidence.
Define how the recipient acknowledges the package. Ask manufacturing to return the release identifier and manifest it will use, rather than merely confirming that an email attachment arrived.
Link programming evidence to the build
For supported SmartFusion2, IGLOO2 and PolarFire flows, Microchip describes logs and digests that connect programming files with device content. It distinguishes bitstream-payload digests from device-component digests; their values are not interchangeable. Follow the documented method for the selected family. Microchip DS60001869A
Choose the evidence appropriate to your device and production method. In the work instruction, specify the required programming result, log location and handling of failures. Do not assume another family's digest or verification procedure applies.
Link the available board, device or work-order identifier to the release and programming result. If individual identification is unavailable, document the tracking boundary honestly. Keep board functional acceptance as a separate record with its procedure revision and actual result.
Hand purchasing an approved component list
Purchasing should receive the complete ordering code, required quantity, delivery schedule and the release or BOM reference. Mark which fields are fixed by engineering approval and who can resolve a discrepancy.
Keep proposed substitutions outside the released BOM until the responsible engineer approves them. A changed package, grade or configuration-memory part needs a recorded disposition. The purchasing record should show the decision and its effective release, rather than leaving the approval in an informal message.
Ask the supplier to identify the quoted manufacturer part number and document the agreed delivery and documentation requirements. Tie the purchase order to that quotation. Availability information belongs to the purchasing record; it does not alter the released engineering baseline.
A release index the team can use
Use a short index to point to controlled evidence instead of duplicating every report.
| Record | Minimum reference to retain |
|---|---|
| Approved hardware | Product, board and BOM revisions; complete FPGA code |
| Design baseline | Source revision, dependency list and archive location |
| Build evidence | Tool identity, procedure, logs and reviewed report set |
| Manufacturing package | Released files, manifest and programming instruction |
| Acceptance | Required checks, actual results and approving owner |
| Purchasing handoff | Approved BOM, quotation reference and change authority |
| Production execution | Work order or unit identifiers and result locations |
| Exceptions | Open limitation, responsible owner and disposition |
Assign a status and owner to each row. Missing evidence should remain visible; an empty field should not imply approval. Resolve blocking items before issuing the package for its stated use.
Control changes after release
When a released input changes, create a new revision and record the reason, review required and affected production range. Tell purchasing and manufacturing when the revision takes effect, and obtain acknowledgment that the correct package is active.
Use the first production build to check that the handoff can be followed. Record discrepancies between the released instructions and actual execution, then route corrections through the same approval process.
For a quotation from FPGAX, provide the approved complete part number, quantity and required date. Include the relevant purchasing reference and make any proposed alternative subject to your engineering review. Keep confidential design files and programming secrets within your organization's approved exchange process.
