1. Overview

In this class we will do some very simple synthesis of your designs. The primary goal of this exercise is to get a sense for the actual hardware your verilog is creating. Synthesizing your design will allow us to see:

The actual gates

Area

Delay

The actual longest path in your design

There is a lot more to synthesis optimizations than what we will cover in this class.

We will be using Synopsys DC Compiler and a 45nm gate library provided by FreePDK. A lot of the details will be abstracted away and you will be using a simple script called synth.pl which will do most of the work for you.

To synthesize your design several pieces of information are required:

A gate library that says what types of gates are available at your disposal. We will use the FREEPDK library installed at: /u/k/a/karu/courses/cs552/cad/Synopsys_Libraries/libs

List of verilog files and the name of each module. Now you will begin to appreciate why the verilog file name and the module name have to be identical

The top-most module name

Synthesis constraints (how much area, what frequency, arrival times for each primary input etc.)

Whatever is in the red box, you will *IGNORE* for this class and instead use the defaults we provide.
All your designs will be synthesized to meet a 1 Ghz clock frequency (1ns clock-period). Area goal is to minimum area.

We will perform synthesis in the following three steps:

Write verilog, verify

Check verilog is synthesizable

Synthesize the verilog

Before we can begin, we should setup environment variables and such just like we did for ModelSim.

2. Environment setup

Note a dot is the first character in the filename. Many browsers may sometimes delete this dot. So be careful. Your file copied in your home directory MUST have the dot as the first character.

You MUST not modify this file

You MUST not change its name

You MUST copy the file in your home directory

IMPORTANT: Logout of the shell, then log back in. This will make sure the modifications to your .bashrc.local take effect

3. The synth.pl script

The synth.pl script is a wrapper that will allow us to perform synthesis. It requires the following information and has the following usage:

3.1 Usage

Usage: synth.pl [options]
Options:
[-cmd <check|synth>] What to do:
check = just check if everything is ok
synth = perform synthesis (will take longer)
[-type <other|proc>] What is the design:
proc = This is the processor.
Use when synthesizing the full processor
then -f, -d, -e, -m, -wb must be specified
other = Some other design (use for hw, caches etc.)
[-top <module name>] Name of the top-most module in your design. This
must be module instantiated inside the _hier level.
**You cannot specify the _hier module here*
[-opt <yes|no> ] Optimize the design yes or no. [Default = no]
[-list <filename> ] <filename> has a list of verilog files which make up
your design.
[-file <f0,f1,f2,..> ] Provide a comma-separated list of verilog file names.
Only one of -list or -file can be used
[-f <fetch module] Name of your fetch module,
required if type=proc, else ignored
[-d <fetch module] Name of your decode module,
required if type=proc, else ignored
[-e <fetch module] Name of your execute module,
required if type=proc, else ignored
[-m <fetch module] Name of your memory module,
required if type=proc, else ignored
[-wb <fetch module] Name of your write-back module,
required if type=proc, else ignored

3.2 The output it creates are:

Output:
If cmd=check
synth/hiearchy.txt Hieararchy of your design
synth/<top>.syn.v Gate-level version of your design
All modules will be in ONE single
verilog file. Replace top with the
top module name you specified
as input.
If cmd=synth
The above two files, PLU
synth/report_reference.txt Detailed usage of each module
synth/area_report.txt Detailed area report
synth/timing_report.txt Detailed timing report

3.3 Some example usages:

Example usages:
Checking the ALU from hw2/problem2
prompt> synth.pl --list=foo --type=other --cmd=check --top=alu
Synthesizing the ALU from hw2/problem2
prompt> synth.pl --list=foo --type=other --cmd=synth --top=alu
Checking the full processor for demo2
prompt> synth.pl --list=foo --type=proc --cmd=check --top=proc -f=fetch -d=decode -e=execute -m=memory -wb=write_back
Assumes your fetch module is called fetch, decode module
is called decode etc. Since we are specifying module names (and NOT files names), there is no .v at the end of these names.

4. Step-by-step tutorial

4.1 Synthesizing alu from hw2/problem2

Step 1

Setup environment

Step 2

Go to the correct directory where you have all the verilog files.

prompt> cd hw2/problem2

Step 3

Make a list of verilog files that are part of the design. Create a text file with one verilog filename per line.

No testbenches should be included in this list

No _hier files which are wrappers should be in this list

clkrst.v should NOT be in the list, since we don't want to synthesize the clock generator

Go look in synth/*.txt. You will find an area report, cell report, and timing report.

Step 6

Checking synthesis output

Make sure that no cells in the synth/cell_report.txt file has zeroes in it. If you see a zero area for a module name, then that means that module had some kind of Verilog coding error and did NOT get synthesized. You must fix this problem. Look in the synth.log files and search for that verilog file name in the file and look for warnings.

Fix these warnings and try step 6 again.

4.2 Synthesizing full processor

We will do this slightly differently. For all other problems we allowed the synthesis tool to completely "flatten" the design. If we flatten the full processor, then reasoning about it and applying optimizations will be hard. So we will break it up into some large pieces and preserve the hierarchy at those levels. Specifically we will preserve fetch, decode, execute, memory, and writeback modules of your processors. Within each of those modules, we will let synthesis completely flatten the design. This is why, when you specify the --type=proc option, you must specify the fetch, decode, execute, memory, and writeback module names.

Step 1

Setup environment

Step 2

Go to the correct directory where you have all the verilog files.

prompt> cd project

Step 3

Remember list of verilog files that are part of the design. Create a text file with one verilog filename per line. For example list.txt with the following contents.

Go look in synth/*.txt. You will find an area report, timing report, proc.syn.v, cell_report, and a reference report

Step 6

Checking synthesis output

Make sure that no cells in the synth/cell_report.txt file has zeroes in it. If you see a zero area for a module name, then that means that module had some kind of Verilog coding error and did NOT get synthesized. You must fix this problem. Look in the synth.log files and search for that verilog file name in the file and look for warnings.

Fix these warnings and try step 6 again.

4.3 Interpretting the output files (all in synth/)

hierarchy.txt

This file describes your design hierarchy in text-format. It shows the list of top-level modules.
For each module it shows list of sub-modules. And for each sub-module, the sub-sub-module and so on.
An example is shown below:

Whatever you see on the line: "Total cell area:" is the actual cell area.

timing_report.txt

This file will contain the list of the top-20 longest/slowest paths in your design. For each such path you will see the start and a list of gates that make up the path. Recall that, all your designs will be synthesized to meet a 1 Ghz clock frequency (1ns clock-period). For example:

In the above example, there are about 40 or 50 gates on that path. Right at the end notice the string slack (VIOLATED). This means the design is consuming 0.08ns longer than it should. You should try optimizing. The names of gates and their prefix give you a hint on which stage of the pipeline this logic belongs to.

reference_report.txt

This file will show you all the low-level modules that ended up in your design. It will show you how many times each such cell was instantiated. For example:

cell_report.txt

This file will provide the individual areas of every module synthesized. If you see any module with a zero in this file, it means that module was NOT synthesized correctly. The format of this file is similar to the references_report.txt file.

.syn.v file

This file contains the synthesized structural netlist of your design.

4.4 Optimizing your design - make it faster and smaller

Thus far we have been synthesizing your design preserving its hierarchy. That is, if you said build a barrel-shifft using mux -> shift -> mux -> shift. Then synthesis will blindly create a hardware module for each such individual module you specified.

You can guide synthesis into "flattening" your design, i.e. treat everything between two flip-flops as raw combinational logic and simply create the most efficient logic gates to implement this. When you do this process, you will see your hierarchical design of the datapath completely disappear.