Telephones used to be a treasured resource. Having one in your house was originally a luxury, then an expectation. Today we all get phones and carry them with us. But instead of paying tens of dollars per month, we willingly pay more than $100—maybe much more. And we take it all for granted.
Bell’s original wired contraption withers compared to what’s inside today’s smart phones. More astounding yet is how these phones are obsoleted almost monthly. New phones with new features or new combinations of features are being designed at a dizzying rate. Systems far more complex than the ones we send to Mars are designed and redesigned in a matter of months.
Of course, these phones are small, so high integration is key. System-on-a-chip (SoC) designs must be done and then done again and again for each generation, with scarcely any time for breathing in between. And each SoC is more intricate than its predecessor.
In about a 10-year span, from roughly 2000 to 2010, the complexity of the main chip in a mobile phone grew more than two orders of magnitude, from less than 100,000 ASIC-equivalent gates to more than 10 million ASIC gates. In 2012, an advanced smart-phone IC will consume between 30 million and 50 million ASIC gates.
A Daunting Task
How can anyone design something so huge so fast? There’s only one way: intellectual property (IP). Once a tiny industry begging for credibility, IP is now the way that such chips can be designed. And, while mobile designs consume tons of IPs, both internally generated and third-party, it’s not limited to that industry. IP is a standard ingredient in most any serious SoC for most any application.
Ideally, a digital IP is available in register transfer level (RTL) form so it’s easy to understand. But IP providers want to protect their secrets, so they often offer a hardened implementation with an encrypted RTL model for simulation. And this is where things become difficult.
Verilog 2005, for example, has “protect” and “unprotect” statements. That much is standard. But the implementation of the protection isn’t standard. The result is that different verification tools may support different encryption algorithms and keys. So an IP model that works on, say, VCS may not work on NC-Sim.
While IP vendors have covered all simulators, this is still an issue for emulation. A designer will want to use the same model for simulation and emulation. And yet the encryption is unlikely to work on both. Two models, then, must be used: one for simulation and one for emulation. It becomes a matter of faith that the two models will be equivalent, aside from the encryption.
Thinking Outside The Boxes
Then there’s the question of debug visibility into the IP block. If a problem occurs during emulation, you need to know what happened. By definition, you’re not going to have visibility into all the details of the IP block. Such “white-box” implementations would be anathema to a provider because they could easily be used for reverse engineering.
What’s more typical is a “black-box” model, where only the very periphery of the model is visible. This is wholly inadequate. You typically need visibility into more of the internal registers than a black-box model will provide, usually called a “gray-box” model.
So what happens if you can’t get a gray-box model of your IP block that will work your emulator? The fallback is generally to use a gate-level model. These usually aren’t encrypted since it’s hard to figure out what’s going on inside them.
Even though you may get full white-box visibility, then, making sense of what you see can be a challenge. And in this situation, you may be more concerned about the equivalence between an encrypted RTL model used in simulation and a gate-level model used for emulation since non-trivial transformations likely occurred during synthesis.
Some IP vendors avoid encryption entirely by shipping PLI-based (programming language interface) models, which hide the details of the design. But even on a simulator, they hurt performance—particularly on an emulator—and they provide no detailed debug visibility. So, a PLI-based model can’t substitute for an appropriate gray-box RTL model.
The real solution lies in having encrypted RTL models for all simulation and emulation platforms. Making encrypted models interoperable on different tools might be an obvious way to accomplish this, but EDA vendors are unlikely to agree to that. Standardizing levels of visibility (white-, gray-, and black-box) would help on the debug front. But this still places the burden on the IP vendors to proliferate their model versions so there’s one for every platform.
Realistically, that may be hard for some IP companies to do. That’s why it’s critical that the IP vendors you choose have excellent partnerships with the makers of the tools you use. When you make a decision on an emulator purchase, for example, you want to select it based on overall performance and cost, not because some specific IP model is available for only that emulator.
With design cycles as short as they are, no one has time to monkey with IP models that don’t fit together well in all verification environments. Having all of the necessary models available with no fuss or bother is essential for success when assembling an enormous SoC in practically no time at all.