Taking on DFT
By Alan Sguigna
Vice President of Sales and Marketing
ASSET InterTech
It’s not like the boundary-scan industry hasn’t tried to affect change by making design-for-test an integral part of new product development. We’ve preached the value of DFT for many years. We’ve offered seminars extolling the virtues of DFT. We’ve trained countless engineers on how to do DFT the right way. What we haven’t done – until now at least – is offer tangible tools that automate and simplify the DFT process.
You might say that a DFT tool ought to be part of a computer aided design (CAD) suite. There is logic in that, but, quite frankly, we’re tired of waiting. ASSET has never shied away from taking on the tough technical issues, so now we’re taking on DFT.
Certainly there are easier issues to tackle, but we think that the payoff for our users is much greater when we are able to automate, simplify and facilitate a complex process like DFT rather than putting a few bells and whistles on a simple task.
For example, we saw a need to reduce boundary scan’s time-to-test. The result was our TopCAT™ technology. In benchmark tests on a complex circuit board with almost 9,000 nets, over 40,000 solder joints, approximately 6,000 components including more than 60 memory and over 40 logic clusters, TopCAT showed that boundary-scan test development time could be reduced to less than a day while achieving very high test coverage. TopCAT makes use of our online library of cluster device models. First, the schematic is analyzed to identify all of the non-boundary scan cluster devices that are connected to boundary scan devices. Next, TopCAT automatically matches the names of the cluster devices with device models archived in our web library of models. Once the device models have been retrieved, they are automatically included in the interconnect test generation process. TopCAT’s final step is to optimize the configuration of the device models in a test action for the highest test coverage and to ensure the safety of the board.
And then there are those processes that are ancillary to the actual boundary scan test, but which can have a major impact on test time. With Process Automation Scripting, the capabilities of ScanWorks are available through many of the programming languages that test engineers are most familiar with. Process Automation Scripting software objects can be created and controlled with interpreted languages like Tcl, Perl, or Visual Basic, or with compiled languages such as C++ or C#. Process Automation Scripting uses Component Object Model (COM), which makes its objects available to any language that supports COM. Some of the common uses of Process Automation Scripting include automatically gathering design description data, creating and managing ScanWorks projects and actions, logging fault coverage and test results data, and many more.
And now our next frontier is DFT. We’re tackling this issue with our newly introduced DFT Analyzer™ tool. Get an insider’s look at the DFT Analyzer tool in this issue of Connect from Dave Bonnett, our technical marketing manager. Click here for Dave’s insight.
|