Introduction FPGA CAD Tools Requirement

Introduction

This documents pertains to the development of FPGA CAD design flows. The purpose of the project
was to develop design flows using FPGA CAD tools available in public domain. Right now, numerous
point tools exists that can not communicate in absence of an integrated infrastructure that can ensure
end to end flow. We explored new end to end design FPGA CAD flows through integration of various
front-end compilation engines (SIS, QUIP, FlowMap) with popular back-end tools (VPR, Quartus II).

FPGA CAD Tools Requirement

The various tools examined are listed below along with their download links and compilation steps.

1. SIS 1.3 – ( http://www-cad.eecs.berkeley.edu/~pchong/sis.html )

How To Compile SIS
After downloading, you can compile the source code on a Linux machine as per the instruction
given in the sis-1.3.6/README file. We will just summarize the compilation steps and
workaround for the potential problems that you might face in the compilation depending on
your work environment.

> tar xvfz sis-1.3.6.tar.gz
> cd sis-1.3.6
> ./configure
> make
Upon doing compilation (make command), it is quite possible that you will face following
errors.
read_kiss.c:13: error: conflicting types for 'read_error'
To rectify this problem, edit file sis/io/read_kiss.c. In this file, comment out line#13 as
shown below.
/* extern void read_error(); */
If during recompiling you come across following error
act_bdd.c:151: error: invalid storage class for function 'compare'
To workaround this and other potential problems, make following changes to the files
mentioned below. You can also try recompiling after you make each change to see if you
actually need to make all the changes as mentioned below.
• open file sis/pld/act_bdd.c and comment out line#151
/* static int compare(); */
Add following function prototype to start of the file.
static int compare(char* obj1, char* obj2);
• open file sis/pld/act_ite.c
comment out line#136
/* static int compare(); */
and add following function prototype to start of the file
static int compare(char* obj1, char* obj2);
• open file sis/pld/xln_merge.c
comment out line# 299,
/* static sm_row * xln_merge_find_neighbor_of_row1_with_minimum_neighbors(sm_row
*row1, sm_matrix *coeff); */

Add following prototype to start of file,
static sm_row * xln_merge_find_neighbor_of_row1_with_minimum_neighbors(sm_row
*row1, sm_matrix *coeff);

• open file sis/pld/xln_part_dec.c
comment out line# 58
/* static int kernel_value( ); */
Add following prototype declaration,
static int kernel_value(node_t *kernel,node_t *cokernel,char *state);

Finally if you get the following error, you can ignore this.
gcc: xsis: No such file or directory
make[2]: *** [xsis] Error 1
If you want to correct this, then replace line#69 in xsis/Makefile with
LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@

By this time, sis executable must be ready in your sis/ directory. You can try running
sis/sis from the current directory.

2. VPR – ( http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html )
VPR tool can be build up on Linux machine by simply running 'make' after untaring the
downloaded file. You need to make both t-vpack and vpr.
> tar xvfz vpr_430_tar.gz
> cd vpr
> make
> cd ../t-vpack/
> make
The detailed documentation manual of VPR tool will also be available after untar.

3. QUIP 6.0 - ( http://www.altera.com/education/univ/research/unv-quip.html )
You also need to download Quartus II 6.0 software to use QUIP. These can be downloaded
from the provided link after filling the registration form (quip_download_v60.tar). The software
works on Windows platform. If you download the web edition of the Quartus Software, this
version does not have chip editor facilities included but is sufficient for our purpose.

4. RASP – ( http://cadlab.cs.ucla.edu/software_release/rasp/htdocs/#executable )
The executable version can be downloaded directly for the Linux environment from the above
link after taking necessary permissions. The executable is an extended version of SIS and
contains many implemented algorithms as explained in README file. We will specifically use
the 'FlowMap' algorithm in our integrated flow. You can try alternative algorithms also.

5. BLIF/Verilog Conversion Tools – ( http://www.ece.ubc.ca/~julienl/scripts.htm )
You can download file hdl.tar from the above link. Since the converter tools are made on top of
SIS, you will also need existing SIS executable and the complete SIS framework that we
explained earlier in this section. Make sure you have already compiled the SIS tool.
There are three useful programs listed to convert .blif to .v and vice versa:

b2v (converts a .blif file to a behavioral verilog .v file)
vg2b (converts a gate level verilog .v file to a .blif file)
b2v_tb (generates a verilog testbench file for simulating activities)
We will use b2v for our design flows.

How To Compile b2v

Before starting, note down the installation directory of SIS tool in your Linux machine.
For example, if you install sis-1.3.6 in your home directory, the path will be like
/home/user/sis-1.3.6/sis

Use the following steps to build b2v utility on a Linux machine.
• untar xvf hdl.tar (in a separate directory)
• Open file makefile and make following changes
comment line#1 as shown below

#SIS = /usr/home/soc1/grads/julienl/experiments/src/sis/sis

Replace it with your installation path of SIS in your machine

SIS = /home/user/sis-1.3.6/sis

Modify lines# 30, 33, 36 to correctly specify the path of library libsis.a from your SIS
installation. For example,

b2v: ${B2V_OBJS} ${SIS}/lib/libsis.a
b2v_tb: ${B2V_TB_OBJS} ${SIS}/lib/libsis.a
vg2b: ${VG2B_OBJS} ${SIS}/lib/libsis.a

In above lines, check if location of libsis.a is correctly mentioned. I had to change the
location of libsis.a to following to correctly build b2v converter.

b2v: ${B2V_OBJS} ${SIS}/libsis.a
b2v_tb: ${B2V_TB_OBJS} ${SIS}/libsis.a
vg2b: ${VG2B_OBJS} ${SIS}/libsis.a

Also, you may need to change the following lines,

LIB_DIR = \
-L${SIS}/lib \

to

LIB_DIR = \
-L${SIS} \

• Run 'make'
If you get 'missing terminator' error in file 'hdl_write.c' at line#766, then the reason for
that is the splitting of the line with 'fprintf' onto multiple lines. Take care to remove
unnecessary whitespace and return carriage in the source code line.

Getting Started

To get started on exploring the design flows, it is recommended to familiarize yourself with the
working of the individual tools first. The detailed documentation is available with the download of each
tool. We will mention here the reference to the literature that is basic minimum to understand the later
integrated design flows. We will also refer to the existing documents where-ever necessary in the later
part of this document. Here is the list of the documents that you must familiarize with.

REFERENCE:

1. SIS command documentation - http://www.ece.arizona.edu/~veda/cadtools/sis/
2. SIS manual – sis_paper.pdf (downloaded with SIS)
3. QUIP README file – quip_readme (with QUIP download)
4. QUARTUS Tutorial – quip_v60\tutorials\quartus_tutorial (with QUIP download)
5. QUIP Tutorial – quip_v60\tutorials\quip_tutorial (with QUIP download)
6. QUIP Synthesis Interface – quip_v60\documents\quip_synthesis_interface.pdf (with QUIP

download)
7. QUIP Benchmarks – quip_v60\documents\quip_benchmarks.pdf (with QUIP download)
8. VPR manual – manual_430.pdf (with VPR download)
9. RASP README file – README (with RASP download)
10. RASP Synthesis Script - rasp_syn (with RASP download)
11. BLIF documentation - http://www.ece.arizona.edu/~veda/cadtools/sis/
12. QUIP Benchmark location – quip_v60\benchmarks\quip_designs\
13. b2v README file – downloaded with hdl.tar
14. QUIP Benchmarking - quip_v60\documents\quip_benchmarking.pdf (with QUIP download)

Note: We will be referring to the above listed documents with their corresponding serial number

going onwards wherever required.

Design Flows

We will focus on the following FPGA CAD design flows in this document.

 QUIP -> Tv-Pack -> VPR
 QUIP -> SIS -> VPR
 QUIP -> FlowMap -> VPR
 QUIP -> SIS -> QUIP
 QUIP -> FlowMap-> QUIP

Using QUIP Front End Engine

Go through the Tutorials [4], [5] to learn the working of the QUIP/Quartus tool set.
Read [3] and [6] from reference list mentioned above to get the detail information on the use of QUIP
front end compilation engine. Here we will summarize the results from those documents that will be
needed for our design flows.

The basic commands (if using command line interface) for using Quartus are

 quartus_map (HDL elaboration, technology independent optimizations, technology
mapping, packing into logic cells)

 quartus_cdb (create readable mapped netlist in VQM format)
 quartus_fit (packing, placement, routing)

Alternately you can use the GUI to make a new project (.qpf) and include the design files
having RTL in the project. You will notice that when you create a new project, a QSF (.qsf)
file is also generated in the same directory where the project is created. If you look into the
details of the Tutorial [4] [5], you can get familiar with format of QSF file. The newly
generated QSF file contains the Top level project settings like target FPGA architecture etc.

We will modify QSF file to dump the desired output from QUIP front end.

Synthesis with QUIP

Refer to section 2.2 in [6].

BLIF output from QUIP

Refer to section 3 in [6].
There are certain restrictions on outputting BLIF from the designs after front end analysis in Quartus.
Though these are listed in detail in section 3.3 in [6], we will quickly list them here. You can find the
different benchmarks at [12]. The design characteristics are explained in [7]. [7] also mentions as to
which all designs can be outputted in BLIF format.

BLIF [11] is a gate-level netlist format with following restrictions
 Can not express back-boxes such as DSP (multiplier) blocks, RAM
 Can not express arithmetic carry chains without converting them to gates.
 Ignores asynchronous signals
 For LUT with unconnected inputs, BLIF writes replaces unconnected inputs with 'null'

BLIF can be output from QUIP front-end from two points in the CAD flow.
a) before multi-level logic optimization (MLS)
b) after complete optimization and tech-mapping.

Writing BLIF before Multilevel Logic Optimization

To dump BLIF before MLS optimization, you need to turn on the following control variables:
no_add_ops = on
opt_dont_use_mac = on
dump_blif_before_optimize = on

Use the following TCL command in the QSF file that is created along with the project.
set_global_assignment -name INI_VARS “no_add_ops=on; opt_dont_use_mac=on;
dump_blif_before_optimize=on”
set_global_assignment -name AUTO_SHIFT_REGISTER_RECOGNITION OFF
set_global_assignment -name DSP_BLOCK_BALANCING "LOGIC ELEMENTS"
set_global_assignment -name IGNORE_CARRY_BUFFERS ON

If you want to abort the flow after dumping BLIF, use additional setting in QSF file.
“abort_after_dumping_blif = on” along with options as shown below

set_global_assignment -name INI_VARS "no_add_ops=on;opt_dont_use_mac=on;
dump_blif_before_optimize=on;abort_after_dumping_blif = on"

After setting the TCL commands in the QSF file, run the compilation from the GUI of the Quartus tool.
The compilation can be started using hot keys (CTRL + L) or GUI tab (Processing->Start Compilation)
Upon compilation, you might receive the following Error message if you are aborting synthesis flow
after dumping BLIF (abort_after_dumping_blif = on).

Error: Quartus II Analysis & Synthesis was unsuccessful

But this will have no impact as BLIF file may have been already generated in the project directory.

NOTE: After modifying the QSF file as mentioned above, its important to load the already created
project again in the Quartus tool. This will ensure that the modified QSF file settings are enforced
when we do compilation of the current project. You can do this by simply exiting the Quartus tool and
double clicking on the created project (.qpf). It will reopen the Quartus tool GUI and the project with
the modified settings.

Writing BLIF after LUT Mapping

To write BLIF after LUT mapping, we use a different 3rd setting:
no_add_ops = on
opt_dont_use_mac = on
dump_blif_after_lut_map = on

Use the following in your QSF file
set_global_assignment -name INI_VARS “no_add_ops=on; opt_dont_use_mac=on;
dump_blif_after_lut_map =on”
set_global_assignment -name AUTO_SHIFT_REGISTER_RECOGNITION OFF
set_global_assignment -name DSP_BLOCK_BALANCING "LOGIC ELEMENTS"
set_global_assignment -name IGNORE_CARRY_BUFFERS ON

If you want to abort the flow after dumping BLIF, use additional setting in QSF file.
abort_after_dumping_blif = on along with options as shown below

set_global_assignment -name INI_VARS
"no_add_ops=on;opt_dont_use_mac=on;dump_blif_after_lut_map =on;abort_after_dumping_blif =
on"

After setting the TCL commands in the QSF file, run the compilation from the GUI of the Quartus tool.
The compilation can be started using hot keys (CTRL + L) or GUI tab (Processing->Start Compilation)
Upon compilation, you might receive the following Error message if you are aborting synthesis flow
after dumping BLIF (abort_after_dumping_blif = on).

Error: Quartus II Analysis & Synthesis was unsuccessful

But this will have no impact as BLIF file may have been already generated in the project directory.

NOTE: In both the cases, a file called <projectname>.blif will be created in your projects directory.

NOTE: After modifying the QSF file as mentioned above, its important to load the already created
project again in the Quartus tool. This will ensure that the modified QSF file settings are enforced
when we do compilation of the current project. You can do this by simply exiting the Quartus tool and
double clicking on the created project (.qpf). It will reopen the Quartus tool GUI and the project with
the modified settings.

Design Flow 1 (QUIP -> T-VPack -> VPR)

Taking BLIF output from Quartus after LUT mapping through VPR tool for placement and routing.

Quartus -> LUT Mapped BLIF -> Tv-Pack -> VPR

Integrated Flow

a) Use QUIP front end to do synthesis on the HDL description.
b) Write out LUT Mapped BLIF as described earlier by making suitable changes to QSF file.
c) Pack BLIF from QUIP to .net format using t-vpack tool.
d) Use VPR to place & route.

Known Limitations/Workaround:

 The following error is obtained if you try to pack the BLIF output from QUIP to .net format
using T-VPack tool.
Error: Net has no driver and will cause memory corruption.

Quartus writes out BLIF files where unused LUT inputs are connected to gnd. T-VPack does
not like this, since they don't know what gnd is. To get rid of the gnd LUT inputs, read the blif
file into SIS and write it back out. Now each LUT will be of minimal size (i.e. if only two
inputs were used and two were grounded, sis will write out a 2-input LUT only).

sis > read_blif test.blif
sis > write_blif test.blif

 LUT mapped BLIF dumped from QUIP can have LUTs that have more inputs than the inputs
on the LUTs in the target VPR architecture on which you intend to do the placement and
routing. Take care to ensure that target architecture in VPR do have LUTs with desired number
of inputs to support all the LUTs written out from QUIP. Alternately, you can use the following
steps [1] [2] after reading BLIF into SIS to decompose the LUT mapped BLIF to n-input LUTs
with block minimization objective where targeted VPR architecture can support up to max n-
input LUT.

sis > read_blif test.blif
sis > xl_part_coll -m -g 2 -n 4
sis > xl_coll_ck -n 4
sis > xl_partition -m -n 4
sis > simplify

sis > xl_imp -n 4
sis > xl_partition -t -n 4
sis > xl_cover -e 30 -u 200 -n 4
sis > xl_coll_ck -k -n 4
sis > _xl_nodevalue -v 5
sis > write_blif test.blif

Note that in the above commands, we have targeted to decompose the number of inputs in the
LUTs to 4 assuming that target architecture in VPR has 4 input LUTs. You can specify any
value with parameter -n in the above commands based on VPR architecture. Also, notice that
command _xl_nodevalue -v 5 has been used to check finally if the design has any 5 input LUT in
the design after decomposition. Also, if the objective is to do timing optimization you can use
command xl_rl followed by any block count minimization command (xl_cover, xl_partition).
We strongly recommend you to go through the details each of the commands in [1] [2].

Design Flow 2 ( QUIP -> SIS -> VPR )

Taking unoptimized BLIF output from Quartus through SIS for optimizations/mapping and then to
VPR tool for placement and routing.

Quartus -> BLIF before logic optimizations -> SIS -> T-VPack -> VPR

Integrated Flow

a) Use QUIP front end to do elaboration on the HDL description.
b) Write out unoptimized BLIF as described earlier by making suitable changes to QSF file.
c) Use script.rugged (sis-1.3.6/sis/sis_lib/script.rugged) from SIS to optimize the BLIF netlist.

Take time to read sis-1.3.6/sis/sis_lib/script.rugged.notes on using the script to optimize the
design after reading the unoptimized BLIF file generated from QUIP into SIS.
d) Write out optimized BLIF from SIS.
e) Pack BLIF from SIS to .net format using t-vpack tool.
f) Use VPR to place & route.

Known Limitations/Workaround:

 In this case VPR may give memory allocation crash. The error will indicate the failure to
allocate the required memory. The error may occur after T-VPack has been run to output
the .net file. VPR assumes that the first input in generated .net (output of t-vpack) will not be a
global net. The workaround to this problem is to move the global net declaration in .net file
from the first position to some other position.

 After optimizations, take care to ensure that target architecture in VPR do have LUTs with
desired number of inputs to support all the LUTs written out from SIS. Alternately, you can use
the following steps [1] [2] after doing optimizations in SIS (using script.rugged) to decompose
the LUT mapped BLIF to n-input LUTs with block minimization objective where targeted VPR

architecture can support up to max n-input LUT.

sis > xl_part_coll -m -g 2 -n 4
sis > xl_coll_ck -n 4
sis > xl_partition -m -n 4
sis > simplify
sis > xl_imp -n 4
sis > xl_partition -t -n 4
sis > xl_cover -e 30 -u 200 -n 4
sis > xl_coll_ck -k -n 4
sis > _xl_nodevalue -v 5
sis > write_blif test.blif

Note that in the above commands, we have targeted to decompose the number of inputs in the
LUTs to 4 assuming that target architecture in VPR has 4 input LUTs. You can specify any
value with parameter -n in the above commands based on VPR architecture. Also, notice that
command _xl_nodevalue -v 5 has been used to check finally if the design has any 5 input LUT in
the design after decomposition. Also, if the objective is to do timing optimization you can use
command xl_rl followed by any block count minimization command (xl_cover, xl_partition).
We strongly recommend you to go through the details each of the commands in [1] [2].

 SIS tool can not optimize very large benchmarks. It will abort for need of memory. Typically,
choosing from the benchmark suite of the QUIP download, SIS can not handle benchmarks
with 2500 or more logic elements. So far, we do not have any workaround for this problem.
You can try exiting SIS after each iteration of the optimization (script.rugged) after saving
intermediate BLIF file and load it again to save some memory.

Miscellaneous

 Use of command print_stats in SIS to check the optimization after each round of script.rugged
 Better to write out BLIF after each iteration to backtrack when the run is not able to complete or

you see no improvements in results.

Design Flow 3 ( QUIP -> FlowMap -> VPR )

Taking unoptimized BLIF output from Quartus through FlowMap for optimizations/mapping and then
to VPR tool for placement and routing.

Quartus -> BLIF before logic optimizations -> FlowMap -> T-VPack -> VPR

Integrated Flow

a) Use QUIP front end to do elaboration on the HDL description.
b) Write out unoptimized BLIF as described earlier by making suitable changes to QSF file.
c) Read the BLIF file into the SIS executable downloaded with RASP tool.
d) Use script.rugged (sis-1.3.6/sis/sis_lib/script.rugged) from SIS to optimize the BLIF netlist.

Take time to read sis-1.3.6/sis/sis_lib/script.rugged.notes on using the script to optimize the

design after reading the unoptimized BLIF file generated from QUIP into SIS.
e) Use the script script.fm (provided later in this section) to run FlowMap algorithm for mapping.
f) Write out mapped BLIF after FlowMap.
g) Pack BLIF from SIS to .net format using t-vpack tool.
h) Use VPR to place & route.

Sample Command Script To Be Used For FlowMap (script.fm)

tech_decomp -a 1000 -o 1000
dmig -k 2
flowmap -k 4
greedy_pack -m -k 4
flowpack -k 4

NOTE: The above commands are targeting LUT with input size 4. You can change the value
parameter 'k' to target other LUT sizes.

You can use the above commands after reading the BLIF file generated from QUIP into SIS (take care
to use the SIS executable downloaded with RASP)

Its important to note that [9] [10] lists multiple algorithms and commands to complete the mapping.
You are free to use alternative algorithms for doing the mapping. All the commands applicable for a
particular algorithm are listed in script rasp_syn [10]. You can look into this script and extract the
command steps corresponding to the algorithm of your choice. We have not yet tested other algorithms
so far and will update later on their usage.

Known Limitations/Workaround:

 In this case VPR may give memory allocation crash. The error will indicate the failure to
allocate the required memory. The error may occur after T-VPack is run to output the .net file.
VPR assumes that the first input in generated .net (output of t-vpack) will not be a global net.
The workaround to this problem is to move the global net declaration in .net file from the first
position to some other position.

Design Flow 4 ( QUIP -> SIS -> QUIP )

Taking unoptimized BLIF output from Quartus through SIS for optimizations/mapping and then to
QUIP tool for placement and routing.

Quartus -> BLIF before logic optimizations -> FlowMap -> Quartus

Integrated Flow

a) Use QUIP front end to do elaboration on the HDL description.
b) Write out unoptimized BLIF as described earlier by making suitable changes to QSF file.
c) Use script.rugged (sis-1.3.6/sis/sis_lib/script.rugged) from SIS to optimize the BLIF netlist.

Take time to read sis-1.3.6/sis/sis_lib/script.rugged.notes on using the script to optimize the

design after reading the unoptimized BLIF file generated from QUIP into SIS.
d) Write out optimized BLIF from SIS.
e) Use the b2v tool converter to convert BLIF to verilog file.
f) Set Up a project in QUIP to read the new verilog file and run the compilation.

Using B2V Utility

b2v test.blif > test.v

Known Limitations/Workaround:

 None

Design Flow 5 ( QUIP -> FlowMap -> QUIP )

Taking unoptimized BLIF output from Quartus through SIS for optimizations and then to QUIP tool
for placement and routing.

Quartus -> BLIF before logic optimizations -> SIS -> Quartus

Integrated Flow

a) Use QUIP front end to do elaboration on the HDL description.
b) Write out unoptimized BLIF as described earlier by making suitable changes to QSF file.
c) Read the BLIF file into the SIS executable downloaded with RASP tool.
d) Use script.rugged (sis-1.3.6/sis/sis_lib/script.rugged) from SIS to optimize the BLIF netlist.

Take time to read sis-1.3.6/sis/sis_lib/script.rugged.notes on using the script to optimize the
design after reading the unoptimized BLIF file generated from QUIP into SIS.
e) Use the script script.fm (provided earlier in this section) to run FlowMap algorithm for
mapping. Please refer to documentation in Design Flow 3 for other details related to use of
FlowMap.
f) Write out mapped BLIF after FlowMap.
g) Use the b2v tool converter to convert BLIF to verilog file.
h) Set Up a project in QUIP to read the new verilog file and run the compilation.

Using B2V Utility

b2v test.blif > test.v

Known Limitations/Workaround:

None

Comparison of Design Flows on QUIP Benchmarks

We tried the above mentioned flows on the benchmarks obtained with the download of QUIP.
Note that not all the supplied benchmarks support dumping of BLIF file. Refer to [7] for details of
individual benchmarks.

Benchmark Placement Routing
Logic Critical
Block Path Delay Width Total Total Net Critical
Array Logic Delay Path Delay
13x13 2.95e-08 6 Delay
13x13 3.58e-08 6
barrel16a DF1 15x15 2.72e-08 7 4.053e-09 2.6777e-08 3.083e-08
DF2 30x30 3.99e-08 6
mux32_1 DF3 31x31 4.4e-08 6 2.96e-09 3.90e-08 4.20e-08
6bit DF1 35x35 4.26e-08 6
DF2 42x42 5.18e-08 8 2.96e-09 2.55e-08 2.85e-08
mux64_1 DF3 45x45 7.85e-08 11
6bit DF1 49x49 5.72e-08 10 3.50e-09 3.59e-08 3.94e-08
DF2
DF3 4.59e-09 3.83e-08 4.29e-08

4.05e-09 5.11e-08 5.51e-08

3.50e-09 5.14e-08 5.49e-08

6.23e-09 8.32e-08 8.94e-08

4.05e-09 6.59e-08 6.99e-08

** DF1, DF2, DF3 refers to Design Flow 1, Design Flow 2, Design Flow 3 correspondingly.
** The lut_size in above examples was 4. The architecture targeted was with no_clustering.

NOTE: The above results were obtained with default settings of the tools. To get a detailed
perspective on QUIP benchmarking with respect to settings in QUARTUS tool for performance/area
comparison, please refer to [14].