|
|
last updated 12/26/2001
Topics:
Quick Links (coming soon):
|
|
This page details the usage of the SSHAFT chip-assembly flow as automated by ICMake. The dependency graph above shows the major steps of the flow. The hyperlinks in the graph connect to the primary documentation for each step. Each step has a green oval which represents the program that is to be run. Each step also has a file or group of files associated with it that represents the output of the step. These files are called the targets of each step and are represented by the white squares. Likewise, the files associated with earlier steps in the design flow are called the dependencies of the step.
The goal of ICMake is to relieve designers of the burdens of file, directory, and dependency management during the execution of this flow and to eliminate the need for tool expertise as much as possible. Furthermore, it is the goal of ICMake to guarantee functionality of any chip which passes through the entire flow. This is accomplished with the SSHAFT API which provides the basic tools needed create a flow. ICMake is simply a design management program based on the SSHAFT API. ICMake imposes a directory structure and provides a user-interface for directing the flow.
Tutorial 1 - Introduction to the flow, building a Simulink design with macros from the fundamental library, basic floorplanning, place & route and physical verification.
Tutorial 2 - (under construction) Introduction to Simulink macro development with Module Compiler, cross-simulation and pre-layout power analysis with EPIC PowerMill, parasitic extraction with Arcadia, and post-layout power analysis with PowerMill.
Tutorial 3 - (under construction) Introduction to Stateflow, hierarchical place-and-route, and clock-tree synthesis.
Macro Design Tutorial - (obsolete) Tips on how to build and test macros while bypassing Simulink.
Tutorial on using memory in the SSHAFT flow.
To use ICMake, first follow the setup instructions on the SSHAFT Setup Page. Then create a run directory and copy an ICMakefile into it. If you don't have an ICMakefile from a previous execution of the program, then grab one from one of the reference designs below. The ICMakefile defines the design-flow as illustrated in the dependency graph above. You are free to define your own steps or re-define the existing steps as needed. You probably won't need to modify the ICMakefile much at first, but it tends to become a necessity for the later steps of the flow.
Invoke ICMake with the following command: icmake [step name]. ICMake will run the design flow from the beginning up to the step you specify (or to the step all, if no step is specified). Certain steps along the way will be skipped if the dependencies are up-to-date with respect to the targets.
ICMakefile Syntax
Comming soon...
Directory Structure
All paths are relative with SSHAFT API. All paths in ICMake are relative to the ICMake run directory. Any paths specified in a sub-step are relative to the run-directory for that sub-step. In order to make it possible to write the various steps of the design-flow independently, a directory tree structure must be assumed. These directories can be created with the icmDirSetup command in the icmake.pm, or with the dirSetup.pl script.
Because many programs require a run-directory with a certain structure, ICMake assumes that a sub-directory called run exists in the ICMake run-directory. This directory contains sub-directories tailored to the different tools invoked during execution of the design flow.
run/cds - Cadence Design Framework II (icfb)
run/dp - Cadence Design Planner
run/dp/qp - Cadence QPlace
run/icc - Cadence IC Craftsman
run/si - Cadence Open Simulation System
run/dc - Synopsys Design Compiler
run/mc - Synopsys Module Compiler
run/epic - Synopsys EPIC Tools (TimeMill, PowerMill, PathMill)
run/arc - Synopsys Arcadia
run/cl - Mentor Calibre
ICMake produces designs with arbitrary hierarchical depth. The format of these hierarchies are described in the documentation for each step. ICMake assumes that a sub-directory called data exists in the ICMake run-directory to collect these files. The data directory contains the following sub-directories:
data/dfII - Cadence Design Framework II Libraries
data/pillar - Cadence Pillar Libraries
data/other - Libraries not associated with any framework
Each one of these directories contains sub-directories of the format library_name/cell_name to collect the data associated with each cell in the design hierarchy.
Lastly, the log sub-directory in the ICMake run-directory is used for collecting the log files of various steps not associated with a specific cell in the hierarchy.
dirSetup.pl
Author: Rhett Davis (wrdavis@eecs.berkeley.edu)
Repository Location: src/icmake
Description: When invoked from the ICMake run-directory and given a list of sub-directory names, all directories will be created. If the sub-directory name matches the name of one of the run-directories listed above, then that directory will be initialized with all of the setup files needed for the appropriate program. Files will not be modified if they already exist.
Usage:
Platform: unix_step
Run Directory: ICMake run-directory
Required Directories: none
Command: dirSetup.pl directory ...
Log File: stdout or appends to the file specified with the -log logfile arguments
Error Trapping: Returns 0 on success, 1 on error
createLib.pl
Author: Rhett Davis (wrdavis@eecs.berkeley.edu)
Repository Location: src/icmake
Description: When invoked from the ICMake run-directory and given a list of library names, the necessary files and directories will be created to define DFII and Pillar libraries suited to the current technology. If the libraries already exist, they are not modified.
Usage:
Platform: unix_step
Run Directory: ICMake run-directory
Required Directories: none
Command: createLib.pl library_name ...
Log File: stdout or appends to the file specified with the -log logfile arguments
Error Trapping: Returns 0 on success, 1 on error
getTechVar.pl
Author: Rhett Davis (wrdavis@eecs.berkeley.edu)
Repository Location: src/icmake
Description: Returns the values of the technology variables specified, or the values of all tech-file variables if none are specified. If the requested tech-file variable is not found, the result will be an empty string.
Usage:
Platform: unix_step
Run Directory: any
Required Directories: none
Command: getTechVar.pl variable_name ...
Log File: stdout or appends to the file specified with the -log logfile arguments
Error Trapping: Returns 0 on success, 1 on error
bjcGenSchematic
Author: Rhett Davis (wrdavis@eecs.berkeley.edu)
Repository Location: lib/skill/icmake.il
Description: Traverses the given hierarchy down to its abstract views and overwrites any existing schematic and symbol views with a new schematic hierarchy. This can be a convenient way to browse the contents of a design hierarchy.
Usage:
Platform: skill_step
Run Directory: run/cds
Required Directories: none
Command: bjcGenSchematic( ?src list( library_name cell_name view_name ))
...where library_name cell_name and view_name are strings. Note that if the arguments are omitted, then cell-view corresponding the current window is used.Log File: Cadence log file
Error Trapping: Returns t on success, nil on error
listterm, listnet, & listinst
Author: Rhett Davis (wrdavis@eecs.berkeley.edu)
Repository Location: lib/skill/sshaft.il
Description: These functions are handy when debugging a step which operates on cell-views with little or no graphical information.
listterm: Lists the names of all terminals in the given cell-view along with the names of all pins associated with each terminal
listnet: Lists the names of all nets in the given cell-view along with the name of the associated terminal and the names of all associated instance terminals
listinst: Lists the library name, cell name, and view name of every instance header in the design along with the instance names of all instaces associated with each instance header
Usage:
Platform: skill_step
Run Directory: run/cds
Required Directories: none
Command:
listterm( cdb )
listnet( cdb )
listinst( cdb )
...where cdb is a cell-view database object. Note that if the argument is omitted, then cell-view corresponding the current window is used.Log File: Cadence log file
Error Trapping: Returns t on success, nil on error
maintained by Rhett Davis
wrdavis@eecs.berkeley.edu
