No Design Flow Required
Full custom layout designers are the only people who can design chips interactively. The rest of us need a flow to automatically repeat the steps required to build the design.
This is one of a series of articles on simple, specific techniques that will make your chip design flow easy to use. In this installment, I will explain what the scientific method teaches us about the design and application of IC design flows. Other articles include,
- Write Effective Error Messages
- Properly Name Log Files for EDA Tools
- Give Files in Your IC Design Flow Useful Names
- Control Your IC Design Flow
Chip design is an application of the scientific method of inquiry:
- Observe that your chip lacks something. It might be unrouted, or it perhaps it has DFM violations.
- Construct a hypothesis of what will solve the problem
- Run an experiment to prove your hypothesis
- Analyze the outcome of the experiment
- Make corrections and iterate until you find the solution
- Communicate the results
Your chip design flow enables the scientific method by controlling the experiment. It presents results for analysis by the designer. The design flow communicates results to the rest of the team.
Control the Experiment
In a valid experiment, you manipulate a single independent variable, while holding all other variables constant. For example, you might change the RTL, or perhaps write a new routing script. It is the job of the design flow to perform the experiment. To avoid variability caused by human intervention, the design flow must run entirely automatically. Another reason for this is that design flows often run for many hours. Waiting for a human to show up and perform some action is a tremendous waste of time.
Present Data for Analysis
After the experiment you observe the outcome–the dependent variable. You might be looking for improved timing, or fewer vias in response to your new routing script. The flow must also communicate to your colleagues and managers the results they need.
Disorganized, misleading results are worse than no results. The design process creates an enormous number of reports, databases and log files. Everything written to disk must be given a thoughtful, consistent name. An informed engineer should be able to look at the name of any file or variable, and reliably guess its content. You need to establish your naming convention first, because once a file is given a name, changing it is disruptive.
Error messages communicate the validity of the data. The confusion resulting from false and vague error messages takes time and causes mistakes. The design flow must provide meaningful messages.
Communicate the Results
The most important results for the flow to communicate are:
- Pieces of the design flow that are proven, and can be used to produce similar results on other designs:
- Compiled software such as EDA tools and internally-developed applications
- Scripts and makefiles written in interpreted languages
- Status of the design: how far has it progressed, what errors need correction
- Final results for tapeout and archival
I will present some simple approaches to managing this communication in subsequent articles. No matter how sophisticated your formal system for communicating design status, colleagues and managers will peruse your design’s working directory for design status. Here they will navigate by the simplest means–using the names of directories and files. You must not mislead them. This once again underscores the importance of organizing and naming files for ease of navigation.
Upcoming Topics
That’s all for now. Subscribe to John McGehee’s blog to be informed about continuing topics as they become available:
- Writing Effective Messages
- Log File Naming for EDA Tools
- Organizing Your Tool Hierarchy
- Designing Reentrant Steps
- Creating a Self-Documenting File Hierarchy
{ 4 trackbacks }
{ 0 comments… add one now }