DFT Digest

Since the beginning of the electronics age, designers have been putting components together in interesting and useful ways; on boards, on chips, in packages, whatever gets the job done. A trend without end…

Among the more recent aspects of this trend are SoCs, multi-core chips, multi-chip modules (MCM) and systems-in-package (SiP).  The IP that comprises such a system may come from many sources, or may be developed internally, but as with any integration of functions, the DFT engineer’s challenge is always the same: how to test such a beast?

At the beginning of the year, I predicted core test as being one of the most talked about facets of design-for-test.  Allow me to quote myself (when no one else will, you gotta step up):

One way to look at it is that the trend toward multi-core is driving all these design-for-test issues: power-aware test, variability in smaller geometries, core test access, low pin-count test, System-in-Package (SiP), all of it. So for the world of DFT, I say 2009 will be more of 2008 – driving test technology on all these fronts to serve the proliferation of core design.

I may have been right… at least I’d like to think so.  Recently I resurrected an attempt at a discussion of core test started by someone in one of the DFT/Test-related groups on LinkedIn – I asked about what people were doing with respecct to strategy for core test.  I got a couple of perspectives on the the adoption (or lack thereof) of IEEE 1500.

Samy Makar, a senior DFT engineer at C-switch makes a good point: If you’re developing cores for internal use, it doesn’t really matter if you use a standard or not.  I’ll buy that.  He also said that although some IP takes advantage of 1500, many still don’t.  It’s a mixed bag.

Addressing the same point, Sudipta Bhawmik points out: “One reason for 1500 applications being not popular is that the promise of re-usability didn’t hold up to its hype”, at least with respect to delivery of hard macros. He goes on to say, concurring with Makar, that most re-use is internally driven, and test access is homegrown. “Re-usability is not driving ‘core test’ in most cases”

About the same time the discussion took place on LinkedIn, the new issue of IEEE Design & Test arrived in the mail, the cover story being IEEE Std 1500 and Its Usage! A confluence of discussion and related published material – can it get any better?  Inside this D&T was a collection of articles on the application of the standard.

I know that 1500 is not the only way to wrap a core, but I’ve always been curious as to why this standard hasn’t quite caught on yet with the EDA vendors – or core integrators – or… I guess it is somewhat of a chicken and egg situation.

It’s not that it’s been completely ignored; 1500 is now fairly standard as a test access method for industry standard memory BIST tools.  One of the aticles in D&T detailed LogicVision’s hierarchical 1500 test access scheme.  However, the missing tools in the 1500 toolset, in my opinion, are the ones described in an article written by ARM engineers – the verification tools.

Sure, 1500 was written to be flexible – so maybe automating the implementation for a general core may be difficult.  But once a designer actually wraps a core, being able to verify that the wrapper, control logic and CTL all match and comply with the 1500 and 1450.6 specs would be very valuable, and enable test generation as well.

In the same edition of Design & Test, there were articles on CTL, Turbo 1500 (SynTest) and a related “Last Byte”, by Miron Abramovici and the ever entertaining Al Crouch – positing the notion that creating dozens of new standards such as 1500 could single-handedly bailout the travel industry and save the economy with all the travel to meetings in every corner of the world.

So, how will you test your cores?