Software DFT

The recent thread on creating a time source proxy to test applications as they roll over to different dates brings to mind the general issue of testing.

My speciality is ASIC design. After a chip is made, it must be tested to ensure that it is free of fabrication defects. To reduce test time and increase yield, we build circuitry onto the chip that is used only for test.  Once the chip is shipped to the customer, said circuitry is usually never activated again.  We call this Design-For-Test (DFT).

DFT techniques in ASIC design center around increasing the controllability and observability of circuit nodes, which has an obvious significance when applied to hardware.

The same can be done with software.  The clock proxy is one example of a "software DFT" structure employed to increase controllability.

Has there been much research done on other software DFT techniques, especially those that make their way into the system as shipped to the customer?

David Jones
Thursday, April 15, 2004

I would have thought almost every shrink-wrapped S/W has some "trapdoors under the flooring" put in place for the developers by the developers.

One of our software does a system restart based on some input. Our trapdoor was designed to parse the input and if it contains additional specially formed data, then no restart, just the log file dump.

KayJay
Thursday, April 15, 2004

Since every copy of the software is bit-identical to the master copy, and there are no analog artifacts involved, I'm not sure the DFT concept applies here. Maybe signed assemblies come somewhere near?

Just me (Sir to you)
Thursday, April 15, 2004

<quote author="Just Me">
Since every copy of the software is bit-identical to the master copy....
</quote>

Not necessarily. Conditional compilation.

KayJay
Thursday, April 15, 2004

While I can't speak for shrink wrapped software, you will find that most embedded software is littered with diagnostic menus and capabilities that are not normally user visible.  As an example, your cell phone will have diagnostic menus that allow you to view your carrier, signal, offsets, etc.

While these are the most obvious signs of tests being designed in, proper design for test is more than just tacking on a few capabilities to view of manage internal states/data.  DFT in software can influence the architecture of the code, in some cases dictating how the code will eventually be structured.

This is fairly essential for embedded software, especially when you are trying to debug issues with an FPGA load that HW has guaranteed works correctly...

!
Thursday, April 15, 2004

KayJay and !

I would say you are describing more things like operational and configuration tests. As I understood it the DFT was more a post production test aid: testing the part in fab to see wether the produced unit was within spec.

Just me (Sir to you)
Thursday, April 15, 2004

I think XP's Test Driven Development (with build in hooks for testing a class) and mock objects (cooked up input) and unit testing frameworks like JUnit and CppUnit will come under the same category.

Nitin Bhide
Thursday, April 15, 2004

Unit tests are "sort of like" what you call DFT.  These are the test vectors which toggle every node, path, condition on the die.  To accomplish test coverage over the IC, you are required to have the test guys involved in the hardware deisgn - allowing them to insert multiplexers and switches where necessary and giving them a few external pins.

Same is true for software.  You have to give them access to internal objects, allow them to switch things in, switch things out and then they can get really good automated test coverage.  We do exactly this using Java's RMI as the means for the test harness ; to grab hold of the system under test.  While RMI does not ship in our product (this is a key difference, the harness is not wired into the end product - which can lead to a whole other discussion).

One of the key differences with software is when you require specific screen output.  This is often difficult (certainly not impossible) to test against.  Something like "did the font render properly" is just not worth the time spent on automation.

hoser
Thursday, April 15, 2004

  Recent Topics

  Fog Creek Home