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




Ana Ferreira Noullet    ...
2. Big Analog/Small Digital
The pilot project chosen was a Power management ASIC ordered by a European customer.
The proje...
At the end of this phase, each block schematic was delivered to the design leader and to the
layout people.




          ...
Figure 2 - Step #4 Top-Cell Simulation - Mixed behavioral and Transistor -level blocks

The final Top-Cell simulation chec...
Because the language is a superset of both Verilog and Verilog-A and both languages can be
mixed within blocks it allows f...
Simulations were run using the schematic representation of the block and the results were
saved. The same simulations were...
4.2 Inconsistencies between Verilog and Verilog-AMS for digital.
Many key words appear in Verilog-AMS that do not appear i...
5. ISSUES
5.1 Modelling
Certain modeling constructs were found to be unusable in certain contexts. An example of
this was ...
7.2 Reuse of models.
At this level of abstraction, models are easier to maintain and tailor to a specific application
than...
Upcoming SlideShare
Loading in …5
×

Verilog Ams Used In Top Down Methodology For Wireless Integrated Circuits

1,709 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,709
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
3
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Verilog Ams Used In Top Down Methodology For Wireless Integrated Circuits

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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

×