Mukesh Jaiswal Blog

Quick Reference - 8 Ways to Optimize Power Using Encounter Digital Implementation (EDI) System

MJ Cad — Tue, 12 Feb 2013 16:25:00 GMT

Everyone knows that the increasing speed and complexity of today's designs implies a significant increase in power consumption, which demands better optimization of your design for power. I am sure lot of us must be scratching our heads over how to achieve this, knowing that manual power optimization would be hopelessly slow and all too likely to contain errors.

Here are 8 Top Things you need to know to optimize your design for power using the Encounter Digital Implementation (EDI) System.

Given the importance of power usage of ICs at lower and lower technology nodes, it is necessary to optimize power at various stages in the flow. This blog post will focus on methods that can be used to reach an optimal solution using the EDI System in an automated and clearly defined fashion. It will give clear and concise details on what features are available within optimization, and how to use them to best reach the power goals of the design.

Please read through all of the information below before making a decision on the right approach or strategy to take. It is highly dependent on the priority of low power and what timing, runtime, area and signoff criteria were decided upon in your design. With the aid of some or all of the techniques described in this blog it is possible to, depending on the design, vastly reduce both the leakage and dynamic power consumed by the design.

Quick Reference - Top Things to Know about Power Optimization

All of the following items discussed here in brief are covered in greater detail in Low Power Optimization in EDI System appnote posted on http://support.cadence.com/

This is a one stop quick reference and not a substitute for reading the full document.

1) VT partition uses various heuristics to gather the cells into a particular partition. Depending on how the cells get placed in a particular bucket, the design leakage can vary a lot. The first thing is to ensure that the leakage power view is correctly specified using the "set_power_analysis_mode -view" command. The "reportVtInstCount -leakage" command is a useful check to see how the cells and libraries are partitioned. Always ensure correct partitioning of cells.

2) In several designs, manually controlling certain leakage libraries in the flow might give much better results than the automated partitioning of cells. If the VT partitioning is not satisfactory, or the optimization flow is found to use more LVT cells than targeted, selectively turn off cells of certain libraries particularly in initial part of the flow i.e. preRoute flow. The user should selectively set the LVT libraries to "don't use" and run preCts/postCts optimization. Depending on final timing QOR, another incremental optimization with LVT cells enabled may be needed.

3) Depending on the importance of leakage/dynamic power in the flow, the leakage/dynamic power flow effort can be set to high or low.

setOptMode -leakagePowerEffort {low|high}
setOptMode -dynamicPowerEffort {low|high}

If timing is the first concern, but having somewhat better leakage/dynamic power is desired, then select low. If leakage/dynamic power is of utmost importance, use high.

4) PostRoute Optimization typically works with all LVT cells enabled. In case of large discrepancy between preRoute and postRoute timings or if SI timing is much worse than base timing, postRoute optimization may overuse LVT cells. So it may be worthwhile experimenting with a two pass optimization, once with LVT cells disabled, and then with LVT cells enabled.

5) In order to do quick PostRoute timing optimization to clean up final violations without doing physical updates, use the following:

setOptMode -allowOnlyCellSwapping true
optDesign -postRoute

This will only do cell swapping to improve timing, without doing physical updates. This is specifically for timing optimization and will worsen leakage.

6) Leakage flows typically have a larger area footprint than non-leakage flows. This is because EDI trades area with power, as it uses more HVT cells to fix timing to reduce leakage. This sometimes necessitates reclaiming any extra area during postRoute Opt to get better convergence in timing. EDI has an option to turn on area reclaim postRoute which is hold aware also and will not degrade hold timing.

setOptMode -postRouteAreaReclaim holdAndSetupAware

7) Running standalone Leakage Optimization to do extra leakage reclamation:

optLeakagePower

This may be needed if some of the settings have changed or if leakage flows are not being used.

8) PreRoute Optimization works with an extra DRC Margin of 0.2 in the flow. On some designs it is known to result in extra optimization causing more runtime and worse leakage. The option below is used to reset this extra margin in DRV fixing:

setOptMode -drcMargin -0.2

Remember to reset this margin for postRoute optimization to 0, as postRoute doesn't work with this extra margin of 0.2. Note that the extra drcMargin is sometimes useful in reducing the SI effects, so by removing the extra margin, more effort may be needed to fix SI later in the flow.

I hope these tips help you achieve your power goals of your designs!

-Mukesh Jaiswal

SPICE Correlation Made Easy by Encounter Timing System (ETS)

MJ Cad — Mon, 10 Dec 2012 17:24:00 GMT

Hello, and welcome to my first blog!

As an application engineer in customer support, I have received quite a few queries on how to do SPICE correlation of timing numbers. This blog is intended to help users understand the flow/methodology for doing SPICE correlation of static timing analysis (STA) timing results using Encounter Timing System (ETS).

As we know, users do correlation of the critical paths in timing analysis with path simulation, using SPICE to gain the signoff confidence of their design. ETS offers built-in critical path simulation for base delay and signal integrity (SI) correlation with SPICE.

This blog describes the flow/methodology available in ETS at a higher level to perform path simulations with SPICE and correlate them with base delay timing.

SPICE Deck Generation

The ‘create_spice_deck’ command is available in ETS to generate the SPICE trace for a path.

The SPICE deck generated by ‘create_spice_deck’ includes:

- All nets in the path and their instance connections

- Standard cell gate information for the instances and their port connections - initial conditions and voltage sources

- Measure statements for slew and delay measurements

- RC parasitic network information

Various options of create_spice_deck command can be used to specify the path(s) of interest and other information required for SPICE deck.

For details on supported options to this command, visit ETS documentation

Examples for SPICE deck generation command

1) The following command without any options will generate a SPICE for worst path as seen by timing analysis

create_spice_deck

2) The following command creates a SPICE deck for specified path with predriver waveform as input PWL and side path loading of 1 stage, and includes the path of specified SPICE subcircuit and model file in SPICE deck.

create_spice_deck -report_timing {-retime path_slew_propagation -net -from_rise inst_flop1/q -though inst_buf/a -though inst_buf/y -to inst_flop2/d} -input_waveform predriver -subckt_file SPICE_subckt.sp -model_file models.sp -power {vdd vddw} -ground {vss vssw} -side_path_level 1 -outdir ETS_SPICE

3) The following command creates a SPICE deck and simulates it using the Spectre^TM simulator specified.

create_spice_deck -run_path_simulation -Spectre /tools/Spectre

Running Path Simulation and Results Extraction

Path simulation can be done in two ways:

1) Spectre™ path simulator available in ETS installation (create_spice_deck -run_path_simulation) can be used to run path simulation

2) SPICE deck can be generated in user-specified directory, and stand-alone (outside of ETS environment) path simulation can be run using Spectre™ or any simulator that understands SPICE syntax.

Spectre™ path simulator in ETS

create_spice_deck -run_path_simulation option can be used to do on the fly path simulation in ETS.

Note: For running simulation using -run_path_simulation, it is highly recommended to specify SPICE subckt and model file using -subckt_file and -model_file options respectively. If they are not specified, design must have cdB files loaded and software will get this in-formation from cdB file. However, it is mandatory to specify subckt and model files if AAE is being used.

Besides writing a few files in the directory (specified using -outdir option) it also reports a table of timing (as shown in below example) with slew/delay/arrival column from report_timing and path simulation for correlation comparison. It will report two separate tables for launch and capture paths if report_timing –path_type full_clock is used.

Stand-alone Path Simulation

If create_spice_deck command is run without –run_path_simulation option, it will save the SPICE deck of the path (path_1_setup.sp) specified path in the specified directory (specified using –outdir option). By default, it will save the SPICE deck in ets_pathsim directory.

The user can run standalone path simulation using Spectre™ or any other simulator which understands SPICE syntax on the SPICE deck (path_1_setup.sp) saved by ETS.

Upon successful completion of path simulation, path_1_setup.measure file will be generated which can be used to extract results. Below is an example snippet of path_1_setup.measure file, which shows slew and delay measurement of two stages.

Slew/delay statements in spice deck have ‘slew’ and ‘delay’ words to identify the slew and delay numbers for the respective stages in timing path. This file can be easily post-processed to extract simulation results. For example, the sum of all ‘delay’ stages will give path delay of the total path.

So, using any of two methods explained above you can easily correlate your design results using this ETS feature. There is an excellent appnote written on this topic which not only explains the correlation flow and methodology in detail, but at same time showcases an example SPICE deck with reasonable descriptions of various important constructs. It also cleanly covers various debugging techniques that can be used to resolve the correlation issues encountered, if any.

Click to visit the appnote Base delay SPICE correlation In ETS

Cadence Online Support website http://support.cadence.com/ is your 24/7 partner for getting help and resolving issues related to Cadence software. If you are signed up for e-mail notifications, you've likely to notice new solutions, Application Notes (Technical Papers), Videos, Manuals, etc.

Hope you find this information useful.

Thanks

-Mukesh