Recommendations for Increasing Accuracy of

Analog Mixed Signal Simulations by Minimizing

Interface Dependencies

Karin Mehlqvist (Broadcom, San Diego)

JF (Jianfeng) Shi (Broadcom, San Diego)
www.broadcom.com

Vijay Akkaraju (Synopsys, Mountain View)

www.synopsys.com

ABSTRACT

This paper provides a recommended methodology for increasing simulation accuracy within
an Analog Mixed-Signal (AMS) flow by removing approximations of signal magnitude that
transition between analog and digital domains. Mixed signal simulations involve a handshake
between SPICE and Verilog simulators wherein the data-path transition converts a
continuous signal in a SPICE netlist to a discrete representation of Verilog. This conversion is
based on multiple signal settings, that either results in a loss of data or an approximate
reproduction after the domain transition. This approach can potentially result in design bugs
slipping undetected through the verification process. The paper presents a technique that
describes accuracy loss avoidance by the direct polling and driving of signals, independent of
any interface settings. This procedure enabled us to introduce additional innovative concepts
such as dynamic temperature change midway through a simulation and the introduction of a
voltage and current source in digital top-level.
SNUG 2016

Page 2 Reference Flow Recommendations

SNUG 2016

Table of Contents
1. Introduction ........................................................................................................................................................................... 5
2. Design and Test Bench....................................................................................................................................................... 5
2.1 PMU Design.............................................................................................................................................................. 6
2.2 Temperature Sensitivity..................................................................................................................................... 6
3. Voltage and Current based interface elements ....................................................................................................... 7
3.1 Voltage Modeling................................................................................................................................................... 7
3.1.1 Drive and Release Voltage Value to SPICE Node .......................................................................... 7
3.1.2 Sample Voltage from SPICE Node....................................................................................................... 7
3.2 Current Modeling .................................................................................................................................................. 8
3.2.1 Current Load ............................................................................................................................................... 8
3.2.2 Current Measurements ........................................................................................................................... 8
4. Testbench and Testcase Coding ..................................................................................................................................... 9
4.1 UVM Interface pmu_if .......................................................................................................................................... 9
4.2 UVM Interface and snps_force_volt.............................................................................................................. 10
5. Dynamic Temperature Control and Current Sensitive Digital Testbench................................................. 11
5.1 Temperaure Control Implementation ........................................................................................................ 11
5.2 Current Load ......................................................................................................................................................... 12
5.2.1 Dynamic Current load ........................................................................................................................... 12
5.3 Measuring Currents with snsp_get_port_current .................................................................................. 14
6. Results and Conclusions from using XA 2015.06-SP4 ....................................................................................... 15
6.1 Challenges .............................................................................................................................................................. 15
6.2 Results ..................................................................................................................................................................... 15
6.3 Conclusions............................................................................................................................................................ 16
7. Future work ........................................................................................................................................................................ 17
8. Acknowledgements .......................................................................................................................................................... 17
9. References ........................................................................................................................................................................... 17

Table of Figures
Figure 1: UVM SoC Test Bench ........................................................................................................................................... 6
Figure 2: Topology Signal Propagation While Driving a SPICE Node ................................................................ 7
Figure 3: Topology Signal Propagation While Sampling a SPICE Node ............................................................ 8
Figure 4: PMU Subsystem .................................................................................................................................................. 13
Figure 5: vdd Decay .............................................................................................................................................................. 13

Page 3 Reference Flow Recommendations

SNUG 2016

Figure 6: Current Measurement point .......................................................................................................................... 14

Table of Tables
Table 1: PMU Interface Signals .......................................................................................................................................... 9

Page 4 Reference Flow Recommendations

SNUG 2016

1. Introduction
Analog and mixed-signal circuits in wireless connectivity designs[2] present many design
verification challenges where typical AMS flows are not easily usable. Challenges like signal
sensitivity and accuracy within individual design blocks (like the Power Management Unit, PMU).
The PMU introduces many scenarios where signal behavior must be modeled with SPICE-like
accuracy, but functionality and implementation involves control signals that originate in a Verilog
Register Transfer Level, RTL. Scenario examples include cases where state machines of the digital
controller frequently contain discrete state transitions that are synchronous to a high-speed clock.
These output signals act like triggers to PMU block operations, impacting power down and power up
sequences of all devices downstream to the PMU. Specifically, discrete transitions of the digital
control signals introduce fluctuations and instability for the current loads. In previous design
versions the issue was addressed by modeling voltage and current sources in the SPICE netlist. This
added more complexity in the portion of the design (analog circuits) that has longer simulation
times and a more complex flow that would simulate corner cases for functional verification. This
complexity also became a schedule bottleneck as accurate SPICE netlists are not available until
much later in the design cycle and digital verification is incomplete as simulations use models only
and not the actual analog design netlist (the SPICE netlist).
Another engineering modeling issue occurs when SPICE is associated with test cases that target
temperature-dependent performance scenarios. Specifically, PMU sensitivity requires adjusting the
temperature midway through a simulation. This introduces a variable interface element (an
independent flow) that is an important component in the test case.
As designs increase in complexity at 28 nm and smaller geometries, the above mentioned
challenges have an exponentially higher impact on design schedules and time-to-market
requirements of the silicon. There is now substantiated recognition that much more Analog Centric
functionality be introduced in the simpler simulation environment associated with digital coding.
This paper also describes approaches where digital abstraction of analog behavior is achieved by a
methodology that leverages software PLI handshakes that can be implemented on the Verilog and
SPICE simulator handshake boundary. Specifically, instead of establishing settings that create
markers during the signal hand-off on the boundary of two software programs, we apply a PLI
function. This ensures that changes to variables (on the Verilog side) are directly abstracted to
nodes on the SPICE netlist. In this way, there are no approximations required in either signal
propagation direction.
To summarize the sections within the paper:
Section 2 describes the target design and verification environment.
Section 3 provides information on the PLI implementation.
Section 4 covers the changes required in the digital portion of the environment (Verilog) to
ensure that we can use the new PLI architecture.
Section 5 addresses solutions and the engineering challenges of dynamic temperature
change and PMU current sensitivity.
Section 6 presents results and recommendations.

2. Design and Test Bench

The primary focus of the AMS simulation accuracy effort is the PMU inside a System on a Chip
(SoC). SoC verification testing includes the use of a UVM test bench and a test regression process

Page 5 Reference Flow Recommendations

SNUG 2016

with high functional coverage as well as code coverage for each sub-circuit in the SoC. The PMU is
represented as a behavioral model in a normal RTL regression cycle.
During the AMS simulation, this PMU behavioral model is replaced by a pre-layout SPICE netlist.
The scope of AMS simulations is to achieve 100% toggle coverage for the analog/digital PMU
boundary. A subset of tests from the RTL regression constitutes the AMS regression process. These
tests are identified to provide the expected 100% toggle coverage of the PMU.
In the UVM test bench shown in Figure 1: UVM SoC Test Bench, the PMU signals are controlled and
monitored using a defined interface.

Figure 1: UVM SoC Test Bench

2.1 PMU Design

The PMU features multiple supply inputs and several Low Dropout (LDO) regulators all assigned to
different voltage domains. The PMU also has both a voltage monitor and a temperature monitor and
bias current outputs. The AMS regression addresses varying supply voltages and applies glitches on
supply lines and dynamically changes the PMU temperatures. To accurately simulate start-up and
shut down scenarios, dynamic current loads must be introduced.

2.2 Temperature Sensitivity

The PMU is highly sensitive to the variable influence of temperature. To examine the impact of
temperature and implement authenticated testing within the temperature monitor, the
temperature must be varied during verification. Several AMS regression tests were designed to
validate the PMUs temperature behavior. For the PMU model, the temperature is set using a real
variable (TEMP) inside the model. Forcing this real variable from the test bench changes the
models behavior based on the temperature set in TEMP.
The temperature tests dynamically change TEMP during the simulation, while monitoring specific
outputs that are temperature sensitive.

Page 6 Reference Flow Recommendations

SNUG 2016

In AMS simulations, the PMU temperature is defined in the PMU SPICE netlist. To vary the
temperature dynamically means re-loading the netlist with a different temperature setting. In
collaboration with Synopsys a new flow was developed to implement this approach and conduct
the temperature tests in our AMS regression. Although no tool enhancements were needed, the flow
did use the simulation software in a new and innovative way. The solution is described in more
detail in Section5.

3. Voltage and Current based interface elements

3.1 Voltage Modeling
3.1.1 Drive and Release Voltage Value to SPICE Node
PLIs were implemented such that internal analog nodes are accessible to Verilog as real variable
values, shown in Figure 2: Topology Signal Propagation While Driving a SPICE Node. Access is
provided via calls to Verilog system tasks or system functions as described in the coding snippet
below. Specifically, the focus is to ensure consistent coding using Verilog force and release
commands.

$snps_force_volt(analog_node, voltage)
$snps_release_volt(analog_node)

SPICE or
SystemVerilog r2e Verilog-AMS
real Electrical
Figure 2: Topology Signal Propagation While Driving a SPICE Node

Implementation of the force PLIs results in an insertion of an ideal voltage source marker on the
handoff boundary to the SPICE simulator. This ensures a time range that is equivalent to the
simulation time at which the release is placed. The value of the voltage changes only if there is an
additional PLI usage with a different voltage argument. If the node argument is connected to an
ideal voltage source, then this system task overrides the ideal voltage source. The value of the
voltage can be a numerical value as well as a variable (assigned to Verilog real type)

$snps_force_volt (top.xpmu.xvcell.p1, 2.1);

or

real rVar = 2.1;

$snps_force_volt (top.xpmu.xvcell.p1, rVar);
3.1.2 Sample Voltage from SPICE Node
This PLI samples the analog nodes and is used on the right hand side (RHS) of an assignment
operator of a real variable.

Page 7 Reference Flow Recommendations

SNUG 2016

SPICE or
SystemVerilog e2r Verilog-AMS
real Electrical
Figure 3: Topology Signal Propagation While Sampling a SPICE Node

The most common coding abstractions, such as if statements and loops (while), can be introduced in
the usage of this sampling PLI, as shown in the below example:

Syntax
$snps_get_volt (analog_node_name)
Examples
Real rVar;
rVar = $snps_get_volt(top.xpmu.xvcell.p1);
if($snps_get_volt(top.xpmu.xvcell.p1> 2.5)

else

end

3.2 Current Modeling

3.2.1 Current Load
The PMU behavioral model formulates the timing based on a typical current profile during start up
and shut down of the block. When running AMS and replacing the PMU model with the SPICE
netlist, it became evident that to achieve the expected timing, a current source was required. With
the alternative AMS timing of the AMS-versus-model simulation, timing assertions were failing
during AMS simulation. Importantly, and for the purposes of AMS simulation, the SPICE netlist used
for verification contained a constant current source. This approach has the downside of:
1) Requiring that a unique AMS netlist be created. This inflexibility creates the clear potential
for errors.
2) Since the current is constant throughout the simulation, this does not simulate an authentic
condition for the SoC.
The ideal solution would be to maintain a current source that can be dynamically controlled from
the test bench. This is very similar to the Synopsys task: snps_force_volt but since the approach
required a constant current source from digital top, an alternate PLI was needed to implemented,
with a current signal as its output. How this was achieved is described in greater detail in Section
5.2 5.
3.2.2 Current Measurements
There was also a requirement to measure leakage current after the PMU shuts down, specifically,
when the LDO voltage has ramped down the current leakage on the PMU supply has to be within a
certain spec. This scenario was addressed using a UVM test case, where a current measuring XMR
PLI ($snps_get_port_current ) is used to capture the current values and the resulting
measurement value triggers check condition for test case to pass/fail. This scenario can only be
implemented in the Mixed-Signal environment as there are no corresponding current value
abstractions in the PMU model as well as there are no variables/signals form the pmu_if to reuse.
The testcase associated with this usage and the waveforms are described in section 5.3 .

Page 8 Reference Flow Recommendations

SNUG 2016

From a purely methodology point of view (independent of the current design), this approach of
current measuring, we feel can be used to measure leakage current in a SPICE netlist from Digital
top of the AMS environment.

4. Testbench and Testcase Coding

To achieve 100% toggle coverage for the PMU, the objective was to conduct the test cases using the
same process applied during the RTL regression. We sought minimal changes to the actual test
bench and UVM sequences. Some modifications were necessary for example when connecting the
pmu_if in the test bench top. For this purpose a define is used: AMS_SIM. Since the test cases are
continuously improved and modified, and used in multiple projects, we must avoid any duplication
of code. It was of critical importance to be able to use exactly the same tests for AMS and RTL
regressions with only command line additions such as +define+AMS_SIM added for AMS.

4.1 UVM Interface pmu_if

The PMU is controlled and monitored in the test bench via a virtual interface: pmu_if. This
interface is connected to in the bench top. The connections are different in the AMS simulation as
compared to the normal RTL simulation using the PMU Verilog model.

A summary of the most important interface signals and descriptions of how they are used in the
RTL simulation versus the AMS simulation is shown in Table 1: PMU Interface Signals.

Table 1: PMU Interface Signals

Signal Name Connection RTL Connection AMS

force_pmu_volt Not used Signal used to trigger force
from the test bench top.
real_volt_value Connected to a real variable Real variable [V] used as input
inside the PMU Verilog model. argument to snps_force_volt.
Controls LDO output values or
supply input values.
force_pmu_temp Not used Signal used to trigger
temperature change = re-read
of the netlist. Connected to the
signal in the test bench top.
real_temp_val Connected to real variable Real variable [deg C] used by
inside PMU Verilog model. the tcl script to change the
Controls temperature of the temperature in the SPICE
PMU. netlist. Connected to a signal in
the test bench top.
force_pmu_current Not used Signal used to trigger change of
PMU sink current during
power-up or power down.

Page 9 Reference Flow Recommendations

SNUG 2016

real_current_value Not used Real variable [A] used by the

snps_inject_current task.

4.2 UVM Interface and snps_force_volt

Simulating glitches on the power lines to and from the PMU is an integral aspect of the PMU test
coverage. When using the RTL test bench, the PMU Verilog model voltage values for each LDO, and
the voltage supply values, are controlled by real variables inside the model. A voltage glitch can be
applied by controlling these variables from the test bench via the PMU interface. For AMS
simulations, the glitch was accomplished by using the snps_force_volt command directly on the
PMU pins.
The snps_force_volt command uses hierarchal paths as one of the arguments. Hierarchal paths are
not permitted in a UVM sequence. Instead, the force command was applied from the test bench top
using the virtual interface signals as the trigger to control when to force and when to release.
The force signal is part of the PMU interfaces and is controlled in the UVM sequence. For RTL
simulation, the interface is linked up to real values inside the model. However, in the AMS
simulation, this connection does not exist.

Page 10 Reference Flow Recommendations

SNUG 2016

Instead, the interface signals are used in the test bench as follows:
Code snippet from test bench:

`ifdef AMS_SIM
always @(posedge pmu_if.force_pmu_volt) begin
$snps_force_volt(`DUT.u_pmu.i_supply, pmu_if.real_volt_value );
end
always @(negedge pmu_if.force_pmu_volt) begin
$snps_release_volt(`DUT.u_pmu.i_supply );
end
`endif

5. Dynamic Temperature Control and Current Sensitive Digital Testbench

5.1 Temperaure Control Implementation
As mentioned in Section 2.2 the temperature for a SPICE simulation is set in the netlist. Change of
the temperature during a simulation requires:
Stop of simulation.
Re-read of the netlist with a new temperature.
Re-start of simulation from the stop point.
This method is supported by the ace reread command [1] and was implemented as follows:
1. Remove the temperature setting from the SPICE netlist and add it to a separate file tfile.inc.
This file contains the temperature syntax:
simulatorOptions options temp=25.0
Include this file in the netlist.
2. Create a script settemp that takes the temperature as an argument and can re-create the
tfile.inc with a new temperature value:
rm rf tfile.inc
echo simulatorOptions options temp=$1 >> tfile.inc
3. The re-read of the netlist is done using a tcl script. Create a tcl script that will:
a. Stop the simulation for a defined condition. In this case the force_temp signal from
the pmu_if.
b. Get the temperature value from the test bench. In this case the real_temp_val
variable in the pmu_if
c. Call settemp $myval
d. Re-start the simulation

4. The -ucli -do temp_change.do parameters instruct the Synopsys Unified Command Line
Interface to execute the temp_change.do tcl script at the beginning of the VCS simulation.
Add ucli do temp_change.do to the command line for any tests where the
temperature is changed during the simulation.
The tcl script temp_change.do is as follows:

Page 11 Reference Flow Recommendations

SNUG 2016

stop condition {tb_top.force_temp == 1b1} continue command {set

myval [get tb_top. real_temp_val]; exec settemp $myval; ace reread }
run

5.2 Current Load

The PMU supplies downstream blocks in the SoC with supply voltages and bias currents. The SoC
operates in multiple modes that all have different PMU current loads. In the real world, the current
load dynamically fluctuates due to the different modes of SoC operation. In AMS simulation, the
current load is the core area of interest during power up and power down cycles.
The PMU netlist used for AMS simulation has additional external capacitance on some of the supply
power lines. With zero current load added to the PMU, these capacitances will not discharge during
power down, as this may indicate incorrect behavior. With excessive current load, the discharge in
these capacitors will be too fast, and with insufficient current loads, the discharge will be too slow.
This adversely impacts digital timing.
Our first attempt at simulating the current load in the AMS with minimal edits to the SPICE netlist
was to add a constant current source to the SPICE netlist. This approach was successful, but since
the current load was constant during the simulation, the power down timing was not as expected.
5.2.1 Dynamic Current load
An example of a sub circuit that is especially sensitive to this type of timing challenge during power
down is EFLASH. To protect the EFLASH, there are specified power-down signals from the PMU to
the EFLASH that are triggered when the LDO output of the PMU reaches a certain threshold value. If
the timing of these signals, together with the supply lines, does not meet the anticipated timing
requirements of the EFLASH assertions, then the test will fail.
With the use of synopsys tasks snps_inject_current() we could successfully simulate a
power up and power down of the PMU with the correct timing. The current is injected from the test
bench top using trigger signals from the sequence or other digital signals.

Page 12 Reference Flow Recommendations

SNUG 2016

System level connectivity of the PMU sub-system is shown in Error! Reference source not
found.Subsystem.

Figure 4: PMU Subsystem

The LDO outputs in the above sub-system are low impedance ports. In order not to load the LDO,
there is a requirement that the current source be of high impedance. Specifically, it was important
for the vdd_sw signal decay rate after shutdown be such that the timing delays on the load are
accurate. Having a decay rate that is too quick or too slow can cause incorrect behavior.
In Error! Reference source not found., the middle ramp is the target slope for the vdd_sw signal.

Figure 5: vdd Decay

One method to achieve this goal is to insert very accurate current loading at specified times. Since
we were working within a Digital Top framework, driving the current from the digital testbench

Page 13 Reference Flow Recommendations

SNUG 2016

was required. The PLI that supports such functionality not only necessitates a SPICE node and
current value but also a signal rise time that corresponds to the slope. Thus, the syntax of the PLI is:
snps_inject_current (<SPICE node>, <current value>, <rise time>)
The below code snippet effectively captures the expected behavior:
$snps_inject_current(top.i1.n1, 10.0e-3, 5.0e-9);
#5 $snps_inject_current(top.i1.n1, 20.0e-3, 5.0e-9);
#5 $snps_inject_current(top.i1.n1, 30.0e-3, 5.0e-9);
The current commences at 10 mA. At 20 ns, it starts to transition to 20 mA. It takes 5 ns to arrive
and it then starts a second transition to 30 mA with a rise time of 5 ns. Such a usage fits with the
expectation of a y = mx + b equation to have a legal slope of m values.
The only limitation within the above flow is the requirement of knowing when the current needs to
applied to the SPICE node. If that time value is unclear, but slow ramp behavior is still expected,
then an alternative PLI is implemented where the ramp gradient is the argument instead of rise
time. The units of this argument will be amps/sec. The above code will change to just one line, with
ramp time being based on a 10 mA change in value with 5 ns. In terms of amps/second, this will be
2.0e-6. Since the arguments are different, a new PLI would need to be implemented.

This is defined as follows:

snps_inject_current_ramp (<SPICE node>, <current value>, <ramp slope>)
The code snippet would simplify to:
$snps_inject_current_ramp(top.i1.n1, 10.0e-3, 2.0e-6);

5.3 Measuring Currents with snsp_get_port_current

The waveform figure below Error! Reference source not found. shows the voltage decay and the
current profile over 3 measurement point. The point of interest is the marker to the right. This PLI
was used the same way as the $snps_get_volt but this time an event in the UVM sequence was
used to trigger the measurement.

Page 14 Reference Flow Recommendations

SNUG 2016

Figure 6: Current Measurement point

6. Results and Conclusions from using XA 2015.06-SP4

The visible advantage of being able to co-simulate the analog netlist together with the digital design
in a UVM test bench provides comprehensive transistor-level verification for tapeout sign off. The
AMS simulation performance was less than two times the simulation period we typically experience
during RTL simulation. A typical PMU test that exercise start-up and shut down of the PMU takes
about 30 min to run in RTL and it typically took 50 min in AMS.

6.1 Challenges
Due to the nature of the design, we decided to achieve a more precise analog value by selecting a
higher tolerance than the default setting. Initially, we experimented with different tool accuracy
settings and devised an ideal setup that gave us acceptable performance and improved accuracy.
Another area that proved to be challenging was how to configure the vcsAD.init file to get the
desired PMU behavior. In the design we have analog nets connected or sometimes disconnected
through switches where wed like to see hi_z when the net is not driven to avoid getting X
propagation in the digital environment. Other nets exist where we dont want to see hi_z but always
a defined digital 1 or 0. This is all configurable and takes some collaboration between the
verification engineer and the analog designer.
There is also a loop-back analog net that is both an input to the PMU, and output from the PMU and
an input to the digital core. These special cases need to be handled with attention to the details
since a mistake here can lead to the wrong behavior or missed accuracy from interface elements
created where there shouldnt be any.
A lesson learned is to always carefully review the interface element report.

Page 15 Reference Flow Recommendations

SNUG 2016

6.2 Results
Over the course of the project we ran over 20 PMU test cases in AMS. Using the UVM random test
bench each simulation simulated a slightly different scenario. In total the full regression was run
over 40 times. This should be compared with the previous method used for analog mixed signal
simulation where a few test was run once with no randomization. This was more of a sanity check
than functional verification. The old method for PMU analog mixed signal simulation was done as a
pure PMU block level SPICE simulation where the stimulus from the digital core was dumped from
the UVM test bench and then translated to a SPICE simulator format.
This was a time consuming approach that not only gave long simulation times but also involved
several steps of transferring the PMU stimuli from one verification environment to another.
With the AMS approach we get a full functional verification of the SPICE representation of the PMU
in the digital design environment.
The results from the AMS simulations are:
A 100% passing regression with 100% toggle coverage for the PMU.
Minimal changes to test cases/test bench. Example is the use of the pmu_if explained in
section 4.
No added current source to the netlist as current load is controlled from the test bench.
Successfully running test cases that dynamically change the temperature of the PMU during
simulation.
Using the $snps_force_volt task enabled us to simulate voltage glitches on power lines in a
true analog way controlled from a digital test bench.
Identification of model inaccuracies where model and test cases required updates.
Identification of corner cases that were not simulated in pure analog SPICE, along with the
discovery of interesting results. An example is a change of a trim value from one end point
to another. This is not an expected use case but still allowed. In the AMS simulation we saw
an unexpected current glitch when changing the trim value between the end points.

6.3 Conclusions
Initially we experienced failures in several of the test cases when running AMS. The anticipated
output voltage values or threshold values used for the Verilog model did not correspond to the PMU
behavior we obtained during the AMS simulations. All discrepancies were reported to the analog
design team. In most cases, the PMU model was incorrect and required an update.
The most significant advantage of running AMS on a UVM test bench is the insertion of a degree of
randomness being introduced into the test environment. This is a key comparative factor that a
pure analog SPICE simulation environment does not possess. The AMS regression was administered
multiple times and each time using a different seed.
Our findings demonstrate that it is important to add randomness to setup conditions for the PMU in
areas such as trim values, threshold values, clock frequencies, and so forth. By doing this, we
discovered corners that were not tested using the disciplines of pure analog SPICE simulation. We
did exercise traditional scenarios and additional real-world use cases. In one of the corner cases
examined, we encountered an unexpected outcome from the AMS simulation. This required a
comprehensive SPICE simulation of a specific corner case. Consequently, we ended up modifying
the PMU user guidelines.

To summarize:

Page 16 Reference Flow Recommendations

SNUG 2016

By introducing more analog centric functionalities such as:

dynamic temperature control
dynamic current control, and
application of voltage glitches on analog nets
in a digital simulation environment, we achieved a high accuracy analog simulation of the PMU. On
top of this we also get the additional benefits of a constraint-random UVM test bench. This gave us a
greater tape-out confidence and the AMS flow is now part of the verification sign-off.
Without the ability to change the current load dynamically during the simulation we faced the risk
of missing timing bugs/issues in the PMU. As mentioned before this is especially important when
simulation the power down of the EFLASH that has very strict timing requirements.
For the temperature simulations we had no way of testing the PMUs temperature monitor in AMS if
there wasnt the ability to change the temperature dynamically. Before this feature was supported
the only valid temperature monitor tests was done in pure analog simulations. This did not give us
the high verification coverage we targeted.

7. Future work
For the future project we plan on expanding the way we measure coverage for the PMU by creating
cover points for different voltage levels. By using Synopsys task $snps_get_volt() we can read
voltage values from the PMU and then connect them to cover points. Specifically we intend to use
System Verilog coverpoint [3] construct, which will allows digital verification concept of Functional
Coverage to be introduced to the AMS simulations. Since coverpoint in the current IEEE standard of
the language is limited to integers only, we are exploring the potential option of multiplying the
measured voltage values by three orders of magnitude (103) to get an integer that can be re-used as
a coverpoint.
Another area that we are exploring is running the PMU AMS tests with power intent information
defined in an Unified Power Format (UPF) file[3]. The initial focus will be to apply the power intent
policies, defined in the UPF file, to the digital controller logic that drives the SPICE netlist in the
design, followed options for driving the UPF from the SPICE netlist. Both of these approaches would
need Synopsys tool set (VCS and XA) to support the data paths involved (at the moment the support
is not clear).

8. Acknowledgements
The authors would like to acknowledge Amir Nilipour for his contribution to bring up of the Verdi-
AMS and VCS portion of the testbench. We are also grateful for the extensive support from
Synopsys David Cronauer for working with Synopsyss R&D in implementing several of the unique
technologies in the Current modeling area.

9. References
[1] Mixed-Signal Simulation User Guide, Synopsys, Version K-2015.06, June 2015
[2] https://www.broadcom.com/products/wireless-connectivity
[3] http://standards.ieee.org/findstds/standard/1801-2015.html

Page 17 Reference Flow Recommendations