DFT Digest

More than once, I’ve had requests to address analog (or analogue, if you’re a Brit) testability in this blog. I barely touched on it back in December of last year, in this post. I briefly mentioned some things I’d dealt with many years ago. Thinking about it today, it sure doesn’t seem like the EDA industry has come too far since then, with respect to providing tools for automating this kind of DFT. So it’s fair to say that mixed-signal design-for-test is really an ad-hoc process most all the time.

Other things that haven’t changed much are the types of circuits needing test: Amplifiers, filters, PLLs, ADCs, DACs, bias generators, regulators. Of course there are many more, but in the world of SoCs, those are the usual suspects. Agreed? If you’re involved with communications systems, you’d probably have to add a SerDes to that. Most of these are not pure analog, but actually mixed-signal, a combination of digital and analog. The digital circuitry, in these cases, is not normally structurally testable logic, but carefully crafted custom cells. And that’s just another facet of planning testability for mixed-signal circuitry…

The basic objective of analog DFT is the same as in digital cases. You have to maximize controllability and observability. Somehow, if there is a defect in your circuit, it must be possible for the effects of that defect to be propagated to some observation point. The observation point doesn’t have to be external; if you can figure out how to test your circuit internally, it usually saves test time. There are some products on the market that help in this regard. I’ll mention some as we go along.

In the near future, I’ll go through some of the different kinds of analog circuitry I’ve had to deal with, and some ideas for enhancing the testability. If you’re reading - send in your ideas. Educate the community!

A few days ago I wrote a plaintive post about an article I came across somewhere out there on the net, with the title “Dot 6 Explained”. Amazingly enough, the author of that article, James Stanbridge of JTAG Technologies replied to my post corroborating the obvious fact that it had been ‘edited’, and agreed to provide me with the full article, including ‘box-outs’ and figures.

So, if you’re interested, I’ve got it here in pdf format. I included the discarded diagrams, and the article reads much better, and is a nice introduction to the technology. I’d like to do some more discussion on the subject, simply because I’d like to learn more about it, so stay tuned for that.

Give it a read!

In a couple of previous posts, here, and here, I started discussing different design-for-test tools - you know, other than your run-of-the-mill ATPG and BIST tools. In the last post, I talked about a couple of tools that are targeted for the RTL domain. Now I’d like to mention some DFT-related products that are meant for use after the arrival of silicon.

It’s true: one of the nastiest bottlenecks in getting from silicon to production is debug of any kind of test on the ATE. One of the decisions a company should make is whether it’s wise to invest in what I call a “DFT tester”. A DFT tester is a scaled down version of a full-blooded ATE (big iron) that can, many times, fit into one of those god-forsaken cubicles that most of us work in.

Renting time on big iron can cost up to $500/hr. Add in the cost of the test engineer’s time, and you’re talking big bucks to debug scan vectors. So, over time, it may be economical to pick up a DFT tester. If your device is a SoC - the specs will eventually drive you to the bigger testers. But the more tester you design onto the chip (which, as DFT people, we should aspire to), the more you can accomplish on a low-cost tester.

One of the aims of the desktop tester seems to be ease of use, and seamless interaction with DFT tools, especially ATPG tools. This is done by interacting with them through the use of IEEE 1450 STIL, a standardized test language, which was designed for interoperability between tools and testers. STIL is a component in the common test architecture promoted by the Semiconductor Test Consortium (STC) - which is driven by Advantest, the world’s largest ATE vendor, but supported by no others - well, that’s a whole other story.

What I meant to point out were a couple of companies that offer lower-cost ATE solutions and software to address this DFT tester market: Inovys and Teseda. Each company offers both hardware and software to address DFT and debug level test. Inovys offers more on the hardware side (the Ocelot series ranges from a 256 pin ‘Personal Ocelot’, to a more production-worthy Ocelot, with up to 1536 pins). Teseda offers its ‘V520 DFT-optimized engineering test platform’, which is a littler lighter on the specs. I don’t know what the relative costs for these machines are. Each company also will provide debug software - mostly geared toward structural test (read ATPG) debug, and are STIL-based.

Anybody have experience with these testers? I’d love to hear about it!

just ran across the following article, “Dot 6 Explained” at the Components In Electronics website. I’m always interested in a good article on 1149.6 because it seems like a larger and larger percentage of interconnect is implemented with differential signaling - at least in my corner of the industry - and the longer I don’t use AC-JTAG, the less benefit I derive from boundary scan as a whole.

So I set in to read this article, and came out as foggy on the subject as before. My guess is that some editor chopped the hell out of it, because any sort continuity was hidden or non-existent. There were multiple referrals to a missing diagram or sidebar, and just when you thought the meat of the article was upon you, it abruptly ended with the marketing paragraph about the product, which, BTW is JTAG Technologies‘ ProVision.

Oh well… anybody out there have a better source (other than the text of the standard) of information on this technology? Speak up!

Update: See the comment from James Stanbridge below. It appears his article was “somewhat edited”. Also, I fixed the URL to JTAG Technologies above, which was wrong in the article. And my apologies to James is I maligned his writing - I guess it’s hard to maintain control over content after it’s been submitted in some places?

Design-for-test is a rapidly expanding task which is becoming more integrated with the design flow as time goes on. As I mentioned in my previous post, there are DFT-related tools spanning the range from RTL to the extreme back-end (which fall into the DFM category, IMHO). I thought I’d talk a little about those tools closest to the front-end of the flow: RTL.

Heres one: Atrenta specializes in RTL analysis tools to check your code for possible implementation problems, clock-domain crossing problems, power design issues, constraint management, and yes, DFT issues. SpyGlass-DFT analyzes your code against a bunch of DFT rules, and can estimate the fault coverage by looking at just the RTL, which sounds good, because changes can be made early in the design cycle. According to the datasheet, the tool can guide a designer through testability strategies and test point selection. Hmmm… watch out DFT engineers, your job can be outsourced by EDA software! Relax, there’s more to your job than ATPG fault coverage (I hope). Anybody out there evaluated or used this tool? Let me know your opinion.

Another slightly more pro-active approach to design-for-test in the RTL domain is offered by a company called DeFacto Technologies, headquartered near Grenoble, France. Their objective is to provide a tool that will insert DFT code into your RTL before synthesis, thereby reducing (RTL->synth->DFT analysis) iterations. Their product is, according to the website, due to roll out this fall. Should be interesting!

Enough for now, when I follow up, I’ll talk about some DFT-related tools you might use after the silicon comes back…