2017 Austrochip Workshop on Microelectronics

Using Python tools to assist mixed-signal ASIC

design and verification methodologies
Evangelos Logaras Andreas Weitzer

NXP Semiconductors
BU Automotive, PL Secure Car Access
Gratkorn, Austria
Email: (evangelos.logaras, andreas.weitzer)@nxp.com
Abstract—We present a set of tools for digital design, in- have to be taken into account during functional simulation,
tegration and verification of mixed-signal Application Specific timing and power analysis.
Integrated Circuits (ASIC) developed within our design team.
We have chosen Python for the development of the tools. By Especially regarding analog modelling, the selection of the
drawing on Python’s features we have developed tools targeting proper A/D co-simulation environment may have a huge im-
many steps required across a design flow: a) Complex digital pact in terms of simulation time. Analog transistor-level mod-
blocks are auto-generated, where Python generates, according els, can be abstracted using behavioral models, e.g. Verilog-
to input files thousands of Register Transfer Level (RTL) lines AMS, significantly reducing simulation time. Special tools
of code. b) Using the tool a full RTL design hierarchy can must be used to ensure compatibility of the models to the
be parsed and using the extracted information a number of original transistor schematic of an analog block, otherwise
RTL and report files are generated, providing useful information
for RTL integration activities. c) Simulation related files and
the model replacement methodology can be error-prone and
especially IP-XACT models can be used in a Universal Verification introduce bugs in the implemented silicon.
Methodology (UVM) simulation environment to model digital Nowadays well established methodologies and tools exist,
blocks and accelerate verification activities. d) Back-end tools targeting mixed-signal IC design, provided from the main
support to define power constraints and analyze timing reports.
Electronic Design Automation (EDA) software vendors, like
Keywords—mixed-signal, ASIC, Python, design, verification, Cadence, Mentor Graphics and Synopsys. But the initial step
methodology from architectural/customer specification to system modelling
and also the selection of the proper tools and flows always
remains the responsibility of the design teams. Also a number
I. I NTRODUCTION of project-customized tools might be required to glue exist-
ing EDA vendor tools and flows or to fulfil special project
Mixed-signal Integrated Circuits (IC) design is an impor- requirements. Within our design team, while working for sev-
tant area of interest for the semiconductor industry, mainly eral mixed-signal ASIC design projects, targeting automotive
driven during the last two decades by the rise of mobile applications, we have developed a number of custom made
communications. High level of expertise is required to im- tools that help us implement some of the critical steps in a
plement on the same silicon die complex digital functionality mixed-signal ASIC design flow, as these presented in Figure
that interacts with power consuming analog blocks and may 1.
operate on frequencies higher than the Radio Frequency (RF)
band. Nowadays even pure digital ASICs may be considered The full flow starts from the architectural specifications and
as mixed-signal ICs [1], since they may contain frequency goes down to the generation of the required mask fabrication
or voltage analog regulation circuitry and related sensors to files. Steps supported by our custom made tools are highlighted
dynamically reduce power consumption. Many applications in gray color. In more detail, the supported steps are the
also benefit from the single analog/digital die implementation, following:
like automotive, telecommunications, consumer electronics etc. (a) Auto-generation of complex RTL blocks.
Many challenges arise when IC engineers have to handle (b) RTL integration support, where information is extracted
digital and analog blocks within the same chip, in terms of from the provided RTL netlist and a number of report files
design, verification, physical implementation and even post- are generated:
silicon lab validation. Different methodologies and flows used (i) design hierarchy report including all the instantiated
in either digital or analog design, must be merged into a blocks, both in text format and tree-like diagram
single design flow, that serves both worlds. A key factor is the format
modelling of the analog blocks [2] during simulation and how (ii) non-instantiated modules report
these models can be co-simulated with Hardware Description (iii) Lint design rule checks reports and RTL code profil-
Language (HDL) code (VHDL/Verilog) modelling the digital ing, e.g. number of comments lines etc.
blocks. In a simplified example, there are wires connected (iv) interface consistency checks report between digital
to both digital and analog blocks going to both directions, functional and Design for Test (DfT)/analog blocks
carrying digital or analog information. This Analog/Digital (v) Verilog testbench templates and I/O interface files.
(A/D) interface becomes another important aspect of the de- (c) Auto-generation of IP-XACT [3] and UVM models (com-
sign, where all the included wires coming from both directions patible to the Accelera standard) of the CPU registers, used

978-1-5386-3583-4/17 $31.00 © 2017 IEEE 41

DOI 10.1109/Austrochip.2017.17
 architectural specification and diagram reports). Integration problems have been observed
in previous designs, where time consuming RTL code reviews
were required to check proper signal connections. With our
system approach we do not try to replace well-established tools and
modelling methodologies, but rather present a way on how to develop and
Front-end

system integration use customized add-on tools on a mixed-signal ASIC design

RTL analog processor
flow, that speed up design and verification activities.
description models software
The rest of the paper is organized as follows: In Section II
we present some of the challenges of mixed-signal IC design
system verification and also provide an example of an ASIC design that has
been used as a test platform for our tools. We also refer to
timing power
earlier academic projects that used Python in hardware design
constraints constraints flows. In Sections III, IV and V we present in more detail
how the tools have been used during the four main supported
steps in the design flow, RTL design, system integration,
logic synthesis verification and back-end design, as these presented in Figure
1. In Section VI we summarize the capabilities of our tools
and their contribution to the mixed-signal ASIC design flow
Back-end

synthesized
netlist and briefly discuss our work in progress.

II. ASIC TEST DESIGN AND RELATED WORK

floorplan
A. Mixed-signal ASIC test design
In the past we conducted research on how to use Python
place & route to generate RTL code and simulate and facilitate high-level
functional verification of a System on Chip (SoC) design on
FPGA devices [5]. In our current work we developed a set of
timing analysis tools while working for a specific family of ASIC products
targeting the automotive industry. Within our tools we heavily
take advantage of Python’s features [6] to process flat data
files, like plain text and Comma Separated Value (CSV) files.
layout
masks On the other hand we try in our projects to include as much
of design and architectural specification information to be
Fig. 1. Mixed-signal ASIC design/implementation flow. expressed using flat data files, which are easy to be processed
in an automated way for a) generating design files or b) making
crosschecks among design files and generating reports, both in
to communicate with analog and digital peripheral blocks. an automated way.
Using the models, UVM verification register-driven tech- In Figure 2 a simplified block diagram is presented of an
niques are applied to the system during simulation. automotive related ASIC design that has been used as a test
(d) Back-end tools support for analyzing and converting large platform for our tools. The ASIC chip is used on electronic
timing report files to more compact and meaningful rep- boards inside a car. The design has a small digital part, mainly
resentation, easier to review and also auto-generation of controlled by a 16-bit Central Processing Unit (CPU) clocked
power constraints files in Common Power Format (CPF). at 32MHz. The digital part controls a number of four Low
For the development of this set of tools we have cho- Frequency (LF) transceivers and some ADC blocks, while also
sen Python, since this popular scripting language has many establishes a Serial Protocol Interface (SPI) communication
strengths in scanning and manipulating textual data, e.g. HDL with the main car controller and also provides a debug interface
files. Also Python during the last years emerged as one of port for software development. Key aspect of the design is data
the basic scripting tools in many Linux distributions. One exchange between the processor and the analog blocks. This is
of the main goals during the development of the tools was achieved through a number of peripheral registers used to send
that potential users do not have to know Python to use them, and receive data to and from the analog blocks respectively.
while the user interface includes configuration files, where An important block of the digital design is the functional
all the parameters of a design can be easily set (file paths, test block, which connects several digital wires, coming either
analysis options etc.) by the user prior to execution of the from the digital or the analog blocks, to four I/O pins, where
tools. Python code is also very easy to read, even from people the state of the wires can be observed or externally forced
without experience in Python coding, because the syntax of during post-silicon lab validation. Using the features of this
the language is very close to natural languages [4]. block, silicon lab validation of analog and digital blocks
The main purpose of the developed Python software was to becomes easier in terms of: a) observability of internal signals
automate critical steps of the design flow related to RTL block (e.g. timing characterization, threshold characterization, etc.) ,
integration and connection between the analog and the digital b) externally forcing the state of the chip (e.g. evaluation of
blocks and also provide different views of design reports (text protection features, external triggering of events, etc.).

42
 I/O pins
by Xilinx. A designer can develop a structural description by
analog blocks instantiating objects from a Python library. PyGen cannot be
RAM
16kB
ROM
64kB
functional
test logic
used to design custom logic, but provides a Python API that
ADC
handles at a high-level Xilinx proprietary cores.
car main
controller

A/D I/O portlist

DRV1
PyMTL [12] is Python related tool targeting digital hard-
SPI
16-bit Register
bank
DRV2 ware design by unifying functional, cycle-accurate and Reg-
CPU
debug
MDI ister Transfer Level (RTL) hardware descriptions. PyMTL can
interface DRV3
be used for behavioral and structural descriptions and also to
CPU DRV4 verify the functionality of a design. The tool also provides
timers
HDL generation features, by translating Python descriptions
to Verilog.

Fig. 2. Automotive mixed-signal IC top-level diagram. In summary we can say that although a lot of hardware
design related research work has been done using Python, the
majority of the developed tools targeted FPGA implementa-
While only four signals can be observed or forced in tions. Our approach tries for the first time to include Python
parallel, because of IC pin number limitations, the test block in many important steps of a mixed-signal ASIC design flow
implements a complex multiplexing structure, which allows and not just use Python as a set of stand alone small scripts
several groups of wires of similar functionality, to be connected used within the design environment.
to the block and through a selection logic connected to the four
I/O pins.
III. AUTO - GENERATION OF RTL CODE
All peripheral registers are included inside a register bank
container, which is wired to the analog blocks. All these wires As described in Section II, the functional test block is of
are part of the A/D port list I/O interface, which is defined by high importance in our mixed-signal design. This test related
the analog and digital architects of the project, using a single logic block supports lab validation of both analog and digital
CSV file. It is this CSV file that is being reused in several blocks as it provides access to internal nodes of the device that
steps of the project either to generate new front-end or back- otherwise may not be accessible in functional operation mode.
end related files or to make design consistency checks. The Observability of the whole system in functional application
CSV file defines: a) all analog/digital connected wire names, mode rather than test mode, in which analog and digital part of
b) power domain information for each connection and c) flags mixed signal blocks are usually validated stand-alone, is one of
if a wire should be connected to the functional test block or not. the major benefits. Checking the correct behavior and timing
As described in Section III, the complete Verilog description on the interfaces between analog and digital components of
of the functional test block is auto-generated using in Python mixed-signal blocks in application scenarios also enables chip
the A/D port list CSV file as an input. characterization activities which have to be documented in the
datasheet of the device. Finally, the functional test block also
becomes useful when debugging unexpected device behavior
B. Related work during operation and gives insights into the possible root cause
for failures.
Python has been used in the past to assist hardware design
flows. PyCells [7] are structures written in Python resembling The functional test logic is a fully combinational block,
parameterized analog or digital cells for ASIC design. The implementing a large structure of a multiplexer for signal
tool can be used for creating Universal OpenAccess PCells, observation and another one large demultiplexer for externally
which physically represents analog circuits in a transistor level forcing signals. Using the block more than 400 signals grouped
design. PyCell uses Python object-oriented features to define in more than 100 test groups can be forced or observed on the
the geometry of complex analog physical designs with more four related General Purpose Input Output (GPIO) pins.
compact and smaller descriptions, compared to the SKILL
language used in PCells. The PyCell architecture has already In Figure 3 a block diagram of the functional test block is
been adopted by leading EDA companies, like Cadence and presented. On the left side of the diagram the demultiplexer
Synopsys. structure can be seen, used to force any of the signals included
in the test groups. Force values are provided, through the GPIO
PyHDL [8] is a tool for structural descriptions which tried IC pins to “Input[3:0]” pins of the functional test block. On
to simplify system design with the use of optimized hardware the right side the multiplexing structure can be seen, used to
objects described in C++. PyHDL extends the functionality of observe any of the signal in the test groups and connect them
PAM-Blox [9] by creating a Python/C Application Program- to the GPIO pins. Current values of the observed signals are
ming Interface (API) so that a designer can have access to provided to the GPIO pins, through the “Output[3:0] output
the C++ libraries by using Python scripts. PAM-Blox has been pins of the test block. Each time a single group of four signals
developed in times when the capacity of FPGA devices was can be forced or observed using the GPIO pins, by writing the
very constrained, so it did not find many practical uses. proper group number value to “SignalGroupSel”. Each one of
PyGen [10] is an add-on tool for Matlab/Simulink for the signals within a group can be connected to any of the four
hardware design. PyGen maps Simulink’s hardware building available GPIO pins, by writing the correct value to “PinSel”
blocks to Python classes. Simulink handles hardware DSP signals. All selection related logic (group and pin selection)
blocks through System Generator [11], an add-on tool provided wires are controlled by software executed on the CPU. During

43
 on top of the database and generates the described report
and verification files. A configuration file is used to interface
the tool. The user needs to provide in the configuration file
the path of text file that contains the RTL file list and the
name of the top-level HDL module. Upon execution, the
tool follows the designs hierarchy and hops from file to
file to analyze the design. The extracted hierarchy and I/O
interface are stored in a flexible Python dictionary format. By
reading the dictionary keys, the extracted information is used
to generate the corresponding RTL related files and reports.
A flow diagram of the functionality of the integration tool is
presented in Figure 4. In the following paragraphs a description
of the generated files of the integration tool is provided.
RTL related files: To ease integration and verification
activities a Verilog testbench template is generated by the
tool for each HDL module identified in the design hierarchy.
The template contains the I/O of the related block and its
instantiation inside the testbench. A separate file including
the I/O interface of a block is also auto-generated. Both files
are automatically stored in the same folder where the RTL
description of the block exists.
Design hierarchy reports: According to the provided by
the user RTL file list and the analysis performed by the
integration tool, design HDL module hierarchy is provided in
Fig. 3. Functional test block diagram. text format and in schematic tree format. Both reports includes
all instantiated modules under each block. This report, either in
text or schematic format is very useful to easy identify which
lab validation the selection logic can be controlled through the block are already instantiated in a design. The tree schematic is
SPI interface or the MDI debug port as well. implemented using auto-generated Java script code compatible
The functional test block Verilog description is more than with Google charts. An example of the generated tree diagram
30,000 lines of code, so auto-generating the block using Python (please download and open the file using a browser) is provided
software, was the only and safest solution. The block was in [13].
generated many times during the project until the A/D port Non-instantiated modules report: A text format file is
list reached a golden maturity level. Each time the port list generated to report all the included HDL modules in the user-
changed, the description of the test block had to be regenerated. provided file list, which have not been instantiated in the
Except the generation of the Verilog description, a number of design, according to the extracted design hierarchy. This is
Verilog include files are also generated using Python, to ease a very useful report to identify which blocks have been left
connection and integration of the test block with the rest of out of the design either intentionally or by mistake.
the system.
Design rule check reports / RTL code profiling: Using
the Cadence HAL linting tool, we perform design rule checks
IV. S YSTEM INTEGRATION TOOLS on RTL description level. Lint related tools help designers
System integration is another challenging task, especially identify HDL coding errors early in the design process, be-
in a mixed-signal design environment, where analog functional fore verification phase. HAL can identify coding errors and
and macro models have to be used within the design, for improper RTL design styles through a comprehensive code
verification and silicon implementation respectively. The task analysis.
becomes even harder, when more than one teams work in In conjunction to the HAL reports, we also use Python
parallel for the implementation of the several Intellectual to analyze RTL code and identify the number of comments
Property (IP) cores (digital or analog) and all of them have to lines and number/percentage of Verilog and VHDL lines. This
be integrated in a single design, along with software executed is a useful, automated report, generated on a weekly base, to
on the processor of the system. check the progress of RTL code development.Both HAL and
A number of design analysis reports, in text and schematic code profiling report are generated Google chart Java script
format, are generated by our integration tool, that help the format. Especially for the HAL report, related RTL block name
digital designer and integrator to fix and improve the design is provided along with a short description of the identified
during the front-end design phase and in this way save project warning/error. An example of the generated HAL/RTL analysis
time in contrast to find design bugs in later phases of the flow. report (please download and open the file using a browser) is
Also RTL related files are generated, to ease integration and provided in [13].
verification of a specific block. Datapath connectivity checking: By analyzing all the
The initial goal was to develop a tool that could be easily RTL files in a design, our tool is able to extract all the I/O and
used along with any existing RTL database. The tool runs internal wire names of each instantiated block. Our intention

44
 analog blocks
config. Watchdog
file
ADC
top

Peripheral bus
RTL
DRV1
16-bit Register
CPU bank DRV2

RTL RTL RTL RTL DRV3

front door
access

back door
#1 #2 #3 #4

access
DRV4
UVM
System
register
Verilog
models Interrupt GPIO
testbench
ctr. ctr.

Fig. 5. Front/back door register access in UVM verification.

RTL #x
tool folder
Obviously front door access better simulates the system be-
cause a register access is accomplished in the same way the
RTL tb netlist reports
CPU does it, while back door access is faster and can be used
during earlier phases in the development of the verification
{
{
environment.
design non-inst.
Verilog Verilog
hierachy. modules
Because of legacy tools used along with our CPU IP core,
testbench interface
the names and the properties of the registers (length access
policy etc.) are defined using C-like syntax. In order though
to create models of the registers in SystemVerilog for the UVM
Lint RTL
checks/
connect. verification environment that we have developed, we needed
code checks
profiling to convert the description of the registers into XML IP-XACT
compatible format.
Fig. 4. Types of reports and files generated by the integration tool. UVM testbench register sequences [14] is a powerful
verification tool, in order to bypass the software and the
CPU and verify a mixed-signal design and achieve verification
is to use this wiring information to perform connectivity checks coverage closure in a faster and more efficient way. We de-
among the different blocks and check e.g. that a block has veloped Python tools that auto-generate the IP-XACT register
been properly integrated and connected in the design. Of descriptions and also call the Cadence Ireg generator tool, to
course connectivity check can be performed only on pure convert the IP-XACT files to UVM SystemVerilog models,
wire connection paths which include no logic elements. The which then used within our tests. Every test implements a
input for this analysis is the path of a wire name and then sequence of register accesses, in the same way this is done
the tool generates a report on how this path propagates in in software executed by the CPU. Register names used in the
the design, until it reaches a combinational or a sequential sequences are decoded, in terms of register length and address,
logic element. The report is generated in text format. The using the information in the corresponding register model.
connectivity checking functionality is still in beta mode in our
tool. A schematic on how front/back door register access is
implemented in UVM is presented in Figure 5. The UVM
testbench gets access to the register bank, in the same way the
V. P RE - SILICON VERIFICATION AND DIGITAL BACK - END CPU is connected to it and performs front/back-door access to
SUPPORT the registers. All peripheral analog/digital blocks are wired to
the register bank and controlled or provide status information
A. CPU register based verification modelling to specific registers.
A key aspect of the simulation environment required to
verify, before silicon implementation, the functionality of B. Timing / Power constraints development support
our mixed-signal design, is the modelling of the peripheral Using Cadence Conformal Constraints Designer (CCD)
registers. All the information within the system is exchanged tool, we perform checks on SDC timing constraints against
between the CPU and the peripheral (analog/digital) blocks the RTL description. This is an important step to deliver clean
using this set of registers. The models of the registers can timing constraints to the back-end team. In summary, using
be used to perform two different types of tests, regarding CCD we perform a) basic syntax SDC checks, b) timing checks
the way a SystemVerilog testbench accesses the registers: a) in terms of unclocked parts of the design or unconstrained
back door access, where the test directly access the registers, paths and c) clock domain crossing reports, when data buses
bypassing the CPU and the related peripheral bus and b) front cross a clock domain and no synchronization stages are used.
door access, where the testbench mimics the way the CPU
accesses the registers, by interfacing and exchanging data with In order to analyze and review in a more efficient way the
the registers through the peripheral data and control bus. clock domain crossing reports, we developed Python tools to

45
analyze the reports and generate a summary in a CSV, Excel [7] “PyCell Studio,” 2012, http://www.ciranova.com.
compatible format. The initial reports from the CCD tool can [8] P. Haglund, O. Mencer, W. Luk, and B. Tai, “PyHDL: Hardware
be larger than 50,000 lines, so it is not possible to analyze such scripting with Python,” in Proc. International Conference on Field
Programmable Logic (FPL), 2003, pp. 1040–1043.
huge reports and come to safe conclusions about the state of
[9] O. Mencer, M. Morf, and M. J. Flynn, “PAM-Blox: High performance
the clock diagram in a design. The summarized report that FPGA design for adaptive computing,” in Proc. IEEE Symposium on
we generate helps the design team to quickly identify possible FPGAs for Custom Computing Machines, 1998, pp. 167–174.
errors in data crossings between different clock domains and [10] Jingzhao Ou and Viktor K. Prasanna, “PyGen: A Matlab/Simulink based
in case of a real problem then analyze and go through the tool for synthesizing parameterized and energy efficient designs using
full report to identify problems in clock synchronization. It FPGAs,” in Proc. International Symposium on Field-Programmable
also makes easier to identify possible bugs in SDC timing Custom Computing Machines (FCCM), 2004, pp. 47–56.
constraints. [11] “System Generator for DSP, UG640,” 2009, http://www.xilinx.com.
[12] D. Lockhart, G. Zibrat, and C. Batten, “PyMTL: A Unified Framework
Python tool is also used to assist development of power for Vertically Integrated Computer Architecture Research,” in Mi-
constraints in CPF format. In more detail, a power CPF macro croarchitecture (MICRO), 2014 47th Annual IEEE/ACM International
model is required for the main analog block, that assigns each Symposium on. IEEE, 2014, pp. 280–292.
wire in the A/D port list into the proper power domain. The [13] “Google chart diagrams,” https://www.dropbox.com/s/fqiseg9rxy3n8fb/
Python tool extracts power information from the A/D port list google charts.zip?dl=0.
file and generates a CPF model for the I/O lines of the analog [14] A. Jain and R. Gupta, “Scaling the UVM REG model towards automa-
tion and simplicity of use,” in 2015 28th International Conference on
block. VLSI Design, Jan 2015, pp. 164–169.

VI. C ONCLUSIONS
We have presented a set of tools used within our mixed-
signal ASIC design methodology to improve front-end design,
verification and back-end design activities. Our tools do not
replace any well-known and accepted design or verification
methodologies, but rather used in parallel with popular design
tools from the largest EDA software vendors, like Cadence.
For the development of our tools we used the popular Python
programming language in conjunction with other popular and
free available tools, like Java script, XML and Google charts.
Python is used mainly either to generate RTL related files
or to analyze RTL code and other large report files and present
information about the status of a design in a more compact
and human readable format, easier to review and understand.
Without the use of our tools it would be almost impossible
to a) manually develop the RTL code of the functional test
block, b) generate the UVM register models and c) analyze and
review the clock domain crossing reports. So the importance
of our tool has been proven in all three main phases of the
flow: front-end design - verification - back-end design. Work
in progress includes format improvements of the generated
Google chart diagrams and finalize the development of the
connectivity checking tool.

R EFERENCES
[1] “Intel plans a future of CMOS,” 2016,
http://www.eetimes.com/document.asp?doc id=1329353.
[2] M. Barnasconi, M. Dietrich, K. Einwich, T. Vrtler, J. P. Chaput, M. M.
Lourat, F. Pcheux, Z. Wang, P. Cuenot, I. Neumann, T. Nguyen,
R. Lucas, and E. Vaumorin, “UVM-SystemC-AMS framework for
system-level verification and validation of automotive use cases,” IEEE
Design Test, vol. 32, no. 6, pp. 76–86, Dec 2015.
[3] Victor Berman, “Standards: the P1685 IP-XACT IP metadata standard,”
Design & Test of Computers, IEEE, vol. 23, no. 4, pp. 316–317, 2006.
[4] K. Jarrod M. and M. Aivazis, “Python for Scientists and Engineers,”
Computing in Science Eng., vol. 13, no. 2, pp. 9 –12, March 2011.
[5] E. Logaras, E. Koutsouradis, and E. S. Manolakos, “Python facilitates
the rapid prototyping and hw/sw verification of processor centric SoCs
for FPGAs,” in 2016 IEEE International Symposium on Circuits and
Systems (ISCAS), May 2016, pp. 1214–1217.
[6] H. Fangohr, “A comparison of C, MATLAB, and Python as teaching
languages in engineering,” in Computational Science - ICCS 2004, vol.
3039, pp. 1210–1217. Springer Berlin, 2004.

46