Documente Academic
Documente Profesional
Documente Cultură
Presented at
Verification of 1M+ transistors Mixed-Signal ICs for Cellular and Multimedia Player Applications
Rgis Santonja, Freescale Semiconductors
1. Introduction
As the complexity and modularity of modern mixed-signal Integrated Circuits (IC) increase, together with the costs of masks and wafers, one needs to find new ways to simulate the ICs behavior, signal integrity and power consumption before tape-out. This paper will demonstrate how, at Freescale, we take up this challenge by presenting the real case verification of a family of power-management ICs containing up to 1 million transistors, and more, with a wide variety of circuit topologies (linear analog circuits, switched mode supplies and audio system, high precision data converters, etc). Most of the aspects involved will be presented, beginning with testbench architecture, then to regression tests, up through database management, test coverage, signal integrity, power consumption, etc Historically, our initial goal was limited to functional verification. This paper presents our mixed-level simulation approach, based on some real case examples. However, some IC respins were caused by signal integrity problems, accidental leakages, or over consumptions. Indeed, the static current consumption requirements are getting more and more challenging, and the risk of leakages are increasing with the use of several voltage supplies that can be switched on or off independently. This paper presents how we manage to correlate simulated current consumption at IC level with silicon measures, and how we track potential floating nodes.
2. The IC specification
Our methodology has been used for several ICs of the same family. The diagram below roughly presents the features embedded on a single die. As we can see, lots of analog functions are implemented, but the digital is also important. Verification requires a very deep knowledge of the circuits specification. Indeed, older generations of Power-Management ICs had their functions quite independent one from the other. Whereas todays ICs have much more complex system interactions. For example, the buck switchers that are used by the external processor can also be used to supply the internal audio system; the boost switcher can be used by the internal LED drivers; the negative charge pump can be a shared resource between the blue LED driver and the true-ground audio biasing, etc Chapter 8 will present the Verification Matrix that were using to track that all specification has been covered by simulation.
3.1.
Block-level testbenches
In the example here, the audio of the IC was first simulated at block-level. The vector file has been written in such a way that one could use it to re-simulate the audio at chip-level. We call vertical re-use the ability to use the same resources at block-level and chiplevel. The audio circuit did not have a SPI/I2C interface at this level. However, the vector file was written with the chip-level SPI/I2C transactor syntax in such a way that it could be re-used as is during chip-level simulation phase.
Optional assertions
3.2.
The chip-level testbench is built at the beginning of the project, as soon as the pad list of the chip is defined, and is used throughout the whole project development. This is the Verification Leaders role to provide such a testbench. It will then be used by the whole design and verification team to exercise all blocks individually, at different levels. At the top testbench level, each IC pin has its counterpart in the Stimulus/Checker block and both are connected together (cf. Figure 3) in a Cadence schematic view.
Audio (SSI) transactor BCL/FS/RX/TX Optional secondary Audio transactor USB (ULPI) transactor
Figure 3 Chip-level Testbench block diagram with AMS Stimulus/Checker for mixed-level simulations
The Verilog-AMS Stimulus/Checker gives the ability to exercise the IC through its interfaces, such as SPI, I2C, I2S, general purpose Inputs/Outputs (IOs), but also through all its analog pins.
These resources are available to be referenced from the vector file. The test-specific vector file is pulled into the top stimulus via a Verilog include. The file to be included is selected by a `define directive given during compilation. In the vector file, one can have additional variable declarations, SPI transactor calls to read/write SPI bits in either SPI or I2C mode, controls on pins, checks of pins or internal nets, and any other various code needed to stimulate and check the response of the part. An example vector file is shown in Listing 1. The first thing done here is to bring up the various supply voltages (LICELL, BP, and SPIVCC). Once a rising edge on RESETB is detected, some read accesses via the SPI interface are done. Also, the state of the chips interrupt pin is checked. At the end, an END_SIM call prints a pass or fail report based on whether any errors were found throughout the test (Cf. Listing 3).
/********************* DIGITAL EXECUTABLE initial begin // Initial Condition: BP_level = 0; LICELL_level = 0; SPIVCC_level = 0; #(10*`nano_in_usec); LICELL_level = 2.5; #(500*`nano_in_usec); BP_level = 3.6; SPIVCC_level = 2.775; COMMENT("********** WAIT FOR RESETB HIGH **********"); @(cross(V(RESETB)-SPIVCC_level/2, +1, 1n, 10u)); wdi = 1; COMMENT("********** CHECK INT PIN IS HIGH **********"); check_digital_net_id(" INT pin high check", `IC.INT, 1'b1); COMMENT("********** READING FIN, ICID AND REV BITS **********"); spi_icid_fld = 3'b111; spi_rev_fld = 5'b01_000; // 1.0 spi_read_fields1(SPI_ID_REG_ADR, 24'hff_ff_ff); COMMENT("*****READING ICID DUPLICATE **********"); spi_icid_adc3_fld = spi_icid_fld; spi_read_fields1(fnGetAddr("spi_icid_adc3_fld"), spi_icid_adc3_mask); COMMENT("********** ALL TESTS COMPLETED **********"); END_SIM; end /********************* ANALOG EXECUTABLE **************************/ analog begin // Generic analog section `include "generic_analog.v" Listing 1 Example of vector file (extract) **************************/
The vector file is made of 2 parts. The digital side drives the tests sequence. The analog side is driven by the digital controls. It consists in a vector-specific section, and a generic section imported via a file called generic_analog.v. This file contains all the external components, such as external capacitors, crystal, microphone models, etc It also contains all the supply sources for the main battery, the charger, the Lithium cell, etc All these components are gathered in a single file in order not to duplicate their declaration in every vector. They are usually declared in Verilog-AMS syntax, but can also be a spice netlist. Finally, some `ifdef compiler directives can be used to select the IC-specific file to be included. Indeed, the same vectors are often used for several ICs of the same family that usually do not have the exact same external component list. Listing 2 presents an extract of such a file.
//******************************************************************* // Main Supplies V(BP_stim) <+ transition(BP_level, 0, BP_rise, BP_fall); I(BP, BP_stim) <+ V(BP, BP_stim)/RBP; //******************************************************************* // External Capacitors I(REGULATOR1) <+ 1e-6 * ddt(V(REGULATOR1)); I(REGULATOR2) <+ 1e-6 * ddt(V(REGULATOR2)); I(BANDGAP) <+ 100e-9 * ddt(V(BANDGAP)); //******************************************************************* // GROUNDS V( GND1) <+ 0.0; V( GND2) <+ 0.0; Listing 2 Generic analog file containing the external components
One can see in this example how BP_level, BP_rise and BP_fall play the role of digital controls for the corresponding external voltage source. The resulting log file for this specific simple example is presented in Listing 3.
% % % % % % % % % % % % % % % % % INFO @ 0 ns: *************************************************** INFO @ 0 ns: RUNNING SIMULATION common_topctrl_revid.vams INFO @ 0 ns: *************************************************** INFO @ 510000 ns: ********** WAIT FOR RESETB HIGH ********** INFO @ 41229624 ns: ********** CHECK INT PIN IS HIGH ********** PASS # 2 @ 41229624 ns: INT pin high check: correct digital value INFO @ 41229624 ns: ****** READING FIN, ICID AND REV BITS ******** PASS # 3 @ 41230878 ns: PASS: SPI Reg. 7 Read Check PASS. INFO @ 41230878 ns: ****** READING ICID DUPLICATE****** PASS # 4 @ 41232132 ns: PASS: SPI Reg. 46 Read Check PASS. INFO @ 51232132 ns: ********** ALL TESTS COMPLETED ********** ----------------------------------------Simulation common_topctrl_revid.vams Completed Successfully END_SIM called @ Time = 51232632 4 Checks done 4 Checks successful Listing 3: Log file example
3.2.2. Assertions
It is common to consider that assertions are a concept limited to digital verification languages, such as PSL/Sugar, Vera, or SystemVerilog. However, if we define assertions as piece of codes that are continuously monitoring one or several signals together, whatever the specific test being applied to the DUT, then Verilog/Verilog-AMS can be used to create assertions. They would typically be coded with either combinational (continuous) logic, or with @always processes. These tests are implemented in the generic section of the testbench. They are permanently running and monitoring the involved signals, independently of the vector file being used. In our case, the behavior of the clock provided by the IC to the external processor depends on the internal power system state of the IC. An assertion is permanently controlling that the clock is correctly provided. Additionally a compiler directive is available to automatically add rise and fall time monitors in case the clock is considered analog. Assertions can be implemented in the testbench as illustrated in Figure 3. They can also be implemented in the design itself, or in the models of the blocks. For example each of our models continuously checks that its supplies and grounds are within an accepted voltage range.
3.3.
Verification IP re-use
We talked about vertical re-use above. Indeed, as on the design side, reusing previous developments in verification has become mandatory. A design IP can be a standard interface implementation. The corresponding Verification IP (VIP) would be the set of resources necessary to verify this interface. It can include block-level or chip-level testbenches, together with their appropriate transactors, monitors, and even the vectors created to stimulate and observe the complete behavior of the design (Cf. Figure 2 and Figure 3). The testbench itself, and the Verification plan (cf. chapter on the Verification Matrix), can be re-used or can at least serve as a good starting point for a new project. In our case, we have developed a set of Verification IPs which consists in a list of configurable mixed-signal Verilog-AMS modules, tasks and functions which can be called from the Stimulus/Checker module. They allow printing comments, counting error/warning/pass information, or report the final status of the simulation. They also control the various transactors (SPI/I2C, USB/ULPI, I2S) and a set of standard digital controls for the power supplies and other analog pins. Additionally they provide digital and analog monitors (voltage or current levels, sine wave amplitude, frequency, gain, etc). During the whole project development, the same bench can be used to verify each and every sub-circuit as it gets changed: either after a specification change or because an issue was found. 8
On the model side, we also have generic and configurable models for LDOs, amplifiers, etc In addition, we have also developed generic vector files for the most common mixedsignal functions of our product line, i.e for linear regulators, buck switchers, audio amplifiers and codecs. These benches can easily be plugged in every project-specific chip-level testbench and are ready to be used immediately on any new project. These generic vector files are connected to the specific DUT thanks to a set of `define that give the correspondence between the generic names (instances, enables, outputs, etc) and the actual ones. Some of the involved signals can be addressed through the hierarchy of the IC whose complete path is defined in a specific file that gets plugged in the generic testbench. Finally, a set of simulator options is available and can be reused to ease convergence or to speed up some especially long simulations. All these Verification IPs make the setup of the verification environment fast and easy.
4. Tagging Methodology
Todays IC are developed by multi-site teams spread all over the world, counting tens of designers, each of them re-using circuits from previous generations and also developing new ones. It became absolutely necessary to have a very rigorous methodology to handle the design and verification database. During the development phase, each designer can release his work to integration, layout or verification teams by checking it in a central database. At any time, he or another designer can check it back out, modify it, and check it back in with a short comment about the change. This increases the version of the corresponding circuit and builds the version history of the block.
X_top.01
X_top.01 C V2.8
X_top.01
If a check-in can be considered being an official release for a flat block, one needs to find a way to reliably release a hierarchical block. Indeed, it is unlikely that all sub-blocks will have the same revision number. Placing a tag on the whole hierarchy of the block will allow other teams to work with the good combination of sub-block versions. It will also ensure that at any time in the future we are able to retrieve the exact state of todays design. Note that it is useful to also tag the complete development and verification environment (testbenches, but also libraries, simulator version, etc). Such release tags must not be moved: once it is associated to a given version of a block, it needs to get locked to it. In our case, the revision control tool is configured so that all tags starting with X_ prefix can not be moved. Each block instantiated at the top-level must be tagged by its owner before it gets plugged in the IC. The designer takes the responsibility that his block is consistent across all its hierarchy and is functional. If any change needs to be done on a block or one of its sub-blocks, it must be checked-in and a new tag must be placed with an increased number.
10
X_VE.12
Verification Environment
X_topcell.06
X_topblock_Y.05 C V2.8
C V2.8
C V2.8 X_topblock_Z.08
Figure 5 All tags in place for chip-level integration and complete Verification Environment release
One of the challenges of the design leader of a complex mixed-signal IC is to precisely identify which version of each individual block is to be assembled into the chip-level design. Thanks to the tagging methodology, this integration task is much easier, as he is guaranteed that all the blocks that get integrated, and all their sub-blocks, are self consistent, netlistable and simulatable. He just needs to ensure that his top-cell passes Cadence schematic Electric Rule Checker (check & save) and tag it before releasing the whole circuit database to the Verification Leader. The latter will also tag the entire Verification Environment. The overall list of tags is gathered in a Freescale specific file format (CCF) and a mail is sent to the whole verification team to inform them that a new release is available. Each verification engineer can then open this (versioned) file with a proprietary tool that will create a clean
11
workarea for them. The Verification engineer creates a new workarea at each new IC and VE release. He can actually create many of them with any variation of its content.
Topblock_X X_topblock_X.03 Topblock_Y X_topblock_Y.05 Topblock_Z Top-Cell X_topblock_Z.08 X_topcell.06 Verification Engineer #1 work area
CCF file
12
Analog block Small linear analog blocks Big non-linear analog blocks (audio converters, switchers, etc)
This chapter will present how mixed-level simulations (using transistors and models together) can accelerate the simulations enough to get a good functional coverage, still ensuring a satisfactory accuracy. The goal is to keep each simulation time below 2 hours. The next chapter will present how Ultra-AMS or Ultrasim can handle big non-linear functions, keeping the simulation time around a night, or maximum a few days.
5.1.
Mixed-level Simulations
Mixed-level simulations give the opportunity to simulate the chip early in the process, allowing the capture of system-level errors early in the development phase with a minimal cost. All models must be pin accurate and each pin must match the expected voltage levels, drive strength, etc of the block. It is also high priority to verify Design For Test structures. The difficulty here is that the test feature of the IC might not be detailed in the specification when the latter is owned by the customer. It is still too often that DFT breaks the main functionality of a block or creates over consumption if not properly turned off during normal operation. Finally, the models should be reviewed with the block designers in order to check that no essential functionality is missing or wrongly modeled. This also gives the designer a reassuring knowledge of what is being simulated by the verification team prior to fulltransistor simulations.
5.1.1. Languages
An initial approach for the verification of mixed-signal designs has been to use digital HDL (VHDL or Verilog-D) to model the analog blocks. The advantage was the simulation speed, but the sensitive drawback was that these languages are not suitable to model all necessary analog behaviors. Indeed, time steps are constrained to discrete digital events, it is not possible to find zero-crossings; filtering, integration, derivatives, and other functions need to be recreated manually, and until SystemVerilog, floatingpoint connections were not supported.
13
Verilog-AMS solves these limitations. However, the modeling style of mixed-signal circuits tends to be the major contributor to simulation speed, after the transistors. We give some examples on how to speed up the simulations further in this paper. In the digital world, SystemVerilog has brought a powerful syntax to the verification engineer, such as concise assertion coding. Cadences AMS-Designer (based on ncsim simulator) is able, providing some cleverness, to co-simulate transistors, Verilog-AMS and SystemVerilog all together, enabling state-of-the-heart mixed-signal verification techniques. However, there is no SystemVerilog-AMS standard, even though Cadence and other companies are working on that project with Accelera. One could imagine that a first step would be to simply merge Verilog-AMS with SystemVerilog. Another valuable step would be to add some new AMS constructs such as AMS assertions able to monitor analog signals. Some companies are already proposing their own AMS assertion language.
STUB RTL/GATES
VAMS
14
Figure 7 shows how a mixed-level simulation can look like. The analog blocks that are complete can be selected at transistor-level while some or all of the surrounding blocks, such as the biasing references or the digital logic, can be left as models. In this case, the chip-level Verification Environment, together with the mixed-level representation of the IC, act as a super testbench for the block under test. If undesired interactions are likely to occur between several blocks, they should all be simulated at transistor level together. In order to get rid of the risk inherent to the use of models, each analog block should be at least simulated once at transistor level. The stub views are empty models, used as simple placeholders, whose functionality is not being activated in the given simulation. Our experience is that it is wiser to let the simulator consider the pins of the stub views being digital, so that if a high frequency signal is connected to it (such as a clock), it is kept digital by default. This avoids potential dramatic simulation slowdowns. As the design cycle progresses and the design of analog blocks is completed, the behavioral models can be replaced with their corresponding transistor (or RTL/gates) representation.
VAMS
VAMS
VAMS
Due to design re-use, some analog blocks that do not impact simulation time in a sensitive manner, might have always been simulated at transistor-level. In this case, there is no need to waste time creating models, unless the impact on simulation speed appears, for example if a high frequency clock gets connected to it. Finally, during the mixed-level simulation phase, the digital is kept at Register Transfer Level (RTL) or gate level. The latter is usually used to ensure that the scan chain, which is inserted during synthesis, did not break the functionality of the IC. Sometimes we also use Standard Delay Files (SDF) files to back-annotate the digital blocks.
15
vcore
VCORE
Digital Block _z
USB
Reg 1
Switched Cap
Block _x
Block _y
The digital blocks run at low voltages (such as 1.5V or below), while some analog blocks need higher operating voltage levels for better performance (such as 2.8V). Level-shifters are needed between digital and higher voltage analog domains. Levelshifters are simple linear analog blocks that simulate quite fast. Still, a level-shifter on a clock path can kill your simulation time. Hence, when possible, level-shifters on the clock lines should be replaced by simple (digital) Verilog models.
16
Digital (RTL)
1.5V CM
Analog (1.5V)
1.5V CM
VAMS model
2.8V CM
This example uses two power supplies: 1.5V and 2.8V. The default discipline, logic, is set for 1.5V domain, while logic28V is created for handling the 2.8V domain. discipline logic domain discrete; enddiscipline discipline logic28V domain discrete; enddiscipline
Listing 4 Example of discipline declaration
Then the Connect Rules are associated with the new logic28V discipline as shown in Listing 5.
17
`include "disciplines.vams" `include "userDisciplines.vams" connectrules ConnRules_28V_basic; connect E2L_0 #( .vsup(2.8), .vthi(2.0), .vtlo(1.0), .tr(0.4n)) input electrical, output logic28V; connect L2E_0 #( .vsup(2.8), .tr(0.4n), .rout(200)) input logic28V, output electrical; connect Bidir_0 #( .vsup(2.8), .vthi(2.0), .vtlo(1.0), .tr(0.4n), .rout(200)) inout logic28V, inout electrical; endconnectrules
Listing 5 Example of Connect Rules declaration
Finally, the new discipline must be attached to the appropriate instance or cell terminals. This is done with the scope_discipline option of the elaborator. The latter can then use this information during discipline resolution to detect the discipline pairs (such as logic28V and electrical) and insert the proper connect module with the proper power supply. ncelab scope_discipline "cellterm-gpadc.lshift_lv.out- logic28V"
Listing 6 Example of scope_discipline elaboration option
The command in Listing 6 tells the elaborator to consider the out pin of the cell lshift_lv from the library gpadc to be at 2.8 volts.
18
`celldefine module inv(x, a); // define pin sensitivities input (* integer supplySensitivity="\\vdd! "; integer groundSensitivity="\\vss! "; *) a; output (* integer supplySensitivity="\\vdd! "; integer groundSensitivity="\\vss! "; *) x; // supply declarations for supply sensitivity wire (* integer inh_conn_prop_name="vdd" ; integer inh_conn_def_value="cds_globals.\\vdd! "; *) \vdd! ; wire (* integer inh_conn_prop_name="vss" ; integer inh_conn_def_value="cds_globals.\\vss! "; *) \vss! ; // functional section. not ( x, a ); endmodule `endcelldefine
Listing 7 Example of a simple inverter using Cadence-specific syntax for supply-sensitive Connect Modules.
Additionally, these Connect Modules are slower that the standard ones.
could simulate tens of sine periods and extract an FFT, calculate the SNR, etc which was totally impractical with the original PLL and modulator description, still proving the system was correct. Charge pump Up digital clk Loop Filter analog VCO pllout digital
Phase Detector
fb
Dwn
digital
Divider
20
clk 1
clk clk 1 2
Figure 12 Non-overlapping clocks kept digital
Keeping the high frequency nets digital allow a 100x improvement factor in terms of simulation speed.
V1
1 2 +
V2
21
`timescale 1ns/10ps `include "constants.h" `include "discipline.h" module Switch_Ams( Y, X, CTRL); inout Y; //output pin inout X; //input voltage pin input CTRL; //1-bit control pin electrical X, Y; logic CTRL; parameter real RON = 1m; //ON-resistance; unit=Ohm parameter real ROFF = 1e9; //OFF-resistance; unit=Ohm real res; initial res = 1; always @(posedge CTRL or negedge CTRL) if (CTRL===0) res = ROFF; else res = RON; analog begin I(X,Y) <+ V(X,Y)/res; end // analog
Listing 8 Example of an AMS model of a transistor used as a switch
There is no need to edit the designers schematic if the AMS model used is included in the MOS library. Similarly to previous examples, a factor of 100x simulation speed is typically reached compared to when the clock nets are kept analog.
5.2.
Full-transistor simulations
In the analog world, there is no formal method to prove that a model is exactly reproducing the circuits behavior. Hence, the use of models introduces the risk that the simulation does not match the future silicon behavior. Consequently, it is important to also run full-transistor simulations, with a minimum (but carefully selected) set of functionalities being covered. Usually one tries to check the startup, shut down, and basic communication through the ICs interfaces. Unfortunately, 22
this can only be started once the design is complete, which is at the very end of the design cycle. However, using a fast-spice engine such as Ultrasim (Ultra-AMS) with the appropriate set of simulator options, one can simulate complex functions, such as a complete audio chain.
Table 2 presents the Ultrasim options we found the most appropriate for this kind of simulations. Ultrasim options .usim_top sim_mode=df .usim_opt speed=8 .usim_opt analog=0 .usim_opt dyn_part=0 .usim_optrshort=1.01 #<block name> .usim_opt dcut=1 #<standard cell names> .usim_opt speed=3 sim_mode=a #< cell name> Comments Global sim_mode set to digital fast Aggressive speed Aggressive partitioning Disables Dynamic Paritionning Remove small resistors Remove standard cells antenna diodes Tighten options for sensitive blocks
Running full-chip, full-transistor simulations allows potential leakages and overconsumption capture and tracking. Providing the huge number of transistors to simulate at a time (1M+), this is very challenging but it works. We are using Cadence Ultra-AMS environment. However, as of today, we use a spice testbench, because Connect Modules that otherwise are inserted between the Stimulus/Checker and the IC introduce false current calculations. Hence, only the Ultrasim solver is used: this is a pure analog simulation. Indeed, the stimulus can either be selected as a Verilog-AMS view for mixed-level simulations (cf. Figure 3) or a spice view in case of full-transistor current consumption simulation (Cf. Figure 15). Chip-Level Testbench
IC (DUT) Stimulus/Checker (Spice)
Vin1 Vin2
Figure 15: Chip-level Testbench with spice Stimulus for chip-level current consumption simulations
The bench must be as close as possible to the application: spice external components must be added (no Verilog-A/MS), and all pins must be connected. In our case, our capacitor library makes Verilog-A calls. Hence, we had to use simpler (pure Spectre) models.
24
Table 3 presents the Ultrasim options we found the most appropriate for this simulation. As a general rule, one must be extremely careful when widening the tolerance settings, as this can damage both functionality and performance simulation results. Wed better not spend time thinking there might be a design issue when the unexpected results are due to a too strong relaxation of the simulator parameters.
Ultrasim options .usim_opt rshort=1.01 rvshort=1.01 .usim_opt lshort=1e-3 lvshort=1e-3 .usim_opt elemcut_file=1 .usim_opt nodecut_file=1 .usim_opt dcut=1 #<all standard cells names> .usim_opt speed=2 #<digital cell name>
Comments Remove small resistors on both signal and power nets. Remove small inductances on both signal and power nets. Print all cut elements into a file. Print all cut nodes into a file. Remove standard cells antenna diodes Set speed=2 on all standard cells. A speed=8 is functional but too loose for accurate current consumption estimation. The global speed is left to its default value=5. Set digital blocks to digital-accurate. A digital-fast (df) option is functional but too loose for accurate current consumption estimation. The global sim_mode is left to the default mixed-signal (ms) mode. Aggressive partitioning on digital blocks Cf. comment on VR simulation below. Saving currents to waveform. CAUTION : current probing increases the size of the partitions. It is preferred to run several successive simulations with a limited number of current probes. Saving voltages to waveform Complete operating point calculation using pseudo-transient algorithm. The simulator extends the DC calculation until a stable operating point is reached. This disables the default 3 hour time limit, and the maximum DC event limit. Report the 100 most unstable nodes during DC calculation into a .dcr file. Higher voltage used for df or da models calculation.
.usim_opt analog=0 #<digital cell name> .usim_vr block=#<regulator cell name> node=<hierarchical path to supply node> .probe x(<hierarchical node name>)
25
.usim_opt mos_method=a
Non linear analog current and charge model for all MOSFET devices.
Using conventional partition method, all the blocks connected to an internally generated supply (cf. Figure 9) have to be contained in a single partition, resulting in unacceptable simulation performance. VR simulation is specifically designed to overcome this limitation. Finally, the simulators log file must be carefully read in order to see if there are no issues or main warnings which could lead to an incorrect behavior of the simulator, such as a bad partitioning or remaining Verilog-A models. The settings presented in Table 3 have been carefully tuned in order to match silicon measurements. Over consumption and leakages are often very difficult to debug on silicon. This methodology has proven to be very powerful to save this debug time, and it also prevented several IC respins. Unfortunately, some undesired consumptions due to floating nodes can not be caught by traditional simulations. The following chapter presents how we track them.
7. Floating nodes
Some sanity checks need to be done before tape-out to track potential floating nodes. Indeed, todays wireless handsets and portable multimedia player integrate an incredible set of features such as GPS, high resolution screens, WiFi, Bluetooth, still and video cameras, etc In order to deliver an acceptable battery life to these portable devices, advanced power management techniques have been developed, such as power gating which consists in turning off some of the supplies on the IC. Unfortunately, such techniques often result in unknown states and floating nodes. The floating nodes are the nodes that present high impedance values with respect to ground or supply nets. They appear when they are not correctly driven by the design.
26
No Power
VDD
Floating node
Figure 16 Example of floating node condition : the driver gate is powered down. Its floating output can cause both PMOS and NMOS of the load to be passing, creating a short circuit leakage.
These floating nodes cannot be detected via usual transient simulations and are often discovered on silicon, as they create over consumptions. As usual, the impact of detecting issues on silicon is much higher that detecting them before the IC is fabricated, leading to potentially being late on the market. Because of that, we are using a tool that measures the impedance of each node in the circuit, compares it to a user-defined threshold and generates the corresponding detailed report. Cadence provides similar capabilities with the pcheck option of Ultrasim solver. However, it does not report the values of the impedance, and has no integrated viewer to ease the analysis (cross-probing between the report and the schematic). Note that some nodes can voluntarily be high-impedance even when supplies are present, for example in switched capacitors circuits. In any case, designers can analyze the report and determine whether some nodes are badly controlled. As of today, this analysis at chip-level (full transistor) is still tedious.
This priority level is consolidated during a Verification Matrix Review with the design team. Typically, new functions have the highest priority. Then come the ones that need to be adapted. Some other high priority simulations are the ones that check the startup, turn off, some basic functionality such as communication with processor, etc The latter are required to be run at transistor-level.
For the ICs of the same family, providing their specifications have enough chapters in common, we use the same Matrix. When the test of a specific item is developed, and the item has been verified for a given IC, we report that into the matrix. The latter is then able to gather all this information and build a coverage report for each IC, allowing a continuous coverage follow up. Several coverage are actually defined, giving the percent of items being verified at blocklevel and at chip-level, the total reached coverage, and the percent of the items still uncovered by the test suite. It is worth mentioning that a 100% coverage, does not guarantee a bug-free design. Indeed, there are quite often several ways to verify a specification item. For example, some bugs are sequence-dependent. Lets take the example of a function that needs several SPI bits to be set. What if they all get programmed in a single SPI access, or if they get programmed sequentially, and in a specific order? Will the function activated behave the same? Future improvements consisting in automatically generating stimuli, based on constrained pseudo-random techniques, such as the ones already used in digital, will be able to reduce this risk. 28
As mentioned, the Verification Matrix is used for several ICs of the same family. It is a form of reuse (cf. Verification IP re-use Chapter). It is also reused, as a good starting point, for the new projects, providing they are close enough in terms of specifications. Indeed, writing down the matrix is quite a big task, but weve done it from scratch only once, while weve used it on a complete family of ICs. The Verification Matrix is finally reviewed with the design team and the management, in order to identify some missing items, and to limit misunderstandings between teams.
9. Regression Testing
Last but not least, running all these simulations during the development of the project is fine, but we need to make sure that the final database which is sent to fabrication is still compliant with the simulation results we obtained. Hence, we need to re-run all simulations at the very end of the development cycle. This is what we call regression (or non-regression) testing: we ensure that no functional or performance regression got introduced in the IC during the latest changes. There are at least two pre-requisites for regression testing. The first one is that all tests must be self-checking. Indeed, one cannot expect the engineers to visually review the waveforms of hundreds of tests in the last days before tape-out. The Verification IP library is made for that (cf. chapter 3). As luck would have it, this opens the door for all techniques of random or pseudo-random stimulus generation that can be used to find unexpected design corners or combinations.
9.1.
The second pre-requisite is that one must be able to launch the simulation from the command line. Indeed, one cannot expect the verification engineer to stay at his computers desk to click on the run button each time a new simulation needs to start. This is done by using the AMS-Designer command which takes in the name of the Cadence top cell and configuration, and from that determines what all of the files being pulled into the simulation should be. In order to ease the usage of the AMS-Designer command, a wrapper script was written. The first thing the wrapper does is create a run directory for the simulation. By including the hostname and process ID in the name, the run directory will always be unique each time the wrapper script is called. This allows for multiple tests to be run in parallel with no chance of conflict between the runs. The solver can be chosen directly from the command line (either Spectre or Ultrasim), and the model files can be altered from the default typ values to either bcs or wcs values. One can also save off toggle coverage information for the top level of the chip for each test. They can be combined to see the overall coverage of all tests taken together.
29
Finally, the script also allows one to submit the job directly to LSF with the lsf option. LSF will then select the most available compute servers, so that all tests can be run in parallel on a pool of machines. An example command line is given in Listing 9. wrapper -lib top_verification -cell top_testbench -view config_topctrl \ -test_name common_topctrl_revid -lsf -waves -waves_dir \$RUN_DIR
Listing 9 Starting a simulation from the command line (Example)
9.2.
We have also developed a script which parses all tests log files and collect the results in a comprehensive report file.
30
Regis submitted the regression at Wed Mar 12 18:45:34 CET 2008 Workarea used was X_top_verification.07 Logfiles can be found in $WORKAREA/top_verification/logfiles WORST LOGFILE TEST NAME CONFIG NAME BCS TYP -----------------------------------------------------------------------------------------------------------------------------charger_batfet config_charger_batfet N/A NOT_RUN N/A [...] gpadc config_gpadc N/A NCELAB N/A gpo1 config_gpo1 N/A NOT_RUN N/A pll config_pll N/A NOT_RUN N/A startup config_startup N/A NOT_RUN N/A tcled config_tcled N/A NCELAB N/A topctrl_fsm config_topctrl N/A NOT_RUN N/A topctrl_i2c config_topctrl N/A VNE N/A topctrl_revid config_topctrl PASS PASS PASS vcam config_vcam N/A NCELAB N/A vdig config_vdig N/A FAIL N/A viohi config_viohi N/A FAIL N/A vpll config_vpll N/A FAIL N/A vgen1 config_vgen1 N/A NCELAB N/A vgen2 config_vgen2 N/A NCELAB N/A vgen3 config_vgen3 N/A NCELAB N/A vsd config_vsd N/A NCELAB N/A sw1 config_sw1 N/A FAIL N/A sw2 config_sw2 N/A FAIL N/A backlight config_backlight N/A NCELAB N/A [...] N/A: The test was not in the regression for this mode NOT_RUN: Logfile was not found. ANE: Analog netlist error. VNE: Verilog netlist error, check the log file for *E NCELAB: Elaboration Error, check your config RUNNING: Job is either still running, or it may have been terminated early RUNERR: Job started running, but found a *E with no PASS/FAIL indication. NOT_SC: Not self checking, simulation seemed to complete, but END_TEST was never called NOCFG: Cadence couldn't find the config, likely caused by a machine with automount problems UNKNOWN: Status could not be determined from log file FAIL: Test finished with Errors PASS: Test pass, yay!!! Catagory Total(%) BCS(%) TYP(%) WCS(%) -------------------------------------------------------------------------------------------------------------------------Number tests in regression 66(100.00%) 2(100.00%) 62(100.00%) 2(100.00%) Number Tests submitted 36( 54.55%) 2(100.00%) 32( 51.61%) 2(100.00%) NOT_RUN 30( 45.45%) 0( 0.00%) 30( 48.39%) 0( 0.00%) ANE: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%) VNE: 6( 9.09%) 0( 0.00%) 6( 9.68%) 0( 0.00%) NCELAB: 15( 22.73%) 0( 0.00%) 15( 24.19%) 0( 0.00%) RUNNING: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%) RUNERR: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%) NOT_SC: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%) NOCFG: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%) UNKNOWN: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%) FAIL: 9( 13.64%) 0( 0.00%) 9( 14.52%) 0( 0.00%) PASS: 6( 9.09%) 2(100.00%) 2( 3.23%) 2(100.00%) Listing 10 Regression suite report example
31
10.
Conclusion
Since 2003, weve been able to successfully verify a complete Power-Management IC family of up to 1 million transistors, and more. The approach described in this paper, allowed us to find critical bugs before tape-out and to get a very high level of IC functionality on first silicon. This has been a very strong requirement for fast platforms software integration. In the mean time we also proved the effectiveness of the IC modifications due to specification changes. We have also been able to correlate our current consumption simulations with the real silicon, and to detect some accidental floating nodes. Overall, we reduced significantly our time-to-market and development costs.
11.
Future improvements
We are closely observing several initiatives, such as Verimags AMT tool, or a future SystemVerilog-AMS standard, that would propos AMS assertions. Finally, as mentioned above, automatic regression tests opens the door for all techniques of random or pseudo-random stimulus generation that can be used to find unexpected design corners or sequence hazards. As G.Bonfini writes in An Analog Mixed-Signal Verification Kit for Verification of Analog-Digital Circuits (YOGITECH SpA, via Lenin 132/p, 56017 San Martino Ulmiano (Pisa), Italia): If verification of digital sub-systems is based on advanced techniques such as constraints capture, randomized or pseudo-randomized stimulusgeneration and result collection with functional coverage evaluation, on the other side the use of hand-coded analog blocks models, manually-verified within a digital verification environment has been sufficient to provide confidence in a mixed-signal design to signoff prior to submitting it for fabrication. However, due to greater levels of integration, changes in process technology and increasing market pressures and risks, an automated and metric-driven methodology is now required
The team
This paper is the result of a collective work that has taken place for several years at Freescale. I would never have been able to write it down without the collaboration of Bill Getka and Mike Doll, digital and verification engineers at Freescale Libertyville (USA), Thierry Nouguier from our Toulouse CAD support team, Ana Ferreira-Noullet and JeanClaude Mboli from the Power-Management Verification team at Freescale Toulouse (France).
32
Bibliography
Detecting Leakage Problems in Low-Power Designs, Mike Demler, Nikkei Electronics Asia September 2007 An Analog Mixed-Signal Verification Kit for Verification of Analog-Digital Circuits, G.Bonfini, M. Chiavacci, R. Mariani, E. Pescari, YOGITECH SpA Regression Testing in Analog Verification, By Henry Chang and Ken Kundert Top-Down Design and Verification of Mixed-Signal Circuits, Ken Kundert, Henry Chang. Regression Testing in Analog Verification, Part 1, Henry Chang and Ken Kundert. Verification of Complex Analog and RF IC Designs, Henry Chang and Ken Kundert. Verification Plan Reuse Extending Verification Reuse for Verification Plan Definition and Verification Environment Implementation, Nihar Shah and Sasan Iman, SiMantis Inc. Analog Design Collaboration and Configuration Management, Paul Bompastore, TI. Verification Plan Reuse, Nihar Shah, Sasan Iman, Simantis, Inc.
33