Autopilot Example

This example shows how to configure the ERC Analyzer so that the user runs on autopilot:

  1. The transistor parameters come from a specific PDK.
  2. The user accepts a suggested project name, based on the design library.
  3. ERC scans are pre-configured, minimizing the user's decision making.

Objectives

You want to configure the ERC Analyzer so that the user has a minimum of decisions to make.

When starting the ERC Analyzer, the user is prompted to accept a pre-defined project name (in this case, the project name is based on the design library). Whether he accepts that project name, or defines a new one, the transistor device parameters will come from a specific place related to the active PDK. He won't need to define any device parameters. Finally, the ERC Scan Library window will display only those ERC scans that have been pre-configured.

Procedure

Check Version

This application note assumes you are running the Insight ERC Analyzer v3.02-964 or higher.

Choose PDK

The PDK (process design kit) has a root directory where you want to place the device parameters (.devparams file) for this process. For this example, let's assume the PDK is located at /the/path/to/pdk45/. In the following steps, all paths and names are only examples - you may change these as you see fit:

  1. Do 'setenv EXAMPLE_PDK /the/path/to/pdk45'
  2. Do 'mkdir $EXAMPLE_PDK/insight'

Define Device Parameters

You will place the device parameters file in the PDK path, again using example naming:

  1. Create the file $EXAMPLE_PDK/insight/base.devparams. The filename may be anything but the extension ".devparams" is required.
  2. Fill the contents of this file, either by copying another .devparams file, or using the ERC Analyzer GUI (you must set the devparams path in order to use the GUI for editing (see below)).

Writeable Device Parameters

If the user needs the ability to override PDK parameters (above), you may use file referencing from a devparams file in his local work directory. As a modification of the steps (above), do the following instead:

  1. Create the file override.devparams in the user's work directory. The filename may be anything but the extension ".devparams" is required.
  2. The contents of this file must have a reference back to the master file, as shown below:
[DataSource]
Reference=$EXAMPLE_PDK/insight/base.devparams

In this case, the base definitions will come from the file in the PDK area. But if the user edits definitions in the ERC Analyzer GUI, those changes will be written into his file override.devparams.

Create Startup Script

While you could make edits to the main startup script ($INSIGHT_ROOT/scripts/startup.tcl), we will create a new one for this example:

  1. Create the file /sample/path/to/scripts/startup.tcl (or simply edit the one under $INSIGHT_ROOT/scripts/).
  2. Do 'setenv INSIGHT_PROJPATHS /sample/path/to', so that the ERC Analyzer will see your scripts/startup.tcl. (This environment variable must be spelled as shown. If editing startup.tcl under $INSIGHT_ROOT, you won't need to provide $INSIGHT_PROJPATHS.)
  3. Edit the contents of this file as shown below:
# If the user isn't pointing to our desired project,
   # create it for him now
set currentProject [ project getName ] ;# whatever he selected in last session
set desiredProject "$::env(INSIGHT_PROJLIB)" ;# whatever we want him to use
   # check to see if he's on something different
if {[ string compare $currentProject $desiredProject ]} { ;# yes, steer him back to desired proj
      # path to desired project under his own $HOME/.insight/ dir
      # of course this path could also be something else, like
      # a globally accessible directory - up to you. If we let him
      # do this in his .insight dir, he'll be able to add his own
      # power definitions, filter conditions, etc - good idea.
   project setName $desiredProject "$::env(HOME)/.insight/projdefs/$desiredProject"
      # since he previously had a different project in mind, we
      # pop up the set-project window now. He will either say "OK"
      # or he'll make his own name - it's actually OK for us
      # either way, everything will work the same.
   wkspace showWindow "setProject" ;# waits for him to say "OK"
}
  # regardless of his project path, we're going to pre-empt his device
  # parameters to come from the PDK path. He won't be able to make any
  # dev param changes now
devparams setPath "$::env(EXAMPLE_PDK)/insight/base.devparams"

  # now load his netlist, if it's not already loaded.
# TODO...

  ###### Following will setup his power nets ####
  ###### This block doesn't wait ################
  # With the netlist, he'll be able to define his power rails.
  # the power finder will help him do that, as the transistor
  # voltage definitions (already done in devparams, above) will
  # guide the tool to suggest nets and their voltages.
wkspace showWindow powerSetup
wkspace setBusy 1 ;# this could take a while on huge netlist
  # get list such as 
  # "{top ampout_sata 1.80} {top ampout_dot 1.80} ..."
set suspectsList [ pwrdefs findSuspects byDSB ]
  # load suspects into main power window
foreach suspect $suspectsList {
  set cell [ lindex $suspect 0 ]
    # don't set cell name if it's the top of netlist
  if { $cell == [ cdb getHierarchyName ]} {
    set cell {} ;# don't set
  }
  set net [ lindex $suspect 1 ]
  set domain {} ;# user will provide any domain info
  set volts [ lindex $suspect 2 ]
  pwrdefs define $cell $net $domain $volts
}
wkspace setBusy 0
  # NOTE: leave the library un-saved
  # we want the user to save from the
  # library window, which should be visible now

  ###### Setup ERC scans #################################
  # let's pre-configure the ERC scans we want him to run
  # this is just one example
  # first turn everything off, no matter how many
foreach singlePlugin [ plugin catalog ] {
  plugin toggle $singlePlugin 0 ;# disables the checkbox / toggle
}
  # now turn on something, set the options for it too
  # NOTE: you can dump all option names by calling this without any settings
plugin toggle "Interconnect" 1
plugin configure "Interconnect" \
    -doOutputsShorted 1 \
    -doDriversBelowInputs 0 \
    -doNoDriversBelowOutputs 0 \
    -doFloatingGates 1 \
    -doNoLoadNets 1 \
    -doNoPinNets 1 \
    -ignoreToplevelPorts 1 \
    -priority 1

  # we can now open up the scan library window
  # but remember: Since the power setup (above) didn't wait,
  # it's not a good idea to open Scan Library window also
  # He'll get two windows popping up! This is just here for
  # example:
wkspace showWindow "scanLibrary"

  # finally we're just waiting for the user to "run" a scan,
  # we could do that automatically with:
# plugin runSelected  ;# will only work if a netlist is loaded

Launch ERC Analyzer

Assuming the environment variables have been spelled as shown above, you will launch the ERC Analyzer like this:

  1. Set the INSIGHT_PROJLIB variable, to provide the library name as the ERC project name. There are two ways you might be doing this:
    1. If running directly from a command shell:
      'setenv INSIGHT_PROJLIB my298chip'
    2. If running from within the Composer environment, insert this code prior to the launch, such as in insight_launchErcApp():
      setShellEnvVar(
      strcat( "INSIGHT_PROJLIB=" insight_topCellLib ))
  2. Start the ERC Analyzer. There are two ways you might be doing this:
    1. If running directly from a command shell:
      '$INSIGHT_ROOT/bin/run-insight'
    2. If running from within Composer:
      start from the "ERC" menu.

Because the $INSIGHT_PROJPATHS variable includes (possibly with colons) the path made above, the ERC Analyzer will run your startup.tcl script. Within that script, it will find the $INSIGHT_PROJLIB and use that to guide the user into the project by that name. After that, the user may run the selected ERC scan(s), depending on your use of the 'plugin runSelected' command (above). The last thing to do is for him to review the ERC results.

Scripting and the API
Read Time: 1 min