Power Aware Gate Level Simulations

-Balakrishna

Index
1.

MVSIM Tool based Approach..3 Power Aware Gatesim Approach. .8 Comparison between MVSIM and PAG.13 References ..14

2.

3.

4.

Power Aware Gate Level Simulations

This document gives a brief overview of the approaches for Power Aware Gate Level Simulations. Currently, we have two of them. 1. MVSIM Tool based approach
2. Power Aware Gatesim (PAG) Approach developed internal to AMD

1. MVSIM Tool based approach:

MVSIM is a tool from Synopsys which comes as a set of Static Rule Checker (MVRC) and Dynamic Multi-Voltage Simulator (MVSIM). We can plug the tool in the regular Gatesim flow and use it for verifying the protection logic in the design. Synopsys recommended flow for MVSIM is to capture the Power Intent of the design in a UPF file and feed it to the Design Compiler along with Synthesizable RTL. Thus, DC gives the netlists and its power intent file (UPF). But, as AMD doesnt synthesize all the blocks in the design and has lot of custom design in the flow, the Synopsys recommendation doesnt work. A custom flow for AMD was formulated and the tool is being evaluated for future use. The flow defined for AMD is as follows:
a) For RTL, the UPF file is manually written capturing the power intent.

This file is used for the power verification. b) For Gates, the APF is extracted from the design using the tool. APF is the internal format of the tool. In normal UPF flow, MVTOOLS convert UPF to APF while generating the database for Multi-Voltage Simulations. We dump this APF using one of the commands in MVTOOLS i.e. MVPHYDBGEN. This gives us the APF file in .mv format.
It was discussed that the following approach would suit for MVRC/MVSIM execution for gates. 3

1. Change the macros to include the Power Ground information 2. Generation of APF 3. Execute MVRC and debug the reports 4. Execute MVSIM and debug the reports 5. Setup requirements for MVRC/MVSIM

1.1 Change the macros to include the Power Ground information:

The following changes are made to the multi-macros: a) At the beginning of each macro, the voltage_map statement for each VDD in that macro is added. b) Every VDD pin is changed as pg_pin. Then the voltage_name and pg_type is added for that pg_pin. c) The related_power_pin and related_ground_pin is added for each pin in the macro. The related_power_pin is obtained from the supply_pinmap for the particular macro. The related_ground_pin for all the pins is taken as VSS. All these changes are detailed for library guys in the bug #118010.

1.2

Generation of APF from .libs:

APF is generated by using the command MVPHYDBGEN in the MVTOOLS. It takes in the changed macros, stdcell libraries and gates netlists as the arguments. It generates the APF in .mv format which contains the islands in the design and what all the instances that go into each of these islands. Once the APF is generated, the power state table which tells about all the legal states that the design can go through is inserted. MVPHYDBGEN doesnt take the libmap as an argument while generating APF. The path to the macros and stdcell libraries is specified in the archpro.ini file as search_path and link_library.

1.3

Execute MVRC and debug the reports:

Once the APF is generated, In MVRC, the following commands are used to run the static checks on the design: a. report_protection: gives us the protection requirements like if any Level shifter/ Isolation Cell need to be placed between two signals, any protection cell is redundant between two signals etc. b. report_architecture: gives us report on any violations 4

c. report_connection_pg: check the Power Ground Connection integrity of cells in the design

1.4

Execute MVSIM and debug the reports:

The following steps are involved in executing MVSIM: a. APF modifications: APF file is modified to include the testbench power rails. b. MVCMP: Invoking the mvtool to compile the netlist and APF file. c. MVDBGEN: mvtool add some extra code in .v files during this stage based on the power intent info in APF file. mvtool also generates the apdb in this stage which will load during runtime. d. VCS compilation and .exe generation: Supplying both mvtool modified .v and other .v files to VCS for compilation and .exe generation. e. Running tests on MVSIM build: S3 test which goes through the S3 entry and exit sequence is run on this MVSIM build.

1.5 Setup Requirements for MVRC/MVSIM:

a. BuildPlugin.pm updates: Created a separate table for MVSIM gates model like other existing model in the BuildPlugin.pm. Added extra switches in SBS_DEFINE, V_DEFINE and in MAKE_VAR sections as per project specific requirements. b. sbs.make updates: Updated the sbs.make file in order to add extra steps like mvcmp, mvdbgen etc., in the build flow.
c. Gate Models of the Macros: RTL models of the macros are

replaced by equivalent gate models.

d. Test bench Updates: Updated the test bench in order to

generate the stimulus (real values) for the following power rails GATE_VDDR, GATE_VDDIO, GATE_VDDA and GATE_VSS.
e. Archpro.ini file updates: Updated the .ini file with macro .dbs

and their location.

1.6

Reference:

http://twiki.amd.com/twiki/bin/view/Main/GatesMVSimTestbenchFlow

1.7 Issues Identified MVRC/MVSIM Prototype:

during

the

RR

Storm

AMD internal issues: i) Some of the stdcells (ioinx*) are multi-rail cells, initially they were assumed to be single rail. As they dont have info on the pg_pins and the related_power_pins, the tool was complaining about the crossovers on these stdcells. A bug#117400 was filed to make the enhancements to the 32nm stdcell library and a resolution of the 45nm library is also being discussed. LowPower_VIO pin in the macro mad3nbddrls should have the related_power_pin as VDDIO. But, there is no pg_pin VDDIO in the macro. This was overcome with a DOMAINMAP syntax in the Supply_pinmap as detailed in the bug #117595. Currently, these pins are declared to have the related_power_pin as VDDNB and the error messages are ignored in the MVRC run. MVRC reports error on a crossover from In20ua[](VDDA) pins in the macro marrcorepll to the pin IRef20uN_VIO_Q8(VDDIO) in the macro mad3rxmasterbias. In20ua[] pins have analog currents which corresponds to the voltage VDDA. A bug #118005 has been filed on this issue. Further to this, the bugs #118009 and #118010 have been filed for the changes to be done to the macros for 45nm and 32nm. Christopher Ang from LSDC is working on a script which can convert the RR Full Chip macros to the required format. Macros team has been informed about the changes to be carried out for the 32nm libraries. Testing the S3 mode sequence with MVSIM on the DDRPHY netlist: S3 test was passed by keeping the multi rail macros under always on domain whose primary power is VDDR. Reason: we kept the multi rail macros under always_on section because mvtool is not properly handle the backup power related interfaces in the multi macros. MVSIM forcing Zs on those interfaces when the primary power of the macro was shutdown (cases like VDDR as primary and VDDIO, VDDA as backup power). When we remove above mentioned multi rail macros from always on then the test was failed due to ova errors which are generating due to high Zs forcing by mvsim on VDDIO related interfaces when VDDR was down on.
6

ii)

iii)

iv)

v)

vi)

We are seeing following difference in the RTL UPF and the GATES APF: VDDA domain: VDDA domain was missing in the gates APF. Reason: .libs are not present for lower level modules instantiated in marrcorepll. We have .lib for top level module only. As the primary power of top level module is VDDR the whole module was kept under VDDR domain. Resolution: Changes being done in our .libs for 32nm (Guidelines by Chris Ang)

vii)

Refer below link for more info on guidelines: http://twiki.amd.com/twiki/bin/view/Verif/VerifCOEPowerOtherRules

Bugs filed in Synopsys:

Unresolved Issues: i) Support for Isolation cells inbuilt in multi-rail cells: The MVTOOLS are yet to provide the support for the Isolation cells which are inbuilt in multi-rail macro cells. A STAR #9000 273129 (Bug in Synopsys) is filed in that regard. This is yet to be resolved. The ISO_PURE cells are not yet tested in the design with MVRC.

ii)

Multi Rail issue: S3 test was failing due to insertion of high Z's by MVSIM, because modules like marrcorepll, mad3por etc., have multi rails. As their primary rail VDDR was shut down MVSIM forces Z's on the interfaces related to backup power (like VDDA, VDDIO etc.,) though they are not shutdown. EV writer issue when using BIT select: MVTOOL creating extra bits for some variables during mvdbgen. Refer following link for mvtool bugs: http://twiki.amd.com/twiki/bin/view/Main/RRIssuesChecklist

iii)

iv)

Resolved issues: i) MVPHYDBGEN not generating any extra crossovers: In the MVTOOLS, MVDBGEN generates the logical database for the design and gives a list of crossovers in the design. In addition to that MVPHYDBGEN, when it generates the physical database it should identify extra crossovers in the design. Synopsys has done a beta release which can identify the extra crossovers after discovering that MVPHYDBGEN is not reporting any crossovers. 7

ii)

Issue with the backup_power: In every multi-rail macro, we had different power rails, which are primary_power, backup_power and primary_ground. While generating APF, some of the instances were wrongly placed due to wrong interpretation of backup_power. This bug was fixed in one of the beta releases.

iii)

Hierarchy separator in b/w the instance name: During mvdbgen stage, Tcl parser inside the mvtool was not able to parse the instance names properly if hierarchy separator comes in b/w the instance name (like \D3MASTERV_SLM/DDRPHYPLL). Tool was confusing if hierarchy separator comes in b/w the instance name. Missing of input ports under sensitivity list: Test (s3) fails due to extra logic created by MVTOOL (version 2008.12-beta4_2) during mvdbgen in the .v files. Actually Mvtool modified the sensitivity list in .v files during mvdbgen and ignored to place the input ports under sensitivity. Always @* blocks not evaluated by mvtool at power up: Mvtool was not able to evaluate the always blocks at power up due to problem with instrumentation by MVDBGEN.

iv)

v)

2. Power Aware Gatesim Approach:

Power Aware Gatesim has started as part of the Ridgeback Tapeout Quality Initiative. The goal of this activity is to model the voltage sequencing behavior of all possible voltage sequences which also includes S3 sequence. We expect to hit the problems related to circuit contention issues, but indirectly through monitors, assertions etc. More links can be found here: http://twiki.amd.com/twiki/bin/viewauth/SOCDesign/TapeoutQualityInitiative

2.1

Methodology:

The following are the steps involved in the Power Aware Gatesim Approach: a) Convert all stdcells and macros to be power aware and build a fullchip model
8

b) Power Connectivity for Cell-based multi-vdd macros has to be implemented. Transistor level macros are more problematic and may have pessimistic for voltage behavior c) All allowable sequences as per data sheet has to be implemented d) Any additional monitors in the environment to identify voltage domain crossing/circuit contention problems are to be added e) Run sequences of tests with as much coverage as possible. This includes S3 test also 2.1.1 Scripts used in this flow: The following scripts are used in this flow:
a) Netlist_Macro_Edit.pl

This script takes three inputs 1. text file containing macro names 2. Directory containing the macro files 3. net list on which the processing is to be done. This script copies the macros found in file and copes the file to current working dir, edit the macro file and changes the declaration of macro as _gate Then it searches net list for instantiation of this macro and changes the instance name with _gate Then the person needs to edit the vcs_gate_opts file to include the dir containing the modified macro files.
b) power_up_monitor.pl

This script is used to generate the fire walling mechanism in the power aware gatesim. User needs to provide following information to the script: This script takes a monitor file as input which contains information about the signal and its value to be monitored during power up. Run this script in gatesim base dir as it also modifies the gatesim.v and gatesim.sbs files so that there are fewer chances of human error.
c) getLEC_data.pl

This script copies the LEC data for the TLL macros. User needs to provide the information like the check pointed area. From the check pointed area and the version the script find out the local work area where the LEC was done and copies the LEC file to current location. This script works across
9

site i. e. if you are working in asdc and local work area for a macro is located at some other site script will do rsync and get the LEC data. In this script getting the macro names and the correct check pointed version of each macro is very tedious and error prone job. We need to improve our infra to have a central location from where this information can be retrieved. Also the other problem is designer may delete the local work area so we need to check point the LEC results in future projects.
d) get_signals.pl

This script is used to get the information like the power plane on which a particular instance is connected and hierarchy of that instance in full chip
e) State2X.pl

This script generates the verilog code to force the TLL macros state points to X when we remove the VDD. It requires path to dir containing the LEC files (collected using getLEC_data.pl). and other text file containing the information like; Macro name, hierarchy of the instance and VDD to which this instance is connected. (one can use the get_signals.pl script to get the information like the power plane on which a particular instance is connected and hierarchy of that instance in full chip.) This script also modifies the gatesim.sbs and gatesim.v files to avoid human errors so run this script in base gatesim dir.
f) Copy_Power_Aware_files.cmd

This is a simple file with the series of shell commands to copy the files modified to implement the power sequencing in the environment. Need to run this cmd file in ASDC. 2.1.2 Monitors: In Power Aware gatesim, the RTL-Gate Comparisons are disabled till the PwrOk is asserted. So, there are chances the following may happen in the period when the power plane comes up and PwrOk is not asserted. Gates may misbehave/hold incorrect value/ X due to incorrect connection to VDD

10

The level shifters may be absent on a signal going from one voltage domain to another and this may cause X propagation in machine

Thus, there is need of a mechanism to catch these scenarios and avoid complete failure of chip. Firewall.v serves this purpose by checking the status of some important signals when power planes are coming up
2.1.3 Steps in generating a build:

We got to consider the changes that are required to do a) without TLL macros and b) with TLL macros And both include power aware cell based macros and power aware stdcells. The following are the changes that are required to do a) Without TLL macros:
-

Take an existing gatesim build and run a small simulation of 10 cycles Copy the gatesim build to the local build area, replace the flat gate netlist with the power aware gates netlist (having VDD and VSS connection) Edit the vcs_gate_opts file and point to the power aware gates libraries (Cell based libraries and GV primitives) Use power_up_monitor.pl script to generate the firewall.v file Use the script Netlist_Macro_Edit.pl to edit the instances of cell based macros In the gatesim.v file, tie the VDD to 1 and VSS to 0 do the gatesim build and run the simulation (This is same as the normal gatesim build to find any VDD connectivity issues) Now, replace the simenv files used for the power sequencing in the current build. For this, we have a shell script Copy_Power_Aware.cmd to copy the files to local area
11

Do a build clean and rebuild the model. This will build the model with VDD and VSS connected to the correct voltage levels Run the power aware gatesim on stdcell build

b) With TLL macros: The problem with macros that have TLL models is that we are using the RTL models for them in the gate simulations. So when we turn them off during S3 state transitions, the state points in these macros continue to hold the value before they are turned off The possible solution is to make these macros power aware (add notion of power planes), but this is huge task, so we are forcing the state points to X when we turn them off We need the state points in a macro, instance hierarchy of all such macros in full chip, and information about power planes in which a particular instance is operating The state points in a macro can be found out from the LEC output file The instance hierarchy was found out using the Verdi When we have all the above information, we generate state2x_.v file containing the routines to force the state points of macro instances to X when we turn them off

2.2 Lessons learnt from Ridgeback Power Aware Gatesim Effort:

Lessons for Immediate use 1. Try to run the power aware gatesim at the TLM level first and then go at the Full chip level. 2. Make sure that all the gate level library components are power aware and their behavior is correct. o The following issues are reported with library components: gv_fqs: (Flop with scan) state element is not initialized so "X"; keeps there indefinitely. (this element is replaced with gv_fqs_init) In PLL the missing forces causes clocks to go to "X". Such forces need to be identified before building full chip and
12

resolve them as turnaround time is high with full gate build. Some counters remain in "X" e.g. SYS.MPU00.CPU0.BU.DcHrBufId. They need to be forced to RTL/Known value when it comes out of reset. Flop SCANCTL in rtl_stdlib.v needs to be initialized to known value. gv_fq: (Flop without scan) causes problem in feedback loop, where "X" keeps circulating. o Make sure that all the power nets are properly connected in the top level and second level of macro cell instances. If they are connected to "1"; one may not be simulating correct power sequencing behavior. o Run some of the scripts on the libraries that are developed to filter out the primitives like gv_fqs and macro modules without power pin connections. 3. In DFT world, the signals/Stimulus is applied on rising edge and the signals also get sampled internally on the same. This causes race condition between RTL and gate causing false RTL-Gate mismatches. Presently, #delays are added in such cases but the proper solution would be to toggle the TB signals on negative edge so that there will not be such cases. 4. Presently the compares are turned off till power ok gets asserted. Instead of compare points the firewall signals are being watched 5. James Torrey is working on automating the most of the flow. Please refer: http://twiki.amd.com/twiki/pub/Verif/VerifCOEGateSim/PAG_Mainstream _Meth_Needs_11.12.08.pdf Long Term Goals to Implement:
1. All checkers need to understand the power sequencing behavior

(power sequencing can be made part of normal test runs with reduced delays). 2. Need to standardize the level shifters and isolators so that it will be simple to auto mate the flow and catch the voltage domain crossing errors using static checkers (Like Xtools) 3. The complete build flow need to have a central file which contains all the macro information, their check pointed version against sync and relative macro paths in the check point dir. o This will simplify/automate the information gathering process (presently it is very time consuming and tedious to collect macro information) and fewer chances for human error while gathering correct macro model and LEC files. o Flow could be ported across projects very easily if there is such provision.
13

4. At each and every IP level the AMDFORCE methodology need to be

followed and forces should be applied on flops. 5. Every IP should provide adequate compare point / Probe point details to SOC level, so that mismatch internal to IP could be easily caught.

14

3. Comparison between MVSIM and PAG:

A comparison report basing on the experience shared by the people who worked on MVSIM and PAG is presented below: Waveform Nature of the Voltage: To simulate the build with real time behavior, the real value of voltages should be generated and driven across different modules. Both PAG and MVSIM use VRM and drive it on the modules. MVSIM understands the waveform nature of the voltage and drives it to different modules. In PAG, waveform nature of the voltage is understood by the logic cells/macros but not driven. Power Down of module MVSIM understands the state sequence of a module and drives X when a module is powered down, basing on UPF and the value of voltage driven. But in PAG, all this needs to be identified manually. Usability with RTL MVSIM can be run over both RTL & Gates but PAG is currently used only with Gates Checks for missing protection logic MVRC checks for the Level Shifter and Isolation cells at a static level when run in electrically accurate mode. It monitors the different connections made between the modules. This gives a good advantage on the time factor too. MVSIM checks for the protection logic in the simulation when different modules are powered down and powered up. In PAG, we dont have any explicit checks for the protection cells but can be caught during simulations when X propagation happens. X-tools do some of the protection logic checks. Impact on Checkers Checkers need to be powered down happy in both the approaches. The corresponding checker owner should take care of that. Speed Overhead
15

In PAG, the speed is not affected that much as the code added is not that huge. MVSIM puts in some code in the MVDBGEN phase, which brings in some considerable amount of overhead Power Intent Issues Power intent is captured as a UPF file in MVSIM approach. MVSIM takes care of forcing X/Z in the macros when they are not powered up. It presents a tough challenge to categorize the multi-rail macros into any single power domain. If the power intent info on any module is missed, the tool doesnt report that.

4. References:
1. Tapeout Quality Initiative Page:

http://twiki.amd.com/twiki/bin/viewauth/SOCDesign/TapeoutQualityIniti ative
2. Verification CoE page on Power Verification :

http://twiki.amd.com/twiki/bin/viewauth/Verif/VerifCOEPower
3. Comparison of MVSIM and PAG by Narasimha:

http://twiki.amd.com/twiki/bin/view/LN32Verif/PowerAwareGatesMVSim

16