A working prototype and a controlled engineering release are different deliverables. The prototype proves that a configuration can work. A release identifies exactly what was built, why it is accepted, how it is reproduced, what remains unresolved, and which files belong together.
The transition requires technical evidence and configuration control across hardware, FPGA, firmware, software, test assets, and manufacturing data. The depth of control should match project risk and scope, but the release should never depend on undocumented bench knowledge.
Key engineering takeaways
- ✓Plan bring-up before power is first applied and define safe stop conditions.
- ✓Record every tested hardware, FPGA, firmware, and software revision together.
- ✓Convert anomalies into an issue log with evidence, ownership, disposition, and verification status.
- ✓Link requirements and acceptance criteria to test evidence and known limitations.
- ✓Release a coherent package that another engineer can build, configure, verify, and continue.
1. Prepare the bring-up plan before the hardware arrives
The plan should define inspection, power sequencing, current limits, expected rail values, clock checks, reset state, programmable-device configuration, communication tests, and the order in which subsystems are enabled. Include stop conditions for overcurrent, missing rails, abnormal heating, or unexpected clock behavior.
Prepare the required test equipment, cables, programming files, known-good firmware, pin maps, and measurement locations. A bring-up session loses value quickly when configuration uncertainty is mixed with hardware uncertainty.
2. Establish a reproducible baseline
Assign identifiers to the PCB revision, assembly variant, programmable-logic build, firmware build, host software, configuration, and test procedure. Record the serial number or unit identifier for the tested prototype.
A result is reproducible only if another engineer can reconstruct the same configuration. Screenshots without build identifiers, register settings, stimulus information, and acceptance limits are weak release evidence.
| Configuration item | Minimum record |
|---|---|
| Hardware | PCB revision, assembly variant, rework state, unit identifier |
| FPGA | Source revision, constraints revision, tool version, generated image hash or identifier |
| Firmware/software | Source revision, compiler/tool version, configuration and deployed artifact |
| Test environment | Procedure revision, equipment, stimulus, fixtures, and relevant calibration state |
| Result | Measured evidence, pass/fail decision, anomalies, reviewer, and date |
3. Turn bench discoveries into controlled issues
Prototype bring-up is expected to reveal incorrect assumptions, design errors, assembly defects, timing problems, and integration gaps. The engineering difference is whether those findings remain in chat messages and memory or enter a controlled issue record.
Each issue should state the observed behavior, configuration, evidence, expected behavior, impact, current hypothesis, corrective action, and verification result. Link schematic changes, HDL commits, firmware patches, and rework instructions to the issue that caused them.
4. Verify against defined acceptance criteria
Verification should trace back to project requirements or explicitly agreed acceptance criteria. Cover normal operation, boundaries, error handling, startup, reset, configuration changes, sustained operation, and interfaces with the wider system as appropriate.
When a requirement cannot yet be verified, record the limitation and its release impact. Do not silently convert an untested requirement into an assumed pass.
- Identify the requirement or acceptance criterion being tested.
- Use a controlled procedure or clearly recorded test method.
- Preserve raw or linked evidence where practical.
- Record actual results, not only a pass/fail label.
- Document anomalies and the disposition of deviations.
- Repeat affected tests after corrective changes.
5. Prepare a manufacturing-ready data set
For PCB-based products, the release may include fabrication outputs, stack-up and controlled-impedance requirements, drill data, assembly drawings, pick-and-place data, BOM, approved substitutions, programming instructions, test requirements, and revision markings.
Review the generated outputs as a package. A correct schematic does not guarantee correct fabrication data, and a valid BOM does not guarantee that the assembly drawing, designators, variants, and programming steps agree.
6. Build a release package that can be continued
The release package should have an index, version, approval state, and clear relationship between source files and generated outputs. Separate released records from working files and identify any third-party components or tools needed to reproduce the build.
Include operating instructions, configuration, verification summary, known limitations, unresolved issues accepted for release, and the path for support or future revisions. This makes handover an engineering transition rather than a file transfer.
Primary references
Sources and further reading
External documents remain the authority for component ratings, standard requirements, and device-specific implementation details.