Debugging is still the most time consuming part of IC design. Typical debug includes: (a) find out the checkers that indicate errors, (b) investigate waveforms of observation points (typically primary outputs) which may propagate errors to the checkers, (c) trace drivers of those observation points, (d) indicate error sources, (e) fix them, and finally (f) re-run simulation to make sure the bugs disappear. The whole process is very, very labor intensive. Are there any automation tools that can help?

This paper presents the techniques for automatic debugging. Given design source code (RTL) and simulation error traces, the tool automatically tells designers “OK, the error sources come from those lines; please take care of them”. In other words, automatic debugging let designers skip steps (a)(b)(c)(d) and focus on steps (e)(f).

The basic underlying techniques of an automatic debugging tool are very similar to those of formal verification tools: BDDs, SAT, QBF, etc… Thus, the notorious challenges that accompany those techniques are the same – scaling – larger design with longer error traces. To conquer the problem, the authors introduce an important observation: “error sources are often excited temporally close to failure points”. They even make some experiments by simplifying the error behavior model and calculating the probability of error sources to prove the observation. No matter how realistic the experiment reveals, this part is the most interesting section that is worth reading again.

Based on the “error source temporal proximity to failure point” observation, the authors propose the approach “bounded model debugging” which is very similar to the concept of BMC (bounded model checking) used in formal property verification. The experiments show that 2.7 times more problems can be solved.

One of the most challenging jobs of promoting any metric is actually not from the technical side. Instead, it is more likely from the political/business side. Big companies usually refuse to adopt proprietary methods, formats, or metrics to make sure they won’t be tethered to one single vendor. However, providing innovative solutions usually means having to use supplicated tools which only one or a few vendors can provide. This in turn usually means that the single vendor (or small group of vendors) will do their best to avoid competition. Therefore, a proprietary language or method will show up.

In the end, the proposed metric makes a lot of sense. The “proprietary” factor could make it difficult to go through the deployment process. This situation is worse between IP vendors compared to internal IP providers. Each IP vendor is an individual company. Trying to ask them to adopt some proprietary metric/tool together could be really tough.

The solution? Some people suggest that metric providers (aka startups) should create a fake company to work on the similar thing. In this way, the big companies won’t worry about being tied to one vendor Joking aside… No, we don’t know the answer yet but that’s the fun part of the game…

Having a robust IP signoff process is really critical and adopting reliable signoff metrics to help make signoff decisions is key. Most IP vendors provide various kinds of converge as the proof for good verification quality. However, in reality, those metrics are only telling half of the story. Most of the coverage metrics, such as functional coverage and code coverage are measuring the test distribution. Those metrics are adopted to try to make sure the test stimuli covers most of the critical functions and import corners. It assumes that whatever abnormal design behavior will be detected by the testbench. To check if the there is any exception during simulation, “checkers” inside testbench play the role of identifying the correctness. A checker can be a simple “diff” in scripts, a waveform compare utility along with the golden model, or some complicated structures.

Using coverage to qualify the verification quality is not enough. An extreme example is: a design that has 100% coverage but all checkers are disconnected by accident. Although the verification engineers still get 100% coverage, the testbench actually checks nothing. Taking the checker quality into account is definitely a must for any verification methodology, especially critical for IP signoff. Since checkers can be implemented in various forms, it is not easy to directly measure their quality. An alternative method is called mutation-testing. This is done by injecting artificial faults into a design and running the regression tests. If any introduced erroneous behavior cannot be detected by primary outputs, it implies that there might be a missing checker to check this exception behavior. The mutation-test tricks have been adopted in the software world for more than 20 years, but recently re-gained a lot of attention their application on chip design and verification. Using mutation-testing is a practical way to quantify the quality of checkers inside the testbench. It should be served as a complementary metric as any other coverage metric.

In the next blog, we will talk more about mutation-test solution and its practical usages and applications in verification. J

There are many aspects of chip-package-system co-analysis such as signal integrity, power integrity and electromagnetic interference. For now, let’s look at the system power integrity aspect of co-analysis. The noise on the power supply is becoming a major source of noise that can cause a rail collapse, and directly impact the noise margins and the timing. The power delivery network spans multiple domains, from the VRM and through the board and package to the IO regions of the dies and all the way to the transistors on the die. At present, due to the absence of a single analysis platform that can read in the chip layouts and the package/board layouts to perform power noise simulations in one unified run, a model based approach is in-vogue. In this method, there are key ingredients: (a) comprehensive model of the chip(s), (b) accurate model of the package and board, and (c) a co-simulation platform that can take these models appropriately to perform the required simulations (frequency domain, DC, or transient). The rest of this blog discusses the die model requirements (part a) and its application in a system level analysis.

The requirements for a die model must be understood to perform an accurate system level analysis. The die must be represented with the electrical and physical properties of the chip (wires, RDL, cell/IP/macro characteristics and placement etc) and must be a compact model that contains:

(1) Current consumption profiles over different parts of the chip in a spatial and temporal sense, for every domain and at every pin.  This current signature can reflect different operating modes of the chip and can be triggered through test patterns in the form of VCDs or by using a statistical vector generation engine such as Redhawk.

(2) Parasitics present on the chip to provide an effective Rdie and Cdie which is domain specific and reflects the layout and the technology of the chip.

Such a model can be used for chip-package-system (CPS) analysis and optimization during different stages of the design cycle. In the early stages of the chip when only the power grid prototype is available, the die model can contain only the parasitic components because the chip switching activity cannot be determined. Such a model is sufficient to perform a CPS frequency domain analysis to optimize the impedance and resonance frequency points. As the chip design progresses, the die model must incorporate incremental transient current information (for DC and transient analysis ) and become an accurate representation of the die that will ultimately correlate with measurement.

There are several aspects of the power delivery network design that must be optimized and verified, such as PCB stackup, VRM placement, de-coupling capacitance selection and placement, package layer, socket and connector selection, pin assignments and placement. The basic goal is to minimize the levels of noise and the impedance over a wide frequency range while limiting the cost, size, pin count, and number of layers. To accomplish this goal, a CPS co-analysis of the following types must be performed: (1) frequency domain (2) DC and (3) transient.

In the frequency domain, the die model is used in the combined package and board analysis to study the various resonance points and compute the impedance. The resonance frequency is estimated to ensure that it does not overlap with the functional frequency of the chip and its associated harmonics. The lower frequency range resonance points are determined mostly by the PCB and package elements. However, the resonance frequency at the higher frequency range (50+ MHz) is determined by the package/PCB inductance and the die capacitance.  The chip parasitic model as mentioned earlier needs to reflect all the various capacitances present in the chip (wires, gate, diffusion, well). It also needs to model the resistance (and inductance) of the power and ground routings and the channel resistances of the devices. Additionally, an accurate parasitic model of the die can determine whether the impedance is less than the target impedance.

For DC analysis, the current drawn at various parts of the die reflect either an average or a peak current situation. The system DC analysis will reflect the average drop at the die bump locations. For time-domain analysis the complexity of this modeling is higher due to several additional requirements: a) the model must provide current profile information for sufficiently long period of time to allow for meaningful CPS time-domain analysis capturing the LC resonance effects, b) the model must reflect various operating modes of the chips providing di/dt signatures in the transitions between such modes, and c) it must be spatially distributed over the chip to capture the placement of various circuits and their operations. Various studies have been done regarding “worst casing” the current signatures.

Historically design teams have explored ways to generate such die models. But these models have typically been unable to provide the accuracy or the modeling sophistication outlined earlier.  The Chip Power Model (CPM) technology from Apache pioneered the concept of a layout driven die modeling solution that met these needs. Essentially a CPM is generated subsequent to a die level RedHawk (for digital) or Totem (for custom/analog) power noise simulations. The information (layout, library, technology parameters) provided to either RedHawk or Totem is necessary and sufficient to generate a CPM with its accuracy commensurate with the detailed nature of the data provided. The generated chip power model is an electrical representation of the layout of the chip and its operating mode in an open Spice format that can then be connected to a package model.

Today, we cannot afford to work independent of each other. Design collaboration will lead to more innovation, improved quality and lower cost. Getting a good die model in the form of CPM is a first step towards a converged chip-package-system design methodology. Stay tuned for the next posts on package/board extraction and co-simulation technologies.

]]> http://www.techguri.com/2009/07/07/chip-power-model-for-co-design/feed/ http://www.techguri.com/2009/06/23/verification-challenges-soc/ http://www.techguri.com/2009/06/23/verification-challenges-soc/#comments Tue, 23 Jun 2009 17:43:12 +0000 Kai Yang http://www.techguri.com/?p=391 One of the major headaches when building a SoC is the quality of the adopted IP. A general SoC usually contains many IP cores which are either provided by the internal design team or purchased from 3^rd party providers. An IP block usually comes with a complete function and performance spec for SoC integrators. However, SoC integrators usually don’t provide much of an idea of how well the given IP has been verified. Primitive metrics such as code-coverage might be provided but it is definitely not sufficient. The consequence of adopting a not-well-verified IP in a SoC could be a nightmare, especially when it happens in the late integration stage. A problematic IP could be extremely hard to debug in the SoC level.

One thing we have observed in the industry is that people are looking for better signoff metrics which can provide more meaningful verification information. Traditional code-coverage provides a very straightforward number but it hardly provides much insight about the verification quality. Functional coverage, on the other hand, gives the integrator a much better idea of the stimulus statistics but doesn’t answer the question of how healthy the verification environment is. To compensate the missing part of the existing coverages, an orthogonal metric is necessary to take the verification environment into account.

In the next blog, we will introduce what that metric might look like and how the industry is adopting it. Stay tuned.

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.