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:
clean: rm -rf .??* # ...
.PHONY: all clean # ...
In addition to the fixes mentioned above, Rob and Glenn are still
enhancing the flow.
Currently the flow executes Tcl scripts that contain procs
and variables. In a future version, the flow can first generate linear scripts
with all variable values evaluated and all procs expanded
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:
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
I was using subversion for version control of the flow scripts, and the input data, like LEF and Verilog.
I was not using Subversion for binary databases. I believe I have seen Subversion used with CAD databases, but the user was not so satisfied and was looking for a different solution.
Could you elaborate on the use of subversion? Were you using it for revision control of your design data?