This is a guest post from John McGehee. John is an independent consultant in Silicon Valley, specializing in EDA application development and design. He blogs about these topics at voom.net. Prior to starting his consulting career, John was an AE at Avanti, Cadence Japan and Daisy Systems Japan.
In an earlier series of posts, I described techniques that will make
your chip design flow easy to use. I subsequently had the pleasure
of using a flow that employed most of my favorite techniques—the Cadence Encounter Foundation Flow version 8.1.
The focus of this flow is to get you up and running immediately.
Plug in your libraries, netlist, timing constraints, do some
floorplanning, create a clock tree specification file, type make,
and something comes out the other end. Not a usable chip of course,
but something, so you can see what’s next. A flow is executable
documentation, and this is your Quick Start Guide.
The Encounter Foundation Flow does not try to be everything to
everybody, but rather the portion of the design flow that is common to
everybody. It can be difficult to decide how far to go with such a
flow, but Cadence engineers Rob Lipsey and Glenn Gullikson knew where to stop. I found the Encounter Foundation Flow to be
a good balance between completeness, extensibility, and usability. It
contains no confusing, useless features like GUIs, wrappers, and “under
the covers” sleight of hand. The best ASIC designers I know use flows
architected like this one.
An additional advantage of any standard flow is that it gets all
users to operate the tools in the same way. With versatile tools like
place and route, there are many ways to accomplish the same thing. Yet
such tools are a minefield of bugs and quirks. When every user chooses a
different approach, something bad always happens. A standard flow
defines a single safe path for users. It frees the tool developers from
having to support a needless variety of ways to accomplish one task.
The make/ Semaphore File Directory
Physical designers who are accustomed to using GNU Make
will be at home with the Encounter Foundation Flow. The one thing that
you need to be aware of is the location of the target
semaphore files in the make/ directory. This is specified
in the Makefile with the VPATH variable.
While a separate directory for semaphore files initially seems like a
good idea, putting them in the make/ directory causes subtle
problems. You can eliminate this make/
directory by changing,
in the Makefile to:
If you prefer to keep the make/ semaphore file directory, be
careful of the following points:
Suggestions for Improvement
- With the Encounter Foundation Flow, you reset
the design flow so that the init target is the most up to
but if you forget the directory name and mistakenly type,
touch init #wrong
the flow forever thinks that only the init target is up to
date; every time you run, the flow starts over. I burned up a lot of
CPU time until I discovered that the culprit was the ./init
file hiding in my working directory.
- Similarly, do not forget the directory name when you use
the make -t option to update the design flow:
make -t make/place
This can be difficult to remember after becoming accustomed to typing make
I found several things in Encounter Foundation Flow 8.1.RTM that I think Cadence should consider improving. As noted below, many are in fact already fixed in later versions of the
- The Makefile clean target deletes the Subversion version
control directory .svn:
clean: rm -rf .??* # ...
Wildcards in the clean target can easily make a mess. This is fixed in the version 8.1.USR2 cleanup target.
- The Makefile does not make use of the .PHONY target. This is
especially useful for the administrative targets like clean and
.PHONY: all clean # ...
- The Encounter Foundation Flow puts reports in its own RPT/
directory rather than the tool default. For example, I would prefer
that Encounter timing reports go in the Encounter default, timingReports/.
- Lower case is easier to type, so I would prefer lower case names for the
LOG/, RPT/, and DBS/ directories. Users can customize these paths using the vars(rpt_dir)
and vars(dbs_dir) variables in the setup.tcl file. The log file directory can be changed using the Makefile variable LOG.
- In file SCRIPTS/FLOW/run_route.tcl, line 68, the variable setFillerMode
is missing for the non-power domain case, but this is fixed in version 8.1.USR2.
In addition to the fixes mentioned above, Rob and Glenn are still
enhancing the flow.
Currently the flow executes Tcl scripts that contain
and variables. In a future version, the flow can first generate linear scripts
with all variable values evaluated and all
into Encounter commands. Then it executes these scripts with Encounter.
In my flows I avoid generating scripts, because it allows the
configuration variables and the scripts to become desynchronized. But
Glenn and Rob had some good arguments for doing it this way:
- The script stands alone as a record of exactly which commands were
executed. To reproduce the step, you (or your AE) need only the
starting database and one script file, not the entire flow.
- The flow can be easily tested by merely comparing the scripts
against golden scripts, without running Encounter. Testability is a key
feature of every software project.
To solve the synchronization problem, I encouraged Rob and Glenn to
generate each script within the Make target, immediately before it is
used. I’m interested to see how this works out. Make
sure to send them your feedback, too.
I'd like to thank John for exercising the Foundation Flow and sharing his thoughts with us in this piece. -Bob Dwyer