Spectre Tech Tips: Identifying and Resolving Spectre Accuracy Issues Caused by Multiple DC Solutions

17 Dec 2021 • 6 minute read

Simulation inaccuracies can be attributed to various reasons including wrong testcase setup, inappropriate simulation options, issues in simulation engines, wrong expectations and others. Experience shows that a significant number of accuracy issues are caused by the designs that have multiple DC solutions. This blog and the related application note illustrate the problem and describe how to identify and resolve such problems.

Introduction

Frequently, we receive queries related to the difference in the simulation results generated by Spectre^® X Simulator versus Spectre^® Accelerated Parallel Simulator, Spectre iterated EMIR versus direct EMIR analysis, or Spectre^® Circuit Simulator versus other simulators. In quite a few of these problem cases, we have identified that the root cause is the design that has multiple DC solutions.

If the design contains latches, memory cells, and other elements with memory effect, then it is important to properly initialize them. In most designs, there is a startup logic that initializes the circuit properly during the power-up or initialization phase. The initialization phase makes sure that before the first circuit operation happens, all cells with memory effect are initialized up to a unique and well-defined state. This initialization is not only important for cells with memory effects but also for analog cells with multiple possible states. For example, bandgap circuits requiring a startup circuitry or comparators with hysteresis.

Often, in circuit simulation, subblocks or cut-down circuits are simulated. Such cases may miss initialization circuitry or proper initialization, which may result in multiple possible states at time=0. Depending on the design, the difference in circuit state at time=0 may cause differences in the transient or other analysis behavior and these differences may be perceived as simulator accuracy problems.

For the identification of Spectre inaccuracies caused by multiple DC solutions, you can follow these steps:

Exclude incomplete DC solutions
Identify multiple DC solutions
Crosscheck operating point solutions

Excluding incomplete DC solutions requires checking the Spectre logfile to see whether the DC calculation converged fully or whether it exited early. The details for this step are described in the application note.

Identifying Multiple DC Solutions

Consider an example where simulation A provides accurate results and simulation B provides wrong results. If we suspect the problem may be caused by multiple DC solutions of the design, then the first step is to compare the DC operating point results between these two simulations. If not done yet, we need to write the operating point files using the Spectre write statement.

Simulation A: 
tr1 tran stop=1u write="simA.ic"
Simulation B:
tr1 tran stop=1u write="simB.ic"

We can use the spw utility provided in the Spectre installation to check the differences between the two operating point files.

spw ic --d simA.ic simB.ic

The results of this comparison may look like the following:

Golden file     Measured file   Quantity     Common     Equal      Diff      Displayed
-----------     -------------   --------     ------     -------    ----      ---------
simA.ic          simB.ic           V         817029     808007     9022      10
simA.ic          simB.ic           I         237        234        3          3

The example report shows that both IC files contain 817029 common nodes, 808007 nodes have the same voltage in both IC files, and 9022 nodes have different voltages. In addition, 3 currents out of 237 source element currents are different. The spw utility considers the results identical when the differences are below the default spw thresholds of reltol=1e-3, vabstol=1uV, and iabstol=1pA.

When node voltages are different, it does not necessarily mean that there is a problem of multiple DC solutions. There could be mV differences that are flagged by the default vabstol=1uV, but these are not real circuit state differences at time=0. Therefore, we need to check the report for the nodes that have the biggest voltage difference.

Quantity : V

+------------------------------------------------------------------+----------+-------------+----------+---------------+
| Name                                                             |   Golden |    Measured |     Diff |   RelDiff (%) |
+==================================================================+==========+=============+==========+===============+
| I0.node_a                                                        | 0.829527 | 9.63673e-05 | -0.82943 |       99.9884 |
+------------------------------------------------------------------+----------+-------------+----------+---------------+
| I0.node_b                                                        | 0.829527 | 9.63643e-05 | -0.82943 |       99.9884 |
+------------------------------------------------------------------+----------+-------------+----------+---------------+
| I0.node_c                                                        | 0.829527 | 9.62921e-05 | -0.82943 |       99.9884 |
+------------------------------------------------------------------+----------+-------------+----------+---------------+

In the above report, we observe that all the reported nodes have a 0.8V state in one IC file, but a 0V state in the other file. If the design has a power supply around 0.8V, it could mean that the nodes have multiple valid DC solutions (ground and vdd level), and the two simulations just happened to find different solutions.

Crosschecking Operating Point Solutions

Getting a different DC solution on some nodes may be caused by the design having multiple DC solutions for these nodes. However, it may also be caused by different DC algorithms used by the two simulators. To check this, we can crosscheck the operating point solutions.

First, we load the operating point file from simulation A into simulation B and check whether simulation B with the DC solution file from A provides correct results.

Simulation B: tr1 tran stop=1u readns="simA.ic"

Next, we load the operation point file from simulation B into simulation A and check whether it causes simulation A to deliver wrong results.

Simulation A: tr1 tran stop=1u readns="simB.ic"

If simulation A with simB.ic delivers wrong results and simulation B with simA.ic provides correct results, then we have proven that the different simulation results between A and B are caused by the design having multiple DC solutions.

Fixing the Multiple DC Problem

Multiple DC issues in a design need to be thoroughly analyzed by the designers of this block. Some problem nodes may need adjustments of the circuitry while others may be known to be caused only by the simplified simulation setup. For the latter, it is sufficient to properly initialize them with Spectre IC statements.

ic I0.nodeA=0.8 I0.node2=0.8 …

If the list of problem nodes is long and we already know which simulation provides the expected DC solution (simulation A in our example), we can use the operating point file of simulation A to enforce the same DC solution for all other simulations by using the readic statement.

Simulation B: tr1 tran stop=1u readic="simA.ic"
Simulation C: tr1 tran stop=1u readic="simA.ic"
…

This brute force solution will eliminate the impact of multiple DC solutions on the simulation accuracy, but it is only a workaround solution. It still requires the designer to fundamentally address the problem nodes.

Summary

In this blog, we discussed how to identify and fix Spectre inaccuracy issues caused by multiple DC solutions in a design. More details can be found in the related application note listed in the Related Resources section.

Stefan Wuensche

Related Resources

You may also contact your Cadence support AE for guidance.

For more information on Cadence products and services, visit www.cadence.com.

About Spectre Tech Tips

Spectre Tech Tips is a blog series aimed at exploring the capabilities and potential of Spectre^® circuit simulator. In addition to providing insight into the useful features and enhancements in Spectre, this series broadcasts the voice of different bloggers and experts, who share their knowledge and experience on all things related to Spectre.