Quality in Hard IP

I was CTO at Atrenta, home of SpyGlass, for many years before the company was acquired by Synopsys, so I know a thing or two about IP quality, to paraphrase a popular commercial. The problem is that even in the best-run IP shops, errors happen. Sometimes they happen on simple changes, especially when you think “This IP has been very carefully checked and the change I just made is so small it won’t affect anything”. They also happen in configurable IP, especially near architecture transitions where not all possible configurations have been comprehensively validated.

At Atrenta we worried about soft IP and were sometimes told “We have it covered internally and we’ll catch any escapes in simulation”. Then we’d wait (with confidence) for a call-back after a quality problem made it to silicon. But the “we’ve got it covered” argument is even more difficult to defend with hard IP. Simulation isn’t going to tell you that you have a mismatch between your GDSII and LEF models or an un-routable pin or many other potential problems in the long list of files now needed to describe a hard IP. Sure you’ll catch some of these in layout, but that’s way too late to be finding basic problems that could trigger major rework. And some will still escape to silicon.

Where can errors happen? Perhaps in foundation (cell) libraries. These get pretty well shaken out unless you’re an early user but some cells at some corners could remain untouched until you stumble across a problem. Memory compilers are a more likely source for an undiscovered problem because they are configurable. Then there are internally sourced hard macros – PLLs, PHYs, ADCs and DACs, voltage references, special I/Os. And there are hardened digital IPs – ARM cores, GPUs and accelerators – optimized by an internal team for performance, for whatever power profile you need for this design and for layout footprint. In all of these cases it’s much more likely you will be the first user on any given incarnation of a block and that you may see multiple releases of a block before tapeout.

What are typical errors? A small subset of examples, encountered on production designs, include:

• Pin direction mismatch between views, pins in the wrong layer
• Missing labels, or label spelling errors or labels in wrong layer
• Abutment errors (layers do not touch outline)
• Pins not on grid
• Delay decreases with increasing output load, non-paired setup and hold times in Liberty file
• CCS curves have more than one peak or a correction current in the tail
• ECSM curves have large deviations between ECSM and NLDM values
• Transistor bulk terminal connections in Spice incorrect

Checking for these kinds of problem obviously can’t be left to visual inspection, across potentially terabytes of data, much less at each point in the design evolution where errors may have crept in. You could build tool-based scripts to check for some problems, but that gets messy when you want to check correspondence between a Verilog view, a layout view and a Spice view. And you have to worry about the correctness and currency of over 30 parsers. If you feel that building and maintaining that kind of infrastructure is a good use of your company’s time, go for it. Or you could take a look at Crossfire from Fractal Technologies.

I first became aware of Fractal several years ago. I felt that Crossfire would be a really good fit with SpyGlass – SpyGlass for soft IP quality and Crossfire for hard IP. For various reasons we didn’t pursue that further, but not because I was unimpressed with the product or the company. I still feel Crossfire would be a great complement to SpyGlass. I also happen to know that, without naming names, some of the most significant design teams in the world use Crossfire. These teams are staffed by the best of the best. When they believe it is important to perform these checks, it’s worth taking note.

You can learn more about Fractal and Crossfire HERE.

More articles by Bernard…