IP Surgery and the Redundant Logic Problem

It’s now difficult to remember when we didn’t reuse our own IP and didn’t have access to extensive catalogs of commercial IP. But reuse comes with a downside – without modification we can’t finetune IP specs to exactly what we want in a current design. We’re contractually limited in how we can adapt commercial IP, however vendors compensate through a good deal of heavily tested configurability which seems to satisfy most needs. For in-house IP, the ROI to bring IP to commercial reuse standards is tough to justify but here there is much more freedom to get creative with a design. It’s more common to see copy-paste reuse, where you start with an IP already proven in silicon then adapt through selective surgery to meet current needs. The challenge of course is that getting this right is never as simple as carving out chunks of RTL and adding in new chunks. Dependencies ripple through the design and what had been proven in silicon, under surgery is probably going to break in interesting ways. Which according to Ashish Darbari (CEO of Axiomise) introduces new opportunities to apply formal methods in pursuit of that verification.

Is there really anything new here?

Of course you need to re-verify, but how far do you want to go down the path to complete re-verification? For argument’s sake, let’s suppose the original IP built on some 8-channel subsystem from which you want to drop 4-channels. You’ll start with the easy checks: formal Linting and coverage. Unless the design/testbench is already parametrized to take care of that possibility, around the area you cut out Lint might show bus size mismatches, inaccessible states, all the usual problems. From coverage you will see new coverage holes. Also not surprising.

These are the obvious must-fix problems but there will be more issues lurking in the rest of the design. The original IP was scaled to handle 8 channels; if you drop 4 channels it may still work fine but it won’t necessarily be efficient. The NoC was tuned for an 8-channel load – FIFOs in the NoC are now bigger than needed for this reduced traffic. More generally, when you remove logic is there any other logic you should also trim, to reduce area and power? Synthesis can help optimize away unnecessary logic to a limited extent, but not complex sequential logic.

Redundant logic

The idea that there could be redundant logic in a design might seem odd. In some cases, you can’t take it out without voiding a warranty, but otherwise if it’s not needed then why not remove it? Makes perfect sense when you anyway plan to invest in detailed verification on that IP. But what if you are doing surgery on a known good IP? You started with that IP because it would save you time and resources. If you have to go back to square one in verification and rediscovering the IP microarchitecture in depth, how much time and effort did you really save?

First-pass checking with Lint and coverage will help but these analyses are not quite as painless or complete as you might think. Take an unreachable state in an FSM. Lint (formal) will find this without problems, but it won’t tell you about the downstream logic made redundant because that state is unreachable. Maybe the state should be reachable (you created a bug) in which case that logic wouldn’t be redundant. Or maybe the state now being unreachable is OK and a function of the surgery, in which case that downstream logic should also be cut out.

Similar redundancies can appear after surgery around counters, FIFOs and other sequential logic. All because logic that was previously useful now has no purpose or should be modified. Axiomise has developed an app (formal based) which will identify redundant logic without requiring a user have expertise in formal. They call this Footprint.

Ashish adds that what Lint and coverage tools do, they do well but they are obviously designed to highlight the problems they target, not collateral problems like redundant logic. Lint will warn about stuck signals and coverage will warn about missed coverage bins (though only for cover points the testbench is checking).

Footprint on the other hand automates all these checks and is in production use in some of the biggest design houses, for good reason. Removing redundant logic can have real impact on area (and power), a million gates in one case. When you’re under pressure to signoff and fielding tough questions about why you are spending so much time on a proven IP, you might appreciate the help.

Check it out along with other Axiomise capabilities HERE.