Digital Flow

Table of Contents

Open Source Digital Flow
Digital Flow Download
Digital Flow Example
Simulating the Layout with IRSIM
Creating a New Digital Flow
Code changes and release notes

A Digital Flow using Open Source EDA Tools

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 "VIS" program (see below), or more precisely, its preprocessor "vl2mv", 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 through MOSIS (mostly TSMC and AMI, 0.18um to 0.5um). The standard cell set is available from vlsiarch.ecen.okstate.edu and is available for download, free of charge (see also the Flows main page).

The important components to have (all of which are in the OSU standard cell sets) are:

  1. A LEF-format file with all of the macros defined.
  2. A GDS file with all of the standard cell layouts
  3. 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.3)
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, but it is not clear that this is anything but a repackaged version 1.3. The version above will compile under Linux.

I also have a version that has some corrections to function calls that I am posting on this site; you can find it in the table below. It is more likely to compile on finicky systems. Thanks to Jeff DuMonthier at NASA for the code fixes. I have no trouble with the original code from Berkeley on my Fedora system, but, as they say, your mileage may vary.

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.

Placement (TimberWolf 6.3)
Obtain a Linux port of the last GPL open source version from OpenCircuitDesign: timberwolf-6.3.2.tgz. In May of 2011 I made a particular effort to remove all the segmentation fault errors and get the tool to compile (relatively) cleanly on 32-bit and 64-bit systems. It is now reliably stable.

Detail Router (qrouter 1.0)
Obtain Qrouter 1.0 from OpenCircuitDesign: Qrouter home page
This is a work in progress, but is a full-featured multi-layer, sea-of-gates maze router. For a very very long time, a good open-source maze router was not available anywhere, and it had been on my list of important things to do for ages. Finally, in June of 2011, I finally sat down and wrote it. Although as a starting point it was based on router code by Steve Beccue, it is totally overhauled and can be considered written from scratch for all practical purposes. It is a command-line-only tool, taking standard format (LEF and DEF) files as input and generating an annotated DEF format file as output.

Layout viewer (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.

Digital Flow Download

Conversion scripts

File Revision Size Date
bdnet2cel.tcl 0 12.7KB Jun. 21, 2011
rtl2bdnet.tcl 1 8.3KB Nov. 21, 2012
rtl2sim.tcl 0 7.7KB Nov. 19, 2012
place2lef3.tcl 1 3.3KB Apr. 29, 2011
place2lef2.tcl 0 3.3KB Nov. 11, 2006
place2def2.tcl 3 22.4KB Mar. 29, 2013
preproc.tcl 0 6.7KB Jun. 19, 2011
postproc.tcl 1 6.0KB Oct. 2, 2012
posttw.sh 0 1.5KB Jun. 19, 2011
synth_script.sh 0 10.2KB Jun. 22, 2011
resynth_script.sh 0 7.3KB Mar. 27, 2013
place_and_route.sh 0 6.7KB Jun. 22, 2011
initial_placement.sh 0 3.4KB Mar. 27, 2013
AddIO2BDnet.c 1 16.2KB Oct. 11, 2012
Bdnet2BSpice.c 1 9.1KB Oct. 11, 2012
Bdnet2Verilog.c 2 15.2KB Oct. 11, 2012
CleanUpBdnet.c 1 12.0KB Oct. 11, 2012
clocktree.tcl 0 16.3KB Dec. 7, 2012
vl2mv-2.1.tgz 2.1 273KB June 11, 2009
sis-1.3.6.tgz 3.6 3.15MB October 6, 2012

Files related to the OSU standard cells (MOSIS SCMOS for TSMC 0.35)

File Revision Size Date
OSU035.genlib 0 2.6KB Jun. 19, 2011
osu035.par 0 1.3KB Jun. 19, 2011
synthesize_osu035 0 0.3KB Jun. 10, 2011
resynthesize_osu035 0 0.4KB Mar. 27, 2013
OSU_dig.lps 0 23KB Oct. 11, 2012
osu035_stdcells.sp 1 25KB Oct. 11, 2012
Note that most of these files are not ones that come with the standard OSU downloads. The last one, however, is a copy of the SPICE netlist for the standard cell set (excluding the pads). The reason for this copy is that the original file has pins in random order, even among cells that are just different strengths of the same logic gate. I have cleaned up the file to put all pins in order. The ".lps" file above it is a library for XCircuit where the pin order of the SPICE netlist output follows the order in the file "osu035_stdcells.sp" below it, so that it is correct to include that file at the top of a netlist produced by XCircuit.

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)?
File Revision Size Date
map9v3.v 0 1.4KB Nov. 11, 2006
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.

Digital Flow Example

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

  1. 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}.

  2. Create four subdirectories of ${project_dir} called source, scripts, lib, synthesis, and layout.

  3. Copy the example file map9v3.v to directory ${project_dir}/source.

  4. Files to go to ${project_dir}/scripts:
    bdnet2cel.tcl
    place2def2.tcl
    place_and_route.sh
    postproc.tcl
    posttw.sh
    preproc.tcl
    synth_script.sh
    synthesize_osu035
    All of these files can be downloaded from this web page.

  5. Files to go to ${project_dir}/lib:
    OSU035.genlib
    osu035.par
    osu035_stdcells.lef
    Note that the third of these files is from the OSU download.

  6. 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 CleanUpBdnet
    and add these programs to a standard executable path (such as /usr/local/bin).

Execution

  1. From the project directory, run synthesize_osu035 source/map9v3
    Assuming that you got SIS and VIS properly compiled and installed, this should run both of them, read in the file "OSU035.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.

  2. 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.

  3. 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>
    corners 4 0 0 0 72 72 72 72 0
    pin name N<3> signal N<3> layer 1 0 0
    After the corners statement, for each pin, you may optionally add the line:
    restrict side sides
    where 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.
  4. 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.

  5. Run the place-and-route script from the command line, again from the project directory, using the command line invocation as follows:
    scripts/place_and_route.sh layout/map9v3
    To get this to run properly, you will probably need to edit the place_and_route.sh script and change the path to the timberwolf-6.3 source directory, which by default assumes /usr/local/src/timberwolf-6.3.
  6. The place-and-route script runs two separate programs, first TimberWolf to do the placement phase, then qrouter to do the detail route. In between, it runs the conversion script "place2def2.tcl" to generate the standard DEF file input for qrouter. Finally, it takes the routed DEF file and runs magic in batch process to write out a .mag file as the final result.

    The output of qrouter will be an annotated version of the input DEF file, with "_route" appended to the name ("map9v3_buf_route.def"). The script changes this name back to the original project name, removing both the "_buf" and "_route" suffixes, so that the final two files (DEF file and magic layout file) are:

    map9v3.def
    map9v3.mag
    These files contain the completed, routed circuit. Some tools can read the DEF file directly; however, it is best to use the Magic layout viewer to read the file, check for problems, DRC violations, etc., and re-write the file in GDS format.

  7. To get the final GDS format file, run Magic either with the GDS view of the standard cells saved to a directory and accessed with the "addpath" command, or read on the fly, which is the method I show here:
    magic -d OGL
    And on the command line:
    gds readonly true
    gds rescale false
    gds read osu018_stdcells.gds
    load map9v3
    gds write map9v3
    The end result of this step is the finished GDS file of the design. . . you're done!

Simulating the Layout with IRSIM

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.

Creating a new Digital Flow

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)

Code changes and release notes

  1. Date: June 19, 2011
    Initial offering of the full digital flow with the new open-source detail router qrouter.

  2. Date: June 21, 2011
    Modified the bdnet2cel.tcl script to do much more thorough parsing of the LEF file, including ignoring various sections that are normally found in LEF files (but not needed by the converter script), and parsing layer information for track pitches. The pins must be declared with dimensions equal to the route pitches, because TimberWolf will place pins next to each other, and if they are placed closer together than the route pitch, they will overlap and not be routable.

  3. Date: December 6, 2012
    Made substantial updates to the place2def2.tcl script. This corrects for track offset from the origin and also corrects an error that gave all the pin positions an offset that could potentially drop the pins outside of the routing track area, making them unroutable.
  4. Date: December 7, 2012
    Added clocktree.tcl to the list of files to download. This script tool breaks up large fanout nets (like the clock) with buffer trees. It is not particularly useful without the load balancing tool that I have not yet converted to a generic process.


email:

Last updated: August 26, 2013 at 1:41pm