Published on March 23, 2009
Verification of 1M+ transistors Mixed Signal IC for Cellular and Multimedia Applications Session # 2 Freescale Semiconductors Régis Santonja Presented at
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. 2
1M+ transistors Power- Management IC 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. 3
Block-level Testbench using the same vector file Stimulus/Checker (VAMS) Vector file (VAMS) SPI /I2C contains calls to the transactors. wrapper Also has stimulus and checkers for remainder of test initial begin <specific digital stimulus> end // initial always @ analog begin <specific analog stimulus> end // analog Audio (SSI) transactor SPI map files Optional Environment defines secondary Audio Environment Tasks transactor Waveforms Optional assertions 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. 4
Chip-level Testbench IC Stimulus/Checker (VAMS) (DUT) SPI/I2C pins Vector file (VAMS) SPI /I2C contains calls to the transactors. transactor Also has stimulus and checkers for remainder of test initial begin Optional <specific digital stimulus> secondary end // initial SPI/I2C Supplies/Grounds transactor always @ and other analog pins analog begin <specific analog stimulus> end // analog Audio (SSI) transactor BCL/FS/RX/TX SPI map files Optional Environment defines secondary Audio Environment Tasks transactor Waveforms USB (ULPI) transactor Optional assertions Other miscellaneous transactor which may be added in future 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). 5
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). /********************* 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(quot;********** WAIT FOR RESETB HIGH **********quot;); @(cross(V(RESETB)-SPIVCC_level/2, +1, 1n, 10u)); wdi = 1; COMMENT(quot;********** CHECK INT PIN IS HIGH **********quot;); check_digital_net_id(quot; INT pin high checkquot;, `IC.INT, 1'b1); COMMENT(quot;********** READING FIN, ICID AND REV BITS **********quot;); 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(quot;*****READING ICID DUPLICATE **********quot;); spi_icid_adc3_fld = spi_icid_fld; spi_read_fields1(fnGetAddr(quot;spi_icid_adc3_fldquot;), spi_icid_adc3_mask); COMMENT(quot;********** ALL TESTS COMPLETED **********quot;); END_SIM; end /********************* ANALOG EXECUTABLE **************************/ analog begin // Generic analog section `include quot;generic_analog.vquot; Listing 1 Example of vector file (extract) 6
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. //******************************************************************* // 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 7
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 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. 9
Top-block V3.0 X_top.01 X_top.01 B A V2.3 V1.2 X_top.01 X_top.01 C V2.8 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. 10
X_VE.12 Verification Environment X_topcell.06 Top-cell X_topblock_X.03 Topblock_X B A V2.3 V1.2 X_topblock_Y.05 C V2.8 Topblock_Y B A V2.3 V1.2 Topblock_Z B A V2.3 V1.2 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 Verification Engineer Topblock_Y X_topblock_Y.05 #1 work area Topblock_Z X_topblock_Z.08 Top-Cell X_topcell.06 Verification Environment X_VE.12 CCF file Central database (vault) 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). 12
Analog block Requirement Simulation method Small linear analog blocks Full accuracy Spectre Big non-linear analog Speed Mixed-level blocks (audio converters, Accuracy Ultra-AMS switchers, etc…) 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. 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. 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. STUB RTL/GATES VAMS Figure 7 Mixed level circuit representation example 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. STUB Digital model RTL/GATES VAMS VAMS VAMS 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. 15
5.1.3. Multiple supplies Typical Power-Management ICs have an on-chip voltage regulator generating internal supply voltages, as presented in Figure 9. Internal voltage Regulator + - Digital vcore Block VCORE _z Reg 1 USB Block Block Switched Cap Internal blocks _x _y supplied off the on- chip voltage regulator 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. 126.96.36.199. 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. 16
1.5V Digital Analog CM (RTL) (1.5V) 1.5V Level-shifter CM Analog (2.8V) 2.8V CM VAMS model digital pin CM : Connect Module 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. 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 quot;disciplines.vamsquot; `include quot;userDisciplines.vamsquot; 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 quot;cellterm-gpadc.lshift_lv.out- logic28Vquot; 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. 188.8.131.52. 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. 18
`celldefine module inv(x, a); // define pin sensitivities input (* integer supplySensitivity=quot;vdd! quot;; integer groundSensitivity=quot;vss! quot;; *) a; output (* integer supplySensitivity=quot;vdd! quot;; integer groundSensitivity=quot;vss! quot;; *) x; // supply declarations for supply sensitivity wire (* integer inh_conn_prop_name=quot;vddquot; ; integer inh_conn_def_value=quot;cds_globals.vdd! quot;; *) vdd! ; wire (* integer inh_conn_prop_name=quot;vssquot; ; integer inh_conn_def_value=quot;cds_globals.vss! quot;; *) 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. 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. 184.108.40.206. 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 19
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 Phase Detector pump Up digital pllout clk Loop Filter VCO digital analog fb Dwn digital Divider Figure 11 Fast model of PLL 220.127.116.11. 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. 20
clk δ φ1 δ φ2 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. 18.104.22.168. 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 + 21
Figure 13 Digital gates for switched-cap MOS `timescale 1ns/10ps `include quot;constants.hquot; `include quot;discipline.hquot; 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 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, 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. 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 Tighten options for sensitive blocks name> 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. 23
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). Chip-Level Testbench IC Stimulus/Checker (“Spice”) (DUT) Vin1 Vin2 Vin3 Vout1 Vout2 External devices Vout3 Vout4 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. 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 Remove standard cells’ antenna diodes names> .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 Set digital blocks to digital-accurate. A name> 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> Cf. comment on VR simulation below. node=<hierarchical path to supply node> .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. 25
.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. 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. 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. 27
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. 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 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. 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. 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. 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 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%)
Verification Of 1 M+ Transistors Mixed Signal Ic Presentation Apr 22, 2015 Technology regis-santonja
TechOnline is a leading source for reliable tech papers. View the Verification of 1M+ Transistors Mixed-Signal IC for Cellular and Multimedia Applications ...
Mixed-signal integrated circuit. A ... an efficient mixed-signal IC ... CMOS technology is usually optimal for digital performance and scaling while ...
be verified in the full IC or sys-tem context with the help of mixed ... verification Figure 1: ... using it for the verification of a mixed-signal ...
View 7985 Mixed Signal Ic posts, presentations, ... Mixed Signal I.C. Design Engineer at EASii IC, Senior Analog & Mixed Signal I.C. Design Engineer at ...
Verification of 1M+ transistors Mixed Signal IC for Cellular and Multimedia Applications Session # 2 Freescale Semiconductors Régis Santonja Presented at ...
... discuss mixed-signal/low-power IC design ... analog/mixed-signal simulation, and I’m ... verification of current and next gen mixed-signal ...
The tool then generates a layout for the IC incorporating each generated device and device group layout. ...