Qflow 1.1 Digital Synthesis Flow Reference Page

Table of Contents

Qflow Usage
Qflow Syntax and Options
The Digital Synthesis Flow
Additional Information
Tips for Writing Synthesizable Verilog
Creating a New Digital Flow

Qflow Usage

Setup

The first step in synthesizing a circuit is to have a project directory which will be the workspace for qflow. The project directory can be named whatever you want. The project directory should have three subdirectories, named
source
Contains the verilog source code
synthesis, and
Contains working files and RTL verilog output
layout.
Contains working files and DEF file output
The verilog source file (.v extension) should be placed in the source subdirectory. This is mostly for convenience in organizing files. If you specify a flat directory structure, qflow will work with it, but you will have a large number of files all in the same directory, which can be confusing.

Execution

From the project directory, do:
qflow source_name
That is, if you have a verilog source file named "circuit.v", you should run the command "qflow circuit". For a complete list of options, see the section below. The result of this step is the creation of three files:
qflow_vars.sh
Contains project-dependent variables needed by all the tools, identifying the project paths, qflow executable paths, and technology used.
qflow_exec.sh
Contains the sequence of commands needed to complete the synthesis flow.
project_vars.sh
This is an empty file, but may be edited for control over the command line options passed to various tools in the tool chain. This file will never be overwritten, so user options can be preserved.
When qflow is given no options, the file qflow_exec.sh will have a list of commented commands. This allows the user to uncomment the tool chain commands one at a time and run each tool independently. In most cases, the design cycle will require checking the result of each step and making adjustments as necessary. Eventually, the flow will be stable and all steps can be run in batch.

Stages of the Flow

Here is the typical sequence of commands found in the qflow_exec.sh file for qflow 1.1:
synthesize.sh options
Logic synthesis, standard-cell mapping, and load balancing, fanout reduction, and decongestion.
vesta.sh options
Static timing analysis (without back-annotated parasitics).
placement.sh
Placement of standard cells with buffer tree optimization
router.sh
Detail routing
cleanup.sh
Removal of temporary working files
display.sh
Display of the final layout

Qflow version 1.0 has an additional level of resynthesis followed by a second placement stage, which was improved and merged into a single step in qflow version 1.1:

synthesize.sh options
Logic synthesis, standard-cell mapping, and load balancing.
vesta.sh options
Static timing analysis (without back-annotated parasitics).
placement.sh
Placement of standard cells
resynthesize.sh
Placement-based fanout reduction, and load balancing
placement.sh
Placement using modified netlist from resynthesis
router.sh
Detail routing
cleanup.sh
Removal of temporary working files
display.sh
Display of the final layout

Qflow Syntax and Options

Qflow Command Syntax

qflow [options] [actions] source_name
Where options and actions are listed below. source_name is the name of the verilog source file to synthesize (with or without the ".v" extension).

Options

-T technology
--tech technology
Use the technology technology for synthesis. If not specified, then the directory is searched for an existing file qflow_vars.sh. If it exists, then it is parsed to see what technology was previously specified for the project, and selects that to be the technology. Otherwise, the default technology (osu035) is used. If the technology is specified by name, it should be a named directory that can be found in the qflow install location under subdirectory "tech" (normally, "/usr/local/share/qflow/tech/"), or in the current working directory, or in the directory indicated by environment variable QFLOW_TECH_DIR. In the technology directory must be a file named technology.sh, containing all of the configuration settings used by qflow (see section on adding new technologies, below).

-p project
--project project
This option may be supplied if qflow is not being run in the top-level project directory. The value of project is the project directory where qflow should dump its files, and all pointers in those files will refer to the indicated project directory project.

-t toolname
--tool toolname
This option specifies a non-default tool to be used by the synthesis flow. At present, only one option is available, which is odin, to use the Odin-II synthesis frontend instead of the default yosys synthesis frontend, in qflow version 1.0. In qflow version 1.1, this option is no longer available.

-h
--help
Generate some help text, and exit.

-v
--version
Print the qflow version number, and exit.

Actions

All actions are represented in the output file qflow_exec.sh. However, if specific actions are called out on the command line, those commands related to the actions will be left uncommented in the file. When qflow sources the command file, these actions will be executed in sequence.

There are two actions that are easy to remember and encompass the most important steps, so you don't have to remember all the names of all the steps to add to the command line:

build
Run these steps in sequence: synthesize, place, buffer, route (see below)

all
Run these steps in sequence: synthesize, place, buffer, route, clean, display (see below)

Individual synthesis steps are as follows:

synthesize
Run the verilog synthesis (yosys, or, in qflow-1.0 only, Odin-II and ABC) and load balancing (blifFanout) and node fanout reduction (blifFanout, in qflow-1.1 only)

sta
Run static timing analysis (vesta)

place
Run the placement (graywolf)

buffer
(qflow 1.0 only)
Perform fanout reduction, and rerun the load balancing and placement (clocktree, blifFanout, and graywolf). Note that qflow 1.1 does this in one pass during the "synthesize" stage.

route
Run the detail router (qrouter)

clean
Clean up temporary files in all subdirectories.

display
Display the layout result (magic)

Environment Variables

The following environment variables are meaningful to qflow:

QFLOW_TECH_DIR
Use the variable definition as the location where the technology directory can be found. This environment variable overrides the default location in the qflow install path. It can be overridden on the command line with the "-T" option.

QFLOW_TECH
Use the variable definition as the name of the directory where technology information can be found for the target technology for the synthesis. This environment variable overrides the default technology that is provided with the qflow distribution, which is "osu035". It can be overridden on the command line with the "-T" option.

QFLOW_PROJECT_ROOT
Use the variable definition as the name of the top-level project directory. This environment variable overrides the default project location, which is the current working directory ("."). It can be overridden on the command line with the "-p" option.

QFLOW_SYNTHESIS_TOOL
Specify the synthesis tool to use for qflow. This is "yosys" by default, and the variable may be set to "odin" to use the alternative Odin_II synthesis frontend. It can be overridden on the command line with the "-t" option.

In qflow version 1.1, this environment variable is no longer supported.

User-defined options

For most projects, the user will want to have control over many aspects of the synthesis process. The file "project_vars.sh" is the primary location of such user options. Most options are declared by setting a shell variable in the file. The following shell variables are recognized by qflow. This list is frequently updated. More options are available than are listed here; only those option settings of interest or help to the user are described here:
yosys_options "text"
Options to pass to yosys for synthesis. In cases where more control is needed over the processing done by yosys, this option is the best one to use, namely for passing an alternative script to yosys through the "-s" option. Most other command-line options to yosys will not be of use to the qflow user.

The preferred procedure is to run qflow with standard options to yosys; this will create a file "modulename.ys" containing a usable, but not necessarily optimal, processing script. It will, however, contain all the correct commands for reading the verilog file or files, mapping to the technology specified for qflow, and writing a BLIF format file needed for the rest of the synthesis flow. This file will be regenerated and overwritten on each run of qflow. Copy this file to another name. Then edit it for any extra processing that is needed (e.g., "iopadmap -inpad ..." to add buffers to input signals), and set yosys_options to "-s newscript.ys".

yosys_script filename
The filename indicates the name of a file containing commands to pass to yosys to perform the main part of the synthesis. The contents of the file are inserted into the normal synthesis script between the commands to load the necessary verilog source files and the commands to map the synthesis result to the standard cell set. It therefore differs from passing "-s filename" in yosys_options (see above), which is a complete replacement for the entire synthesis script. The content of filename is a direct replacement for the following standard synthesis commands used by qflow:
proc; memory; opt; fsm; opt

yosys_debug
If this variable is defined, then the "-purge" option is not passed to yosys during optimization, so that all internal node names are retained. This results in a layout that is much bigger, with a number of non-functional buffers inserted to maintain nets with specific signal names (particularly prevalent for layouts derived from hierarchical verilog sources). The result allows all signal names to be probed during simulation and debugging, but is generally not what one would want in an implementation.

nobuffers
If this variable is defined, then the module outputs will be unbuffered; that is, module output pins will be connected directly to register outputs, which may also be internally connected to other inputs. The default behavior is to buffer register outputs, so that output pin loads cannot change the internal timing characteristics of the circuit. Buffering is highly recommended. The typical reason for not buffering is to synthesize a small subcircuit, such as a decoder driving an analog circuit, where all output loads are small, and circuit area is restricted.

odin_options "text"
Options to pass to Odin_II for synthesis. Use "odin_ii -h" to get a list of options. The "-W" option is useful for generating a lot of warning messages.

In qflow version 1.1, this option is no longer supported.

abc_script filename
(Qflow version 1.0 only)
The filename indicates the name of a file containing commands to pass to ABC to perform the synthesis. The file will be prepended with the commands necessary to read the BLIF-format file and standard cell libraries, and followed by the "map" command and the command to write the mapped BLIF-format netlist. The contents of the "abc_script" file would normally be one of the ABC "standard scripts". In the ABC source distribution, these can be found in the file "abc.rc", where they have names like "resyn", "resyn2", etc. The default script used by qflow corresponds to the ABC script known as "resyn2", which is a fairly general-purpose script producing good synthesis results in the vast majority of cases.

This option was discontinued from qflow version 1.1.0 to version 1.1.13, where it was re-introduced.

abc_script string
(Qflow version 1.1 only)
The string represents either the name of a file containing ABC commands, or, if it starts with the character "+", a set of semicolon-separated commands passed to the ABC logic optimizer (see ABC documentation for information about valid commands that can be passed to it; see yosys documentation for the specific syntax of the "abc -script" command in yosys). This option was added in qflow-1.1.13 when it was noted that a non-default script could improve synthesis results. The default script was updated to the improved one, but the option was added to allow the qflow end-user to experiment with other scripts, should they wish to do so.

Note that when this option is in the form of a single unquoted string starting with "+", ABC commands must be strung together without spaces or linefeeds, separated only by semicolons.

vesta_options "text"
One of the more important options to Vesta, the static timing analyzer, is "--period value", to specify an expected minimum clock period for circuit operations. The clock period is given in units of picoseconds (ps). The option "-l load" specifies a typical output pin load capacitance of the circuit, when integrated into and operating in a larger context.

fanout_options "text"
blifFanout has only a few options that are not already used by qflow: "-l
addspacers_options "options"
(From qflow version 1.1.54) Options "-stripe width spacing pattern [-nostretch]" will configure the addspacers tool to automatically add power and ground stripes from top to bottom of the layout, connecting together all rows' power and ground. width and spacing are given in microns, while pattern is a character string with some combination of "P" (power), "G" (ground), or "0" (none). These are applied to stripes in sequence from left to right, repeating as needed. So pattern "PG" would be a set of stripes alternating between power and ground (the most common pattern). To avoid specific routing difficulties or pin collisions, one may wish to apply a different pattern. The option "-nostretch" tells addspacers to place the power buses on top of the existing layout. Without this option, the cell will be stretched with fill cells under each power stripe. Stretching the cell may or may not help avoid routing issues around the power stripes.

clocktree_options max_fanout
Clocktree has a single option, which is the maximum fanout count of any single node. Therefore this variable, if used, should be set to a single integer value. The default is 16; that is, nets with more than 16 inputs will be broken up into groups with at most 16 inputs each, fed by a buffer tree.

In qflow version 1.1, this option is no longer supported. The clock tree and buffer tree insertion is taken care of by the blifFanout tool, so options for clock and buffer tree control should be passed with fanout_options.

initial_density value
(Available from qflow version 1.0.95) This option sets an initial density to use, where the density value is defined as the fraction of the layout area comprising actively routed (that is, not fill or decap) cells. For small cells (< 1000 gates), it should not be necessary to specify a density (the default is 1, or no filler cells except as needed to straighten up the edges of the layout area). For large cells, and especially for cells with areas of dense combinatorial logic (such as multipliers), specifying an initial density is critical to getting the design to route.

qrouter_options "text"
The useful qrouter options are "-k tries", "-f", and "-v value". Qrouter evaluates its progress, and in the case of a difficult route---such as too much congestion with too few route layers available---it may determine that it is stuck. Occasionally its evaluation is wrong and it exists just prior to getting a valid solution. It is rare, but just in case, the option "-k tries" tells qrouter to "keep going" tries more times, after things start looking hopeless. Beware---this can cause ridiculously long runtimes, and qrouter may never find a solution (prior to qrouter version 1.3.18, the option was simply "-k" with no addition value, and would keep trying indefinitely). The option "-f" tells qrouter to force a connection to a pin, even if qrouter determines that all tap points of a pin are unroutable due to obstructions. The "-v" sets the level of verbose output, which can produce a huge amount of output, so use it carefully.

The option "-r value" was useful for versions of qrouter prior to 1.3.42, and indicates the scalefactor of the output precision compared to centimicrons. Thus, if the manufacturing grid is 5nm, then "-r 2" should be used. From version 1.3.42, qrouter automatically gets the manufacturing grid precision from the technology LEF file.

via_stacks num_vias
This value is passed to qrouter from the ".cfg" router configuration file. It indicates how many vias may be stacked on top of one another. Usually, this value will be set in the technology script, but the user may want to make the stacking more restrictive.

via_pattern type
This value is passed to qrouter from the ".cfg" router configuration file. It indicates how vias are supposed to be placed relative to the grid. Some processes with tight route track spacing and metal overhang requirements need vias to be placed in a checkerboard pattern with the overhangs rotated on every other position to avoid creating DRC errors. The values of type are "none", "normal", and "invert". By default, if no patterning is specified, "none" is assumed (vias are not rotated based on position). "normal" and "invert" differ only in the grid position offset of the pattern. For via patterning to work, the technology LEF file must define the first two vias for each metal layer pair as rotated versions of each other.

The Digital Synthesis Flow

Synthesis

Placement

Fanout Reduction (Qflow 1.0 only method)

Fanout Reduction (Qflow 1.1 method)

Routing

Display

Additional Information

  1. There are several switches you can pass to the synthesis.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. (NOTE: This item refers to netlist manipulation performed by AddIOtoBDnet, which is currently removed from the flow)

    You can also change the "flopcell" or "bufcell" entries in the technology shell script 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.

  2. 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 automatically generated and should not be messed with, the script that generates it appends a file of the same name with the extension .cel2 to the end of the .cel file. The .cel2 file is a convenient place to declare all the input and output signals as part of padgroups and give detailed information about where they should be placed around the edges of the layout.

    For a complete description of the .cel file format, see the documentation on graywolf. In summary, pins are grouped into "padgroups" with the following syntax:

    padgroup group_name [permute| nopermute]
    twpin_pinname
    [fixed|nonfixed ]
    ...
    [restrict side sides]
    [sidespace frac-low frac-high]
    where sides may be one or more of T, B, L, or R, concatentated (with no spaces or other puntuation in between), which tells graywolf to which side or sides those signals are restricted. If not restricted, graywolf will place the pin on the side of the cell that minimizes the net length. The sidespace statement restricts placement between limits specified as a fraction of the total side length, between zero and one inclusive.

    Also look at this example .cel2 file that corresponds to the qflow tutorial example.

  3. The .par file contains the parameters passed to the graywolf place and route program. For a complete list of options and their meanings, you should consult the graywolf 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, graywolf 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.

    Graywolf 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. . .). By specifying a large number of implicit pass-through connections in each standard cell, the result produced by graywolf is close to the result it would get for a sea-of-gates or over-the-cell router.

  4. 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 osu035_stdcells.gds2
    load map9v3
    gds write map9v3
    The end result of this step is the finished GDS file of the design. . . you're done!

  5. The Magic layout editor is also a good resource for extracting a netlist of the layout based entirely on the physical layout, to get either a SPICE or sim netlist. The SPICE netlist can be used in conjunction with netgen to verify the layout against the original synthesized netlist. The sim netlist can be used in conjunction with IRSIM to perform a functional verification of the system. For details, see the tutorial page.

Tips for Writing Synthesizable Verilog

This section refers specifically to the alternative Odin-II/ABC synthesis front-end, and is useful only for Qflow version 1.0 with the alternate synthesis frontend.

This section has become completely deprecated with the introduction of "yosys" into qflow. "yosys" is capable of parsing any officially synthesizable subset of Verilog-2005, and so there are no specific restrictions other than the normal prohibitions against simulation directives in the verilog source. See the yosys manual section 2.2, "Features of Synthesizable Verilog", with references to the IEEE standards document on the subject.

Qflow version 1.1 no longer supports Odin-II.

The developers of qflow, Odin-II, and ABC have gone to great lengths to accomodate the many, obscure ways in which a system can be written in verilog. However, the verilog syntax is so complicated and confusing that a complete coverage of all ways of abusing the syntax is a monumental task, and the tools are not able to provide quite this level of support. However, enough syntax forms are covered that it is not too difficult to convert any verilog source into something that can be synthesized.

Note that prior to Odin-II and ABC, the only open-source solution for verilog synthesis to a standard-cell mapping target was VIS and SIS, and were restricted to almost trivial verilog syntax, such as single- clock domains only, in one level of hierarchy, no bit-shifts, and so forth.

Here are the dos and don'ts of writing (or editing) verilog source for synthesis under qflow using Odin-II/ABC.

Don't use functions
As of this writing (October 2013), Odin-II does not support verilog functions.

Set all signals in a state machine unambiguously
Odin's main drawback is the inability to handle cases where a signal is set to one value at the top of a procedural block, as a default value, and then later set to something else according to a specific condition. For example,
value <= 2'b00;
if (testsig == 1'b1) value <= 2'b10;
cannot be synthesized, and must be re-written as:
if (testsig == 1'b1) value <= 2'b10;
else value <= 2'b00;
This is probably the most common syntax that breaks when synthesizing in Odin-II, and possibly the most difficult to convert to a synthesizable form.

Avoid the use of multiple resets
The qflow postprocessor handles reset conditions on flip-flops by attempting to pull reset conditions out of a verilog code block. Too many signals in the sensitivity list can confuse the preprocessor. Verilog is at fault here, by not providing any clear way to specify how a register is to be reset. By convention, it is usually specified as the second edge-triggered signal in the sensitivity list after the clock in an "always" statement, and the reset condition is handled immediately afterward. Statements of the form
always @(posedge clock or posedge reset) begin
   if (reset) begin
     // reset registered values
   end else begin
     // main block
   end
end
are preferred.

Beware of resets in module subcircuits
When the preprocessor pulls a reset signal out of a block, often the remaining verilog source that is passed to the synthesis tool is left with the reset signal in the input/output list of the module, but unused within the module. If this module is used as a subcircuit, Odin-II will attempt to optimize the reset signal out of the subcircuit, and then complain that the calling module is passing it a bad signal. Although this is an error in Odin-II, if it happens, the error can be circumvented by placing some reference to the reset signal in the subcircuit source in such a way that will not be removed by the preprocessor. In the above example,
always @(posedge clock or posedge reset) begin
   if (reset) begin
     // reset registered values
   end else begin
     if (!reset) begin
       // main block
     end
   end
end
will suffice to keep one reference to "reset" in the subcircuit and prevent Odin-II from attempting to optimize it out of the subcircuit.

Avoid excessive complexity in a reset blocks
The preprocessor knows how to parse the following types of reset statements:
signal <= 0;
signal <= 1;
signal <= other_signal;
vector <= 3'b000;
vector <= 10;
This takes care of basically all use cases, although it may take some effort to rewrite a complicated reset block into this form. In particular, if the reset condition involves combinatorial logic, or vector bundles, such as the following:
signal <= other_signal1 | other_signal2; signal <= {other_signal1, other_signal2, 3'b000};
then it would be necessary to declare an additional wire, assign it the combinatorial value, and then use that additional wire as the reset value.

Other uses, such as conditional or case blocks, or any other structure besides simple registered signal assignments in the reset block are generally prohibited. For example, the following structure is not synthesizable:

always @(posedge clock or posedge reset) begin
   if (reset) begin
     if (other_signal) begin
       // reset some registered values
     end else begin
       // reset other registered values
     end
   end else begin
     // main block
   end
end
Don't use underscores in digit values
Odin-II does not handle syntax such as
signal <= 10'b00_0000_0000;
so remove any such underscores from digits in the verilog source.

Don't take vector ranges of constants
This is most likely to show up in the use of parameters; e.g.,
parameter BASE_ADDR = 15'h8fe0;
assign signal = BASE_ADDR[5:0];
where it is not necessarily obvious that the vector range is being applied to a constant value. The above example is easy to recast in a synthesizable form, by doing:
parameter BASE_ADDR = 15'h8fe0;
assign signal = BASE_ADDR & 6'd63;
Don't use keywords "signed" and "unsigned"
These keywords are not supported by Odin-II. This can be problematic because it may not be easily discernable how the arithmetic in the module depends on the signage of a variable. Proceed with caution, and simulate thoroughly.

Don't use constant values without a bit width
Odin-II does not support the use of, e.g., "'h0", even when this is used in a context in which bit width is irrelevant; e.g.,
assign signal = x >> 'h3;
In these cases, replace the value either by an integer, or with a bit width large enough to hold the value:
assign signal = x >> 4'h3;
assign signal = x >> 3;
Don't use variable bit shifts
Odin-II cannot handle bit shifts by a variable amount; that is,
assign signal = x >> 3;
is legal but
assign signal = x >> y;
is not.

Don't put wire or register declarations or wire assignments in the module I/O list
The preprocessor will handle statements of the type
wire signal = value;
even though Odin does not, by breaking the statement up into separate lines for the wire declaration and the wire assignment. However, the preprocessor will not handle such statements when they are in the I/O list of the module. The following are all unsynthesizable:
module mymod ( wire signal );
module mymod ( wire [3:0] vector );
module mymod ( reg signal );
module mymod ( reg [10:0] vector );
module mymod ( wire signal = 0 );
module mymod ( wire [2:0] vector = 3'b000 );
Restrict the I/O list of a module to contain only the names of all input and output (and inout) signals. No declarations, no bit ranges, and no assignments.

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.

Most of these files have simple syntax that can be copied from an existing technology, like the OSU035 technology that is packaged with qflow, and modified as appropriate for the new technology.

The list of files and what they are used for is given below, followed by a description of the syntax of each file format used.

.sh Main variable definition file
This is the most important file of all, because it is used to gather information from different sources into a single file of variable names that can be used by each of the qflow scripts.

.lib (Liberty) file
The .lib file contains detailed timing information for all standard cells, as well as information about the standard cell function, and a number of other properties. This is an open standards format and is usually included with standard cell libraries. It is required when using the yosys synthesis frontend with qflow, and it is required for the qflow static timing analysis (vesta).

.genlib file (qflow version 1.0 only)
The .genlib file is deprecated with the use of the yosys synthesis frontend, since yosys reads a liberty format timing file and automatically generates a .genlib file for use in calling abc for combinatorial optimization. A .genlib file is needed in the tech library directory only for use with the optional Odin-II/ABC synthesis frontend.

The genlib file tells ABC what standard cells to use for synthesis, and provides a functional description of each. Genlib files for ABC 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, ABC will still generate a reasonably good synthesis.

Qflow comes with a tool called "liberty2tech", which is compiled and placed in the qflow binaries install target directory. If the standard-cell vendor supplies a timing file in the Liberty text format, then this tool will generate a genlib file and a gate.cfg file (see below) automatically from the contents of this file. For standard cell sets with many entries, this tool avoids a lot of hand-editing. Note that the liberty2tech tool will generally produce more cells than are needed by the synthesis flow. Remove any entries that are not required. Note that the ABC mapper does NOT like to see DFF entries in the file. Flip-flops are inserted by replacement into the netlist file after ABC has run.

Usage:

liberty2tech liberty_file genlib_file gate_cfg_file [pattern]
where:
liberty_file
is the name of the Liberty format file
genlib_file
is the name of the output genlib file
gate_cfg_file
should be "gate.cfg" (output file)
pattern
determines what cells go into the genlib file. Pattern matching is exact except for characters "^" indicating beginning-of-string, and "$" indicating end-of-string. For example, if you want all cells ending with "X1", the pattern string would be "X1$".
As noted, Qflow version 1.1 does not use the .genlib file.

gate.cfg file (qflow version 1.0 only)
This file is used by blifFanout to figure out what variants of standard cells exist with what drive strength. To perform the load balancing, it is necessary for this file to record the propagation delay from input to output per fF of load, and the input capacitance of each of its inputs. Usually this information is provided in documentation by the standard cell vendor.

See also comments above about the use of the liberty2tech tool for automatically generating this file.

As noted, Qflow version 1.1 does not use the gate.cfg file.

.super file (qflow version 1.0 only)
This file is also deprecated when used with the yosys synthesis frontend (see .genlib files, above). This file is an auxilliary file used by ABC. ABC is able to create this file itself, so you don't need to. However, ABC is not very smart about where to put the file when it creates it. To get this file, run ABC manually. First, run the synthesis flow through the "synthesis" step. ABC will fail. However, in the first synthesis step, Odin-II will produce a ".blif" file. Copy this .blif file to the tech directory. Then run ABC and give it the following commands:
read_blif filename.blif
read_library techname.genlib
map
ABC will generate the "techname.super" file and write it into the tech directory. Delete the ".blif" file, and you're done.

As noted, Qflow version 1.1 does not use the .super file.

.par file
This file contains a set of parameters passed to graywolf, which itself runs numerous sub-programs and needs a complicated setup. Mostly this file just tells graywolf basic information about the number of metal layers used for routing. The file is copied from the technology directory to the layout directory, where it can be customized for a particular synthesis run.
LEF file(s)
The LEF file contains technology information useful to the placement and routing tools. Its primary function is to provide a description of each cell in the standard cell set, including the cell boundary and position and geometry of pins and other routing obstructions, but without any functional description, or details of transistors (or anything that is not on a routing layer). Another important function is to specify routing layer width, pitch, direction, and minimum separation information for use by the detail router. These two functions are sometimes found in the same LEF file, and sometimes they are separated into more than one file. Qflow accepts any number of LEF files, which are specified in the technology script (see "Main variable definition file", above). Often a LEF file will be provided with a standard cell set. If not, the layout tool Magic can generate a LEF macro library from a GDS file of the standard cell set using the "lef write" or "lef writeall" commands. See the documentation for Magic for details.

Standard cell SPICE file
This is the SPICE library file containing a ".subckt" entry for each of the standard cells.

magic techfile (.tech file)
If Magic is to be used for circuit extraction, then the technology file needs to be specified, preferably with GDS input/output sections, DRC rules, device extraction information, and LEF input/output information, all corresponding to the technology used by the standard cells.

.magicrc file
In most cases, a few lines of commands suffices to tell Magic what technology file to load on startup, and additionally (optionally) refine the grid spacing, turn DRC on or off, etc.

Standard cell GDS file
This is the physical layout library containing the GDS cell view for every standard cell in the technology.

.prm file
This is a simple parameter file for use by IRSIM which tells IRSIM very basic modeling information about transistors in the process so that IRSIM can make a decent approximation of the behavior of the transistor-level circuit in the digital domain. The information includes gate capacitance, and resistance of devices when active or saturated.

Standard cell verilog file
This is the functional simulation library containing the verilog modules for every standard cell in the technology. It is not mandatory for qflow, but can be used to simulate the gate-level netlist using a verilog simulator such as Icarus verilog.



email:

Last updated: June 9, 2017 at 10:09pm