You've been building chips for
years and the growing complexity means you just can't tolerate simple tool-to-tool flows and group-to-group barriers any more. SystemC and RTL in the same low-power simulation? Got it.
Mixed-signal? Yep. Every team with fingers in the power intent? For sure. Siicon
Realization is real to you because you're living it, but you need more
from EDA so you're demanding "Cadence Low-power Verification: Tear Down These Walls!!"
why is the product manager for the Incisive Enterprise Simulator, a
seemingly siloed product, blogging about this? Because it's my life
too. If you've invited me to your site in the past year, you know my
roadmap presentation has 150+ slides. It's not becuase I'm running each
team through every button and switch in our simulator. It's because the
simulator itself has blown through the barriers. Sure, we cover
traditional topics like SystemVerilog, coverage, and assertions. But we
also talk about low-power, mixed-signal, and project-level
performance. We have to because you live this integration.
the walls are already down and silicon is being realized, what's the
news? Let's take low-power verification as an example. Sure, we have a
file to capture power intent and tools that work on that intent. At
that level, so do our competitors. The real magic is fusion of the
power intent, the verification plan, and mixed-abstraction simulation.
Take a look at the first of the two figures here and you can see
the real silicon problem. From a very simple set of power domains, the
complexity in verification can explode. In this instance, the designer plans four power domains -- three simple power shut-off and one with 3 levels of voltage scaling. Pretty simple, except that we need at least 9 tests for those domains (3 x on/off + 1 x three levels). We can, and do, certainly build those nine tests, but we need to verify 25 power modes, only 19 of which are actually legal. That could imply dynamic assertions or formal analysis to assure that the design does not enter the illegal states.
At 25 modes we are talking about some reasonable complexity with the possibility of long transaction sequences to drive the design into the proper mode. That complexity then explodes when we think about all of the corner cases and functional tests we need to run in each of those modes. There is no way that a simple tool flow will handle this complexity.
Figure 1: Simple design intent can rapidly escalate into a huge verification challenge
What we need is a methodology that will assure consistent intent, leverage abstraction, and converge technology and people. That is what Silicon Realization brings, as depicted in Figure 2. In this example, we certainly see the tool support in the lower right. Without any doubt, Silicon Realization requires that the core technologies exist and be the best they can be. However, you can see the tenets of Silicon Realization even in that box with Conformal and Incisive sharing the same power intent. These tenets are present in the dynamic power analysis and UVM layers as well culminating with the project level view of low-power verification captured in the verification plan, which ultimately reconnects the simple design intent and complex verification described in Figure 1. This
approach doesn't just tear down the walls, it reshapes the landscape for
more productive and more profitable silicon realization.
Figure 2: Silicon Realization in the low-power methodology
Now as a
user, you know that this is a fractal problem. We can zoom in tight to
see intent, abstraction, and convergence in a detailed, technical
aspect of the product development process or zoom out to the project
level. Where simulation is employed, we can pan to the architectural
development phase or to the implementation hand-off. Over the next few
weeks I'll blog on other areas where the tenets of Silicon Realization are
being employed. What areas would you like me to detail?