Home > Community > Blogs > Digital Implementation > user review of the encounter foundation flow
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Digital Implementation blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

User Review of The Encounter Foundation Flow

Comments(2)Filed under: scripting, Encounter Digital Implementation System 8.1, Foundation Flow, Encounter Digital Implementation System 9.1

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,

  VPATH=./make

in the Makefile to:

  VPATH=.

If you prefer to keep the make/ semaphore file directory, be careful of the following points:

  • With the Encounter Foundation Flow, you reset the design flow so that the init target is the most up to date using,
      touch make/init
    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 place.
Suggestions for Improvement

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 flow.
  • 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 all:
      .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.

Future Direction

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:

  • 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

Comments(2)

By keithd on February 24, 2010
hi John,
Could you elaborate on the use of subversion?  Were you using it for revision control of your design data?
thanks
-keith

By John McGehee on February 25, 2010
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.


Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.