ERC projects are often created through use of the ERC Analyzer GUI. However, you may want to automate the process of creating or cloning projects through script control.
Do You Need to do this?
First, let's discuss the reasons for creating a project.
A project serves as a data container, holding the following:
- Definitions of voltages and names for power rails. These may differ when a new chip or process technology is involved.
- Definitions of transistor characteristics, such as gate capacitance and maximum voltages. These are referenced by model names, and will likely change with a new process technology.
- ERC results "filtering", where certain false positive results are memorized as exceptions and do not re-appear in subsequent validation. Filters are stored relative to library and cell names. These will likely change when a new design library is involved.
So, it is usually necessary to change projects (or define a new project) if any of the following are true:
- A new process technology is introduced.
- A substantial change of design libraries or chip top level is made.
The Typical Case
Normally, a user will define or change projects with the GUI. They will first set the project name, then define power rails, and finally define the transistor characteristics. This is done in the GUI, using spreadsheet lists.
In automating this process, you will basically be triggering the same methods that the GUI uses, except that your code will run as a script. In the end, the results will be the same: The user will see the project settings in the GUI. This can be done either before the ERC Analyzer runs, or while it is running.
Two Basic Methods of Automation
There are actually two ways of automating the project creation and selection. Each has advantages and disadvantages. As a third method, at the end of this note, we present a hybrid solution that combines the best of both worlds.
Method 1: "Under the Hood"
Advantages
- Powerful: Can do everything the end user would need.
Disadvantages
- No abstraction: Requires writing / copying data files directly.
Procedure
You may find it helpful to refer to an existing project for the following steps:
Create a directory under projdefs/ with the name of the project. Example: projdefs/enetPhy/. This projdefs/ directory is either in $INSIGHT_ROOT/../shared/, or listed in the optional $INSIGHT_PROJPATHS.
Create a text file for the device parameters, inside the project directory (above), with the same name as the project. Example: projdefs/enetPhy/enetPhy.devparams. This file could be copied from an existing template or reference project. It holds definitions for each primitive model, as seen in the GUI under "Setup > Device Parameters". An example of this file is shown below:
[PerUnitParameters]
nch DefL=.25
nch Cg=0.4
nch CEdge=0.2
nch Vgs=2.5
nch Vsd=2.5
pch DefL=.25
pch Cg=0.4
pch CEdge=0.2
pch Vgs=2.5
pch Vsd=2.5
[UserDefNames]
UserDefCount=0
Create a text file for the power definitions, inside the project directory (above), with the same name as the project. Example: projdefs/enetPhy/enetPhy.pwrdefs. This file could be copied from an existing template or reference project. It holds definitions for each power net name, voltage, and domain, as seen in the GUI under "Setup > Power Nets". An example of this file is shown below:
[PowerNames]
Net 0=VDD
Domain 0=CorePower
Voltage 0=2.50
Net 1=VDD_A
Domain 1=RegAnalog
Voltage 1=2.50
Net 2=VSS
Domain 2=
Voltage 2=0.00
Net 3=
Domain 3=
Voltage 3=
Create or edit the file config/ProjectList.config. The config/ directory will be adjacent to the projdefs/ directory (above). In the ProjectList.config file, you'll insert a reference to the project you are creating:
[Projects] Project 0=enetPhy Path 0=../projdefs/enetPhy/
Note that in this list, above, we have used "../projdefs" to make the path relative. For this reason, the config/ and projdefs/ directories must be adjacent to each other.
See Also
Application note on "Making Projects Portable".
Method 2: Official API Commands
Advantages
- Clean: Utilizes documented API commands, no manipulation of data files.
Disadvantages
- Limited: Requires a netlist to be loaded before device characteristics can be saved.
Procedure
In a Tcl script, running inside the ERC Analyzer, create the project with a given path, such as this example:
set pp "$::env(HOME)/.insight/settings/projdefs"
if { ![ file isdirectory $pp ]} {
file mkdir $pp
}
project setName "QuickDemo" "$pp" ;# creates the project and specifies the projdefs/ directory
Setup power nets with these Tcl commands:
pwrdefs clear ;# erase any old stuff user may have been twiddling with
# now define powers for this project
pwrdefs define "" VDD_180 "" 1.8
pwrdefs define "" VDD_330 "" 3.3
pwrdefs define "" VDD_A "" 1.8
pwrdefs define "" VDD "" 1.8
pwrdefs define "" VSS "" 0
pwrdefs save
To setup the device parameters, you must wait until a netlist that has those devices has been loaded. When the netlist is loaded, execute these Tcl commands:
set deviceParms { \
{ PCH {DefL .18} {Cg .35} {CEdge .16} {Vgs 1.8} {Vsd 1.8}}
{ NCH {DefL .18} {Cg .35} {CEdge .16} {Vgs 1.8} {Vsd 1.8}}
}
foreach dp $deviceParms {
set devName [ lindex $dp 0 ]
set params [ lrange $dp 1 end ]
foreach p $params {
set pName [ lindex $p 0 ]
set pVal [ lindex $p 1 ]
catch { devparams configure $devName $pName $pVal } ;# catch: cell may not exist
}
}
The prject will then be in place, and the user will then see the project's name in the top title bar of the GUI main window.
See Also
Application note "Standalone Quick Demo".
Method 3: Hybrid
This method combines parts of the first two, above. There's some "under the hood" work to establish the template without requiring a netlist, plus some "official API" to integrate the solution into the GUI for the end user.
Procedure
Building upon the steps from the two alternate methods, above, we'll do the following:
- Establish the project path.
- Use $INSIGHT_PROJPATHS to provide the user with a unique path to the project. This can be a shared path, or private, as needed.
- Create the project subdirectory projdefs/, as described above in "Method 1".
- Setup the device parameters. It's probably best to clone a master template file, as in "Method 1".
- Setup the power definitions. You may find it best to either...
- ... Clone a master file projdefs/theName/theName.pwrdefs, if you know what the power nets are,
- ... or run the Tcl command 'pwrdefs findSuspects' (and the other pwrdefs commands) to populate power nets based on a loaded netlist.
- Set the active project for the user, as shown in "Method 2":
'project setName "theName"'. In this case, you don't need to specify the project's path because you've already created it, and this command is simply making reference to the project by name.