You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

IP Wanna Go Fast, Core Wanna Not Rollover

At a dinner table a couple years ago, someone quietly shared their biggest worry in EDA. Not 2GHz, or quad core. Not 20nm, or 450mm. Not power, or timing closure. Call it The Rollover. It’s turned out to be the right worry.

Best brains spent inordinate hours designing and verifying a big, hairy, heavy breathing processor core to do its thing at 2GHz and beyond. They spent person-months getting memory interfaces tuned to keep the thing fed at those speeds. They spent more time getting four cores to work together. They lived with a major customer or two making sure the core worked in their configuration. They sweated out the process details with the fab partners making sure the handoff went right, and working parts came out the other end. All this was successful.

So, the core has been turned loose on the world at large, for anyone to design with. On some corner of the globe, somebody who has spent a lot of money on this aforementioned processor core grabs an IP block, glues it and other IP functions in, and the whole thing starts to rollover and bounces down the track to a crunching halt.

The EDA tools can’t see what’s going on, although they point in the general direction of the smoke. The IP function supplier says that block works with other designs with that core.

The conclusion is it’s gotta be the core, at least until it’s proven innocent. Now, the hours can really start piling up for the design team and the core vendor, and more often than not it will turn out the problem isn’t in the processor core, but in the complexity of interconnects and a nuance here or there.

Been here? I wanna go fast, and so do you, and the IP suppliers do too, and there are open interfaces like MIPI to help. The harsh reality is that IP blocks, while individually verified functionally, haven’t seen everything that can be thrown at them from all possible combinations of other IP blocks at the most inconvenient times. Enter the EDA community and art of verification IP in preventing The Rollover.

Problemmatic combinations aren’t evident until a team starts assembling the exact IP for a specific design, and the idea of “verified” is a moving target. Synopsys has launched VIP-Central.org to help with this reality. Protocols have gotten complex, speeds have increased, and verification methodologies are just emerging to tackle the classes of problems these very fast cores and IP are presenting.

Janick Bergeron put it really well when he said that Synopsys is looking to share learning from successful engagements. No IP supplier, core or peripheral, wants to be the source of an issue, but some issues are fixed more easily than others. Understanding errata and a workaround can often be more expedient than waiting for a new version with a solution from the IP block supplier, and a community can help discuss and share that information quickly.

The idea of verification standards in EDA wasn’t so functional IP suppliers could say they’ve checked their block, but instead to give designers a way to check that block within a new design with other blocks of undetermined interoperability. “Verified” IP catalogs are a starting point, but the real issues have only started to surface, and verification IP can help avoid your next design being a scene in The Rollover.