Good Library Hygiene Takes More Than an Occasional Scrub

You don’t shower only before you have to go to an important meeting (teenagers excepted). Surgical teams go further, demanding a strict regimen of hygiene be followed before anyone is allowed into an operating room. Yet we tend to assume that libraries and physical IP (analog, memories, other physical blocks) are checked and pronounced clean by the provider and thereafter require no further hygiene-checks.

That view is based on a presumption that libraries and physical IP were somehow frozen in time and were perfectly checked (or, more likely, that that is somebody else’s problem). In fact, library and other physical IP (and even hardened digital IP) are just as subject to change (and errors) as any soft IP. Bugs in design and characterization are found and fixed, parametric models are improved and models are updated to reflect process and design refinements. As a result, it is common that careful teams walk a library hygiene path close to surgical expectations to minimize surprises.

Here I’m not thinking about the functionality and general parametrics of the IP, but more the consistency, completeness and basic reasonableness of the library models. If a supplier or an internal group give you a NAND gate or a PHY or a memory which doesn’t function as advertised, you have to start a different discussion. But you should be able to detect and demand correction to bad library models before they contaminate active designs.

Fractal Technologies have just published an entertaining white paper detailing the daily routine of a user of their Crossfire product in ensuring that good library hygiene is maintained. They illustrate this based on a new rev of a design they call Enigma-II, very successful in the first rev, now being ported to a smaller process node with a few additional interfaces. And naturally they have a short window to release this updated product.

The library verification engineer’s day (the engineer is JT Kirk in the WP, next update hoping to see Michael Burnham) starts by checking the nightly regression – sounds familiar. In Engima-I the design team ran into a bunch of library inconsistencies, some caught late in design. Now using Crossfire, Jim can quickly detect mismatches between views or missing pin-labels in rarely-used corner-case files and fire off a “fix ASAP” note to the IP owners, with all relevant details.

Jim also has to complete the Liberty power model for an IP with 7 different power domains and nearly 100 power terminals. Lots of opportunities for mistakes in power arcs and power pin attributes. Getting this right requires careful checking between Spice and Liberty files with power-domain-aware schematic support using SpiceVisionPro (from one of my favorite companies, Concept Engineering). Jim finds a problem in the schematic which hadn’t been caught in Spice testing completed so far. Note that here he caught not a characterization bug but a design bug – potentially much more damaging.

Then Jim has to inspect a new foundry library update. Who knows what changes this might represent, across hundreds of cells and hundreds of process corners? With Crossfire, Jim can fire off regression runs across a server farm to retest all required checks, yet allow for some acceptable variation in parameters like terminal capacitances for example. A challenge here is that this many checks across hundreds of cells and corners could lead to a deluge in violations from a few root causes. Crossfire has a neat way to visualize such problems through what they call an error fingerprint, to quickly identify a possible root cause for multiple violations. Once isolated, he can start a discussion with the design team and possibly the foundry. No need for surprises at signoff – significant changes become visible immediately.

Enigma-I was a big enough success that Jim’s company wants a second source for the derivative design, so now he has to qualify another library. But he can’t afford to double his effort, so he communicates acceptable quality expectations to that foundry in the Crossfire Transport format; using this the foundry can run all required checks and make corrections as needed, so Jim’s final incoming inspection should always pass clean.

Multiple libraries, multiple updates, frequently updated IP – that’s life in design these days. We all need a process to ensure that what we are getting in these updates is as thoroughly scrubbed as we expect it to be – not occasionally, but every time we get a new drop, because we will be accountable for not finding problems, even if the root-cause was somewhere else. You can read the white paper HERE.