1. VerilogAMS language used in the Top-Down
Methodology for wireless integrated circuit designs
Ana Ferreira Noullet ana.ferreira.noullet@motorola.com
Fachtna Healey(1) fachtna.healy@motorola.com
Regis Santonja r45398@email.sps.mot.com
Olivier Tico r42867@email.sps.mot.com
Jean-Claude Mboli r54850@email.sps.mot.com
Thierry Nouguier r57359@email.sps.mot.com
Motorola Semiconductors
(1) 3400 Airport Business Park.Cork, Ireland
(2) Av Gen Einsenhower BP 1029 Toulouse
France.
Abstract
Presently, the complexity of mixed-signal designs used in the wireless field implies a change in the
traditional chip functionality verification.
The Bottom-Up way of designing where each block from a chip is implemented and simulated
separately must be combined with other verification methodologies to accelerate the project cycle time.
The Top-Down Methodology has been used for years in the digital field.
The extension of this methodology to the analog world has been used in several departments in
Motorola. In addition, the methodology is improved thanks to the advancement of analog behavioral
languages, such as VerilogA and Verilog-AMS.
This paper presents the use of the behavioral modeling and the Top-Down Methodology in the design
of wireless integrated circuits.
1.Top-Down Methodology overview
In Motorola , the high complexity of circuits, implies the extensive use of CAD tools and
methods to accelerate the project cycle time.
The Top-Down Methodology is an efficient method to reach the project goals. The method of
analyzing the ASIC from the top towards the bottom allows general functionality verification
in the beginning of the project.
It must be applied associated with Bottom-Up methods to cover all chip checking.
In the case of a bigD/smallA (Big Digital Part and small analog one) the use of behavioral
modeling is more straightforward than in a bigA/small D.
Both cases will be treated in this paper.

2. 2. Big Analog/Small Digital
The pilot project chosen was a Power management ASIC ordered by a European customer.
The project was chosen due to its medium chip size and the number of functions required by
the customer. The main steps followed to validate the Top-Down methodology are described
below.
VerilogA as a behavioral language was chosen at that time because our home-made
simulator did not support VerilogAMS languages.
First Step - From Specs downto partitioning
Based on specification book, we defined the list of all blocks to be designed as well as all
their inputs and outputs.
Then all blocks have been tied together in the chip top-cell in Cadence framework.
Step 2-From partitioning downto Top-Cell behavioral simulation
As the first partitioning was defined, the design leader checked the complete top-cell
connectivity. With the aid of the analog behavioral language, VerilogA in our case, the top-
cell simulations started without waiting the implementation of individual blocks.
For the schematic entry as well as simulations, the Cadence framework was used.
Thus, the block implementation consisted of a verilogA description, where the ports
respected the same direction and pin-out as Cadence symbols created in the framework.
To avoid convergence problems with a Top-Cell which all blocks described in a behavioral
language, the simulation process was similar to stacking-up bricks or pieces from a puzzle:
• “Empty” views were created for each block. In these views currents and voltages were set
to zero values . These “empty” views were made up of generic elements such as
resistances and sources with null values, or they had verilogA views with very simplified
functionality. The check of the complete connectivity was done thanks to these dummy
views.
• As the behavioral model was written, little by little each block had its empty view replaced
by the behavioral one in the Top-Cell configuration. After each replacement a top-cell
simulation was run.
• These simulations were made using Cadence Analog Artist tools. In Cadence framework,
the configuration view allowed switching from one view type to another without changing
anything in the schematic test-benches. The main goal was to check the general
connectivity.
In this step, some trouble caused by simulator convergence problems were detected.
Convergence errors were mainly generated by the non conformity of VerilogA model
writing.
These issues led the team to write guidelines of how to write conveniently models to
reduce convergence problems.
Step 3 - Implementation of each block in transistor level
As the block I/O pins and symbol were being defined, the designers worked on developing
the schematic at transistor level.
Figure1 shows this step .
Each designer run analog or mixed simulations depending of the design complexity.
The block was kept in the simulation loop until it reached specifications.
A Motorola spice/Verilog co-simulator was used.
In addition more sophisticated verification tools were used to explore all PVT
(power/voltage/temperature) cases.

3. At the end of this phase, each block schematic was delivered to the design leader and to the
layout people.
Figure 1 - Step #3 Implementation of each block in transistor level.
Step 4- Top-Cell Simulation - Mixed behavioral and Transistor-level blocks
As a block was delivered at transistor level, the behavioral model was replaced in the Top-
Cell block diagram by the real block. Figure 3 presents this simulation methodology.
Using Cadence tools, the configuration view was switched from “veriloga” to “schematic”
when the Transistor level schematic was available.
Using the same strategy as described in step #3, each behavioral view was little by little
replaced the by transistor level view.
This step was completed when all blocks at the top level had schematic views.
The digital can be also delivered in gate level. Since each block has already been designed
and exhaustively checked individually, the Top-Cell simulation had the goal of checking
global functionality and connectivity.
The Top-Cell simulations can combine several methods of simulation :
• Analog part at transistor level with digital at gate level: in this case a mixed simulator is
used.
In our projects, our (Mixed simulator, spice-like, Motorola property) simulator has been
used.
• Every block at transistor level : in this case, to avoid big simulation matrices some
methods can be chosen
• By using simplified SPICE model levels, as level3 by instance instead of empirical
models for MOS devices.
• By using a fast-SPICE simulator to speed-up the simulation (Nanosim Tools).
In the pilot project a complete simulation was possible with all elements at transistor level
using the Motorola analog simulator and no-simplified models.
This analysis is not possible in the majority of cases due to the chip size.

4. Figure 2 - Step #4 Top-Cell Simulation - Mixed behavioral and Transistor -level blocks
The final Top-Cell simulation checks for connectivity and global functionality.
3.Big Digital /small Analog
In this case, the project was a base-band processor design. It is made up of mainly digital
components but it also has a substantial analog component. The top-down methodology
steps were followed .
Thus the modeling had different phases :
Phase 1 - Creating models
An existing verification environment for the software and digital parts of the system, along
with basic Verilog models for the analog parts was available.
The chosen behavior language was VerilogAMS. This language enabled a much more
complex environment to be developed for the analog part of the system without seriously
compromising the simulation speed.
In general Verilog-AMS models simulated faster than their Verilog-A equivalents because
fewer signals needed to be placed in the analog domain, which uses a constant time step for
simulation, and more in the digital domain, which is event driven.
An improvement factor of 3-10X (depending on the model) was found in project simulations
when switching from Verilog-A to Verilog-AMS models while other Verilog-A models failed to
simulate in the design system-level testbench.
The interface between the digital and analog domains was much simpler, leading to reduced
overhead in passing signal values between the two.

5. Because the language is a superset of both Verilog and Verilog-A and both languages can be
mixed within blocks it allows for much more flexibility and intelligent models to be written for
accuracy, speed and reusability.
Cadence tools were chosen to simulate the mixed signal scenario: NC-Verilog as the digital
simulator and AMS-Designer environment to simulate the mixed signal blocks.
When implementing Verilog-AMS models for the system, the requirement to extend the
existing digital verification environment to cover analog functionality was the key objective. A
Two-pronged strategy was employed to do this as illustrated in figure 3
System Testbench Block Testbench
(ncverilog) (Analog Artist)
Create basic
Verilog-AMS model
with block interface
and basic analog
functionality
Run initial system Run Verilog-AMS Run
simulation model in schematic schematic
testbench simulation
Fig 2.1 Compare results
Re-run system and modify model
simulation with until desired
accurate Verilog- accuracy is
AMS model achieved
(model calibrated)
Figure 3 - Design Implementation
Since the digital sections of the design were modeled at RTL and gate level, models were
written for the analog blocks at a compatible hierarchical level.
In the existing simulation environment the analog blocks were represented as stubs or as
very basic functional models written in Verilog, the key objective being to verify connectivity.
The first step in generating an analog model was to take the hierarchical analog schematic
view in the simulation environment inside Cadence in order of generating a Verilog-AMS
netlist.
The digital verification environment was then extended to incorporate these models.
Phase 2 -Model Calibration
The next stage was to verify that the models accurately captured the analog functionality.
This was done in the standard analog verification domain, by using the schematic
testbenches to verify the analog blocks in standalone mode.

6. Simulations were run using the schematic representation of the block and the results were
saved. The same simulations were rerun using the Verilog-AMS representation of the block
and the two sets of results were compared. The Verilog-AMS model was modified to give the
same results as the schematic where necessary. This process is known as model calibration.
Phase 3 - Interface elements writing
To facilitate the transition from analog to digital and vice versa interface elements were
automatically (or manually) placed in the circuit. Interface elements are written in Verilog-
AMS. The interface elements are usually provided by the tool vendor and it is possible to
customize these interface elements by editing the source code. Interface elements were
available for analog to digital, digital to analog and bi-directional interfaces.
3.Guidelines for future implementations.
When implementing Verilog-AMS in future designs it should be kept in mind that legacy
designs are likely to be used and it may not be practical to implement all of these guidelines.
Since Verilog-AMS is a new language, it is unlikely that there will be any legacy data. If
legacy data does exist then it will most likely be in schematic format.
3.1.Schematics.
When beginning to write Verilog-ASM code, every effort should be made to make the block
interface compatible with the schematic and symbol views.
There are strict rules governing the Verilog-AMS language and if necessary the schematic
and symbol needs to be modified to conform to these rules in order to make the two views
compatible.
Also, the following things should be avoided in a schematic :
• Reversing busses.
• Referencing individual bits of a bus in the symbol
• Gaps in bus.
• Special characters in signal names.
• Signal names beginning with numbers.
• Primitives at top hierarchical levels.
4. Lessons learned
As the Verilog-AMS implementation process progressed certain issues became apparent in
how the IEEE- 1364 standard and the tools handled the implementation of Verilog-AMS in an
existing design. Many of these issues have been reported to Cadence and the IEEE
standards committee so in future they may not be issues. Other issues related how models
were implemented and what people expected from them. The main issues are covered here.
4.1 Inconsistencies between analog schematics and Verilog-AMS.
Much of the Verilog-AMS language is based on the Verilog IEEE-1364 standard. This
includes the way interface ports to blocks are defined. This standard does not apply to
analog schematics, thus inconsistencies occur when a VerilogAMS block is created to be
interchangeable with an analog schematic.
The main problems we encountered related to busses, both analog and digital.
Since the Verilog rules govern the Verilog-AMS view this cannot change so the schematics to
be re drawn as follows to make the two views compatible.

7. 4.2 Inconsistencies between Verilog and Verilog-AMS for digital.
Many key words appear in Verilog-AMS that do not appear in IEEE-1364 Verilog. If a Verilog-
AMS keyword (for example idt) that is not a Verilog keyword is used as a variable name in a
purely Verilog module it is not a problem when simulated using a Verilog simulator. However
if it is simulated using a Verilog-AMS simulator, then a syntax error occurs because the
simulator now recognizes it as a keyword. This becomes a problem when a digital design is
incorporated into a mixed signal simulation environment and Verilog-AMS keywords are used
as module and variable definitions in the legacy code.
4.3 Inconsistencies between Verilog, Verilog-AMS and spice.
It is possible to co-simulate using Verilog, Verilog-AMS and spice to define the design being
simulated. In a similar way to co-simulating using Verilog and Verilog-AMS there can be
legacy issues with introducing spice. An example of this is if there is a primitive cell such as
an and gate instantiated in the Verilog portion of the design and again in the spice portion
then the simulator needs to be able to distinguish between which primitive view to use in the
relevant case.
4.4.Model abstraction level.
This was an issue that had to be addressed up front before any modeling could proceed. It
was decided that the best level to write initial models was for the level the individual blocks
were designed at. This was based on a trade-off between, functional accuracy, speed of
simulation and ease of model verification.
4.5 Coding style for simulating with analog schematics.
The most important aspects to this were readability and making sure that the convergence
was achieved during simulation. Any nets going into or out of the block requiring current to be
modeled had to be carefully modeled so that the simulation functioned correctly when
connected to a potentially unknown sink or source.
4.6 Coding style for simulating with digital Verilog.
The most important aspects to this were readability and maintaining synchronization between
the analog and digital domains.
4.7Coding style for optimal simulation speed.
The most important aspects to this were readability and maintaining the greatest degree of
functionality while not compromising simulation speed. An important aspect of this was
pushing as much functionality into event driven blocks rather than constant timing blocks,
thus requiring less CPU time for simulation.
4.8 Managing people’s expectations
Since modeling using Verilog-AMS was a new concept to us, many people had different
ideas about what could be achieved and how this should be done. Because of this it was
important to evaluate at an early stage what could and could not be done in a given time
frame and how best to optimize the time available to us.

8. 5. ISSUES
5.1 Modelling
Certain modeling constructs were found to be unusable in certain contexts. An example of
this was a complex transfer function for a filter. When simulated in standalone the model
worked well, however when incorporated into the feedback loop of a larger design, the model
did not converge. Reverting to a model based on resistors and capacitors connected as they
were in the schematic solved the problem.
5.2 Digital controlling analog.
Analog signals under digital control sometimes had problems with fast changing levels. This
led to large ddts and dvdts and subsequently convergence problems.
This was a major problem in integrating Verilog-AMS blocks into the overall system.
Depending on the time a digital signal changed, the simulation may not run. This led to some
uncertainty with reuse of top-level testbenches.
5.3Analog controlling digital.
Digital signals generated from analog blocks cause serious simulation slowdown if the signal
changes too rapidly.
6. Benefits
6.1 Closed loop simulation across software, digital and analog domains.
The primary benefit of simulating using Verilog-AMS models was to achieve full closed-loop
simulation across software, digital and analog domains on a mixed signal system. Previously,
using standard digital simulators, the analog portions of a design had to be treated as black
boxes of at most digital blocks with basic functionality.
6.2 Verification of analog designs at system level.
This allowed analog designs to be verified at the system level.
6.3 Full system connectivity checking.
Analog connectivity, including functional, power supply and test signals was verified using
simulations run in AMS mode.
6.4 Design prototyping.
Going forward, new block designs can be evaluated and verified in the system they are
intended to work in before the schematic needs to be drawn.
6.5 Design and testbench IP reuse.
Developing testbenches using Verilog-AMS will lead to greater reuse because they will be
easier to maintain and port to future designs.
7. Future Capabilities
7.1 Integrating different stages of design flow.
Creating a more integrated design flow from system-level concept to schematic
implementation.

9. 7.2 Reuse of models.
At this level of abstraction, models are easier to maintain and tailor to a specific application
than their schematic counterpart.
7.3 Test vector generation.
At the time of writing Analog Virtual test is still not available however Verilog-AMS is one of
the factors in enabling this to happen.
7.4 Better tools. Existing ones very new.
Tool vendors see the opportunity to enhance their portfolio with newer and better tools in this
area.
7.5 Digital and analog tradeoffs.
One simulator at close to implementation level allows more system level partition evaluation.
Conclusion
Behavioral languages are the corner stone for the Top-down Methodology.
The extension of VerilogA into AMS field is a positive point for mixed signal circuit modeling.
Using VerilogA the top-cell verification for a bigA/small D circuit could be accomplished.
Verilog-AMS was successfully used to verify the connectivity and broad functionality to base-
band processor project. Going forward, it will be used more as a top-down design tool,
bridging the gap between the system architects and the analog circuit designers.
The methodology developed for this application can be applied to any mixed-signal system.
The tools involved are in their infancy and as they mature so too will the methodologies
associated with them thus making Verilog-AMS a more powerful and usable language.
References
• Verilog-AMS Language Reference Manual –Version 2.0, February 2000
• "Analog Behavioral Modeling with the Verilog-A Language" , Kluwer 1997 - Dan
Fitzpatrick and Ira Miller
• Verilog HDL coding- Semiconductor Reuse Standard”-SRS07HDL V3.3-Motorola
• Motorola home made simulator (confidential documentation)
• Top-Down Methodologies applied in Integrated Circuit Designs in Power Management
Department - SMS2002 Simulation Modeling Symposium, 2002