DFT Digest

I always look forward to getting my new IEEE Design & Test magazine.  It seems to consistently contain  great articles that bring out leading edge practices in IC design and test.  And, refreshingly for me, mostly test.  Design-for-test.  Good stuff.

The May/June issue that just arrived in my mailbox this week did not disappoint – it was part 2 of the special issue on IEEE Std 1500 and Its Usage – I blogged about the first part in February: Get to the core of the matter – how will you test that core?. I tacked the discussion in the magazine onto other discussion that had taken place in the LinkedIn groups I had been watching.

Part 1 of the 1500 coverage in D&T aimed at bringing the reader up to speed on the objectives of the standard, the core test infrastructure and the language that expresses it, CTL (Core Test Language, itself an IEEE standard), improvements in core isolation, and some usage examples in the industry and EDA tools.

Part 2 tackled automation and verification of the standard, as well as some analysis of test data volume of modular (i.e. 1500-like) vs. monolithic testing. Also interesting was an article about core-based test of a mixed-signal SoC.

I guess the idea behind these two magazine issues was to show that core-based test, and in particular IEEE 1500 test, really is making its way into the mainstream, both with respect to industry acceptance and automation provided by EDA tools. Not that many people read what I write – but I have asked the question before, more than once, that if this really were a practical methodology, then, where are the tools? If it’s such a great way to go, why doesn’t everyone I talk to say “yeah, of course we’re doing that?”

So where are the tools? Between the two issues, there are two articles from folks representing EDA vendors: SynTest and Cadence. The SynTest article describes “Turbo1500″, a suite of tools for automating wrapper and scan insertion for a core-based SoC. The Cadence article also describes an automation methodology and a supposed tool-set to address IEEE 1500. Neither company has made announcements or document these tool-sets on their websites, so I guess the articles were more forward-looking than anything else. But great! At least someone’s working on them, right?  Right?

In all fairness, there are some companies that do use the 1500 infrastructure as part of tool-sets that serve other purposes.  That’s a start.

The article that most interested me was offered up in part 2 concerning test data volume: Test Data Volume Comparison: Monolithic vs. Modular SoC Testing, written by Sinanoglu, Seghal, Marinissen, Fitzgerald and Rearick (from a variety of places, so I’m guessing they were all involved in the standards work). The article set out both conceptual and mathematical arguments confirming that the benefits derived from approaching SoC test in a modular way far exceeded the cost of implementing core wrappers and the extra time required to access them.

That’s good news – for those who have the foresight to pursue modular test and test mechanisms from the start of your project – the payoff is there…