You may have noticed that in the Encounter Digital Implementation (EDI) System 11 the commands addCustomBox, addCustomLine and addCustomText are no longer in the documentation. These previous commands weren't cutting it when it came to the features customers wanted and were not supported by OpenAccess or database commands like dbGet. So they've been replaced in EDI 11 by the commands add_shape and add_text. I think you will like the expanded features and database support of these new commands over their predecessors. Following are some of the highlights. Note the previous addCustom* commands will still work in EDI 11 but may be disabled in the future.

add_shape

Use add_shape to add custom retangles, polygons and path segments to your design. These shapes are represented as Special Nets (snet) in the database. Use the -net option to specify the net name to associate the shape to. If -net is omitted the shape is assigned the net name _NULL to indicate it is floating. This allows you to still access the shape through database commands (i.e. dbGet).

As you can see below add_shape has significantly more features compared to addCustomBox:

Here's an example of adding a rectangle for net VDD on layer M1:

     add_shape -net VDD -layer M1 -rect {1 1 25 9}

When adding path segments you can specify begin and end extension values. The extensions can be any positive value which is on the manufacturing grid. Also, paths are center-line based so in the example below X=2.5 is where I want the center of the wire. Here's an example of adding a vertical segment on M1:

     add_shape -net VDD -layer M1 -pathSeg {2.5 1 2.5 25} -width 3 -beginExt 0 -endExt 0

Combining add_shape with dbGet leads to some nice automation. For example, say I select the rectangle and path I created above. I can then create a polygon on M3 overlapping them using:

     add_shape -polygon [lindex [dbShape [dbGet selected.polyPts -i 0] OR [dbGet selected.polyPts -i 1] \

     -output polygon] 0] -layer M3 -net VDD

As I mentioned above these shapes are represented as special nets so you can use commands such as editSelect, editDelete, etc. with them just like other special nets.

Here is an example of how the above shapes are represented in DEF:

     SPECIALNETS 2 ;

     ...

     - VDD

       + POLYGON Metal3 ( 50000 18000 ) ( 8000 18000 )

         ( 8000 50000 ) ( 2000 50000 ) ( 2000 2000 ) ( 50000 2000 )

      + ROUTED Metal1 6000 ( 5000 2000 0 ) ( * 50000 0 )

       + RECT Metal1 ( 2000 2000 ) ( 50000 18000 )

       + USE POWER

      ;

     END SPECIALNETS

Another nice feature of add_shape is it will return the pointer of the new object. For example:

     encounter 42> set rectPtr [add_shape -rect {10 10 12 12} -layer M4]

     0x2aaab3eb8fd0

     encounter 43> dbGet $rectPtr.??

     beginExt: 0

     box: {10 10 12 12}

     endExt: 0

     geomType: rect

     layer: 0x1a7afa48

     net: 0x2aaab3834ef8

     objType: sWire

     polyPts: {{10 10} {12 10} {12 12} {10 12}}

     pts: 0x0

     shape: notype

     shieldNet: 0x0

     status: routed

     subClass: {}

     width: 2

Lastly, you stream out the objects to GDS just like other special nets.

     # streamOut map file:

     M1  SPNET  1  0

add_text

Use add_text to add custom text on the desired layer. You can see below add_text has significantly more features than addCustomText had:

For example, to add text on layer M1:

     add_text -label "Hello World!" -pt {1 1} -layer M1

When you add text to a specific layer its visibility/selectability is controlled by both the layer and the overall text control.

You can also omit the layer. When you do this the text is added to the general text layer:

     add_text -label "Hello World!" -pt {1 1}

Below is the respective stream out mapping depending on whether the text is on a metal layer or the general text layer:

     # Mapping text of a specific metal layer:

     M1    TEXT  1  0

     # Mapping general text:

     text  TEXT  2  0

Note: If you specify values for font, height, orientation, or alignment it will not be reflected in the EDI System GUI. EDI will display it in the default values. But these properties are saved for Open Access interoperability with Virtuoso. So if you open the design in Virtuoso you'll see the text displayed as you specified.

Brian Wallace

Querying the Encounter database with dbGet is typically pretty concise to begin with. But you might not be aware of its support for expression-based matching, which enables even more compact scripting.

Let's take a very simple but common scripting challenge: Finding all of the high fanout nets in the design.

Then let's take this a little further. How would we write a script to find all nets with fanout greater than "n" which are not clock nets?

Historically we'd do this by iterating through all of the nets in the design, checking whether their fanout is greater than "n", checking whether it is marked as a clock net, and if so add it to a list of nets that meet the criteria. This would take about a half-dozen lines of code.

But by using dbGet's support for expression-based matching, we can make this script more compact. Here's how it works.

First, let's look at how we'd write this script without expressions:

set high_fanout_nets {}
foreach net [dbGet top.nets] {
  if {[dbGet $net.numInputTerms] > 32} {
    if {![dbGet $net.isClock]} {
      lappend high_fanout_nets $net
    }
  }
}
return $high_fanout_nets

Here's how we'd write the same functionality using dbGet's expression-based matching:

encounter 1> dbGet top.nets {.numInputTerms > 32 && .isClock == 0}

Much more compact, right?

So here's how it works, step by step. The attribute ".numInputTerms" gives us, effectively, the fanout for each net. If we were to query that attribute for each net we'd get a list of numbers representing the fanout of each net in the design:

encounter 2> dbGet top.nets.numInputTerms
5 5 1 16 32 32 16 33 19 17 18 21 20 21 20 20 71 17 17 8 16 16 32 16

We more commonly use "simple" matching to find things we're looking for like object names, and testing for 1's and 0's. And we could certainly do that with the .numInputTerms attribute:

encounter 3> dbGet top.nets.numInputTerms 32
32 32 32 32 32 32 32 32

And if we wanted to get the pointers to those nets we could do it like this:

encounter 4> dbGet top.nets.numInputTerms 32 -p
0x2aaab4252f38 0x2aaab20acbe8 0x2aaab20acf30 0x2aaab215fc88 0x2aaab2160078 0x2aaab21faa00 0x2aaab21faca0 0x2aaab21fcab8

And if we wanted to get their names we could do it like this:

encounter 5> dbGet [dbGet top.nets.numInputTerms 32 -p].name
DTMF_INST/TDSP_CORE_INST/ALU_32_INST/n_3062 DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/n_896 {DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/nbus_426[0]} DTMF_INST/TDSP_CORE_INST/TDSP_CORE_GLUE_INST/n_1213 DTMF_INST/TDSP_CORE_INST/TDSP_CORE_GLUE_INST/n_1357 DTMF_INST/RESULTS_CONV_INST/n_2516 DTMF_INST/RESULTS_CONV_INST/n_2521 DTMF_INST/RESULTS_CONV_INST/n_2512

But if we want to get more sophisticated we can use dbGet expression matching. The first thing to notice is the unique syntax these expressions use. If we want to do the same as we did a couple examples back -- ie, get the pointers to all nets with a fanout of 32 -- here's how we do it with expression matching:

encounter 6> dbGet top.nets {.numInputTerms == 32}          
0x2aaab4252f38 0x2aaab20acbe8 0x2aaab20acf30 0x2aaab215fc88 0x2aaab2160078 0x2aaab21faa00 0x2aaab21faca0 0x2aaab21fcab8

Notice that we select the attribute to match on with ".numInputTerms", then the criteria ("==" in this case), then the value. And we wrap it all in "{}". Note also that dbGet automatically returns pointers in this mode and doesn't require a "-p".

From there we can make it more complex, with a greater than rather than equal:

encounter 7> dbGet top.nets {.numInputTerms > 32}           
0x2aaab3c5c928 0x2aaab3c5c9d0 0x2aaab3cf7898 0x2aaab3cf8c48 0x2aaab40e5890 0x2aaab42533d0 0x2aaab4253a60 0x2aaab44474b0 0x2aaab20ad080 0x2aaab20adc38 0x2aaab20c4180 0x2aaab20c44c8 0x2aaab21fb288 0x2aaab21fbfa8

Or combine two expressions to match the nets with fanout greater than "n" which are not marked as clock nets:

encounter 8> dbGet top.nets {.numInputTerms > 32 && .isClock == 0}
0x2aaab3c5c928 0x2aaab3c5c9d0 0x2aaab40e5890 0x2aaab42533d0 0x2aaab4253a60 0x2aaab44474b0 0x2aaab20ad080 0x2aaab20adc38 0x2aaab20c4180 0x2aaab20c44c8 0x2aaab21fb288 0x2aaab21fbfa8

If we wanted to get the names of these nets we could wrap it within another call to dbGet:

encounter 9> dbGet [dbGet top.nets {.numInputTerms > 32 && .isClock == 0}].name
test_modeI scan_enI {DTMF_INST/TDSP_CORE_INST/alu_cmd[1]} DTMF_INST/TDSP_CORE_INST/ALU_32_INST/n_1716 DTMF_INST/TDSP_CORE_INST/ALU_32_INST/n_1738 DTMF_INST/TDSP_CORE_INST/MPY_32_INST/n_268 {DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/nbus_440[0]} DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/n_4221 DTMF_INST/TDSP_CORE_INST/DECODE_INST/n_4475 DTMF_INST/TDSP_CORE_INST/DECODE_INST/n_181 DTMF_INST/RESULTS_CONV_INST/n_2509 DTMF_INST/RESULTS_CONV_INST/n_6011

I hope this is helpful in making your scripting within Encounter more compact. Check back next time and I'll show how to write these nets to a file, one net name per line by using redirect and a couple of tricks.

I'd love it if you subscribed to the Cadence Digital Implementation blogs for notification of new posts.

Question of the Day: Have you found cases where dbGet's expression based matching is particularly useful?

-Bob Dwyer

In this blog post I want to highlight the command get_metric that was introduced in Encounter Digital Implementation (EDI) System 10.1 and enhanced further in version 11. Have you ever tried writing a script to extract information from the log file like run times or timing results? It becomes complicated quite fast when you're trying to capture the desired data, especially if a command is run multiple times. Also, any script is reliant on the log file format staying consistent.

The command get_metric was developed to make reporting metrics easy and straightforward. When the variable encEnableMetric is set to 1 (default in EDI 11) EDI System will automatically store metrics for a set of a predefined commands. These metrics are saved with the database (*.enc.dat/designName.metric) and made accessible from session to session using get_metric.

Here are some examples of how it is used:

get_metric by itself returns all metrics last computed:

encounter> get_metric
    34726           design.numStandardCell
    35327           design.numNet
     0               design.numFloatBlock
     4               design.numFixedBlock
     34726           design.numSingleRowCell
     0               design.numDoubleRowCell
     0               design.numMultiRowCell
     0               design.numIoInst
     0               design.numFixedIo
     0               design.numFloatIo
     156584          design.numTerm
     4.43            design.numTermPerNet
     40.547 %        design.util
     0.138           design.pinDensity
     1.10e+06 um     place.totalNetLength
     -1.036 ns       timing.setup.WNS.all
     -61.875 ns      timing.setup.TNS.all
     12273           timing.setup.numPaths.all
     100             timing.setup.numViolatingPaths.all
     0.026 ns        timing.setup.WNS.reg2reg
     ...

Use the -cmd option to filter metrics by command:

encounter> get_metric -cmd verifyGeometry
verifyGeometry
     3    verify.geom.cell
     0    verify.geom.samenet
     0    verify.geom.wiring
     0    verify.geom.antenna
     0    verify.geom.short
     0    verify.geom.overlap
     3    verify.geom.total

Use wildcards to match multiple commands:

encounter> get_metric -cmd verify*
verifyGeometry
     3    verify.geom.cell
     0    verify.geom.samenet
     0    verify.geom.wiring
     0    verify.geom.antenna
     0    verify.geom.short
     0    verify.geom.overlap
     3    verify.geom.total
verifyConnectivity -type all -error 1000 -warning 50
     0    verify.conn
verifyProcessAntenna -reportfile leon.antenna.rpt -error 1000
     0    verify.antenna

You can specify the metric name to report. If multiple commands have the same metric it returns the most recent one:

encounter> get_metric timing.setup.WNS.all
     -1.036 ns timing.setup.WNS.all

Filter by both command and metric:

encounter> get_metric timing.setup.WNS.all -cmd {optDesign* *setup*}
optDesign -preCts
     0.006 ns   timing.setup.WNS.all
optDesign -postCts
     -1.023 ns timing.setup.WNS.all
optDesign -postCts -hold
     -1.023 ns timing.setup.WNS.all
optDesign -postRoute
     -1.036 ns timing.setup.WNS.all
optDesign -postRoute -hold
     -1.036 ns timing.setup.WNS.all

If you want to format your own standard QoR report, the -tcl and -value options are used to read the data directly into Tcl lists/values you can write out in any style you choose. Below is an example of using the -tcl option:

encounter> get_metric design.* -tcl
{design.numStandardCell 34726} {design.numNet 35327} {design.numFloatBlock 0} {design.numFixedBlock 4} {design.numSingleRowCell 34726} {design.numDoubleRowCell 0} {design.numMultiRowCell 0} {design.numIoInst 0} {design.numFixedIo 0} {design.numFloatIo 0} {design.numTerm 156584} {design.numTermPerNet 4.43} {design.util 40.547 %} {design.pinDensity 0.138}

Use the -value option to return only the metric's value. Here I assign it to a variable:

encounter> set totalGeomViols [get_metric verify.geom.total -value]
  3

Lastly, use the following to report metrics for all the commands run:

encounter> get_metric -cmd *
placeDesign
     34726           design.numStandardCell
     35327           design.numNet
...
optDesign -preCts
     0.006 ns   timing.setup.WNS.all
     0.000 ns   timing.setup.TNS.all
...
clockDesign -specFile DATA/leon.ctstch
     306             clock.clk.numBuffer
     1978.44         clock.clk.areaBuffer
...
optDesign -postCts
     -1.023 ns       timing.setup.WNS.all
     -62.451 ns      timing.setup.TNS.all
...
optDesign -postCts -hold
     -1.023 ns       timing.setup.WNS.all
     -62.490 ns      timing.setup.TNS.all
     12273           timing.setup.numPaths.all
...
optDesign -postRoute
     -1.036 ns       timing.setup.WNS.all
     -61.835 ns      timing.setup.TNS.all
     12273           timing.setup.numPaths.all
...
optDesign -postRoute -hold
     -1.036 ns       timing.setup.WNS.all
     -61.875 ns      timing.setup.TNS.all
...
verifyGeometry
     3    verify.geom.cell
...
verifyConnectivity -type all -error 1000 -warning 50
     0    verify.conn
verifyProcessAntenna -reportfile
leon.antenna.rpt -error 1000
     0    verify.antenna

The metrics are stored in the .metric file with both the command and options. So it's useful to use wildcards when specifying the -cmd option.

The commands currently supported by get_metric are:

placeDesign
optDesign
timeDesign
clockDesign
verifyGeometry
verifyConnectivity
verifyProcessAntenna
verifyMetalDensity
report_power
addFiller
addWellTap
addEndCap

If you've haven't tried get_metric I encourage you to give a try and let us know what you think. Are there commands currently not supported which you would like to report metrics on?

Brian Wallace

As you know, Cadence Online Support is your 24/7 site for getting help and resolving issues related to Cadence software. If you are signed up for e-mail notifications, you've noticed new solutions, application notes, videos and other content are added daily. In this blog I want to highlight a new content type called the Rapid Adoption Kit (RAK). This new content type is a packaging of related material to demonstrate how you can improve your productivity and maximize the benefits of your tools. Here is what I like about the RAKs:

• Go Deep - RAKs provide detailed information and training on a focused topic.
• Get Your Hands Dirty - Each RAK comes with a workshop database so you can learn-by-doing.
• You're in Control - The workshop labs, presentations and videos are all downloadable so you can go through them at your own pace.

For example, if you want to be an expert with the Encounter Digital Implementation (EDI) System then knowing DBTcl is essential. The "Database Access with DBTCL" RAK provides an overview presentation of the DBTcl commands and hands-on labs to advance your skills quickly.

Or perhaps you are an expert EDI System user but wanting to learn more about a new technology like Clock Concurrent Optimization (CCOpt). There's a RAK for that too!

Cadence EDI System customers can access the following RAKs for Encounter Digital Implementation (EDI) System and Sign-off Flow:

These RAKs as well as RAKs for other products are easily available by going to support.cadence.com and selecting Resources -> Rapid Adoption Kits.

RAKs were developed in response to customer feedback so we'd love to hear what you think. Also, what topics do you want to see new RAKs created for? Send us your feedback by adding a comment below or using the Feedback box on Cadence Online Support.

Happy learning!

Brian Wallace

In my last post I wrote about writing more compact db access scripts with dbGet's expression-based matching. We found all of the high fanout nets in the design which weren't clock nets:

dbGet [dbGet top.nets {.numInputTerms > 16 && .isClock == 0}].name

This writes the name of each net to the console. But how would we write those nets to a file? Say, for example, if we wanted to call optDesign -selectedNets on them? optDesign expects a file with a list of net names, one per line. How could we create that file? We could use the redirect command along with some clever scripting. More on that in a moment, but let's talk about redirect first.

The Basics

The redirect command as described here is available starting in release EDI release 11.1 (EDI stands for Encounter Digital Implementation System).

In its simplest form redirect takes the output that's written to the Encounter console and writes it to a file. This is useful when you want to process that output programatically and do something based on what's found in that file.

Take for example the checkPinAssignment command. It writes output like this:

encounter 1> checkPinAssignment

Start Checking pins of top cell: [top]
**WARN: (ENCPTN-562):   Pin [in] is [PLACED] at location (   0.330,   50.120 4 ) is NOT ON THE DESIGN BOUNDARY.
Summary report for top level: [top]
        Total Pads                         : 0
        Total Pins                         : 3
        Legally Assigned Pins              : 2
        Illegally Assigned Pins            : 0
        Unplaced Pins                      : 0
        Constant/Spl Net Pins              : 0
        Internal Pins                      : 1
        Legally Assigned Feedthrough Pins  : 0
        Illegally Assigned Feedthrough Pins: 0
End of Summary report
End Checking pins of top cell: [top]

The command doesn't return anything (ie, if you "set x checkPinAssignment", "x" wouldn't have a value) so if we want to query whether checkPinAssignment found any violations -or- check which specific pins were in violation we could do it by redirecting to a file and parsing the output. It's not necessarily pretty but sometimes you've got to do it. Here's how it works:

encounter 1> redirect checkPinAssignment.out checkPinAssignment
**Info: stdout is directed to file 'checkPinAssignment.out'...

Now, you could iterate through each line in checkPinAssignment.out and regexp for "WARN", find a pin name and operate on it in some way.

If the command you want to execute contains options, embed the options in curly brackets:

encounter 1> redirect queryPlaceDensity.out {queryPlaceDensity -userSpecified}
**Info: stdout is directed to file 'queryPlaceDensity.out'...

Intermediate 

We've talked before about writing to and reading from a file. I've got a couple more tips that extend on that idea and make things more compact.

First, check out the dbForEachFileLine command. It essentially does the same thing as:

set infile [open checkPinAssignment.out "r"]
while {[gets $infile line] >= 0} {
  if {[regexp WARN $line]} {
    Puts "$line"
  }
}
close $infile

If you're like me and have trouble remembering the infile/open/while/gets/close business try dbForEachFileLine instead:

dbForEachFileLine checkPinAssignment.out line {
  if {[regexp WARN $line]} {
    Puts "$line"
  }
}

But we can get even fancier with this approach, and avoid writing to a file altogether with redirect's -variable option:

redirect x checkPinAssignment -variable
set lines [split $x \n]
foreach line $lines {
  if {[regexp WARN $line]} {
    Puts "$line"
  }
}

Extra Credit

Back to the original puzzler I mentioned previously. How could we write to a file, one net per line, all of the nets with fanout greater than "n" so we could pass it to a command like "optDesign -selectNets <fileName>"? It's a little tricky, and probably exceedingly compound to be honest, but there is a way:

encounter 18> redirect high_fanout.nets {puts "[join [split [dbGet [dbGet top.nets {.numInputTerms > 16 && .isClock == 0}].name]] \n]"}   
**Info: stdout is directed to file 'high_fanout.nets'...

encounter 19> more high_fanout.nets
scan_enI
DTMF_INST/TDSP_CORE_INST/MPY_32_INST/n_7295
DTMF_INST/TDSP_CORE_INST/MPY_32_INST/n_6735
{DTMF_INST/TDSP_CORE_INST/MPY_32_INST/ab_a[15]}
{DTMF_INST/TDSP_CORE_INST/MPY_32_INST/ab_b[15]}

Pretty cool!

Here's the full usage for the redirect command:

encounter 1> help redirect

Usage: redirect [-help] [<file_or_var_name>] [<command>] [-tee] [-stdin | -append | -variable ] [-stderr | -stdin ]

-help                        # Prints out the command usage
<file_or_var_name>           # file name or variable name, for outputs to go
                             # (string, optional)
<command>                    # command to execute (string, optional)
-append                      # append stdout/stderr to file or variable
                             # (bool, optional)
-stderr                      # redirect stderr also (bool, optional)
-stdin                       # redirect stdin (bool, optional)
-tee                         # redirect output to both screen and file or
                             # variable (bool, optional)
-variable                    # redirect to a Tcl variable (bool, optional)

I hope there's a useful nugget or two in here.

Question of the Day: Any tips or tricks you'd like to share about reading from/writing to a file, capturing output as a variable, or redirecting it to a file? 

-Bob Dwyer

In looking over the shoulders of Encounter users over the years I've found there's a bunch of little tips and tricks I use to make interacting with the tool a little easier that aren't necessarily immediately obvious. Here are some of the more common ones I used this week:

1. When navigating an Encounter log file in a text editor, search forward for "<CMD>". Each time a command is executed it's embedded in the log file, for example: "<CMD> optDesign -preCTS". This makes it easier to understand what was executed and what resulted. 
2. Use "getLogFileName" to determine which log file goes with which Encounter session.
3. Use "win" at the Encounter prompt to raise the window of the session associated with the Encounter console. Doesn't work with all window managers but when it does I find this quite useful.
4. Use "dbWireCleanup" to delete all of the signal routes in the design (trialRoute or NanoRoute). See also "editDelete -type Signal".
5. Use "deleteAllPowerPreroutes" to delete all of the power routing in a design. Sure you could "editDelete -type Special" but what fun is that?
6. Use "encounter -init design.enc" to restore a design from the UNIX prompt.
7. Load designs with "source design.enc" at the Encounter prompt instead of using restoreDesign. That way you don't need to use a pulldown menu and you don't need to tell the tool the top cell name since it's embedded within the .enc file.
8. Use emacs-style shortcuts like "ctrl-a", "ctrl-e", and "ctrl-k" to position the cursor and strike text at the Encounter console.
9. Use "dbGet selected.??" to query physical information about an object.
10. Use "report_property [get_nets <net_name>]" to query timing information about an object.

Question of the Day: What little tips and tricks have you found useful in Encounter over the years? Let us know in the comments.

-Bob Dwyer

Okay, this one is too cool not to share.

The other day a customer and I were trying to understand a tool behavior better so we did what we all do in desperate times: We read the documentation.

As straightforward as "reading the documentation" would seem, I bet no two users of the system interact with documentation the same way. Some people like to bring up "cdnshelp" at the UNIX prompt. Some like to download the .pdfs from the install tree. Others like to use CommandGetIt through a web browser. Some click the "Help" button within the tool. Others like to read them through http://support.cadence.com

For most things, I use "help <command_name>" at the Encounter prompt. And "man <command_name>" for an extended description of what each option does along with some examples.

So when the designer I was working with saw me launching Encounter to bring up the man page for a command, he asked if there is a way to do that from the UNIX prompt without launching the tool. I didn't know how to do that, but there is a way. Here's how...

The short answer is to add the path to the Encounter man pages to your MANPATH environment variable.

The man pages reside in the Encounter installation tree under <install_path>/share/fe/man - for example:

UNIX> which encounter
/icd/flow/EDI/EDI111/latest.USR1.lnx86/lnx86/bin/encounter

UNIX> setenv MANPATH /icd/flow/EDI/EDI111/latest.USR1.lnx86/lnx86/share/fe/man

UNIX> man placeDesign

This should bring up the man page for placeDesign without needing to launch Encounter.

However, you probably don't want to lose access to regular UNIX commands, so you'll want to append the Encounter path to your existing MANPATH. How to do this depends on the shell you use but this works for me:

setenv MANPATH ${MANPATH}:/icd/flow/EDI/EDI111/latest.USR1.lnx86/lnx86/share/fe/man

Want to get even fancier? If you've already got the encounter executable in your path you can make use of the "cds_root" utility to set your MANPATH. This way your MANPATH will always update to the latest version of Encounter you're pointing to. Slick!

setenv MANPATH ${MANPATH}:`cds_root encounter`/share/fe/man

Another approach would be to create an alias to a separate man command for Encounter:

UNIX> alias eman 'man -M `cds_root encounter`/share/fe/man'
UNIX> eman placeDesign

Hope this is helpful! And thanks to my colleagues Tim, Benton, and Bupendra for pointing out how to do this.

-Bob Dwyer

I mentioned in my first blog one of my roles in customer support is to identify and author knowledge content for Cadence Online Support (http://support.cadence.com). In this blog post I want to highlight some of the popular Encounter Design Implementation (EDI) System content published in recent months.

If you're not receiving email notifications on the latest Cadence Online Support content, log in to http://support.cadence.com and My Support -> My Account then click on the Notification Preferences tab. Here you can specify the type of content you want to be notified of and the frequency.

There were several new videos and application notes posted recently. AOCV is definitely a hot topic lately:

• Appnote - Flipchip Implementation - Peripheral IO Application Note
• Appnote - Analysis with Advanced On-chip Variation (AOCV) derating in EDI system and ETS
• Appnote - Develop understanding on cdB constructs
• Appnote - Power Routing Re-Use while converting 7 Metal Layer to 10 Metal Layer Process
• Presentation - EDI 11 Foundation Flow Presentation
• Video - EDI11 Foundation Flow Video

Additionally, below are the solutions published in recent months which customers viewed the most. I hope you enjoy these highlights!

-  Brian

Adding decap cells near clock buffers or flip-flops

Provides a script to place decoupling capacitors (decap cells) near clock tree buffers or even flip-flops. These cells can have a high current draw so inserting decap cells minimizes the current draw effects.

Script to convert config file to global variable file for init_design in EDI 11

The Design Import flow in EDI 11 uses global variables in place of the config file. This solution provides a script for converting the EDI 10.1 config file to a global variables file. It also updates your environment to MMMC if needed.

Step-by-step through a top-down hierarchical design flow

An easy to follow description of the steps to import a large design with blackboxes and go through a top-down hierarchical partitioning in EDI System.

Using generateVias to create optimal vias for NanoRoute

Shows how to simplify your via definitions in your technology LEF using the generateVias command.

What is the encounter.logv file written out by EDI 11?

Answers the common question, "What is this encounter.logv file?".

How to Search-and-Repair after Post-Route Timing Closure

Simple flow to delete and re-route nets Verify Geometry reports violations on.

assembleDesign does not support one step assembly with nested partitions until EDI 11

Clarifies support for one step design assembly with nested partitions using assembleDesign

Does optDesign fix max transition violations on nets which have set_case_analysis constraint?

Explains optDesign will fix max transition violations even if the net is constant.

Can I update Tech LEF on the fly in Encounter? No.

Explains what LEF data can be loaded incrementally.

How do you balance skew between clocks using CTS?

Shows how to use ClkGroup in the CTS constraints file to balance skew between clocks.

You've placed and routed your design in the Encounter Digital Implementation (EDI) System. It passed Verify Geometry and Verify Connectivity without a violation. Great!

But when you run DRC signoff with your physical verification tool, you have violations related to the routing. What should you do now?

Depending on your situation there are usually two solutions:

1. Fix the violations by hand. This is okay if there are a small number and you don't need to go back to physical design.

2. Debug why these violations were not caught during physical design. This is done when you want to understand the cause of the miscorrelation. Is it a bug in one of the tools? Is a LEF rule wrong? Is the DRC rule deck wrong?

In this blog I'll explain my approach to debugging the discrepancy. If you have a different approach, please share it by adding a comment below. Here are the details of my approach:

1. Load the DRC violation report into EDI System
2. Use Violation Browser to see details of violation
3. Verify violation is valid by reviewing Design Rule Manual
4. Determine if corresponding LEF rule is correct
5. Review other causes such as Verify Geometry option settings

First I read the violation report from the DRC checker into EDI System. EDI System supports the major DRC tool formats. In my run I've taken advantage of the Physical Verification System (PVS) interface from EDI System and invoked it straight from the EDI System GUI (PVS - Run DRC).

To read in the results to the violation browser I select Tools - Violation Browser. Then I on the Load Violation Report form, specify the report file, ts format and click OK.

Here I see there is a violation on an M2 metal. If I go back to the Violation Browser and click on the actual rule, the Description field gives the reason for the violation. In this case it says the METAL2 to METAL2 spacing required is >= 0.15.

Zoom into the violation by clicking on it under the Location section of the Violation Browser.

Below is the example violation with rulers added to show the spacing and widths:

If you have the Design Rule Manual (DRM) you can double check the rule to confirm the DRC check is correct. If the DRC deck is in development or for a newer technology ,it's possible it's wrong, but typically it is correct since this is for signoff.

The next step is to determine which LEF rule should enforce this spacing and verify it is defined correctly. This is not always easy, especially as more and more rules are required for smaller geometries, but typically you can narrow it down by knowing the layer, type of rule and value expected. And if the LEF has comments to label which LEF rules correspond to the DRM rules, then it's even easier.

If we go to the spacing rules for M2 we have a SPACING table which specifies required spacing based on the object width and parallel run length. This rule is likely the one which should be enforcing the spacing.

LAYER Metal2

...

  SPACINGTABLE

    PARALLELRUNLENGTH      0 0.32 0.75  1.5  2.5  3.5

    WIDTH             0 X.XX X.XX X.XX X.XX X.XX X.XX

    WIDTH          0.11 X.XX 0.15 X.XX X.XX X.XX X.XX

    WIDTH          0.75 X.XX X.XX X.XX X.XX X.XX X.XX

    WIDTH           1.5 X.XX X.XX X.XX X.XX X.XX X.XX

    WIDTH           2.5 X.XX X.XX X.XX X.XX X.XX X.XX

    WIDTH           3.5 X.XX X.XX X.XX X.XX X.XX X.XX ;

The rule seems correct ,stating that for a width 0.11 and parallel run length of 0.32 the spacing should be 0.15. But looking closely at the LEF syntax I find objects have to be greater than the specified width to trigger the rule:

PARALLELRUNLENGTH {length} ...

  {WIDTH width {spacing} ...}                       

Specifies the maximum parallel run length between two objects, in microns. If the maximum width of the two objects is greater than width, and the parallel run length is greater than length, then the spacing between the objects must be greater than or equal to spacing. The first spacing value is the minimum spacing for a given width, even if the PRL value is not met.

So in this case the LEF rule is incorrect and must be adjusted. After I change 0.11 to 0.10 in the LEF rule above then Verify Geometry catches the error shown in the browser below and the GUI:

An incorrect LEF rule definition is just one possible cause. Other possible reasons are listed in solution 11728790 on Cadence Online Support:

Lastly, always check with your foundry for the latest technology LEF. They often provide technology LEF files optimized and tested for EDI System.

And if you ever need help with debugging we're here to help. Contact us by opening a Service Request by going to http://support.cadence.com and selecting Service Requests - Create Service Request.

Thanks,

Brian Wallace

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:

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

• 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

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

- 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

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

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

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. You'll need the iRCX file (also referred to as a unified tech file) from your foundry, and you'll need to locate both your extraction installation and your EDI installation.

When you request the iRCX information from your foundry, 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

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

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

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.