Qflow 1.1

Table of Contents

Release Notes
Release Notes
Release Notes
Things To Do

Release Notes for Qflow version 1.2:

Version 1.2 is the develpment version of Qflow as of April 25, 2017. Immediate anticipated development pushes are to handle hard macros and automatic power bus generation.

Release Notes for Qflow version 1.1:

Version 1.1 was made the stable version on April 25, 2017, having been used successfully in a number of projects and being far more capable than the original version 1.0.

Version 1.1 became the development version of Qflow on November 16, 2015, as the original version 1.0 had been used successfully on several projects and can be considered stable, if not perfect.

The initial check-in of version 1.1 includes a new method for placing and optimizing clock and buffer trees, which operates in one placement pass instead of two, and gives far superior results.

It requires a code update in graywolf, which was applied to the graywolf git database on May 25, 2015. Once this version has been vetted on several projects, it will be declared stable, due to the major improvements over version 1.0.

Release Notes for Qflow version 1.0:

Version 1.0 is the first packaged version of the open-source digital flow. Previously, this flow was posted on the Open Circuit Design website as a loose collection of scripts, with some vague instructions as to how they all fit together. Qflow is a packaged version of the scripts, reorganized with the following goals:
  • All the technology-independent scripts and programs are be organized in one place, and not copied for every project.
  • All the technology-dependent files are organized under a single tech directory, with the technology specified on the command-line, or even pulled from a file in the layout directory. All scripts have been made technology-independent.
  • Various working directories can be reassigned by setting environment variables.
  • The primary flow creates two files, one containing variables related to the technology and project that is sourced by each tool as needed, and one file that is a command file of the principal commands used in the flow. The flow proceeds by uncommenting one or more commands in this file, and then executing the file. This also makes it easier to start the flow from any point, or to stop at any point to modify files used by the next tool in the flow.
  • The C source code files are compiled under a standard "make" process.
  • The compile and install process are put under gnu autoconf.
  • The location of external programs (qrouter, graywolf, yosys) are searched for by autoconf, or passed as arguments to the configure script. The configure script flags a warning for each tool that cannot be found.
  • Qflow handles connections to VDD/VSS throughout, using tielo/tiehi cells, preferably, but forming direct connections to VDD/VSS if necessary. Note that this is a separate item from the handling of power routing.
  • Multiple modules in the source code are handled. Odin-II makes no distinction between signal names in different modules in the same file; yosys has no such limitations.
  • Instances (subcircuits) in the verilog source are handled by yosys and Odin-II. For yosys, yosys's "hierarcy -check" option is used to build up a list of dependencies. For Odin-II, the preprocessor creates dependency files that it uses to generate a list of files that are the input to Odin-II.
  • Yosys handles all include files and conditionals. Yosys provides all errors and warnings about syntax and other issues in the verilog source code. For Odin-II, include files from the verilog source are handled by the preprocessor, and not passed on to Odin-II. This ensures that definitions in the included file are known and interpreted, and it helps with the error message output from Odin-II, which reports line numbers as if the include file were expanded into the source. The Odin-II line numbers will correspond to the pre-processed "_tmp.v" file that is its input. Unfortunately, when working with multiple files, Odin-II does not report which source file the error number is referenced to.
  • To-Do List for Qflow version 1.0:

  • Handle generation of the .par file automatically and move many of the user options into the "project_vars.sh" file, or wholesale in a ".par2" file to be provided by the user.
  • Should have a method (maybe with a GUI) to specify how pins are to be placed, as opposed to the existing ".cel2" file, which depends on graywolf syntax and is awkward.
  • It should be possible to specify a shaped area to use as the placement target. Again, this is stuff that goes into graywolf and described in the GrayWolf/TimberWolf documentation. But it is inconvenient, has never been tried, and may or may not actually work correctly with the existing flow.
  • Long-term project to leave room in the synthesis stage for power routing, then do the power routing across tracks. This is potentially fairly simple to do with 4-layer routing, because layer 4 can run vertically from top to bottom without directly interfering with any pin positions, and taps can be brought down to the power buses.
  • Another long-term and major project is to obtain or write static timing analysis tool, and apply the static timing analysis results to select fanout and loads, etc., as needed to hit a specific clock frequency target.

    (Update, late 2013: I have written the tool vesta which reads a liberty-format file and generates a list of maximum- and minimum-latency paths. It will eventually replace the blifFanout tool, as it can check fanout against the liberty file parameters, and optimize critical path timing instead of the broad approach of balancing timing on all paths used by blifFanout.
  • A general goal is to convert and handle all files in standard formats: mainly RTL verilog, LEF, and DEF. The technology file formats used by ABC (.genlib) and BDnetFanout (.cfg) are non-standard, but have been handled by a converter "liberty2tech" that automatically generates them from a standard (Liberty format) timing file. The ".par" format (Graywolf) and ".prm" format (IRSIM) should likewise be automatically generated.

    (Update, October 2013: The use of bdnet files has been completely removed from the synthesis flow, and genlib files are not used by the yosys flow, except where they are created automatically by yosys. The blifFanout tool still uses the "gate.cfg" file generated by liberty2tech; this will be eliminated when vesta replaces blifFanout.)
  • All configuration information is (slowly) being consolidated into a single file called "project_vars.sh" that calls out each tool or tools for which the configuration information applies, much like Graywolf does, except extended to include the other tools in qflow. Mainly, this is for arguments passed to each tool in the flow. It allows an easier setup for defining project-specific actions to be taken. Principal user modifications are:
  • Synthesis: Select whether inputs, outputs, or both should be buffered. Standard should be to buffer both, to avoid problems with unknown input and output loads.
  • Synthesis: Select output drive strength for buffered outputs.
  • Synthesis: Select maximum allowed fanout (done).
  • Placement: Various options to make rows back-to-back or in the same orientation, put extra space between rows.
  • Routing: Options for config file, such as choosing the number of route layers (done).
    In the end, there may be as many as four configuration files: The "project_vars.sh" file mentioned above, the ".cel2" file that gets appended to ".cel" and contains pin location hints; a ".cfg2" file for qrouter that can contain additional information about user-defined obstructions; and a ".par2" file with additional input for Graywolf.
  • email:

    Last updated: April 25, 2017 at 9:36am