Cadence Digital Implementation Blogs

Answers to Top 10 Questions on Performing ECOs in EDI System

wally1 — Wed, 17 Apr 2013 19:23:00 GMT

Applying ECOs to a design can be complex, stressful and error prone so it's important to apply the right tools and flow to implement the changes successfully. EDI System provides multiple ECO flows to physically implement ECOs efficiently and accurately based on your design requirements. And adding a tool such as Encounter Conformal ECO Designer or the Encounter Timing System's MMMC Signoff ECO capability can lead to faster design closure with fewer iterations.

I field many customer questions related to implementing physical ECOs with EDI System. In this blog I provide answers to 10 of the most common questions. Do you have any tips to share on performing ECOs with EDI System? If so, please post it as a comment below.

Thanks,

Brian

1. What's the best place to find details on how to perform ECOs in EDI System?

The EDI System User Guide has a chapter dedicated to ECO Flows (Cadence Online Support access required). It describes several flows depending on whether it is a pre-mask or post-mask ECO, whether the changes are coming from a new Verilog netlist, DEF or ECO file, and whether gate array cells are being used or not. If you are new to ECO flows in EDI System then the ECO Flows chapter is the place to start!

It's worth mentioning here ECOs can be implemented using the super-command ecoDesign or by running each command individually (init_design, ecoDefin, ecoPlace, ...). Both methods are described in the User Guide.

2. What's the difference between a pre-mask and post-mask ECO flow?

A pre-mask ECO is when you are making changes to the design before any masks have been made. With a pre-mask ECO you are free to make changse to any layer thus providing you more freedom to implement the ECO.

A post-mask ECO is when you are making changes to a design after masks have been made. Therefore, you want to limit the changes to specific layers so you do not need to re-make all the masks. In a post-mask ECO flow you can utilize existing spare cells which where placed in the design to avoid changes to layers Metal1 and below. You can also instruct the router to which layers it can use to perform ECO routing and which must remain frozen.

3. How do I apply changes made in my RTL to the physical design through ECO?

Encounter Conformal ECO Designer is recommended for performing complex ECOs originating from RTL. It interfaces with RTL Compiler and EDI System to perform the logical and physical ECOs while leveraging Conformal's logical equivalency abilities to ensure the ECO was successful for both the front-end and back-end signoff.

4. How does EDI System identify spare cells in a post-mask ECO flow?

Spare cells should have a unique string in their instance name to identify them. Then the command specifySpareGate or ecoDesign -useSpareCells patternName is run to identify the spare instances. For example, if all spare cells have _spare_ in their name then they are identified using:

specifySpareGate -inst *_spare_*

OR

ecoDesign -spareCells *_spare_* ...

Note if you are making manual ECO changes to a netlist and converting a spare cell to a logical instance, it's important to change the instance name. Otherwise, the instance may be identified as a spare cell if a future ECO is performed because it still has the spare cell instance name.

5. How does EDI System identify the changes in the design?

During the ecoDefin step the existing netlist (new netlist) is compared against the original placed and routed design. A summary of differences is output to the log file and a detailed report file is output to the local directory. You can review the report file to see a list of all the differences.

6. How do I use spare cells or gate array cells during placement?

Spare cells are identified using specifySpareGate. Then use the -useSpareCells true option when running ecoPlace to instruct it to swap the unplaced cells with spare cells of the same cell type:

specifySpareGate -inst *_spare_*
ecoPlace -useSpareCells true

Gate array style filler cells can be programmed with metal layers so the poly/diffusion and lower layers are not changed, and only the metal and via layer masks need to be modified. If you are using gate array spare cells the flow depends on the SITE type used by the gate array cells.

If your design has GA Cells which utilize a SITE type (i.e. GACORE) different from normal standard cells (i.e. CORE) then use:

ecoPlace -useGACells GACORE

If your design has GA cells which utilize the same SITE type as standard cells: ecoPlace -useGAFillerCells {List of GAFillerCells}

Reference the User Guide for the complete flow.

7. Is ecoPlace -useSpareCells true timing driven?

ecoPlace will choose the spare cells to minimize wire length but is not timing driven. After ecoPlace you can run ecoSwapSpareCell to relocate an instance to the location of another spare cell of the same type. Alternatively, you can run ecoRemap in place of ecoPlace. ecoRemap is timing driven and automatically analyzes the functionality of the newly added cells and remaps them to available spare cells. The software analyzes the logic and performs changes to improve timing and minimize DRVs.

8. How do I freeze certain metal layers during routing?

In a post-mask ECO Flow run ecoRoute with the -modifyOnlyLayers option to specify which layers it is allowed to modify. For example, to route using only Metal1 through Metal3:

ecoRoute -modifyOnlyLayers 1:3

9. How does ECO routing deal with metal fill?

When performing a post-mask ECO flow, ecoRoute will ignore the metal fill while routing. This will likely cause DRC violations between the ECO routes and metal fill. To fix these violations, run verifyGeometry followed by the the trimMetalFill command. This will cut back the metal fill from the ECO routing to fix the violations.

10. Does EDI System support interactive (maual) ECOs?

Yes, EDI System provides a number of interactive commands to both evaluate and commit ECO changes. See the Interactive ECO chapter of the EDI System User Guide for details.

When performing interactive ECOs make sure setEcoMode is set as desired. Here are some specific options to pay attention to and tips to speed up run time when implementing a series of ECOs:

setEcoMode -updateTiming - Default is false allowing you to wait until all ECOs are performed to run timing analysis. If set to true, timing analysis is run after each ECO command.
setEcoMode -honorDontTouch, -honorDontUse, -honorFixedStatus - The default for all of these is true. So if you find you cannot make a change, check if any of these apply.
setEcoMode -batchMode - Sets this to true to improve runtime if you are performing many ECOs.

Five-Minute Tutorial: Set Flip-Chip Bumps as Voltage Sources in EPS/EDI Rail Analysis

Kari — Tue, 26 Mar 2013 14:32:00 GMT

When running power and rail analysis for a flip chip, we used to have to spend some time creating the voltage sources. It wasn't too terrible; usually we would output the bumps into a Cadence Encounter Digital Implementation (EDI) .io file, then use a perl script to filter out the pwr/gnd bumps and create the voltage source file format. The script would need a bit of editing from project to project, but nothing too complicated. We ended up with a voltage source file, with one point-source per bump. However, it is much easier these days to create voltage sources for a flip chip to be used in the Cadence Encounter Power System (EPS) Rail Analysis (run either from EPS directly, or through EDI.) It is also more accurate, since the bumps get modeled with several points in a resistor network. (This will avoid false EM violations.)

The LEF file of your flip chip bump will be used as a reference. Bumps are usually octagonal, although sometimes are represented as squares. Here is an example bump LEF, which I will use to illustrate the process. (Note that a polygon shape is used to create an octagonal bump, but the corresponding coordinates that would have been used for a square are commented out.)

VERSION 5.6 ;
BUSBITCHARS "[]" ;
DIVIDERCHAR "/" ;
UNITS
DATABASE MICRONS 1000 ;
END UNITS
MACRO BUMP
CLASS COVER BUMP ;
FOREIGN BUMP -49.45 -49.45 ;
ORIGIN 49.45 49.45 ;
SIZE 98.9 BY 98.9 ;
PIN PAD
    DIRECTION INOUT ;
    USE SIGNAL ;
    PORT
      LAYER AP ;
        #RECT -49.45 -49.45 49.45 49.45 ;
        POLYGON -20.49 -49.45 20.49 -49.45 49.45 -20.49 49.45 20.49 20.49 49.45 -20.49 49.45 -49.45 20.49 -49.45 -20.49 ;
    END
END PAD
END BUMP
END LIBRARY

First, create a file called bump.padfile. This file contains one line, the MACRO name of the bump from the LEF. It should look like this:

BUMP

Next, create a file called bump.srcfile. It should look like this:

CELL BUMP
NET PAD
PORT {
AP -49.45 -49.45 49.45 49.45
}

Make sure the CELL and NET names match your bump LEF. The NET name is the PIN name from the LEF. The port layer name (AP here) is the same layer from the LEF. Remember the commented-out square coordinates that I mentioned in the LEF example above? Here is where that's useful: the coordinates of the PORT shape should be a square that encloses the octagonal bump.

Now, create the bump powergrid view. Here is a sample script, called create_bump_pwrgrid.ss0p81v.tcl:

read_lib -lef tech.lef \
   BUMP.lef
set_power_library_mode \
    -accuracy fast \
    -celltype allcells \
    -extraction_tech_file cworst.qrcTechFile \
    -lef_layermap lef_layer.map \
    -generic_power_names {VDD 0.81} \
    -generic_ground_names {VSS} \
    -input_type pr_lef
characterize_power_library \
    -celllist_file bump.list \
    -padvsrcfile bump.srcfile \
    -libgen_command_file libgen.inc \
    -output_directory fast_bump.ss_0p81v

A few notes about the files referenced in this script:

The bump.list file just contains the bump name and is actually the same as the bump.padfile.
For an example of the lef_layer.map file, see my last blog, Five-Minute Tutorial: Create Encounter Power System (EPS) Power-Grid Views For Standard Cells.
The libgen.inc file looks like this (again, the cell and net name should match the bump LEF):
cell_common_supply_names cell BUMP nets {PAD}

Finally, when running rail analysis, use the bump.padfile in your set_power_pads command. The same padfile can be used for any rail:

set_power_pads \
-net VDD \
-format padcell \
-file bump.padfile

set_power_pads \
-net VSS \
-format padcell \
-file bump.padfile

All bumps will then be recognized as voltage sources, with multiple points inside the bump shape. I hope this has helped simplify your rail analysis flow!

- Kari Summers

CDNLive High-Performance Track: Do You Have What it Takes to Get Your High-Performance SoC to Market?

Vasu Madabushi — Mon, 11 Mar 2013 04:58:00 GMT

Implementing SoCs with embedded processors at advanced nodes has become increasingly difficult. This is due to the complexity of the design functionality as well as the low power and increased performance requirements driven by a plethora of end-user applications in modern hand-held devices. Path-breaking trends in ARMv8 64-bit processor based microservers for power efficient cloud computing/data centers and high-end content generating superphones and tablets have thrown new curveballs at chip designers. As we're aware, battery technology hasn't kept pace with Moore's Law and as a result some amazing recent advances in process technology (such as FinFET, double patterning, etc.) and EDA tools are helping offset the difficulties in designing power efficient yet high-performance SoCs.

I'm really pleased to see a lineup of exciting papers in the High-Performance Digital Implementation track at the upcoming CDNLive Silicon Valley in Santa Clara, March 12, from some of the heavy hitters in the industry. These presentations describe the implementation of SoCs for a multitude of designs such as ARM Cortex-A core-based applications processors with state-of-the-art GPUs for demanding high-end smartphones and tablets; the world's first multi-Gigahertz ARMv8 64-bit processor architecture based server-on-chip for cloud computing/data centers; and complex networking ASICs, to name a few.

Rounding off the sessions are interesting papers from ARM on implementing their latest 64-bit Cortex-A57 processor based on the ARMv8 architecture and processor optimization pack (POP) IP development for ARM's big.LITTLE^TM paradigm -- with Cortex-A15 and Cortex-A7 processors respectively -- with Cadence's Encounter digital flows. These presentations exemplify the strong partnership and collaboration between ARM and Cadence in developing implementation reference methodologies (iRM) that ease designing ARM processors into leading-edge SoCs and accelerate time-to-market.

A common thread that the audience will hear is the significant power, performance and area (PPA) improvements customers have been able to achieve with some of the key Cadence tools such as RTL Compiler-Physical (RCP) and Encounter Digital Implementation (EDI) System featuring the latest GigaOpt physical optimization and Clock Concurrent Optimization (CCOpt) technologies. RCP, GigaOpt and CCOpt form the three pillars of Cadence's strong offering for implementing complex and high-performance designs in silicon. Some of the key advances include extending GigaOpt to the entire optimization flow (pre- and post-route) with full multi-CPU support, route-driven and layer-aware optimization at advanced nodes, and native integration of CCOpt in EDI, all leading to significant PPA improvements. Stop by the Cadence booth at the partner expo to learn more about the upcoming EDI release 13.1 highlights!

I've always been fascinated by our customers' end-products and verticals (going beyond just chip design and into adjacencies) where Cadence's tools have been used for bleeding-edge designs. So when companies such as AppliedMicro, ARM, Avago and NVidia come to town to graciously share their design experiences, one can't help but sit up and take notice! CDNLive gives a wonderful opportunity for attendees to understand the intricacies behind implementing these complex SoCs, including the challenges faced-from synthesis, design planning to final implementation, signoff and everything in between-and how they surmounted them. Key takeaways include lessons learned and best practices that the audience can readily deploy into their own designs and methodologies. That's the beauty of CDNLive-it provides ample opportunities to learn from fellow designers while extending one's professional network. What more can you ask for?

On Wednesday, March 13, the R&D luncheon offers a unique opportunity for our customers to sit down with our R&D and product engineers to discuss the chip-design problems of the day. We've set up thematic tables to cater to different areas of focus, including Advanced Node (28/20/16/14nm), Clock Concurrent Optimization, Implementing GHz+ ARM Cortex-A processor based designs, low-power, mixed-signal, signoff, and more! This offers an informal atmosphere for Cadence to also better understand our customers' requirements.

Here's a sneak peek into the paper presentations in the high-performance track on March 12, 2013:

In Session HP105 (4:45-5:35pm), Sumbal Rafiq of AppliedMicro will present "X-Gene: Realizing a complex high-performance and power efficient 64-bit multicore ARMv8 based server-on-chip solution in silicon". This revolutionary multi-gigahertz design targets the extremely demanding cloud-computing/datacenter market. With multi-core ARMv8 CPUs, network interface controller (NIC), high-speed interconnect fabric, memory and other peripherals, the design complexity has reached unprecedented levels, throwing several new challenges in chip integration and meeting stringent PPA metrics. AppliedMicro and Cadence have collaborated from an early stage of development to deploy an RTL-to-GDSII flow based on Cadence's Encounter Digital tools to successfully implement and tape out the design. The proof's in working silicon!
Session HP 104 (9:00-9:50am) titled "High Performance/Low Power Implementation of ARM Cortex-A15 and Cortex-A7 with ARM POP IP for ARM big.LITTLE Systems and Applications" will be presented by Sathyanath Subramanian from ARM. Sathya will talk about ARM's big.LITTLE heterogeneous processing concept and how the ARM POP IP optimized with Cadence's flows at advanced nodes provides designers a head start and a PPA boost for implementing designs with Cortex-A15 and Cortex-A7 processors.
In Session HP103 (2:30-3:20pm), Brent McKanna of ARM will present Targeting High Frequency and Power Efficient Implementations for ARM's High Performance Cortex-A57 Processor. Cortex-A57 is ARM's latest and highest performing ARMv8 64-bit processor targeting the enterprise server and high-end smartphone/tablet applications, where maintaining high power efficiencies at superior performance points are critical. ARM and Cadence have collaborated throughout the development of Cortex-A57 to create an RTL-to-signoff flow based on Cadence Encounter design tools. The paper describes the techniques used for handling the increased complexity of larger ARM cores and for closing designs on advanced nodes such as 28nm.
Session HP102 (1:30-2:20pm) titled Advanced Strategies for Timing Closure Utilizing New GigaOpt Features will be presented by Jack Benzel of Avago Technologies. Given the explosive growth in the number of large memory macros and the growing dominance of RC delays limiting long-haul wire performance at advanced nodes, new strategies are required to address low-latency architectures. Jack's paper will cover several of EDI System's new GigaOpt features including low-RC layer promotion, advanced re-buffering, TNS focus, path balancing, and path compaction. Get exposed to real-world 28nm examples demonstrating before/after QOR improvements.
In Session HP101 (3:45-4:35pm), Santosh Navale of NVidia will present Implementing high performance GHz+ mobile applications processors and GPU with clock concurrent design techniques. Hear about how NVidia changed their clocking methodology to tackle several hundred complex generated and interacting clock signals, which form the back-bone of modern applications processors. Hear how they handled on-chip-variation, complex clock gating, multi-mode/multi-corner, and low-power requirements while improving chip performance with the Cadence clock concurrent optimization (CCOpt) technology on multi-Gigahertz ARM CPU based mobile applications and GeForce GPU processors.

Registration and program information for CDNLive Silicon Valley is available here.

Vasu Madabushi

Five-Minute Tutorial: Create Encounter Power System (EPS) Power-Grid Views For Standard Cells

Kari — Fri, 22 Feb 2013 16:54:00 GMT

In today's tutorial, I'm giving you a sample EPS (Encounter Power System) script that you can use to generate power-grid views for your standard cells. Power-grid views are used during rail analysis, with IR-Drop and EM (electromigration/current density) being the two most popular analysis types.

First, the LEF information is read in. The technology LEF needs to be read in first, then the LEF files of your standard cell libraries:

read_lib -lef tech.lef \

stdcell_hvt.lef \

stdcell_lvt.lef

Next, we tell EPS what kind of views we want to create. We're creating accurate standard cell views using the LEF models. We also need to point to the QRC extraction tech file, list all of our power/ground names (you may or may not have bulk pwr/gnd - you can leave that out if not), and include a layer mapping file.

set_power_library_mode \

-accuracy accurate \

-celltype stdcells \

-extraction_tech_file tt_qrcTechFile \

-lef_layermap lef_layer.map \

-generic_power_names {VDD 0.90 VDD_SW 0.90 VDDG 0.90} \

-generic_ground_names {VSS} \

-generic_bulk_power_names {VNW 0.90} \

-generic_bulk_ground_names {VPW} \

-default_power_voltage 0.90 \

-input_type pr_lef

Below is an example of the lef_layer.map file. The second column is what the metal and via layers are called in the QRC extraction tech file, and the fourth column is what the metal and via layers are called in the technology LEF. (The QRC techfile is not an ASCII file, but you can find the names in the .ict text file that usually comes with the QRC techfile.) In this example, the names happened to be the same between the QRC tech file and the technology LEF, but many times the layer/via names differ, especially for the upper layers.

metal M1 lefdef M1

metal M2 lefdef M2

metal M3 lefdef M3

metal M4 lefdef M4

metal M5 lefdef M5

metal M6 lefdef M6

metal M7 lefdef M7

metal M8 lefdef M8

metal AP lefdef AP

via VIA1 lefdef VIA1

via VIA2 lefdef VIA2

via VIA3 lefdef VIA3

via VIA4 lefdef VIA4

via VIA5 lefdef VIA5

via VIA6 lefdef VIA6

via VIA7 lefdef VIA7

via RV lefdef RV

Finally, we can issue the characterize_power_library command which is what creates the power-grid views. The filler cells and decap cells are specified, as well as any powergate cells. (If you're not working on a power-shutoff design, you can leave out the detailed_powergate option.) We also provide the SPICE model file from the foundry, the SPICE subckt cells for our standard cells, and list the SPICE sections that contain the devices in our standard cells. (That part involves some trial and error - the first time you run the script, you may get errors for devices that are undefined. Search for those devices in the spice model file, then include the section they are found in, such as "ttg_hvt".) You'll notice we reference a "stdcell.list" file - this is a simple text file with one std cell name per line.

characterize_power_library \

-celllist_file stdcell.list \

-library_name accurate_std.tt_0p90v \

-filler_cells { FILL* }

-decap_cells { DCAP* }

-detailed_powergate { \

{HEADBUFx16 VDDG VDD} \

{HEADBUFx32 VDDG VDD} \

} \

-spice_models cln28hpm_1d8_elk_v1d0_2p1.l \

-spice_corners {ttg ttg_lvt ttg_hvt TT TT_hvt TT_lvt Total Total_lvt Total_hvt} \

-spice_subckts { \

stdcell_hvt_typical_25c.spice \

stdcell_lvt_typical_25c.spice \

}

To run the script (let's call it create_stdcell_pgv.tt.tcl), just start EPS and type:

source create_stdcell_pgv.tt.tcl

The resulting power-grid library from this sample script can be used for power and rail analysis in the tt_0p90v corner. You'll need to create a power-grid view library for each process/voltage you want to run power analysis in. So if you need to run IR-drop in the ss_0p81v corner, for example, make a copy of the script and edit it to refer to ss SPICE models, the ss qrcTechFile, and change all the voltages to 0.81.

Once the script completes successfully, check the .report file that was generated to make sure that your cells report PASS. If you're using powergate cells, make sure they were recognized as such.

I hope this has provided a quick-start to getting your standard cell power-grid views created!

- Kari Summers

Here's the whole script at once, so you can just cut and paste into a file, and start editing for your specific design.

read_lib -lef tech.lef \

stdcell_hvt.lef \

stdcell_lvt.lef

set_power_library_mode \

-accuracy accurate \

-celltype stdcells \

-extraction_tech_file tt_qrcTechFile \

-lef_layermap lef_layer.map \

-generic_power_names {VDD 0.90 VDD_SW 0.90 VDDG 0.90} \

-generic_ground_names {VSS} \

-generic_bulk_power_names {VNW 0.90} \

-generic_bulk_ground_names {VPW} \

-default_power_voltage 0.90 \

-input_type pr_lef

characterize_power_library \

-celllist_file stdcell.list \

-library_name accurate_std.tt_0p90v \

-filler_cells { FILL* }

-decap_cells { DCAP* }

-detailed_powergate { \

{HEADBUFx16 VDDG VDD} \

{HEADBUFx32 VDDG VDD} \

} \

-spice_models cln28hpm_1d8_elk_v1d0_2p1.l \

-spice_corners {ttg ttg_lvt ttg_hvt TT TT_hvt TT_lvt Total Total_lvt Total_hvt} \

-spice_subckts { \

stdcell_hvt_typical_25c.spice \

stdcell_lvt_typical_25c.spice \

}

exit

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

Five-Minute Tutorial: Creating An EM Model File

Kari — Mon, 14 Jan 2013 17:06:00 GMT

One of the least-fun parts of running power and rail analysis has always been coming up with the electromigration (EM) model file. In the past, this involved cracking open the process design rule manual, finding the appropriate equations, and creating a spreadsheet to calculate all the numbers needed for the various metal width and via sizes. Then, this information had to be put in the format of the model file used by Encounter Digital Implementation System (EDI) and Encounter Power System (EPS). This approach was prone to errors and involved some user decisions about what exactly to model. Frustrating, but it worked for the most part.

Now there is an easier way to get this information into an automatically-created EM model file if you are using a TSMC process. You'll need the iRCX file (also referred to as a unified tech file) from TSMC, and you'll need to locate both your extraction installation and your EDI installation.

When you request the iRCX information from TSMC, it may come in a directory that needs to be unzipped and untarred. Ultimately, you're looking for a file that's named something like IRCX_28NM_8M_typical.ircx. Make sure you have the right file for your process, metal stack, and extraction corner.

To locate your extraction installation, type:

>which qrc
/apps/PVE111/11.11.238/bin/qrc

To locate your EDI installation, type:

>which encounter
/apps/EDI110/11.12.000/tools/bin/encounter

Now, you'll run two translators. The first comes from the extraction installation and is called ircxtoict. This translates the iRCX file into the .ict format:

>/apps/PVE111/11.11.238/bin/ircxtoict -i IRCX_28NM_8M_typical.ict IRCX_28NM_8M_typical.ircx

Now that you have an .ict file, you can use the second translator, which comes from your EDI installation, to create the EM model file. But first, you'll need to create a small text file called conductor.widths (or another name of your choice). It looks something like this, with the order of each line being <metal_layer> <min_width> <max_width>. The width values are in microns:

M1 0.05 4.5
M2 0.05 4.5
M3 0.05 4.5
M4 0.05 4.5
M5 0.05 4.5
M6 0.05 4.5
M7 0.40 12.0
M8 0.40 12.0
AP 2.00 35.0

The metal layer names come from the .ict file, and the min and max widths come from the tech LEF. (Note that the metal layer names may differ between the .ict file and your tech LEF.)

Now we're ready for that second translator, called ict2emfiles. It converts the newly-created .ict file to the EDI/EPS EM model file format:

>/apps/EDI110/11.12.000/share/anls/gift/bin/ict2emfiles -eps -i IRCX_28NM_8M_typical.ict -w conductor.widths

This will result in a file called IRCX_28NM_8M_typical.ict.em_model, which you can then use during the RJ analysis in EDI/EPS.

This method saves a lot of time and removes potential sources of error. I was very happy to be able to create my EM model file this way, and I hope others will find this useful as well.

- Kari Summers

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

The Case for the Tiny Testcase

BobD — Fri, 16 Nov 2012 14:56:00 GMT

I often joke with customers that, although I realize they have to work on large designs, I do my best work on designs with just 2 or 3 instances. That's because I'm often trying to replicate an issue they've observed on their design and I'm attempting to reproduce that behavior in a smaller circuit. I've found tiny testcases to be extremely efficient ways to gain quick clarity on tool behaviors which can then be more effectively applied to the real design. But it's not just having a tiny testcase that's most useful. It's the act of creating the small testcase where most insight is gained.

But it's not always easy to create a tiny testcase. Do you know how to write a syntactically correct gate-level Verilog netlist from scratch with a text editor? Do you know how to contrive complicated timing scenarios? Do you know to modify .lib/LEFs to replicate the things likely present in a design in a smaller setting? These are non-trivial things for someone who works in many different aspects of a design flow as designers are tasked with understanding an ever-increasing breadth of tools.

I recall a quote from a colleague of mine, Thad McCracken (interview here), a few years ago. We were working on a benchmark and were having a hard time reproducing some of the issues we were observing in a small testcase. He said "If we can't reproduce it in a small testcase it tells me we fundamentally don't understand the problem well enough."

Isn't that the truth of it? With the exception of run-time/memory related issues, nearly every issue we run into can be replicated in a tiny representative testcase -- but doing so can be very difficult.

Customers often joke with me that the oldest tricks in the EDA Applications Engineering books are (1) to ask if you're using the latest tool version and (2) ask for a testcase. Sure it's easy to get a self-contained testcase with Encounter (see the link for saveTestcase at the end of this post). But a better question to ask is, "Do you have any hunches on the likely circumstances causing the issue?"

Tiny testcases can be powerful in the user community as well. Some of the most disciplined and effective project teams and CAD groups I've worked with relentlessly stress the tool at the onset of a project in ways they're going to need it to perform during crunch time. Sure, some things only come to light in the context of real designs. But creating tiny testcases can efficiently flush out the gaps between project requirements and tool capabilities to give everyone a chance to find ways to get the software to do what it needs to do to meet project requirements.

In our busy schedules we often feel like we don't have time to create small testcases to triage a situation. And indeed, sometimes we just need to send a testcase in to R&D for resolution. But next time you run into an issue I'd encourage you to consider whether a tiny testcase might shed more light on the situation.

To borrow a line from Paul Cunningham: "Sometimes we need to slow down to speed up."

-Bob Dwyer

Related Reading:

Transitioning Your LEF-Based EDI System Design Flow to OpenAccess

wally1 — Mon, 12 Nov 2012 14:00:00 GMT

The trend of combining analog and digital circuits on a single chip has been growing for several years. More recently I'm seeing more and more designers improve their productivity by transitioning their designs to Open Access (OA) and taking advantage of the interoperability between Virtuoso and the Encounter Digital Implementation (EDI) System. Whether you're performing floorplanning in Virtuoso (schematic-driven flow) or EDI System (netlist driven flow), OA allows you take advantage of interoperability features such as seamlessly defining and passing routing constraints. The Mixed Signal Interoperability Guide (Cadence Online Support account required) is the resource I turn to frequently when I have questions on the mixed-signal flow. Formal training is also available through the Analog-on-Top Mixed-Signal Implementation class.

In this blog I want to focus on data preparation and highlight the steps involved to create a common PDK to be used by Virtuoso and EDI System. This involves translating the LEF files to OA, then reconciling the differences between your base PDK and the OA database created from the LEF. Once these differences are resolved, I explain how to load the design into EDI System references the OA libraries.

Converting LEF to OA

The first step is to create a LEF-compatible PDK which Virtuoso and EDI System can use. This is typically defined in 1 of 2 ways:

1. A single PDK containing the base PDK information plus the LEF rules and vias required for physical design.

A single PDK is not flexible. For example, if you have to add a custom via or routing constraint you must modify this main PDK which may cause problems for other users.

2. Define the LEF rules and vias in an Incremental Technology Database (ITDB) which references the base PDK.

An ITDB is more flexible because updates can be made directly to the ITDB without effecting the base PDK. You can also define multiple ITDBs which reference the same base PDK.

The ITDB is typically created by converting the technology LEF to OA using the lefin command found in the Virtuoso installation. To create an ITDB from tech.lef referencing the basePDKLib you would run:

lefin -lef tech.lef -lib techLib -refLib basePDKLib

The LEF files defining the standard cells, hard macros and IO cells are then converted to OA using lefin:

lefin -lef stdcells.lef -lib macroLib -refLib techLib
lefin -lef memories.lef -lib macroLib
lefin -lef io.lef -lib macroLib

After the LEF files are transferred to OA run verilogAnnotate to indicate the bit order for busses:

verilogAnnotate -refLibs macroLib -verilog macros.v -refViews layout

Reconciling the ITDB with the Base PDK

Often the LEF technology data and the base PDK are not consistent and you must reconcile their differences. For example, layer names, units or manufacturing grid may differ. For more details on creating a LEF-compatible PDK see the application note Open Access Reference Library Import on Cadence Online Support.

Another useful way to debug differences is compare your original technology LEF to the LEF generated from the OA tech file you've created. You can use the write_lef_library command to compare these LEFs. write_lef_library writes out LEF syntax in a consistent order for easy comparison using the diff command. Below is an example flow to compare the LEF files. See the next section for details on specifying the variables to import an OA based library.

Validation of LEF versus OA

Generate a LEF based on your original tech LEF:

# setup Tcl variables for reading the LEF based design
init_design
write_lef_library from_lef.lef
exit

Generate a LEF based on the OA technology file:

# setup Tcl variables for OA based library using the same Verilog
# and timing libraries
init_design
write_lef_library from_oa.lef
exit

Now run diff to compare the LEF files and investigate the differences:

diff from_lef.lef from_oa.lef

Look for things such as rules and vias defined in one file but not the other. Also, review rules which are the same but have different values specified.

Reading in the Design

After all the LEF libraries are converted you are ready to read in the design. This can be done by reading in the OA libraries + Verilog or read the libraries and design from OA.

Reading in OA Libraries and Verilog Netlist

Following are the variables to set to read in a design using OA libraries and a Verilog netlist:

# Library variables:
set init_oa_ref_lib {techLib macroLib}
set init_layout_view {layout}
set init_abstract_view {abstract}
# Design variables:
set init_verilog {netlist.v}
set init_design_settop 0
set init_top_cell {top}
# Set other init_design variables for global vars, timing, etc.
init_design
# Save the design to OA using saveDesign {lib cell view}
saveDesign -cellview {designLib top preplace}

Reading in OA Libraries and OA Design

Following are the variables to set to read in a design using OA libraries and OA design:

# Library variables:
set init_oa_ref_lib {techLib macroLib}
set init_layout_view {layout}
set init_abstract_view {abstract}
# Design variables:
set init_design_netlisttype {OA}
set init_oa_design_lib {designLib}
set init_oa_design_cell {top}
set init_oa_design_view {layout}
# Set other init_design variables for global vars, timing, etc.
init_design
# Save the design to OA using saveDesign {lib cell view}
saveDesign -cellview {designLib top preplace}

And there you go. I hope this overview helps you understand the data preparation steps involved creating a LEF-compatible PDK and encourages you to utilize OA to take advantage of Virtuoso and EDI System's interoperability. Be sure to leverage the resources I reference above to help your transition go smoothly.

Thanks,
Brian Wallace

Five-Minute Tutorial: Why You Should Be Running Early DRC

Kari — Thu, 11 Oct 2012 19:42:00 GMT

Everyone knows you have to run signoff DRC before you tape out a design. Sometimes, DRC is left to exactly that moment - right before the tapeout. If major problems are found in the design at that point, the tapeout either has to be delayed, or there is a mad scramble to fix the issues. This is a situation no one wants to find themselves in.

Running DRC early and often is very much worth the effort. In addition to the general benefits of having the DRC deck and flow set up early so that it's pushbutton later in the project (there are often switches for metal stack, RDL type, bump pitch, etc that need to be selected), I recommend running DRC at the following milestones:

Power grid in place, no cell placement or signal routing. Hard macros/IP may be placed.

Running DRC here will make sure that your power grid is DRC clean. It can be very costly to have to fix power grid issues around signal routing late in the flow. Also, a majority of DRC issues can occur in power grid vias. Getting this clean early will put you ahead of the game. If your memories/IP/other macros are already placed, you'll be verifying the power connections to them as well, and you'll also make sure they are placed far enough apart from each other.

All cells placed (including macros/IP and filler cells), but no signal routing.

Checking DRC at this point is critical. You need to make sure you have all required welltaps and/or endcaps, and that they are spaced appropriately. Having to fix this later in the flow will mean moving functional cells and affecting your timing. You also want to make sure that any IP or memory blocks have the appropriate spacing between each other and to standard cells. Alignment marker cells are required in many processes, so you'll want to check that you've got that right as well. Don't forget to add standard cell fillers before this run! If you leave out the fillers, you'll have a ton of DRC violations to wade through! You also want to make sure your fill methodology follows any VT spacing rules, and the no-filler1 rule if that exists for your process. (For more info on that particular issue, see Five-Minute Tutorial: Avoiding The Use Of FILL1 Cells.)

As soon as you have the first cut of the design with all cells placed and all signal routing complete.

This can be a big one too. If this is a new process, you may be vetting the LEF routing rules. In a tested process, the routing will usually be ok, but you may have routing access issues to memories or IP that may be using outdated blockage methods. I see a lot of this with memories where the blockage does not go to the edge of the block (the recommended method) so that NanoRoute can access the pins in a planar fashion. You may need to edit the macro blockages, and you'll want to do this at the beginning of the project when you're not in so much of a rush.

After the first pass of metal fill.

I often see DRC violations regarding metal fill spacing from the edge and corners of the design. If you're using a signoff fill utility, you probably don't need to worry about this. But most of the time, metal fill is done in Encounter Digital Implementation System (EDI) so that the timing effects can be seen easily. In that case, you may need to add some routing blockage or adjust your fill settings to get DRC-clean fill. It's also important to make sure you're hitting the metal density targets. A special note: be on the lookout for MAX density violations! It can and does happen, and it's harder to fix than min density.

If you've done all this, then you can continue intermediate DRC checks as you near tapeout and you shouldn't have that much to fix in the final days of your design.

EDI users will be familiar with the verifyGeometry command. I highly recommend running this before you start any of the DRC runs listed above! The verifyGeometry function is not a complete signoff check, but it will point out almost all of your metal DRC issues (and also shorts). Signoff DRC is still needed to check layers below M1 (since EDI uses LEF and not full layouts). But if you proceed to DRC without running verifyGeometry, you're not saving yourself any time. Fix what you can in EDI with verifyGeometry first; then you'll be in very good shape for early DRC!

You may also be interested in this post: Simple Steps To Debug DRC Violations Undetected In EDI System.

- Kari Summers