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


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
Contains the verilog source code
synthesis, and
Contains working files and RTL verilog output
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.


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:
Contains project-dependent variables needed by all the tools, identifying the project paths, qflow executable paths, and technology used.
Contains the sequence of commands needed to complete the synthesis flow.
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 of standard cells with buffer tree optimization
Detail routing
vesta.sh -d options
Static timing analysis (with back-annotated parasitics).
Removal of temporary working files
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 of standard cells
Placement-based fanout reduction, and load balancing
Placement using modified netlist from resynthesis
Detail routing
Removal of temporary working files
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).


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

Generate some help text, and exit.

Print the qflow version number, and exit.


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:

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

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

Individual synthesis steps are as follows:

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)

Run static timing analysis (vesta)

Run the placement (graywolf)

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

Run the detail router (qrouter)

Run static timing analysis (vesta) with back-annotated delays

Clean up temporary files in all subdirectories.

Display the layout result (magic)

Environment Variables

The following environment variables are meaningful to qflow:

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.

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.

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.

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

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.

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_use via_name_list
This values is passed to qrouter from the ".cfg" router configuration file. It indicates a list of via names from the technology LEF file that are allowed to be used. The restriction can be used to enforce via orientation, or double vias, etc.

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



Fanout Reduction (Qflow 1.0 only method)

Fanout Reduction (Qflow 1.1 method)



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]
    [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
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
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 else begin
     // main block
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.

The file consists entirely of "set" lines in tcsh syntax (set varname=value_string). If "value_string" contains spaces then it should be in quotes. Many scripts source this file, so the entire file must contain valid tcsh syntax.

The variable names in the technology .sh file that are recognized by qflow are listed below in four groups. The first group is critical and points to all of the standard format files needed for routing:

set leffile = path/file.lef
Indicates the path to the LEF file definining the standard cell macros.
set techleffile = path/file.lef
Indicates the path to the LEF file defining route layer width, pitch, spacing, etc. Sometimes this information is in the cell macro LEF file, in which case this variable may be omitted.
set libertyfile = path/file.lib
Indicates the path to the liberty format description of the standard cell functions and pin timing.
The second group is files that are not in the critical path of the synthesis flow, but are used to generate various files for simulation or display.
set spicefile = path/file.cdl
Indicates the path to the file containing SPICE subcircuits of the standard cells. This is used to create a SPICE netlist of the design. File may be in SPICE or CDL format.
set gdsfile = path/file.gds
Indicates the path to the GDS mask-layer definition of the standard cells. This is only needed for full extraction and transistor-level verification.
set techfile = path/file.tech
Indicates the path to the techfile for the Magic layout editor. Magic is used for displaying the cell or doing extraction from layout, post-synthesis.
The third group gives pointers to qflow on various names of cells to prefer for use in different situations, default global net names, and such.
set tiehi = "logic1_gate"
The name of the cell that outputs a constant logic 1 value.
set tiehipin_out = "logic1_pin_name"
The name of the output pin of the logic 1 cell.
set tielo = "logic0_gate"
The name of the cell that outputs a constant logic 0 value.
set tielopin_out = "logic0_pin_name"
The name of the output pin of the logic 0 cell.
set fillcell = "fill_cell_name"
The name of the cell to use as a fill cell. This may be a decap cell, or just an empty placeholder with power and ground rails. If there are multiple filler cells, specify the common part of the cell name.
set gndnet = "ground_net_name"
The preferred name of the standard cell ground net.
set vddnet = "power_net_name"
The preferred name of the standard cell power net.
set separator = "separator_string"
The character or characters that separate a cell name in the standard cell set from (usually) a number or string indicating the cell's drive strength. For example, if there are buffer cells "BUFX2", "BUFX4", etc., then the base cell name is "BUF" and the separator is "X". Occasionally standard cell sets don't use a separator character, in which case this is an empty string.
set bufcell = "buffer_cell_name"
The name of the cell to use for buffering fanout trees. Standard cell sets often have normal, balanced, and/or clock buffers. Usually a clock buffer will be most appropriate here.
Some additional, similar variables are related to earlier versions of qflow and are no longer needed. These include the pin names to cells (qflow will now look them up in the liberty format file), nand, nor, invert, and flip-flop cell names (not needed).

The last group is a list of default values that will be copied into the appropriate variables in the project_vars.sh file in the project. Any variable that shows up in project_vars.sh (see "User Defined Options", above) may be given a default in the technology .sh file by adding "_default" to the end of the variable name. Most of the project_vars.sh variables are strictly for the user to choose appropriately for each project. Sometimes, however, there are preferred definitions that are technology-dependent or site-dependent. The most likely variables to need such defaults in the technology .sh file are listed below.

set fanout_options_default = "default_string"
Best for setting the "-l" and "-c" options for typical load and latency. This is usually process-feature-size dependent.
set via_use_default = "default_string"
Best for limiting which vias to allow qrouter to use for routing the design.
set via_stacks_default = "default_string"
For technologies requiring a minimum metal area that is larger than a single contact, the via stacks need to be limited to 2 to prevent minimum area violations.
set route_layers_default = "default_string"
A typical site definition may be not to use the top layer of metal for routing but reserve it for the power supply.
set vesta_options_default = "default_string"
A typical site definition may be to specify the long format.
.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.


liberty2tech liberty_file genlib_file gate_cfg_file [pattern]
is the name of the Liberty format file
is the name of the output genlib file
should be "gate.cfg" (output file)
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
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.


Last updated: September 18, 2017 at 10:37pm