How Fast is Your ATPG?
Well, I told myself that as the ITC faded into the past, I was going to delve into the basics - explain to myself and anyone who cares to read how things like scan, ATPG, JTAG, and memory BIST work, and how some of the tools implement them.
But just as I was about to settle down, I tripped upon this little item on John Cooley’s DeepChip.com. And it made me think. Do I care how fast my ATPG tool is, and how much do I care?
If you didn’t already follow the links and read, John was asking whether Synopsys’ claims of TetraMAX’s 12x performance increase over the past year is just hot air. I for one did not question the veracity of their claims. After all APG vendors are constantly tweeking their algorithms. I was just wondering why it was a story at all.
Update: I just tripped on this article. This is one of the real stories in design for test today…
My reasoning below the fold…
Actually, to be fair to Synopsys, they did at least specify, “the same high-quality test patterns”, for “both stuck-at and transition delay fault testing”, “on all design-types”. I know that’s a little nebulous, but it is a press release.
Cooley brought up some very good concerns in his post: multiple clock domains, asynchronous logic, tri-state busses. However those things are best dealt with in the design, the responsibility of the designer or DFT engineer, not the ATPG.
Other concerns he mentioned, such as false or multi-cycle paths, can be inputs to all ATPG toools, but are are things that might reduce fault coverage, not necessarily affect the speed of the ATPG.
So, perhaps the designs I’m working on aren’t the hugest - not 50-100M gates, but they’re up there. My biggest concerns are size and quality. With the gate count going up, and the transistor size going down, the sheer volume of patterns it requires to catch the defect du-jour on top of the defects that are so-5-minutes-ago can overwhelm ATE test vector capacities. That why test compression, at-speed scan, and power consumption during test are what I’m reading about these days.
And that’s why, to me, speed is secondary. After all, it’s CPU time. I’m not watching it run.
Stumble It!
