Power Aware Gate Level Simulations



Index 1..8 Comparison between MVSIM and PAG……………………. 4.3 Power Aware Gatesim Approach………………….. 2 . 3. MVSIM Tool based Approach………………………………………….…………14 2.……13 References……………………………………………… …………. ………………….

1. 3 . the UPF file is manually written capturing the power intent. 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). MVTOOLS convert UPF to APF while generating the database for Multi-Voltage Simulations. Power Aware Gatesim (PAG) Approach developed internal to AMD 1. It was discussed that the following approach would suit for MVRC/MVSIM execution for gates. Thus. Currently.Power Aware Gate Level Simulations This document gives a brief overview of the approaches for Power Aware Gate Level Simulations. DC gives the netlists and its power intent file (UPF). as AMD doesn’t synthesize all the blocks in the design and has lot of custom design in the flow. This file is used for the power verification.e. APF is the internal format of the tool. This gives us the APF file in . the APF is extracted from the design using the tool. b) For Gates. We dump this APF using one of the commands in MVTOOLS i. the Synopsys’ recommendation doesn’t work. MVPHYDBGEN. 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.mv format. MVSIM Tool based approach 2. But. We can plug the tool in the regular Gatesim flow and use it for verifying the protection logic in the design. A custom flow for AMD was formulated and the tool is being evaluated for future use. we have two of them. In normal UPF flow. The flow defined for AMD is as follows: a) For RTL.

Execute MVSIM and debug the reports 5. the following commands are used to run the static checks on the design: a. Execute MVRC and debug the reports 4. b) Every VDD pin is changed as pg_pin. The path to the macros and stdcell libraries is specified in the archpro. Once the APF is generated. In MVRC. report_architecture: gives us report on any violations 4 . All these changes are detailed for library guys in the bug #118010.1. 1. the power state table which tells about all the legal states that the design can go through is inserted. MVPHYDBGEN doesn’t take the libmap as an argument while generating APF. It takes in the changed macros. report_protection: gives us the protection requirements like if any Level shifter/ Isolation Cell need to be placed between two signals. Change the macros to include the Power Ground information 2. The related_power_pin is obtained from the supply_pinmap for the particular macro. any protection cell is redundant between two signals etc. the voltage_map statement for each VDD in that macro is added.mv format which contains the islands in the design and what all the instances that go into each of these islands. c) The related_power_pin and related_ground_pin is added for each pin in the macro. b.2 Generation of APF from .libs: APF is generated by using the command MVPHYDBGEN in the MVTOOLS. Then the voltage_name and pg_type is added for that pg_pin.ini file as search_path and link_library. Generation of APF 3. Setup requirements for MVRC/MVSIM 1. It generates the APF in .3 Execute MVRC and debug the reports: Once the APF is generated. 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 related_ground_pin for all the pins is taken as VSS. stdcell libraries and gates netlists as the arguments.

7 Issues Identified MVRC/MVSIM Prototype: during the RR Storm 5 .v files to VCS for compilation and . BuildPlugin. APF modifications: APF file is modified to include the testbench power rails. Gate Models of the Macros: RTL models of the macros are replaced by equivalent gate models. 1.4 Execute MVSIM and debug the reports: The following steps are involved in executing MVSIM: a. mvdbgen etc.exe generation: Supplying both mvtool modified .pm updates: Created a separate table for MVSIM gates model like other existing model in the BuildPlugin. c. GATE_VDDIO.6 Reference: http://twiki.ini file updates: Updated the . d. c.db’s and their location.make file in order to add extra steps like mvcmp. d. b. V_DEFINE and in MAKE_VAR sections as per project specific requirements. mvtool also generates the apdb in this stage which will load during runtime.make updates: Updated the sbs.exe generation. e. VCS compilation and .ini file with macro .5 Setup Requirements for MVRC/MVSIM: a. report_connection_pg: check the Power Ground Connection integrity of cells in the design 1. b.com/twiki/bin/view/Main/GatesMVSimTestbenchFlow 1.v and other . Test bench Updates: Updated the test bench in order to generate the stimulus (real values) for the following power rails GATE_VDDR. Archpro.pm. in the build flow. MVDBGEN: mvtool add some extra code in . 1. GATE_VDDA and GATE_VSS. MVCMP: Invoking the mvtool to compile the netlist and APF file. e.. sbs. Added extra switches in SBS_DEFINE.c. Running tests on MVSIM build: S3 test which goes through the S3 entry and exit sequence is run on this MVSIM build.v files during this stage based on the power intent info in APF file.amd.

Further to this. the tool was complaining about the crossovers on these stdcells. Macros team has been informed about the changes to be carried out for the 32nm libraries. there is no pg_pin VDDIO in the macro. 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 Z’s forcing by mvsim on VDDIO related interfaces when VDDR was down on. 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. This was overcome with a DOMAINMAP syntax in the Supply_pinmap as detailed in the bug #117595. 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. 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. VDDA as backup power). Currently. initially they were assumed to be single rail. 6 ii) iii) iv) v) . these pins are declared to have the related_power_pin as VDDNB and the error messages are ignored in the MVRC run. But. As they don’t have info on the pg_pins and the related_power_pins. In20ua[] pins have analog currents which corresponds to the voltage VDDA.AMD internal issues: i) Some of the stdcells (ioinx*) are multi-rail cells. LowPower_VIO pin in the macro mad3nbddrls should have the related_power_pin as VDDIO. A bug #118005 has been filed on this issue. 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. MVSIM forcing Z’s on those interfaces when the primary power of the macro was shutdown (cases like VDDR as primary and VDDIO.

lib for top level module only. because modules like marrcorepll..amd. This is yet to be resolved. Synopsys has done a beta release which can identify the extra crossovers after discovering that MVPHYDBGEN is not reporting any crossovers.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. Reason: .) though they are not shutdown. We have ..amd.vi) We are seeing following difference in the RTL UPF and the GATES APF: VDDA domain: VDDA domain was missing in the gate’s APF. Refer following link for mvtool bugs: http://twiki. The ISO_PURE cells are not yet tested in the design with MVRC.com/twiki/bin/view/Main/RRIssuesChecklist iii) iv) Resolved issues: i) MVPHYDBGEN not generating any extra crossovers: In the MVTOOLS. As their primary rail VDDR was shut down MVSIM forces Z's on the interfaces related to backup power (like VDDA.lib’s are not present for lower level modules instantiated in marrcorepll. A STAR #9000 273129 (Bug in Synopsys) is filed in that regard. have multi rails. As the primary power of top level module is VDDR the whole module was kept under VDDR domain.libs for 32nm (Guidelines by Chris Ang) vii) Refer below link for more info on guidelines: http://twiki. when it generates the physical database it should identify extra crossovers in the design. EV writer issue when using BIT select: MVTOOL creating extra bits for some variables during mvdbgen. Resolution: Changes being done in our . ii) Multi Rail issue: S3 test was failing due to insertion of high Z's by MVSIM. In addition to that MVPHYDBGEN. MVDBGEN generates the logical database for the design and gives a list of crossovers in the design. 7 . mad3por etc. VDDIO etc.

backup_power and primary_ground. More links can be found here: http://twiki. Missing of input ports under sensitivity list: Test (s3) fails due to extra logic created by MVTOOL (version 2008. iii) Hierarchy separator in b/w the instance name: During mvdbgen stage. assertions etc. The goal of this activity is to model the voltage sequencing behavior of all possible voltage sequences which also includes S3 sequence. some of the instances were wrongly placed due to wrong interpretation of backup_power. which are primary_power.amd.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 . 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). we had different power rails. Power Aware Gatesim Approach: Power Aware Gatesim has started as part of the Ridgeback Tapeout Quality Initiative.com/twiki/bin/viewauth/SOCDesign/TapeoutQualityInitiative 2. 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. but indirectly through monitors. This bug was fixed in one of the beta releases. Tool was confusing if hierarchy separator comes in b/w the instance name. While generating APF. iv) v) 2.ii) Issue with the backup_power: In every multi-rail macro.12-beta4_2) during mvdbgen in the . We expect to hit the problems related to circuit contention issues.v files.

v and gatesim.b) Power Connectivity for Cell-based multi-vdd macros has to be implemented.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. 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. 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.1 Scripts used in this flow: The following scripts are used in this flow: a) Netlist_Macro_Edit. This includes S3 test also 2. text file containing macro names 2.pl This script copies the LEC data for the TLL macros. net list on which the processing is to be done.sbs files so that there are fewer chances of human error. This script copies the macros found in file and copes the file to current working dir.pl This script takes three inputs 1. b) power_up_monitor. This script works across 9 . 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.1. c) getLEC_data. Directory containing the macro files 3. Run this script in gatesim base dir as it also modifies the gatesim. User needs to provide the information like the check pointed area.

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. d) get_signals. hierarchy of the instance and VDD to which this instance is connected. Gates may misbehave/hold incorrect value/ ”X” due to incorrect connection to VDD 10 .v files to avoid human errors so run this script in base gatesim dir. (one can use the get_signals. there are chances the following may happen in the period when the power plane comes up and PwrOk is not asserted. It requires path to dir containing the LEC files (collected using getLEC_data. So. We need to improve our infra to have a central location from where this information can be retrieved.2 Monitors: In Power Aware gatesim. Need to run this cmd file in ASDC.pl). Macro name. e. In this script getting the macro names and the correct check pointed version of each macro is very tedious and error prone job. the RTL-Gate Comparisons are disabled till the PwrOk is asserted.site i. and other text file containing the information like. 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.1. f) Copy_Power_Aware_files. Also the other problem is designer may delete the local work area so we need to check point the LEC results in future projects.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.pl This script generates the verilog code to force the TLL macros state points to “X” when we remove the VDD.) This script also modifies the gatesim. 2.sbs and gatesim.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.

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. there is need of a mechanism to catch these scenarios and avoid complete failure of chip. For this. 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.pl to edit the instances of cell based macros In the gatesim. we have a shell script Copy_Power_Aware.v serves this purpose by checking the status of some important signals when power planes are coming up 2.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.v file.v file Use the script Netlist_Macro_Edit. 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.1.- 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.cmd to copy the files to local area 11 - - - - . replace the simenv files used for the power sequencing in the current build.pl script to generate the firewall. Firewall.

so we are forcing the state points to ‘X’ when we turn them off We need the state points in a macro.- Do a build clean and rebuild the model.2 Lessons learnt from Ridgeback Power Aware Gatesim Effort: Lessons for Immediate use 1. we generate state2x_. 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. keeps there indefinitely. 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). Make sure that all the gate level library components are power aware and their behavior is correct. Such forces need to be identified before building full chip and 12 . 2. Try to run the power aware gatesim at the TLM level first and then go at the Full chip level.v file containing the routines to force the state points of macro instances to ‘X’ when we turn them off - - - - 2. but this is huge task. o The following issues are reported with library components:  gv_fqs: (Flop with scan) state element is not initialized so "X". instance hierarchy of all such macros in full chip. So when we turn them off during S3 state transitions. 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. (this element is replaced with gv_fqs_init)  In PLL the missing forces causes clocks to go to "X".

They need to be forced to RTL/Known value when it comes out of reset. where "X" keeps circulating. o Flow could be ported across projects very easily if there is such provision. one may not be simulating correct power sequencing behavior. 4. 3. In DFT world.com/twiki/pub/Verif/VerifCOEGateSim/PAG_Mainstream _Meth_Needs_11. Please refer: http://twiki. Presently.resolve them as turnaround time is high with full gate build. 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.v needs to be initialized to known value.12.  gv_fq: (Flop without scan) causes problem in feedback loop.DcHrBufId. #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.BU. 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. James Torrey is working on automating the most of the flow.08. 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. SYS.CPU0. All checkers need to understand the power sequencing behavior (power sequencing can be made part of normal test runs with reduced delays). This causes race condition between RTL and gate causing false RTL-Gate mismatches.MPU00.amd. 2. their check pointed version against sync and relative macro paths in the check point dir. o Make sure that all the power nets are properly connected in the top level and second level of macro cell instances. The complete build flow need to have a central file which contains all the macro information.pdf Long Term Goals to Implement: 1. 13 . the signals/Stimulus is applied on rising edge and the signals also get sampled internally on the same.  Some counters remain in "X" e.g. If they are connected to "1". Instead of compare points the firewall signals are being watched 5. Presently the compares are turned off till power ok gets asserted.  Flop SCANCTL in rtl_stdlib.

At each and every IP level the AMDFORCE methodology need to be followed and forces should be applied on flops. Every IP should provide adequate compare point / Probe point details to SOC level. 5. so that mismatch internal to IP could be easily caught. 14 .4.

But in PAG. Power Down of module MVSIM understands the state sequence of a module and drives X when a module is powered down. MVSIM understands the waveform nature of the voltage and drives it to different modules. The corresponding checker owner should take care of that. In PAG. It monitors the different connections made between the modules. waveform nature of the voltage is understood by the logic cells/macros but not driven. Both PAG and MVSIM use VRM and drive it on the modules. X-tools do some of the protection logic checks. Speed Overhead 15 . 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. basing on UPF and the value of voltage driven.3. Impact on Checkers Checkers need to be powered down happy in both the approaches. 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. In PAG. the real value of voltages should be generated and driven across different modules. all this needs to be identified manually. we don’t have any explicit checks for the protection cells but can be caught during simulations when X propagation happens. 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. 4. MVSIM puts in some code in the MVDBGEN phase.amd. Comparison of MVSIM and PAG by Narasimha: http://twiki. If the power intent info on any module is missed. Tapeout Quality Initiative Page: http://twiki.amd.com/twiki/bin/view/LN32Verif/PowerAwareGatesMVSim 16 . MVSIM takes care of forcing X/Z in the macros when they are not powered up. Verification CoE page on Power Verification : http://twiki. the speed is not affected that much as the code added is not that huge. It presents a tough challenge to categorize the multi-rail macros into any single power domain. References: 1. the tool doesn’t report that.amd.com/twiki/bin/viewauth/Verif/VerifCOEPower 3. which brings in some considerable amount of overhead Power Intent – Issues Power intent is captured as a UPF file in MVSIM approach.com/twiki/bin/viewauth/SOCDesign/TapeoutQualityIniti ative 2.