Effective Synthesis Methodology for ASIC Projects

An Effective Synthesis Methodology and Synthesis Environment Organization are very important for the success of a project. This article presents an example of a synthesis environment organization for a medium-to-large size ASIC design project. All used scripts are fully functional and can be downloaded and modified to match additional site-specific needs.

RTL Code Database Organization Example
Synthesis Tasks Division
Project Structure for Synthesis
Main Synthesis Script Features
Running Presynthesis Check Using run_syn Script
Running Synthesis Using run_syn Script
Download Scripts

RTL Code Database Organization Example

Usually, chips are built from separate functional modules. For example, a switch chip can be built from an endpoint module, instantiated multiple times, and switching fabric module. Usually, a clock domain scheme also influences module division, and a good practice is to minimize the number of clock domains for each module. This principle is also useful for a hierarchical layout methodology, building each functional module as a separate hard core.

The good design practice is to keep code of each of the functional modules in separate directories. For example, for the switch example used above there can be 3 directories created: endpoint, fabric and chip (structural connections of switching fabric instance and multiple endpoints instances to create a switch chip). Inside each of the directories, it is a good idea to add a configuration file, which would contain a list of all design files in the current directory included for compilation. (We can call this file “vfiles” and create it with one simple unix command: ls *.v > vfiles, if all files in current directory need to be compiled). These configuration files (one per functional module) can facilitate synthesis and verilog compilation process and also make sure that we are synthesizing exactly the same design as we need to verify or in the process of verifying.

For example, using verilog-xl, ncverillog or vcs compilers, we can run a command: <verilog_compiler_name> -f vfiles in order to compile all module’s files. Cadence verilog compilers require us to stay in module’s directory, but Synopsys VCS compiler has a more advances option: –F path to conviguration file , allowing us to run compilation “remotely”, from another UNIX directory. For example, running a compilation in of the whole project using vcs, we can use the following command: vcs –F endpoint/vfiles –F fabric/vfiles –F chip/vfiles.

Synthesis Tasks Division

In most cases, Synthesis, STA and formal verification do not require a deep understanding of the design functionality. So, these tasks can be assigned to the experienced synthesis specialist, a “guru”. His/her tasks include development of scripts for successful synthesis run, STA and timing closure etc. However, it will be difficult for him/her to test each designer’s block for each design iteration in order to find synthesis–related issues. The most convenient way for him/her is to concentrate on stable design “snapshots”, taking a new snapshot once per week or even more rarely. It means that each designer must run a kind of light synthesis after each code update. This approach brings the following problems:

Designers usually don’t want to spend time configuring synthesis tools and developing synthesis environments;

During synthesis environment and synthesis run designers consume expensive time of a Design Compiler license;

Designers may choose a different design strategy and different synthesis settings; this can lead to different synthesis results;

Designers may process a synthesis log and understand synthesis problems differently

Another possibility is to use LINT tools in order to check RTL code. This will solve the problem with DC licenses, but creates a new one: not always a third-party LINT tools are fully compatible with the Design Compiler. The best LINT tool to check design for compatibility with the Design Compiler is, from my point of view, the Design Compiler itself or Synopsys LEDA RTL checker.

In this article, I would like to show the most efficient and cost–effective way to run Presynthesis Checks and Module Synthesis using the Design Compiler. Presynthesis check of average module requires a very small amount of time of DC run (for most cases, less than a minute). Using LSF, this job can also be queued and executed in the future if all D licenses are currently consumed.

Project Structure for Synthesis

It is a good practice to keep all project-related data in one place. So, for each project member, a separate directory inside project’s account should be created. In this directory, user can store all project-related data. However, projects also have common and users-independent data, which should be stored in project account as well. For example, main project directory can have such structure:

<main_project_directory>

| |

common users

| | | | |

bin lib syn .. user1 user2 ..

Each user directory can also have a fixed structure. This directory structure can be built from automatically during new user addition to the project. Matching directory structures for different project users facilitates scripting and coordination of design tasks.

Proposed directory structure for synthesis is:

/users/<user_name>/syn/

db/ - contains synthesized netlist in db format

reports/ - contains synthesis and presynthesis check reports

constraints/ - contains additional (optional) module-specific synthesis constraints

.synopsys-dc_setup - symbolic link to the common initialization file

There should be one common DC initialization file for the whole project. Each user should have symbolic link to this file inside user’s “syn” directory (this link can be also created automatically during new user addition to the project.

So, all required scripts for running synthesis environment are:

syn_funcs.tcl (stored somewhere in /common/syn directory) This file contains dc _tcl procedures; this file should be sourced from the common initialization file .synopsys-dc_setup

run_syn (stored in common/bin directory). This is the main synthesis/Presynthesis checks run script.

Main Synthesis Script Features

In order to get help , use –help switch: run_syn -help

This will print the following help text:

Command line switches:

run_syn [-file <verilog file full name>]

[-vfile <configuration `vfiles` full name>]

[-db <synopsys db full name>]

-top <top_module_name>

[-clk <top_clock_name>]

[-period period_value]

[-flat/hier/check]

This function runs synthesis or presynthesis check for specified design.

Synthesis reports (<top_module_name>.log and <top_module_name>.chk) will

be written into project's .../<user_name>/syn/reports directory,

Synthesised netlist will be written into .../<user_name>/syn/db directory.

Command line switches description:

-file <verilog file full name>: Load specified verilog file for synthesis.

Number of files can be loaded also, using `-file` switch before every

file name.

-vfile <configuration `vfiles` full name>: Load specified in vfiles verilog

files for synthesis. This is more convenient way to load multiple

verilog files for synthesis. The number of `vfiles' can be also

loaded using `-vfile` switch before every `vfiles` name.

Note: User can use both -file and -vfile options in the same command line.

At least one verilog file sholud be loaded for synthesis.

-db <synopsys db full name>: Load synopsys db file for synthesis/reoptimization.

This option can ve useful after sucessful presynthesis check, when loaded

design is already transformed into db file, but not compiled yet.

-top <top_module_name>: Specify top module name in the loaded design.

This is required option.

-clk <top_clock_name>: Specify top module clock port name in the loaded design.

This is required option for synthesis, but optional for presynthesis check.

-p[eriod] <period_value>: Specify clock period in ns. This is optional value. By

default, 10 ns clock period will be used.

-flat/hier/check: This switch determines, whether normal synthesis or presynthesis

check will be run.

Use -check to run presynthesis check only (save runtime).

Use -flat or -hier to run flatten or hierarchical synthesis.

Without specifying anyone of these switches, presynthesis check will be run.

Running Presynthesis Check Using run_syn Script

In order to run Presynthesis check on “my_design.v” file with the top module name “my_design”, run the following command:

run_syn –file <path to my_design.v> -top my_design

This command will:

1. Read specified design into DC using read_verilog command

2. Output synthesis log to stdout and also store it inside syn/reports/<my_design>/synthesis.log file

3. After successful linkage, run “check_design” command and store check report inside syn/reports/<my_design>/synthesis.chk file

4. Store design inside syn/db/ directory as <my_design>_chk.db file. This will accelerate loading design for the following synthesis run.

5. Exit from DC and free the license.

6. Parse syn/reports/<my_design>/synthesis.log file and adds the following report subsections into synthesis.chk file:

Errors report: all synthesis errors

Warnings report: all synthesis warnings

Incomplete cases report.

Inferred latches report.

Here is an example of incomplete cases and inferred latches reports:

LATCHES REPORT

==============

Found latch my_reg in module my_design, line 483

(File '…../syn/my_design.v')

…..

CASE REPORT

==============

Uncomplete case found at line 241 of case beginning at line 233

(File '…../syn/my_design.v')

….

Running Synthesis Using run_syn Script

In order to run synthesis on the module “my_design.v”, with top module my_design and clock my_clk with period 12 ns, run the following command:

run_syn –file <path to my_design.v> -top my_design –clk my_clk –p 12 –hier/flat

This command will:

1. Read specified design into DC using read_verilog command;

2. Generate all check reports as described in the previous chapter;

3. Set core-independent portion of timing constraints using “set_default_timing” procedude (this procedure should be modified to match the projects requirements)

4. Check existence of /syn/constraints/<my_design.tcl> file. If this file exist, it is loaded into Design Compiler; if no, only default timing setting will be used for synthesis.

5. If –flat switch is used, all design will be flatten and all the other modules except the flattened one will be deleted from DC memory.

6. Compile design

7. Generate timing, cell and area reports. Timing report is divided on 3 sections: