DESIGN FOR TEST (DfT): STARTING WITH THE END IN MIND

The list goes on and should be tailored depending on what makes sense for each design. While not technically DfT, the JTAG debug interface is a great example of a DfT like feature for embedded controllers. The same debug can be done without it by lighting LEDs at certain points in the code, but you can imagine how much slower that approach is. Now that we have this debug interface, it sounds crazy to try to design without it!

One central mantra of DfT is test early, test often. This approach allows defects to be found early, leaving time to remedy them without overly extending the schedule. Once the root cause of defects are determined, fixes often require hardware spins, and entire workstreams can grind to a halt waiting for this work to complete in the late stages of the project. On the other hand, if defects are found in early testing, work can usually be reprioritized to keep the team moving while a remedy is put in place. For example, when developing a new sensor, it can be useful to use development boards, or create small custom PCBs to prove out the functionality and test performance before integrating into the larger design.

Another central mantra of DfT is design for modular testing. This enables testing on less complex subsystems, earlier in the project. Design the system such that each subsystem can be tested independently of the rest of the product. If thorough testing is not done until the whole system is built, defects become exponentially harder to root cause. Design software in such a way that it can simulate other parts of the system as needed and add the hardware hooks to do the same with known good bench equipment.

Design for Test (DfT) Mentality 

Some examples of DfT mentality:

1. Design in test modes to isolate functionality.
2. Put test points on important nodes to source and measure what you need rather than having to solder wires onto small components during prototyping. Is it easy to access this node with the probe, or will debug require some gymnastics? Consider bringing the signal out to a breakout board if necessary.
3. Put clear labeling on the board, so test points can be readily identified.
4. When designing for production, add test points or headers to facilitate testing and calibration.
5. Design test fixtures to enable fast and reliable production flows.
6. Design in ways where functional blocks can be isolated for the larger system.
7. Make sure there are adequate grounding points for measurement (number and location for easy and accurate probing), especially for high-speed signals.
8. Create informative error messages and debug hooks in the code rather than passing generic error codes up through the layers. Generic codes through layers make it hard to determine where they originated.
9. Design in self-test modes that allow subsystems to test other subsystems if possible. Explicitly put these processes into the schedule, and review them with the whole team.

In order to be successful in a DfT mindset (and product design in general), it is critical that product requirements be clearly defined up front. A requirement is not a requirement if it cannot be tested. Once top-level requirements are determined, they can be reflected down into each subsystem and used as block level design guides. Put a test plan in place for each subsystem requirement, and design in the hooks necessary to test them. You can learn more about how to write complete and testable requirements in the whitepaper: Developing a Product Requirements Document.

Writing testable requirements is especially important when designing a medical device, when ISO 13485:2016 standards apply. The DfT effort should include all disciplines, not just the system architect. It will facilitate team cohesion and flesh out the tough interdisciplinary issues that are often missed before they become a big problem. Once this plan is fully formed, not only will defects be found early, but by the time the design is complete, most of the production test plan is complete as well. Your production line will run smoother because a lot of the test plan has already been debugged, and common failure modes are known. Field failures? Plans are already in place to quickly resolve them. Perhaps you did such a good job at DfT that debug firmware can be downloaded from across the world to root cause the issue without having to fly out engineers.

The trick to DfT is to not view it as a necessary evil, but rather an important derisking activity. You may have heard the Navy saying, “slow is smooth, and smooth is fast”. Often when projects are looking to cut time or budget, good test practices are the first thing to go. Not only does this add risk, but it almost always ends up in costing time and money in the end. On paper, it looks like there is trimmable fat in DfT planning stages at the beginning of the project. That can be done at a later stage, right? We want to “get the design going” to find early learnings about how it’s going to work. Taking that logic to the next step is realizing that those learnings themselves require testing. Effective testing requires preparation, planning, and good design. Put that planning up front and design it into the product. You won’t regret it, and neither will your budget!