Power Checks for Your Libraries

When your design doesn’t work, who owns that problem? I don’t believe the answer to this question has changed significantly since semiconductor design started, despite distributed sourcing for IP and manufacturing. Some things like yield can (sometimes) be pushed back to the foundry, but mostly the design company owns the problem. Even if you finally figure out the problem was in one of those outsourced technologies, it’s often too late to matter. Which is why incoming inspection is growing in popularity. Better to find a potential problem up-front when you still have time to get the supplier to fix it or you can possibly switch to another option.

Of course, you could reasonably argue that it’s not your job to QA vendor IP, but that’s not going to be much consolation if a bug gets through – see above. That said, IP suppliers generally do a very good job of comprehensive checking before they ship a release; very good, but not always perfect. This is just as much the case in foundation and custom IP as it is in big digital blocks. Some functions or corners have been better tested than others and some characterization errors will be fixed only as they are detected during the lifecycle of the IP. And, of course, some of that hard IP will be your own; are you sure that Liberty models for that PHY have been fully validated against the Spice netlist?

Power characterization is one area that may be more prone to this kind of problem than others, simply because aggressive power management and representation of these features is relatively recent. One very obvious source of potential problems here is in power/ground (PG) associations. Design for low-power depends on multiple power and ground options; planning which of these connect to which IP directly affects power architecture, yet the physical PG connections are not evident even as late as gate-level design and cannot be checked carefully until late-stage physical implementation.

The real PG connections in say a foundation or analog IP are apparent in the Spice netlist for that IP and you can be quite confident that a reputable IP supplier will have run LVS between the netlist and the cell layout. You might be slightly less confident that they have thoroughly checked the Liberty power modeling features for the cell against the Spice netlist, in this case checking the related_power_pin and related_ground_pin specs in the Liberty model. This is something Crossfire from Fractal Technologies, with their 1100 family of checks, will do for you. These checks cover Liberty delay and power models describing conditions, related power-pins and power-down functions, in all cases comparing between the Liberty model and the Spice netlist topology.

There’s a litany of reasons why design teams don’t do these checks; I heard similar reasons for soft IP when I was at Atrenta. First, “not my problem”. Maybe not, but it’s going to be somebody’s problem if an error slips through. Second, “the design tools will catch it before we get to implementation”. That’s not necessarily so, especially for hard IP. Missing arcs, or even pins or conditions can slip through. Even in implementation, timing analysis as one tool example checks against what the model specifies, not what it should specify.

Some problems, particularly PG problems, will eventually be caught at LVS. But waiting to that stage to catch a PG problem is probably suicidal. A PG issue could require rework of the floor plan and the power distribution network with corresponding ripple through all other aspects of implementation, just after you swore on an aged relative’s grave that you were going to tapeout tomorrow. All because you felt the IP providers/teams should do their job properly and you shouldn’t have to double-check their work.

Some brave souls have in the past scripted their own checking, but it’s looking like that approach has become very challenging for the latest technology nodes. And there’s no evidence these kinds of checks are available in other commercial tools or flows. So if you haven’t written and maintained a checker to work with the latest revs of Liberty, you really are gambling.

Yes, these problems are infrequent but they do happen. And when they do, particularly in hard IP, the downside can be pretty catastrophic, as hopefully I have made clear. You might give some thought to why there are some seriously heavyweight IP consumers using Crossfire today. They are big believers in “trust but verify”, not a bad philosophy when you have so much on the line. You can read the Crossfire white-paper HERE.