EVT (Engineering Validation Test), DVT (Design Validation Test), and PVT (Production Validation Test) are the three sequential validation builds that take a hardware product from prototype to mass production. These three stages follow a proof of concept (PoC) and a prototype, which show that the idea is feasible and give a first working version. Each answers a different readiness question: does the engineering work, does the final design meet its requirements, and can the factory build it consistently?
The cost of missing a problem rises with every build: an early change can cost around $50 at the sketch and foam-model stage, compared with 500–1,000 for a rapid prototype and up to $50,000 for a production tooling change, potentially adding weeks or months of delay. Firmware readiness deserves the same attention as hardware because unresolved gaps can hold up builds, testing, and production.
This article explains what happens at each stage, how hardware and firmware progress through the validation builds, and what teams must complete before mass production.
What EVT, DVT and PVT mean for firmware
EVT, DVT, PVT are a sequence of three validation builds that a hardware product must pass before mass production. Each build is a physical batch of PCB and enclosure units, along with a certain percentage of features implemented in the firmware, and a formal stage gate: the team tests the batch, reviews open issues, and decides whether to move on or rebuild.
Before EVT comes a prototyping phase (Proto or PoC), in which firmware engineers build an alpha version on development boards without an enclosure, implementing only the main features needed to validate the approach.
All stages of the hardware development process run in order and should not be skipped, because each change costs more after the previous stage passes. Behind every gate sits firmware and test work that often decides the outcome, from bring-up and diagnostics to factory test firmware, OTA, and the signed release image.
Note: Build sizes depend on product and volume, so treat them as ranges, not rules. Instrumental’s handbook gives consumer-electronics numbers (EVT 100–1,000 units, DVT 300–2,000, PVT 1,000–20,000), while smaller industrial and IoT programs often build far less, with a typical DVT run at 50–200 units.
| Stage | Main goal | Typical build size | Exit criteria |
|---|---|---|---|
| EVT | Verify that the engineering design works as intended | Tens of units, up to about 1,000 | Requirements met in at least one configuration; top design risks identified |
| DVT | Prove the production-intent design meets every requirement | 50 to 200 units in many programs, up to about 2,500 | Passes reliability, environmental, and compliance testing with test limits enforced; no further design changes expected |
| PVT | Demonstrate that the factory can build the design repeatably | 5–20% of the first purchase order, from a few hundred to 1,000+ units | Target yield and speed reached with final fixtures and released firmware |
What firmware must be ready for EVT?
EVT needs two pieces of firmware: bring-up code that configures every part of the board, and a diagnostic build that lets hardware engineers test each subsystem without waiting for the finished application. The memory layout and boot sequence should also be settled by now, because changing them later forces rework on everything built on top.
Board bring up is the first time a new board is turned on. Engineers check that power reaches every part, the clocks tick, the board resets cleanly, and a debugger can connect. Then they test all peripheral devices to confirm every chip responds. The process ends with a basic functionality test and a handover to the software team, which separates it from formal EVT testing.
Up to 40% of units may fail during early product tests. Each failure raises a critical question: is it caused by a hardware fault or a firmware bug? Running diagnostic testing helps engineering teams identify the root cause in minutes instead of spending days troubleshooting.
One should also rely on basic traceability. Log every board's hardware revision and firmware version from the first unit. It looks like paperwork, but it lets the team say “this failure only happens on revision B with firmware 0.3” instead of guessing.
What has to be locked before DVT starts?
Before DVT, three things must be locked: the factory test firmware, the bootloader, and the OTA/OTW update mechanism. Units in a design validation test build go through reliability and certification testing, so they must run exactly what will ship. How much a late change costs depends on the product. In safety-critical and regulated products, the firmware is part of what gets tested and certified, so a change after DVT means repeating testing. In consumer products, the impact is usually smaller, but a late change to the bootloader or the update path still means retesting.
Factory test firmware is a separate program that can run on the test fixture or the product itself to run a hardware test suite and configure a product serial number and other parameters.
Bootloader, OTA, and certification builds come next. Freeze the bootloader first, since every later update depends on it. Then stress-test OTA: confirm that a failed update rolls back cleanly, and cut power mid-update to see whether the device recovers instead of becoming unusable.
When choosing an OTA approach, teams can use a chip-vendor update solution, develop a custom implementation, or adopt a ready-made service such as Memfault, Mender, or RAUC. Teams still hesitating on the update stack can start with this practical guide to Memfault, Mender, and RAUC. Certification needs attention too: the RF and EMC labs require their own test-mode build, which is easiest to prepare while the rest is being finalized.
Regression across hardware revisions matters because more than one board revision is usually in circulation by now. One firmware image reads a board ID at boot, and hardware-in-the-loop (HIL) testing runs each new build against every revision still in use.
What does PVT testing validate?
PVT testing checks that the production line can program, test, and pack units at target speed and yield. By now, the product design is frozen, so what’s under test is the process. At this stage, the factory’s own operators build the product from written work instructions, with design engineers partially supporting the line.
By the end of the PVT, the team should have four things in hand:
- First, release firmware ready to ship. It needs a signed golden image, a versioned release process, and a documented way to load it at volume, whether through pre-programmed parts, in-circuit programming on the line, or the test fixture.
- Second, a measured picture of line performance. Test time per unit and first-pass yield, meaning the share of units that pass without rework, are recorded at target speed, and the test limits come from real production data instead of estimates.
- Third, full traceability for every unit: the serial number, hardware revision, firmware version, calibration values, and test results must be documented so one can trace a field failure back to the exact build that produced it.
- Fourth, a first update that has already been tested. In most production setups, the factory flashes the production firmware at the end of end-of-line (EOL) testing. Then, if the launch firmware will be replaced soon after shipping, the product receives a forced OTA when it starts at the customer’s, so that first OTA should have run on PVT units before mass production. This is called Day 0 firmware: a release that goes out after the device ships but before the customer unboxes it. Without that check, the initial real test of the update path happens on customers’ devices.
If any of the four is missing, PVT isn’t finished, and the build shouldn’t move to mass production.
When is a product ready to move to the next EVT, DVT and PVT stage gate?
A stage gate depends on test results: before moving forward, every open issue should have an owner, severity, and disposition. Anything that could trigger a hardware revision, invalidate test results, or require another build should be resolved first.
Firmware defects can carry forward when their fixes are isolated from the bootloader, partition map, and factory test software. So, they can be delivered without changing the validated configuration. As the product approaches production, the bar gets higher: the team needs evidence that the design is stable and the manufacturing process is repeatable.
Skipping the sequence is expensive. For instance, Instrumental’s handbook describes teams starting hard tooling in parallel at the end of EVT; in its example schedule, that “continuous build” ended in a delay of up to 15 weeks.
| Gate | Must be true to proceed | OK to carry on | Red flag |
|---|---|---|---|
| EVT → DVT | Core requirements pass on the selected hardware configuration; subsystem diagnostics and test coverage are in place; boot chain and partition map are defined; units and test results are traceable. | Minor application defects; power or performance tuning with sufficient margin; cosmetic issues that don't affect validation. | Critical requirements still fail; subsystems cannot be tested independently; bootloader or partition changes invalidate existing test results. |
| DVT → PVT | Production-intent hardware meets requirements; reliability and compliance testing is complete or has an approved disposition; firmware, bootloader, and factory test software are frozen; regression passes on the release configuration. | Non-critical application bugs with a verified OTA fix and no impact on safety, reliability, or production testing. | Hardware changes invalidate certification or reliability results; factory test limits remain unverified; OTA rollback or power-loss recovery fails. |
| PVT → MP | Production line meets target yield and cycle time; test coverage and traceability are demonstrated; programming and calibration follow documented procedures; production firmware and update path are verified; DFM and tooling in the factory are done and tested with a few samples. | Minor issues covered by a Day 0 update. | Yield depends on manual workarounds; operators rely on undocumented steps; test failures are unresolved; shipped units have no verified recovery or update path. |
What does the EVT, DVT and PVT process look like in practice?
In the EVT, DVT, PVT process, hardware, firmware, test fixtures, and certification run as separate tracks. Firmware follows its own maturity path, progressing from an early Alpha version during prototyping to a Beta version at EVT, a Release Candidate at DVT, and a production release by the start of PVT.
| Build stage | Required firmware | Blocker |
|---|---|---|
| PoC/ Alpha | Initial drivers, core state-machine logic, and communication interfaces. Developed on evaluation boards to verify that the main functionality is technically feasible. | Core functions cannot be demonstrated, or major hardware and firmware feasibility risks remain unresolved. |
| EVT/ Beta | Bring-up firmware for PCB Rev. A, followed by most or all planned product functionality. Major subsystems must be operational and testable. PCB Rev. B must be brought up and tested by the end of EVT. | The board cannot boot reliably, critical subsystems cannot be exercised, or hardware faults cannot be isolated from firmware defects. |
| DVT/Release candidate | Finalized and extensively tested firmware on PCB Rev. B. Includes security and regulatory configurations, a frozen bootloader, self-test firmware, configuration tools, and factory programming and testing support. PCB Rev. C must also be validated. | Critical defects remain, certification requirements are unmet, or manufacturing programming and testing still depend on engineering tools or manual workarounds. |
| PVT/Production release | Released production firmware, with signed release images, documentation, and production support. Only minor fixes or polishing should remain. Manufacturing and test processes are validated on production-intent units. | Critical defects remain, release images are not controlled, or firmware changes invalidate previous validation results. |
| Before MP/ Day 0 | Approved Day 0 firmware and a verified OTA update, rollback, and recovery path. | The first update cannot be installed or recovered reliably, or the shipped firmware differs from the approved release. |
At every stage, EVT, DVT, or PVT, the real question is whether the product is ready to move on. Hardware results rarely answer it alone. The firmware work behind each stage often decides the outcome: bring-up and diagnostics for EVT, locked factory test firmware, bootloader, OTA before DVT, and signed release firmware with a tested first update by PVT. If your next gate is close, our hardware and firmware teams can help you not only check what is ready but also close gaps.
