Presented at

Verification of 1M+ transistors Mixed Signal IC for Cellular and Multimedia Applications

Session # 2

Freescale Semiconductors

Régis Santonja

2

Verification of 1M+ transistors Mixed-Signal ICs for Cellular and Multimedia Player Applications Régis 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 IC’s 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 circuit’s specification. Indeed, older generations of Power-Management ICs had their functions quite independent one from the other. Whereas today’s 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 we’re using to track that all specification has been covered by simulation.

3

Figure 1: 1M+ transistor Power-Management IC

3. The Verification Environment

This chapter describes the Verification Environment (VE) that we used for the verification of our Power Management ICs.

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 chip-level. 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.

1M+ transistors Power-

Management IC

4

Figure 2: Block-level testbench

3.2. The Chip-level testbench

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 Leader’s 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.

SPI /I2C

wrapper

Audio

(SSI)

transactor

SPI map files

Environment defines

Environment Tasks

Waveforms

Stimulus/Checker (VAMS)

Optional assertions

Optional secondary

Audio transactor

Block-level Testbench using the same vector file

Vector file (VAMS) contains calls to the transactors. Also has stimulus and checkers

for remainder of test initial begin <specific digital stimulus> end // initial always @ analog begin <specific analog stimulus> end // analog

5

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.

3.2.1. The Verilog-AMS Stimulus/Checker module

As shown in Figure 2 and Figure 3, the Stimulus/Checker consists of a number of include files. These are used to provide resources which can be used to write stimulus and checkers for exercising and observing the Design Under Test (DUT).

Chip-level Testbench

IC

(DUT)

Other miscellaneous

transactor which may be added in future

SPI /I2C

transactor

Optional secondary SPI/I2C

transactor

Audio (SSI)

transactor

Vector file (VAMS) contains calls to the transactors. Also has stimulus and checkers

for remainder of test initial begin <specific digital stimulus> end // initial always @ analog begin <specific analog stimulus> end // analog

Supplies/Grounds and other analog pins

Optional secondary

Audio transactor

USB (ULPI)

transactor

SPI/I2C pins

SPI map files

Environment defines

Environment Tasks

Waveforms

Stimulus/Checker (VAMS)

BCL/FS/RX/TX

Optional assertions

6

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 chip’s 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).

Listing 1 Example of vector file (extract)

/********************* 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"

7

The vector file is made of 2 parts. The digital side drives the test’s 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.

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.

Listing 3: Log file example

% 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

//*******************************************************************

// 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;

8

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.

9

On the model side, we also have generic and configurable models for LDO’s, amplifiers, etc… In addition, we have also developed generic vector files for the most common mixed-signal 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

Today’s 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.

10

Figure 4 Block Tagging methodology

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 today’s 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.

Top-block V3.0

A

V1.2

B V2.3

C V2.8

X_top.01

X_top.01

X_top.01

X_top.01

11

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

Verification Environment

Top-cell

Topblock_X

A V1.2

B V2.3

C V2.8

Topblock_Y

A V1.2

B V2.3

C V2.8

Topblock_Z

A V1.2

B V2.3

C V2.8

X_topblock_X.03

X_topblock_Y.05

X_topblock_Z.08

X_topcell.06

X_VE.12

12

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.

Figure 6 Building workareas for Verification of released database

5. Speeding the simulations up

Some years ago analog functions were limited to their minimum. Nowadays, even though performance and size are still key constraints, a new one has shown up: the function must now be modular, configurable for multiple standard usages. It needs to have special extra features for test efficiency, calibration, low power modes, etc… All this has dramatically increased the complexity of the mixed-signal circuits and the corresponding simulation times. Consequently, a constant concern of verification is the trade-off between simulation speed and accuracy. Small linear analog blocks can still be simulated with full accuracy using a “spice” engine (Spectre). However, for big, non-linear (i.e. switched capacitors) analog functions, one can either promote simulation speed and go for mixed-level simulations, or promote simulation accuracy and go for a “fast-spice” engine (Ultra-AMS).

Central database (vault)

Verification Engineer

#1 work area

Topblock_X X_topblock_X.03 Topblock_Y X_topblock_Y.05 Topblock_Z X_topblock_Z.08 Top-Cell X_topcell.06 Verification Environment X_VE.12

CCF file

13

Analog block Requirement Simulation method

Small linear analog blocks Full accuracy Spectre

Speed Mixed-level Big non-linear analog blocks (audio converters, switchers, etc…) Accuracy Ultra-AMS

Table 1: Accuracy versus speed simulation method

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 full-transistor 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, floating-point connections were not supported.

14

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. Cadence’s 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.

5.1.2. Mixing all levels together

Mixed-level simulations can start as soon as the pin list of all blocks is defined. A top-cell can then be created which connects appropriately all the blocks’ pins together. Depending on its availability, and the simulation time that we can live with, one can either use a transistor or a behavioral model for each block.

Figure 7 Mixed level circuit representation example

RTL/GATES

VAMS

STUB

15

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.

Figure 8 Top-Down Verification

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.

Digital model

VAMS

STUB

RTL/GATES

VAMS VAMS

16

5.1.3. Multiple supplies

Typical Power-Management ICs have an on-chip voltage regulator generating internal supply voltages, as presented in Figure 9.

Figure 9: Internal regulator and its power tree

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. Level-shifters 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.

5.1.3.1. Block-based Discipline Resolution

As presented in Figure 10, several connect modules need to be defined to support multiple supplies mixed-level simulations. This is done using Cadence’s Block-based Discipline Resolution (BDR) methodology. The latter allows to set different disciplines in the digital domain. The elaborator uses BDR to determine which part of the design has which power supply.

vcore

USB

Switched Cap

Reg 1

Digital

Block_x

Block_y

Block_z

VCORE

+ -

Internal voltage Regulator

Internal blocks supplied off the on-

chip voltage regulator

17

Figure 10 Multiple connect modules

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.

Listing 4 Example of discipline declaration

Then the Connect Rules are associated with the new logic28V discipline as shown in Listing 5.

Analog (1.5V)

Analog (2.8V)

VAMS model

Level-shifter

Digital (RTL)

digital pin

1.5V CM

1.5V CM

2.8V CM

CM : Connect Module

discipline logic domain discrete; enddiscipline discipline logic28V domain discrete; enddiscipline

18

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.

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.

5.1.3.2. Supply-sensitive Connect Modules

As we can see, this can be a bit tedious to specify all the cells or instances that need to be associated with a given discipline. Indeed, in real Power-Management ICs, it is typical to have 4 or 5 different supply levels, as some functions need to be connected to an external lithium cell which can typically be at 2.5V, some others need to be connected to the battery, which is typically around 3.6V, and one can also need to consider a 20V domain because of a battery charger being on the same die. In this case, one might consider to use supply-sensitive connect modules. The latter are able to automatically grab the voltage level of the net connected to their analog side. However, these connect modules require the digital code to include some Cadence-specific syntax. Indeed, the libraries of the standard cells have to be re-written. And for RTL or gate-level simulations, the code or netlist also needs to comply to this syntax. Unfortunately, this syntax might not recognized by other tools. A wrapper might then be needed.

`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

ncelab –scope_discipline "cellterm-gpadc.lshift_lv.out- logic28V"

19

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.

5.1.4. Examples of mixed-level simulations

As mentioned before, the goal of mixed-level simulations is to be able to guarantee a high functional coverage by speeding up the simulations compared to running all transistors together. Here are a few real case examples of techniques to speed mixed-level simulations up.

5.1.4.1. Phase Locked Loop (PLL)

The designer had generated a model of his PLL, as a schematic, based on some Verilog-A components. This was perfectly functional, but the PLL model took about 2 hours to lock. The simulation was accelerated by a factor of 100x, enabling the PLL to lock within a minute of simulation time. The strategy was to minimize the number of high frequency nets being considered analog. In practice, this consisted in changing the flops and the divider to a Verilog description, rewriting a model of the Voltage Controlled Oscillator (VCO) so that its output became digital, making sure the PLL output was not converted to analog outside of the PLL, and finally that the input clock was digital too. The PLL was not alone; it was driving the digital filters and sigma-delta modulator of an audio Coder-Decoder (Codec). Providing some additional work on the modulator, we

`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

20

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.

Figure 11 Fast model of PLL

5.1.4.2. Non-overlapping clocks

Non-overlapping clock circuits are needed by all switched capacitors implementation. The block is usually a schematic because, even though this might be a pure digital implementation, the RTL is not well suited to model non-overlapping clocks because of delays being required during simulation. Figure 12 presents a simple implementation of a non-overlapping clock generator. In order to simulate such a block in a timely manner, one needs to use the digital Verilog models of the gates. Indeed, the actual implementation of non-overlapping clocks can be more complex. And usually the delays are built with a chain of inverters, creating as many nets that would dramatically slow down the simulation if they were to be simulated as analog.

clk pllout

Up

Dwn

VCO

fb

Divider

digital

digital analog

digital

Charge pump

Loop Filter

Phase Detector

21

Figure 12 Non-overlapping clocks kept digital

Keeping the high frequency nets digital allow a 100x improvement factor in terms of simulation speed.

5.1.4.3. Switched capacitor (a/d and d/a converters)

In the same spirit, when simulating a switched capacitor circuit, we are used to replace analog switches with an AMS model where the MOS gate is considered digital. This allows keeping the clock lines digital. Figure 13 presents a simplified implementation of a switched capacitor integrator. In real life, the topology of switched capacitor circuits are differential (doubling the number of switches and clock nets), and globally much more complex. They are used for example in high performance audio converters.

-

+

V1

V2

φ1 φ2

clk

φ1

φ2

clk

clk

δ

δ

φ1

φ2

22

Figure 13 Digital gates for switched-cap MOS

Listing 8 Example of an AMS model of a transistor used as a switch

There is no need to edit the designer’s 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 circuit’s 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 IC’s interfaces. Unfortunately,

`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

23

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.

Figure 14 Example: Simulating a complete receive audio chain

Table 2 presents the Ultrasim options we found the most appropriate for this kind of simulations.

Ultrasim options Comments

.usim_top sim_mode=df Global sim_mode set to digital fast

.usim_opt speed=8 Aggressive speed

.usim_opt analog=0 Aggressive partitioning

.usim_opt dyn_part=0 Disables Dynamic Paritionning

.usim_optrshort=1.01 #<block name> Remove small resistors

.usim_opt dcut=1 #<standard cell names> Remove standard cells’ antenna diodes

.usim_opt speed=3 sim_mode=a #< cell name>

Tighten options for sensitive blocks

Table 2 Complete receive audio chain simulation options

6. Full-chip current consumption simulations: 1M+ transistors!

Despite functionality, we also want to run to track potential leakages and over-consumption at IC level.

24

Running full-chip, full-transistor simulations allows potential leakages and over-consumption 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).

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.

Chip-Level Testbench

External devices

Vin1

Vin2

Vin3

Vout1

Vout2

Vout3

Vout4

IC (DUT)

Stimulus/Checker (“Spice”)

25

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. We’d 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 Comments

.usim_opt rshort=1.01 rvshort=1.01 Remove small resistors on both signal and power nets.

.usim_opt lshort=1e-3 lvshort=1e-3 Remove small inductances on both signal and power nets.

.usim_opt elemcut_file=1 Print all cut elements into a file.

.usim_opt nodecut_file=1 Print all cut nodes into a file.

.usim_opt dcut=1 #<all standard cells names>

Remove standard cells’ antenna diodes

.usim_opt speed=2 #<digital cell name> 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.

z.usim_opt sim_mode=da #<digital cell name>

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.

.usim_opt analog=0 #<digital cell name> Aggressive partitioning on digital blocks

.usim_vr block=#<regulator cell name> node=<hierarchical path to supply node>

Cf. comment on VR simulation below.

.probe x(<hierarchical node name>)

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.

.probe v(<hierarchical node name>) Saving voltages to waveform

.usim_opt dc=1 Complete operating point calculation using pseudo-transient algorithm.

.usim_opr dc_prolong=1 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.

.usim_opt dc_rpt_num=100 Report the 100 most unstable nodes during DC calculation into a .dcr file.

.usim_opt vdd=3.0 Higher voltage used for df or da models calculation.

26

.usim_opt mos_method=a Non linear analog current and charge model for all MOSFET devices.

Table 3 Full-chip, full-transistor simulator options

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 simulator’s 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, today’s 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.

27

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.

8. Tracking coverage with the Verification Matrix

This chapter presents the way we, at Freescale, track the verification coverage, during the whole development cycle of our Power-Management ICs. We gather all the specification items into an Excel document that we call the Verification Matrix. The main focus is on functionality. However, some of the performance items are also reported. Typically on our Power-Management ICs, several thousands of items are listed in the matrix. For each item, we document the required test conditions, the associated pair of Cadence configuration and vector file, whether the item is to be verified at block-level only, or if a chip-level simulation is required, a priority number used to mitigate the risks, and finally a column is dedicated to add comments.

No Power VDD

Floating node

28

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.

Table 4 Example of Verification Matrix core sheet

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 block-level 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”. Let’s 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.

29

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 we’ve done it from scratch only once, while we’ve 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. Running a simulation from the command line

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 computer’s 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.

30

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.

Listing 9 Starting a simulation from the command line (Example)

9.2. Automatic log parser and regression suite report

We have also developed a script which parses all tests’ log files and collect the results in a comprehensive report file.

wrapper -lib top_verification -cell top_testbench -view config_topctrl \ -test_name common_topctrl_revid -lsf -waves -waves_dir \$RUN_DIR

31

Listing 10 Regression suite report example

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 TEST NAME CONFIG NAME BCS TYP WORST LOGFILE ------------------------------------------------------------------------------------------------------------------------------ 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%)

32

10. Conclusion

Since 2003, we’ve 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 platform’s 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 Verimag’s 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 stimulus-generation 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 sign-off 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 Jean-Claude Mboli from the Power-Management Verification team at Freescale Toulouse (France).

33

About the author

Regis Santonja received a Bachelor of micro-electronics and signal processing from the "Ecole Supérieure d’Ingénieurs en Eletrotechnique et Electronique" (France) in 1993. He began as an Applications Engineer at LSI LOGIC (France) and spent a few years in several countries around Europe and in the U.S.A. as a digital IC designer. After a short period working for the "Compagnie des Signaux Technologie Informatique" (France), he joined Motorola’s Power Management design team as a digital designer. Since 2002, he has taken the lead of the verification activity of Freescale Power-Management ICs dedicated to mobile phones and Portable Media Players.

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.