Is DfD the Future of DfT?
The concept of DfX or Design for Excellence is very simple to understand. The goal is to increase the value and quality of a new product using established industry methods. The development cycle goes through different phases which is why DfX comes in many flavors. There is DfM (Design for Manufacturing), DfA (Design for Assembly) and, of course, DfT (Design for Testability) among many others.
With thousands of new products coming and going, does it make sense to bother with standardized guidelines? The answer is simply, absolutely.
A world without DfT – what could go wrong?
By zooming in on design for test, a product designer is focusing on how to optimize the future test process, assuring better product quality. DfT can include adding more test points and devices to measure parameters, or the ability to run self-tests, set itself in test mode, and so on.
But why worry?
Well…brand new hardware is being tested and that hardware is running brand new firmware. That new hardware running new firmware is loaded on a new tester. Don’t forget, the new hardware running new firmware on a new tester is running new test software. Piece of cake.
Design for Debug: Looking Ahead into DfT
By applying DfT principles on to the test station itself, simple design features can make debugging much easier. This doesn’t have to cost a lot if it is planned in advance by a test engineer.
Common Steps for Better Debugging
- Confirm every stimulus.
It is important to remember that device under test (DUT) outputs are dependent on good inputs. It is key to make sure all unterminated DUT inputs are driven to a definitive condition. It is also a good idea to use spare inputs to capture what is being fed to the DUT and always check the input against limits. - Digital I/Os are not determinant.
A digital I/O device provides digital input and output capabilities for computer-based systems. Using a digital I/O device makes it possible to monitor (read) the statuses of measuring devices as well as the relays and operation switches of various types of control circuits. They are guaranteed to deliver a specific logic value, not an analog signal level. Subtle characteristics can vary like input threshold, output impedance, termination and others...plus everything is temperature dependent. - Externally monitor every measurement.
In the tester design, include test points to monitor each measured signal and independently verify the actual signal level with the measurement. Don’t forget, the monitoring signal be affected by interference so use buffers, if necessary. - Modularize the test sequence.
It is always easier to digest small bites. Break up the test sequence into simple small modules and focus only on the broken test. This allows for a quick in, you can loop on the test for a while, and then get right out. This should be done gracefully, do not assume the inputs are already set. Check these first and set them if necessary. To get out of the module, set a breakpoint, make a measurement, and abort the test. Entry to clean up (like TestStand) should be accessible from any point. - Break loops and long signal paths.
Allow the test hardware to inject signals at various points in the signal flow and exercise each of the tester’s functions separately. These rules apply equally to hardware and software. This does not need to be complicated, just make the default for the DUT to be connected and cut a trace to isolate. A jumper wire can be added to then reinstate. - Log everything.
Capture as much data as possible, look at waveforms instead of discrete measurements and raw data instead of filtered or adjusted data. Also, add things that are not required to confirm the stimulus. Lastly, keep all data that is captured, not just the data for the failed tests. Sometimes the answers lie elsewhere. It also helps to set up a parallel debug log to the normal data report. - Use the right tools.
Don’t use Windows for timekeeping, use the tool that corresponds to the response time that you need:
Desired Response Appropriate Tool psec ->
VHDL, Verilog
nsec ->
LabVIEW FPGA
µsec ->
LabVIEW RT
msec ->
PLC
- Use triggers to start measurements and to monitor tests.
For the full picture, use a deterministic event to trigger each measurement. If a delay is required, use a timer and make the delay adjustable. You never know, the DUT may change the timing. Once running, use triggers to see how things change. Any spare outputs can be connected to accessible signals and try different things! Make a pulse or toggle an output and see what happens. It is recommended to allow the test hardware to inject signals at various points on the signal flow.
DfT is crucial and is based on repeated success. It results in better products overall with reduced manufacturing and support costs. Is Design for Debug the next step in the DfX family?
For any questions or support for test design, please contact Averna.
Looking for better test?
Sometimes the trick is simply letting go. Check out the benefits that come with outsourcing.
Get in touch with our experts or navigate through our resource center.
