Multi-Technology Simulation with Mixed Design Environments

Bin Wan1, Cindy Zhang2, Xingang Wang3

1
Skyworks Solutions, Inc., Woburn, Massachusetts, United States
2
Skyworks Solutions, Inc., Santa Clara, California, United States
3
Skyworks Solutions, Inc., Irvine, California, United States
bin.wan@skyworksinc.com ; cindy.zhang@skyworksinc.com ; xingang.wang@skyworksinc.com

Abstract circuits with multiple model and device definitions of the

same name. For example, if a device model is called
Typical circuit simulation flows within a design “nfet” in one process, and a different process has the
environment provided by electronic design same model name called “nfet”, this will cause a
automation (EDA) vendors only support a single problem for simulations. The same issue also exists for
foundry process technology node. But multi-chip Verilog-A module names.
modules (MCM) and 3D-IC designs are typically
done with multiple foundry process nodes, which To resolve this issue, SPICE-like simulators must parse
bring a challenge for the EDA industry on how to the netlist to localize the device model at the level in
simulate multiple dies with different technology nodes which it is being included. As of mid-2015, all major
analog/RF simulators have been enhanced to address
to capture interaction effects among various dies.
conflicts of model and/or Verilog-A module name
Although some EDA vendors have recently
definitions with multi-technology simulations1 by
introduced a Multi-Technology Simulation (MTS) implementing the localized scope netlist feature.
feature within their design tools, it is not easy for
designers to use and also does not work in cross 2.1 Spectre netlist with MTS Support
platform design environments. In this paper, we will
present an internally developed MTS methodology Cadence’s Spectre is an early simulator to support the
and utility that can work with both Cadence and MTS2 feature. Since Spectre has been used as a golden
Keysight ADS simulation environments based on our simulator by many foundries and design houses, its
Central Chip Repository methodology. The paper will syntax is considered to be a standard for the industry. We
also describe in detail the challenges of will use the Spectre netlist format to illustrate the local
multi-technology simulation and how to address these scope concept. In Spectre netlist format, any information
challenges. such as include and parameter statements defined inside
a subckt definition will be treated as local, and will not
1. Introduction be populated to the top level. This is the fundamental of
MTS – localization of models, temperature and design
Design Environments developed by EDA industry in the variables. Figure 1 shows the syntax format for a MTS
past only supported a single technology node. Therefore, block:
it was very challenging to simulate multiple foundry
process kits within the same design environment. Not
only should the simulator itself be able to address
netlist-level conflicts to have localized scope feature, the
design environment must also be able to recognize which
circuitry block is designed from which foundry process.
The EDA industry provided some solutions, such as the
Cadence ADE-GXL MTS option, to serve this purpose.
But they are quite difficult for designers to use, as they
require inclusion of multiple design kits and reference
libraries into a single environment. This use model
brings a major difficulty in terms of supporting it, and
also will cause some potential issues such as overwriting
callback functions in the design kits themselves. The
solution described in this paper will present a better
method to run MTS simulations within a single design
environment.
Figure 1. MTS Block Definition using Spectre Syntax
2. MTS Method Developed by EDA Industry
2.2 MTS Challenges with Single Design Environment
Traditional SPICE simulators will fail to simulate
Besides the simulators needed to support MTS, the

978-1-4799-8484-8/15/$31.00 ©2015 IEEE

netlister in a design environment also needs a feature to
netlist a subckt statement with a proper MTS block level
definition. Cadence’s Virtuoso Analog Design
Environment (ADE) has been widely used as an
interface to netlist schematic designs with supporting
simulators format3. Within ADE, users can set up the
models, choose various analyses, set up outputs, and plot
the results. With the release of IC6.1.X, the ADE GXL
offers the MTS option3,4, which allows users to select a
particular circuitry as a MTS block. However, Cadence’s
approach requires all referenced design kits to be defined
in the design environment. This causes three challenges:
1) cumbersome to use; 2) potential conflicts such as
overwriting callback functions; 3) not supporting MTS
simulations across different design environments. For
example, a SKILL callback function defined in one
design kit could be overwritten by another callback
function defined in a different design kit. This can cause
an incorrect netlist and produce wrong simulation
results.
There is no easy solution to address those challenges. So
far, the EDA industry has not delivered a comprehensive
solution. To address them, we developed a netlist based
on Central Chip Repository method to support MTS flow.
Details will be described in the following sections.
3. Skyworks Netlist-Based MTS Flow
Given the challenges of MTS flow within a single design
environment, we proposed and developed a new
methodology for MTS simulation based on netlist file
flow. MTS top level test bench in a design environment
will only contain one design kit, and the other design
blocks from different kits will be included as netlists.
3.1 Exporting Designs as a Netlist
One of benefits with the netlist based method is that it is
very portable, and can be used across design
environments. Since Spectre netlist format can be read
by most analog/RF simulators, we will netlist a chip
design as the Spectre format from Cadence ADE design
environment. To export a design as a netlist, users just
need to follow regular steps to netlist a design: 1) open
Cadence’s ADE, 2) setup design variables and model
include paths and 3) then create the netlist. This netlist
contains all hierarchical circuitry in the schematic that it
is netlisted from, plus additional simulation statements
coming from the design environment. This netlist will be
used as the base for MTS simulations.
3.2 MTS Netlist Parser
The Spectre netlist created by ADE netlister will be used
as an input to the MTS parser, which is developed with
features of supporting MTS syntax. One of key features
is to add subckt definition on top of the netlist to localize
model and circuitry definition, which is a must
requirement by MTS simulations. The parser also needs
to remove simulator options from the netlist created by
ADE. Since temperature in MCM module design could
be different with different die chips, we will keep the
temperature as a local option. The parser will also need
to handle a few other challenges: global nodes, include
files such as Verilog-A and S-parameter files, and design
variables.
3.2.1 Localized Global Node
One challenge with the MTS netlist parser is how to
netlist global nodes. By definition, global nodes are
virtually connected during simulation. However, in most
cases, the power, ground, and substrate nodes among
chips in MCM design are not directly connected. As a
result, we have to localize the global nodes of each chip
with unique names to distinguish them.
The solution to this is to simply append a prefix to those
global nodes. The prefix can typically be the chip name
or the process name, and we chose to use the process
name as the prefix.
3.2.2 Localize Include File
Many designs contain Verilog-A file to represent a logic
block and S-parameter files simulated from EM
simulations. Those include files in Spectre netlist will
become full, absolute path, which can cause an issue for
other design sites to access them. Hence, we need to
convert these absolute paths to relative paths to localize
them, and also copy those include files into a central
location where every design site can access.
3.2.3 Access Design Variables from Top-Level MTS
Design variables have been widely used to facilitate
tuning and sweeping in simulations. One issue is that
design variables defined inside subckt statements will
not be tunable from the top level. This is due to the
subckt statement localizing the design variable to be
accessible only within this subckt block. But very often
designers would like to sweep and tune design variables
from top-level MTS test bench to optimize designs.
The method we developed is that we will treat an
unassigned design variable in Cadence ADE to be as a
global variable, which needs to be defined at top-level
MTS test bench. Therefore, those global design variables
in ADE will be left as empty, unassigned status. The
MTS netlist parser will pick out these unassigned
variables, storing them into a particular file and into
Component Description Format (CDF) of the
Interoperable Netlist Include Component developed for
MTS simulations.
3.3 Schematic Symbol View Creation
A typical chip design can contain many terminals. In
order to wire it up to other designs, we need to create a
schematic symbol view to facilitate this task. The use of
symbol view will let designers seamlessly wire-up chip
blocks at MTS product-level test benches.
A schematic symbol is generally an independent object,
not associated with any design kit. It is simply a drawing
of graphics with pin placements. Assuming Cadence
Virtuoso Composer Schematic Editor has been used, we
can write out the schematic symbol as a Cadence SKILL
code, then load the SKILL code to re-generate the
symbol. Advantages of exporting the schematic symbol
as SKILL code are as below: First, a SKILL code is
portable across design platforms, which can be used for
both Cadence IC51 and IC61. Secondly, as we will
describe in the next section, the symbol view generated
by Skill code can be also interoperable with Keysight
ADS based on usage of Open-Access data base.
3.4 Example of MTS Netlist
The MTS netlist represents a “snapshot” of a chip design.
After parsing by the MTS parser, the output is a simple,
portable, and simulated-able netlist. The newly generated
netlist is independent of any design kit, and will be used
as the basis of Skyworks MTS Flow. Figure 2 shows an
example of the MTS netlist. The red highlighted lines
represented the changes we need to make from the
original netlist to support MTS syntax format.
Figure 2. Summary of Netlist Parsing
4. Skyworks MTS Flow with Central Chip
Repository Methodology
Once representation of chip design is created as a MTS
netlist, the next challenge is how to access it by a top
level MTS test bench. Since companies like Skyworks in
general have quite a few design sites at different
locations, we also need to develop an efficient method to
let MTS netlist with associated data be accessible by all
sites.
When we create the MTS netlist for a circuitry block, as
we described before, we also need to create several other
files such as Symbol view of Skill code, the localized
include files, and a list of global design variables. Those
files are needed for MTS simulations, and must be
accessible for a top level MTS test bench, which could
be located at a different design site. The Central Chip
Repository (CCR) methodology is developed to make
those files accessible by all sites. CCR area stores all
files needed for MTS simulations, and a GUI is also
developed to allow users to easily access those files.
Figure 3 indicates the overall multi-site MTS with CCR
flow:
Figure 3: Multi-Site MTS with CCR Flow
The CCR is a globally accessible space by all design
centers, and is controlled by a design management tool.
A typical MTS design flow is to have chip designers
write out the chip data (simulation files) to the CCR, and
then top level MTS designers import those chip data into
the master design environment for simulations.
5. InterOperable Design Environment for MTS
OpenAccess (OA) data base has become the standard for
EDA industry to develop their IC Design tools. Both
Cadence and Keysight use OA to develop their new
releases such as IC6.1.X and ADS 2012+, which means
in theory designs can be interoperable between Cadence
Virtuoso design environment with Keysight ADS, and
vice versa. Therefore, we leverage this interoperable
feature to access design data for MTS simulations across
those two environments.

5.1 Schematic View for MTS
The CCR stores the MTS netlist, symbol view and
simulation files. In order for MTS netlist to be
referenced by either Cadence ADE or ADS environment,
we need to create a schematic view. The schematic
contains pins to match with the symbol view pins, and
also places a customized netlistInclude block, which will
write out the full path of MTS netlist in the CCR as an
include statement. Inside this schematic view, there are
no design kit references, which can be interoperable
between Cadence and ADS design environment.
The interoperable netlistInclude block is developed as a
primary device to netlist MTS top-level block. The input
to this block is a netlist file name, and output will write
out an include statement with the full path of this file
location for MTS simulations.
Figure 4 below shows a sample MCM testbench with
three chips in ADS. Two of the chips are designed in
Cadence Environment but the symbol and MTS netlist in
imported into ADS from the CCR.
Figure 4. MCM Testbench with Multiple Chips in ADS
6. MTS Simulation Considerations
Major analog/RF simulators like Cadence Spectre,
Keysight ADS, Mentor Graphics Analog FastSpice (AFS)
are able to parse Spectre MTS netlist format to run
simulations. To run MTS simulations at a top-level
Module MCM design, it could take a very long time to
complete even a DC simulation due to complexity of
circuitry, which contains hundreds of thousands devices.
To reduce simulation run time, it is recommended to
write digital circuitry as Verilog or VerilogA modules to
speed up simulations. All three Analog/RF simulators
support VerilogA. However, Verilog code is only
supported by mixed signal simulator like Cadence AMS
Designer. The ability to run MTS with mixed signal
simulation is not explored at this time. We believe that
this will be the next step in enhancing the performance
of MTS.
7. Summary
We described the design methodology developed by
Skyworks to simulate multiple chips at MCM
product-level designs. The MTS flow is developed based
on representing the schematic design in a netlist format,
and storing netlists and supplemental simulation files in
a central location known as the CCR. Because the netlist
is based on text format, it can be used in mixed design
platforms between Cadence IC51/IC61. We also leverage
OA data base to make this flow become interoperable
between Cadence Virtuoso and ADS design
environments.
Acknowledgments
We would like to thank the Design Enablement Group in
Skyworks for their contributions to this work.
References
[1] B. Wan, X. Wang. Overview of commercially
available analog/RF simulation engines and
design environment. IEEE International
Conference on Solid-State and Integrated Circuit
Technology, October 2014.
[2] Cadence Mixed Signal Seminar on AMS
Simulation and Verification,
http://www.cadence.com/cadence/events/Documen
ts/EDA360SiliconRealization/AMS_Simulation_a
nd_Verification.pdf , Feburary 2011.
[3] Cadence Analog Design Environment L Datasheet
http://www.cadence.com/rl/Resources/datasheets/v
irtuoso_adeL_ds.pdf , 2015.
[4] Cadence ADE GXL Datasheet
http://www.cadence.com/rl/Resources/datasheets/v
irtuoso_adeGXL_ds.pdf , 2015.
[5] ADS 2015. 01 Product Release Overview,
http://www.keysight.com/en/pd-2486326/ads-2015
01?cc=US&lc=eng , Keysight, 2015.
[6] IBM PDKs support RFIC interoperability between
latest Keysight ADS software and Cadence
Virtuoso design platform,
http://www.semiconductor-today.com/news_items/
2015/apr/ibm_150415.shtml , April 15, 2015.