A Comprehensive Analog–Mixed Signal (AMS) Simulations Environment

Abstract

The analog–mixed signal simulation environment, used for verifying non-volatile memory macrocells, is presented. It has been adopted over the last decade, providing excellent results in verification coverage, efficiency, and flexibility. This methodology ensures a smooth and effective transition from full transistor/fully analog simulations to fully digital simulations while maintaining most of the environment’s features. This allows verification designers to exchange data, stimuli, and results, thereby enhancing debugging capabilities and reducing simulation time.

1. Introduction

Among the design flow steps, the verification phase has become increasingly important and has grown in complexity: this is especially true for non-volatile memories (NVMs) such as NOR Flash or equivalent technology.

The NVM macrocells being verified by the presented flow range from 128 KB up to >4 MB memory, and operate within a wide voltage range (e.g., 1.2 V supply and up to ~15 V internal nets). On the analog side, they may have one or more memory cell arrays with a complex periphery (row/column decoding), read/write management, test management, several charge pumps, digital-to-analog converters (DACs), internal current/voltage references, oscillators, and so forth. The digital blocks include finite state machines, microcontrollers, registers, read-only memories (ROMs), and random-access memories (RAMs). The interaction of all parts must be verified with extreme confidence before proceeding to industrialization [1].

Such designs, in fact, require a comprehensive list of verifications with up to 200 full-chip simulation patterns (excluding pure digital simulations, which may sum to many tens of thousands). Analog simulation tools, though highly accurate, are insufficient to achieve fast performance, early debugging, and wide coverage in such a complex environment: that is why co-simulations (also analog mixed-mode simulations, AMSs) must be used, based on the interaction of digital and analog simulation tools [2].

However, a number of full transistor-level simulations (i.e., completely analog verifications) are still mandatory to extract crucial data such as accurate timings and power consumption. Normally, the approach to these simulations is different from the pure AMS approach because they require a different environment (netlist, input stimuli, etc.). The presented methodology unifies the various simulation types (from fully digital to full transistor) in a comprehensive and flexible environment.

2. Tools and Methods

The presented verification flow is based on Synopsys^® tools (in Supplementary Materials), as follows:

• PrimeSim^TM-XA^TM (FastSPICE simulator);
• VCS^® (digital simulator);
• Custom WaveView^TM (waveform analyzer).

They are currently the best-in-class for speed and capacity, particularly when dealing with huge analog circuitry, as in the case of NVM. As an example, the latest NVM verified by this flow is 640 KB in 40 nm technology, which is made of ~400 K devices and, after back-annotation, includes around 4 million analog elements (transistors, resistors, capacitors). On average, a typical verification using 8 processors in parallel takes between a few hours (for 25µs simulation) and 7–14 days (for 1 ms simulation).

3. Verification Flow

Some basic knowledge of the verification process is provided below.

3.1. Introducing the Co-Simulation

A full-chip verification can usually rely on three different methods (Figure 1), as follows:

• Full transistor-level (analog): based on SPICE netlist of both analog and digital subcircuits, this gives the highest accuracy but limited coverage (CPU-demanding).
• Fully digital: based on VHDL/Verilog digital blocks and behavioral modeling of analog blocks, this gives the highest performance and coverage, but low accuracy.
• Mixed-mode (AMS): analog and digital behavioral modeling are merged, and this requires both continuous time analog simulation and digital event-driven simulation.

Therefore, a mixed-mode simulation can be defined as a co-simulation of two different design views or netlist formats/domains, using two different simulators, i.e., two simulation kernels that separately solve the analog and the digital blocks, and exchange data to proceed (Figure 2).

This verification methodology not only reduces runtime but increases coverage against transistor-level simulations performed by SPICE standalone [3,4]. Furthermore, since SPICE netlist of digital blocks is often not available for a considerable amount of time in the design cycle, the co-simulation approach based on register transfer language (RTL) can be used to start verification with already completed analog blocks.

3.2. The FastSPICE Optimizations

The fastest co-simulation may still be too slow for satisfying coverage; the bottleneck here is the analog engine. This is where the FastSPICE tools have become indispensable: the main strengths of FastSPICE compared to SPICE are shown in

Table 1. Comparison between SPICE and FastSPICE approaches.

SPICE	FastSPICE Optimizations
Accurate device models	Approximate device models Reduction of RC networks
Global convergence at each time-point	Event-driven simulations No global convergence
Global time-step	Multi-rate simulation
Single matrix for entire circuit	Partitioned matrix, hierarchical simulation

.

The key concepts here are “partitioned matrix” and “event-driven”. The simulator normally translates the SPICE netlist into an internal resolution matrix which is solved via several mathematical algorithms (to compute all voltages and currents in circuit nets and devices); by partitioning the single, huge matrix into many smaller ones, the simulation is accelerated because solving small regions uses fewer computing resources (CPU/memory), as shown in Figure 3.

If multi-thread computing is available, smaller jobs can be effectively parallelized with further speed increase (ideally, N CPUs may run at a speed N times higher).

Moreover, the simulator solves a sub-matrix only when an event occurs at its boundary: for example, an event can be a voltage or current change greater than a defined threshold value. As shown in Figure 4, circuit partition 1 can be controlling two more separate partitions (2, 3) using specific controlling nodes: any of these is considered active only when its voltage changes by a quantity ΔV larger than V_threshold.

In the picture, this is the case for partition 2, which is solved; instead, partition 3, controlled by an idle node which is not changing its voltage level, is not solved, and is not included in the convergence computation. This way, the global resource demand is lower.

3.3. Interface Elements

A key feature in a mixed-mode simulation is the communication between analog (SPICE) and digital (VHDL/Verilog) blocks: it is essentially based on the signal conversion from discrete to continuous domain (Digital To Analog, or d2a) and vice versa (Analog To Digital, or a2d).

The d2a converter is used to apply the output signal of a logic block as an input to an analog block, by building a relationship between the digital domain and the analog domain. In Figure 5, a generic connection between a logic block driving an analog one by a signal S is shown.

The required d2a interface element is automatically placed by the simulator on wire S, to adapt a digital output S_D (either zero or one) to an analog input S_A (ranging from low level, or lov, to high level, or hiv), as shown in Figure 6.

The mixed-signal digital view (e.g., Verilog topview) is shown in Figure 7.

In opposition, an analog block driving a digital one is shown in Figure 8.

An inverse conversion is required to adapt an analog output S_A (defined between low threshold, or loth, and high threshold, or hith) to a digital input S_D (accepting either zero or one), as in Figure 9.

The mixed-signal digital view (e.g., Verilog topview) is shown in Figure 10.

The correct direction of the pins S_A and S_D is extracted from the topology of the SPICE circuit and of the logic gates, according to the natures of their drivers or loads.

3.4. Testbench Architecture

The standard approach for co-simulation is digital-on-top (DoT), since it deals with devices that are embedded in more complex products (e.g., a Smartcard) with a fully digital interface. Moreover, in most cases, there is only one analog partition and one, or more, digital blocks. As shown in Figure 11, the SPICE block exchanges data with the digital block (either Verilog or VHDL), via the d2a and a2d interface elements. The setup for this simple architecture may, in general, follow one of two directions, VHDL or Verilog top; either choice has consequences, particularly when dealing with analog signals on top.

3.4.1. VHDL Top

A SPICE block cannot be placed directly in a VHDL top since it requires the proper definitions of the interfacing signals: this necessitates an additional layer (wrapper), described in Verilog, which surrounds the analog block and manages the communication of all input/output (I/O) ports between the digital top and the analog block itself.

In addition to that, any analog signal to/from the SPICE, which needs to be used as a VHDL port, must be specially treated by declaring it as VHDL type real, and the corresponding Verilog port must be defined as wreal. Proper interface elements will be used to transport the data from SPICE electrical to VHDL real (electrical-to-real or e2r) or vice versa (real-to-electric or r2e). Figure 12 shows the case of a VHDL top instantiating a SPICE block, whose output(s) are transferred by e2r as output(s) of the VHDL itself.

Of course, the inverse applies for input data to a SPICE block in a VHDL top, which will require r2e conversion to transfer real numbers from the VHDL port to the SPICE analog input pins.

There are cases when two SPICE blocks must exchange data (e.g., voltages or currents) while embedded in the same digital VHDL top; in the case of Figure 13, the output from the first analog block (SPICE 1) must cross the Verilog wrapper, go through the e2r to become real and come out to the VHDL world, and then again enter the r2e to cross the Verilog wrapper of the second analog block (SPICE 2) as an electrical input.

3.4.2. Verilog Top

With a Verilog top (Figure 14), the story is different. First, there is no need for any wrapper: the analog block is homogeneously placed as a Verilog module, while its SPICE netlist is easily passed to the Analog Mixed-Mode simulator using the following command:

• use_spice –cell <SPICE_block_name>;

in the initialization file vcsAd.init. Therefore, there is a faster initial setup and simpler changes whenever the SPICE pinout is modified.

Then, VCS, as usual, defines the a2d and d2a converters automatically, but mixed signals can now cross the SPICE/Verilog boundary without converters (such as e2r).

Such signals are propagated by the so-called a2a through-nets; that is, despite being Verilog wires, they are optimized as analog nets (and by default dumped only to the analog output file) without redundant a2d and d2a converters (and computational overhead). Furthermore, the a2a interfacing allows the exact SPICE-like current computation, which is not true for e2r/r2e; that is why it is also the best choice when connecting two SPICE blocks instantiated in a parent digital cell (Figure 15). A practical example of this approach could be a first SPICE 1 block, generating biasing voltages, used to drive an additional SPICE 2 block, which is external to the first one but shares the same Verilog top.

3.4.3. Final Choice

In conclusion, the VHDL top level approach is less efficient. First, the SPICE blocks must be placed by a Verilog wrapper: however, it can be easily understood that this flow is long and susceptible to mistakes, because the SPICE netlist must be elaborated to generate the wrapper, and the VHDL top must be adapted to it. Moreover, every change in SPICE pin-out (very frequent during early development phases) requires many changes to align all views.

The Verilog top level approach is more efficient. The topview is easily provided by digital designers, and it directly derives from the already available Verilog scheme used for the synthesis. Furthermore, the digital Verilog top can be adapted to the evolution of the design: it will initially be the post-synthesis netlist, and later the post-layout scheme can be used taking advantage of the back-annotation through SDF (standard delay format) files. Also, ECO (engineering change order) fixes, which may correct wrong functionality by metal re-routing, can be quickly reproduced and simulated without major changes in the flow.

The analog signals management shown in Section 3.4.2 is clearly faster and more efficient with this choice, too. The Verilog topview is definitely the best choice for the co-simulation flow.

4. The Complete Co-Simulation Environment

Having presented the basic architecture of the co-simulation scheme, it is time to explore the various environment options, based on verification purposes (mainly, accuracy and performance). The starting point is again the scheme of Figure 11, redrawn as shown below in Figure 16.

This general-purpose scheme is applicable for any AMS verification environment with a transistor-level part (SPICE) managed by the analog simulator and a digital part (RTL) managed by the digital simulator. Input stimuli are provided in digital format (such as .tcl commands), and both analog and digital outputs are normally available. This is a sort of ideal combination in which the analog circuitry is solved with very high accuracy and the digital one is managed with the highest speed; starting from this, it is possible to build the two other combinations for the extreme cases of fully digital and fully analog verifications.

4.1. Fully Digital Environment

To perform a huge set of functional verifications which cover many combinations of input sequences and/or digital states (e.g., registers contents), the best choice is a fully digital environment where the analog blocks are either modeled by some RTL language (like System Verilog) or described at high level by a more or less detailed behavioral model [5]. The easy replacement of the whole analog part may lead to the situation shown in Figure 17 (where BEH stands for the digital behavioral model block).

This solution provides the widest coverage: the analog details are lost (e.g., internal voltages/currents, power consumption, transition timings) but, thanks to the computational speed of pure digital simulations, the amount of stimuli/states combinations is in the range of thousands. This is extremely important for the careful verification of RTL codes, ROM algorithms, settings, and timings in all combinations, even randomized combinations.

As mentioned in Section 3.4.3, after the RTL code is complete, the logic is synthesized at gate level and the process of Place&Route is performed to optimize area occupation, propagation delays, and gate density; then, the RTL can be replaced with an extracted Verilog netlist (which is also back-annotated with the capacitive loads) for better simulation confidence.

4.2. Fully Analog Environment

On the other hand, the highest accuracy can only be achieved using a fully analog environment (wherein everything is placed at the transistor-level, including digital blocks, with no modeling at all); that is the only way to extract a complete picture of voltages, currents, timings, and power in any combination of process corners, voltage supply, and temperature (PVT) [6]. This implies that such simulations are highly detailed but very slow.

In general, the fully analog environment is quite modified compared to the ones shown so far, which are based on a Verilog top and contain a selection of RTL, behavioral or SPICE blocks inside. The scheme is illustrated in Figure 18.

Here, there is at least one big difference: the input stimuli cannot be described as digital sequences, but in a SPICE-like transient format (such as .pwl). As an example, to set a signal Input1 from low to high level at t = 100 ns and back to low after 200 ns, in .tcl format, the command sequence is similar to the following:

Meanwhile, in SPICE format, with Gnd = low (0 V) and Vdd = high, the sequence is more similar to the following:

• Vin1 Input1 Gnd PWL 0 0 100n 0 100.1n Vdd 300n Vdd 300.1n Gnd

which is less readable and hardly editable.

In addition to this, the simulation environment must be rewritten and the whole flow is different: the poor reuse of existing files is possible, with a loss of time and resources and a risk of misalignment against the other environments.

4.3. Fully Analog Environment with Verilog Top

There is a simple and effective solution to the problems mentioned above. As stated in 3.4.2, encapsulating SPICE blocks inside a Verilog top does not at all alter the connectivity and propagation of analog nets; then, it is possible to place the analog blocks of Figure 18 in the same Verilog top used in the existing AMS environment (Figure 16).

In order to allow the full reuse of input stimuli in digital format, the only small update which is required is the generation of D/A (input) and A/D (output) converters in the Verilog top itself; this way, the SPICE blocks have full connectivity to the external digital boundary.

As shown in Figure 19, the final scheme shares the digital-on-top approach with the AMS scheme, allowing for the complete compatibility of simulation features. The transition from one environment to the other is easy, straightforward, and more reliable.

4.4. Interchangeability of the Environments

The tools allow for the easy replacement of alternative “views” for subcircuits (analog or digital model); using the configuration file vcsAD.init, it is possible to choose according to the specific needs of each simulation, as follows:

• use_spice -cell top_analog for transistor-level topview
• use_verilog -module chargepump.sv for System Verilog model
• use_verilog -module oscillator.sv for System Verilog model

Therefore, tuning the trade-off between accuracy and performance is just a matter of simulation purpose. Usually, the verification environments are kept separated and run in sequence: first, the large number of mixed-mode simulations, then the smaller quantity of fully analog ones. Fully digital simulations are not normally run by analog designers and are made available just for quick checks or verification of the behavioral model coherence.

4.5. Selection Criteria

The choice is based on experience as well as coverage requirements; as an example, an operation of programming a word in the NVM array can be performed in a large variety of parameter combinations, such as address (row/column) of the word, previous content, programming efficiency, voltage levels, and pulse duration.

Therefore, what normally happens is that, starting from a verification plan which may include several hundreds (or more) of different digital simulation patterns, a subset is selected to run the mixed-mode simulations (usually in the range of 150–200 for NVMs), and then, a shorter list (from 20 to 40) is chosen for fully analog simulations.

In a fully digital environment, it is feasible to test most combinations (including the ones which are properly modeled for analog behaviors), checking the effect of the parameters on the simulation’s outcome.

In a mixed-mode environment instead, a limited number of sample cases is used (e.g., min. and max. voltage level, extreme PVT corners, with cells that require more attempts to be programmed, and so on); this is obviously due to the duration of each simulation, which may range from hours to 1 or 2 days. Other kinds of more complex simulations, like the erasing of a page, will often need up to 3–4 weeks to be completed.

Finally, in a fully analog testbench, the list of simulations is shortened to the typical functionality cases and some worst cases, such as highest consumption or slowest reading access. The duration of a full-transistor simulation is up to >2X the equivalent AMS one.

5. Stimuli and Testbenches Generation Methods

AMS simulations are mainly used to find issues that are not detectable when using digital simulations: mostly, such issues can be related to analog circuits that are not properly modeled in fully digital simulations. Digital simulations, on the other hand, are thousands of times faster than AMS simulations; therefore, they can perform huge numbers of basic operations, playing with randomness in operation sequences, addresses, and data, exploring all possible features in the device under test (DUT) and aiming to achieve the best verification coverage.

It is impractical to run the same testbenches used in digital simulations for AMS simulations; therefore, AMS testbenches are generally quite different from the ones used for digital simulations. However, some common libraries can be shared for the basic procedures, when developing testbenches for digital and AMS simulations; indeed, the signal sequences sent to the devices, as well as the signal setup and hold with respect to the clocks, are the same in both the analog and digital environments.

This gives the advantage that the basic operations are performed using the same elementary bricks. Moreover, if the same procedures are shared between the two environments, the update and maintenance are faster and safer.

Our testbenches for AMS are built using those common libraries: in some cases, the mixed-signal testbench can simply be a lighter version of the digital one (e.g., by reducing the loop number parameter from thousands to one or two).

Two main scenarios have been explored and implemented: one is based on the interactive shell of VCS digital simulator, ucli (which is a tcl shell), and the other one is based on a fully Verilog/System Verilog-based environment.

5.1. Interactive Approach

This approach has been widely used for several years, and it is basically applied to the environment shown in Figure 16.

Testbenches are a collection of tcl files, which are, in general, labeled depending on the device function they are used to test, are sourced at VCS tcl-ucli interface, and reuse the basic libraries that implement the basic operations developed with the same tcl language.

The basic operations inside the libraries are, in general, parametric tcl procedures, such as the following:

proc prog_data { address data } {...}.

The tcl testbench can force digital inputs, read digital outputs, read analog inputs, and sample the internal signals in the design on both the analog and the digital side using the proper commands.

The capability of reading back the outputs and sniffing the internal signals provides the possibility of implementing automatic checks on both the analog and the digital side; since, in AMS simulation, the more time-consuming engine is the analog one, the overhead of such checks is negligible with respect to the overall simulation time, while being extremely efficient compared to direct visual checks by the user.

Another advantage of this approach is the capability of interactive debugging of the testbench itself, using the VCS tcl-ucli interface.

Using this approach, there is a great benefit in the speed of the AMS scheme, because the start-up phase (also known as power-on-reset, POR) can be executed only once and reused for the next simulations. When the analog voltages are ramping up at POR, the simulation can be very slow; moreover, during this phase, the memory trimmings and configurations are loaded as well, so skipping it in subsequent simulations greatly reduces the simulation time.

Sometimes, it is possible to face issues when specific tcl commands are customized for one digital simulator and not supported by another one. In this case, it is necessary to replace those commands by hand-adapting the syntax, which is a nuisance.

5.2. Batch Approach

The complexity of NVM memory designs is continuously growing: an alternative methodology to the interactive approach is provided by testbenches written in Verilog/System Verilog languages. System Verilog also offers a more accurate style for modeling, and stimuli sequences are more readable and reusable. In addition, associative arrays, assertions/checkers, and concurrency provide an added value in terms of quality and compatibility [6].

It is not the scope of this article to go into detail about Verilog and System/Verilog capabilities: it is enough to mention that the approach has been used for digital full-chip and AMS environments in 18 nm technology.

An additional Verilog testbench level must be added, which encloses the TOP_VERILOG that becomes the DUT, as shown in Figure 20. This time, AMS verifications are run in the Synopsys XA-VCS environment, while fully digital verifications make use of the Cadence simulation tool.

Although the two environments are different, the testbench structures are shared between fully digital top simulations and AMS simulations: only the core code of the testbench needs to be modified by limiting the number of the DUT input sequences, in order to have a reasonable duration of AMS simulations.

Also, in this approach, a collection of elementary procedures/commands has been developed to perform the basic operations; as an example, a Verilog task could be as follows:

function [31:0] get_configuration;

input [17:0] conf_add;

begin

{…}

get_configuration = read_data;

end

endfunction

All the tasks are, in general, placed in a specific file or package which is included or declared using the include or import directives.

Thanks to the concurrency, it is easy to parallelize and build more complex stimuli with an enhanced ease of use.

The same System Verilog assertions used for digital full-chip simulations can be reused in the AMS digital side, improving the quality of simulations without affecting the simulation runtime. In addition, other assertions can be built for the analog side of AMS using the real numbers features that have been introduced in System Verilog.

When writing assertions or checks on signals, it is recommended to use (when possible) not internal block signals but internal pins, to be sure that the name is also preserved in the gate-level netlist; this allows for the reusability of the assertion/check approach for back-annotated AMS simulations which use SDF files.

One major difference with respect to the interactive approach is that Verilog/System Verilog testbenches are run in batch mode (compiled first, then executed) so the user loses interactivity with the simulator, which is very useful in the early debug phase.

6. Conclusions

As can be seen from the common Verilog top presented in Section 4, from an external point of view, all the verification environments look the same: they have the same pinout and internal structures, which, whether digital or analog, generate the same outputs after the same input sequences.

In other words, there is a smooth and seamless transition from fully digital simulations (RTL logic + BEH analog), through mixed-mode ones (RTL logic + SPICE analog), to fully analog verifications (wherein everything is transistor-level).

This allows for the efficient and flexible reuse of input stimuli and other required files (e.g., array contents, configurations, and output checks).

By keeping most environment features in common, verification designers can easily exchange data, stimuli, and results, thus enhancing debug capabilities and reducing simulation time. The comparison between behavioral models and their analog counterparts is also easily achieved for the easier debug and maintenance of the models themselves.

The presented approach has been adopted for the last decade on tens of projects in different technology nodes with very good results and is currently under continuous evolution and enhancement.