Mixed-signal verification of pipeline Analog-to-digital converter (ADC) prototype


Albert Lee
Edward Wong
Jenkin Chan
Hong Kong Applied Science and Technology Research Institute (ASTRI) Company Ltd.

ABSTRACT

The main objective of this paper is to illustrate how we make use of Nanosim in our design flow to perform mixed-signal functional verification for our 14-bit pipeline ADC test chip. It describes our experiences in using Nanosim to perform pre-layout and post-layout dynamic simulations. Being a fast SPICE simulator, Nanosim enables us to speed up our verification simulations by lowering our analog/mixed-signal design risks, and ensuring full functional accuracy before final sign-off.

1.0 Introduction

Nanosim enables us to perform quick functional and connectivity checks at various hierarchies of our design. Our analog modules were designed using a conventional bottom-up approach, i.e. we initially ran spice simulations on the schematic views and eventually RC extracted layout views to ensure full functionality of the individual analog building blocks. After assembling these analog blocks into larger modules, Nanosim was run at the various intermediate and top levels to verify analog functionality and to ensure that there are no connectivity errors within the analog blocks. Finally, chip-level simulation was performed to check whole chip functionality with special focus on the interface logic and connections between the analog and digital blocks.

This paper is organized in the following manner. Section 2 describes how we adopt Nanosim into our existing design flow. Section 3 discusses the verification of the analog blocks in pre-layout and post-layout modes. Section 4 illustrates our full-chip verification flow by using the VCD Direct-read feature in Nanosim. Section 5 presents the key features of Nanosim.

2.0 Integration of Nanosim into our design flow

Figure 1 depicts how Nanosim fits seamlessly into our design flow. In a conventional design flow, the digital and analog design teams work independently. Digital portions of the design are verified in a synthesis/HDL environment and the analog parts in a circuit simulation environment. There are very limited interactions between the two teams until full-chip integration and beginning of the verification of the resulting mixed-signal chip. One possible remedy to allow interaction between the two design teams is to use HDL code to model the behavior of analog blocks. The major drawback of such an approach is that there are limited ways to correlate the HDL model against the true functionality of the analog blocks, since HDL models do not often capture full analog behavior. Worst yet, block behaviors that are missing from and/or mis-represented by the HDL model due to human error pose major design risks.

As a result, a more reliable and robust approach is to simulate portions and even the entire design at the transistor level. Using Nanosim as part of our design flow, we were able to perform FAST spice simulation across all levels of hierarchy, ranging from small analog sub-circuits to whole-chip level.

Figure 1 Seamless integration of Nanosim into our existing design flow

3.0 Verification of pure analog blocks

The major analog blocks in our pipeline ADC prototype include a total of 11 multiplying DAC (MDAC) pipeline stages, a sample-and-hold (S/H) circuit preceding the first MDAC stage, and Bandgap reference and buffers. In essence, the analog verification task can be partitioned into four scenarios. 1) Block-level pre-layout : The primary goal of doing block-level pre-layout verification is to check functional behavior of an individual analog circuit. 2) Block-level post-layout : With back-annotated schematic netlist, post-layout verification re-checks functional correctness by taking into account extracted layout parasitics. 3) Top-level pre-layout : It verifies the overall analog top-level functionality and connectivity between analog modules. 4) Top-level post-layout : In the case of top-level post-layout with large amount of extracted parasitic elements, simulation can take a long time to complete. To avoid excessive run time, simulation based on a mixed pre and post-layout netlist seems to be the optimal choice in which back-annotation is only done on the critical analog blocks. Back-annotation of only the key analog blocks, instead of the full analog top, helps shorten the verification cycle without sacrificing accuracy. One additional point worth mentioning is that since switched capacitances are required in our analog circuitry, the “use_mos_chrgconserve” command was found to improve the simulation accuracy of the device models. The “use_mos_chrgconserve” command enables charge conservation for the MOS gate capacitances and is intended for cases where charge conservation is important. Example 1 shows the usage of this command which is included in our Nanosim .cfg file.

use_mos_chrgconserve I0.Icore.I_analog.*

Example 1 Accuracy level settings for our full-chip simulation

3.1 Analog block-level verification

The analog module of interest was instantiated in a simulation schematic and all the input stimuli were specified either as piecewise-linear (PWL) or constant values in voltage or current sources. In pre-layout mode, the corresponding SPICE netlist was generated directly from our simulation schematic. Usually the functionality of the lower-level analog blocks have already been verified in the early design phase by a third-party SPICE simulator, for example, Spectre. In addition, the time it takes to perform spice simulation on a pre-layout analog sub-block is short enough that it is not so much of a concern. Thus running Nanosim with the pre-layout SPICE netlist only serves as a cross-check against the simulation results from the third-party SPICE simulator. However, in the case of post-layout simulation, Nanosim surpasses other SPICE simulators in terms of speed and capacity as it added the flexibility to trade-off simulation accuracy versus performance. The ability to perform intelligent automatic circuit partition and to do RC compaction using Linear Network Solver (LNS) by Nanosim are significant enhancements over traditional SPICE simulators.

Post-layout verifications of the individual analog blocks are particularly crucial in our design due to the nature of differential signaling. Any asymmetry in the extracted RC on our analog differential signal paths will result in a significant degradation in the resulting circuit performance. As soon as the first-pass layout for an analog sub-block is completed, we proactively ran it through Nanosim to perform an initial functionality check and see how much it deviates from the ideal pre-layout results. Nanosim enables us to quickly identify and diagnose potential design problems and glitches caused by mismatches and unintentional layout parasitics much earlier in the verification phase before it propagates to the full-chip level where it is much more difficult to analyze and debug. In short, Nanosim allows us to sign-off the layouts of our bottom level analog sub-blocks with good confidence.

3.2 Analog top-level verification

The main reason for performing analog top-level simulations is to verify the connectivity between the analog sub-blocks and to observe the interaction between our analog sub-blocks with and without the influences of layout parasitics. Simulating just one analog sub-block alone is not sufficient to uncover any functional errors in the analog interface. Traditional SPICE simulations are very time consuming, given the size and complexity of our analog top, and hence the resulting SPICE netlist. Fortunately, Nanosim provides us with a convenient sliding scale for accuracy versus performance trade-off, with a low setting meaning less simulation accuracy but faster run-time and a high setting meaning improved accuracy but longer run-time. In particular, higher accuracy settings can be applied hierarchically to specific analog subcircuit instances of interest to maintain analog simulation accuracy while lower accuracy settings are applied to the remaining circuits to minimize overall simulation time. For instance, we apply a setting of 6 for the first three MDAC stages which are functionally more critical and a setting of 4 for the remaining MDAC stages in our 11-stage pipeline ADC design. Generally speaking, we found that Nanosim timing and power characterizations are within 5% of our comparison

SPICE simulation runs but run-time taken by Nanosim was at least 10x faster.

4.0 Full-chip mixed-signal verification

One of the major benefits of using Nanosim is that it enables quick and accurate functional verification of digital and analog interactions, especially at the full-chip level. In a traditional design flow, the digital place-and-routed (P&R) gate-level netlist is combined with the analog behavioral models to form the chip-level Verilog simulation model. One major design risk is that the analog behavioral models may not be functionally equivalent to the corresponding analog schematics due to human modeling errors. Any mismatches between the analog behavioral model and the real analog schematics may go unnoticed even after running the full-chip Verilog simulation. To completely close this design loophole, we generated and simulated full-chip SPICE netlists which are based upon the circuit schematics with and without the presence of back-annotated layout parasitics.

Another advantage of Nanosim is the ability to reuse our existing Verilog testbench in full-chip simulation. In other words, the same set of Verilog test vectors can be used for both chip-level Verilog simulations and Nanosim simulations. Value Change Dump (VCD) files, generated from our Verilog simulations, can be fed to Nanosim using its “VCD Direct-read feature”, thereby allowing us to read in the VCD dump file for dynamic simulation.

4.1 Using Nanosim

This section describes in detail how we leveraged Nanosim to perform full-chip mixed-signal verification for our ADC prototype in an efficient manner.Initially, a spice top netlist was generated by combining the post place-and-routed (P&R) digital netlist with the transistor-level analog netlist. The spice netlist also defines all the necessary simulation parameters, including a sine-wave function for the analog input, together with the desired nodes to save and print for waveform viewing. Next, we ran Verilog full-chip simulation using a third-party simulator tool to generate a VCD dump file which contains the input and output vectors for the digital logic only. Finally, we prepared a Nanosim configuration (.cfg) file which specifies the necessary commands for Nanosim, a signal information file to map the digital signals in the VCD file into the corresponding signals in the spice top netlist as well as an executable run file for running Nanosim in batch mode.

Full-chip dynamic simulation at the transistor level using a traditional SPICE simulator is incredibly slow such that this type of verification is usually not done. Even with Nanosim, certain techniques were employed to allow significant speed up for our chip-level simulation. For instance, different accuracy level settings were specified for the chip level, digital top-level and analog top-level. As opposed to analog circuits, since we were not trying to push for extra aggressive digital timing, we did not use a very high simulation accuracy level for our digital logic. Simulations ran much faster by using a lower level of accuracy. Example 2 exemplifies our accuracy level settings.

set_sim_eou sim=3 model=3 net=3 (full-chip)

set_sim_cmd I0.Icore.I_digital sim=2 model=2 net=2 (digital top)

set_sim_cmd I0.Icore.I_analog sim=4 model=4 net=4 (analog top)

Example 2 Accuracy level settings defined in .cfg for full-chip simulation

We also took advantage of the save-and-restore feature in Nanosim to re-start simulation from a previously saved simulation state. This feature is especially useful when the full-chip simulation needs to be run iteratively for various reasons. Suppose we ran the full-chip simulation once and saved all the simulation states at time = 20us (since the operations before 20us are common in all test scenarios). Subsequent runs can be re-started from time = 20us without having to start all over again from time = 0us. This significantly reduces our overall full-chip verification times. However, in order to use the standard save-and-restore feature, we need to convert the VCD file to vector (VEC) format using the VTRAN utility since it is the only way to do standard save/restore in

Nanosim W-2004.12 version. VTRAN is a universal vector translator which is used to convert vectors from one format to another. To invoke VTRAN, simply enter: vtran chip.vtran, where chip.vtran is the VTRAN command file shown in Example 2.

Example 3 VTRAN command for VCD to Nanosim vector conversion

In order to run Nanosim with the vector (VEC) file, the –nvec option is used in the Nanosim command line shown in Example 3.

nanosim –nspectre ./chip.scs –nvec ./chip.vec –C ./chip.cfg –A –o ./chip

Example 4 Nanosim command with –nvec option

Last but not least, it is always a good practice to save and print only selected circuit nodes rather than saving all the nodes in the design. In our spectre netlist, we saved only the necessary critical nodes, for example, the primary inputs and output signals and the interfacing signals between the analog and digital blocks, so that we can keep our output data to a manageable size. This avoids excessive simulation run time, and allows us to view the simulation outputs using waveform viewers, e.g. TurboWave.

4.2 Identification of mixed-signal bugs by Nanosim

A few mixed-signal design bugs were discovered by running Nanosim at the full-chip level. This kind of bugs would not be otherwise caught by our Verilog-top simulator model early on due to the absence of certain functional behavior in the analog behavioral models. This would pose a major design risk as the bug may go undetected if Nanosim was not used.

1) The power-on default values for a few test registers, namely, cntl_bg[3], cntl_vrefbuf[3] and osc[4], were incorrect which would cause the analog Bandgap and oscillator circuits to misbehave after reset. For instance, the correct default values after reset for cntl_bg[3:0] and cntl_vrefbuf[3:0] should be 8 (or 4’b1000 in binary format) as shown in Figure 2 below.

Figure 2 Power-on default values for cntl_bg, cntl_vcmbuf and cntl_vr

2) The ATP (analog test pattern) decoding scheme was not designed properly which would cause one of the ATP tests to be prematurely activated in normal mode after reset.

Nonetheless, these are non-fatal bugs since the test registers can always be re-programmed to the correct values after reset via serial port but they are costly and increase our silicon debug time. Although we managed to uncover these bugs before tapeout, in hindsight, it would be better off if we were to run Nanosim earlier in our design cycle. Often times, the time for doing system simulation is free since after the digital RTL code and the first-pass analog schematics are frozen, it generally takes weeks or even months before the final analog and digital layout and routing are completed. Therefore, the system engineers can take advantage of this window by using this powerful simulation engine to uncover and fix any system flaws left undiscovered by the block simulations.

4.3 Sine-wave test

Nanosim was chosen to be our final sign-off tool before taping out our prototype design. We consider our test chip to be fully functional when it passes the sine-wave test. Basically, a sine function at a fixed frequency is provided as differential analog inputs and the values of the 14-bit digital outputs are recorded. For functional correctness, the digital output values should resemble a sine wave when plotted. The performance of the ADC can also be measured in terms of the signal-to-noise (S/N), signal-to-distortion (S/D) and signal-to-noise and distortion (SINAD) by taking the Fast Fourier Transform (FFT) of the resulting digital outputs. Even only one of the digital output bits is incorrect, the resulting spectrum generated from the FFT will show a significant higher distortion than expected. Thus, if the FFT spectrum(s) were found to be clean, we can be confident about the full-chip functionality.

To accomplish the sine wave tests, a customized Perl script was created to parse the Nanosim output (.out) file. An example of our .out file is included in Figure 3.

igure 2 Power-on default values for cntl_bg, cntl_vcmbuf and cntl_vrefbuf registers

Figure 3 An excerpt of our Nanosim .out file

We can also view the digital and analog waveforms by using TurboWave, a third-party utility tool integrated with Nanosim, which parses the output data in the .out file.

Given the fact that our digital outputs are latched at every rising edge of the clock cycle (period = 28ns), the Perl script will extract the binary values of the 14-bit ADC output at every clock boundary from the .out file. Whenever any of the 14-bit digital output toggles, Nanosim will record the updated bit values in the .out file since it is entirely event-based. The Perl script will perform a one-to-one conversion from binary (in two’s complement representation) to decimal for the digital output which can subsequently be imported into Matlab. Figure 4 is an example of a Matlab plot for the digital output.

Figure 4 Sine wave for the 14-bit digital output (plotted in Matlab)

5.0 Key features of Nanosim

Nanosim is a high-performance, high-capacity circuit simulation and analysis tool. It offers simulation speed orders of magnitude faster than traditional SPICE simulators by using SPICE models table lookup and still produces SPICE-like accuracy for Big D (Digital) and Big A (Analog) SoC designs. Nanosim achieves high performance and capacity by adopting a divide-and-conquer approach. The design is automatically partitioned into smaller stages based on hierarchy. Unlike SPICE, any given stage is evaluated only when an input controlling node is triggered; hence, not all the stages are evaluated at each time step. Independent simulation of these smaller stages also helps in DC and transient convergence. Users can obtain useful information about their Nanosim runs such as circuit partitioning, total number of circuit elements, nodes and instances, any errors and/or warnings resulting from various stages of the simulation, by examining

the Nanosim .log file. For illustration purpose, an example of our Nanosim .log file is included in Figures 5(a) and 5(b).

Figure 5a An excerpt of our Nanosim .log file (to be continued in Figure 5b)

Figure 5b An excerpt of our Nanosim .log file

Nanosim supports design abstractions in RTL, gate and transistor level so that integration and verification can be performed at all phases of the design cycle. It also enables the deployment of a top-down, analog verification approach by allowing analog behavioral modeling in Verilog-A and C models. Compared to simulating Verilog-A modules with other full SPICE-based simulators, Nanosim has a key performance advantage since it uses the same high-performance fast SPICE engine. Nanosim support for Verilog-A enables designers to verify the whole system at the specification level to facilitate better architecture and IP selection. In addition, Nanosim provides the highly flexible verification solution for a variety of embedded IP such as a Verilog-based IP with a SPICE netlist and vice versa. On the other hand, Nanosim is tightly integrated with VCS, enabling powerful combination of gate-level performance with transistor-level accuracy. Due to the direct kernel-to-kernel interface between the two tools, it delivers high-performance mixed-signal simulation.

Nanosim offers the widest selection of SPICE netlist and model formats available on the market today, including any combinations of Verilog, Verilog-A, VHDL, EDIF, SPF, DSPF, SPEF, SPICE netlist, Spectre netlist, and C model. This makes it easy to fit into any verification methodology. It also comes with an intuitive and user-friendly setup and simulation environment GUI.

6.0 Conclusions and Recommendations

In our chip-level verification, Nanosim has proved to be a very useful tool by helping us uncover a few mixed-signal bugs late in our design cycle. Full-chip verifications are very intensive computations and the run-times depend largely on the operation conditions used for the simulations in addition to the computational power of the machine running the job.

Hence, full-chip verification has been confined to functional blocks and simulation corners which are considered most critical.

Thanks to the dedicated support by Synopsys Application Consultants and Hong Kong Science Park, we successfully accomplished our whole-chip verification cycle using Nanosim. This is also the first time that Nanosim is used in Hong Kong, China, to tape out a mixed-signal chip. We strongly recommend it to be used in both the block design phase as well as the final sign-off phase.

7.0 Acknowledgements

We would like to express our sincere thanks to Victor Yu, Sean Zhong, Jessica Yu, Xu Wei and Li-Xing Wang of Synopsys. Their contribution and support are essential to the success of this paper. The same goes to Oliver Pun and Tom Tang of Hong Kong Science Park who offered valuable help in setting up our Nanosim run at the EDA center.

8.0 References

1) Nanosim User Guide, Release W-2004.12, December 2004, Synopsys Inc., U.S.A.

2) VTRAN Manual, Release W-2004.12, December 2004, Synopsys Inc., U.S.A.