Open Source Digital Flow
Digital Flow Download
Digital Flow Example
Simulating the Layout with IRSIM
Creating a New Digital Flow
Required components:
- Verilog source
- You can write your own, or you can download example Verilog source from the OSU site (see below) or opencores.org
Warning: The "SIS" program (see below) reads only a subset of valid Verilog code.
- Digital standard cells (OSU)
- This is an excellent source for LEF and GDS standard cells. The cells are all compatible with the MOSIS SCMOS rules for the various processes available throug MOSIS (mostly TSMC and AMI, 0.18um to 0.5um). The standard cell set is available from vcag.ecen.okstate.edu and is available for download, free of charge.
The important components to have (all of which are in the OSU standard cell set) are:
- A LEF-format file with all of the macros defined.
- A GDS file with all of the standard cell layouts
- A technology file for Magic
- Verilog compiler (vl2mv) and logic verification (VIS 2.2)
- Obtain these (as well as a library unfortunately called GLU that they require) from U. Colorado, Boulder VLSI/CAD group. These tools turn Verilog source into a generic logic format understood by SIS. Below you will find a tarball of a Linux port of vl2mv containing one major fix of an error in generating multiplexer logic tables when the multiplexer inputs are a scalar and a 1-bit vector.
- Logic optimization (SIS 1.2)
- This tool taked the BLIF format description and creates a reasonably good netlist representation using a set of standard cells described in the "genlib" format. Obtain this tool from EECS at U.C. Berkeley. I have seen references to SIS version 1.4. If anyone knows where to download the 1.4 version (or if it even exists), please let me know. I will try to put together downloads and compile and install instructions for my Linux ports of these tools.
- genlib file (see download)
- Genlib files for SIS are difficult to find, but easy to create. It just takes a little time to work through the documentation of a standard cell library. The format describes the logic function and physical size of each cell. There's a lot of timing information in the file, too, but left with more or less random values, SIS will still generate a reasonably good synthesis.
- Place and Route (TimberWolf 6.2)
- Obtain a Linux port of the last GPL open source version from OpenCircuitDesign: timberwolf-6.2.tgz.
- Route layout (Magic 7.5)
- Obtain Magic 7.5 from OpenCircuitDesign: Magic home page
- Format conversion scripts (see download)
- None of these programs uses a compatible format, so the main trick to getting a digital design flow working is to have lots of format conversion scripts.
Conversion scripts
File Revision Size Date bdnet2cel.tcl 0 9.7KB Nov. 11, 2006 place2lef2.tcl 0 3.3KB Nov. 11, 2006 place2net2.tcl 0 2.1KB Nov. 11, 2006 synth_script.sh 0 6.7KB Nov. 11, 2006 AddIO2BDnet.c 0 15.9KB Nov. 11, 2006 Bdnet2BSpice.c 0 8.9KB Nov. 11, 2006 Bdnet2Verilog.c 0 14.8KB Nov. 11, 2006 CleanUpBdnet.c 0 11.8KB Nov. 11, 2006 vl2mv-2.1.tgz 2.1 273KB June 11, 2009 Files related to the OSU standard cells (MOSIS SCMOS for TSMC 0.18)
File Revision Size Date osu018.genlib 0 2.8KB Nov. 11, 2006 osu018.par 0 1.3KB Nov. 11, 2006 synthesize_osu018 0 0.2KB Nov. 11, 2006 Files for the example in the next section
This is an example of a simple Verilog source file. It is a configuration logic block for a chip built by MultiGiG, and by itself it is absolutely useless, not to mention inscrutable, which is why it makes a good choice for an example. Note that I was going to use one of the verilog sources from the OSU standard cell library download, but it won't compile under SIS. My suspicion is that I will want a better and more complete Verilog compiler. SIS has a number of other restrictions as well, such as the (apparent) inability of the ".genlib" format to describe a tristate buffer, and the fact that it fails when there is a latch cell named "latch" (parser needs fixing, but is it worth the trouble)?The Verilog subset understood by SIS requires code that does not contain specific timing information (e.g., the "#" construct). I have also been told that bit vectors concatenated with the "{ ... }" notation get assembled backwards. The worst drawback of SIS is that it understands only a single clock, which inevitably gets renamed "clock" regardless of what it started out as. A good near-term project would be to write some tool that would separate out different clock domains from the BLIF-MV format, synthesize them separately through SIS, then recombine their netlists prior to adding buffers and cleaning up. It would also be nice to have a clock buffer insertion tool and a scan insertion tool.
File Revision Size Date map9v3.v 0 1.4KB Nov. 11, 2006
The following is an example of a digital flow from Verilog source to layout. Note that at this point, the flow is very non-automated, and requires quite a few steps, and a lot has to be done by hand, etc. Needless to say, as these are all open source tools, any contributions will be appreciated.Setup
- Create a working directory. For this example, we will assume that the directory path to the example is held as a variable name called ${project_dir}.
- Create three subdirectories of ${project_dir} called source, synthesis, and layout.
- Copy the example file map9v3.v to directory ${project_dir}/source.
- Copy all the scripts and programs to ${project_dir}. Compile the C code:
cc -g AddIO2BDnet.c -o AddIO2BDnet
cc -g Bdnet2BSpice.c -o Bdnet2BSpice
cc -g Bdnet2Verilog.c -o Bdnet2Verilog
cc -g CleanUpBdnet.c -o CleanUpBdnetExecution
- Run synthesize_osu018 source/map9v3
Assuming that you got SIS and VIS properly compiled and installed, this should run both of them, read in the file "osu018.genlib" describing the standard cells that are available, and spit out a number of files, including layout/map9v3_buf.cel and layout/map9v3_buf.par, which are the input files for the TimberWolf place and route tool. Both files contain information that tells TimberWolf exactly how to handle the placement phase, and for the moment controlling this behavior requires hand-editing the files.- There are several switches you can pass to the synth_script.sh script to have some meager amount of control over the post-synthesis process. The two parsed options are "-x" and "-c file". If "-x" is selected, all inputs are latched by inserting a flip-flop after each input signal. The "-c" option is similar, except that file points to a file containing a list of input signals to be latched. If there is a clock signal that is passed to flip-flops inside the cell, it is used as the clock signal for the input latches. If all the internal logic is combinatorial, then an extra signal called "clock" is added to the circuit.
You can also pass the "-f flopcell" or "-b bufcell" to change the cell used for the input latches or the output buffers, respectively. For example, you might want the inputs to be latched with a transparent latch instead of a flip-flop, or you might want all outputs to be buffered with 4x strength buffers.
Note that the input name is "map9v3.v" but the final output is "map9v3_buf.cel". The suffix "_buf" is added to all file formats that contain output buffers added to the original circuit specification.
- The .cel file contains the list of standard-cell subcircuits used to implement the circuit, and the network of connections between them. While the netlist is fixed and should not be messed with, the .cel file also declares all the input and output signals as pins. These will have a form like:
pad 6 name twpin_N<3>After the corners statement, for each pin, you may optionally add the line:
corners 4 0 0 0 72 72 72 72 0
pin name N<3> signal N<3> layer 1 0 0restrict side sideswhere sides may be one or more of T, B, L, or R, concatentated (with no spaces or other puntuation in between), which tells TimberWolf to which side or sides those signals are restricted. If not restricted, TimberWolf will place the pin on the side of the cell that minimizes the net length.- The .par file contains the parameters passed to the TimberWolf place and route program. For a complete list of options and their meanings, you should consult the TimberWolf documentation in the distribution. Most of the values in this file are determined by the fabrication process and the properties of the standard cells. The one value you will want to pay attention to is "GENR*numrows", which is the number of rows of standard cells that will be used. If you remove this line, TimberWolf will attempt to create a square (1:1 aspect ratio) placement. Often you will have a specific space in a chip design to fill, and can divide this space by the standard cell height to arrive at the number or rows of logic to use.
TimberWolf is not a sea-of-gates global router (it makes reference to one called SGGR in the distribution, but SGGR happens to be missing from the distribution. . .). However, in this flow, we do not use the detailed route results from TimberWolf, and assume that a placement that makes a good channel routed solution will also make a good over-the-cell routed solution.
- Run Timberwolf by doing (assuming TimberWolf is in ${src_dir}/timberwolf-6.2):
cd layout pushd ${src_dir}/timberwolf-6.2Normally what you should get the first time around is a graphics window which stops and waits for input. Normally you would just select the menu option "CONTROL->Continue Pgm" to run to completion. Note that TimberWolf often crashes while attempting to exit, but its output files have already been written by the time that happens.
source .twrc
popd TimberWolf map9v3_bufThe output of TimberWolf is three files, two of which we care about: map9v3_buf.pin, which is the netlist, and map9v3_buf.pl1, which is the placement.
- Run a conversion script to put the netlist into a form that Magic can read:
place2net2.tcl map9v3_buf- Getting the cell placement into Magic is a little trickier. First make sure that you have a copy of the appropriate Magic technology file from the standard cell distribution. In the case of this example, that's tsmc018.tech. Next, start Magic:
magic -d OGL -T tsmc018Then, from the Magic command line, do:source ../place2lef2.tclThis should read in the LEF view of the standard cells and generate the placed layout. You should save the layout at this time, so you don't have to regenerate it:
place2lef map9v3_buf ../osu018_stdcells.lefsave map9v3_buf_unrouted- Routing is a time-consuming step, since I have not yet worked out a completely DRC-violation free router (although it is much better than it used to be). To do the global maze routing:
- Select the menu option Options->Maze Router.
- From the popup "Maze Helper" window, select the button "Load"
- Load the netlist file "map9v3_buf.list".
- Select "Sort" to sort the routes from longest to shortest. This aids routing by handling the most complicated routes (namely, the clock) first.
- Select "Fence" to create a boundary around the pins, which will prevent Magic from running routes outside the cell boundary.
- Select all of the unrouted nets, then click the "-->" button to start the maze routing.
- Magic will route as many nets as possible. However, there is no algorithm ensuring that all nets be routable, and sometimes routes can block other routes further down the list. At the end of routing, there may be nets left in the "unrouted" column, and it will be necessary to take step to make these nets routable, by removing blocking nets or moving the position of pins.
- When all nets are in the "routed" column, select everything in that column and type at the Magic prompt: "verifynet". If everything is correct, you are done. If not, you'll get a list of what is different between the layout and the netlist. You can also verify nets in the unrouted column with the command "verifynet unrouted".
- Finally, you will have to correct all the DRC errors introduced by the maze router. Fortunately, most of these are simple problems where Magic cannot see that it has a spacing error to the path that it is generating, and are easy to fix. Be sure to save the routed design!
- The quality of the maze router is heavily dependent upon the parameters in the "mzrouter" section of the Magic technology file "tsmc018.tech". There are a number of changes that need to be made to get a good, clean route.
(to be finished)
An important caveat to remember when synthesizing logic is that a verilog compiler like "cver" or Icarus will only confirm that the source code is functionally correct. Given the number of stages in synthesis and the number of tools involved, one would be very wise to be skeptical of the result produced. Any number of things can go wrong, from an incorrect logic statement in the "genlib" file to a verilog statement not understood by vl2mv to a LEF obstruction layer not put in the magic technology file. In the end, you will want to ensure the correctness of the physical layout one way or another. The best way is to extract a ".sim" netlist from Magic, and simulate using IRSIM. IRSIM (see the IRSIM website on opencircuitdesign.com) has commands that make it very easy to construct a simulation that exactly matches a Verilog testbench. So you can simulate through IRSIM and check the results in the analyzer against the output of, say, cver and dinotrace.
The following are the steps needed to create a digital flow for an arbitrary technology, given the presence of the components outlined in the first section at the top of this web page.
(to be finished)
![]()
| email: |
|
Last updated: June 11, 2009 at 12:03pm