VerilogAMS language used in the Top-DownMethodology for wireless integrated circuit designs

Ana Ferreira NoulletFachtna Healey(1)

Regis SantonjaOlivier TicoJean-Claude MboliThierry Nouguier

Motorola Semiconductors(1) 3400 Airport Business Park.Cork, Ireland(2) Av Gen Einsenhower BP 1029 Toulouse

France.

ana.ferreira.noullet@motorola.comfachtna.healy@motorola.comr45398@email.sps.mot.comr42867@email.sps.mot.comr54850@email.sps.mot.comr57359@email.sps.mot.com

Abstract

Presently, the complexity of mixed-signal designs used in the wireless field implies a change in thetraditional chip functionality verification.The Bottom-Up way of designing where each block from a chip is implemented and simulatedseparately 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 inMotorola. In addition, the methodology is improved thanks to the advancement of analog behaviorallanguages, such as VerilogA and Verilog-AMS.This paper presents the use of the behavioral modeling and the Top-Down Methodology in the designof wireless integrated circuits.

1.Top-Down Methodology overviewIn Motorola , the high complexity of circuits, implies the extensive use of CAD tools andmethods to accelerate the project cycle time.The Top-Down Methodology is an efficient method to reach the project goals. The method ofanalyzing the ASIC from the top towards the bottom allows general functionality verificationin 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 behavioralmodeling is more straightforward than in a bigA/small D.Both cases will be treated in this paper.

2. Big Analog/Small DigitalThe 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 bythe customer. The main steps followed to validate the Top-Down methodology are describedbelow.VerilogA as a behavioral language was chosen at that time because our home-madesimulator did not support VerilogAMS languages.

First Step - From Specs downto partitioningBased on specification book, we defined the list of all blocks to be designed as well as alltheir 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 simulationAs the first partitioning was defined, the design leader checked the complete top-cellconnectivity. 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 portsrespected 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 behaviorallanguage, 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 asresistances and sources with null values, or they had verilogA views with very simplifiedfunctionality. The check of the complete connectivity was done thanks to these dummyviews.

• As the behavioral model was written, little by little each block had its empty view replacedby the behavioral one in the Top-Cell configuration. After each replacement a top-cellsimulation 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 changinganything in the schematic test-benches. The main goal was to check the generalconnectivity.In this step, some trouble caused by simulator convergence problems were detected.Convergence errors were mainly generated by the non conformity of VerilogA modelwriting.These issues led the team to write guidelines of how to write conveniently models toreduce convergence problems.

Step 3 - Implementation of each block in transistor levelAs the block I/O pins and symbol were being defined, the designers worked on developingthe 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.

At the end of this phase, each block schematic was delivered to the design leader and to thelayout people.

Figure 1 - Step #3 Implementation of each block in transistor level.

Step 4- Top-Cell Simulation - Mixed behavioral and Transistor-level blocksAs 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 littlereplaced 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 designedand exhaustively checked individually, the Top-Cell simulation had the goal of checkingglobal 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 beenused.

• Every block at transistor level : in this case, to avoid big simulation matrices somemethods can be chosen

• By using simplified SPICE model levels, as level3 by instance instead of empiricalmodels 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 levelusing the Motorola analog simulator and no-simplified models.This analysis is not possible in the majority of cases due to the chip size.

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 AnalogIn this case, the project was a base-band processor design. It is made up of mainly digitalcomponents but it also has a substantial analog component. The top-down methodologysteps were followed .Thus the modeling had different phases :

Phase 1 - Creating modelsAn existing verification environment for the software and digital parts of the system, alongwith 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 seriouslycompromising the simulation speed.In general Verilog-AMS models simulated faster than their Verilog-A equivalents becausefewer signals needed to be placed in the analog domain, which uses a constant time step forsimulation, and more in the digital domain, which is event driven.An improvement factor of 3-10X (depending on the model) was found in project simulationswhen switching from Verilog-A to Verilog-AMS models while other Verilog-A models failed tosimulate in the design system-level testbench.

The interface between the digital and analog domains was much simpler, leading to reducedoverhead in passing signal values between the two.

Because the language is a superset of both Verilog and Verilog-A and both languages can bemixed within blocks it allows for much more flexibility and intelligent models to be written foraccuracy, speed and reusability.

Cadence tools were chosen to simulate the mixed signal scenario: NC-Verilog as the digitalsimulator and AMS-Designer environment to simulate the mixed signal blocks.When implementing Verilog-AMS models for the system, the requirement to extend theexisting digital verification environment to cover analog functionality was the key objective. ATwo-pronged strategy was employed to do this as illustrated in figure 3

Fig 2.1

Figure 3 - Design Implementation

Since the digital sections of the design were modeled at RTL and gate level, models werewritten for the analog blocks at a compatible hierarchical level.In the existing simulation environment the analog blocks were represented as stubs or asvery 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 schematicview in the simulation environment inside Cadence in order of generating a Verilog-AMSnetlist.The digital verification environment was then extended to incorporate these models.

Phase 2 -Model CalibrationThe 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 schematictestbenches to verify the analog blocks in standalone mode.

System Testbench(ncverilog)

Block Testbench(Analog Artist)

Create basicVerilog-AMS modelwith block interfaceand basic analogfunctionality

Run initial systemsimulation

Runschematicsimulation

Run Verilog-AMSmodel in schematictestbench

Compare resultsand modify modeluntil desiredaccuracy isachieved(model calibrated)

Re-run systemsimulation withaccurate Verilog-AMS model

Simulations were run using the schematic representation of the block and the results weresaved. The same simulations were rerun using the Verilog-AMS representation of the blockand the two sets of results were compared. The Verilog-AMS model was modified to give thesame results as the schematic where necessary. This process is known as model calibration.

Phase 3 - Interface elements writingTo facilitate the transition from analog to digital and vice versa interface elements wereautomatically (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 tocustomize these interface elements by editing the source code. Interface elements wereavailable 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 legacydesigns 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. Iflegacy 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 blockinterface compatible with the schematic and symbol views.There are strict rules governing the Verilog-AMS language and if necessary the schematicand symbol needs to be modified to conform to these rules in order to make the two viewscompatible.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 learnedAs the Verilog-AMS implementation process progressed certain issues became apparent inhow the IEEE- 1364 standard and the tools handled the implementation of Verilog-AMS in anexisting design. Many of these issues have been reported to Cadence and the IEEEstandards committee so in future they may not be issues. Other issues related how modelswere 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. Thisincludes the way interface ports to blocks are defined. This standard does not apply toanalog schematics, thus inconsistencies occur when a VerilogAMS block is created to beinterchangeable 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 tobe re drawn as follows to make the two views compatible.

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 apurely Verilog module it is not a problem when simulated using a Verilog simulator. Howeverif it is simulated using a Verilog-AMS simulator, then a syntax error occurs because thesimulator now recognizes it as a keyword. This becomes a problem when a digital design isincorporated into a mixed signal simulation environment and Verilog-AMS keywords are usedas 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 beingsimulated. In a similar way to co-simulating using Verilog and Verilog-AMS there can belegacy issues with introducing spice. An example of this is if there is a primitive cell such asan and gate instantiated in the Verilog portion of the design and again in the spice portionthen the simulator needs to be able to distinguish between which primitive view to use in therelevant case.

4.4.Model abstraction level.This was an issue that had to be addressed up front before any modeling could proceed. Itwas decided that the best level to write initial models was for the level the individual blockswere designed at. This was based on a trade-off between, functional accuracy, speed ofsimulation 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 convergencewas achieved during simulation. Any nets going into or out of the block requiring current to bemodeled had to be carefully modeled so that the simulation functioned correctly whenconnected 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 betweenthe analog and digital domains.

4.7Coding style for optimal simulation speed.The most important aspects to this were readability and maintaining the greatest degree offunctionality while not compromising simulation speed. An important aspect of this waspushing as much functionality into event driven blocks rather than constant timing blocks,thus requiring less CPU time for simulation.

4.8 Managing people’s expectationsSince modeling using Verilog-AMS was a new concept to us, many people had differentideas about what could be achieved and how this should be done. Because of this it wasimportant to evaluate at an early stage what could and could not be done in a given timeframe and how best to optimize the time available to us.

5. ISSUES5.1 ModellingCertain modeling constructs were found to be unusable in certain contexts. An example ofthis was a complex transfer function for a filter. When simulated in standalone the modelworked well, however when incorporated into the feedback loop of a larger design, the modeldid not converge. Reverting to a model based on resistors and capacitors connected as theywere in the schematic solved the problem.

5.2 Digital controlling analog.Analog signals under digital control sometimes had problems with fast changing levels. Thisled 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 someuncertainty with reuse of top-level testbenches.

5.3Analog controlling digital.Digital signals generated from analog blocks cause serious simulation slowdown if the signalchanges too rapidly.

6. Benefits6.1 Closed loop simulation across software, digital and analog domains.The primary benefit of simulating using Verilog-AMS models was to achieve full closed-loopsimulation 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 blackboxes 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 usingsimulations run in AMS mode.

6.4 Design prototyping.Going forward, new block designs can be evaluated and verified in the system they areintended 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 beeasier to maintain and port to future designs.

7. Future Capabilities7.1 Integrating different stages of design flow.Creating a more integrated design flow from system-level concept to schematicimplementation.

7.2 Reuse of models.At this level of abstraction, models are easier to maintain and tailor to a specific applicationthan 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 ofthe 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 thisarea.

7.5 Digital and analog tradeoffs.One simulator at close to implementation level allows more system level partition evaluation.

ConclusionBehavioral 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 methodologiesassociated 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