Design Automation

Automating Full-Chip Logic Synthesis

A synthesis infrastructure known as "makesyn," developed at the now-defunct Kubota Graphics, proved useful, and Kubota designers­now spread throughout the EDA industry­are keeping the idea alive.

by Thomas L. Anderson

When commercial logic synthesis tools were introduced in 1988, most users were designing ASICs in 1.0µm geometry or larger technologies. Most of these devices had 20 to 50 kgates, with a few pushing the 100-kgate mark. Since then, ASIC technology has advanced so that 0.5µm geometries and chips with several hundred thousands of gates are common. This has put pressure on all EDA tools, including logic synthesis. The time and computational resources needed to fully synthesize an ASIC device with hundreds of modules is a significant bottleneck in many design flows.

This article discusses some issues surrounding full-chip logic synthesis of large ASIC devices and presents a synthesis infrastructure­dubbed "makesyn"­designed to address these issues by automating the synthesis of entire chips. It was originally developed at Kubota Graphics, a now-defunct supplier of workstation and PC graphics subsystems. These ideas and approaches have since found their way into a number of companies populated by former Kubota EDA developers and hardware designers.

The makesyn system The makesyn full-chip synthesis system was designed with three things in mind:

• Achievment of a first-pass synthesis of a chip by putting all the Verilog register transfer level (RTL) files in a single directory, specifying only a handful of parameters, and typing a single command.

• Directories and files created during the initial synthesis pass must accommodate changes in the chip hierarchy and the parameters and optimization constraints as the designer refines the design.

• Unnecessary synthesis runs must be avoided to maximize the use of the expensive synthesis tools.

Makesyn would have to build a directory structure in which to run the synthesis tools, create all the synthesis command scripts, and perform the synthesis runs. Whenever the designer changed the hierarchy or tuned the optimization constraints, makesyn would have to assess the effects of these changes and resynthesize the fewest modules possible.

Designers should only have to enter information once; if a particular parameter or constraint applies to the entire chip, the designer should not need to enter it for every module. The system was also designed to support a range of ASIC chip technologies from multiple vendors, all under the synthesis tools from Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys (Mountain View, CA).

The directory structure established by makesyn is shown in Figure 1. All the designer had to do was create the "verilog" directory and place it in the RTL files, and to create the "build" directory and place in it the "setsyn" file. This file set a few Unix environment variables to define such things as the target ASIC cell library and the version of the Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys synthesizer to use. The example "setsyn" file (Listing 1) includes comments to describe some of these environment variables.

Figure 1. The directory structure established by makesyn only requires the designer to create the "verilog" directory and place in it the RTL files, and to create the "build" directory and place in it the "setsyn" file.

Once the designer created the top-level directories and the setsyn file, the first makesyn run created a directory for each module in the chip, built synthesis scripts, and ran the synthesis tools on every module. The scripts were assembled from a hierarchy of command "include" files designated with the ".inc" extension. System defaults are a starting point that creates new files as the design evolves. The synthesis script was assembled according to the template shown in Listing 2, which was run through the "M4" pre-processor to incorporate the include files.

Nearly all the variable Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys settings and commands in the template file were read in from the include files. For example, the ASIC technology include file defined the search paths for the synthesis libraries, set the netlist options required by the ASIC vendor and defined the names for the power and ground signals. Additional include files defined clocks, provided other module-specific information, and specified commands to be run before and after the "compilation" phase, in which the synthesis tools perform the optimization and mapping to the target library.

Each include file could exist in as many as three different locations. A system-wide version of each file was provided in the makesyn library, but the user could have a local copy in the chip's top-level "build" directory or in the directory for an individual module. The search path for the include commands was arranged so a module-specific file would take precedence over a chip-specific file, which would in turn override the system file. Chips generally did not require local copies of the technology include files. As their names suggest, the "custom_pre.inc" and "custom_post.inc" files were usually chip-specific. A few files such as "donttouch.inc" were specific to each module, while "clocks.inc" was generally found in the "build" directory and also in the directory of any module with clock names differing from the rest of the chip.

One of makesyn's more novel aspects was its automatically tracing the submodule hierarchy under each module as it built the synthesis script. The Kubota "hiergen" program parsed the Verilog RTL file and generated a module-specific "read.inc" file that read in the submodules. The most common use of this feature was reading in submodule "skeleton" files consisting of only the Verilog header information. This allowed Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys to link the entire module without performing any synthesis operations on the submodules.

Reading in the full design for a submodule rather than just the skeleton allows a designer to perform some local timing characterization. The default format of the submodule was controlled by the designer with a variable in the "setsyn" file. Designers could also change individual read formats simply by editing the "read.inc" file. Subsequent makesyn runs preserve any such changes by supplementing "read.inc" with hierarchy changes rather than by regenerating the file from scratch.

In addition to submodule reads, skeleton files were also used to read "black box" modules (such as PLL and RAM) when no Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys library model was available. The skeleton files were generated from full Verilog RTL descriptions by the Kubota "skelgen" program. A later version of makesyn included a wide-ranging Verilog analysis tool dubbed "verquery" that handled the hierarchy tracing, skeleton generation, and other useful tasks.

The hierarchy of a chip frequently changed during its design. Makesyn had to detect an individual module's hierarchy changes and modify its synthesis scripts accordingly. This feature was supported by the comparison of the complete newly generated synthesis script with the original version every time that makesyn was run. It ignored comments and other irrelevant information and would cause resynthesis only for relevant differences in the script or changes in the source file.

Makesyn usually could generate a complete synthesis script for each module automatically based upon variables in the "setsyn" and include files. The Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys tools have a rich set of commands for handling many special circumstances, however, so makesyn allowed the designer to maintain a chip- or module-specific template file for fine-tuning unavailable through standard include files. The overall makesyn flow was controlled by a complex makefile compatible with the "Gnumake" program. The steps makefile performed when makesyn was invoked on one module, or on each module when makesyn was invoked on the entire chip were:

1. Save the current module synthesis script.

2. If the Verilog RTL source has changed, run it through a pre-processor (used for conditional includes).

3. Trace the hierarchy and check to see that any referenced submodules exist.

4. Modify the "read.inc" file to reflect any hierarchy changes.

5. Generate any new skeletons required.

6. Build a new synthesis script by using M4 to read the template file and incorporate the include files.

7. Compare old and new synthesis scripts.

8. Rerun synthesis if the script or RTL has changed, writing output design to temporary files.

9. Filter the synthesis log file for errors and warnings, moving temporary files to permanent names only if the synthesis run was clean.

Extensions and improvements Makesyn was designed for chip designs with simple timing relationships between modules that did not require complex timing characterization. One large standard cell designed with makesyn did not follow this model. It had many key timing paths that crossed major module boundaries. The designers accommodated this situation by using makesyn in two stages. First they used the normal flow, in which little or only local timing characterization was performed. This was followed by a full-characterization stage, in which parts of makesyn helped control the flow. In addition, the synthesis script was heavily modified to read in and perform timing characterization on collections of modules at the same time.

This chip was designed when Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys introduced back-annotation on its synthesis tool. The designer was able to re-run the timing characterization phase using back-annotated delays from the routed chip, allowing the synthesis tool to perform limited local optimizations to fix post-route timing problems. Plans to modify makesyn to handle back-annotation runs more elegantly were in progress when Kubota's graphics business ceased operation.

Designers at Kubota Graphics used makesyn successfully to design more than 20 gate arrays, embedded arrays, and standard cell chips using ASIC libraries from LSI Logic (Milpitas, CA), VLSI Technology (San Jose, CA) and AT&T Microelectronics (Allentown, PA). Makesyn derivatives at other companies have been extended to handle more vendors and types of chip technology. The original makesyn system was written by Doug Stiles and Drew Lynch, with numerous enhancements and extensions by Rick Meneely.

Thomas L. Anderson is a freelance author and a CAD engineering manager at Advanced Micro Devices (Sunnyvale, CA). He wasformerly ECAD manager at Kubota Graphics. He is a contributing author to the book Digital Design and Synthesis with Verilog HDL.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design  September 1995