I sat  in during the User Track session on Chip-Package-System power delivery network design optimization.

Sorin Dobre from Qualcomm presented how they use a comprehensive time and frequency domain methodology to design and validate their wireless chip-package-board designs.  He highlighted the complexities associated with  time domain analysis in which he includes the chip layout, package RLCK model and a fitted model for the PCB in a multi-domain analysis framework. He uses a multi-cycle resonance frequency aware VectorLess methodology to define the excitation model for his time domain analysis of this system. The current signature for the final excitation model generates high energy around the system resonance frequency stressing the chip-package-system PDN.

Davide Pandini from ST Microelectronics, Agrate, presented results on power supply noise and EMI analysis and how it can be mitigated for the chips his group designs for the automotive market. He presented in the second part of his talk the results on a case study highlighting static and dynamic voltage drop and EMI results. He illustrated how power noise from the chip propagates along the chip/package/board supply lines and radiates to the air. He highlighted a methodology of controlling the dynamic switching on the chip to control the on-die noise/drop and hence the EMI coupling.

Erhan Erglin from AMD presented a methodology of dynamic voltage drop analysis for their high performance designs targeting CPU/GPU/APU applications. He presented arguments on the need for dynamic voltage drop analysis and why inductance, both on the package and on the chip have to be included for their designs using advanced processes. As supply voltages reach threshold voltage levels, dynamic voltage drop analysis highlights areas of switching noise that can cause the chip to fail. Static IR which has been used historically is useful to find gross violations and typically show small drop (3-4% range) for their designs. But to include the package/die inductance and capacitance and the simultaneous switching current, he highlighted the need for dynamic voltage drop analysis. He presented findings showing that the inclusion of on-die inductance changes not only the peak voltage drop number, but also changes the voltage drop map.

Ricky Yong from Intel, Penang, Malaysia, presented results on power noise analysis on their MTCMOS (power gate)  designs including silicon correlation results. He focused on dynamic power noise analysis for mode transition for his power gated designs. He highlighted how they perform on-die voltage drop measurements using sense lines and showed close match between measurement and simulation results. He also presented simulation results for different power-on sequences and correlation to measurements (within 4%).

Kyung-Tae Do from Samsung presented a methodology for estimating statistical leakage and the library/modeling support needed to achieve that. He highlighted that present techniques are not applicable for large macros and that a new technique is needed. His proposed methodology uses a combination of library characterization using Monte-Carlo simulations and silicon measurement based tuning.

Souvik Mukherjee from TI, Dallas, showed results on a different but equally critical area of IO sub-system design and the impact of power ground noise on IO/memory interface timing. He mentioned that an ideal SSO/SSN analysis methodology needs to accurately trade off between accuracy and efficiency of modeling, extraction and simulation flows. He presented results using the Sentinel-SSO technology from Apache on how the PDN noise and signal cross-talk impact can be included for IO/memory interface timing analysis. He presented results using this technique and compared that to silicon measurement results for a 45nm SoC based wireless platform.

Again thanks to the various DAC committees and to all the folks who made DAC 2010 a very useful and productive show.  Headed back home now

But what can of weaknesses are we talking about?
- The scan mode failure is one of the most unfortunate. As a known fact, with a static based analysis, the drop is purely proportional to the chip power consumption. Because of the slow frequencies of the scan chain(s), the average power gets smaller compared to the functional mode. But think dynamic!
In scan mode, you get most of your cells (FFs, Latches, clock buffers) switching at the same time – especially when there is only 1 single scan chain… This is the worst stressing switching scenario for your resistive PG grid and your inductive package.
Actually, since there is no way to get the PG grid designed to handle the test mode, we start to see more and more Apache users adjusting their test structures and strategies based on the corresponding dynamic analysis feedbacks.

- A second typical failure is when few set of standard cells, or even a single one, get isolated and weakly connected just because of the floorplan. The figure1 illustrates some cases.

figure1: Typical Floorplan

That’s what we use to call missing via, or impossibility to get vias as expected, at least in an automatic manner.

With a static approach, such a specific issue cannot be easily detected. A single standard cell does not consume enough average current to highlight such weakness in the static voltage drop map. But in dynamic mode, such weakness gets clearly identified.

Figure2: Supply Over TIme

Obviously, such weakness can be detected in dynamic if and only if the cell is switching during your simulation. So, even if, very luckily, you get a VCD file before your tapeout, you cannot guaranty this switching scenario will fire all those weakly connected standard cells… That’s exactly where the Apache’s Vectorless Approach will complete your analysis!
This very dedicated algorithm is automatically selecting the cells that will switch or not during your simulation. This selection is obviously dependant of the instances’ power, timing, logic, switching statistics, but it is also function of the topology of your design.  The tool identifies the weakly PG connected cells and makes them switch during your dynamic simulation. As a result, it gets very easy to viualize the consequences and quantify how bad could be the resulting dynamic voltage drop. Obviously, it is up to the designer to try different ‘what-if ‘ within RedHawk (add vias, straps or decap) in order to take the appropriate decisions,  but at least, he is aware of the weakness.

So, bottom line, if you want your chip first time right, don’t stay static and move for a dynamic solution!

Jerome

Before looking at how Algorithmic Synthesis accelerates low-power design, let’s take a look at the spectrum of alternatives to achieve low power. Analysis and optimization of a design’s power footprint can start as early as the system level specification or as late as the physical layout. While design changes to reduce power can occur at any stage of the design cycle, the amount of effort and the power reduction are inversely proportional to each other. The figure below helps illustrate this point.

Figure 1: Power Reduction Opportunities Across Stages of a Design Cycle

It can be seen from Figure 1, that the closer a design is to the gate level, the harder it is to make changes that will reduce power consumption. At the same time, the maximum possible reduction in power consumption decreases the closer a design is to the final gate level implementation. There are several reasons which explain this phenomenon. Primarily the inverse relationship between effort and power savings can be summarized by the following constraints at the RTL level

1. Once the RTL is functionally complete and in verification, touching the RTL for power savings is a complex and risky approach which can delay tape-out. Once a design is in verification, the most common type of RTL change has to do with functional correctness, not with design improvements.
2. Opportunities to change the power profile on an algorithm once RTL is complete are very limited. Maybe a logic equation can be further optimized here or there, but it is too late to do architectural changes with real impact on the power profile. For example, changing the memory representation of data can have a large impact on power. The problem is that this change usually involves an algorithm change, which will not be taken up at the RTL level.
3. Once the RTL is complete, it is typically too late in the design cycle to consider advanced design techniques such as clock gating. Without clock gating, a design can easily leave 50% more power on the table than is needed for functional correctness.

When looking at Figure 1 and the constraints at the RTL level, it is clear that the solution for low-power has to be applied earlier in the design cycle. The engineer has to move to a higher level of abstraction to gain some freedom in the design cycle to test out algorithmic variations for their impact on the power profile required for functionality. One way of increasing the level of abstraction, is to move the design capture from RTL to C by using Algorithmic Synthesis (AS) tools.

AS refers to a class of hardware design tools, which raise the level of abstraction for design capture from RTL to a programmatic language such as C. One of the key advantages of AS tools is that efficient hardware implementations are derived from untimed, sequential C algorithms. The allows the designer to focus on the algorithm, while at the same time be shielded from the error-prone steps involved in writing/verifying RTL. While all AS tools offer an increased level of design abstraction when compared to RTL, they do not all provide the same level of capabilites to enable power reduction and optimization of an algorithm. From the field of AS tools, PICO Extreme Power from Synfora is the first to automatically optimize power consumption at both the system and the architecture level by using a variety of techniques such as multi-level clock gate insertion. As shown by Figure 1, there are clear benefits to tackling power consumption at the system and architecture level instead of the transistor and layout levels.

Another conclusion which can be drawn from Figure 1 is that the higher abstraction level for design capture, the faster it is to test and verify different power saving strategies. With this in mind, the question is how can a technique such as multi-level clock gating be efficiently used on a design captured in an AS tool?

The answer to this question requires the explanation of a more basic concept. What is clock-gating and what are it’s benefits? The basic premise of clock gating is that portions of a computational datapath can be turned on and off depending on dynamic processing requirements by shutting off sections of the clock tree network. While the concept is simple, it’s implementation is actually quite complex. Effective use of clock gating requires

• Fine grain knowledge about the schedule of sections of a datapath/blocks relative to other elements in the design. One common mistake with clock-gating is to turn-off a block or datapath section without taking into account the downstream effects of that decision, which leads to dead-locks.
• Increased verification effort and complexity to cover all the cases when a block may be inactive and turned off. The verification team also has to take into account the cases where the block is turned on again. Both the shutdown and startup of a clock gated element must be tested to occur only in a safe state of the circuit operation.

While clock-gating has the potential of delivering significant power reduction in a given design, the complexity associated with the verification of this technique prohibits many tradiational hand-written RTL flows from utilizing it. An AS tool like PICO Extreme Power, solves the problems associated with designing clock-gated hardware through automation. In the case of the PICO solution, the tool is in complete control of the RTL being generated. This means that PICO has complete knowledge of block inactive/active states, and of cross block dependencies which affect the clock gating implementation. Without affecting how the user creates the design in the AS tool, automatic clock gating insertion happens at the following levels:

• Coarse-grain: Automatic startup and shutdown of large portions of a design from the top-level module. At this level, the AS tools has to guarantee both functional correctness and the correctness of the control logic associated with clock gating. The correctness of the clock-gating has to be verified both statically and through simulation to provide the user with confidence in the correctness of the solution.
• Fine-grain: Even if an entire block can not be turned-off, portions of that block can be. The AS tool should detect this possibility, creat the appropriate control logic and the verification infrastructure to prove correct operation. One way of enabling fine-grain clock gating is through the use of multi-level hierarchical design using a TCAB design methodology. TCABs will be discussed in more detail in a follow-up posting.

In addition to inserting the clock gating circuits at different levels of the design hierarchy, the AS tool needs to verify the correct sequencing of all clock and clock enable signals. Without a verification component as part of any automated clock gating solution, the power savings achieved by this technique will be overshadowed by the manual effort in verifying the correctness of the circuit. Like in a traditional hand design RTL flow, clock gating is a powerful technique, but it will not be used if the verification burden is high.

Unlocking the low-power design puzzle requires a combination of techniques, which can be readily applied at the C algorithmic level. In addition to the classical approaches in AS tools such as architectural exploration and algorithmic changes, clock gating is an important tool in minimizing power consumption.

We are fortunate to have three key customers present in our booth. Harpreet Anand from Broadcom’s Mobility Group will share his experiences on using RedHawk from early in his design process to sign-off for a 45nm design and how the step by step approach helped reduce the overall design risks. Ralf Schmitt from Rambus will share his experiences on bringing up and using Totem on high speed I/O interface designs. Louis Liu from TSMC will highlight the design challenges that are prompting a move towards a SiP/3D IC based designs.

Having worked with both Ralf and Harpreet on power noise and reliability for UltraSparc processors, I know that they bring considerable experience and expertise to the work they do and their presentations not only will provide a window into the flows and methodologies they use, but also give an opportunity to understand the challenges they see confront their specific focus areas. Louis’s presentation gives us an opportunity to participate in a discussion on the issues he sees both designers and foundries face in supporting advanced SiP/3D TSV based designs. The concerns and the challenges in this are seems to be part of the keynote to be delivered by Dr. Fu-Chieh Hsu (TSMC).

Additionally there are presentations in the DAC User Track sessions covering several application areas of Apache products. Bando-san from Kobe University will share his experiences on using Totem for substrate noise analysis and silicon correlation for the same. Davide Pandini from ST Microelectronics will share his experiences of using Sentinel Chip Power/Emission Model technology for near field and far field emission study for his designs.

This year at Apache we are focusing on four key areas:

• The capacity and usability features in RedHawk-NX, which is the Next Generation RedHawk engine incorporating the Mesh Pattern Recognition (MPR) and Hierarchical Dynamic (CMM) technologies. Additionally this version of RedHawk rolls out RedHawk Explorer (RHE), which for the first time provides automated design weakness and root cause identification capabilities for power noise simulations.

• The power noise and reliability analysis capabilities in Totem covering power grid design analysis, signal electromigration and substrate noise analysis. Totem comes with a highly interactive layout editor like GUI that overlays the analysis results on the layout and highlights design weaknesses automatically allowing users to fix their designs interactively before committing to the final layout.

• The full package and board extraction support in Sentinel-PI with true 3D full-wave accuracy, its ability to read one or more die models (CPM ~ chip power models) and its flexibility to perform frequency domain, time domain and DC analyses in one integrated simulation platform.

• Co-design strategies looking at power delivery, signal noise, EMI and thermal challenges associated with integrating one or more dies in complex package structures (SiP, 3D/TSV, etc). One key area is to assess the impact of IO power noise on signal transmission and jitter. The Sentinel-SSO solution provides the ability to simulate an entire IO bank (e.g. DDR3) incorporating both power noise and signal cross-talk impact to signal propagation.

Hope you can make it to DAC. Drop by and say hi if you are around.

  As a matter of fact, when a chip is ‘ON’, it is meant to do something, whatever the final application. Therefore, millions of standard cells (or millions of transistors) are driving signals in a very specific way. To drive those output signals, each cell needs energy: they consume current.
When the signal is static, the cell is consuming a leakage current, which is a state dependant constant value. But when the signal is switching, the cell will consume a certain amount of current over the time. This amount of current depends on 4 main factors: the slew (transition), the charge (load), the switching direction (from ‘0’ to ‘1’ or from ‘1’ to ‘0’) of the net and the supply voltage of the cell itself. The bigger is the net and the more aggressive is the timing, the higher will be the corresponding peak of current.
  The figures below represent the current consumption profile of a cell during a switching output event. 

This current profile is obviously also dependent of the cell structure (complexity, size). In other words, each cell, such as each transistor, does have its own characteristics depending of the output signal.

Note:  It is important to notice that the frequency of the net does not directly change the value of the peak of current but rather the frequency of this peak. In other words, the frequency is impacting the “average” current consumption (better known as “average power”).

It is mandatory for a tool such as RedHawk to perfectly understand and use these current profiles in a way that mimics their physical operation (e.g. the current draw should depend on the supply voltage to that transistor) to compute an accurate Dynamic Voltage Drop.  Since the chip is not only made of standard cells but includes also memories, analog and full custom IPs, it implies a wide range a different current profiles for each element. So far we store all those profiles in APL (Apache Power Library) format. This is a spice based characterization; we may develop a bit more this subject later in this blog.

So, a cell needs current to drive a net – fine – but we may wonder why we hear more and more about switching noise with the last new technologies. As matter of fact, since we are shrinking a lot the geometries, the output loads and the cells get reduced, and therefore the corresponding switching peak of current. On the other hands, still due to this shrinking, we end up with much more transistors and cells per mm². In other words, the issue is not coming from individual current cell consumptions but from thousands of cells that are potentially switching at the same time in a very small area of your die. The density increases faster than the peak of current reduction. The real source of noise is clearly a simultaneous switching matter.

Even if today some technics such as gated clocks or skew and phase control tend to limit the simultaneous switching events, the transistor density gets so high, that we have to control the switching current and hence the switching noise very carefully. Additionnally, the tight design requirements on the chip, its package and its board make it more difficult to supply these high switching current requirements quickly enough. Thus, we see increasing needs for co-design solutions like Sentinel and RedHawk for designers working on advanced technology designs.

The many beautiful places our users live and work.

The most common question I get prior to visiting Israel is if it’s safe. I have never felt otherwise. I have walked in the ancient streets in Jaffa or gone running along the Promenade in Haifa late at night and never felt insecure or concerned. On the other hand, the visits are extremely fruitful not only in understanding how our many products are used but also from the insightful feedbacks I get from all the design teams we engage in. Our users in Israel, either from their work on some of the most advanced and complex designs or from their focus on having the most price competitive product, have adopted our power noise analysis solutions in comprehensive manner using them not only in the flow we recommend but also by adapting it to their specific needs by working closely with our local and world-wide application engineering and RnD teams.

While RedHawk™ use for the SoC or digital circuit analysis has been wide-spread since we started working with our customers there, the visit offered tantalizing insights into how our customers have obtained considerable value from using our Totem™ solution on their taped-out or ongoing designs. They have used it to validate the IPs they obtain from internal or external design teams to highlight issues that the traditional netlist based flows that the IP design teams use have missed. They have also been able to simulate entire designs or blocks that they had to earlier partition and simulate either in pieces or partially. They have also benefitted from Totem’s integrated simulation driven signal line electromigration analysis for their advanced sub-65nm designs.

Quite a few of our customers there have had co-design methodologies, but our CPM™ (Chip Power Modeling) and Sentinel-PI technologies have given them an accurate, usable and robust framework to perform their chip-package-board co-simulations and design changes. The use of CPM in a model based design environment (one in which models of the package, board and die are cascaded and simulated in a Spice simulator) tend to have complexities especially if the package model is in the S-parameter format or Broadband Spice models which do not reflect the physical nature of the CPM netlist. Discussions of model based simulation flows with our users in Israel tend to revolve around the parameters used to generate the CPM in a manner that makes it most suitable for a hook-up to such package models and the feedbacks from our customer in Israel have helped clarify some of those questions. Other discussions revolve around the various simulation scenarios that can be used to create a CPM to make the combined chip-package-board transient analysis representative of various operating modes of the system.

Interest in Sentinel-PI continues to build up given the benefits it provides. Sentinel-PI first imports the die model (CPM) along with the package and board layouts. It performs circuit level connection (die bump to package bump, package ball to board solder) and performs an integrated analysis (DC, AC, transient or EMI) within a single environment. Thus, users not only benefit from Sentinel-PI’s true 3D full-wave modeling accuracy but also from its proper handling of die to package to board connections resolving inaccuracies or ambiguities that arise in a cascaded model based approach. Due to their work on high speed, sensitive circuits or from a need to control the design margins and the costs across these disparate domains, our customers appreciate Sentinel-PI’s value proposition. Many of our users benchmark Sentinel-PI against HFSS taking small representative circuits while others have qualified it against measurements. Those results have increased their confidence in using Sentinel-PI to extract their entire package and board layouts with 3D full-wave accuracy (which they are unable to do in other available 3D full-wave extraction tools) and to leverage its unified simulation environment. Hence I look forward to my next visits there to get feedback on their experience on using Sentinel-PI.

On a separate note, I am very thankful to one of our users in Haifa, who introduced us to Pichoto, a fabulous find in Zikhron Ya’akov. I will recommend it to any of the readers who happen to visit Haifa and are looking for a place to have dinner of local favorites paired with fabulous local wines.

Till next time, cheers or as my colleagues in Israel would say, L’Chaim.

We have been working on the power-aware related projects for a while and there are some interesting experiences and thoughts that we would like to share in several blog posts. Hope you will enjoy it and please feel free to give us feedback.

As we all know, low-power has become a more, if not the most, important design constraint over the past few years. Mobile devices such as iPhones/iPods are getting so popular that people want to use them all the time. Although the battery techniques have improved dramatically, effective power management, either in software or hardware, is still the key to keeping the power consumption under control. There are several techniques in hardware power management such as power-shutoff (PSO) and dynamic voltage scaling (DVS). Both techniques have shown to be very effective to reduce both dynamic and leakage power.

Power management is usually planned in the RTL or even an earlier architecture stage. To design power management in the RTL stage, new languages called Power-Definition-Markup-Language PDML (such as CPF and UPF), are used to compensate the lack of power modeling capability in traditional HDL. Similar to HDL, CPF/UPF describes hardware functionality but only focuses on the power related parts. Designers can use CPF/UPF to specify the power-domain, power-shutoff condition, level-shifter, isolation and retention strategy. The HDL simulator then takes both HDL and CPF/UPF as inputs and imposes the power introduced behavior during the simulation run. For example, if a component is power-shutoff at particular time during simulation, the HDL simulator will cancel all corresponding events and assign its value to unknown. By co-simulating both HDL and PDML, designers can verify the design behavior with power-intent.

Since CPF or UPF are usually designed and written manually by a designer, it will be error prone just like any software. Moreover, since CPF and UPF interact with the HDL design, debugging them together can be very tricky. We called this type of debugging process as power-aware debugging.

Before getting into what power-aware debugging is and why it is so important, we would like to share some of our observations between the two mainstream power-definition-markup-languages – UPF and CPF. Although we haven’t been involve in the UPF or CPF development since the very beginning, we have followed their progress very closely. Both languages have been evolving over several versions in the past two years. UPF is in the process of becoming an IEEE standard (P1801) and CPF is still keeping itself as an open language.

Although both languages try to achieve the same thing – description of power intention – both languages actually have very different design philosophies in mind. UPF is more like a “structure” language which is used to describe the physical “power network”. You need to define the power-source, the corresponding supply voltage, the power supply-net, and the power-switch. The power-intent is then described as the power-network. If you want to design a dynamic voltage scaling (DVS) system, you need to define a set of power-supplies with different supply voltages. Then you have to connect the supply source to power-switch via power supply-net and defines the control condition of the power-switch to make it provides the corresponding voltage under certain control configurations. This process is very similar to constructing a Netlist with HDL language.

CPF, on the other hand, is more like a “behavior” description language. The on/off condition and the voltage status can be described as simple behaviors. For example, to implement DVS, you have to define the power-state-table and the corresponding state transitions. Each power-state represents which region (power-domains) is supplied by what voltage value.

I will use this space to share my experiences working here at Apache in bringing technologies that help our customers make their designs more likely to succeed the first time around and at the lowest unit cost looking at chip design holistically considering the package it goes in and the board it sits on. I will also look from the package and board designers point of view about how the die needs to be designed and factored in to make cheaper, more efficient package and board layouts.

Looking forward to hearing from others also.