vpr_5.txt

VPR布局布线源码

     VPR and T-VPack1 User’s Manual 

                 Summer 2008 VPR 5.0 Full Release, July 17, 2008 


                 VPR Contributers: 
                         Betz, Vaughn ([e-mail]) 
                         Campbell, Ted ([e-mail]) 
                         Fang, Wei Mark ([e-mail]) 
                         Jamieson, Peter ([e-mail]) 
                         Kuon, Ian ([e-mail]) 
                         Luu, Jason ([e-mail]) 
                         Marquardt, Alexander 
                         Rose, Jonathon ([e-mail]) 
                         Ye, Andy 



1.       Overview 

     VPR (Versatile Place and Route) is an FPGA placement and routing tool. VPR has four 
required and many optional parameters; it is invoked by typing: 

> vpr netlist.net architecture.xml placement.p routing.r [-options] 


     Netlist.net is the netlist describing the circuit to be placed and/or routed, while 
architecture.xml describes the architecture of the FPGA in which the circuit is to be realized. If 
VPR is placing a circuit, the final placement will be written to placement.p; if VPR is routing a 
previously placed circuit, the placement is read from placement.p. The final routing of a circuit is 
written to file routing.r. The format of each of these files is described in Section 0. 
     VPR can be run in one of two basic modes. In its default mode, VPR places a circuit on an 
FPGA and then repeatedly attempts to route it in order to find the minimum number of tracks 
required by the specified FPGA architecture to route this circuit. If a routing is unsuccessful, 
VPR increases the number of tracks in each routing channel and tries again; if a routing is 
successful, VPR decreases the number of tracks before trying to route it again. Once the 
minimum number of tracks required to route the circuit is found, VPR exits. The other mode of 
VPR is invoked when a user specifies a specific channel width for routing. In this case, VPR 
places a circuit and attempts to route it only once, with the specified channel width. If the circuit 
will not route at the specified channel width, VPR simply report that it is unroutable. 
     VPR can perform either global routing or combined global and detailed routing. 
     T-VPack is a packing program which can be used with or without VPR. It takes a 
technology-mapped netlist (in blif format) consisting of lookup tables (LUTs), flip flops (FFs), 
and black boxes. It packs the LUTs and FFs together to form more coarse-grained logic blocks 
while treating inputs and outputs from black boxes as primary outputs and inputs respectively. 
The netlist it outputs is in the .net format required by VPR, and hence can be fed directly into 
VPR. Its usage is: 

> t-vpack input.blif output.net [-options] 




     1 T-VPack is a timing-driven version of the VPack program that was provided with earlier versions of 
VPR. When run in its non-timing-driven mode, T-VPack is equivalent to VPack. 

   Typing either VPR or T-VPack with no parameters will print out a list of all the available 
command line parameters. 

2.       Compiling VPR and T-VPack 

    If your compiler of choice is gcc and you are running a Solaris-based Sparcstation, you can 
compile VPR simply by typing make in the directory containing VPR’s source code and 
makefile. If your compiler and/or architecture are different, however, you will have to make 
some small modifications to the makefile. First, change the CC = gcc line in the makefile so that 
CC is set to the name of your desired compiler. Second, you may want to change the line 
OPT_FLAGS = -O3 to set OPT_FLAGS to the value that gives the highest level of optimization 
with your compiler, and it may be necessary to give the linker different options so it finds all the 
relevant libraries on your machine. If, during compilation, you get an error that type XPointer is 
not defined, uncomment the “typedef char *XPointer” line in graphics.c (many X Windows 
implementations do not define the XPointer type). Finally, if you are compiling VPR on a 
system without X Windows (e.g. Windows NT), you should add a “#define NO_GRAPHICS” line 
to the top of vpr_types.h. VPR’s built-in graphics will all be removed by this define, allowing 
compilation on non-X11 machines. 
    Project files are included for Microsoft Visual C++ 2005 for compilation under Windows. 
The Cygwin package should allow compiling under Windows using the makefile. Graphics are 
not supported when compiling with Visual C++, but should be supported when compiling with 
Cygwin. 
    If you are using T-VPack to convert SIS output to VPR’s netlist format, you should make 
similar modifications to T-VPack’s makefile. 

3.       Typical CAD Flow 

     Figure 1 illustrates the CAD flow we typically use. First, Odin [16] converts a Verilog 
Hardware Destription Language (HDL) design into a flattened netlist consisting of logic gates 
and blackboxes that represent heterogeneous blocks. Next, the ABC [1] synthesis package is 
used to perform technology-independent logic optimization of each circuit, and then each circuit 
is technology-mapped into 4-LUTs and flip flops [2]. The output of ABC is a .blif format netlist of 
LUTs, flip flops, and blackboxes. The T-VPack program [3, 4, 5, 6] then packs this netlist of 
LUTs and flip flops into more coarse-grained logic blocks, and outputs a netlist in the .net 
format VPR uses. The black boxes are also converted into the .net format. VPR [3, 4, 7, 8, 9, 
10, 11] can then place the circuit and either globally route it or perform combined global and 
detailed routing on it. The output of VPR consists of a file describing the circuit placement, 
another file describing the circuit’s routing, and various statistics concerning the minimum 
number of tracks per channel required to successfully route, the total wirelength, etc. In order 
to find the minimum number of tracks required for successful routing, VPR actually attempts to 
route the circuit several times with different numbers of tracks allowed per channel in each 
attempted routing. 
     Of course, many variations on this CAD flow are possible. It is possible to use other high- 
level synthesis tools to generate the blif files that are passed into ABC. Also, one can use 
different logic optimizers and technology mappers than ABC; just put the output netlist from 
your technology-mapper into .blif format and feed it into T-VPack. Alternatively, if the logic 
block you are interested in is not supported by T-VPack, your CAD flow can bypass T-VPack 
altogether by outputting a netlist of logic blocks in .net format. VPR can place and route netlists 
of any type of logic block -- you simply have to create the netlist and describe the logic block in 
the FPGA architecture description file. Finally, if you want only to route a placement produced 
by another CAD tool you can create a placement file in VPR format, and have VPR route this 
pre-existing placement. 

                                    Verilog HDL Circuit 




                              Front-end Synthesis (ODIN) 
         Description of 
        Heterogeneous 
          Blocks on 
            FPGA                .blif Format Netlist of Logic 
                                    and blackboxes for 
                                 Heterogeneous Blocks 



                                Logic Optimization (ABC) 
                            Technology Map to LUTs (ABC) 



                               .blif Format Netlist of LUTs 
                                    and Flipl Flops and 
                                      blackboxes for 
                                 Heterogeneous Blocks 

  Logic Block 
                      T-Vpack: Pack FFs and LUTs into Logic Blocks 
  Parameters 



                                   .net Format Netlist of 
                                     Logic Blocks and 
                                 Heterogeneous Blocks 




   FPGA                                     VPR: 
                                                                     Existing Placement or 
 Architecture               Place Circuit or Read in an Existing         Placement from 
Description File                         Placement                      another CAD tool 

                           Perform Either Global or Combined 
                                Global/Detailed Routing 




                          Placement and Routing Output Files 
                            Placment and Routing Statistics 

                                           Figure 1 

4.       Operation of T-VPack 

     As stated earlier, T-VPack takes as input a technology-mapped netlist of lookup tables 
(LUTs) and flip flops in .blif format, and outputs a .net format netlist composed of more complex 
logic blocks. The logic block to be targeted is selected via command-line options. The simplest 
logic block T-VPack can target consists of a LUT and a FF, in the configuration shown in Figure 
2. We call this logic block a basic logic element. 




     To have T-VPack target a logic block of this form, use the command: 

> t-vpack <input.blif> <output.net> -lut_size <K> -no_clustering 


     In the command above, the italicized values in angled brackets, <>, should be replaced by 
the file names or numbers you are using, while unitalicized words are keywords and must be 
typed exactly as shown. 
     The -lut_size <K> option specifies the number of inputs to a LUT (i.e. K in Figure ). If - 
lut_size is not specified, a default LUT size of 4 is assumed by T-VPack. The -no_clustering 
option indicates that the logic block is a single basic logic element with no local routing to route 
the logic block output back to the logic block inputs. By default, T-VPack marks all clock nets in 
the input netlist as global nets which VPR should not route. Since clocks are typically routed via 
a dedicated network in FPGAs, this is usually the most realistic thing to do. If, however, you 
want clocks to be routed as using normal routing resources, you should specify -global_clocks 
off on the T-VPack command line. 
     T-VPack is capable of targeting a more complex form of logic block, which we call a 
cluster-based logic block [5]. Figure 3 depicts an example. A cluster-based logic block 
consists of N basic logic elements (i.e. N LUTs and N FFs), along with local interconnect that 
allows the N cluster outputs to be routed back to LUT inputs. Since the number of logic block 
inputs, I, can be less than the total number of LUT inputs (KN, where K is the number of inputs 
per LUT), the local interconnect also allows each of the I inputs to be routed to any of the KN 
LUT inputs. Cluster-based logic blocks are very similar to the logic blocks used in the Altera 8K 
and 10K FPGAs, and are reasonably similar to those used in the Xilinx 5200 and Virtex FPGAs. 

    To target such a logic block, use a command line of the form: 

> t-vpack input.blif output.net –lut_size <K> -cluster_size <N> 
  -inputs_per_cluster <I> -clocks_per_cluster <C> 


    The meaning of the -inputs_per_cluster and -cluster_size parameters should be clear from 
Figure . The -clocks_per_cluster option is used to specify how many distinct clocks can be 
used by each logic block. 

4.1 T-VPack Options 

4.1.1 Architecture Description Options That Are Always Valid 

     -lut_size <int> 
          Number of inputs per LUT (i.e. K). 
          Default: 4. 

     -no_clustering 
          Specifies that no clustering is to be performed -- i.e. the logic block consists of one 
          BLE (a LUT and a FF) with no local routing. 
          Default: cluster. 

     -global_clocks {on | off} 
          Indicates whether clocks should be marked as being routed via a special, global 
          resource. VPR does not route global signals. 
          Default: on. 

4.1.2 Architecture Options Valid Only When -no_clustering Is Not Specified 

    -cluster_size <int> 
         Number of BLEs in a cluster-based logic block (i.e. N). 

        Default: 1. 

   -inputs_per_cluster <int> 
        Number of distinct inputs in a logic cluster (i.e. I).