Low Power Blogs

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!!"

So 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.

But if 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?

=Adam Sherer