Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Things To Do
Version 1.4 is the development version of Qflow as of December 24, 2018. The first committed version (1.4.0) makes extensive changes in removing the dependence of all tools on the BLIF format, instead opting for keeping standard formats, which generally means using verilog netlists in place of BLIF.The major goal of version 1.4 is to slowly integrate all of the tools from abk-openroad on github, with a push to ensure that all the abk-openroad tools are purely open-source and not dependent on closed-source and/or commercial components.
A parallel goal is to make qflow more compartmentalized so that it is much easier to swap alternative tools in and out, with the introduction of alternative scripts for each tool.
Version 1.3 is the stable version of Qflow as of December 24, 2018. This is a copy of the last development version 1.2, and reflects the new system of updating both development and stable version numbers at once, so that the same version number does not get used for both a development version and (later) a stable version. There are no changes between version 1.2.93 and 1.3.0.
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.
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.
Updates in June 2017 finally added the ability to create power stripes through the circuit with new functionality coded into the "addspacers" script. The tutorial has been updated to reflect the new method, simplifying the flow by no longer requiring any manual layout steps between synthesis and verification. Another script was developed to convert SPICE output to an equivalent XSPICE model using my d_lut and d_genlut extensions to XSPICE, now in the ngspice repository.
Additional updates have been made to netgen, for better LVS, to magic, for better extraction, and to qrouter, for better routing.
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.
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: 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. 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).
| email: | 
|
Last updated: February 20, 2019 at 8:43pm