diff options
author | Peter Gadfort <peter.gadfort@gmail.com> | 2023-01-02 12:46:41 -0500 |
---|---|---|
committer | Peter Gadfort <peter.gadfort@gmail.com> | 2023-01-02 12:46:41 -0500 |
commit | 7971154e727cc4d7c4b8c62ad43a28645bb66795 (patch) | |
tree | ea4632f116b272bc15940cc59f45a73eef008566 | |
parent | 58cca9592d64178a097c6345a576b1df022cd50c (diff) | |
parent | 583ab81670847bc0084708bab04c64cb43bc3a51 (diff) | |
download | yosys-7971154e727cc4d7c4b8c62ad43a28645bb66795.tar.gz yosys-7971154e727cc4d7c4b8c62ad43a28645bb66795.tar.bz2 yosys-7971154e727cc4d7c4b8c62ad43a28645bb66795.zip |
Merge branch 'master' into stat-json-area
89 files changed, 11 insertions, 20297 deletions
diff --git a/.github/workflows/emcc.yml b/.github/workflows/emcc.yml index 7a9a6064f..295d9554b 100644 --- a/.github/workflows/emcc.yml +++ b/.github/workflows/emcc.yml @@ -8,12 +8,6 @@ jobs: steps: - uses: mymindstorm/setup-emsdk@v11 - uses: actions/checkout@v3 - - name: Cache sources - id: cache-sources - uses: actions/cache@v3 - with: - path: . - key: cache-yosys - name: Build run: | make config-emcc diff --git a/.github/workflows/vs.yml b/.github/workflows/vs.yml index 744ad5677..428770e72 100644 --- a/.github/workflows/vs.yml +++ b/.github/workflows/vs.yml @@ -7,12 +7,6 @@ jobs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - - name: Cache sources - id: cache-sources - uses: actions/cache@v3 - with: - path: . - key: cache-yosys - name: Build run: make vcxsrc YOSYS_VER=latest - uses: actions/upload-artifact@v3 @@ -976,18 +976,9 @@ DOC_TARGET ?= html docs: docs/source/cmd/abc.rst docs/gen_images docs/guidelines $(Q) $(MAKE) -C docs $(DOC_TARGET) -update-manual: $(TARGETS) $(EXTRA_TARGETS) - cd manual && ../$(PROGRAM_PREFIX)yosys -p 'help -write-tex-command-reference-manual' - -manual: $(TARGETS) $(EXTRA_TARGETS) - cd manual && bash appnotes.sh - cd manual && bash presentation.sh - cd manual && bash manual.sh - clean: rm -rf share rm -rf kernel/*.pyh - if test -d manual; then cd manual && sh clean.sh; fi rm -f $(OBJS) $(GENFILES) $(TARGETS) $(EXTRA_TARGETS) $(EXTRA_OBJS) $(PY_WRAP_INCLUDES) $(PY_WRAPPER_FILE).cc rm -f kernel/version_*.o kernel/version_*.cc rm -f libs/*/*.d frontends/*/*.d passes/*/*.d backends/*/*.d kernel/*.d techlibs/*/*.d @@ -1127,5 +1118,5 @@ echo-abc-rev: -include kernel/*.d -include techlibs/*/*.d -.PHONY: all top-all abc test install install-abc docs manual clean mrproper qtcreator coverage vcxsrc mxebin +.PHONY: all top-all abc test install install-abc docs clean mrproper qtcreator coverage vcxsrc mxebin .PHONY: config-clean config-clang config-gcc config-gcc-static config-gcc-4.8 config-afl-gcc config-gprof config-sudo @@ -596,43 +596,10 @@ Building the documentation ========================== Note that there is no need to build the manual if you just want to read it. -Simply download the PDF from https://yosyshq.net/yosys/documentation.html -instead. +Simply visit https://yosys.readthedocs.io/en/latest/ instead. -On Ubuntu, texlive needs these packages to be able to build the manual: - - sudo apt-get install texlive-binaries - sudo apt-get install texlive-science # install algorithm2e.sty - sudo apt-get install texlive-bibtex-extra # gets multibib.sty - sudo apt-get install texlive-fonts-extra # gets skull.sty and dsfont.sty - sudo apt-get install texlive-publishers # IEEEtran.cls - -Also the non-free font luximono should be installed, there is unfortunately -no Ubuntu package for this so it should be installed separately using -`getnonfreefonts`: - - wget https://tug.org/fonts/getnonfreefonts/install-getnonfreefonts - sudo texlua install-getnonfreefonts # will install to /usr/local by default, can be changed by editing BINDIR at MANDIR at the top of the script - getnonfreefonts luximono # installs to /home/user/texmf - -Then execute, from the root of the repository: - - make manual - -Notes: - -- To run `make manual` you need to have installed Yosys with `make install`, - otherwise it will fail on finding `kernel/yosys.h` while building - `PRESENTATION_Prog`. - -Building the website -==================== - -If you're seeing this, it means you are on an as yet unmerged branch (I hope), -and the website version of the documentation is not yet publicly available. - -In addition to those listed above for building Yosys from source, the following -packages are used for building the website: +In addition to those packages listed above for building Yosys from source, the +following are used for building the website: $ sudo apt-get install pdf2svg faketime diff --git a/guidelines/Checklists b/guidelines/Checklists index cc61c7876..51756cfd7 100644 --- a/guidelines/Checklists +++ b/guidelines/Checklists @@ -11,7 +11,7 @@ Things to do right away: Things to do after finalizing the cell interface: - Add support to kernel/satgen.h for the new cell type - - Add to manual/CHAPTER_CellLib.tex (or just add a fixme to the bottom) + - Add to docs/source/CHAPTER_CellLib.rst (or just add a fixme to the bottom) - Maybe add support to the Verilog backend for dumping such cells as expression @@ -29,11 +29,9 @@ Update the CHANGELOG file: Update and check documentation: cd ~yosys - make update-manual - make manual - - sanity check the figures in the appnotes and presentation + make docs + - sanity check the figures in docs/images - if there are any odd things -> investigate - - make cosmetic changes to the .tex files if necessary cd ~yosys vi README guidelines/* @@ -108,13 +106,11 @@ Release: Updating the website: cd ~yosys - make manual make install - - update pdf files on the website - cd ~yosys-web - make update_cmd make update_show git commit -am update make push + + - Read the Docs updates handled by Jenkins on source change diff --git a/guidelines/GettingStarted b/guidelines/GettingStarted index fcc84c153..d27b285fc 100644 --- a/guidelines/GettingStarted +++ b/guidelines/GettingStarted @@ -191,7 +191,7 @@ Example Code The following yosys commands are a good starting point if you are looking for examples of how to use the Yosys API: - manual/CHAPTER_Prog/stubnets.cc + docs/source/CHAPTER_Prog/stubnets.cc manual/PRESENTATION_Prog/my_cmd.cc diff --git a/kernel/driver.cc b/kernel/driver.cc index a89c790d9..ef8e77924 100644 --- a/kernel/driver.cc +++ b/kernel/driver.cc @@ -297,7 +297,7 @@ int main(int argc, char **argv) #endif printf("\n"); printf(" -p command\n"); - printf(" execute the commands\n"); + printf(" execute the commands (to chain commands, separate them with semicolon + whitespace: 'cmd1; cmd2')\n"); printf("\n"); printf(" -m module_file\n"); printf(" load the specified module (aka plugin)\n"); diff --git a/kernel/register.cc b/kernel/register.cc index 9449890b1..ab391b10d 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -765,63 +765,6 @@ struct HelpPass : public Pass { log(" help <celltype>+ .... print verilog code for given cell type\n"); log("\n"); } - void escape_tex(std::string &tex) - { - for (size_t pos = 0; (pos = tex.find('_', pos)) != std::string::npos; pos += 2) - tex.replace(pos, 1, "\\_"); - for (size_t pos = 0; (pos = tex.find('$', pos)) != std::string::npos; pos += 2) - tex.replace(pos, 1, "\\$"); - } - void write_tex(FILE *f, std::string cmd, std::string title, std::string text) - { - size_t begin = text.find_first_not_of("\n"), end = text.find_last_not_of("\n"); - if (begin != std::string::npos && end != std::string::npos && begin < end) - text = text.substr(begin, end-begin+1); - std::string cmd_unescaped = cmd; - escape_tex(cmd); - escape_tex(title); - fprintf(f, "\\section{%s -- %s}\n", cmd.c_str(), title.c_str()); - fprintf(f, "\\label{cmd:%s}\n", cmd_unescaped.c_str()); - fprintf(f, "\\begin{lstlisting}[numbers=left,frame=single]\n"); - fprintf(f, "%s\n\\end{lstlisting}\n\n", text.c_str()); - } - void escape_html(std::string &html) - { - size_t pos = 0; - while ((pos = html.find_first_of("<>&", pos)) != std::string::npos) - switch (html[pos]) { - case '<': - html.replace(pos, 1, "<"); - pos += 4; - break; - case '>': - html.replace(pos, 1, ">"); - pos += 4; - break; - case '&': - html.replace(pos, 1, "&"); - pos += 5; - break; - } - } - void write_html(FILE *idxf, std::string cmd, std::string title, std::string text) - { - FILE *f = fopen(stringf("cmd_%s.in", cmd.c_str()).c_str(), "wt"); - fprintf(idxf, "<li><a href=\"cmd_%s.html\"> ", cmd.c_str()); - - escape_html(cmd); - escape_html(title); - escape_html(text); - - fprintf(idxf, "%s</a> <span>%s</span></a>\n", cmd.c_str(), title.c_str()); - - fprintf(f, "@cmd_header %s@\n", cmd.c_str()); - fprintf(f, "<h1>%s - %s</h1>\n", cmd.c_str(), title.c_str()); - fprintf(f, "<pre>%s</pre>\n", text.c_str()); - fprintf(f, "@footer@\n"); - - fclose(f); - } void write_rst(std::string cmd, std::string title, std::string text) { FILE *f = fopen(stringf("docs/source/cmd/%s.rst", cmd.c_str()).c_str(), "wt"); @@ -958,24 +901,6 @@ struct HelpPass : public Pass { return; } // this option is undocumented as it is for internal use only - else if (args[1] == "-write-tex-command-reference-manual") { - FILE *f = fopen("command-reference-manual.tex", "wt"); - fprintf(f, "%% Generated using the yosys 'help -write-tex-command-reference-manual' command.\n\n"); - for (auto &it : pass_register) { - std::ostringstream buf; - log_streams.push_back(&buf); - it.second->help(); - if (it.second->experimental_flag) { - log("\n"); - log("WARNING: THE '%s' COMMAND IS EXPERIMENTAL.\n", it.first.c_str()); - log("\n"); - } - log_streams.pop_back(); - write_tex(f, it.first, it.second->short_help, buf.str()); - } - fclose(f); - } - // this option is undocumented as it is for internal use only else if (args[1] == "-write-rst-command-reference-manual") { for (auto &it : pass_register) { std::ostringstream buf; @@ -990,23 +915,6 @@ struct HelpPass : public Pass { write_rst(it.first, it.second->short_help, buf.str()); } } - // this option is undocumented as it is for internal use only - else if (args[1] == "-write-web-command-reference-manual") { - FILE *f = fopen("templates/cmd_index.in", "wt"); - for (auto &it : pass_register) { - std::ostringstream buf; - log_streams.push_back(&buf); - it.second->help(); - if (it.second->experimental_flag) { - log("\n"); - log("WARNING: THE '%s' COMMAND IS EXPERIMENTAL.\n", it.first.c_str()); - log("\n"); - } - log_streams.pop_back(); - write_html(f, it.first, it.second->short_help, buf.str()); - } - fclose(f); - } else if (pass_register.count(args[1])) { pass_register.at(args[1])->help(); if (pass_register.at(args[1])->experimental_flag) { diff --git a/manual/APPNOTE_010_Verilog_to_BLIF.tex b/manual/APPNOTE_010_Verilog_to_BLIF.tex deleted file mode 100644 index 16254d593..000000000 --- a/manual/APPNOTE_010_Verilog_to_BLIF.tex +++ /dev/null @@ -1,466 +0,0 @@ - -% IEEEtran howto: -% http://ftp.univie.ac.at/packages/tex/macros/latex/contrib/IEEEtran/IEEEtran_HOWTO.pdf -\documentclass[9pt,technote,a4paper]{IEEEtran} - -\usepackage[T1]{fontenc} % required for luximono! -\usepackage[scaled=0.8]{luximono} % typewriter font with bold face - -% To install the luximono font files: -% getnonfreefonts-sys --all or -% getnonfreefonts-sys luximono -% -% when there are trouble you might need to: -% - Create /etc/texmf/updmap.d/99local-luximono.cfg -% containing the single line: Map ul9.map -% - Run update-updmap followed by mktexlsr and updmap-sys -% -% This commands must be executed as root with a root environment -% (i.e. run "sudo su" and then execute the commands in the root -% shell, don't just prefix the commands with "sudo"). - -\usepackage[unicode,bookmarks=false]{hyperref} -\usepackage[english]{babel} -\usepackage[utf8]{inputenc} -\usepackage{amssymb} -\usepackage{amsmath} -\usepackage{amsfonts} -\usepackage{units} -\usepackage{nicefrac} -\usepackage{eurosym} -\usepackage{graphicx} -\usepackage{verbatim} -\usepackage{algpseudocode} -\usepackage{scalefnt} -\usepackage{xspace} -\usepackage{color} -\usepackage{colortbl} -\usepackage{multirow} -\usepackage{hhline} -\usepackage{listings} -\usepackage{float} - -\usepackage{tikz} -\usetikzlibrary{calc} -\usetikzlibrary{arrows} -\usetikzlibrary{scopes} -\usetikzlibrary{through} -\usetikzlibrary{shapes.geometric} - -\lstset{basicstyle=\ttfamily,frame=trBL,xleftmargin=2em,xrightmargin=1em,numbers=left} - -\begin{document} - -\title{Yosys Application Note 010: \\ Converting Verilog to BLIF} -\author{Claire Xenia Wolf \\ November 2013} -\maketitle - -\begin{abstract} -Verilog-2005 is a powerful Hardware Description Language (HDL) that can be used -to easily create complex designs from small HDL code. It is the preferred -method of design entry for many designers\footnote{The other half prefers VHDL, -a very different but -- of course -- equally powerful language.}. - -The Berkeley Logic Interchange Format (BLIF) \cite{blif} is a simple file format for -exchanging sequential logic between programs. It is easy to generate and -easy to parse and is therefore the preferred method of design entry for -many authors of logic synthesis tools. - -Yosys \cite{yosys} is a feature-rich -Open-Source Verilog synthesis tool that can be used to bridge the gap between -the two file formats. It implements most of Verilog-2005 and thus can be used -to import modern behavioral Verilog designs into BLIF-based design flows -without dependencies on proprietary synthesis tools. - -The scope of Yosys goes of course far beyond Verilog logic synthesis. But -it is a useful and important feature and this Application Note will focus -on this aspect of Yosys. -\end{abstract} - -\section{Installation} - -Yosys written in C++ (using features from C++11) and is tested on modern Linux. -It should compile fine on most UNIX systems with a C++11 compiler. The README -file contains useful information on building Yosys and its prerequisites. - -Yosys is a large and feature-rich program with a couple of dependencies. It is, -however, possible to deactivate some of the dependencies in the Makefile, -resulting in features in Yosys becoming unavailable. When problems with building -Yosys are encountered, a user who is only interested in the features of Yosys -that are discussed in this Application Note may deactivate {\tt TCL}, {\tt Qt} -and {\tt MiniSAT} support in the {\tt Makefile} and may opt against building -{\tt yosys-abc}. - -\bigskip - -This Application Note is based on GIT Rev. {\tt e216e0e} from 2013-11-23 of -Yosys \cite{yosys}. The Verilog sources used for the examples are taken from -yosys-bigsim \cite{bigsim}, a collection of real-world designs used for -regression testing Yosys. - -\section{Getting Started} - -We start our tour with the Navr\'e processor from yosys-bigsim. The Navr\'e -processor \cite{navre} is an Open Source AVR clone. It is a single module ({\tt -softusb\_navre}) in a single design file ({\tt softusb\_navre.v}). It also is -using only features that map nicely to the BLIF format, for example it only -uses synchronous resets. - -Converting {\tt softusb\_navre.v} to {\tt softusb\_navre.blif} could not be -easier: - -\begin{figure}[H] -\begin{lstlisting}[language=sh] -yosys -o softusb_navre.blif -S softusb_navre.v -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{Calling Yosys without script file} -\end{figure} - -Behind the scenes Yosys is controlled by synthesis scripts that execute -commands that operate on Yosys' internal state. For example, the {\tt -o -softusb\_navre.blif} option just adds the command {\tt write\_blif -softusb\_navre.blif} to the end of the script. Likewise a file on the -command line -- {\tt softusb\_navre.v} in this case -- adds the command -{\tt read\_verilog softusb\_navre.v} to the beginning of the -synthesis script. In both cases the file type is detected from the -file extension. - -Finally the option {\tt -S} instantiates a built-in default synthesis script. -Instead of using {\tt -S} one could also specify the synthesis commands -for the script on the command line using the {\tt -p} option, either using -individual options for each command or by passing one big command string -with a semicolon-separated list of commands. But in most cases it is more -convenient to use an actual script file. - -\section{Using a Synthesis Script} - -With a script file we have better control over Yosys. The following script -file replicates what the command from the last section did: - -\begin{figure}[H] -\begin{lstlisting}[language=sh] -read_verilog softusb_navre.v -hierarchy -proc; opt; memory; opt; techmap; opt -write_blif softusb_navre.blif -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{\tt softusb\_navre.ys} -\end{figure} - -The first and last line obviously read the Verilog file and write the BLIF -file. - -\medskip - -The 2nd line checks the design hierarchy and instantiates parametrized -versions of the modules in the design, if necessary. In the case of this -simple design this is a no-op. However, as a general rule a synthesis script -should always contain this command as first command after reading the input -files. - -\medskip - -The 3rd line does most of the actual work: - -\begin{itemize} -\item The command {\tt opt} is the Yosys' built-in optimizer. It can perform -some simple optimizations such as const-folding and removing unconnected parts -of the design. It is common practice to call opt after each major step in the -synthesis procedure. In cases where too much optimization is not appreciated -(for example when analyzing a design), it is recommended to call {\tt clean} -instead of {\tt opt}. -\item The command {\tt proc} converts {\it processes} (Yosys' internal -representation of Verilog {\tt always}- and {\tt initial}-blocks) to circuits -of multiplexers and storage elements (various types of flip-flops). -\item The command {\tt memory} converts Yosys' internal representations of -arrays and array accesses to multi-port block memories, and then maps this -block memories to address decoders and flip-flops, unless the option {\tt -nomap} -is used, in which case the multi-port block memories stay in the design -and can then be mapped to architecture-specific memory primitives using -other commands. -\item The command {\tt techmap} turns a high-level circuit with coarse grain -cells such as wide adders and multipliers to a fine-grain circuit of simple -logic primitives and single-bit storage elements. The command does that by -substituting the complex cells by circuits of simpler cells. It is possible -to provide a custom set of rules for this process in the form of a Verilog -source file, as we will see in the next section. -\end{itemize} - -Now Yosys can be run with the filename of the synthesis script as argument: - -\begin{figure}[H] -\begin{lstlisting}[language=sh] -yosys softusb_navre.ys -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{Calling Yosys with script file} -\end{figure} - -\medskip - -Now that we are using a synthesis script we can easily modify how Yosys -synthesizes the design. The first thing we should customize is the -call to the {\tt hierarchy} command: - -Whenever it is known that there are no implicit blackboxes in the design, i.e. -modules that are referenced but are not defined, the {\tt hierarchy} command -should be called with the {\tt -check} option. This will then cause synthesis -to fail when implicit blackboxes are found in the design. - -The 2nd thing we can improve regarding the {\tt hierarchy} command is that we -can tell it the name of the top level module of the design hierarchy. It will -then automatically remove all modules that are not referenced from this top -level module. - -\medskip - -For many designs it is also desired to optimize the encodings for the finite -state machines (FSMs) in the design. The {\tt fsm} command finds FSMs, extracts -them, performs some basic optimizations and then generate a circuit from -the extracted and optimized description. It would also be possible to tell -the {\tt fsm} command to leave the FSMs in their extracted form, so they can be -further processed using custom commands. But in this case we don't want that. - -\medskip - -So now we have the final synthesis script for generating a BLIF file -for the Navr\'e CPU: - -\begin{figure}[H] -\begin{lstlisting}[language=sh] -read_verilog softusb_navre.v -hierarchy -check -top softusb_navre -proc; opt; memory; opt; fsm; opt; techmap; opt -write_blif softusb_navre.blif -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{{\tt softusb\_navre.ys} (improved)} -\end{figure} - -\section{Advanced Example: The Amber23 ARMv2a CPU} - -Our 2nd example is the Amber23 \cite{amber} -ARMv2a CPU. Once again we base our example on the Verilog code that is included -in yosys-bigsim \cite{bigsim}. - -\begin{figure}[b!] -\begin{lstlisting}[language=sh] -read_verilog a23_alu.v -read_verilog a23_barrel_shift_fpga.v -read_verilog a23_barrel_shift.v -read_verilog a23_cache.v -read_verilog a23_coprocessor.v -read_verilog a23_core.v -read_verilog a23_decode.v -read_verilog a23_execute.v -read_verilog a23_fetch.v -read_verilog a23_multiply.v -read_verilog a23_ram_register_bank.v -read_verilog a23_register_bank.v -read_verilog a23_wishbone.v -read_verilog generic_sram_byte_en.v -read_verilog generic_sram_line_en.v -hierarchy -check -top a23_core -add -global_input globrst 1 -proc -global_arst globrst -techmap -map adff2dff.v -opt; memory; opt; fsm; opt; techmap -write_blif amber23.blif -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{\tt amber23.ys} -\label{aber23.ys} -\end{figure} - -The problem with this core is that it contains no dedicated reset logic. -Instead the coding techniques shown in Listing~\ref{glob_arst} are used to -define reset values for the global asynchronous reset in an FPGA -implementation. This design can not be expressed in BLIF as it is. Instead we -need to use a synthesis script that transforms this form to synchronous resets that -can be expressed in BLIF. - -(Note that there is no problem if this coding techniques are used to model -ROM, where the register is initialized using this syntax but is never updated -otherwise.) - -\medskip - -Listing~\ref{aber23.ys} shows the synthesis script for the Amber23 core. In -line 17 the {\tt add} command is used to add a 1-bit wide global input signal -with the name {\tt globrst}. That means that an input with that name is added -to each module in the design hierarchy and then all module instantiations are -altered so that this new signal is connected throughout the whole design -hierarchy. - -\begin{figure}[t!] -\begin{lstlisting}[language=Verilog] -reg [7:0] a = 13, b; -initial b = 37; -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{Implicit coding of global asynchronous resets} -\label{glob_arst} -\end{figure} - -\begin{figure}[b!] -\begin{lstlisting}[language=Verilog] -(* techmap_celltype = "$adff" *) -module adff2dff (CLK, ARST, D, Q); - -parameter WIDTH = 1; -parameter CLK_POLARITY = 1; -parameter ARST_POLARITY = 1; -parameter ARST_VALUE = 0; - -input CLK, ARST; -input [WIDTH-1:0] D; -output reg [WIDTH-1:0] Q; - -wire [1023:0] _TECHMAP_DO_ = "proc"; - -wire _TECHMAP_FAIL_ = - !CLK_POLARITY || !ARST_POLARITY; - -always @(posedge CLK) - if (ARST) - Q <= ARST_VALUE; - else - Q <= D; - -endmodule -\end{lstlisting} -\renewcommand{\figurename}{Listing} -\caption{\tt adff2dff.v} -\label{adff2dff.v} -\end{figure} - -In line 18 the {\tt proc} command is called. But in this script the signal name -{\tt globrst} is passed to the command as a global reset signal for resetting -the registers to their assigned initial values. - -Finally in line 19 the {\tt techmap} command is used to replace all instances -of flip-flops with asynchronous resets with flip-flops with synchronous resets. -The map file used for this is shown in Listing~\ref{adff2dff.v}. Note how the -{\tt techmap\_celltype} attribute is used in line 1 to tell the techmap command -which cells to replace in the design, how the {\tt \_TECHMAP\_FAIL\_} wire in -lines 15 and 16 (which evaluates to a constant value) determines if the -parameter set is compatible with this replacement circuit, and how the {\tt -\_TECHMAP\_DO\_} wire in line 13 provides a mini synthesis-script to be used to -process this cell. - -\begin{figure*} -\begin{lstlisting}[language=C] -#include <stdint.h> -#include <stdbool.h> - -#define BITMAP_SIZE 64 -#define OUTPORT 0x10000000 - -static uint32_t bitmap[BITMAP_SIZE/32]; - -static void bitmap_set(uint32_t idx) { bitmap[idx/32] |= 1 << (idx % 32); } -static bool bitmap_get(uint32_t idx) { return (bitmap[idx/32] & (1 << (idx % 32))) != 0; } -static void output(uint32_t val) { *((volatile uint32_t*)OUTPORT) = val; } - -int main() { - uint32_t i, j, k; - output(2); - for (i = 0; i < BITMAP_SIZE; i++) { - if (bitmap_get(i)) continue; - output(3+2*i); - for (j = 2*(3+2*i);; j += 3+2*i) { - if (j%2 == 0) continue; - k = (j-3)/2; - if (k >= BITMAP_SIZE) break; - bitmap_set(k); - } - } - output(0); - return 0; -} -\end{lstlisting} -\renewcommand{\figurename}{Listing} -\caption{Test program for the Amber23 CPU (Sieve of Eratosthenes). Compiled using -GCC 4.6.3 for ARM with {\tt -Os -marm -march=armv2a -mno-thumb-interwork --ffreestanding}, linked with {\tt -{}-fix-v4bx} set and booted with a custom -setup routine written in ARM assembler.} -\label{sieve} -\end{figure*} - -\section{Verification of the Amber23 CPU} - -The BLIF file for the Amber23 core, generated using Listings~\ref{aber23.ys} -and \ref{adff2dff.v} and the version of the Amber23 RTL source that is bundled -with yosys-bigsim, was verified using the test-bench from yosys-bigsim. -It successfully executed the program shown in Listing~\ref{sieve} in the -test-bench. - -For simulation the BLIF file was converted back to Verilog using ABC -\cite{ABC}. So this test includes the successful transformation of the BLIF -file into ABC's internal format as well. - -The only thing left to write about the simulation itself is that it probably -was one of the most energy inefficient and time consuming ways of successfully -calculating the first 31 primes the author has ever conducted. - -\section{Limitations} - -At the time of this writing Yosys does not support multi-dimensional memories, -does not support writing to individual bits of array elements, does not -support initialization of arrays with {\tt \$readmemb} and {\tt \$readmemh}, -and has only limited support for tristate logic, to name just a few -limitations. - -That being said, Yosys can synthesize an overwhelming majority of real-world -Verilog RTL code. The remaining cases can usually be modified to be compatible -with Yosys quite easily. - -The various designs in yosys-bigsim are a good place to look for examples -of what is within the capabilities of Yosys. - -\section{Conclusion} - -Yosys is a feature-rich Verilog-2005 synthesis tool. It has many uses, but -one is to provide an easy gateway from high-level Verilog code to low-level -logic circuits. - -The command line option {\tt -S} can be used to quickly synthesize Verilog -code to BLIF files without a hassle. - -With custom synthesis scripts it becomes possible to easily perform high-level -optimizations, such as re-encoding FSMs. In some extreme cases, such as the -Amber23 ARMv2 CPU, the more advanced Yosys features can be used to change a -design to fit a certain need without actually touching the RTL code. - -\begin{thebibliography}{9} - -\bibitem{yosys} -Claire Xenia Wolf. The Yosys Open SYnthesis Suite. \\ -\url{https://yosyshq.net/yosys/} - -\bibitem{bigsim} -yosys-bigsim, a collection of real-world Verilog designs for regression testing purposes. \\ -\url{https://github.com/YosysHQ/yosys-bigsim} - -\bibitem{navre} -Sebastien Bourdeauducq. Navr\'e AVR clone (8-bit RISC). \\ -\url{http://opencores.org/project,navre} - -\bibitem{amber} -Conor Santifort. Amber ARM-compatible core. \\ -\url{http://opencores.org/project,amber} - -\bibitem{ABC} -Berkeley Logic Synthesis and Verification Group. ABC: A System for Sequential Synthesis and Verification. \\ -\url{http://www.eecs.berkeley.edu/~alanmi/abc/} - -\bibitem{blif} -Berkeley Logic Interchange Format (BLIF) \\ -\url{http://vlsi.colorado.edu/~vis/blif.ps} - -\end{thebibliography} - - -\end{document} diff --git a/manual/APPNOTE_011_Design_Investigation.tex b/manual/APPNOTE_011_Design_Investigation.tex deleted file mode 100644 index 881212fe9..000000000 --- a/manual/APPNOTE_011_Design_Investigation.tex +++ /dev/null @@ -1,1070 +0,0 @@ - -% IEEEtran howto: -% http://ftp.univie.ac.at/packages/tex/macros/latex/contrib/IEEEtran/IEEEtran_HOWTO.pdf -\documentclass[9pt,technote,a4paper]{IEEEtran} - -\usepackage[T1]{fontenc} % required for luximono! -\usepackage[scaled=0.8]{luximono} % typewriter font with bold face - -% To install the luximono font files: -% getnonfreefonts-sys --all or -% getnonfreefonts-sys luximono -% -% when there are trouble you might need to: -% - Create /etc/texmf/updmap.d/99local-luximono.cfg -% containing the single line: Map ul9.map -% - Run update-updmap followed by mktexlsr and updmap-sys -% -% This commands must be executed as root with a root environment -% (i.e. run "sudo su" and then execute the commands in the root -% shell, don't just prefix the commands with "sudo"). - -\usepackage[unicode,bookmarks=false]{hyperref} -\usepackage[english]{babel} -\usepackage[utf8]{inputenc} -\usepackage{amssymb} -\usepackage{amsmath} -\usepackage{amsfonts} -\usepackage{units} -\usepackage{nicefrac} -\usepackage{eurosym} -\usepackage{graphicx} -\usepackage{verbatim} -\usepackage{algpseudocode} -\usepackage{scalefnt} -\usepackage{xspace} -\usepackage{color} -\usepackage{colortbl} -\usepackage{multirow} -\usepackage{hhline} -\usepackage{listings} -\usepackage{float} - -\usepackage{tikz} -\usetikzlibrary{calc} -\usetikzlibrary{arrows} -\usetikzlibrary{scopes} -\usetikzlibrary{through} -\usetikzlibrary{shapes.geometric} - -\def\FIXME{{\color{red}\bf FIXME}} - -\lstset{basicstyle=\ttfamily,frame=trBL,xleftmargin=0.7cm,xrightmargin=0.2cm,numbers=left} - -\begin{document} - -\title{Yosys Application Note 011: \\ Interactive Design Investigation} -\author{Claire Xenia Wolf \\ Original Version December 2013} -\maketitle - -\begin{abstract} -Yosys \cite{yosys} can be a great environment for building custom synthesis -flows. It can also be an excellent tool for teaching and learning Verilog based -RTL synthesis. In both applications it is of great importance to be able to -analyze the designs it produces easily. - -This Yosys application note covers the generation of circuit diagrams with the -Yosys {\tt show} command, the selection of interesting parts of the circuit -using the {\tt select} command, and briefly discusses advanced investigation -commands for evaluating circuits and solving SAT problems. -\end{abstract} - -\section{Installation and Prerequisites} - -This Application Note is based on the Yosys \cite{yosys} GIT Rev. {\tt 2b90ba1} from -2013-12-08. The {\tt README} file covers how to install Yosys. The -{\tt show} command requires a working installation of GraphViz \cite{graphviz} -and \cite{xdot} for generating the actual circuit diagrams. - -\section{Overview} - -This application note is structured as follows: - -Sec.~\ref{intro_show} introduces the {\tt show} command and explains the -symbols used in the circuit diagrams generated by it. - -Sec.~\ref{navigate} introduces additional commands used to navigate in the -design, select portions of the design, and print additional information on -the elements in the design that are not contained in the circuit diagrams. - -Sec.~\ref{poke} introduces commands to evaluate the design and solve SAT -problems within the design. - -Sec.~\ref{conclusion} concludes the document and summarizes the key points. - -\section{Introduction to the {\tt show} command} -\label{intro_show} - -\begin{figure}[b] -\begin{lstlisting} -$ cat example.ys -read_verilog example.v -show -pause -proc -show -pause -opt -show -pause - -$ cat example.v -module example(input clk, a, b, c, - output reg [1:0] y); - always @(posedge clk) - if (c) - y <= c ? a + b : 2'd0; -endmodule -\end{lstlisting} -\caption{Yosys script with {\tt show} commands and example design} -\label{example_src} -\end{figure} - -\begin{figure}[b!] -\includegraphics[width=\linewidth]{APPNOTE_011_Design_Investigation/example_00.pdf} -\includegraphics[width=\linewidth]{APPNOTE_011_Design_Investigation/example_01.pdf} -\includegraphics[width=\linewidth]{APPNOTE_011_Design_Investigation/example_02.pdf} -\caption{Output of the three {\tt show} commands from Fig.~\ref{example_src}} -\label{example_out} -\end{figure} - -The {\tt show} command generates a circuit diagram for the design in its -current state. Various options can be used to change the appearance of the -circuit diagram, set the name and format for the output file, and so forth. -When called without any special options, it saves the circuit diagram in -a temporary file and launches {\tt xdot} to display the diagram. -Subsequent calls to {\tt show} re-use the {\tt xdot} instance -(if still running). - -\subsection{A simple circuit} - -Fig.~\ref{example_src} shows a simple synthesis script and a Verilog file that -demonstrate the usage of {\tt show} in a simple setting. Note that {\tt show} -is called with the {\tt -pause} option, that halts execution of the Yosys -script until the user presses the Enter key. The {\tt show -pause} command -also allows the user to enter an interactive shell to further investigate the -circuit before continuing synthesis. - -So this script, when executed, will show the design after each of the three -synthesis commands. The generated circuit diagrams are shown in Fig.~\ref{example_out}. - -The first diagram (from top to bottom) shows the design directly after being -read by the Verilog front-end. Input and output ports are displayed as -octagonal shapes. Cells are displayed as rectangles with inputs on the left -and outputs on the right side. The cell labels are two lines long: The first line -contains a unique identifier for the cell and the second line contains the cell -type. Internal cell types are prefixed with a dollar sign. The Yosys manual -contains a chapter on the internal cell library used in Yosys. - -Constants are shown as ellipses with the constant value as label. The syntax -{\tt <bit\_width>'<bits>} is used for for constants that are not 32-bit wide -and/or contain bits that are not 0 or 1 (i.e. {\tt x} or {\tt z}). Ordinary -32-bit constants are written using decimal numbers. - -Single-bit signals are shown as thin arrows pointing from the driver to the -load. Signals that are multiple bits wide are shown as think arrows. - -Finally {\it processes\/} are shown in boxes with round corners. Processes -are Yosys' internal representation of the decision-trees and synchronization -events modelled in a Verilog {\tt always}-block. The label reads {\tt PROC} -followed by a unique identifier in the first line and contains the source code -location of the original {\tt always}-block in the 2nd line. Note how the -multiplexer from the {\tt ?:}-expression is represented as a {\tt \$mux} cell -but the multiplexer from the {\tt if}-statement is yet still hidden within the -process. - -\medskip - -The {\tt proc} command transforms the process from the first diagram into a -multiplexer and a d-type flip-flip, which brings us to the 2nd diagram. - -The Rhombus shape to the right is a dangling wire. (Wire nodes are only shown -if they are dangling or have ``public'' names, for example names assigned from -the Verilog input.) Also note that the design now contains two instances of a -{\tt BUF}-node. This are artefacts left behind by the {\tt proc}-command. It is -quite usual to see such artefacts after calling commands that perform changes -in the design, as most commands only care about doing the transformation in the -least complicated way, not about cleaning up after them. The next call to {\tt -clean} (or {\tt opt}, which includes {\tt clean} as one of its operations) will -clean up this artefacts. This operation is so common in Yosys scripts that it -can simply be abbreviated with the {\tt ;;} token, which doubles as -separator for commands. Unless one wants to specifically analyze this artefacts -left behind some operations, it is therefore recommended to always call {\tt clean} -before calling {\tt show}. - -\medskip - -In this script we directly call {\tt opt} as next step, which finally leads us to -the 3rd diagram in Fig.~\ref{example_out}. Here we see that the {\tt opt} command -not only has removed the artifacts left behind by {\tt proc}, but also determined -correctly that it can remove the first {\tt \$mux} cell without changing the behavior -of the circuit. - -\begin{figure}[b!] -\includegraphics[width=\linewidth,trim=0 2cm 0 0]{APPNOTE_011_Design_Investigation/splice.pdf} -\caption{Output of {\tt yosys -p 'proc; opt; show' splice.v}} -\label{splice_dia} -\end{figure} - -\begin{figure}[b!] -\lstinputlisting{APPNOTE_011_Design_Investigation/splice.v} -\caption{\tt splice.v} -\label{splice_src} -\end{figure} - -\begin{figure}[t!] -\includegraphics[height=\linewidth]{APPNOTE_011_Design_Investigation/cmos_00.pdf} -\includegraphics[width=\linewidth]{APPNOTE_011_Design_Investigation/cmos_01.pdf} -\caption{Effects of {\tt splitnets} command and of providing a cell library. (The -circuit is a half-adder built from simple CMOS gates.)} -\label{splitnets_libfile} -\end{figure} - -\subsection{Break-out boxes for signal vectors} - -As has been indicated by the last example, Yosys is can manage signal vectors (aka. -multi-bit wires or buses) as native objects. This provides great advantages -when analyzing circuits that operate on wide integers. But it also introduces -some additional complexity when the individual bits of of a signal vector -are accessed. The example show in Fig.~\ref{splice_dia} and \ref{splice_src} -demonstrates how such circuits are visualized by the {\tt show} command. - -The key elements in understanding this circuit diagram are of course the boxes -with round corners and rows labeled {\tt <MSB\_LEFT>:<LSB\_LEFT> -- <MSB\_RIGHT>:<LSB\_RIGHT>}. -Each of this boxes has one signal per row on one side and a common signal for all rows on the -other side. The {\tt <MSB>:<LSB>} tuples specify which bits of the signals are broken out -and connected. So the top row of the box connecting the signals {\tt a} and {\tt x} indicates -that the bit 0 (i.e. the range 0:0) from signal {\tt a} is connected to bit 1 (i.e. the range -1:1) of signal {\tt x}. - -Lines connecting such boxes together and lines connecting such boxes to cell -ports have a slightly different look to emphasise that they are not actual signal -wires but a necessity of the graphical representation. This distinction seems -like a technicality, until one wants to debug a problem related to the way -Yosys internally represents signal vectors, for example when writing custom -Yosys commands. - -\subsection{Gate level netlists} - -Finally Fig.~\ref{splitnets_libfile} shows two common pitfalls when working -with designs mapped to a cell library. The top figure has two problems: First -Yosys did not have access to the cell library when this diagram was generated, -resulting in all cell ports defaulting to being inputs. This is why all ports -are drawn on the left side the cells are awkwardly arranged in a large column. -Secondly the two-bit vector {\tt y} requires breakout-boxes for its individual -bits, resulting in an unnecessary complex diagram. - -For the 2nd diagram Yosys has been given a description of the cell library as -Verilog file containing blackbox modules. There are two ways to load cell -descriptions into Yosys: First the Verilog file for the cell library can be -passed directly to the {\tt show} command using the {\tt -lib <filename>} -option. Secondly it is possible to load cell libraries into the design with -the {\tt read\_verilog -lib <filename>} command. The 2nd method has the great -advantage that the library only needs to be loaded once and can then be used -in all subsequent calls to the {\tt show} command. - -In addition to that, the 2nd diagram was generated after {\tt splitnet -ports} -was run on the design. This command splits all signal vectors into individual -signal bits, which is often desirable when looking at gate-level circuits. The -{\tt -ports} option is required to also split module ports. Per default the -command only operates on interior signals. - -\subsection{Miscellaneous notes} - -Per default the {\tt show} command outputs a temporary {\tt dot} file and launches -{\tt xdot} to display it. The options {\tt -format}, {\tt -viewer} -and {\tt -prefix} can be used to change format, viewer and filename prefix. -Note that the {\tt pdf} and {\tt ps} format are the only formats that support -plotting multiple modules in one run. - -In densely connected circuits it is sometimes hard to keep track of the -individual signal wires. For this cases it can be useful to call {\tt show} -with the {\tt -colors <integer>} argument, which randomly assigns colors to the -nets. The integer (> 0) is used as seed value for the random color -assignments. Sometimes it is necessary it try some values to find an assignment -of colors that looks good. - -The command {\tt help show} prints a complete listing of all options supported -by the {\tt show} command. - -\section{Navigating the design} -\label{navigate} - -Plotting circuit diagrams for entire modules in the design brings us only helps -in simple cases. For complex modules the generated circuit diagrams are just stupidly big -and are no help at all. In such cases one first has to select the relevant -portions of the circuit. - -In addition to {\it what\/} to display one also needs to carefully decide -{\it when\/} to display it, with respect to the synthesis flow. In general -it is a good idea to troubleshoot a circuit in the earliest state in which -a problem can be reproduced. So if, for example, the internal state before calling -the {\tt techmap} command already fails to verify, it is better to troubleshoot -the coarse-grain version of the circuit before {\tt techmap} than the gate-level -circuit after {\tt techmap}. - -\medskip - -Note: It is generally recommended to verify the internal state of a design by -writing it to a Verilog file using {\tt write\_verilog -noexpr} and using the -simulation models from {\tt simlib.v} and {\tt simcells.v} from the Yosys data -directory (as printed by {\tt yosys-config -{}-datdir}). - -\subsection{Interactive Navigation} - -\begin{figure} -\begin{lstlisting} -yosys> ls - -1 modules: - example - -yosys> cd example - -yosys [example]> ls - -7 wires: - $0\y[1:0] - $add$example.v:5$2_Y - a - b - c - clk - y - -3 cells: - $add$example.v:5$2 - $procdff$7 - $procmux$5 -\end{lstlisting} -\caption{Demonstration of {\tt ls} and {\tt cd} using {\tt example.v} from Fig.~\ref{example_src}} -\label{lscd} -\end{figure} - -\begin{figure}[b] -\begin{lstlisting} - attribute \src "example.v:5" - cell $add $add$example.v:5$2 - parameter \A_SIGNED 0 - parameter \A_WIDTH 1 - parameter \B_SIGNED 0 - parameter \B_WIDTH 1 - parameter \Y_WIDTH 2 - connect \A \a - connect \B \b - connect \Y $add$example.v:5$2_Y - end -\end{lstlisting} -\caption{Output of {\tt dump \$2} using the design from Fig.~\ref{example_src} and Fig.~\ref{example_out}} -\label{dump2} -\end{figure} - -Once the right state within the synthesis flow for debugging the circuit has -been identified, it is recommended to simply add the {\tt shell} command -to the matching place in the synthesis script. This command will stop the -synthesis at the specified moment and go to shell mode, where the user can -interactively enter commands. - -For most cases, the shell will start with the whole design selected (i.e. when -the synthesis script does not already narrow the selection). The command {\tt -ls} can now be used to create a list of all modules. The command {\tt cd} can -be used to switch to one of the modules (type {\tt cd ..} to switch back). Now -the {\tt ls} command lists the objects within that module. Fig.~\ref{lscd} -demonstrates this using the design from Fig.~\ref{example_src}. - -There is a thing to note in Fig.~\ref{lscd}: We can see that the cell names -from Fig.~\ref{example_out} are just abbreviations of the actual cell names, -namely the part after the last dollar-sign. Most auto-generated names (the ones -starting with a dollar sign) are rather long and contains some additional -information on the origin of the named object. But in most cases those names -can simply be abbreviated using the last part. - -Usually all interactive work is done with one module selected using the {\tt cd} -command. But it is also possible to work from the design-context ({\tt cd ..}). In -this case all object names must be prefixed with {\tt <module\_name>/}. For -example {\tt a*/b*} would refer to all objects whose names start with {\tt b} from -all modules whose names start with {\tt a}. - -The {\tt dump} command can be used to print all information about an object. -For example {\tt dump \$2} will print Fig.~\ref{dump2}. This can for example -be useful to determine the names of nets connected to cells, as the net-names -are usually suppressed in the circuit diagram if they are auto-generated. - -For the remainder of this document we will assume that the commands are run from -module-context and not design-context. - -\subsection{Working with selections} - -\begin{figure}[t] -\includegraphics[width=\linewidth]{APPNOTE_011_Design_Investigation/example_03.pdf} -\caption{Output of {\tt show} after {\tt select \$2} or {\tt select t:\$add} -(see also Fig.~\ref{example_out})} -\label{seladd} -\end{figure} - -When a module is selected using the {\tt cd} command, all commands (with a few -exceptions, such as the {\tt read\_*} and {\tt write\_*} commands) operate -only on the selected module. This can also be useful for synthesis scripts -where different synthesis strategies should be applied to different modules -in the design. - -But for most interactive work we want to further narrow the set of selected -objects. This can be done using the {\tt select} command. - -For example, if the command {\tt select \$2} is executed, a subsequent {\tt show} -command will yield the diagram shown in Fig.~\ref{seladd}. Note that the nets are -now displayed in ellipses. This indicates that they are not selected, but only -shown because the diagram contains a cell that is connected to the net. This -of course makes no difference for the circuit that is shown, but it can be a useful -information when manipulating selections. - -Objects can not only be selected by their name but also by other properties. -For example {\tt select t:\$add} will select all cells of type {\tt \$add}. In -this case this is also yields the diagram shown in Fig.~\ref{seladd}. - -\begin{figure}[b] -\lstinputlisting{APPNOTE_011_Design_Investigation/foobaraddsub.v} -\caption{Test module for operations on selections} -\label{foobaraddsub} -\end{figure} - -The output of {\tt help select} contains a complete syntax reference for -matching different properties. - -Many commands can operate on explicit selections. For example the command {\tt -dump t:\$add} will print information on all {\tt \$add} cells in the active -module. Whenever a command has {\tt [selection]} as last argument in its usage -help, this means that it will use the engine behind the {\tt select} command -to evaluate additional arguments and use the resulting selection instead of -the selection created by the last {\tt select} command. - -Normally the {\tt select} command overwrites a previous selection. The -commands {\tt select -add} and {\tt select -del} can be used to add -or remove objects from the current selection. - -The command {\tt select -clear} can be used to reset the selection to the -default, which is a complete selection of everything in the current module. - -\subsection{Operations on selections} - -\begin{figure}[t] -\lstinputlisting{APPNOTE_011_Design_Investigation/sumprod.v} -\caption{Another test module for operations on selections} -\label{sumprod} -\end{figure} - -\begin{figure}[b] -\includegraphics[width=\linewidth]{APPNOTE_011_Design_Investigation/sumprod_00.pdf} -\caption{Output of {\tt show a:sumstuff} on Fig.~\ref{sumprod}} -\label{sumprod_00} -\end{figure} - -The {\tt select} command is actually much more powerful than it might seem on -the first glimpse. When it is called with multiple arguments, each argument is -evaluated and pushed separately on a stack. After all arguments have been -processed it simply creates the union of all elements on the stack. So the -following command will select all {\tt \$add} cells and all objects with -the {\tt foo} attribute set: - -\begin{verbatim} -select t:$add a:foo -\end{verbatim} - -(Try this with the design shown in Fig.~\ref{foobaraddsub}. Use the {\tt -select -list} command to list the current selection.) - -In many cases simply adding more and more stuff to the selection is an -ineffective way of selecting the interesting part of the design. Special -arguments can be used to combine the elements on the stack. -For example the {\tt \%i} arguments pops the last two elements from -the stack, intersects them, and pushes the result back on the stack. So the -following command will select all {\$add} cells that have the {\tt foo} -attribute set: - -\begin{verbatim} -select t:$add a:foo %i -\end{verbatim} - -The listing in Fig.~\ref{sumprod} uses the Yosys non-standard {\tt \{* ... *\}} -syntax to set the attribute {\tt sumstuff} on all cells generated by the first -assign statement. (This works on arbitrary large blocks of Verilog code an -can be used to mark portions of code for analysis.) - -Selecting {\tt a:sumstuff} in this module will yield the circuit diagram shown -in Fig.~\ref{sumprod_00}. As only the cells themselves are selected, but not -the temporary wire {\tt \$1\_Y}, the two adders are shown as two disjunct -parts. This can be very useful for global signals like clock and reset signals: just -unselect them using a command such as {\tt select -del clk rst} and each cell -using them will get its own net label. - -In this case however we would like to see the cells connected properly. This -can be achieved using the {\tt \%x} action, that broadens the selection, i.e. -for each selected wire it selects all cells connected to the wire and vice -versa. So {\tt show a:sumstuff \%x} yields the diagram shown in Fig.~\ref{sumprod_01}. - -\begin{figure}[t] -\includegraphics[width=\linewidth]{APPNOTE_011_Design_Investigation/sumprod_01.pdf} -\caption{Output of {\tt show a:sumstuff \%x} on Fig.~\ref{sumprod}} -\label{sumprod_01} -\end{figure} - -\subsection{Selecting logic cones} - -Fig.~\ref{sumprod_01} shows what is called the {\it input cone\/} of {\tt sum}, i.e. -all cells and signals that are used to generate the signal {\tt sum}. The {\tt \%ci} -action can be used to select the input cones of all object in the top selection -in the stack maintained by the {\tt select} command. - -As the {\tt \%x} action, this commands broadens the selection by one ``step''. But -this time the operation only works against the direction of data flow. That means, -wires only select cells via output ports and cells only select wires via input ports. - -Fig.~\ref{select_prod} show the sequence of diagrams generated by the following -commands: - -\begin{verbatim} -show prod -show prod %ci -show prod %ci %ci -show prod %ci %ci %ci -\end{verbatim} - -When selecting many levels of logic, repeating {\tt \%ci} over and over again -can be a bit dull. So there is a shortcut for that: the number of iterations -can be appended to the action. So for example the action {\tt \%ci3} is -identical to performing the {\tt \%ci} action three times. - -The action {\tt \%ci*} performs the {\tt \%ci} action over and over again until -it has no effect anymore. - -\begin{figure}[t] -\hfill \includegraphics[width=4cm,trim=0 1cm 0 1cm]{APPNOTE_011_Design_Investigation/sumprod_02.pdf} \\ -\includegraphics[width=\linewidth,trim=0 0cm 0 1cm]{APPNOTE_011_Design_Investigation/sumprod_03.pdf} \\ -\includegraphics[width=\linewidth,trim=0 0cm 0 1cm]{APPNOTE_011_Design_Investigation/sumprod_04.pdf} \\ -\includegraphics[width=\linewidth,trim=0 2cm 0 1cm]{APPNOTE_011_Design_Investigation/sumprod_05.pdf} \\ -\caption{Objects selected by {\tt select prod \%ci...}} -\label{select_prod} -\end{figure} - -\medskip - -In most cases there are certain cell types and/or ports that should not be considered for the {\tt \%ci} -action, or we only want to follow certain cell types and/or ports. This can be achieved using additional -patterns that can be appended to the {\tt \%ci} action. - -Lets consider the design from Fig.~\ref{memdemo_src}. It serves no purpose other than being a non-trivial -circuit for demonstrating some of the advanced Yosys features. We synthesize the circuit using {\tt proc; -opt; memory; opt} and change to the {\tt memdemo} module with {\tt cd memdemo}. If we type {\tt show} -now we see the diagram shown in Fig.~\ref{memdemo_00}. - -\begin{figure}[b!] -\lstinputlisting{APPNOTE_011_Design_Investigation/memdemo.v} -\caption{Demo circuit for demonstrating some advanced Yosys features} -\label{memdemo_src} -\end{figure} - -\begin{figure*}[t] -\includegraphics[width=\linewidth,trim=0 0cm 0 0cm]{APPNOTE_011_Design_Investigation/memdemo_00.pdf} \\ -\caption{Complete circuit diagram for the design shown in Fig.~\ref{memdemo_src}} -\label{memdemo_00} -\end{figure*} - -But maybe we are only interested in the tree of multiplexers that select the -output value. In order to get there, we would start by just showing the output signal -and its immediate predecessors: - -\begin{verbatim} -show y %ci2 -\end{verbatim} - -From this we would learn that {\tt y} is driven by a {\tt \$dff cell}, that -{\tt y} is connected to the output port {\tt Q}, that the {\tt clk} signal goes -into the {\tt CLK} input port of the cell, and that the data comes from a -auto-generated wire into the input {\tt D} of the flip-flop cell. - -As we are not interested in the clock signal we add an additional pattern to the {\tt \%ci} -action, that tells it to only follow ports {\tt Q} and {\tt D} of {\tt \$dff} cells: - -\begin{verbatim} -show y %ci2:+$dff[Q,D] -\end{verbatim} - -To add a pattern we add a colon followed by the pattern to the {\tt \%ci} -action. The pattern it self starts with {\tt -} or {\tt +}, indicating if it is -an include or exclude pattern, followed by an optional comma separated list -of cell types, followed by an optional comma separated list of port names in -square brackets. - -Since we know that the only cell considered in this case is a {\tt \$dff} cell, -we could as well only specify the port names: - -\begin{verbatim} -show y %ci2:+[Q,D] -\end{verbatim} - -Or we could decide to tell the {\tt \%ci} action to not follow the {\tt CLK} input: - -\begin{verbatim} -show y %ci2:-[CLK] -\end{verbatim} - -\begin{figure}[b] -\includegraphics[width=\linewidth,trim=0 0cm 0 0cm]{APPNOTE_011_Design_Investigation/memdemo_01.pdf} \\ -\caption{Output of {\tt show y \%ci2:+\$dff[Q,D] \%ci*:-\$mux[S]:-\$dff}} -\label{memdemo_01} -\end{figure} - -Next we would investigate the next logic level by adding another {\tt \%ci2} to -the command: - -\begin{verbatim} -show y %ci2:-[CLK] %ci2 -\end{verbatim} - -From this we would learn that the next cell is a {\tt \$mux} cell and we would add additional -pattern to narrow the selection on the path we are interested. In the end we would end up -with a command such as - -\begin{verbatim} -show y %ci2:+$dff[Q,D] %ci*:-$mux[S]:-$dff -\end{verbatim} - -in which the first {\tt \%ci} jumps over the initial d-type flip-flop and the -2nd action selects the entire input cone without going over multiplexer select -inputs and flip-flop cells. The diagram produces by this command is shown in -Fig.~\ref{memdemo_01}. - -\medskip - -Similar to {\tt \%ci} exists an action {\tt \%co} to select output cones that -accepts the same syntax for pattern and repetition. The {\tt \%x} action mentioned -previously also accepts this advanced syntax. - -This actions for traversing the circuit graph, combined with the actions for -boolean operations such as intersection ({\tt \%i}) and difference ({\tt \%d}) -are powerful tools for extracting the relevant portions of the circuit under -investigation. - -See {\tt help select} for a complete list of actions available in selections. - -\subsection{Storing and recalling selections} - -The current selection can be stored in memory with the command {\tt select -set -<name>}. It can later be recalled using {\tt select @<name>}. In fact, the {\tt -@<name>} expression pushes the stored selection on the stack maintained by the -{\tt select} command. So for example - -\begin{verbatim} -select @foo @bar %i -\end{verbatim} - -will select the intersection between the stored selections {\tt foo} and {\tt bar}. - -\medskip - -In larger investigation efforts it is highly recommended to maintain a script that -sets up relevant selections, so they can easily be recalled, for example when -Yosys needs to be re-run after a design or source code change. - -The {\tt history} command can be used to list all recent interactive commands. -This feature can be useful for creating such a script from the commands used in -an interactive session. - -\section{Advanced investigation techniques} -\label{poke} - -When working with very large modules, it is often not enough to just select the -interesting part of the module. Instead it can be useful to extract the -interesting part of the circuit into a separate module. This can for example be -useful if one wants to run a series of synthesis commands on the critical part -of the module and wants to carefully read all the debug output created by the -commands in order to spot a problem. This kind of troubleshooting is much easier -if the circuit under investigation is encapsulated in a separate module. - -Fig.~\ref{submod} shows how the {\tt submod} command can be used to split the -circuit from Fig.~\ref{memdemo_src} and \ref{memdemo_00} into its components. -The {\tt -name} option is used to specify the name of the new module and -also the name of the new cell in the current module. - -\begin{figure}[t] -\includegraphics[width=\linewidth,trim=0 1.3cm 0 0cm]{APPNOTE_011_Design_Investigation/submod_00.pdf} \\ \centerline{\tt memdemo} \vskip1em\par -\includegraphics[width=\linewidth,trim=0 1.3cm 0 0cm]{APPNOTE_011_Design_Investigation/submod_01.pdf} \\ \centerline{\tt scramble} \vskip1em\par -\includegraphics[width=\linewidth,trim=0 1.3cm 0 0cm]{APPNOTE_011_Design_Investigation/submod_02.pdf} \\ \centerline{\tt outstage} \vskip1em\par -\includegraphics[width=\linewidth,trim=0 1.3cm 0 0cm]{APPNOTE_011_Design_Investigation/submod_03.pdf} \\ \centerline{\tt selstage} \vskip1em\par -\begin{lstlisting}[basicstyle=\ttfamily\scriptsize] -select -set outstage y %ci2:+$dff[Q,D] %ci*:-$mux[S]:-$dff -select -set selstage y %ci2:+$dff[Q,D] %ci*:-$dff @outstage %d -select -set scramble mem* %ci2 %ci*:-$dff mem* %d @selstage %d -submod -name scramble @scramble -submod -name outstage @outstage -submod -name selstage @selstage -\end{lstlisting} -\caption{The circuit from Fig.~\ref{memdemo_src} and \ref{memdemo_00} broken up using {\tt submod}} -\label{submod} -\end{figure} - -\subsection{Evaluation of combinatorial circuits} - -The {\tt eval} command can be used to evaluate combinatorial circuits. -For example (see Fig.~\ref{submod} for the circuit diagram of {\tt selstage}): - -{\scriptsize -\begin{verbatim} - yosys [selstage]> eval -set s2,s1 4'b1001 -set d 4'hc -show n2 -show n1 - - 9. Executing EVAL pass (evaluate the circuit given an input). - Full command line: eval -set s2,s1 4'b1001 -set d 4'hc -show n2 -show n1 - Eval result: \n2 = 2'10. - Eval result: \n1 = 2'10. -\end{verbatim} -\par} - -So the {\tt -set} option is used to set input values and the {\tt -show} option -is used to specify the nets to evaluate. If no {\tt -show} option is specified, -all selected output ports are used per default. - -If a necessary input value is not given, an error is produced. The option -{\tt -set-undef} can be used to instead set all unspecified input nets to -undef ({\tt x}). - -The {\tt -table} option can be used to create a truth table. For example: - -{\scriptsize -\begin{verbatim} - yosys [selstage]> eval -set-undef -set d[3:1] 0 -table s1,d[0] - - 10. Executing EVAL pass (evaluate the circuit given an input). - Full command line: eval -set-undef -set d[3:1] 0 -table s1,d[0] - - \s1 \d [0] | \n1 \n2 - ---- ------ | ---- ---- - 2'00 1'0 | 2'00 2'00 - 2'00 1'1 | 2'xx 2'00 - 2'01 1'0 | 2'00 2'00 - 2'01 1'1 | 2'xx 2'01 - 2'10 1'0 | 2'00 2'00 - 2'10 1'1 | 2'xx 2'10 - 2'11 1'0 | 2'00 2'00 - 2'11 1'1 | 2'xx 2'11 - - Assumed undef (x) value for the following signals: \s2 -\end{verbatim} -} - -Note that the {\tt eval} command (as well as the {\tt sat} command discussed in -the next sections) does only operate on flattened modules. It can not analyze -signals that are passed through design hierarchy levels. So the {\tt flatten} -command must be used on modules that instantiate other modules before this -commands can be applied. - -\subsection{Solving combinatorial SAT problems} - -\begin{figure}[b] -\lstinputlisting{APPNOTE_011_Design_Investigation/primetest.v} -\caption{A simple miter circuit for testing if a number is prime. But it has a -problem (see main text and Fig.~\ref{primesat}).} -\label{primetest} -\end{figure} - -\begin{figure*}[!t] -\begin{lstlisting}[basicstyle=\ttfamily\small] -yosys [primetest]> sat -prove ok 1 -set p 31 - -8. Executing SAT pass (solving SAT problems in the circuit). -Full command line: sat -prove ok 1 -set p 31 - -Setting up SAT problem: -Import set-constraint: \p = 16'0000000000011111 -Final constraint equation: \p = 16'0000000000011111 -Imported 6 cells to SAT database. -Import proof-constraint: \ok = 1'1 -Final proof equation: \ok = 1'1 - -Solving problem with 2790 variables and 8241 clauses.. -SAT proof finished - model found: FAIL! - - ______ ___ ___ _ _ _ _ - (_____ \ / __) / __) (_) | | | | - _____) )___ ___ ___ _| |__ _| |__ _____ _| | _____ __| | | - | ____/ ___) _ \ / _ (_ __) (_ __|____ | | || ___ |/ _ |_| - | | | | | |_| | |_| || | | | / ___ | | || ____( (_| |_ - |_| |_| \___/ \___/ |_| |_| \_____|_|\_)_____)\____|_| - - - Signal Name Dec Hex Bin - -------------------- ---------- ---------- --------------------- - \a 15029 3ab5 0011101010110101 - \b 4099 1003 0001000000000011 - \ok 0 0 0 - \p 31 1f 0000000000011111 - -yosys [primetest]> sat -prove ok 1 -set p 31 -set a[15:8],b[15:8] 0 - -9. Executing SAT pass (solving SAT problems in the circuit). -Full command line: sat -prove ok 1 -set p 31 -set a[15:8],b[15:8] 0 - -Setting up SAT problem: -Import set-constraint: \p = 16'0000000000011111 -Import set-constraint: { \a [15:8] \b [15:8] } = 16'0000000000000000 -Final constraint equation: { \a [15:8] \b [15:8] \p } = { 16'0000000000000000 16'0000000000011111 } -Imported 6 cells to SAT database. -Import proof-constraint: \ok = 1'1 -Final proof equation: \ok = 1'1 - -Solving problem with 2790 variables and 8257 clauses.. -SAT proof finished - no model found: SUCCESS! - - /$$$$$$ /$$$$$$$$ /$$$$$$$ - /$$__ $$ | $$_____/ | $$__ $$ - | $$ \ $$ | $$ | $$ \ $$ - | $$ | $$ | $$$$$ | $$ | $$ - | $$ | $$ | $$__/ | $$ | $$ - | $$/$$ $$ | $$ | $$ | $$ - | $$$$$$/ /$$| $$$$$$$$ /$$| $$$$$$$//$$ - \____ $$$|__/|________/|__/|_______/|__/ - \__/ -\end{lstlisting} -\caption{Experiments with the miter circuit from Fig.~\ref{primetest}. The first attempt of proving that 31 -is prime failed because the SAT solver found a creative way of factorizing 31 using integer overflow.} -\label{primesat} -\end{figure*} - -Often the opposite of the {\tt eval} command is needed, i.e. the circuits -output is given and we want to find the matching input signals. For small -circuits with only a few input bits this can be accomplished by trying all -possible input combinations, as it is done by the {\tt eval -table} command. -For larger circuits however, Yosys provides the {\tt sat} command that uses -a SAT \cite{CircuitSAT} solver \cite{MiniSAT} to solve this kind of problems. - -The {\tt sat} command works very similar to the {\tt eval} command. The main -difference is that it is now also possible to set output values and find the -corresponding input values. For Example: - -{\scriptsize -\begin{verbatim} - yosys [selstage]> sat -show s1,s2,d -set s1 s2 -set n2,n1 4'b1001 - - 11. Executing SAT pass (solving SAT problems in the circuit). - Full command line: sat -show s1,s2,d -set s1 s2 -set n2,n1 4'b1001 - - Setting up SAT problem: - Import set-constraint: \s1 = \s2 - Import set-constraint: { \n2 \n1 } = 4'1001 - Final constraint equation: { \n2 \n1 \s1 } = { 4'1001 \s2 } - Imported 3 cells to SAT database. - Import show expression: { \s1 \s2 \d } - - Solving problem with 81 variables and 207 clauses.. - SAT solving finished - model found: - - Signal Name Dec Hex Bin - -------------------- ---------- ---------- --------------- - \d 9 9 1001 - \s1 0 0 00 - \s2 0 0 00 -\end{verbatim} -} - -Note that the {\tt sat} command supports signal names in both arguments -to the {\tt -set} option. In the above example we used {\tt -set s1 s2} -to constraint {\tt s1} and {\tt s2} to be equal. When more complex -constraints are needed, a wrapper circuit must be constructed that -checks the constraints and signals if the constraint was met using an -extra output port, which then can be forced to a value using the {\tt --set} option. (Such a circuit that contains the circuit under test -plus additional constraint checking circuitry is called a {\it miter\/} -circuit.) - -Fig.~\ref{primetest} shows a miter circuit that is supposed to be used as a -prime number test. If {\tt ok} is 1 for all input values {\tt a} and {\tt b} -for a given {\tt p}, then {\tt p} is prime, or at least that is the idea. - -The Yosys shell session shown in Fig.~\ref{primesat} demonstrates that SAT -solvers can even find the unexpected solutions to a problem: Using integer -overflow there actually is a way of ``factorizing'' 31. The clean solution -would of course be to perform the test in 32 bits, for example by replacing -{\tt p != a*b} in the miter with {\tt p != \{16'd0,a\}*b}, or by using a -temporary variable for the 32 bit product {\tt a*b}. But as 31 fits well into -8 bits (and as the purpose of this document is to show off Yosys features) -we can also simply force the upper 8 bits of {\tt a} and {\tt b} to zero for -the {\tt sat} call, as is done in the second command in Fig.~\ref{primesat} -(line 31). - -The {\tt -prove} option used in this example works similar to {\tt -set}, but -tries to find a case in which the two arguments are not equal. If such a case is -not found, the property is proven to hold for all inputs that satisfy the other -constraints. - -It might be worth noting, that SAT solvers are not particularly efficient at -factorizing large numbers. But if a small factorization problem occurs as -part of a larger circuit problem, the Yosys SAT solver is perfectly capable -of solving it. - -\subsection{Solving sequential SAT problems} - -\begin{figure}[t!] -\begin{lstlisting}[basicstyle=\ttfamily\scriptsize] -yosys [memdemo]> sat -seq 6 -show y -show d -set-init-undef \ - -max_undef -set-at 4 y 1 -set-at 5 y 2 -set-at 6 y 3 - -6. Executing SAT pass (solving SAT problems in the circuit). -Full command line: sat -seq 6 -show y -show d -set-init-undef - -max_undef -set-at 4 y 1 -set-at 5 y 2 -set-at 6 y 3 - -Setting up time step 1: -Final constraint equation: { } = { } -Imported 29 cells to SAT database. - -Setting up time step 2: -Final constraint equation: { } = { } -Imported 29 cells to SAT database. - -Setting up time step 3: -Final constraint equation: { } = { } -Imported 29 cells to SAT database. - -Setting up time step 4: -Import set-constraint for timestep: \y = 4'0001 -Final constraint equation: \y = 4'0001 -Imported 29 cells to SAT database. - -Setting up time step 5: -Import set-constraint for timestep: \y = 4'0010 -Final constraint equation: \y = 4'0010 -Imported 29 cells to SAT database. - -Setting up time step 6: -Import set-constraint for timestep: \y = 4'0011 -Final constraint equation: \y = 4'0011 -Imported 29 cells to SAT database. - -Setting up initial state: -Final constraint equation: { \y \s2 \s1 \mem[3] \mem[2] \mem[1] - \mem[0] } = 24'xxxxxxxxxxxxxxxxxxxxxxxx - -Import show expression: \y -Import show expression: \d - -Solving problem with 10322 variables and 27881 clauses.. -SAT model found. maximizing number of undefs. -SAT solving finished - model found: - - Time Signal Name Dec Hex Bin - ---- -------------------- ---------- ---------- --------------- - init \mem[0] -- -- xxxx - init \mem[1] -- -- xxxx - init \mem[2] -- -- xxxx - init \mem[3] -- -- xxxx - init \s1 -- -- xx - init \s2 -- -- xx - init \y -- -- xxxx - ---- -------------------- ---------- ---------- --------------- - 1 \d 0 0 0000 - 1 \y -- -- xxxx - ---- -------------------- ---------- ---------- --------------- - 2 \d 1 1 0001 - 2 \y -- -- xxxx - ---- -------------------- ---------- ---------- --------------- - 3 \d 2 2 0010 - 3 \y 0 0 0000 - ---- -------------------- ---------- ---------- --------------- - 4 \d 3 3 0011 - 4 \y 1 1 0001 - ---- -------------------- ---------- ---------- --------------- - 5 \d -- -- 001x - 5 \y 2 2 0010 - ---- -------------------- ---------- ---------- --------------- - 6 \d -- -- xxxx - 6 \y 3 3 0011 -\end{lstlisting} -\caption{Solving a sequential SAT problem in the {\tt memdemo} module from Fig.~\ref{memdemo_src}.} -\label{memdemo_sat} -\end{figure} - -The SAT solver functionality in Yosys can not only be used to solve -combinatorial problems, but can also solve sequential problems. Let's consider -the entire {\tt memdemo} module from Fig.~\ref{memdemo_src} and suppose we -want to know which sequence of input values for {\tt d} will cause the output -{\tt y} to produce the sequence 1, 2, 3 from any initial state. -Fig.~\ref{memdemo_sat} show the solution to this question, as produced by -the following command: - -\begin{verbatim} - sat -seq 6 -show y -show d -set-init-undef \ - -max_undef -set-at 4 y 1 -set-at 5 y 2 -set-at 6 y 3 -\end{verbatim} - -The {\tt -seq 6} option instructs the {\tt sat} command to solve a sequential -problem in 6 time steps. (Experiments with lower number of steps have show that -at least 3 cycles are necessary to bring the circuit in a state from which -the sequence 1, 2, 3 can be produced.) - -The {\tt -set-init-undef} option tells the {\tt sat} command to initialize -all registers to the undef ({\tt x}) state. The way the {\tt x} state -is treated in Verilog will ensure that the solution will work for any -initial state. - -The {\tt -max\_undef} option instructs the {\tt sat} command to find a solution -with a maximum number of undefs. This way we can see clearly which inputs bits -are relevant to the solution. - -Finally the three {\tt -set-at} options add constraints for the {\tt y} -signal to play the 1, 2, 3 sequence, starting with time step 4. - -It is not surprising that the solution sets {\tt d = 0} in the first step, as -this is the only way of setting the {\tt s1} and {\tt s2} registers to a known -value. The input values for the other steps are a bit harder to work out -manually, but the SAT solver finds the correct solution in an instant. - -\medskip - -There is much more to write about the {\tt sat} command. For example, there is -a set of options that can be used to performs sequential proofs using temporal -induction \cite{tip}. The command {\tt help sat} can be used to print a list -of all options with short descriptions of their functions. - -\section{Conclusion} -\label{conclusion} - -Yosys provides a wide range of functions to analyze and investigate designs. For -many cases it is sufficient to simply display circuit diagrams, maybe use some -additional commands to narrow the scope of the circuit diagrams to the interesting -parts of the circuit. But some cases require more than that. For this applications -Yosys provides commands that can be used to further inspect the behavior of the -circuit, either by evaluating which output values are generated from certain input values -({\tt eval}) or by evaluation which input values and initial conditions can result -in a certain behavior at the outputs ({\tt sat}). The SAT command can even be used -to prove (or disprove) theorems regarding the circuit, in more advanced cases -with the additional help of a miter circuit. - -This features can be powerful tools for the circuit designer using Yosys as a -utility for building circuits and the software developer using Yosys as a -framework for new algorithms alike. - -\begin{thebibliography}{9} - -\bibitem{yosys} -Claire Xenia Wolf. The Yosys Open SYnthesis Suite. -\url{https://yosyshq.net/yosys/} - -\bibitem{graphviz} -Graphviz - Graph Visualization Software. -\url{http://www.graphviz.org/} - -\bibitem{xdot} -xdot.py - an interactive viewer for graphs written in Graphviz's dot language. -\url{https://github.com/jrfonseca/xdot.py} - -\bibitem{CircuitSAT} -{\it Circuit satisfiability problem} on Wikipedia -\url{http://en.wikipedia.org/wiki/Circuit_satisfiability} - -\bibitem{MiniSAT} -MiniSat: a minimalistic open-source SAT solver. -\url{http://minisat.se/} - -\bibitem{tip} -Niklas Een and Niklas S\"orensson (2003). -Temporal Induction by Incremental SAT Solving. -\url{http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.4.8161} - -\end{thebibliography} - -\end{document} diff --git a/manual/APPNOTE_011_Design_Investigation/cmos.v b/manual/APPNOTE_011_Design_Investigation/cmos.v deleted file mode 100644 index 2912c760a..000000000 --- a/manual/APPNOTE_011_Design_Investigation/cmos.v +++ /dev/null @@ -1,3 +0,0 @@ -module cmos_demo(input a, b, output [1:0] y); -assign y = a + b; -endmodule diff --git a/manual/APPNOTE_011_Design_Investigation/cmos_00.dot b/manual/APPNOTE_011_Design_Investigation/cmos_00.dot deleted file mode 100644 index 49c630080..000000000 --- a/manual/APPNOTE_011_Design_Investigation/cmos_00.dot +++ /dev/null @@ -1,34 +0,0 @@ -digraph "cmos_demo" { -rankdir="LR"; -remincross=true; -n4 [ shape=octagon, label="a", color="black", fontcolor="black" ]; -n5 [ shape=octagon, label="b", color="black", fontcolor="black" ]; -n6 [ shape=octagon, label="y", color="black", fontcolor="black" ]; -c10 [ shape=record, label="{{<p7> A|<p8> B|<p9> Y}|$g0\nNOR|{}}" ]; -c11 [ shape=record, label="{{<p7> A|<p9> Y}|$g1\nNOT|{}}" ]; -c12 [ shape=record, label="{{<p7> A|<p9> Y}|$g2\nNOT|{}}" ]; -c13 [ shape=record, label="{{<p7> A|<p8> B|<p9> Y}|$g3\nNOR|{}}" ]; -x0 [ shape=record, style=rounded, label="<s0> 1:1 - 0:0 " ]; -x0:e -> c13:p9:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c14 [ shape=record, label="{{<p7> A|<p8> B|<p9> Y}|$g4\nNOR|{}}" ]; -x1 [ shape=record, style=rounded, label="<s0> 1:1 - 0:0 " ]; -x1:e -> c14:p8:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -x2 [ shape=record, style=rounded, label="<s0> 0:0 - 0:0 " ]; -x2:e -> c14:p9:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -n1 [ shape=diamond, label="$n4" ]; -n1:e -> c10:p9:w [color="black", label=""]; -n1:e -> c14:p7:w [color="black", label=""]; -n2 [ shape=diamond, label="$n5" ]; -n2:e -> c11:p9:w [color="black", label=""]; -n2:e -> c13:p7:w [color="black", label=""]; -n3 [ shape=diamond, label="$n6_1" ]; -n3:e -> c12:p9:w [color="black", label=""]; -n3:e -> c13:p8:w [color="black", label=""]; -n4:e -> c10:p8:w [color="black", label=""]; -n4:e -> c12:p7:w [color="black", label=""]; -n5:e -> c10:p7:w [color="black", label=""]; -n5:e -> c11:p7:w [color="black", label=""]; -n6:e -> x0:s0:w [color="black", label=""]; -n6:e -> x1:s0:w [color="black", label=""]; -n6:e -> x2:s0:w [color="black", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/cmos_01.dot b/manual/APPNOTE_011_Design_Investigation/cmos_01.dot deleted file mode 100644 index ea6f4403c..000000000 --- a/manual/APPNOTE_011_Design_Investigation/cmos_01.dot +++ /dev/null @@ -1,23 +0,0 @@ -digraph "cmos_demo" { -rankdir="LR"; -remincross=true; -n4 [ shape=octagon, label="a", color="black", fontcolor="black" ]; -n5 [ shape=octagon, label="b", color="black", fontcolor="black" ]; -n6 [ shape=octagon, label="y[0]", color="black", fontcolor="black" ]; -n7 [ shape=octagon, label="y[1]", color="black", fontcolor="black" ]; -c11 [ shape=record, label="{{<p8> A|<p9> B}|$g0\nNOR|{<p10> Y}}" ]; -c12 [ shape=record, label="{{<p8> A}|$g1\nNOT|{<p10> Y}}" ]; -c13 [ shape=record, label="{{<p8> A}|$g2\nNOT|{<p10> Y}}" ]; -c14 [ shape=record, label="{{<p8> A|<p9> B}|$g3\nNOR|{<p10> Y}}" ]; -c15 [ shape=record, label="{{<p8> A|<p9> B}|$g4\nNOR|{<p10> Y}}" ]; -c11:p10:e -> c15:p8:w [color="black", label=""]; -c12:p10:e -> c14:p8:w [color="black", label=""]; -c13:p10:e -> c14:p9:w [color="black", label=""]; -n4:e -> c11:p9:w [color="black", label=""]; -n4:e -> c13:p8:w [color="black", label=""]; -n5:e -> c11:p8:w [color="black", label=""]; -n5:e -> c12:p8:w [color="black", label=""]; -c15:p10:e -> n6:w [color="black", label=""]; -c14:p10:e -> n7:w [color="black", label=""]; -n7:e -> c15:p9:w [color="black", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/example.v b/manual/APPNOTE_011_Design_Investigation/example.v deleted file mode 100644 index 8c71989b3..000000000 --- a/manual/APPNOTE_011_Design_Investigation/example.v +++ /dev/null @@ -1,6 +0,0 @@ -module example(input clk, a, b, c, - output reg [1:0] y); - always @(posedge clk) - if (c) - y <= c ? a + b : 2'd0; -endmodule diff --git a/manual/APPNOTE_011_Design_Investigation/example.ys b/manual/APPNOTE_011_Design_Investigation/example.ys deleted file mode 100644 index b1e956088..000000000 --- a/manual/APPNOTE_011_Design_Investigation/example.ys +++ /dev/null @@ -1,11 +0,0 @@ -read_verilog example.v -show -format dot -prefix example_00 -proc -show -format dot -prefix example_01 -opt -show -format dot -prefix example_02 - -cd example -select t:$add -show -format dot -prefix example_03 - diff --git a/manual/APPNOTE_011_Design_Investigation/example_00.dot b/manual/APPNOTE_011_Design_Investigation/example_00.dot deleted file mode 100644 index 1e23ed0ea..000000000 --- a/manual/APPNOTE_011_Design_Investigation/example_00.dot +++ /dev/null @@ -1,23 +0,0 @@ -digraph "example" { -rankdir="LR"; -remincross=true; -n4 [ shape=octagon, label="a", color="black", fontcolor="black" ]; -n5 [ shape=octagon, label="b", color="black", fontcolor="black" ]; -n6 [ shape=octagon, label="c", color="black", fontcolor="black" ]; -n7 [ shape=octagon, label="clk", color="black", fontcolor="black" ]; -n8 [ shape=octagon, label="y", color="black", fontcolor="black" ]; -c12 [ shape=record, label="{{<p9> A|<p10> B}|$2\n$add|{<p11> Y}}" ]; -v0 [ label="2'00" ]; -c14 [ shape=record, label="{{<p9> A|<p10> B|<p13> S}|$3\n$mux|{<p11> Y}}" ]; -p1 [shape=box, style=rounded, label="PROC $1\nexample.v:3"]; -c12:p11:e -> c14:p10:w [color="black", style="setlinewidth(3)", label=""]; -c14:p11:e -> p1:w [color="black", style="setlinewidth(3)", label=""]; -n4:e -> c12:p9:w [color="black", label=""]; -n5:e -> c12:p10:w [color="black", label=""]; -n6:e -> c14:p13:w [color="black", label=""]; -n6:e -> p1:w [color="black", label=""]; -n7:e -> p1:w [color="black", label=""]; -p1:e -> n8:w [color="black", style="setlinewidth(3)", label=""]; -n8:e -> p1:w [color="black", style="setlinewidth(3)", label=""]; -v0:e -> c14:p9:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/example_01.dot b/manual/APPNOTE_011_Design_Investigation/example_01.dot deleted file mode 100644 index e89292b51..000000000 --- a/manual/APPNOTE_011_Design_Investigation/example_01.dot +++ /dev/null @@ -1,33 +0,0 @@ -digraph "example" { -rankdir="LR"; -remincross=true; -n6 [ shape=octagon, label="a", color="black", fontcolor="black" ]; -n7 [ shape=octagon, label="b", color="black", fontcolor="black" ]; -n8 [ shape=octagon, label="c", color="black", fontcolor="black" ]; -n9 [ shape=octagon, label="clk", color="black", fontcolor="black" ]; -n10 [ shape=octagon, label="y", color="black", fontcolor="black" ]; -c14 [ shape=record, label="{{<p11> A|<p12> B}|$2\n$add|{<p13> Y}}" ]; -c18 [ shape=record, label="{{<p15> CLK|<p16> D}|$7\n$dff|{<p17> Q}}" ]; -c20 [ shape=record, label="{{<p11> A|<p12> B|<p19> S}|$5\n$mux|{<p13> Y}}" ]; -v0 [ label="2'00" ]; -c21 [ shape=record, label="{{<p11> A|<p12> B|<p19> S}|$3\n$mux|{<p13> Y}}" ]; -x1 [shape=box, style=rounded, label="BUF"]; -x2 [shape=box, style=rounded, label="BUF"]; -n1 [ shape=diamond, label="$0\\y[1:0]" ]; -x2:e:e -> n1:w [color="black", style="setlinewidth(3)", label=""]; -c18:p17:e -> n10:w [color="black", style="setlinewidth(3)", label=""]; -n10:e -> c20:p11:w [color="black", style="setlinewidth(3)", label=""]; -c14:p13:e -> c21:p12:w [color="black", style="setlinewidth(3)", label=""]; -n3 [ shape=point ]; -c20:p13:e -> n3:w [color="black", style="setlinewidth(3)", label=""]; -n3:e -> c18:p16:w [color="black", style="setlinewidth(3)", label=""]; -n3:e -> x2:w:w [color="black", style="setlinewidth(3)", label=""]; -x1:e:e -> c20:p19:w [color="black", label=""]; -c21:p13:e -> c20:p12:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> c14:p11:w [color="black", label=""]; -n7:e -> c14:p12:w [color="black", label=""]; -n8:e -> c21:p19:w [color="black", label=""]; -n8:e -> x1:w:w [color="black", label=""]; -n9:e -> c18:p15:w [color="black", label=""]; -v0:e -> c21:p11:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/example_02.dot b/manual/APPNOTE_011_Design_Investigation/example_02.dot deleted file mode 100644 index f950ed2ed..000000000 --- a/manual/APPNOTE_011_Design_Investigation/example_02.dot +++ /dev/null @@ -1,20 +0,0 @@ -digraph "example" { -rankdir="LR"; -remincross=true; -n3 [ shape=octagon, label="a", color="black", fontcolor="black" ]; -n4 [ shape=octagon, label="b", color="black", fontcolor="black" ]; -n5 [ shape=octagon, label="c", color="black", fontcolor="black" ]; -n6 [ shape=octagon, label="clk", color="black", fontcolor="black" ]; -n7 [ shape=octagon, label="y", color="black", fontcolor="black" ]; -c11 [ shape=record, label="{{<p8> A|<p9> B}|$2\n$add|{<p10> Y}}" ]; -c15 [ shape=record, label="{{<p12> CLK|<p13> D}|$7\n$dff|{<p14> Q}}" ]; -c17 [ shape=record, label="{{<p8> A|<p9> B|<p16> S}|$5\n$mux|{<p10> Y}}" ]; -c17:p10:e -> c15:p13:w [color="black", style="setlinewidth(3)", label=""]; -c11:p10:e -> c17:p9:w [color="black", style="setlinewidth(3)", label=""]; -n3:e -> c11:p8:w [color="black", label=""]; -n4:e -> c11:p9:w [color="black", label=""]; -n5:e -> c17:p16:w [color="black", label=""]; -n6:e -> c15:p12:w [color="black", label=""]; -c15:p14:e -> n7:w [color="black", style="setlinewidth(3)", label=""]; -n7:e -> c17:p8:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/example_03.dot b/manual/APPNOTE_011_Design_Investigation/example_03.dot deleted file mode 100644 index e19d24af7..000000000 --- a/manual/APPNOTE_011_Design_Investigation/example_03.dot +++ /dev/null @@ -1,11 +0,0 @@ -digraph "example" { -rankdir="LR"; -remincross=true; -v0 [ label="a" ]; -v1 [ label="b" ]; -v2 [ label="$2_Y" ]; -c4 [ shape=record, label="{{<p1> A|<p2> B}|$2\n$add|{<p3> Y}}" ]; -v0:e -> c4:p1:w [color="black", label=""]; -v1:e -> c4:p2:w [color="black", label=""]; -c4:p3:e -> v2:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/foobaraddsub.v b/manual/APPNOTE_011_Design_Investigation/foobaraddsub.v deleted file mode 100644 index 0f277211d..000000000 --- a/manual/APPNOTE_011_Design_Investigation/foobaraddsub.v +++ /dev/null @@ -1,8 +0,0 @@ -module foobaraddsub(a, b, c, d, fa, fs, ba, bs); - input [7:0] a, b, c, d; - output [7:0] fa, fs, ba, bs; - assign fa = a + (* foo *) b; - assign fs = a - (* foo *) b; - assign ba = c + (* bar *) d; - assign bs = c - (* bar *) d; -endmodule diff --git a/manual/APPNOTE_011_Design_Investigation/make.sh b/manual/APPNOTE_011_Design_Investigation/make.sh deleted file mode 100644 index 3845dac6b..000000000 --- a/manual/APPNOTE_011_Design_Investigation/make.sh +++ /dev/null @@ -1,23 +0,0 @@ -#!/bin/bash -set -ex -if false; then - rm -f *.dot - ../../yosys example.ys - ../../yosys -p 'proc; opt; show -format dot -prefix splice' splice.v - ../../yosys -p 'techmap; abc -liberty ../../techlibs/cmos/cmos_cells.lib;; show -format dot -prefix cmos_00' cmos.v - ../../yosys -p 'techmap; splitnets -ports; abc -liberty ../../techlibs/cmos/cmos_cells.lib;; show -lib ../../techlibs/cmos/cmos_cells.v -format dot -prefix cmos_01' cmos.v - ../../yosys -p 'opt; cd sumprod; select a:sumstuff; show -format dot -prefix sumprod_00' sumprod.v - ../../yosys -p 'opt; cd sumprod; select a:sumstuff %x; show -format dot -prefix sumprod_01' sumprod.v - ../../yosys -p 'opt; cd sumprod; select prod; show -format dot -prefix sumprod_02' sumprod.v - ../../yosys -p 'opt; cd sumprod; select prod %ci; show -format dot -prefix sumprod_03' sumprod.v - ../../yosys -p 'opt; cd sumprod; select prod %ci2; show -format dot -prefix sumprod_04' sumprod.v - ../../yosys -p 'opt; cd sumprod; select prod %ci3; show -format dot -prefix sumprod_05' sumprod.v - ../../yosys -p 'proc; opt; memory; opt; cd memdemo; show -format dot -prefix memdemo_00' memdemo.v - ../../yosys -p 'proc; opt; memory; opt; cd memdemo; show -format dot -prefix memdemo_01 y %ci2:+$dff[Q,D] %ci*:-$mux[S]:-$dff' memdemo.v - ../../yosys submod.ys - sed -i '/^label=/ d;' *.dot -fi -for dot_file in *.dot; do - pdf_file=${dot_file%.dot}.pdf - dot -Tpdf -o $pdf_file $dot_file -done diff --git a/manual/APPNOTE_011_Design_Investigation/memdemo.v b/manual/APPNOTE_011_Design_Investigation/memdemo.v deleted file mode 100644 index b39564ddc..000000000 --- a/manual/APPNOTE_011_Design_Investigation/memdemo.v +++ /dev/null @@ -1,19 +0,0 @@ -module memdemo(clk, d, y); - -input clk; -input [3:0] d; -output reg [3:0] y; - -integer i; -reg [1:0] s1, s2; -reg [3:0] mem [0:3]; - -always @(posedge clk) begin - for (i = 0; i < 4; i = i+1) - mem[i] <= mem[(i+1) % 4] + mem[(i+2) % 4]; - { s2, s1 } = d ? { s1, s2 } ^ d : 4'b0; - mem[s1] <= d; - y <= mem[s2]; -end - -endmodule diff --git a/manual/APPNOTE_011_Design_Investigation/memdemo_00.dot b/manual/APPNOTE_011_Design_Investigation/memdemo_00.dot deleted file mode 100644 index 0336a9aac..000000000 --- a/manual/APPNOTE_011_Design_Investigation/memdemo_00.dot +++ /dev/null @@ -1,138 +0,0 @@ -digraph "memdemo" { -rankdir="LR"; -remincross=true; -n24 [ shape=octagon, label="clk", color="black", fontcolor="black" ]; -n25 [ shape=octagon, label="d", color="black", fontcolor="black" ]; -n26 [ shape=diamond, label="mem[0]", color="black", fontcolor="black" ]; -n27 [ shape=diamond, label="mem[1]", color="black", fontcolor="black" ]; -n28 [ shape=diamond, label="mem[2]", color="black", fontcolor="black" ]; -n29 [ shape=diamond, label="mem[3]", color="black", fontcolor="black" ]; -n30 [ shape=diamond, label="s1", color="black", fontcolor="black" ]; -n31 [ shape=diamond, label="s2", color="black", fontcolor="black" ]; -n32 [ shape=octagon, label="y", color="black", fontcolor="black" ]; -c36 [ shape=record, label="{{<p33> A|<p34> B}|$28\n$add|{<p35> Y}}" ]; -c37 [ shape=record, label="{{<p33> A|<p34> B}|$31\n$add|{<p35> Y}}" ]; -c38 [ shape=record, label="{{<p33> A|<p34> B}|$34\n$add|{<p35> Y}}" ]; -c39 [ shape=record, label="{{<p33> A|<p34> B}|$37\n$add|{<p35> Y}}" ]; -c41 [ shape=record, label="{{<p33> A|<p34> B|<p40> S}|$110\n$mux|{<p35> Y}}" ]; -x0 [ shape=record, style=rounded, label="<s0> 1:1 - 0:0 " ]; -x0:e -> c41:p40:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c42 [ shape=record, label="{{<p33> A|<p34> B|<p40> S}|$113\n$mux|{<p35> Y}}" ]; -x1 [ shape=record, style=rounded, label="<s0> 0:0 - 0:0 " ]; -x1:e -> c42:p40:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c43 [ shape=record, label="{{<p33> A|<p34> B|<p40> S}|$116\n$mux|{<p35> Y}}" ]; -x2 [ shape=record, style=rounded, label="<s0> 0:0 - 0:0 " ]; -x2:e -> c43:p40:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -v3 [ label="1'1" ]; -c44 [ shape=record, label="{{<p33> A|<p34> B}|$145\n$and|{<p35> Y}}" ]; -v4 [ label="1'1" ]; -c45 [ shape=record, label="{{<p33> A|<p34> B}|$175\n$and|{<p35> Y}}" ]; -v5 [ label="1'1" ]; -c46 [ shape=record, label="{{<p33> A|<p34> B}|$205\n$and|{<p35> Y}}" ]; -v6 [ label="1'1" ]; -c47 [ shape=record, label="{{<p33> A|<p34> B}|$235\n$and|{<p35> Y}}" ]; -v7 [ label="2'00" ]; -c48 [ shape=record, label="{{<p33> A|<p34> B}|$143\n$eq|{<p35> Y}}" ]; -v8 [ label="2'01" ]; -c49 [ shape=record, label="{{<p33> A|<p34> B}|$173\n$eq|{<p35> Y}}" ]; -v9 [ label="2'10" ]; -c50 [ shape=record, label="{{<p33> A|<p34> B}|$203\n$eq|{<p35> Y}}" ]; -v10 [ label="2'11" ]; -c51 [ shape=record, label="{{<p33> A|<p34> B}|$233\n$eq|{<p35> Y}}" ]; -c52 [ shape=record, label="{{<p33> A|<p34> B|<p40> S}|$147\n$mux|{<p35> Y}}" ]; -c53 [ shape=record, label="{{<p33> A|<p34> B|<p40> S}|$177\n$mux|{<p35> Y}}" ]; -c54 [ shape=record, label="{{<p33> A|<p34> B|<p40> S}|$207\n$mux|{<p35> Y}}" ]; -c55 [ shape=record, label="{{<p33> A|<p34> B|<p40> S}|$237\n$mux|{<p35> Y}}" ]; -c59 [ shape=record, label="{{<p56> CLK|<p57> D}|$66\n$dff|{<p58> Q}}" ]; -c60 [ shape=record, label="{{<p56> CLK|<p57> D}|$68\n$dff|{<p58> Q}}" ]; -c61 [ shape=record, label="{{<p56> CLK|<p57> D}|$70\n$dff|{<p58> Q}}" ]; -c62 [ shape=record, label="{{<p56> CLK|<p57> D}|$72\n$dff|{<p58> Q}}" ]; -c63 [ shape=record, label="{{<p56> CLK|<p57> D}|$59\n$dff|{<p58> Q}}" ]; -c64 [ shape=record, label="{{<p56> CLK|<p57> D}|$63\n$dff|{<p58> Q}}" ]; -c65 [ shape=record, label="{{<p56> CLK|<p57> D}|$64\n$dff|{<p58> Q}}" ]; -c66 [ shape=record, label="{{<p33> A}|$39\n$reduce_bool|{<p35> Y}}" ]; -v11 [ label="4'0000" ]; -c67 [ shape=record, label="{{<p33> A|<p34> B|<p40> S}|$40\n$mux|{<p35> Y}}" ]; -x12 [ shape=record, style=rounded, label="<s1> 3:2 - 1:0 |<s0> 1:0 - 1:0 " ]; -c67:p35:e -> x12:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", style="setlinewidth(3)", label=""]; -c68 [ shape=record, label="{{<p33> A|<p34> B}|$38\n$xor|{<p35> Y}}" ]; -x13 [ shape=record, style=rounded, label="<s1> 1:0 - 3:2 |<s0> 1:0 - 1:0 " ]; -x13:e -> c68:p33:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", style="setlinewidth(3)", label=""]; -c36:p35:e -> c52:p33:w [color="black", style="setlinewidth(3)", label=""]; -c44:p35:e -> c52:p40:w [color="black", label=""]; -c45:p35:e -> c53:p40:w [color="black", label=""]; -c46:p35:e -> c54:p40:w [color="black", label=""]; -c47:p35:e -> c55:p40:w [color="black", label=""]; -c48:p35:e -> c44:p33:w [color="black", label=""]; -c49:p35:e -> c45:p33:w [color="black", label=""]; -c50:p35:e -> c46:p33:w [color="black", label=""]; -c51:p35:e -> c47:p33:w [color="black", label=""]; -c52:p35:e -> c59:p57:w [color="black", style="setlinewidth(3)", label=""]; -c53:p35:e -> c60:p57:w [color="black", style="setlinewidth(3)", label=""]; -c37:p35:e -> c53:p33:w [color="black", style="setlinewidth(3)", label=""]; -c54:p35:e -> c61:p57:w [color="black", style="setlinewidth(3)", label=""]; -c55:p35:e -> c62:p57:w [color="black", style="setlinewidth(3)", label=""]; -c66:p35:e -> c67:p40:w [color="black", label=""]; -c68:p35:e -> c67:p34:w [color="black", style="setlinewidth(3)", label=""]; -n24:e -> c59:p56:w [color="black", label=""]; -n24:e -> c60:p56:w [color="black", label=""]; -n24:e -> c61:p56:w [color="black", label=""]; -n24:e -> c62:p56:w [color="black", label=""]; -n24:e -> c63:p56:w [color="black", label=""]; -n24:e -> c64:p56:w [color="black", label=""]; -n24:e -> c65:p56:w [color="black", label=""]; -n25:e -> c52:p34:w [color="black", style="setlinewidth(3)", label=""]; -n25:e -> c53:p34:w [color="black", style="setlinewidth(3)", label=""]; -n25:e -> c54:p34:w [color="black", style="setlinewidth(3)", label=""]; -n25:e -> c55:p34:w [color="black", style="setlinewidth(3)", label=""]; -n25:e -> c66:p33:w [color="black", style="setlinewidth(3)", label=""]; -n25:e -> c68:p34:w [color="black", style="setlinewidth(3)", label=""]; -c59:p58:e -> n26:w [color="black", style="setlinewidth(3)", label=""]; -n26:e -> c38:p34:w [color="black", style="setlinewidth(3)", label=""]; -n26:e -> c39:p33:w [color="black", style="setlinewidth(3)", label=""]; -n26:e -> c42:p33:w [color="black", style="setlinewidth(3)", label=""]; -c60:p58:e -> n27:w [color="black", style="setlinewidth(3)", label=""]; -n27:e -> c36:p33:w [color="black", style="setlinewidth(3)", label=""]; -n27:e -> c39:p34:w [color="black", style="setlinewidth(3)", label=""]; -n27:e -> c42:p34:w [color="black", style="setlinewidth(3)", label=""]; -c61:p58:e -> n28:w [color="black", style="setlinewidth(3)", label=""]; -n28:e -> c36:p34:w [color="black", style="setlinewidth(3)", label=""]; -n28:e -> c37:p33:w [color="black", style="setlinewidth(3)", label=""]; -n28:e -> c43:p33:w [color="black", style="setlinewidth(3)", label=""]; -c62:p58:e -> n29:w [color="black", style="setlinewidth(3)", label=""]; -n29:e -> c37:p34:w [color="black", style="setlinewidth(3)", label=""]; -n29:e -> c38:p33:w [color="black", style="setlinewidth(3)", label=""]; -n29:e -> c43:p34:w [color="black", style="setlinewidth(3)", label=""]; -c38:p35:e -> c54:p33:w [color="black", style="setlinewidth(3)", label=""]; -c63:p58:e -> n30:w [color="black", style="setlinewidth(3)", label=""]; -n30:e -> x13:s1:w [color="black", style="setlinewidth(3)", label=""]; -c64:p58:e -> n31:w [color="black", style="setlinewidth(3)", label=""]; -n31:e -> x13:s0:w [color="black", style="setlinewidth(3)", label=""]; -c65:p58:e -> n32:w [color="black", style="setlinewidth(3)", label=""]; -c39:p35:e -> c55:p33:w [color="black", style="setlinewidth(3)", label=""]; -n5 [ shape=point ]; -x12:s0:e -> n5:w [color="black", style="setlinewidth(3)", label=""]; -n5:e -> c48:p34:w [color="black", style="setlinewidth(3)", label=""]; -n5:e -> c49:p34:w [color="black", style="setlinewidth(3)", label=""]; -n5:e -> c50:p34:w [color="black", style="setlinewidth(3)", label=""]; -n5:e -> c51:p34:w [color="black", style="setlinewidth(3)", label=""]; -n5:e -> c63:p57:w [color="black", style="setlinewidth(3)", label=""]; -n6 [ shape=point ]; -x12:s1:e -> n6:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> c64:p57:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> x0:s0:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> x1:s0:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> x2:s0:w [color="black", style="setlinewidth(3)", label=""]; -c41:p35:e -> c65:p57:w [color="black", style="setlinewidth(3)", label=""]; -c42:p35:e -> c41:p33:w [color="black", style="setlinewidth(3)", label=""]; -c43:p35:e -> c41:p34:w [color="black", style="setlinewidth(3)", label=""]; -v10:e -> c51:p33:w [color="black", style="setlinewidth(3)", label=""]; -v11:e -> c67:p33:w [color="black", style="setlinewidth(3)", label=""]; -v3:e -> c44:p34:w [color="black", label=""]; -v4:e -> c45:p34:w [color="black", label=""]; -v5:e -> c46:p34:w [color="black", label=""]; -v6:e -> c47:p34:w [color="black", label=""]; -v7:e -> c48:p33:w [color="black", style="setlinewidth(3)", label=""]; -v8:e -> c49:p33:w [color="black", style="setlinewidth(3)", label=""]; -v9:e -> c50:p33:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/memdemo_01.dot b/manual/APPNOTE_011_Design_Investigation/memdemo_01.dot deleted file mode 100644 index 2ad92c78b..000000000 --- a/manual/APPNOTE_011_Design_Investigation/memdemo_01.dot +++ /dev/null @@ -1,29 +0,0 @@ -digraph "memdemo" { -rankdir="LR"; -remincross=true; -n4 [ shape=diamond, label="mem[0]", color="black", fontcolor="black" ]; -n5 [ shape=diamond, label="mem[1]", color="black", fontcolor="black" ]; -n6 [ shape=diamond, label="mem[2]", color="black", fontcolor="black" ]; -n7 [ shape=diamond, label="mem[3]", color="black", fontcolor="black" ]; -n8 [ shape=octagon, label="y", color="black", fontcolor="black" ]; -v0 [ label="$0\\s2[1:0] [1]" ]; -c13 [ shape=record, label="{{<p9> A|<p10> B|<p11> S}|$110\n$mux|{<p12> Y}}" ]; -v1 [ label="$0\\s2[1:0] [0]" ]; -c14 [ shape=record, label="{{<p9> A|<p10> B|<p11> S}|$113\n$mux|{<p12> Y}}" ]; -v2 [ label="$0\\s2[1:0] [0]" ]; -c15 [ shape=record, label="{{<p9> A|<p10> B|<p11> S}|$116\n$mux|{<p12> Y}}" ]; -v3 [ label="clk" ]; -c19 [ shape=record, label="{{<p16> CLK|<p17> D}|$64\n$dff|{<p18> Q}}" ]; -c13:p12:e -> c19:p17:w [color="black", style="setlinewidth(3)", label=""]; -c14:p12:e -> c13:p9:w [color="black", style="setlinewidth(3)", label=""]; -c15:p12:e -> c13:p10:w [color="black", style="setlinewidth(3)", label=""]; -n4:e -> c14:p9:w [color="black", style="setlinewidth(3)", label=""]; -n5:e -> c14:p10:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> c15:p9:w [color="black", style="setlinewidth(3)", label=""]; -n7:e -> c15:p10:w [color="black", style="setlinewidth(3)", label=""]; -c19:p18:e -> n8:w [color="black", style="setlinewidth(3)", label=""]; -v0:e -> c13:p11:w [color="black", label=""]; -v1:e -> c14:p11:w [color="black", label=""]; -v2:e -> c15:p11:w [color="black", label=""]; -v3:e -> c19:p16:w [color="black", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/primetest.v b/manual/APPNOTE_011_Design_Investigation/primetest.v deleted file mode 100644 index 6cb766b73..000000000 --- a/manual/APPNOTE_011_Design_Investigation/primetest.v +++ /dev/null @@ -1,4 +0,0 @@ -module primetest(p, a, b, ok); -input [15:0] p, a, b; -output ok = p != a*b || a == 1 || b == 1; -endmodule diff --git a/manual/APPNOTE_011_Design_Investigation/splice.dot b/manual/APPNOTE_011_Design_Investigation/splice.dot deleted file mode 100644 index 4657feed1..000000000 --- a/manual/APPNOTE_011_Design_Investigation/splice.dot +++ /dev/null @@ -1,39 +0,0 @@ -digraph "splice_demo" { -rankdir="LR"; -remincross=true; -n1 [ shape=octagon, label="a", color="black", fontcolor="black" ]; -n2 [ shape=octagon, label="b", color="black", fontcolor="black" ]; -n3 [ shape=octagon, label="c", color="black", fontcolor="black" ]; -n4 [ shape=octagon, label="d", color="black", fontcolor="black" ]; -n5 [ shape=octagon, label="e", color="black", fontcolor="black" ]; -n6 [ shape=octagon, label="f", color="black", fontcolor="black" ]; -n7 [ shape=octagon, label="x", color="black", fontcolor="black" ]; -n8 [ shape=octagon, label="y", color="black", fontcolor="black" ]; -c11 [ shape=record, label="{{<p9> A}|$2\n$neg|{<p10> Y}}" ]; -x0 [ shape=record, style=rounded, label="<s1> 1:0 - 3:2 |<s0> 1:0 - 1:0 " ]; -x0:e -> c11:p9:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", style="setlinewidth(3)", label=""]; -x1 [ shape=record, style=rounded, label="<s0> 3:0 - 7:4 " ]; -c11:p10:e -> x1:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", style="setlinewidth(3)", label=""]; -c12 [ shape=record, label="{{<p9> A}|$1\n$not|{<p10> Y}}" ]; -x2 [ shape=record, style=rounded, label="<s1> 1:0 - 3:2 |<s0> 1:0 - 1:0 " ]; -x2:e -> c12:p9:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", style="setlinewidth(3)", label=""]; -x3 [ shape=record, style=rounded, label="<s1> 3:2 - 1:0 |<s0> 1:0 - 3:2 " ]; -c12:p10:e -> x3:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", style="setlinewidth(3)", label=""]; -x4 [ shape=record, style=rounded, label="<s1> 0:0 - 1:1 |<s0> 1:1 - 0:0 " ]; -x5 [ shape=record, style=rounded, label="<s1> 1:0 - 3:2 |<s0> 1:0 - 1:0 " ]; -x6 [ shape=record, style=rounded, label="<s0> 3:0 - 11:8 " ]; -x5:e -> x6:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", style="setlinewidth(3)", label=""]; -n1:e -> x4:s0:w [color="black", style="setlinewidth(3)", label=""]; -n1:e -> x4:s1:w [color="black", style="setlinewidth(3)", label=""]; -n1:e -> x5:s1:w [color="black", style="setlinewidth(3)", label=""]; -n2:e -> x5:s0:w [color="black", style="setlinewidth(3)", label=""]; -n3:e -> x0:s1:w [color="black", style="setlinewidth(3)", label=""]; -n4:e -> x0:s0:w [color="black", style="setlinewidth(3)", label=""]; -n5:e -> x2:s1:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> x2:s0:w [color="black", style="setlinewidth(3)", label=""]; -x4:e -> n7:w [color="black", style="setlinewidth(3)", label=""]; -x1:s0:e -> n8:w [color="black", style="setlinewidth(3)", label=""]; -x3:s0:e -> n8:w [color="black", style="setlinewidth(3)", label=""]; -x3:s1:e -> n8:w [color="black", style="setlinewidth(3)", label=""]; -x6:s0:e -> n8:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/splice.v b/manual/APPNOTE_011_Design_Investigation/splice.v deleted file mode 100644 index 1cf7274c0..000000000 --- a/manual/APPNOTE_011_Design_Investigation/splice.v +++ /dev/null @@ -1,10 +0,0 @@ -module splice_demo(a, b, c, d, e, f, x, y); - -input [1:0] a, b, c, d, e, f; -output [1:0] x = {a[0], a[1]}; - -output [11:0] y; -assign {y[11:4], y[1:0], y[3:2]} = - {a, b, -{c, d}, ~{e, f}}; - -endmodule diff --git a/manual/APPNOTE_011_Design_Investigation/submod.ys b/manual/APPNOTE_011_Design_Investigation/submod.ys deleted file mode 100644 index 29ad61076..000000000 --- a/manual/APPNOTE_011_Design_Investigation/submod.ys +++ /dev/null @@ -1,16 +0,0 @@ -read_verilog memdemo.v -proc; opt; memory; opt - -cd memdemo -select -set outstage y %ci2:+$dff[Q,D] %ci*:-$mux[S]:-$dff -select -set selstage y %ci2:+$dff[Q,D] %ci*:-$dff @outstage %d -select -set scramble mem* %ci2 %ci*:-$dff mem* %d @selstage %d -submod -name scramble @scramble -submod -name outstage @outstage -submod -name selstage @selstage - -cd .. -show -format dot -prefix submod_00 memdemo -show -format dot -prefix submod_01 scramble -show -format dot -prefix submod_02 outstage -show -format dot -prefix submod_03 selstage diff --git a/manual/APPNOTE_011_Design_Investigation/submod_00.dot b/manual/APPNOTE_011_Design_Investigation/submod_00.dot deleted file mode 100644 index 2e55268ee..000000000 --- a/manual/APPNOTE_011_Design_Investigation/submod_00.dot +++ /dev/null @@ -1,45 +0,0 @@ -digraph "memdemo" { -rankdir="LR"; -remincross=true; -n5 [ shape=octagon, label="clk", color="black", fontcolor="black" ]; -n6 [ shape=octagon, label="d", color="black", fontcolor="black" ]; -n7 [ shape=diamond, label="mem[0]", color="black", fontcolor="black" ]; -n8 [ shape=diamond, label="mem[1]", color="black", fontcolor="black" ]; -n9 [ shape=diamond, label="mem[2]", color="black", fontcolor="black" ]; -n10 [ shape=diamond, label="mem[3]", color="black", fontcolor="black" ]; -n11 [ shape=diamond, label="s1", color="black", fontcolor="black" ]; -n12 [ shape=diamond, label="s2", color="black", fontcolor="black" ]; -n13 [ shape=octagon, label="y", color="black", fontcolor="black" ]; -c17 [ shape=record, label="{{<p14> CLK|<p15> D}|$59\n$dff|{<p16> Q}}" ]; -c18 [ shape=record, label="{{<p14> CLK|<p15> D}|$63\n$dff|{<p16> Q}}" ]; -c20 [ shape=record, label="{{<p5> clk|<p7> mem[0]|<p8> mem[1]|<p9> mem[2]|<p10> mem[3]|<p19> n1}|outstage\noutstage|{<p13> y}}" ]; -c21 [ shape=record, label="{{<p5> clk|<p6> d|<p19> n1}|scramble\nscramble|{<p7> mem[0]|<p8> mem[1]|<p9> mem[2]|<p10> mem[3]}}" ]; -c23 [ shape=record, label="{{<p6> d|<p11> s1|<p12> s2}|selstage\nselstage|{<p19> n1|<p22> n2}}" ]; -n1 [ shape=point ]; -c23:p19:e -> n1:w [color="black", style="setlinewidth(3)", label=""]; -n1:e -> c17:p15:w [color="black", style="setlinewidth(3)", label=""]; -n1:e -> c21:p19:w [color="black", style="setlinewidth(3)", label=""]; -c21:p10:e -> n10:w [color="black", style="setlinewidth(3)", label=""]; -n10:e -> c20:p10:w [color="black", style="setlinewidth(3)", label=""]; -c17:p16:e -> n11:w [color="black", style="setlinewidth(3)", label=""]; -n11:e -> c23:p11:w [color="black", style="setlinewidth(3)", label=""]; -c18:p16:e -> n12:w [color="black", style="setlinewidth(3)", label=""]; -n12:e -> c23:p12:w [color="black", style="setlinewidth(3)", label=""]; -c20:p13:e -> n13:w [color="black", style="setlinewidth(3)", label=""]; -n2 [ shape=point ]; -c23:p22:e -> n2:w [color="black", style="setlinewidth(3)", label=""]; -n2:e -> c18:p15:w [color="black", style="setlinewidth(3)", label=""]; -n2:e -> c20:p19:w [color="black", style="setlinewidth(3)", label=""]; -n5:e -> c17:p14:w [color="black", label=""]; -n5:e -> c18:p14:w [color="black", label=""]; -n5:e -> c20:p5:w [color="black", label=""]; -n5:e -> c21:p5:w [color="black", label=""]; -n6:e -> c21:p6:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> c23:p6:w [color="black", style="setlinewidth(3)", label=""]; -c21:p7:e -> n7:w [color="black", style="setlinewidth(3)", label=""]; -n7:e -> c20:p7:w [color="black", style="setlinewidth(3)", label=""]; -c21:p8:e -> n8:w [color="black", style="setlinewidth(3)", label=""]; -n8:e -> c20:p8:w [color="black", style="setlinewidth(3)", label=""]; -c21:p9:e -> n9:w [color="black", style="setlinewidth(3)", label=""]; -n9:e -> c20:p9:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/submod_01.dot b/manual/APPNOTE_011_Design_Investigation/submod_01.dot deleted file mode 100644 index f8f8c008a..000000000 --- a/manual/APPNOTE_011_Design_Investigation/submod_01.dot +++ /dev/null @@ -1,87 +0,0 @@ -digraph "scramble" { -rankdir="LR"; -remincross=true; -n17 [ shape=octagon, label="clk", color="black", fontcolor="black" ]; -n18 [ shape=octagon, label="d", color="black", fontcolor="black" ]; -n19 [ shape=octagon, label="mem[0]", color="black", fontcolor="black" ]; -n20 [ shape=octagon, label="mem[1]", color="black", fontcolor="black" ]; -n21 [ shape=octagon, label="mem[2]", color="black", fontcolor="black" ]; -n22 [ shape=octagon, label="mem[3]", color="black", fontcolor="black" ]; -n23 [ shape=octagon, label="n1", color="black", fontcolor="black" ]; -c27 [ shape=record, label="{{<p24> A|<p25> B}|$28\n$add|{<p26> Y}}" ]; -c28 [ shape=record, label="{{<p24> A|<p25> B}|$31\n$add|{<p26> Y}}" ]; -c29 [ shape=record, label="{{<p24> A|<p25> B}|$34\n$add|{<p26> Y}}" ]; -c30 [ shape=record, label="{{<p24> A|<p25> B}|$37\n$add|{<p26> Y}}" ]; -v0 [ label="1'1" ]; -c31 [ shape=record, label="{{<p24> A|<p25> B}|$145\n$and|{<p26> Y}}" ]; -v1 [ label="1'1" ]; -c32 [ shape=record, label="{{<p24> A|<p25> B}|$175\n$and|{<p26> Y}}" ]; -v2 [ label="1'1" ]; -c33 [ shape=record, label="{{<p24> A|<p25> B}|$205\n$and|{<p26> Y}}" ]; -v3 [ label="1'1" ]; -c34 [ shape=record, label="{{<p24> A|<p25> B}|$235\n$and|{<p26> Y}}" ]; -v4 [ label="2'00" ]; -c35 [ shape=record, label="{{<p24> A|<p25> B}|$143\n$eq|{<p26> Y}}" ]; -v5 [ label="2'01" ]; -c36 [ shape=record, label="{{<p24> A|<p25> B}|$173\n$eq|{<p26> Y}}" ]; -v6 [ label="2'10" ]; -c37 [ shape=record, label="{{<p24> A|<p25> B}|$203\n$eq|{<p26> Y}}" ]; -v7 [ label="2'11" ]; -c38 [ shape=record, label="{{<p24> A|<p25> B}|$233\n$eq|{<p26> Y}}" ]; -c40 [ shape=record, label="{{<p24> A|<p25> B|<p39> S}|$147\n$mux|{<p26> Y}}" ]; -c41 [ shape=record, label="{{<p24> A|<p25> B|<p39> S}|$177\n$mux|{<p26> Y}}" ]; -c42 [ shape=record, label="{{<p24> A|<p25> B|<p39> S}|$207\n$mux|{<p26> Y}}" ]; -c43 [ shape=record, label="{{<p24> A|<p25> B|<p39> S}|$237\n$mux|{<p26> Y}}" ]; -c47 [ shape=record, label="{{<p44> CLK|<p45> D}|$66\n$dff|{<p46> Q}}" ]; -c48 [ shape=record, label="{{<p44> CLK|<p45> D}|$68\n$dff|{<p46> Q}}" ]; -c49 [ shape=record, label="{{<p44> CLK|<p45> D}|$70\n$dff|{<p46> Q}}" ]; -c50 [ shape=record, label="{{<p44> CLK|<p45> D}|$72\n$dff|{<p46> Q}}" ]; -c27:p26:e -> c40:p24:w [color="black", style="setlinewidth(3)", label=""]; -c36:p26:e -> c32:p24:w [color="black", label=""]; -c37:p26:e -> c33:p24:w [color="black", label=""]; -c38:p26:e -> c34:p24:w [color="black", label=""]; -c40:p26:e -> c47:p45:w [color="black", style="setlinewidth(3)", label=""]; -c41:p26:e -> c48:p45:w [color="black", style="setlinewidth(3)", label=""]; -c42:p26:e -> c49:p45:w [color="black", style="setlinewidth(3)", label=""]; -c43:p26:e -> c50:p45:w [color="black", style="setlinewidth(3)", label=""]; -n17:e -> c47:p44:w [color="black", label=""]; -n17:e -> c48:p44:w [color="black", label=""]; -n17:e -> c49:p44:w [color="black", label=""]; -n17:e -> c50:p44:w [color="black", label=""]; -n18:e -> c40:p25:w [color="black", style="setlinewidth(3)", label=""]; -n18:e -> c41:p25:w [color="black", style="setlinewidth(3)", label=""]; -n18:e -> c42:p25:w [color="black", style="setlinewidth(3)", label=""]; -n18:e -> c43:p25:w [color="black", style="setlinewidth(3)", label=""]; -c47:p46:e -> n19:w [color="black", style="setlinewidth(3)", label=""]; -n19:e -> c29:p25:w [color="black", style="setlinewidth(3)", label=""]; -n19:e -> c30:p24:w [color="black", style="setlinewidth(3)", label=""]; -c28:p26:e -> c41:p24:w [color="black", style="setlinewidth(3)", label=""]; -c48:p46:e -> n20:w [color="black", style="setlinewidth(3)", label=""]; -n20:e -> c27:p24:w [color="black", style="setlinewidth(3)", label=""]; -n20:e -> c30:p25:w [color="black", style="setlinewidth(3)", label=""]; -c49:p46:e -> n21:w [color="black", style="setlinewidth(3)", label=""]; -n21:e -> c27:p25:w [color="black", style="setlinewidth(3)", label=""]; -n21:e -> c28:p24:w [color="black", style="setlinewidth(3)", label=""]; -c50:p46:e -> n22:w [color="black", style="setlinewidth(3)", label=""]; -n22:e -> c28:p25:w [color="black", style="setlinewidth(3)", label=""]; -n22:e -> c29:p24:w [color="black", style="setlinewidth(3)", label=""]; -n23:e -> c35:p25:w [color="black", style="setlinewidth(3)", label=""]; -n23:e -> c36:p25:w [color="black", style="setlinewidth(3)", label=""]; -n23:e -> c37:p25:w [color="black", style="setlinewidth(3)", label=""]; -n23:e -> c38:p25:w [color="black", style="setlinewidth(3)", label=""]; -c29:p26:e -> c42:p24:w [color="black", style="setlinewidth(3)", label=""]; -c30:p26:e -> c43:p24:w [color="black", style="setlinewidth(3)", label=""]; -c31:p26:e -> c40:p39:w [color="black", label=""]; -c32:p26:e -> c41:p39:w [color="black", label=""]; -c33:p26:e -> c42:p39:w [color="black", label=""]; -c34:p26:e -> c43:p39:w [color="black", label=""]; -c35:p26:e -> c31:p24:w [color="black", label=""]; -v0:e -> c31:p25:w [color="black", label=""]; -v1:e -> c32:p25:w [color="black", label=""]; -v2:e -> c33:p25:w [color="black", label=""]; -v3:e -> c34:p25:w [color="black", label=""]; -v4:e -> c35:p24:w [color="black", style="setlinewidth(3)", label=""]; -v5:e -> c36:p24:w [color="black", style="setlinewidth(3)", label=""]; -v6:e -> c37:p24:w [color="black", style="setlinewidth(3)", label=""]; -v7:e -> c38:p24:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/submod_02.dot b/manual/APPNOTE_011_Design_Investigation/submod_02.dot deleted file mode 100644 index 1a672c484..000000000 --- a/manual/APPNOTE_011_Design_Investigation/submod_02.dot +++ /dev/null @@ -1,33 +0,0 @@ -digraph "outstage" { -rankdir="LR"; -remincross=true; -n4 [ shape=octagon, label="clk", color="black", fontcolor="black" ]; -n5 [ shape=octagon, label="mem[0]", color="black", fontcolor="black" ]; -n6 [ shape=octagon, label="mem[1]", color="black", fontcolor="black" ]; -n7 [ shape=octagon, label="mem[2]", color="black", fontcolor="black" ]; -n8 [ shape=octagon, label="mem[3]", color="black", fontcolor="black" ]; -n9 [ shape=octagon, label="n1", color="black", fontcolor="black" ]; -n10 [ shape=octagon, label="y", color="black", fontcolor="black" ]; -c15 [ shape=record, label="{{<p11> A|<p12> B|<p13> S}|$110\n$mux|{<p14> Y}}" ]; -x0 [ shape=record, style=rounded, label="<s0> 1:1 - 0:0 " ]; -x0:e -> c15:p13:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c16 [ shape=record, label="{{<p11> A|<p12> B|<p13> S}|$113\n$mux|{<p14> Y}}" ]; -x1 [ shape=record, style=rounded, label="<s0> 0:0 - 0:0 " ]; -x1:e -> c16:p13:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c17 [ shape=record, label="{{<p11> A|<p12> B|<p13> S}|$116\n$mux|{<p14> Y}}" ]; -x2 [ shape=record, style=rounded, label="<s0> 0:0 - 0:0 " ]; -x2:e -> c17:p13:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c21 [ shape=record, label="{{<p18> CLK|<p19> D}|$64\n$dff|{<p20> Q}}" ]; -c15:p14:e -> c21:p19:w [color="black", style="setlinewidth(3)", label=""]; -c21:p20:e -> n10:w [color="black", style="setlinewidth(3)", label=""]; -c16:p14:e -> c15:p11:w [color="black", style="setlinewidth(3)", label=""]; -c17:p14:e -> c15:p12:w [color="black", style="setlinewidth(3)", label=""]; -n4:e -> c21:p18:w [color="black", label=""]; -n5:e -> c16:p11:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> c16:p12:w [color="black", style="setlinewidth(3)", label=""]; -n7:e -> c17:p11:w [color="black", style="setlinewidth(3)", label=""]; -n8:e -> c17:p12:w [color="black", style="setlinewidth(3)", label=""]; -n9:e -> x0:s0:w [color="black", label=""]; -n9:e -> x1:s0:w [color="black", label=""]; -n9:e -> x2:s0:w [color="black", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/submod_03.dot b/manual/APPNOTE_011_Design_Investigation/submod_03.dot deleted file mode 100644 index 0dbbe3baa..000000000 --- a/manual/APPNOTE_011_Design_Investigation/submod_03.dot +++ /dev/null @@ -1,26 +0,0 @@ -digraph "selstage" { -rankdir="LR"; -remincross=true; -n3 [ shape=octagon, label="d", color="black", fontcolor="black" ]; -n4 [ shape=octagon, label="n1", color="black", fontcolor="black" ]; -n5 [ shape=octagon, label="n2", color="black", fontcolor="black" ]; -n6 [ shape=octagon, label="s1", color="black", fontcolor="black" ]; -n7 [ shape=octagon, label="s2", color="black", fontcolor="black" ]; -c10 [ shape=record, label="{{<p8> A}|$39\n$reduce_bool|{<p9> Y}}" ]; -v0 [ label="4'0000" ]; -c13 [ shape=record, label="{{<p8> A|<p11> B|<p12> S}|$40\n$mux|{<p9> Y}}" ]; -x1 [ shape=record, style=rounded, label="<s1> 3:2 - 1:0 |<s0> 1:0 - 1:0 " ]; -c13:p9:e -> x1:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", style="setlinewidth(3)", label=""]; -c14 [ shape=record, label="{{<p8> A|<p11> B}|$38\n$xor|{<p9> Y}}" ]; -x2 [ shape=record, style=rounded, label="<s1> 1:0 - 3:2 |<s0> 1:0 - 1:0 " ]; -x2:e -> c14:p8:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", style="setlinewidth(3)", label=""]; -c10:p9:e -> c13:p12:w [color="black", label=""]; -c14:p9:e -> c13:p11:w [color="black", style="setlinewidth(3)", label=""]; -n3:e -> c10:p8:w [color="black", style="setlinewidth(3)", label=""]; -n3:e -> c14:p11:w [color="black", style="setlinewidth(3)", label=""]; -x1:s0:e -> n4:w [color="black", style="setlinewidth(3)", label=""]; -x1:s1:e -> n5:w [color="black", style="setlinewidth(3)", label=""]; -n6:e -> x2:s1:w [color="black", style="setlinewidth(3)", label=""]; -n7:e -> x2:s0:w [color="black", style="setlinewidth(3)", label=""]; -v0:e -> c13:p8:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/sumprod.v b/manual/APPNOTE_011_Design_Investigation/sumprod.v deleted file mode 100644 index 4091bf0a1..000000000 --- a/manual/APPNOTE_011_Design_Investigation/sumprod.v +++ /dev/null @@ -1,12 +0,0 @@ -module sumprod(a, b, c, sum, prod); - - input [7:0] a, b, c; - output [7:0] sum, prod; - - {* sumstuff *} - assign sum = a + b + c; - {* *} - - assign prod = a * b * c; - -endmodule diff --git a/manual/APPNOTE_011_Design_Investigation/sumprod_00.dot b/manual/APPNOTE_011_Design_Investigation/sumprod_00.dot deleted file mode 100644 index 06522dcc9..000000000 --- a/manual/APPNOTE_011_Design_Investigation/sumprod_00.dot +++ /dev/null @@ -1,18 +0,0 @@ -digraph "sumprod" { -rankdir="LR"; -remincross=true; -v0 [ label="a" ]; -v1 [ label="b" ]; -v2 [ label="$1_Y" ]; -c4 [ shape=record, label="{{<p1> A|<p2> B}|$1\n$add|{<p3> Y}}" ]; -v3 [ label="$1_Y" ]; -v4 [ label="c" ]; -v5 [ label="sum" ]; -c5 [ shape=record, label="{{<p1> A|<p2> B}|$2\n$add|{<p3> Y}}" ]; -v0:e -> c4:p1:w [color="black", style="setlinewidth(3)", label=""]; -v1:e -> c4:p2:w [color="black", style="setlinewidth(3)", label=""]; -c4:p3:e -> v2:w [color="black", style="setlinewidth(3)", label=""]; -v3:e -> c5:p1:w [color="black", style="setlinewidth(3)", label=""]; -v4:e -> c5:p2:w [color="black", style="setlinewidth(3)", label=""]; -c5:p3:e -> v5:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/sumprod_01.dot b/manual/APPNOTE_011_Design_Investigation/sumprod_01.dot deleted file mode 100644 index aefe7a6da..000000000 --- a/manual/APPNOTE_011_Design_Investigation/sumprod_01.dot +++ /dev/null @@ -1,15 +0,0 @@ -digraph "sumprod" { -rankdir="LR"; -remincross=true; -n2 [ shape=octagon, label="a", color="black", fontcolor="black" ]; -n3 [ shape=octagon, label="b", color="black", fontcolor="black" ]; -n4 [ shape=octagon, label="c", color="black", fontcolor="black" ]; -n5 [ shape=octagon, label="sum", color="black", fontcolor="black" ]; -c9 [ shape=record, label="{{<p6> A|<p7> B}|$1\n$add|{<p8> Y}}" ]; -c10 [ shape=record, label="{{<p6> A|<p7> B}|$2\n$add|{<p8> Y}}" ]; -c9:p8:e -> c10:p6:w [color="black", style="setlinewidth(3)", label=""]; -n2:e -> c9:p6:w [color="black", style="setlinewidth(3)", label=""]; -n3:e -> c9:p7:w [color="black", style="setlinewidth(3)", label=""]; -n4:e -> c10:p7:w [color="black", style="setlinewidth(3)", label=""]; -c10:p8:e -> n5:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/sumprod_02.dot b/manual/APPNOTE_011_Design_Investigation/sumprod_02.dot deleted file mode 100644 index 4646c9947..000000000 --- a/manual/APPNOTE_011_Design_Investigation/sumprod_02.dot +++ /dev/null @@ -1,5 +0,0 @@ -digraph "sumprod" { -rankdir="LR"; -remincross=true; -n1 [ shape=octagon, label="prod", color="black", fontcolor="black" ]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/sumprod_03.dot b/manual/APPNOTE_011_Design_Investigation/sumprod_03.dot deleted file mode 100644 index dcfea2b56..000000000 --- a/manual/APPNOTE_011_Design_Investigation/sumprod_03.dot +++ /dev/null @@ -1,11 +0,0 @@ -digraph "sumprod" { -rankdir="LR"; -remincross=true; -n1 [ shape=octagon, label="prod", color="black", fontcolor="black" ]; -v0 [ label="$3_Y" ]; -v1 [ label="c" ]; -c5 [ shape=record, label="{{<p2> A|<p3> B}|$4\n$mul|{<p4> Y}}" ]; -c5:p4:e -> n1:w [color="black", style="setlinewidth(3)", label=""]; -v0:e -> c5:p2:w [color="black", style="setlinewidth(3)", label=""]; -v1:e -> c5:p3:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/sumprod_04.dot b/manual/APPNOTE_011_Design_Investigation/sumprod_04.dot deleted file mode 100644 index e77c41aa2..000000000 --- a/manual/APPNOTE_011_Design_Investigation/sumprod_04.dot +++ /dev/null @@ -1,11 +0,0 @@ -digraph "sumprod" { -rankdir="LR"; -remincross=true; -n2 [ shape=octagon, label="c", color="black", fontcolor="black" ]; -n3 [ shape=octagon, label="prod", color="black", fontcolor="black" ]; -c7 [ shape=record, label="{{<p4> A|<p5> B}|$4\n$mul|{<p6> Y}}" ]; -n1 [ shape=diamond, label="$3_Y" ]; -n1:e -> c7:p4:w [color="black", style="setlinewidth(3)", label=""]; -n2:e -> c7:p5:w [color="black", style="setlinewidth(3)", label=""]; -c7:p6:e -> n3:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_011_Design_Investigation/sumprod_05.dot b/manual/APPNOTE_011_Design_Investigation/sumprod_05.dot deleted file mode 100644 index b54441290..000000000 --- a/manual/APPNOTE_011_Design_Investigation/sumprod_05.dot +++ /dev/null @@ -1,15 +0,0 @@ -digraph "sumprod" { -rankdir="LR"; -remincross=true; -n2 [ shape=octagon, label="c", color="black", fontcolor="black" ]; -n3 [ shape=octagon, label="prod", color="black", fontcolor="black" ]; -v0 [ label="a" ]; -v1 [ label="b" ]; -c7 [ shape=record, label="{{<p4> A|<p5> B}|$3\n$mul|{<p6> Y}}" ]; -c8 [ shape=record, label="{{<p4> A|<p5> B}|$4\n$mul|{<p6> Y}}" ]; -c7:p6:e -> c8:p4:w [color="black", style="setlinewidth(3)", label=""]; -n2:e -> c8:p5:w [color="black", style="setlinewidth(3)", label=""]; -c8:p6:e -> n3:w [color="black", style="setlinewidth(3)", label=""]; -v0:e -> c7:p4:w [color="black", style="setlinewidth(3)", label=""]; -v1:e -> c7:p5:w [color="black", style="setlinewidth(3)", label=""]; -} diff --git a/manual/APPNOTE_012_Verilog_to_BTOR.tex b/manual/APPNOTE_012_Verilog_to_BTOR.tex deleted file mode 100644 index aabdc63c4..000000000 --- a/manual/APPNOTE_012_Verilog_to_BTOR.tex +++ /dev/null @@ -1,435 +0,0 @@ - -% IEEEtran howto: -% http://ftp.univie.ac.at/packages/tex/macros/latex/contrib/IEEEtran/IEEEtran_HOWTO.pdf -\documentclass[9pt,technote,a4paper]{IEEEtran} - -\usepackage[T1]{fontenc} % required for luximono! -\usepackage[scaled=0.8]{luximono} % typewriter font with bold face - -% To install the luximono font files: -% getnonfreefonts-sys --all or -% getnonfreefonts-sys luximono -% -% when there are trouble you might need to: -% - Create /etc/texmf/updmap.d/99local-luximono.cfg -% containing the single line: Map ul9.map -% - Run update-updmap followed by mktexlsr and updmap-sys -% -% This commands must be executed as root with a root environment -% (i.e. run "sudo su" and then execute the commands in the root -% shell, don't just prefix the commands with "sudo"). - -\usepackage[unicode,bookmarks=false]{hyperref} -\usepackage[english]{babel} -\usepackage[utf8]{inputenc} -\usepackage{amssymb} -\usepackage{amsmath} -\usepackage{amsfonts} -\usepackage{units} -\usepackage{nicefrac} -\usepackage{eurosym} -\usepackage{graphicx} -\usepackage{verbatim} -\usepackage{algpseudocode} -\usepackage{scalefnt} -\usepackage{xspace} -\usepackage{color} -\usepackage{colortbl} -\usepackage{multirow} -\usepackage{hhline} -\usepackage{listings} -\usepackage{float} - -\usepackage{tikz} -\usetikzlibrary{calc} -\usetikzlibrary{arrows} -\usetikzlibrary{scopes} -\usetikzlibrary{through} -\usetikzlibrary{shapes.geometric} - -\lstset{basicstyle=\ttfamily,frame=trBL,xleftmargin=2em,xrightmargin=1em,numbers=left} - -\begin{document} - -\title{Yosys Application Note 012: \\ Converting Verilog to BTOR} -\author{Ahmed Irfan and Claire Xenia Wolf \\ April 2015} -\maketitle - -\begin{abstract} -Verilog-2005 is a powerful Hardware Description Language (HDL) that -can be used to easily create complex designs from small HDL code. -BTOR~\cite{btor} is a bit-precise word-level format for model -checking. It is a simple format and easy to parse. It allows to model -the model checking problem over the theory of bit-vectors with -one-dimensional arrays, thus enabling to model Verilog designs with -registers and memories. Yosys~\cite{yosys} is an Open-Source Verilog -synthesis tool that can be used to convert Verilog designs with simple -assertions to BTOR format. - -\end{abstract} - -\section{Installation} - -Yosys written in C++ (using features from C++11) and is tested on -modern Linux. It should compile fine on most UNIX systems with a -C++11 compiler. The README file contains useful information on -building Yosys and its prerequisites. - -Yosys is a large and feature-rich program with some dependencies. For -this work, we may deactivate other extra features such as {\tt TCL} -and {\tt ABC} support in the {\tt Makefile}. - -\bigskip - -This Application Note is based on GIT Rev. {\tt 082550f} from -2015-04-04 of Yosys~\cite{yosys}. - -\section{Quick Start} - -We assume that the Verilog design is synthesizable and we also assume -that the design does not have multi-dimensional memories. As BTOR -implicitly initializes registers to zero value and memories stay -uninitialized, we assume that the Verilog design does -not contain initial blocks. For more details about the BTOR format, -please refer to~\cite{btor}. - -We provide a shell script {\tt verilog2btor.sh} which can be used to -convert a Verilog design to BTOR. The script can be found in the -{\tt backends/btor} directory. The following example shows its usage: - -\begin{figure}[H] -\begin{lstlisting}[language=sh,numbers=none] -verilog2btor.sh fsm.v fsm.btor test -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{Using verilog2btor script} -\end{figure} - -The script {\tt verilog2btor.sh} takes three parameters. In the above -example, the first parameter {\tt fsm.v} is the input design, the second -parameter {\tt fsm.btor} is the file name of BTOR output, and the third -parameter {\tt test} is the name of top module in the design. - -To specify the properties (that need to be checked), we have two -options: -\begin{itemize} -\item We can use the Verilog {\tt assert} statement in the procedural block - or module body of the Verilog design, as shown in - Listing~\ref{specifying_property_assert}. This is the preferred option. -\item We can use a single-bit output wire, whose name starts with - {\tt safety}. The value of this output wire needs to be driven low - when the property is met, i.e. the solver will try to find a model - that makes the safety pin go high. This is demonstrated in - Listing~\ref{specifying_property_output}. -\end{itemize} - -\begin{figure}[H] -\begin{lstlisting}[language=Verilog,numbers=none] -module test(input clk, input rst, output y); - - reg [2:0] state; - - always @(posedge clk) begin - if (rst || state == 3) begin - state <= 0; - end else begin - assert(state < 3); - state <= state + 1; - end - end - - assign y = state[2]; - - assert property (y !== 1'b1); - -endmodule -\end{lstlisting} -\renewcommand{\figurename}{Listing} -\caption{Specifying property in Verilog design with {\tt assert}} -\label{specifying_property_assert} -\end{figure} - -\begin{figure}[H] -\begin{lstlisting}[language=Verilog,numbers=none] -module test(input clk, input rst, - output y, output safety1); - - reg [2:0] state; - - always @(posedge clk) begin - if (rst || state == 3) - state <= 0; - else - state <= state + 1; - end - - assign y = state[2]; - - assign safety1 = !(y !== 1'b1); - -endmodule -\end{lstlisting} -\renewcommand{\figurename}{Listing} -\caption{Specifying property in Verilog design with output wire} -\label{specifying_property_output} -\end{figure} - -We can run Boolector~\cite{boolector}~$1.4.1$\footnote{ -Newer version of Boolector do not support sequential models. -Boolector 1.4.1 can be built with picosat-951. Newer versions -of picosat have an incompatible API.} on the generated BTOR -file: - -\begin{figure}[H] -\begin{lstlisting}[language=sh,numbers=none] -$ boolector fsm.btor -unsat -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{Running boolector on BTOR file} -\end{figure} - -We can also use nuXmv~\cite{nuxmv}, but on BTOR designs it does not -support memories yet. With the next release of nuXmv, we will be also -able to verify designs with memories. - -\section{Detailed Flow} - -Yosys is able to synthesize Verilog designs up to the gate level. -We are interested in keeping registers and memories when synthesizing -the design. For this purpose, we describe a customized Yosys synthesis -flow, that is also provided by the {\tt verilog2btor.sh} script. -Listing~\ref{btor_script_memory} shows the Yosys commands that are -executed by {\tt verilog2btor.sh}. - -\begin{figure}[H] -\begin{lstlisting}[language=sh] -read_verilog -sv $1; -hierarchy -top $3; hierarchy -libdir $DIR; -hierarchy -check; -proc; opt; -opt_expr -mux_undef; opt; -rename -hide;;; -splice; opt; -memory_dff -wr_only; memory_collect;; -flatten;; -memory_unpack; -splitnets -driver; -setundef -zero -undriven; -opt;;; -write_btor $2; -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{Synthesis Flow for BTOR with memories} -\label{btor_script_memory} -\end{figure} - -Here is short description of what is happening in the script line by -line: - -\begin{enumerate} -\item Reading the input file. -\item Setting the top module in the hierarchy and trying to read - automatically the files which are given as {\tt include} in the file - read in first line. -\item Checking the design hierarchy. -\item Converting processes to multiplexers (muxs) and flip-flops. -\item Removing undef signals from muxs. -\item Hiding all signal names that are not used as module ports. -\item Explicit type conversion, by introducing slice and concat cells - in the circuit. -\item Converting write memories to synchronous memories, and - collecting the memories to multi-port memories. -\item Flattening the design to get only one module. -\item Separating read and write memories. -\item Splitting the signals that are partially assigned -\item Setting undef to zero value. -\item Final optimization pass. -\item Writing BTOR file. -\end{enumerate} - -For detailed description of the commands mentioned above, please refer -to the Yosys documentation, or run {\tt yosys -h \it command\_name}. - -The script presented earlier can be easily modified to have a BTOR -file that does not contain memories. This is done by removing the line -number~8 and 10, and introduces a new command {\tt memory} at line -number~8. Listing~\ref{btor_script_without_memory} shows the -modified Yosys script file: - -\begin{figure}[H] -\begin{lstlisting}[language=sh,numbers=none] -read_verilog -sv $1; -hierarchy -top $3; hierarchy -libdir $DIR; -hierarchy -check; -proc; opt; -opt_expr -mux_undef; opt; -rename -hide;;; -splice; opt; -memory;; -flatten;; -splitnets -driver; -setundef -zero -undriven; -opt;;; -write_btor $2; -\end{lstlisting} - \renewcommand{\figurename}{Listing} -\caption{Synthesis Flow for BTOR without memories} -\label{btor_script_without_memory} -\end{figure} - -\section{Example} - -Here is an example Verilog design that we want to convert to BTOR: - -\begin{figure}[H] -\begin{lstlisting}[language=Verilog,numbers=none] -module array(input clk); - - reg [7:0] counter; - reg [7:0] mem [7:0]; - - always @(posedge clk) begin - counter <= counter + 8'd1; - mem[counter] <= counter; - end - - assert property (!(counter > 8'd0) || - mem[counter - 8'd1] == counter - 8'd1); - -endmodule -\end{lstlisting} -\renewcommand{\figurename}{Listing} -\caption{Example - Verilog Design} -\label{example_verilog} -\end{figure} - -The generated BTOR file that contain memories, using the script shown -in Listing~\ref{btor_script_memory}: -\begin{figure}[H] -\begin{lstlisting}[numbers=none] -1 var 1 clk -2 array 8 3 -3 var 8 $auto$rename.cc:150:execute$20 -4 const 8 00000001 -5 sub 8 3 4 -6 slice 3 5 2 0 -7 read 8 2 6 -8 slice 3 3 2 0 -9 add 8 3 4 -10 const 8 00000000 -11 ugt 1 3 10 -12 not 1 11 -13 const 8 11111111 -14 slice 1 13 0 0 -15 one 1 -16 eq 1 1 15 -17 and 1 16 14 -18 write 8 3 2 8 3 -19 acond 8 3 17 18 2 -20 anext 8 3 2 19 -21 eq 1 7 5 -22 or 1 12 21 -23 const 1 1 -24 one 1 -25 eq 1 23 24 -26 cond 1 25 22 24 -27 root 1 -26 -28 cond 8 1 9 3 -29 next 8 3 28 -\end{lstlisting} -\renewcommand{\figurename}{Listing} -\caption{Example - Converted BTOR with memory} -\label{example_btor} -\end{figure} - -And the BTOR file obtained by the script shown in -Listing~\ref{btor_script_without_memory}, which expands the memory -into individual elements: -\begin{figure}[H] -\begin{lstlisting}[numbers=none,escapechar=@] -1 var 1 clk -2 var 8 mem[0] -3 var 8 $auto$rename.cc:150:execute$20 -4 slice 3 3 2 0 -5 slice 1 4 0 0 -6 not 1 5 -7 slice 1 4 1 1 -8 not 1 7 -9 slice 1 4 2 2 -10 not 1 9 -11 and 1 8 10 -12 and 1 6 11 -13 cond 8 12 3 2 -14 cond 8 1 13 2 -15 next 8 2 14 -16 const 8 00000001 -17 add 8 3 16 -18 const 8 00000000 -19 ugt 1 3 18 -20 not 1 19 -21 var 8 mem[2] -22 and 1 7 10 -23 and 1 6 22 -24 cond 8 23 3 21 -25 cond 8 1 24 21 -26 next 8 21 25 -27 sub 8 3 16 - -@\vbox to 0pt{\vss\vdots\vskip3pt}@ -54 cond 1 53 50 52 -55 root 1 -54 - -@\vbox to 0pt{\vss\vdots\vskip3pt}@ -77 cond 8 76 3 44 -78 cond 8 1 77 44 -79 next 8 44 78 -\end{lstlisting} -\renewcommand{\figurename}{Listing} -\caption{Example - Converted BTOR without memory} -\label{example_btor} -\end{figure} - -\section{Limitations} - -BTOR does not support initialization of memories and registers, i.e. they are -implicitly initialized to value zero, so the initial block for -memories need to be removed when converting to BTOR. It should -also be kept in consideration that BTOR does not support the {\tt x} or {\tt z} -values of Verilog. - -Another thing to bear in mind is that Yosys will convert multi-dimensional -memories to one-dimensional memories and address decoders. Therefore -out-of-bounds memory accesses can yield unexpected results. - -\section{Conclusion} - -Using the described flow, we can use Yosys to generate word-level -verification benchmarks with or without memories from Verilog designs. - -\begin{thebibliography}{9} - -\bibitem{yosys} -Claire Xenia Wolf. The Yosys Open SYnthesis Suite. \\ -\url{https://yosyshq.net/yosys/} - -\bibitem{boolector} -Robert Brummayer and Armin Biere, Boolector: An Efficient SMT Solver for Bit-Vectors and Arrays\\ -\url{http://fmv.jku.at/boolector/} - -\bibitem{btor} -Robert Brummayer and Armin Biere and Florian Lonsing, BTOR: -Bit-Precise Modelling of Word-Level Problems for Model Checking\\ -\url{http://fmv.jku.at/papers/BrummayerBiereLonsing-BPR08.pdf} - -\bibitem{nuxmv} -Roberto Cavada and Alessandro Cimatti and Michele Dorigatti and -Alberto Griggio and Alessandro Mariotti and Andrea Micheli and Sergio -Mover and Marco Roveri and Stefano Tonetta, The nuXmv Symbolic Model -Checker\\ -\url{https://es-static.fbk.eu/tools/nuxmv/index.php} - -\end{thebibliography} - - -\end{document} diff --git a/manual/CHAPTER_Appnotes.tex b/manual/CHAPTER_Appnotes.tex deleted file mode 100644 index e0d093290..000000000 --- a/manual/CHAPTER_Appnotes.tex +++ /dev/null @@ -1,29 +0,0 @@ - -\chapter{Application Notes} -\label{chapter:appnotes} - -% \begin{fixme} -% This appendix will cover some typical use-cases of Yosys in the form of application notes. -% \end{fixme} -% -% \section{Synthesizing using a Cell Library in Liberty Format} -% \section{Reverse Engineering the MOS6502 from an NMOS Transistor Netlist} -% \section{Reconfigurable Coarse-Grain Synthesis using Intersynth} - -This appendix contains copies of the Yosys application notes. - -\begin{itemize} -\item Yosys AppNote 010: Converting Verilog to BLIF \dotfill Page \pageref{app:010} \hskip2cm\null -\item Yosys AppNote 011: Interactive Design Investigation \dotfill Page \pageref{app:011} \hskip2cm\null -\item Yosys AppNote 012: Converting Verilog to BTOR \dotfill Page \pageref{app:012} \hskip2cm\null -\end{itemize} - -\eject\label{app:010} -\includepdf[pages=-,pagecommand=\thispagestyle{plain}]{APPNOTE_010_Verilog_to_BLIF.pdf} - -\eject\label{app:011} -\includepdf[pages=-,pagecommand=\thispagestyle{plain}]{APPNOTE_011_Design_Investigation.pdf} - -\eject\label{app:012} -\includepdf[pages=-,pagecommand=\thispagestyle{plain}]{APPNOTE_012_Verilog_to_BTOR.pdf} - diff --git a/manual/CHAPTER_Approach.tex b/manual/CHAPTER_Approach.tex deleted file mode 100644 index 4b170ee0a..000000000 --- a/manual/CHAPTER_Approach.tex +++ /dev/null @@ -1,145 +0,0 @@ - -\chapter{Approach} -\label{chapter:approach} - -Yosys is a tool for synthesising (behavioural) Verilog HDL code to target architecture netlists. Yosys aims at a wide -range of application domains and thus must be flexible and easy to adapt to new tasks. This chapter covers the general -approach followed in the effort to implement this tool. - -\section{Data- and Control-Flow} - -The data- and control-flow of a typical synthesis tool is very similar to the data- and control-flow of a typical -compiler: different subsystems are called in a predetermined order, each consuming the data generated by the -last subsystem and generating the data for the next subsystem (see Fig.~\ref{fig:approach_flow}). - -\begin{figure}[b] - \hfil - \begin{tikzpicture} - \path (-1.5,3) coordinate (cursor); - \draw[-latex] ($ (cursor) + (0,-1.5) $) -- ++(1,0); - \draw[fill=orange!10] ($ (cursor) + (1,-3) $) rectangle node[rotate=90] {Frontend} ++(1,3) coordinate (cursor); - \draw[-latex] ($ (cursor) + (0,-1.5) $) -- ++(1,0); - \draw[fill=green!10] ($ (cursor) + (1,-3) $) rectangle node[rotate=90] {Pass} ++(1,3) coordinate (cursor); - \draw[-latex] ($ (cursor) + (0,-1.5) $) -- ++(1,0); - \draw[fill=green!10] ($ (cursor) + (1,-3) $) rectangle node[rotate=90] {Pass} ++(1,3) coordinate (cursor); - \draw[-latex] ($ (cursor) + (0,-1.5) $) -- ++(1,0); - \draw[fill=green!10] ($ (cursor) + (1,-3) $) rectangle node[rotate=90] {Pass} ++(1,3) coordinate (cursor); - \draw[-latex] ($ (cursor) + (0,-1.5) $) -- ++(1,0); - \draw[fill=orange!10] ($ (cursor) + (1,-3) $) rectangle node[rotate=90] {Backend} ++(1,3) coordinate (cursor); - \draw[-latex] ($ (cursor) + (0,-1.5) $) -- ++(1,0); - - \path (-3,-0.5) coordinate (cursor); - \draw (cursor) -- node[below] {HDL} ++(3,0) coordinate (cursor); - \draw[|-|] (cursor) -- node[below] {Internal Format(s)} ++(8,0) coordinate (cursor); - \draw (cursor) -- node[below] {Netlist} ++(3,0); - - \path (-3,3.5) coordinate (cursor); - \draw[-] (cursor) -- node[above] {High-Level} ++(3,0) coordinate (cursor); - \draw[-] (cursor) -- ++(8,0) coordinate (cursor); - \draw[->] (cursor) -- node[above] {Low-Level} ++(3,0); - - \end{tikzpicture} - \caption{General data- and control-flow of a synthesis tool} - \label{fig:approach_flow} -\end{figure} - -The first subsystem to be called is usually called a {\it frontend}. It does not process the data generated by -another subsystem but instead reads the user input---in the case of a HDL synthesis tool, the behavioural -HDL code. - -The subsystems that consume data from previous subsystems and produce data for the next subsystems (usually in the -same or a similar format) are called {\it passes}. - -The last subsystem that is executed transforms the data generated by the last pass into a suitable output -format and writes it to a disk file. This subsystem is usually called the {\it backend}. - -In Yosys all frontends, passes and backends are directly available as commands in the synthesis script. Thus -the user can easily create a custom synthesis flow just by calling passes in the right order in a synthesis -script. - -\section{Internal Formats in Yosys} - -Yosys uses two different internal formats. The first is used to store an abstract syntax tree (AST) of a Verilog -input file. This format is simply called {\it AST} and is generated by the Verilog Frontend. This data structure -is consumed by a subsystem called {\it AST Frontend}\footnote{In Yosys the term {\it pass} is only used to -refer to commands that operate on the RTLIL data structure.}. This AST Frontend then generates a design in Yosys' -main internal format, the Register-Transfer-Level-Intermediate-Language (RTLIL) representation. It does that -by first performing a number of simplifications within the AST representation and then generating RTLIL from -the simplified AST data structure. - -The RTLIL representation is used by all passes as input and outputs. This has the following advantages over -using different representational formats between different passes: - -\begin{itemize} -\item The passes can be rearranged in a different order and passes can be removed or inserted. -\item Passes can simply pass-thru the parts of the design they don't change without the need - to convert between formats. In fact Yosys passes output the same data structure they received - as input and performs all changes in place. -\item All passes use the same interface, thus reducing the effort required to understand a pass - when reading the Yosys source code, e.g.~when adding additional features. -\end{itemize} - -The RTLIL representation is basically a netlist representation with the following additional features: - -\begin{itemize} -\item An internal cell library with fixed-function cells to represent RTL datapath and register cells as well -as logical gate-level cells (single-bit gates and registers). -\item Support for multi-bit values that can use individual bits from wires as well as constant bits to -represent coarse-grain netlists. -\item Support for basic behavioural constructs (if-then-else structures and multi-case switches with -a sensitivity list for updating the outputs). -\item Support for multi-port memories. -\end{itemize} - -The use of RTLIL also has the disadvantage of having a very powerful format -between all passes, even when doing gate-level synthesis where the more -advanced features are not needed. In order to reduce complexity for passes that -operate on a low-level representation, these passes check the features used in -the input RTLIL and fail to run when unsupported high-level constructs are -used. In such cases a pass that transforms the higher-level constructs to -lower-level constructs must be called from the synthesis script first. - -\section{Typical Use Case} -\label{sec:typusecase} - -The following example script may be used in a synthesis flow to convert the behavioural Verilog code -from the input file {\tt design.v} to a gate-level netlist {\tt synth.v} using the cell library -described by the Liberty file \citeweblink{LibertyFormat} {\tt cells.lib}: - -\begin{lstlisting}[language=sh,numbers=left,frame=single] -# read input file to internal representation -read_verilog design.v - -# convert high-level behavioral parts ("processes") to d-type flip-flops and muxes -proc - -# perform some simple optimizations -opt - -# convert high-level memory constructs to d-type flip-flops and multiplexers -memory - -# perform some simple optimizations -opt - -# convert design to (logical) gate-level netlists -techmap - -# perform some simple optimizations -opt - -# map internal register types to the ones from the cell library -dfflibmap -liberty cells.lib - -# use ABC to map remaining logic to cells from the cell library -abc -liberty cells.lib - -# cleanup -opt - -# write results to output file -write_verilog synth.v -\end{lstlisting} - -A detailed description of the commands available in Yosys can be found in App.~\ref{commandref}. - diff --git a/manual/CHAPTER_Auxlibs.tex b/manual/CHAPTER_Auxlibs.tex deleted file mode 100644 index b3041078f..000000000 --- a/manual/CHAPTER_Auxlibs.tex +++ /dev/null @@ -1,35 +0,0 @@ - -\chapter{Auxiliary Libraries} - -The Yosys source distribution contains some auxiliary libraries that are bundled -with Yosys. - -\section{SHA1} - -The files in {\tt libs/sha1/} provide a public domain SHA1 implementation written -by Steve Reid, Bruce Guenter, and Volker Grabsch. It is used for generating -unique names when specializing parameterized modules. - -\section{BigInt} - -The files in {\tt libs/bigint/} provide a library for performing arithmetic with -arbitrary length integers. It is written by Matt McCutchen \citeweblink{bigint}. - -The BigInt library is used for evaluating constant expressions, e.g.~using the {\tt -ConstEval} class provided in {\tt kernel/consteval.h}. - -\section{SubCircuit} -\label{sec:SubCircuit} - -The files in {\tt libs/subcircuit} provide a library for solving the subcircuit -isomorphism problem. It is written by C. Wolf and based on the Ullmann -Subgraph Isomorphism Algorithm \cite{UllmannSubgraphIsomorphism}. It is used by -the {\tt extract} pass (see {\tt help extract} or Sec.~\ref{cmd:extract}). - -\section{ezSAT} - -The files in {\tt libs/ezsat} provide a library for simplifying generating CNF -formulas for SAT solvers. It also contains bindings of MiniSAT. The ezSAT -library is written by C. Wolf. It is used by the {\tt sat} pass (see -{\tt help sat} or Sec.~\ref{cmd:sat}). - diff --git a/manual/CHAPTER_Auxprogs.tex b/manual/CHAPTER_Auxprogs.tex deleted file mode 100644 index f09b18f76..000000000 --- a/manual/CHAPTER_Auxprogs.tex +++ /dev/null @@ -1,26 +0,0 @@ - -\chapter{Auxiliary Programs} - -Besides the main {\tt yosys} executable, the Yosys distribution contains a set -of additional helper programs. - -\section{yosys-config} - -The {\tt yosys-config} tool (an auto-generated shell-script) can be used to -query compiler options and other information needed for building loadable -modules for Yosys. FIXME: See Sec.~\ref{chapter:prog} for details. - -\section{yosys-filterlib} -\label{sec:filterlib} - -The {\tt yosys-filterlib} tool is a small utility that can be used to strip -or extract information from a Liberty file. See Sec.~\ref{sec:techmap_extern} -for details. - -\section{yosys-abc} - -This is a fork of ABC \citeweblink{ABC} with a small set of custom modifications -that have not yet been accepted upstream. Not all versions of Yosys work with -all versions of ABC. So Yosys comes with its own yosys-abc to avoid -compatibility issues between the two. - diff --git a/manual/CHAPTER_Basics.tex b/manual/CHAPTER_Basics.tex deleted file mode 100644 index 5c60b7305..000000000 --- a/manual/CHAPTER_Basics.tex +++ /dev/null @@ -1,839 +0,0 @@ - -\chapter{Basic Principles} -\label{chapter:basics} - -This chapter contains a short introduction to the basic principles of digital -circuit synthesis. - -\section{Levels of Abstraction} - -Digital circuits can be represented at different levels of abstraction. -During the design process a circuit is usually first specified using a higher -level abstraction. Implementation can then be understood as finding a -functionally equivalent representation at a lower abstraction level. When -this is done automatically using software, the term {\it synthesis} is used. - -So synthesis is the automatic conversion of a high-level representation of a -circuit to a functionally equivalent low-level representation of a circuit. -Figure~\ref{fig:Basics_abstractions} lists the different levels of abstraction -and how they relate to different kinds of synthesis. - -\begin{figure}[b!] - \hfil - \begin{tikzpicture} - \tikzstyle{lvl} = [draw, fill=green!10, rectangle, minimum height=2em, minimum width=15em] - \node[lvl] (sys) {System Level}; - \node[lvl] (hl) [below of=sys] {High Level}; - \node[lvl] (beh) [below of=hl] {Behavioral Level}; - \node[lvl] (rtl) [below of=beh] {Register-Transfer Level (RTL)}; - \node[lvl] (lg) [below of=rtl] {Logical Gate Level}; - \node[lvl] (pg) [below of=lg] {Physical Gate Level}; - \node[lvl] (sw) [below of=pg] {Switch Level}; - - \draw[dotted] (sys.east) -- ++(1,0) coordinate (sysx); - \draw[dotted] (hl.east) -- ++(1,0) coordinate (hlx); - \draw[dotted] (beh.east) -- ++(1,0) coordinate (behx); - \draw[dotted] (rtl.east) -- ++(1,0) coordinate (rtlx); - \draw[dotted] (lg.east) -- ++(1,0) coordinate (lgx); - \draw[dotted] (pg.east) -- ++(1,0) coordinate (pgx); - \draw[dotted] (sw.east) -- ++(1,0) coordinate (swx); - - \draw[gray,|->] (sysx) -- node[right] {System Design} (hlx); - \draw[|->|] (hlx) -- node[right] {High Level Synthesis (HLS)} (behx); - \draw[->|] (behx) -- node[right] {Behavioral Synthesis} (rtlx); - \draw[->|] (rtlx) -- node[right] {RTL Synthesis} (lgx); - \draw[->|] (lgx) -- node[right] {Logic Synthesis} (pgx); - \draw[gray,->|] (pgx) -- node[right] {Cell Library} (swx); - - \draw[dotted] (behx) -- ++(5,0) coordinate (a); - \draw[dotted] (pgx) -- ++(5,0) coordinate (b); - \draw[|->|] (a) -- node[right] {Yosys} (b); - \end{tikzpicture} - \caption{Different levels of abstraction and synthesis.} - \label{fig:Basics_abstractions} -\end{figure} - -Regardless of the way a lower level representation of a circuit is -obtained (synthesis or manual design), the lower level representation is usually -verified by comparing simulation results of the lower level and the higher level -representation \footnote{In recent years formal equivalence -checking also became an important verification method for validating RTL and -lower abstraction representation of the design.}. -Therefore even if no synthesis is used, there must still be a simulatable -representation of the circuit in all levels to allow for verification of the -design. - -Note: The exact meaning of terminology such as ``High-Level'' is of course not -fixed over time. For example the HDL ``ABEL'' was first introduced in 1985 as ``A High-Level -Design Language for Programmable Logic Devices'' \cite{ABEL}, but would not -be considered a ``High-Level Language'' today. - -\subsection{System Level} - -The System Level abstraction of a system only looks at its biggest building -blocks like CPUs and computing cores. At this level the circuit is usually described -using traditional programming languages like C/C++ or Matlab. Sometimes special -software libraries are used that are aimed at simulation circuits on the system -level, such as SystemC. - -Usually no synthesis tools are used to automatically transform a system level -representation of a circuit to a lower-level representation. But system level -design tools exist that can be used to connect system level building blocks. - -The IEEE 1685-2009 standard defines the IP-XACT file format that can be used to -represent designs on the system level and building blocks that can be used in -such system level designs. \cite{IP-XACT} - -\subsection{High Level} - -The high-level abstraction of a system (sometimes referred to as {\it -algorithmic} level) is also often represented using traditional programming -languages, but with a reduced feature set. For example when representing a -design at the high level abstraction in C, pointers can only be used to mimic -concepts that can be found in hardware, such as memory interfaces. Full -featured dynamic memory management is not allowed as it has no corresponding -concept in digital circuits. - -Tools exist to synthesize high level code (usually in the form of C/C++/SystemC -code with additional metadata) to behavioural HDL code (usually in the form of -Verilog or VHDL code). Aside from the many commercial tools for high level synthesis -there are also a number of FOSS tools for high level synthesis -\citeweblink{C_to_Verilog} \citeweblink{LegUp}. - -\subsection{Behavioural Level} - -At the behavioural abstraction level a language aimed at hardware description such -as Verilog or VHDL is used to describe the circuit, but so-called {\it behavioural -modelling} is used in at least part of the circuit description. In behavioural -modelling there must be a language feature that allows for imperative programming to be used to -describe data paths and registers. This is the {\tt always}-block in Verilog and -the {\tt process}-block in VHDL. - -In behavioural modelling, code fragments are provided together with a {\it -sensitivity list}; a list of signals and conditions. In simulation, the code -fragment is executed whenever a signal in the sensitivity list changes its -value or a condition in the sensitivity list is triggered. A synthesis tool -must be able to transfer this representation into an appropriate datapath followed -by the appropriate types of register. - -For example consider the following Verilog code fragment: - -\begin{lstlisting}[numbers=left,frame=single,language=Verilog] -always @(posedge clk) - y <= a + b; -\end{lstlisting} - -In simulation the statement \lstinline[language=Verilog]{y <= a + b} is executed whenever -a positive edge on the signal \lstinline[language=Verilog]{clk} is detected. The synthesis -result however will contain an adder that calculates the sum \lstinline[language=Verilog]{a + b} -all the time, followed by a d-type flip-flop with the adder output on its D-input and the -signal \lstinline[language=Verilog]{y} on its Q-output. - -Usually the imperative code fragments used in behavioural modelling can contain -statements for conditional execution (\lstinline[language=Verilog]{if}- and -\lstinline[language=Verilog]{case}-statements in Verilog) as well as loops, -as long as those loops can be completely unrolled. - -Interestingly there seems to be no other FOSS Tool that is capable of -performing Verilog or VHDL behavioural syntheses besides Yosys (see -App.~\ref{chapter:sota}). - -\subsection{Register-Transfer Level (RTL)} - -On the Register-Transfer Level the design is represented by combinatorial data -paths and registers (usually d-type flip flops). The following Verilog code fragment -is equivalent to the previous Verilog example, but is in RTL representation: - -\begin{lstlisting}[numbers=left,frame=single,language=Verilog] -assign tmp = a + b; // combinatorial data path - -always @(posedge clk) // register - y <= tmp; -\end{lstlisting} - -A design in RTL representation is usually stored using HDLs like Verilog and VHDL. But only -a very limited subset of features is used, namely minimalistic {\tt always}-blocks (Verilog) -or {\tt process}-blocks (VHDL) that model the register type used and unconditional assignments -for the datapath logic. The use of HDLs on this level simplifies simulation as no additional -tools are required to simulate a design in RTL representation. - -Many optimizations and analyses can be performed best at the RTL level. Examples include FSM -detection and optimization, identification of memories or other larger building blocks -and identification of shareable resources. - -Note that RTL is the first abstraction level in which the circuit is represented as a -graph of circuit elements (registers and combinatorial cells) and signals. Such a graph, -when encoded as list of cells and connections, is called a netlist. - -RTL synthesis is easy as each circuit node element in the netlist can simply be replaced -with an equivalent gate-level circuit. However, usually the term {\it RTL synthesis} does -not only refer to synthesizing an RTL netlist to a gate level netlist but also to performing -a number of highly sophisticated optimizations within the RTL representation, such as -the examples listed above. - -A number of FOSS tools exist that can perform isolated tasks within the domain of RTL -synthesis steps. But there seems to be no FOSS tool that covers a wide range of RTL -synthesis operations. - -\subsection{Logical Gate Level} - -At the logical gate level the design is represented by a netlist that uses only -cells from a small number of single-bit cells, such as basic logic gates (AND, -OR, NOT, XOR, etc.) and registers (usually D-Type Flip-flops). - -A number of netlist formats exists that can be used on this level, e.g.~the Electronic Design -Interchange Format (EDIF), but for ease of simulation often a HDL netlist is used. The latter -is a HDL file (Verilog or VHDL) that only uses the most basic language constructs for instantiation -and connecting of cells. - -There are two challenges in logic synthesis: First finding opportunities for optimizations -within the gate level netlist and second the optimal (or at least good) mapping of the logic -gate netlist to an equivalent netlist of physically available gate types. - -The simplest approach to logic synthesis is {\it two-level logic synthesis}, where a logic function -is converted into a sum-of-products representation, e.g.~using a Karnaugh map. -This is a simple approach, but has exponential worst-case effort and cannot make efficient use of -physical gates other than AND/NAND-, OR/NOR- and NOT-Gates. - -Therefore modern logic synthesis tools utilize much more complicated {\it multi-level logic -synthesis} algorithms \cite{MultiLevelLogicSynth}. Most of these algorithms convert the -logic function to a Binary-Decision-Diagram (BDD) or And-Inverter-Graph (AIG) and work from that -representation. The former has the advantage that it has a unique normalized form. The latter has -much better worst case performance and is therefore better suited for the synthesis of large -logic functions. - -Good FOSS tools exists for multi-level logic synthesis \citeweblink{ABC} -\citeweblink{AIGER} \citeweblink{MVSIS}. - -Yosys contains basic logic synthesis functionality but can also use ABC -\citeweblink{ABC} for the logic synthesis step. Using ABC is recommended. - -\subsection{Physical Gate Level} - -On the physical gate level only gates are used that are physically available on -the target architecture. In some cases this may only be NAND, NOR and NOT gates as well as -D-Type registers. In other cases this might include cells that are more complex than the cells -used at the logical gate level (e.g.~complete half-adders). In the case of an FPGA-based -design the physical gate level representation is a netlist of LUTs with optional output -registers, as these are the basic building blocks of FPGA logic cells. - -For the synthesis tool chain this abstraction is usually the lowest level. In -case of an ASIC-based design the cell library might contain further information on -how the physical cells map to individual switches (transistors). - -\subsection{Switch Level} - -A switch level representation of a circuit is a netlist utilizing single transistors as cells. -Switch level modelling is possible in Verilog and VHDL, but is seldom used in modern designs, -as in modern digital ASIC or FPGA flows the physical gates are considered the atomic build blocks -of the logic circuit. - -\subsection{Yosys} - -Yosys is a Verilog HDL synthesis tool. This means that it takes a behavioural -design description as input and generates an RTL, logical gate or physical gate -level description of the design as output. Yosys' main strengths are behavioural -and RTL synthesis. A wide range of commands (synthesis passes) exist -within Yosys that can be used to perform a wide range of synthesis tasks within -the domain of behavioural, rtl and logic synthesis. Yosys is designed to be -extensible and therefore is a good basis for implementing custom synthesis -tools for specialised tasks. - -\section{Features of Synthesizable Verilog} - -The subset of Verilog \cite{Verilog2005} that is synthesizable is specified in -a separate IEEE standards document, the IEEE standard 1364.1-2002 \cite{VerilogSynth}. -This standard also describes how certain language constructs are to be interpreted in -the scope of synthesis. - -This section provides a quick overview of the most important features of -synthesizable Verilog, structured in order of increasing complexity. - -\subsection{Structural Verilog} - -{\it Structural Verilog} (also known as {\it Verilog Netlists}) is a Netlist in -Verilog syntax. Only the following language constructs are used in this case: - -\begin{itemize} -\item Constant values -\item Wire and port declarations -\item Static assignments of signals to other signals -\item Cell instantiations -\end{itemize} - -Many tools (especially at the back end of the synthesis chain) only support -structural Verilog as input. ABC is an example of such a tool. Unfortunately -there is no standard specifying what {\it Structural Verilog} actually is, -leading to some confusion about what syntax constructs are supported in -structural Verilog when it comes to features such as attributes or multi-bit -signals. - -\subsection{Expressions in Verilog} - -In all situations where Verilog accepts a constant value or signal name, -expressions using arithmetic operations such as -\lstinline[language=Verilog]{+}, \lstinline[language=Verilog]{-} and \lstinline[language=Verilog]{*}, -boolean operations such as -\lstinline[language=Verilog]{&} (AND), \lstinline[language=Verilog]{|} (OR) and \lstinline[language=Verilog]{^} (XOR) -and many others (comparison operations, unary operator, etc.) can also be used. - -During synthesis these operators are replaced by cells that implement the respective function. - -Many FOSS tools that claim to be able to process Verilog in fact only support -basic structural Verilog and simple expressions. Yosys can be used to convert -full featured synthesizable Verilog to this simpler subset, thus enabling such -applications to be used with a richer set of Verilog features. - -\subsection{Behavioural Modelling} - -Code that utilizes the Verilog {\tt always} statement is using {\it Behavioural -Modelling}. In behavioural modelling, a circuit is described by means of imperative -program code that is executed on certain events, namely any change, a rising -edge, or a falling edge of a signal. This is a very flexible construct during -simulation but is only synthesizable when one of the following is modelled: - -\begin{itemize} -\item {\bf Asynchronous or latched logic} \\ -In this case the sensitivity list must contain all expressions that are used within -the {\tt always} block. The syntax \lstinline[language=Verilog]{@*} can be used -for these cases. Examples of this kind include: - -\begin{lstlisting}[numbers=left,frame=single,language=Verilog] -// asynchronous -always @* begin - if (add_mode) - y <= a + b; - else - y <= a - b; -end - -// latched -always @* begin - if (!hold) - y <= a + b; -end -\end{lstlisting} - -Note that latched logic is often considered bad style and in many cases just -the result of sloppy HDL design. Therefore many synthesis tools generate warnings -whenever latched logic is generated. - -\item {\bf Synchronous logic (with optional synchronous reset)} \\ -This is logic with d-type flip-flops on the output. In this case the sensitivity -list must only contain the respective clock edge. Example: -\begin{lstlisting}[numbers=left,frame=single,language=Verilog] -// counter with synchronous reset -always @(posedge clk) begin - if (reset) - y <= 0; - else - y <= y + 1; -end -\end{lstlisting} - -\item {\bf Synchronous logic with asynchronous reset} \\ -This is logic with d-type flip-flops with asynchronous resets on the output. In -this case the sensitivity list must only contain the respective clock and reset edges. -The values assigned in the reset branch must be constant. Example: -\begin{lstlisting}[numbers=left,frame=single,language=Verilog] -// counter with asynchronous reset -always @(posedge clk, posedge reset) begin - if (reset) - y <= 0; - else - y <= y + 1; -end -\end{lstlisting} -\end{itemize} - -Many synthesis tools support a wider subset of flip-flops that can be modelled -using {\tt always}-statements (including Yosys). But only the ones listed above -are covered by the Verilog synthesis standard and when writing new designs one -should limit herself or himself to these cases. - -In behavioural modelling, blocking assignments (=) and non-blocking assignments -(<=) can be used. The concept of blocking vs.~non-blocking assignment is one -of the most misunderstood constructs in Verilog \cite{Cummings00}. - -The blocking assignment behaves exactly like an assignment in any imperative -programming language, while with the non-blocking assignment the right hand side -of the assignment is evaluated immediately but the actual update of the left -hand side register is delayed until the end of the time-step. For example the Verilog -code \lstinline[language=Verilog]{a <= b; b <= a;} exchanges the values of -the two registers. See Sec.~\ref{sec:blocking_nonblocking} for a more -detailed description of this behaviour. - -\subsection{Functions and Tasks} - -Verilog supports {\it Functions} and {\it Tasks} to bundle statements that are -used in multiple places (similar to {\it Procedures} in imperative programming). -Both constructs can be implemented easily by substituting the function/task-call -with the body of the function or task. - -\subsection{Conditionals, Loops and Generate-Statements} - -Verilog supports \lstinline[language=Verilog]{if-else}-statements and -\lstinline[language=Verilog]{for}-loops inside \lstinline[language=Verilog]{always}-statements. - -It also supports both features in \lstinline[language=Verilog]{generate}-statements -on the module level. This can be used to selectively enable or disable parts of the -module based on the module parameters (\lstinline[language=Verilog]{if-else}) -or to generate a set of similar subcircuits (\lstinline[language=Verilog]{for}). - -While the \lstinline[language=Verilog]{if-else}-statement -inside an always-block is part of behavioural modelling, the three other cases -are (at least for a synthesis tool) part of a built-in macro processor. Therefore it must -be possible for the synthesis tool to completely unroll all loops and evaluate the -condition in all \lstinline[language=Verilog]{if-else}-statement in -\lstinline[language=Verilog]{generate}-statements using const-folding. - -Examples for this can be found in Fig.~\ref{fig:StateOfTheArt_for} and -Fig.~\ref{fig:StateOfTheArt_gen} in App.~\ref{chapter:sota}. - -\subsection{Arrays and Memories} - -Verilog supports arrays. This is in general a synthesizable language feature. -In most cases arrays can be synthesized by generating addressable memories. -However, when complex or asynchronous access patterns are used, it is not -possible to model an array as memory. In these cases the array must -be modelled using individual signals for each word and all accesses to the array -must be implemented using large multiplexers. - -In some cases it would be possible to model an array using memories, but it -is not desired. Consider the following delay circuit: -\begin{lstlisting}[numbers=left,frame=single,language=Verilog] -module (clk, in_data, out_data); - -parameter BITS = 8; -parameter STAGES = 4; - -input clk; -input [BITS-1:0] in_data; -output [BITS-1:0] out_data; -reg [BITS-1:0] ffs [STAGES-1:0]; - -integer i; -always @(posedge clk) begin - ffs[0] <= in_data; - for (i = 1; i < STAGES; i = i+1) - ffs[i] <= ffs[i-1]; -end - -assign out_data = ffs[STAGES-1]; - -endmodule -\end{lstlisting} - -This could be implemented using an addressable memory with {\tt STAGES} input -and output ports. A better implementation would be to use a simple chain of flip-flops -(a so-called shift register). -This better implementation can either be obtained by first creating a memory-based -implementation and then optimizing it based on the static address signals for all ports -or directly identifying such situations in the language front end and converting -all memory accesses to direct accesses to the correct signals. - -\section{Challenges in Digital Circuit Synthesis} - -This section summarizes the most important challenges in digital circuit -synthesis. Tools can be characterized by how well they address these topics. - -\subsection{Standards Compliance} - -The most important challenge is compliance with the HDL standards in question (in case -of Verilog the IEEE Standards 1364.1-2002 and 1364-2005). This can be broken down in two -items: - -\begin{itemize} -\item Completeness of implementation of the standard -\item Correctness of implementation of the standard -\end{itemize} - -Completeness is mostly important to guarantee compatibility -with existing HDL code. Once a design has been verified and tested, HDL designers -are very reluctant regarding changes to the design, even if it is only about -a few minor changes to work around a missing feature in a new synthesis tool. - -Correctness is crucial. In some areas this is obvious (such as -correct synthesis of basic behavioural models). But it is also crucial for the -areas that concern minor details of the standard, such as the exact rules -for handling signed expressions, even when the HDL code does not target -different synthesis tools. This is because (unlike software source code that -is only processed by compilers), in most design flows HDL code is not only -processed by the synthesis tool but also by one or more simulators and sometimes -even a formal verification tool. It is key for this verification process -that all these tools use the same interpretation for the HDL code. - -\subsection{Optimizations} - -Generally it is hard to give a one-dimensional description of how well a synthesis tool -optimizes the design. First of all because not all optimizations are applicable to all -designs and all synthesis tasks. Some optimizations work (best) on a coarse-grained level -(with complex cells such as adders or multipliers) and others work (best) on a fine-grained -level (single bit gates). Some optimizations target area and others target speed. -Some work well on large designs while others don't scale well and can only be applied -to small designs. - -A good tool is capable of applying a wide range of optimizations at different -levels of abstraction and gives the designer control over which optimizations -are performed (or skipped) and what the optimization goals are. - -\subsection{Technology Mapping} - -Technology mapping is the process of converting the design into a netlist of -cells that are available in the target architecture. In an ASIC flow this might -be the process-specific cell library provided by the fab. In an FPGA flow this -might be LUT cells as well as special function units such as dedicated multipliers. -In a coarse-grain flow this might even be more complex special function units. - -An open and vendor independent tool is especially of interest if it supports -a wide range of different types of target architectures. - -\section{Script-Based Synthesis Flows} - -A digital design is usually started by implementing a high-level or -system-level simulation of the desired function. This description is then -manually transformed (or re-implemented) into a synthesizable lower-level -description (usually at the behavioural level) and the equivalence of the -two representations is verified by simulating both and comparing the simulation -results. - -Then the synthesizable description is transformed to lower-level -representations using a series of tools and the results are again verified -using simulation. This process is illustrated in Fig.~\ref{fig:Basics_flow}. - -\begin{figure}[t!] - \hfil - \begin{tikzpicture} - \tikzstyle{manual} = [draw, fill=green!10, rectangle, minimum height=2em, minimum width=8em, node distance=10em] - \tikzstyle{auto} = [draw, fill=orange!10, rectangle, minimum height=2em, minimum width=8em, node distance=10em] - - \node[manual] (sys) {\begin{minipage}{8em} - \center - System Level \\ - Model - \end{minipage}}; - \node[manual] (beh) [right of=sys] {\begin{minipage}{8em} - \center - Behavioral \\ - Model - \end{minipage}}; - \node[auto] (rtl) [right of=beh] {\begin{minipage}{8em} - \center - RTL \\ - Model - \end{minipage}}; - \node[auto] (gates) [right of=rtl] {\begin{minipage}{8em} - \center - Gate-Level \\ - Model - \end{minipage}}; - - \draw[-latex] (beh) edge[double, bend left] node[above] {synthesis} (rtl); - \draw[-latex] (rtl) edge[double, bend left] node[above] {synthesis} (gates); - - \draw[latex-latex] (sys) edge[bend right] node[below] {verify} (beh); - \draw[latex-latex] (beh) edge[bend right] node[below] {verify} (rtl); - \draw[latex-latex] (rtl) edge[bend right] node[below] {verify} (gates); - \end{tikzpicture} - \caption{Typical design flow. Green boxes represent manually created models. Orange boxes represent - models generated by synthesis tools.} - \label{fig:Basics_flow} -\end{figure} - -In this example the System Level Model and the Behavioural Model are both -manually written design files. After the equivalence of system level model -and behavioural model has been verified, the lower level representations of the -design can be generated using synthesis tools. Finally the RTL Model and -the Gate-Level Model are verified and the design process is finished. - -However, in any real-world design effort there will be multiple iterations for -this design process. The reason for this can be the late change of a design -requirement or the fact that the analysis of a low-abstraction model (e.g.~gate-level -timing analysis) revealed that a design change is required in order to meet -the design requirements (e.g.~maximum possible clock speed). - -Whenever the behavioural model or the system level model is -changed their equivalence must be re-verified by re-running the simulations -and comparing the results. Whenever the behavioural model is changed the -synthesis must be re-run and the synthesis results must be re-verified. - -In order to guarantee reproducibility it is important to be able to re-run all -automatic steps in a design project with a fixed set of settings easily. -Because of this, usually all programs used in a synthesis flow can be -controlled using scripts. This means that all functions are available via -text commands. When such a tool provides a GUI, this is complementary to, -and not instead of, a command line interface. - -Usually a synthesis flow in an UNIX/Linux environment would be controlled by a -shell script that calls all required tools (synthesis and simulation/verification -in this example) in the correct order. Each of these tools would be called with -a script file containing commands for the respective tool. All settings required -for the tool would be provided by these script files so that no manual interaction -would be necessary. These script files are considered design sources and should -be kept under version control just like the source code of the system level and the -behavioural model. - -\section{Methods from Compiler Design} - -Some parts of synthesis tools involve problem domains that are traditionally known from -compiler design. This section addresses some of these domains. - -\subsection{Lexing and Parsing} - -The best known concepts from compiler design are probably {\it lexing} and {\it parsing}. -These are two methods that together can be used to process complex computer languages -easily. \cite{Dragonbook} - -A {\it lexer} consumes single characters from the input and generates a stream of {\it lexical -tokens} that consist of a {\it type} and a {\it value}. For example the Verilog input -``\lstinline[language=Verilog]{assign foo = bar + 42;}'' might be translated by the lexer -to the list of lexical tokens given in Tab.~\ref{tab:Basics_tokens}. - -\begin{table}[t] -\hfil -\begin{tabular}{ll} -Token-Type & Token-Value \\ -\hline -\tt TOK\_ASSIGN & - \\ -\tt TOK\_IDENTIFIER & ``{\tt foo}'' \\ -\tt TOK\_EQ & - \\ -\tt TOK\_IDENTIFIER & ``{\tt bar}'' \\ -\tt TOK\_PLUS & - \\ -\tt TOK\_NUMBER & 42 \\ -\tt TOK\_SEMICOLON & - \\ -\end{tabular} -\caption{Exemplary token list for the statement ``\lstinline[language=Verilog]{assign foo = bar + 42;}''.} -\label{tab:Basics_tokens} -\end{table} - -The lexer is usually generated by a lexer generator (e.g.~{\tt flex} \citeweblink{flex}) from a -description file that is using regular expressions to specify the text pattern that should match -the individual tokens. - -The lexer is also responsible for skipping ignored characters (such as whitespace outside string -constants and comments in the case of Verilog) and converting the original text snippet to a token -value. - -Note that individual keywords use different token types (instead of a keyword type with different -token values). This is because the parser usually can only use the Token-Type to make a decision on -the grammatical role of a token. - -The parser then transforms the list of tokens into a parse tree that closely resembles the productions -from the computer languages grammar. As the lexer, the parser is also typically generated by a code -generator (e.g.~{\tt bison} \citeweblink{bison}) from a grammar description in Backus-Naur Form (BNF). - -Let's consider the following BNF (in Bison syntax): - -\begin{lstlisting}[numbers=left,frame=single] -assign_stmt: TOK_ASSIGN TOK_IDENTIFIER TOK_EQ expr TOK_SEMICOLON; -expr: TOK_IDENTIFIER | TOK_NUMBER | expr TOK_PLUS expr; -\end{lstlisting} - -\begin{figure}[b!] - \hfil - \begin{tikzpicture} - \tikzstyle{node} = [draw, fill=green!10, ellipse, minimum height=2em, minimum width=8em, node distance=10em] - - \draw (+0,+1) node[node] (n1) {\tt assign\_stmt}; - - \draw (-6,-1) node[node] (n11) {\tt TOK\_ASSIGN}; - \draw (-3,-2) node[node] (n12) {\tt TOK\_IDENTIFIER}; - \draw (+0,-1) node[node] (n13) {\tt TOK\_EQ}; - \draw (+3,-2) node[node] (n14) {\tt expr}; - \draw (+6,-1) node[node] (n15) {\tt TOK\_SEMICOLON}; - - \draw (-1,-4) node[node] (n141) {\tt expr}; - \draw (+3,-4) node[node] (n142) {\tt TOK\_PLUS}; - \draw (+7,-4) node[node] (n143) {\tt expr}; - - \draw (-1,-5.5) node[node] (n1411) {\tt TOK\_IDENTIFIER}; - \draw (+7,-5.5) node[node] (n1431) {\tt TOK\_NUMBER}; - - \draw[-latex] (n1) -- (n11); - \draw[-latex] (n1) -- (n12); - \draw[-latex] (n1) -- (n13); - \draw[-latex] (n1) -- (n14); - \draw[-latex] (n1) -- (n15); - - \draw[-latex] (n14) -- (n141); - \draw[-latex] (n14) -- (n142); - \draw[-latex] (n14) -- (n143); - - \draw[-latex] (n141) -- (n1411); - \draw[-latex] (n143) -- (n1431); - \end{tikzpicture} - \caption{Example parse tree for the Verilog expression ``\lstinline[language=Verilog]{assign foo = bar + 42;}''.} - \label{fig:Basics_parsetree} -\end{figure} - -The parser converts the token list to the parse tree in Fig.~\ref{fig:Basics_parsetree}. Note that the parse -tree never actually exists as a whole as data structure in memory. Instead the parser calls user-specified -code snippets (so-called {\it reduce-functions}) for all inner nodes of the parse tree in depth-first order. - -In some very simple applications (e.g.~code generation for stack machines) it is possible to perform the -task at hand directly in the reduce functions. But usually the reduce functions are only used to build an in-memory -data structure with the relevant information from the parse tree. This data structure is called an {\it abstract -syntax tree} (AST). - -The exact format for the abstract syntax tree is application specific (while the format of the parse tree and token -list are mostly dictated by the grammar of the language at hand). Figure~\ref{fig:Basics_ast} illustrates what an -AST for the parse tree in Fig.~\ref{fig:Basics_parsetree} could look like. - -Usually the AST is then converted into yet another representation that is more suitable for further processing. -In compilers this is often an assembler-like three-address-code intermediate representation. \cite{Dragonbook} - -\begin{figure}[t] - \hfil - \begin{tikzpicture} - \tikzstyle{node} = [draw, fill=green!10, ellipse, minimum height=2em, minimum width=8em, node distance=10em] - - \draw (+0,+0) node[node] (n1) {\tt ASSIGN}; - - \draw (-2,-2) node[node] (n11) {\tt ID: foo}; - \draw (+2,-2) node[node] (n12) {\tt PLUS}; - - \draw (+0,-4) node[node] (n121) {\tt ID: bar}; - \draw (+4,-4) node[node] (n122) {\tt CONST: 42}; - - \draw[-latex] (n1) -- (n11); - \draw[-latex] (n1) -- (n12); - - \draw[-latex] (n12) -- (n121); - \draw[-latex] (n12) -- (n122); - \end{tikzpicture} - \caption{Example abstract syntax tree for the Verilog expression ``\lstinline[language=Verilog]{assign foo = bar + 42;}''.} - \label{fig:Basics_ast} -\end{figure} - -\subsection{Multi-Pass Compilation} - -Complex problems are often best solved when split up into smaller problems. This is certainly true -for compilers as well as for synthesis tools. The components responsible for solving the smaller problems can -be connected in two different ways: through {\it Single-Pass Pipelining} and by using {\it Multiple Passes}. - -Traditionally a parser and lexer are connected using the pipelined approach: The lexer provides a function that -is called by the parser. This function reads data from the input until a complete lexical token has been read. Then -this token is returned to the parser. So the lexer does not first generate a complete list of lexical tokens -and then pass it to the parser. Instead they run concurrently and the parser can consume tokens as -the lexer produces them. - -The single-pass pipelining approach has the advantage of lower memory footprint (at no time must the complete design -be kept in memory) but has the disadvantage of tighter coupling between the interacting components. - -Therefore single-pass pipelining should only be used when the lower memory footprint is required or the -components are also conceptually tightly coupled. The latter certainly is the case for a parser and its lexer. -But when data is passed between two conceptually loosely coupled components it is often -beneficial to use a multi-pass approach. - -In the multi-pass approach the first component processes all the data and the result is stored in a in-memory -data structure. Then the second component is called with this data. This reduces complexity, as only one -component is running at a time. It also improves flexibility as components can be exchanged easier. - -Most modern compilers are multi-pass compilers. - -\iffalse -\subsection{Static Single Assignment Form} - -In imperative programming (and behavioural HDL design) it is possible to assign the same variable multiple times. -This can either mean that the variable is independently used in two different contexts or that the final value -of the variable depends on a condition. - -The following examples show C code in which one variable is used independently in two different contexts: - -\begin{minipage}{7.7cm} -\begin{lstlisting}[numbers=left,frame=single,language=C++] -void demo1() -{ - int a = 1; - printf("%d\n", a); - - a = 2; - printf("%d\n", a); -} -\end{lstlisting} -\end{minipage} -\hfil -\begin{minipage}{7.7cm} -\begin{lstlisting}[frame=single,language=C++] -void demo1() -{ - int a = 1; - printf("%d\n", a); - - int b = 2; - printf("%d\n", b); -} -\end{lstlisting} -\end{minipage} - -\begin{minipage}{7.7cm} -\begin{lstlisting}[numbers=left,frame=single,language=C++] -void demo2(bool foo) -{ - int a; - if (foo) { - a = 23; - printf("%d\n", a); - } else { - a = 42; - printf("%d\n", a); - } -} -\end{lstlisting} -\end{minipage} -\hfil -\begin{minipage}{7.7cm} -\begin{lstlisting}[frame=single,language=C++] -void demo2(bool foo) -{ - int a, b; - if (foo) { - a = 23; - printf("%d\n", a); - } else { - b = 42; - printf("%d\n", b); - } -} -\end{lstlisting} -\end{minipage} - -In both examples the left version (only variable \lstinline[language=C++]{a}) and the right version (variables -\lstinline[language=Verilog]{a} and \lstinline[language=Verilog]{b}) are equivalent. Therefore it is -desired for further processing to bring the code in an equivalent form for both cases. - -In the following example the variable is assigned twice but it cannot be easily replaced by two variables: - -\begin{lstlisting}[frame=single,language=C++] -void demo3(bool foo) -{ - int a = 23 - if (foo) - a = 42; - printf("%d\n", a); -} -\end{lstlisting} - -Static single assignment (SSA) form is a representation of imperative code that uses identical representations -for the left and right version of demos 1 and 2, but can still represent demo 3. In SSA form each assignment -assigns a new variable (usually written with an index). But it also introduces a special $\Phi$-function to -merge the different instances of a variable when needed. In C-pseudo-code the demo 3 would be written as follows -using SSA from: - -\begin{lstlisting}[frame=single,language=C++] -void demo3(bool foo) -{ - int a_1, a_2, a_3; - a_1 = 23 - if (foo) - a_2 = 42; - a_3 = phi(a_1, a_2); - printf("%d\n", a_3); -} -\end{lstlisting} - -The $\Phi$-function is usually interpreted as ``these variables must be stored -in the same memory location'' during code generation. Most modern compilers for imperative languages -such as C/C++ use SSA form for at least some of its passes as it is very easy to manipulate and analyse. -\fi - diff --git a/manual/CHAPTER_CellLib.tex b/manual/CHAPTER_CellLib.tex deleted file mode 100644 index 86b1f6a9a..000000000 --- a/manual/CHAPTER_CellLib.tex +++ /dev/null @@ -1,1007 +0,0 @@ - -\chapter{Internal Cell Library} -\label{chapter:celllib} - -Most of the passes in Yosys operate on netlists, i.e.~they only care about the RTLIL::Wire and RTLIL::Cell -objects in an RTLIL::Module. This chapter discusses the cell types used by Yosys to represent a behavioural -design internally. - -This chapter is split in two parts. In the first part the internal RTL cells are covered. These cells -are used to represent the design on a coarse grain level. Like in the original HDL code on this level the -cells operate on vectors of signals and complex cells like adders exist. In the second part the internal -gate cells are covered. These cells are used to represent the design on a fine-grain gate-level. All cells -from this category operate on single bit signals. - -\section{RTL Cells} - -Most of the RTL cells closely resemble the operators available in HDLs such as -Verilog or VHDL. Therefore Verilog operators are used in the following sections -to define the behaviour of the RTL cells. - -Note that all RTL cells have parameters indicating the size of inputs and outputs. When -passes modify RTL cells they must always keep the values of these parameters in sync with -the size of the signals connected to the inputs and outputs. - -Simulation models for the RTL cells can be found in the file {\tt techlibs/common/simlib.v} in the Yosys -source tree. - -\subsection{Unary Operators} - -All unary RTL cells have one input port \B{A} and one output port \B{Y}. They also -have the following parameters: - -\begin{itemize} -\item \B{A\_SIGNED} \\ -Set to a non-zero value if the input \B{A} is signed and therefore should be sign-extended -when needed. - -\item \B{A\_WIDTH} \\ -The width of the input port \B{A}. - -\item \B{Y\_WIDTH} \\ -The width of the output port \B{Y}. -\end{itemize} - -Table~\ref{tab:CellLib_unary} lists all cells for unary RTL operators. - -\begin{table}[t!] -\hfil -\begin{tabular}{ll} -Verilog & Cell Type \\ -\hline -\lstinline[language=Verilog]; Y = ~A ; & {\tt \$not} \\ -\lstinline[language=Verilog]; Y = +A ; & {\tt \$pos} \\ -\lstinline[language=Verilog]; Y = -A ; & {\tt \$neg} \\ -\hline -\lstinline[language=Verilog]; Y = &A ; & {\tt \$reduce\_and} \\ -\lstinline[language=Verilog]; Y = |A ; & {\tt \$reduce\_or} \\ -\lstinline[language=Verilog]; Y = ^A ; & {\tt \$reduce\_xor} \\ -\lstinline[language=Verilog]; Y = ~^A ; & {\tt \$reduce\_xnor} \\ -\hline -\lstinline[language=Verilog]; Y = |A ; & {\tt \$reduce\_bool} \\ -\lstinline[language=Verilog]; Y = !A ; & {\tt \$logic\_not} -\end{tabular} -\caption{Cell types for unary operators with their corresponding Verilog expressions.} -\label{tab:CellLib_unary} -\end{table} - -For the unary cells that output a logical value ({\tt \$reduce\_and}, {\tt \$reduce\_or}, -{\tt \$reduce\_xor}, {\tt \$reduce\_xnor}, {\tt \$reduce\_bool}, {\tt \$logic\_not}), -when the \B{Y\_WIDTH} parameter is greater than 1, the output is zero-extended, -and only the least significant bit varies. - -Note that {\tt \$reduce\_or} and {\tt \$reduce\_bool} actually represent the same -logic function. But the HDL frontends generate them in different situations. A -{\tt \$reduce\_or} cell is generated when the prefix {\tt |} operator is being used. A -{\tt \$reduce\_bool} cell is generated when a bit vector is used as a condition in -an {\tt if}-statement or {\tt ?:}-expression. - -\subsection{Binary Operators} - -All binary RTL cells have two input ports \B{A} and \B{B} and one output port \B{Y}. They -also have the following parameters: - -\begin{itemize} -\item \B{A\_SIGNED} \\ -Set to a non-zero value if the input \B{A} is signed and therefore should be sign-extended -when needed. - -\item \B{A\_WIDTH} \\ -The width of the input port \B{A}. - -\item \B{B\_SIGNED} \\ -Set to a non-zero value if the input \B{B} is signed and therefore should be sign-extended -when needed. - -\item \B{B\_WIDTH} \\ -The width of the input port \B{B}. - -\item \B{Y\_WIDTH} \\ -The width of the output port \B{Y}. -\end{itemize} - -Table~\ref{tab:CellLib_binary} lists all cells for binary RTL operators. - -\begin{table}[t!] -\hfil -\begin{tabular}[t]{ll} -Verilog & Cell Type \\ -\hline -\lstinline[language=Verilog]; Y = A & B; & {\tt \$and} \\ -\lstinline[language=Verilog]; Y = A | B; & {\tt \$or} \\ -\lstinline[language=Verilog]; Y = A ^ B; & {\tt \$xor} \\ -\lstinline[language=Verilog]; Y = A ~^ B; & {\tt \$xnor} \\ -\hline -\lstinline[language=Verilog]; Y = A << B; & {\tt \$shl} \\ -\lstinline[language=Verilog]; Y = A >> B; & {\tt \$shr} \\ -\lstinline[language=Verilog]; Y = A <<< B; & {\tt \$sshl} \\ -\lstinline[language=Verilog]; Y = A >>> B; & {\tt \$sshr} \\ -\hline -\lstinline[language=Verilog]; Y = A && B; & {\tt \$logic\_and} \\ -\lstinline[language=Verilog]; Y = A || B; & {\tt \$logic\_or} \\ -\hline -\lstinline[language=Verilog]; Y = A === B; & {\tt \$eqx} \\ -\lstinline[language=Verilog]; Y = A !== B; & {\tt \$nex} \\ -\end{tabular} -\hfil -\begin{tabular}[t]{ll} -Verilog & Cell Type \\ -\hline -\lstinline[language=Verilog]; Y = A < B; & {\tt \$lt} \\ -\lstinline[language=Verilog]; Y = A <= B; & {\tt \$le} \\ -\lstinline[language=Verilog]; Y = A == B; & {\tt \$eq} \\ -\lstinline[language=Verilog]; Y = A != B; & {\tt \$ne} \\ -\lstinline[language=Verilog]; Y = A >= B; & {\tt \$ge} \\ -\lstinline[language=Verilog]; Y = A > B; & {\tt \$gt} \\ -\hline -\lstinline[language=Verilog]; Y = A + B; & {\tt \$add} \\ -\lstinline[language=Verilog]; Y = A - B; & {\tt \$sub} \\ -\lstinline[language=Verilog]; Y = A * B; & {\tt \$mul} \\ -\lstinline[language=Verilog]; Y = A / B; & {\tt \$div} \\ -\lstinline[language=Verilog]; Y = A % B; & {\tt \$mod} \\ -\multicolumn{1}{c}{\tt [N/A]} & {\tt \$divfloor} \\ -\multicolumn{1}{c}{\tt [N/A]} & {\tt \$modfoor} \\ -\lstinline[language=Verilog]; Y = A ** B; & {\tt \$pow} \\ -\end{tabular} -\caption{Cell types for binary operators with their corresponding Verilog expressions.} -\label{tab:CellLib_binary} -\end{table} - -The {\tt \$shl} and {\tt \$shr} cells implement logical shifts, whereas the {\tt \$sshl} and -{\tt \$sshr} cells implement arithmetic shifts. The {\tt \$shl} and {\tt \$sshl} cells implement -the same operation. All four of these cells interpret the second operand as unsigned, and require -\B{B\_SIGNED} to be zero. - -Two additional shift operator cells are available that do not directly correspond to any operator -in Verilog, {\tt \$shift} and {\tt \$shiftx}. The {\tt \$shift} cell performs a right logical shift -if the second operand is positive (or unsigned), and a left logical shift if it is negative. -The {\tt \$shiftx} cell performs the same operation as the {\tt \$shift} cell, but the vacated bit -positions are filled with undef (x) bits, and corresponds to the Verilog indexed part-select expression. - -For the binary cells that output a logical value ({\tt \$logic\_and}, {\tt \$logic\_or}, -{\tt \$eqx}, {\tt \$nex}, {\tt \$lt}, {\tt \$le}, {\tt \$eq}, {\tt \$ne}, {\tt \$ge}, -{\tt \$gt}), when the \B{Y\_WIDTH} parameter is greater than 1, the output is zero-extended, -and only the least significant bit varies. - -Division and modulo cells are available in two rounding modes. The original {\tt \$div} and {\tt \$mod} -cells are based on truncating division, and correspond to the semantics of the verilog {\tt /} and -{\tt \%} operators. The {\tt \$divfloor} and {\tt \$modfloor} cells represent flooring division and -flooring modulo, the latter of which is also known as ``remainder'' in several languages. See -table~\ref{tab:CellLib_divmod} for a side-by-side comparison between the different semantics. - -\begin{table}[h] -\hfil -\begin{tabular}{lr|rr|rr} -\multirow{2}{*}{Division} & \multirow{2}{*}{Result} & \multicolumn{2}{c|}{Truncating} & \multicolumn{2}{c}{Flooring} \\ - & & {\tt \$div} & {\tt \$mod} & {\tt \$divfloor} & {\tt \$modfloor} \\ -\hline -{\tt -10 / 3} & {\tt -3.3} & {\tt -3} & {\tt -1} & {\tt -4} & {\tt 2} \\ -{\tt 10 / -3} & {\tt -3.3} & {\tt -3} & {\tt 1} & {\tt -4} & {\tt -2} \\ -{\tt -10 / -3} & {\tt 3.3} & {\tt 3} & {\tt -1} & {\tt 3} & {\tt -1} \\ -{\tt 10 / 3} & {\tt 3.3} & {\tt 3} & {\tt 1} & {\tt 3} & {\tt 1} \\ -\end{tabular} -\caption{Comparison between different rounding modes for division and modulo cells.} -\label{tab:CellLib_divmod} -\end{table} - -\subsection{Multiplexers} - -Multiplexers are generated by the Verilog HDL frontend for {\tt -?:}-expressions. Multiplexers are also generated by the {\tt proc} pass to map the decision trees -from RTLIL::Process objects to logic. - -The simplest multiplexer cell type is {\tt \$mux}. Cells of this type have a \B{WIDTH} parameter -and data inputs \B{A} and \B{B} and a data output \B{Y}, all of the specified width. This cell also -has a single bit control input \B{S}. If \B{S} is 0 the value from the \B{A} input is sent to -the output, if it is 1 the value from the \B{B} input is sent to the output. So the {\tt \$mux} -cell implements the function \lstinline[language=Verilog]; Y = S ? B : A;. - -The {\tt \$pmux} cell is used to multiplex between many inputs using a one-hot select signal. Cells -of this type have a \B{WIDTH} and a \B{S\_WIDTH} parameter and inputs \B{A}, \B{B}, and \B{S} and -an output \B{Y}. The \B{S} input is \B{S\_WIDTH} bits wide. The \B{A} input and the output are both -\B{WIDTH} bits wide and the \B{B} input is \B{WIDTH}*\B{S\_WIDTH} bits wide. When all bits of -\B{S} are zero, the value from \B{A} input is sent to the output. If the $n$'th bit from \B{S} is -set, the value $n$'th \B{WIDTH} bits wide slice of the \B{B} input is sent to the output. When more -than one bit from \B{S} is set the output is undefined. Cells of this type are used to model -``parallel cases'' (defined by using the {\tt parallel\_case} attribute or detected by -an optimization). - -The {\tt \$tribuf} cell is used to implement tristate logic. Cells of this type have a \B{WIDTH} -parameter and inputs \B{A} and \B{EN} and an output \B{Y}. The \B{A} input and \B{Y} output are -\B{WIDTH} bits wide, and the \B{EN} input is one bit wide. When \B{EN} is 0, the output \B{Y} -is not driven. When \B{EN} is 1, the value from \B{A} input is sent to the \B{Y} output. Therefore, -the {\tt \$tribuf} cell implements the function \lstinline[language=Verilog]; Y = EN ? A : 'bz;. - -Behavioural code with cascaded {\tt if-then-else}- and {\tt case}-statements -usually results in trees of multiplexer cells. Many passes (from various -optimizations to FSM extraction) heavily depend on these multiplexer trees to -understand dependencies between signals. Therefore optimizations should not -break these multiplexer trees (e.g.~by replacing a multiplexer between a -calculated signal and a constant zero with an {\tt \$and} gate). - -\subsection{Registers} - -SR-type latches are represented by {\tt \$sr} cells. These cells have input ports -\B{SET} and \B{CLR} and an output port \B{Q}. They have the following parameters: - -\begin{itemize} -\item \B{WIDTH} \\ -The width of inputs \B{SET} and \B{CLR} and output \B{Q}. - -\item \B{SET\_POLARITY} \\ -The set input bits are active-high if this parameter has the value {\tt 1'b1} and active-low -if this parameter is {\tt 1'b0}. - -\item \B{CLR\_POLARITY} \\ -The reset input bits are active-high if this parameter has the value {\tt 1'b1} and active-low -if this parameter is {\tt 1'b0}. -\end{itemize} - -Both set and reset inputs have separate bits for every output bit. -When both the set and reset inputs of an {\tt \$sr} cell are active for a given bit -index, the reset input takes precedence. - -D-type flip-flops are represented by {\tt \$dff} cells. These cells have a clock port \B{CLK}, -an input port \B{D} and an output port \B{Q}. The following parameters are available for {\tt \$dff} -cells: - -\begin{itemize} -\item \B{WIDTH} \\ -The width of input \B{D} and output \B{Q}. - -\item \B{CLK\_POLARITY} \\ -Clock is active on the positive edge if this parameter has the value {\tt 1'b1} and on the negative -edge if this parameter is {\tt 1'b0}. -\end{itemize} - -D-type flip-flops with asynchronous reset are represented by {\tt \$adff} cells. As the {\tt \$dff} -cells they have \B{CLK}, \B{D} and \B{Q} ports. In addition they also have a single-bit \B{ARST} -input port for the reset pin and the following additional two parameters: - -\begin{itemize} -\item \B{ARST\_POLARITY} \\ -The asynchronous reset is active-high if this parameter has the value {\tt 1'b1} and active-low -if this parameter is {\tt 1'b0}. - -\item \B{ARST\_VALUE} \\ -The state of \B{Q} will be set to this value when the reset is active. -\end{itemize} - -\begin{sloppypar} -Usually these cells are generated by the {\tt proc} pass using the information -in the designs RTLIL::Process objects. -\end{sloppypar} - -D-type flip-flops with synchronous reset are represented by {\tt \$sdff} cells. As the {\tt \$dff} -cells they have \B{CLK}, \B{D} and \B{Q} ports. In addition they also have a single-bit \B{SRST} -input port for the reset pin and the following additional two parameters: - -\begin{itemize} -\item \B{SRST\_POLARITY} \\ -The synchronous reset is active-high if this parameter has the value {\tt 1'b1} and active-low -if this parameter is {\tt 1'b0}. - -\item \B{SRST\_VALUE} \\ -The state of \B{Q} will be set to this value when the reset is active. -\end{itemize} - -Note that the {\tt \$adff} and {\tt \$sdff} cells can only be used when the reset value is constant. - -D-type flip-flops with asynchronous load are represented by {\tt \$aldff} cells. As the {\tt \$dff} -cells they have \B{CLK}, \B{D} and \B{Q} ports. In addition they also have a single-bit \B{ALOAD} -input port for the async load enable pin, a \B{AD} input port with the same width as data for -the async load data, and the following additional parameter: - -\begin{itemize} -\item \B{ALOAD\_POLARITY} \\ -The asynchronous load is active-high if this parameter has the value {\tt 1'b1} and active-low -if this parameter is {\tt 1'b0}. -\end{itemize} - -D-type flip-flops with asynchronous set and reset are represented by {\tt \$dffsr} cells. -As the {\tt \$dff} cells they have \B{CLK}, \B{D} and \B{Q} ports. In addition they also have -multi-bit \B{SET} and \B{CLR} input ports and the corresponding polarity parameters, like -{\tt \$sr} cells. - -D-type flip-flops with enable are represented by {\tt \$dffe}, {\tt \$adffe}, {\tt \$aldffe}, {\tt \$dffsre}, -{\tt \$sdffe}, and {\tt \$sdffce} cells, which are enhanced variants of {\tt \$dff}, {\tt \$adff}, {\tt \$aldff}, {\tt \$dffsr}, -{\tt \$sdff} (with reset over enable) and {\tt \$sdff} (with enable over reset) -cells, respectively. They have the same ports and parameters as their base cell. -In addition they also have a single-bit \B{EN} input port for the enable pin and the following parameter: - -\begin{itemize} -\item \B{EN\_POLARITY} \\ -The enable input is active-high if this parameter has the value {\tt 1'b1} and active-low -if this parameter is {\tt 1'b0}. -\end{itemize} - -D-type latches are represented by {\tt \$dlatch} cells. These cells have an enable port \B{EN}, -an input port \B{D}, and an output port \B{Q}. The following parameters are available for {\tt \$dlatch} cells: - -\begin{itemize} -\item \B{WIDTH} \\ -The width of input \B{D} and output \B{Q}. - -\item \B{EN\_POLARITY} \\ -The enable input is active-high if this parameter has the value {\tt 1'b1} and active-low -if this parameter is {\tt 1'b0}. -\end{itemize} - -The latch is transparent when the \B{EN} input is active. - -D-type latches with reset are represented by {\tt \$adlatch} cells. In addition to {\tt \$dlatch} -ports and parameters, they also have a single-bit \B{ARST} input port for the reset pin and the following additional parameters: - -\begin{itemize} -\item \B{ARST\_POLARITY} \\ -The asynchronous reset is active-high if this parameter has the value {\tt 1'b1} and active-low -if this parameter is {\tt 1'b0}. - -\item \B{ARST\_VALUE} \\ -The state of \B{Q} will be set to this value when the reset is active. -\end{itemize} - -D-type latches with set and reset are represented by {\tt \$dlatchsr} cells. -In addition to {\tt \$dlatch} ports and parameters, they also have multi-bit -\B{SET} and \B{CLR} input ports and the corresponding polarity parameters, like -{\tt \$sr} cells. - -\subsection{Memories} -\label{sec:memcells} - -Memories are either represented using RTLIL::Memory objects, {\tt \$memrd\_v2}, {\tt \$memwr\_v2}, and {\tt \$meminit\_v2} -cells, or by {\tt \$mem\_v2} cells alone. - -In the first alternative the RTLIL::Memory objects hold the general metadata for the memory (bit width, -size in number of words, etc.) and for each port a {\tt \$memrd\_v2} (read port) or {\tt \$memwr\_v2} (write port) -cell is created. Having individual cells for read and write ports has the advantage that they can be -consolidated using resource sharing passes. In some cases this drastically reduces the number of required -ports on the memory cell. In this alternative, memory initialization data is represented by {\tt \$meminit\_v2} cells, -which allow delaying constant folding for initialization addresses and data until after the frontend finishes. - -The {\tt \$memrd\_v2} cells have a clock input \B{CLK}, an enable input \B{EN}, an -address input \B{ADDR}, a data output \B{DATA}, an asynchronous reset input \B{ARST}, -and a synchronous reset input \B{SRST}. They also have the following parameters: - -\begin{itemize} -\item \B{MEMID} \\ -The name of the RTLIL::Memory object that is associated with this read port. - -\item \B{ABITS} \\ -The number of address bits (width of the \B{ADDR} input port). - -\item \B{WIDTH} \\ -The number of data bits (width of the \B{DATA} output port). Note that this may be a power-of-two -multiple of the underlying memory's width -- such ports are called wide ports and access an aligned -group of cells at once. In this case, the corresponding low bits of \B{ADDR} must be tied to 0. - -\item \B{CLK\_ENABLE} \\ -When this parameter is non-zero, the clock is used. Otherwise this read port is asynchronous and -the \B{CLK} input is not used. - -\item \B{CLK\_POLARITY} \\ -Clock is active on the positive edge if this parameter has the value {\tt 1'b1} and on the negative -edge if this parameter is {\tt 1'b0}. - -\item \B{TRANSPARENCY\_MASK} \\ -This parameter is a bitmask of write ports that this read port is transparent with. The bits -of this parameter are indexed by the write port's \B{PORTID} parameter. Transparency can only be -enabled between synchronous ports sharing a clock domain. When transparency is enabled for a given -port pair, a read and write to the same address in the same cycle will return the new value. -Otherwise the old value is returned. - -\item \B{COLLISION\_X\_MASK} \\ -This parameter is a bitmask of write ports that have undefined collision behavior with this port. -The bits of this parameter are indexed by the write port's \B{PORTID} parameter. This behavior can only be -enabled between synchronous ports sharing a clock domain. When undefined collision is enabled for a given -port pair, a read and write to the same address in the same cycle will return the undefined (all-X) value. -This option is exclusive (for a given port pair) with the transparency option. - -\item \B{ARST\_VALUE} \\ -Whenever the \B{ARST} input is asserted, the data output will be reset to this value. -Only used for synchronous ports. - -\item \B{SRST\_VALUE} \\ -Whenever the \B{SRST} input is synchronously asserted, the data output will be reset to this value. -Only used for synchronous ports. - -\item \B{INIT\_VALUE} \\ -The initial value of the data output, for synchronous ports. - -\item \B{CE\_OVER\_SRST} \\ -If this parameter is non-zero, the \B{SRST} input is only recognized when \B{EN} is true. -Otherwise, \B{SRST} is recognized regardless of \B{EN}. -\end{itemize} - -The {\tt \$memwr\_v2} cells have a clock input \B{CLK}, an enable input \B{EN} (one -enable bit for each data bit), an address input \B{ADDR} and a data input -\B{DATA}. They also have the following parameters: - -\begin{itemize} -\item \B{MEMID} \\ -The name of the RTLIL::Memory object that is associated with this write port. - -\item \B{ABITS} \\ -The number of address bits (width of the \B{ADDR} input port). - -\item \B{WIDTH} \\ -The number of data bits (width of the \B{DATA} output port). Like with {\tt \$memrd\_v2} cells, -the width is allowed to be any power-of-two multiple of memory width, with the corresponding -restriction on address. - -\item \B{CLK\_ENABLE} \\ -When this parameter is non-zero, the clock is used. Otherwise this write port is asynchronous and -the \B{CLK} input is not used. - -\item \B{CLK\_POLARITY} \\ -Clock is active on positive edge if this parameter has the value {\tt 1'b1} and on the negative -edge if this parameter is {\tt 1'b0}. - -\item \B{PORTID} \\ -An identifier for this write port, used to index write port bit mask parameters. - -\item \B{PRIORITY\_MASK} \\ -This parameter is a bitmask of write ports that this write port has priority over in case of writing -to the same address. The bits of this parameter are indexed by the other write port's \B{PORTID} parameter. -Write ports can only have priority over write ports with lower port ID. When two ports write to the same -address and neither has priority over the other, the result is undefined. Priority can only be set between -two synchronous ports sharing the same clock domain. -\end{itemize} - -The {\tt \$meminit\_v2} cells have an address input \B{ADDR}, a data input \B{DATA}, with the width -of the \B{DATA} port equal to \B{WIDTH} parameter times \B{WORDS} parameter, and a bit enable mask input -\B{EN} with width equal to \B{WIDTH} parameter. All three of the inputs -must resolve to a constant for synthesis to succeed. - -\begin{itemize} -\item \B{MEMID} \\ -The name of the RTLIL::Memory object that is associated with this initialization cell. - -\item \B{ABITS} \\ -The number of address bits (width of the \B{ADDR} input port). - -\item \B{WIDTH} \\ -The number of data bits per memory location. - -\item \B{WORDS} \\ -The number of consecutive memory locations initialized by this cell. - -\item \B{PRIORITY} \\ -The cell with the higher integer value in this parameter wins an initialization conflict. -\end{itemize} - -The HDL frontend models a memory using RTLIL::Memory objects and asynchronous -{\tt \$memrd\_v2} and {\tt \$memwr\_v2} cells. The {\tt memory} pass (i.e.~its various sub-passes) migrates -{\tt \$dff} cells into the {\tt \$memrd\_v2} and {\tt \$memwr\_v2} cells making them synchronous, then -converts them to a single {\tt \$mem\_v2} cell and (optionally) maps this cell type -to {\tt \$dff} cells for the individual words and multiplexer-based address decoders for the read and -write interfaces. When the last step is disabled or not possible, a {\tt \$mem\_v2} cell is left in the design. - -The {\tt \$mem\_v2} cell provides the following parameters: - -\begin{itemize} -\item \B{MEMID} \\ -The name of the original RTLIL::Memory object that became this {\tt \$mem\_v2} cell. - -\item \B{SIZE} \\ -The number of words in the memory. - -\item \B{ABITS} \\ -The number of address bits. - -\item \B{WIDTH} \\ -The number of data bits per word. - -\item \B{INIT} \\ -The initial memory contents. - -\item \B{RD\_PORTS} \\ -The number of read ports on this memory cell. - -\item \B{RD\_WIDE\_CONTINUATION} \\ -This parameter is \B{RD\_PORTS} bits wide, containing a bitmask of ``wide continuation'' read ports. -Such ports are used to represent the extra data bits of wide ports in the combined cell, and must -have all control signals identical with the preceding port, except for address, which must have -the proper sub-cell address encoded in the low bits. - -\item \B{RD\_CLK\_ENABLE} \\ -This parameter is \B{RD\_PORTS} bits wide, containing a clock enable bit for each read port. - -\item \B{RD\_CLK\_POLARITY} \\ -This parameter is \B{RD\_PORTS} bits wide, containing a clock polarity bit for each read port. - -\item \B{RD\_TRANSPARENCY\_MASK} \\ -This parameter is \B{RD\_PORTS*WR\_PORTS} bits wide, containing a concatenation of all -\B{TRANSPARENCY\_MASK} values of the original {\tt \$memrd\_v2} cells. - -\item \B{RD\_COLLISION\_X\_MASK} \\ -This parameter is \B{RD\_PORTS*WR\_PORTS} bits wide, containing a concatenation of all -\B{COLLISION\_X\_MASK} values of the original {\tt \$memrd\_v2} cells. - -\item \B{RD\_CE\_OVER\_SRST} \\ -This parameter is \B{RD\_PORTS} bits wide, determining relative synchronous reset and enable priority for each read port. - -\item \B{RD\_INIT\_VALUE} \\ -This parameter is \B{RD\_PORTS*WIDTH} bits wide, containing the initial value for each synchronous read port. - -\item \B{RD\_ARST\_VALUE} \\ -This parameter is \B{RD\_PORTS*WIDTH} bits wide, containing the asynchronous reset value for each synchronous read port. - -\item \B{RD\_SRST\_VALUE} \\ -This parameter is \B{RD\_PORTS*WIDTH} bits wide, containing the synchronous reset value for each synchronous read port. - -\item \B{WR\_PORTS} \\ -The number of write ports on this memory cell. - -\item \B{WR\_WIDE\_CONTINUATION} \\ -This parameter is \B{WR\_PORTS} bits wide, containing a bitmask of ``wide continuation'' write ports. - -\item \B{WR\_CLK\_ENABLE} \\ -This parameter is \B{WR\_PORTS} bits wide, containing a clock enable bit for each write port. - -\item \B{WR\_CLK\_POLARITY} \\ -This parameter is \B{WR\_PORTS} bits wide, containing a clock polarity bit for each write port. - -\item \B{WR\_PRIORITY\_MASK} \\ -This parameter is \B{WR\_PORTS*WR\_PORTS} bits wide, containing a concatenation of all -\B{PRIORITY\_MASK} values of the original {\tt \$memwr\_v2} cells. -\end{itemize} - -The {\tt \$mem\_v2} cell has the following ports: - -\begin{itemize} -\item \B{RD\_CLK} \\ -This input is \B{RD\_PORTS} bits wide, containing all clock signals for the read ports. - -\item \B{RD\_EN} \\ -This input is \B{RD\_PORTS} bits wide, containing all enable signals for the read ports. - -\item \B{RD\_ADDR} \\ -This input is \B{RD\_PORTS}*\B{ABITS} bits wide, containing all address signals for the read ports. - -\item \B{RD\_DATA} \\ -This input is \B{RD\_PORTS}*\B{WIDTH} bits wide, containing all data signals for the read ports. - -\item \B{RD\_ARST} \\ -This input is \B{RD\_PORTS} bits wide, containing all asynchronous reset signals for the read ports. - -\item \B{RD\_SRST} \\ -This input is \B{RD\_PORTS} bits wide, containing all synchronous reset signals for the read ports. - -\item \B{WR\_CLK} \\ -This input is \B{WR\_PORTS} bits wide, containing all clock signals for the write ports. - -\item \B{WR\_EN} \\ -This input is \B{WR\_PORTS}*\B{WIDTH} bits wide, containing all enable signals for the write ports. - -\item \B{WR\_ADDR} \\ -This input is \B{WR\_PORTS}*\B{ABITS} bits wide, containing all address signals for the write ports. - -\item \B{WR\_DATA} \\ -This input is \B{WR\_PORTS}*\B{WIDTH} bits wide, containing all data signals for the write ports. -\end{itemize} - -The {\tt memory\_collect} pass can be used to convert discrete {\tt \$memrd\_v2}, {\tt \$memwr\_v2}, and {\tt \$meminit\_v2} cells -belonging to the same memory to a single {\tt \$mem\_v2} cell, whereas the {\tt memory\_unpack} pass performs the inverse operation. -The {\tt memory\_dff} pass can combine asynchronous memory ports that are fed by or feeding registers into synchronous memory ports. -The {\tt memory\_bram} pass can be used to recognize {\tt \$mem\_v2} cells that can be implemented with a block RAM resource on an FPGA. -The {\tt memory\_map} pass can be used to implement {\tt \$mem\_v2} cells as basic logic: word-wide DFFs and address decoders. - -\subsection{Finite State Machines} - -\begin{fixme} -Add a brief description of the {\tt \$fsm} cell type. -\end{fixme} - -\subsection{Specify rules} - -\begin{fixme} -Add information about {\tt \$specify2}, {\tt \$specify3}, and {\tt \$specrule} cells. -\end{fixme} - -\subsection{Formal verification cells} - -\begin{fixme} -Add information about {\tt \$assert}, {\tt \$assume}, {\tt \$live}, {\tt \$fair}, {\tt \$cover}, {\tt \$equiv}, -{\tt \$initstate}, {\tt \$anyconst}, {\tt \$anyseq}, {\tt \$anyinit}, {\tt \$allconst}, {\tt \$allseq} cells. -\end{fixme} - -\begin{fixme} -Add information about {\tt \$ff} and {\tt \$\_FF\_} cells. -\end{fixme} - -\section{Gates} -\label{sec:celllib_gates} - -For gate level logic networks, fixed function single bit cells are used that do -not provide any parameters. - -Simulation models for these cells can be found in the file {\tt techlibs/common/simcells.v} in the Yosys -source tree. - -\begin{table}[t] -\hfil -\begin{tabular}[t]{ll} -Verilog & Cell Type \\ -\hline -\lstinline[language=Verilog]; Y = A; & {\tt \$\_BUF\_} \\ -\lstinline[language=Verilog]; Y = ~A; & {\tt \$\_NOT\_} \\ -\lstinline[language=Verilog]; Y = A & B; & {\tt \$\_AND\_} \\ -\lstinline[language=Verilog]; Y = ~(A & B); & {\tt \$\_NAND\_} \\ -\lstinline[language=Verilog]; Y = A & ~B; & {\tt \$\_ANDNOT\_} \\ -\lstinline[language=Verilog]; Y = A | B; & {\tt \$\_OR\_} \\ -\lstinline[language=Verilog]; Y = ~(A | B); & {\tt \$\_NOR\_} \\ -\lstinline[language=Verilog]; Y = A | ~B; & {\tt \$\_ORNOT\_} \\ -\lstinline[language=Verilog]; Y = A ^ B; & {\tt \$\_XOR\_} \\ -\lstinline[language=Verilog]; Y = ~(A ^ B); & {\tt \$\_XNOR\_} \\ -\lstinline[language=Verilog]; Y = ~((A & B) | C); & {\tt \$\_AOI3\_} \\ -\lstinline[language=Verilog]; Y = ~((A | B) & C); & {\tt \$\_OAI3\_} \\ -\lstinline[language=Verilog]; Y = ~((A & B) | (C & D)); & {\tt \$\_AOI4\_} \\ -\lstinline[language=Verilog]; Y = ~((A | B) & (C | D)); & {\tt \$\_OAI4\_} \\ -\lstinline[language=Verilog]; Y = S ? B : A; & {\tt \$\_MUX\_} \\ -\lstinline[language=Verilog]; Y = ~(S ? B : A); & {\tt \$\_NMUX\_} \\ -(see below) & {\tt \$\_MUX4\_} \\ -(see below) & {\tt \$\_MUX8\_} \\ -(see below) & {\tt \$\_MUX16\_} \\ -\lstinline[language=Verilog]; Y = EN ? A : 1'bz; & {\tt \$\_TBUF\_} \\ -\hline -\lstinline[language=Verilog]; always @(negedge C) Q <= D; & {\tt \$\_DFF\_N\_} \\ -\lstinline[language=Verilog]; always @(posedge C) Q <= D; & {\tt \$\_DFF\_P\_} \\ -\lstinline[language=Verilog]; always @* if (!E) Q <= D; & {\tt \$\_DLATCH\_N\_} \\ -\lstinline[language=Verilog]; always @* if (E) Q <= D; & {\tt \$\_DLATCH\_P\_} \\ -\end{tabular} -\caption{Cell types for gate level logic networks (main list)} -\label{tab:CellLib_gates} -\end{table} - -\begin{table}[t] -\hfil -\begin{tabular}[t]{llll} -$ClkEdge$ & $RstLvl$ & $RstVal$ & Cell Type \\ -\hline -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFF\_NN0\_}, {\tt \$\_SDFF\_NN0\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFF\_NN1\_}, {\tt \$\_SDFF\_NN1\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFF\_NP0\_}, {\tt \$\_SDFF\_NP0\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFF\_NP1\_}, {\tt \$\_SDFF\_NP1\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFF\_PN0\_}, {\tt \$\_SDFF\_PN0\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFF\_PN1\_}, {\tt \$\_SDFF\_PN1\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFF\_PP0\_}, {\tt \$\_SDFF\_PP0\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFF\_PP1\_}, {\tt \$\_SDFF\_PP1\_} \\ -\end{tabular} -\caption{Cell types for gate level logic networks (FFs with reset)} -\label{tab:CellLib_gates_adff} -\end{table} - -\begin{table}[t] -\hfil -\begin{tabular}[t]{lll} -$ClkEdge$ & $EnLvl$ & Cell Type \\ -\hline -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_NN\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_NP\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_PN\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_PP\_} \\ -\end{tabular} -\caption{Cell types for gate level logic networks (FFs with enable)} -\label{tab:CellLib_gates_dffe} -\end{table} - -\begin{table}[t] -\begin{tabular}[t]{lllll} -$ClkEdge$ & $RstLvl$ & $RstVal$ & $EnLvl$ & Cell Type \\ -\hline -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_NN0N\_}, {\tt \$\_SDFFE\_NN0N\_}, {\tt \$\_SDFFCE\_NN0N\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_NN0P\_}, {\tt \$\_SDFFE\_NN0P\_}, {\tt \$\_SDFFCE\_NN0P\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_NN1N\_}, {\tt \$\_SDFFE\_NN1N\_}, {\tt \$\_SDFFCE\_NN1N\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_NN1P\_}, {\tt \$\_SDFFE\_NN1P\_}, {\tt \$\_SDFFCE\_NN1P\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_NP0N\_}, {\tt \$\_SDFFE\_NP0N\_}, {\tt \$\_SDFFCE\_NP0N\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_NP0P\_}, {\tt \$\_SDFFE\_NP0P\_}, {\tt \$\_SDFFCE\_NP0P\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_NP1N\_}, {\tt \$\_SDFFE\_NP1N\_}, {\tt \$\_SDFFCE\_NP1N\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_NP1P\_}, {\tt \$\_SDFFE\_NP1P\_}, {\tt \$\_SDFFCE\_NP1P\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_PN0N\_}, {\tt \$\_SDFFE\_PN0N\_}, {\tt \$\_SDFFCE\_PN0N\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_PN0P\_}, {\tt \$\_SDFFE\_PN0P\_}, {\tt \$\_SDFFCE\_PN0P\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_PN1N\_}, {\tt \$\_SDFFE\_PN1N\_}, {\tt \$\_SDFFCE\_PN1N\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_PN1P\_}, {\tt \$\_SDFFE\_PN1P\_}, {\tt \$\_SDFFCE\_PN1P\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_PP0N\_}, {\tt \$\_SDFFE\_PP0N\_}, {\tt \$\_SDFFCE\_PP0N\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_PP0P\_}, {\tt \$\_SDFFE\_PP0P\_}, {\tt \$\_SDFFCE\_PP0P\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFE\_PP1N\_}, {\tt \$\_SDFFE\_PP1N\_}, {\tt \$\_SDFFCE\_PP1N\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFE\_PP1P\_}, {\tt \$\_SDFFE\_PP1P\_}, {\tt \$\_SDFFCE\_PP1P\_} \\ -\end{tabular} -\caption{Cell types for gate level logic networks (FFs with reset and enable)} -\label{tab:CellLib_gates_adffe} -\end{table} - -\begin{table}[t] -\hfil -\begin{tabular}[t]{llll} -$ClkEdge$ & $SetLvl$ & $RstLvl$ & Cell Type \\ -\hline -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSR\_NNN\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSR\_NNP\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSR\_NPN\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSR\_NPP\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSR\_PNN\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSR\_PNP\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSR\_PPN\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSR\_PPP\_} \\ -\end{tabular} -\caption{Cell types for gate level logic networks (FFs with set and reset)} -\label{tab:CellLib_gates_dffsr} -\end{table} - -\begin{table}[t] -\hfil -\begin{tabular}[t]{lllll} -$ClkEdge$ & $SetLvl$ & $RstLvl$ & $EnLvl$ & Cell Type \\ -\hline -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSRE\_NNNN\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSRE\_NNNP\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSRE\_NNPN\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSRE\_NNPP\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSRE\_NPNN\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSRE\_NPNP\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSRE\_NPPN\_} \\ -\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSRE\_NPPP\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSRE\_PNNN\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSRE\_PNNP\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSRE\_PNPN\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSRE\_PNPP\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSRE\_PPNN\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSRE\_PPNP\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFFSRE\_PPPN\_} \\ -\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFFSRE\_PPPP\_} \\ -\end{tabular} -\caption{Cell types for gate level logic networks (FFs with set and reset and enable)} -\label{tab:CellLib_gates_dffsre} -\end{table} - -\begin{table}[t] -\hfil -\begin{tabular}[t]{llll} -$EnLvl$ & $RstLvl$ & $RstVal$ & Cell Type \\ -\hline -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DLATCH\_NN0\_} \\ -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DLATCH\_NN1\_} \\ -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DLATCH\_NP0\_} \\ -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DLATCH\_NP1\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DLATCH\_PN0\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DLATCH\_PN1\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DLATCH\_PP0\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DLATCH\_PP1\_} \\ -\end{tabular} -\caption{Cell types for gate level logic networks (latches with reset)} -\label{tab:CellLib_gates_adlatch} -\end{table} - -\begin{table}[t] -\hfil -\begin{tabular}[t]{llll} -$EnLvl$ & $SetLvl$ & $RstLvl$ & Cell Type \\ -\hline -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DLATCHSR\_NNN\_} \\ -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DLATCHSR\_NNP\_} \\ -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DLATCHSR\_NPN\_} \\ -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DLATCHSR\_NPP\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DLATCHSR\_PNN\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DLATCHSR\_PNP\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DLATCHSR\_PPN\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DLATCHSR\_PPP\_} \\ -\end{tabular} -\caption{Cell types for gate level logic networks (latches with set and reset)} -\label{tab:CellLib_gates_dlatchsr} -\end{table} - -\begin{table}[t] -\hfil -\begin{tabular}[t]{llll} -$SetLvl$ & $RstLvl$ & Cell Type \\ -\hline -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_SR\_NN\_} \\ -\lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_SR\_NP\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_SR\_PN\_} \\ -\lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_SR\_PP\_} \\ -\end{tabular} -\caption{Cell types for gate level logic networks (SR latches)} -\label{tab:CellLib_gates_sr} -\end{table} - -Tables~\ref{tab:CellLib_gates}, \ref{tab:CellLib_gates_dffe}, \ref{tab:CellLib_gates_adff}, \ref{tab:CellLib_gates_adffe}, \ref{tab:CellLib_gates_dffsr}, \ref{tab:CellLib_gates_dffsre}, \ref{tab:CellLib_gates_adlatch}, \ref{tab:CellLib_gates_dlatchsr} and \ref{tab:CellLib_gates_sr} list all cell types used for gate level logic. The cell types -{\tt \$\_BUF\_}, {\tt \$\_NOT\_}, {\tt \$\_AND\_}, {\tt \$\_NAND\_}, {\tt \$\_ANDNOT\_}, -{\tt \$\_OR\_}, {\tt \$\_NOR\_}, {\tt \$\_ORNOT\_}, {\tt \$\_XOR\_}, {\tt \$\_XNOR\_}, -{\tt \$\_AOI3\_}, {\tt \$\_OAI3\_}, {\tt \$\_AOI4\_}, {\tt \$\_OAI4\_}, -{\tt \$\_MUX\_}, {\tt \$\_MUX4\_}, {\tt \$\_MUX8\_}, {\tt \$\_MUX16\_} and {\tt \$\_NMUX\_} are used to model combinatorial logic. -The cell type {\tt \$\_TBUF\_} is used to model tristate logic. - -The {\tt \$\_MUX4\_}, {\tt \$\_MUX8\_} and {\tt \$\_MUX16\_} cells are used to model wide muxes, and correspond to the following Verilog code: - -\begin{lstlisting}[language=Verilog] -// $_MUX4_ -assign Y = T ? (S ? D : C) : - (S ? B : A); -// $_MUX8_ -assign Y = U ? T ? (S ? H : G) : - (S ? F : E) : - T ? (S ? D : C) : - (S ? B : A); -// $_MUX16_ -assign Y = V ? U ? T ? (S ? P : O) : - (S ? N : M) : - T ? (S ? L : K) : - (S ? J : I) : - U ? T ? (S ? H : G) : - (S ? F : E) : - T ? (S ? D : C) : - (S ? B : A); -\end{lstlisting} - -The cell types {\tt \$\_DFF\_N\_} and {\tt \$\_DFF\_P\_} represent d-type flip-flops. - -The cell types {\tt \$\_DFFE\_[NP][NP]\_} -implement d-type flip-flops with enable. The values in the table for these cell types relate to the -following Verilog code template. - -\begin{lstlisting}[mathescape,language=Verilog] - always @($ClkEdge$ C) - if (EN == $EnLvl$) - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_DFF\_[NP][NP][01]\_} implement -d-type flip-flops with asynchronous reset. The values in the table for these cell types relate to the -following Verilog code template, where \lstinline[mathescape,language=Verilog];$RstEdge$; is \lstinline[language=Verilog];posedge; -if \lstinline[mathescape,language=Verilog];$RstLvl$; if \lstinline[language=Verilog];1;, and \lstinline[language=Verilog];negedge; -otherwise. - -\begin{lstlisting}[mathescape,language=Verilog] - always @($ClkEdge$ C, $RstEdge$ R) - if (R == $RstLvl$) - Q <= $RstVal$; - else - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_SDFF\_[NP][NP][01]\_} implement -d-type flip-flops with synchronous reset. The values in the table for these cell types relate to the -following Verilog code template: - -\begin{lstlisting}[mathescape,language=Verilog] - always @($ClkEdge$ C) - if (R == $RstLvl$) - Q <= $RstVal$; - else - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_DFFE\_[NP][NP][01][NP]\_} implement -d-type flip-flops with asynchronous reset and enable. The values in the table for these cell types relate to the -following Verilog code template, where \lstinline[mathescape,language=Verilog];$RstEdge$; is \lstinline[language=Verilog];posedge; -if \lstinline[mathescape,language=Verilog];$RstLvl$; if \lstinline[language=Verilog];1;, and \lstinline[language=Verilog];negedge; -otherwise. - -\begin{lstlisting}[mathescape,language=Verilog] - always @($ClkEdge$ C, $RstEdge$ R) - if (R == $RstLvl$) - Q <= $RstVal$; - else if (EN == $EnLvl$) - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_SDFFE\_[NP][NP][01][NP]\_} implement d-type flip-flops -with synchronous reset and enable, with reset having priority over enable. -The values in the table for these cell types relate to the -following Verilog code template: - -\begin{lstlisting}[mathescape,language=Verilog] - always @($ClkEdge$ C) - if (R == $RstLvl$) - Q <= $RstVal$; - else if (EN == $EnLvl$) - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_SDFFCE\_[NP][NP][01][NP]\_} implement d-type flip-flops -with synchronous reset and enable, with enable having priority over reset. -The values in the table for these cell types relate to the -following Verilog code template: - -\begin{lstlisting}[mathescape,language=Verilog] - always @($ClkEdge$ C) - if (EN == $EnLvl$) - if (R == $RstLvl$) - Q <= $RstVal$; - else - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_DFFSR\_[NP][NP][NP]\_} implement -d-type flip-flops with asynchronous set and reset. The values in the table for these cell types relate to the -following Verilog code template, where \lstinline[mathescape,language=Verilog];$RstEdge$; is \lstinline[language=Verilog];posedge; -if \lstinline[mathescape,language=Verilog];$RstLvl$; if \lstinline[language=Verilog];1;, \lstinline[language=Verilog];negedge; -otherwise, and \lstinline[mathescape,language=Verilog];$SetEdge$; is \lstinline[language=Verilog];posedge; -if \lstinline[mathescape,language=Verilog];$SetLvl$; if \lstinline[language=Verilog];1;, \lstinline[language=Verilog];negedge; -otherwise. - -\begin{lstlisting}[mathescape,language=Verilog] - always @($ClkEdge$ C, $RstEdge$ R, $SetEdge$ S) - if (R == $RstLvl$) - Q <= 0; - else if (S == $SetLvl$) - Q <= 1; - else - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_DFFSRE\_[NP][NP][NP][NP]\_} implement -d-type flip-flops with asynchronous set and reset and enable. The values in the table for these cell types relate to the -following Verilog code template, where \lstinline[mathescape,language=Verilog];$RstEdge$; is \lstinline[language=Verilog];posedge; -if \lstinline[mathescape,language=Verilog];$RstLvl$; if \lstinline[language=Verilog];1;, \lstinline[language=Verilog];negedge; -otherwise, and \lstinline[mathescape,language=Verilog];$SetEdge$; is \lstinline[language=Verilog];posedge; -if \lstinline[mathescape,language=Verilog];$SetLvl$; if \lstinline[language=Verilog];1;, \lstinline[language=Verilog];negedge; -otherwise. - -\begin{lstlisting}[mathescape,language=Verilog] - always @($ClkEdge$ C, $RstEdge$ R, $SetEdge$ S) - if (R == $RstLvl$) - Q <= 0; - else if (S == $SetLvl$) - Q <= 1; - else if (E == $EnLvl$) - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_DLATCH\_N\_} and {\tt \$\_DLATCH\_P\_} represent d-type latches. - -The cell types {\tt \$\_DLATCH\_[NP][NP][01]\_} implement -d-type latches with reset. The values in the table for these cell types relate to the -following Verilog code template: - -\begin{lstlisting}[mathescape,language=Verilog] - always @* - if (R == $RstLvl$) - Q <= $RstVal$; - else if (E == $EnLvl$) - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_DLATCHSR\_[NP][NP][NP]\_} implement -d-type latches with set and reset. The values in the table for these cell types relate to the -following Verilog code template: - -\begin{lstlisting}[mathescape,language=Verilog] - always @* - if (R == $RstLvl$) - Q <= 0; - else if (S == $SetLvl$) - Q <= 1; - else if (E == $EnLvl$) - Q <= D; -\end{lstlisting} - -The cell types {\tt \$\_SR\_[NP][NP]\_} implement -sr-type latches. The values in the table for these cell types relate to the -following Verilog code template: - -\begin{lstlisting}[mathescape,language=Verilog] - always @* - if (R == $RstLvl$) - Q <= 0; - else if (S == $SetLvl$) - Q <= 1; -\end{lstlisting} - -In most cases gate level logic networks are created from RTL networks using the {\tt techmap} pass. The flip-flop cells -from the gate level logic network can be mapped to physical flip-flop cells from a Liberty file using the {\tt dfflibmap} -pass. The combinatorial logic cells can be mapped to physical cells from a Liberty file via ABC \citeweblink{ABC} -using the {\tt abc} pass. - -\begin{fixme} -Add information about {\tt \$slice} and {\tt \$concat} cells. -\end{fixme} - -\begin{fixme} -Add information about {\tt \$lut} and {\tt \$sop} cells. -\end{fixme} - -\begin{fixme} -Add information about {\tt \$alu}, {\tt \$macc}, {\tt \$fa}, and {\tt \$lcu} cells. -\end{fixme} diff --git a/manual/CHAPTER_Eval.tex b/manual/CHAPTER_Eval.tex deleted file mode 100644 index f719618d5..000000000 --- a/manual/CHAPTER_Eval.tex +++ /dev/null @@ -1,209 +0,0 @@ - -\chapter{Evaluation, Conclusion, Future Work} -\label{chapter:eval} - -The Yosys source tree contains over 200 test cases\footnote{Most of this test -cases are copied from HANA \citeweblink{HANA} or the ASIC-WORLD website -\citeweblink{ASIC-WORLD}.} which are used in the {\tt make test} make-target. -Besides these there is an external Yosys benchmark and test case package that -contains a few larger designs \citeweblink{YosysTestsGit}. This package -contains the designs listed in Tab.~\ref{tab:yosys-test-designs}. - -\begin{table} - \hfil - \begin{tabular}{lrrp{8.5cm}} - Test-Design & Source & Gates\footnotemark & Description / Comments \\ - \hline - {\tt aes\_core} & IWLS2005 & $ 41{,}837 $ & \footnotesize AES Cipher written by Rudolf Usselmann \\ - {\tt i2c} & IWLS2005 & $ 1{,}072 $ & \footnotesize WISHBONE compliant I2C Master by Richard Herveille \\ - {\tt openmsp430} & OpenCores & $ 7{,}173 $ & \footnotesize MSP430 compatible CPU by Olivier Girard \\ - {\tt or1200} & OpenCores & $ 42{,}675 $ & \footnotesize The OpenRISC 1200 CPU by Damjan Lampret \\ - {\tt sasc} & IWLS2005 & $ 456 $ & \footnotesize Simple Async. Serial Comm. Device by Rudolf Usselmann \\ - {\tt simple\_spi} & IWLS2005 & $ 690 $ & \footnotesize MC68HC11E based SPI interface by Richard Herveille \\ - {\tt spi} & IWLS2005 & $ 2{,}478 $ & \footnotesize SPI IP core by Simon Srot \\ - {\tt ss\_pcm} & IWLS2005 & $ 279 $ & \footnotesize PCM IO Slave by Rudolf Usselmann \\ - {\tt systemcaes} & IWLS2005 & $ 6{,}893 $ & \footnotesize AES core (using SystemC to Verilog) by Javier Castillo \\ - {\tt usb\_phy} & IWLS2005 & $ 515 $ & \footnotesize USB 1.1 PHY by Rudolf Usselmann \\ - \end{tabular} - \caption{Tests included in the yosys-tests package.} - \label{tab:yosys-test-designs} -\end{table} - -\footnotetext{ -Number of gates determined using the Yosys synthesis script ``{\tt hierarchy -top \$top; proc; opt; memory; opt; techmap; opt; abc; opt; flatten \$top; hierarchy -top \$top; abc; opt; select -count */c:*}''. -} - -\section{Correctness of Synthesis Results} - -The following measures were taken to increase the confidence in the correctness of the Yosys synthesis results: - -\begin{itemize} -\item Yosys comes with a large selection\footnote{At the time of this writing -269 test cases.} of small test cases that are evaluated when the command {\tt -make test} is executed. During development of Yosys it was shown that this -collection of test cases is sufficient to catch most bugs. The following more -sophisticated test procedures only caught a few additional bugs. Whenever this -happened, an appropriate test case was added to the collection of small test -cases for {\tt make test} to ensure better testability of the feature in -question in the future. - -\item The designs listed in Tab.~\ref{tab:yosys-test-designs} where validated -using the formal verification tool Synopsys Formality\citeweblink{Formality}. -The Yosys synthesis scripts used to synthesize the individual designs for this -test are slightly different per design in order to broaden the coverage of -Yosys features. The large majority of all errors encountered using these tests -are false-negatives, mostly related to FSM encoding or signal naming in large -array logic (such as in memory blocks). Therefore the {\tt fsm\_recode} pass -was extended so it can be used to generate TCL commands for Synopsys Formality -that describe the relationship between old and new state encodings. Also the -method used to generate signal and cell names in the Verilog backend was -slightly modified in order to improve the automatic matching of net names in -Synopsys Formality. With these changes in place all designs in Tab.~\ref{tab:yosys-test-designs} -validate successfully using Formality. - -\item VlogHammer \citeweblink{VlogHammer} is a set of scripts that -auto-generate a large collection of test cases\footnote{At the time of this -writing over 6600 test cases.} and synthesize them using Yosys and the -following freely available proprietary synthesis tools. -\begin{itemize} -\item Xilinx Vivado WebPack (2013.2) \citeweblink{XilinxWebPACK} -\item Xilinx ISE (XST) WebPack (14.5) \citeweblink{XilinxWebPACK} -\item Altera Quartus II Web Edition (13.0) \citeweblink{QuartusWeb} -\end{itemize} -The built-in SAT solver of Yosys is used to formally -verify the Yosys RTL- and Gate-Level netlists against the netlists generated by -this other tools.\footnote{A SAT solver is a program that can solve the boolean -satisfiability problem. The built-in SAT solver in Yosys can be used for formal -equivalence checking, amongst other things. See Sec.~\ref{cmd:sat} for details.} -When differences are found, the input pattern that result in -different outputs are used for simulating the original Verilog code as well as -the synthesis results using the following Verilog simulators. -\begin{itemize} -\item Xilinx ISIM (from Xilinx ISE 14.5 \citeweblink{XilinxWebPACK}) -\item Modelsim 10.1d (from Quartus II 13.0 \citeweblink{QuartusWeb}) -\item Icarus Verilog (no specific version) -\end{itemize} -The set of tests performed by VlogHammer systematically verify the correct -behaviour of -\begin{itemize} -\item Yosys Verilog Frontend and RTL generation -\item Yosys Gate-Level Technology Mapping -\item Yosys SAT Models for RTL- and Gate-Level cells -\item Yosys Constant Evaluator Models for RTL- and Gate-Level cells -\end{itemize} -against the reference provided by the other tools. A few bugs related to sign -extensions and bit-width extensions where found (and have been fixed meanwhile) -using this approach. This test also revealed a small number of bugs in the -other tools (i.e.~Vivado, XST, Quartus, ISIM and Icarus Verilog; no bugs where -found in Modelsim using vlogHammer so far). -\end{itemize} - -Although complex software can never be expected to be fully bug-free -\cite{MURPHY}, it has been shown that Yosys is mature and feature-complete -enough to handle most real-world cases correctly. - -\section{Quality of synthesis results} - -In this section an attempt to evaluate the quality of Yosys synthesis results is made. To this end the -synthesis results of a commercial FPGA synthesis tool when presented with the original HDL code vs.~when -presented with the Yosys synthesis result are compared. - -The OpenMSP430 and the OpenRISC 1200 test cases were synthesized using the following Yosys synthesis script: - -\begin{lstlisting}[numbers=left,frame=single,mathescape] -hierarchy -check -proc; opt; fsm; opt; memory; opt -techmap; opt; abc; opt -\end{lstlisting} - -The original RTL and the Yosys output where both passed to the Xilinx XST 14.5 -FPGA synthesis tool. The following setting where used for XST: - -\begin{lstlisting}[numbers=left,frame=single,mathescape] --p artix7 --use_dsp48 NO --iobuf NO --ram_extract NO --rom_extract NO --fsm_extract YES --fsm_encoding Auto -\end{lstlisting} - -The results of this comparison is summarized in Tab.~\ref{tab:synth-test}. The -used FPGA resources (registers and LUTs) and performance (maximum frequency as -reported by XST) are given per module (indentation indicates module hierarchy, -the numbers are including all contained modules). - -For most modules the results are very similar between XST and Yosys. XST is -used in both cases for the final mapping of logic to LUTs. So this comparison -only compares the high-level synthesis functions (such as FSM extraction and -encoding) of Yosys and XST. - -\begin{table} - \def\nomhz{--- \phantom{MHz}} - \def\P#1 {(#1\hbox to 0px{)\hss}} - \hfil - \begin{tabular}{l|rrr|rrr} - & \multicolumn{3}{c|}{Without Yosys} & \multicolumn{3}{c}{With Yosys} \\ - Module & Regs & LUTs & Max. Freq. & Regs & LUTs & Max. Freq. \\ - \hline - {\tt openMSP430} & 689 & 2210 & 71 MHz & 719 & 2779 & 53 MHz \\ - {\tt \hskip1em omsp\_clock\_module} & 21 & 30 & 645 MHz & 21 & 30 & 644 MHz \\ - {\tt \hskip1em \hskip1em omsp\_sync\_cell} & 2 & --- & 1542 MHz & 2 & --- & 1542 MHz \\ - {\tt \hskip1em \hskip1em omsp\_sync\_reset} & 2 & --- & 1542 MHz & 2 & --- & 1542 MHz \\ - {\tt \hskip1em omsp\_dbg} & 143 & 344 & 292 MHz & 149 & 430 & 353 MHz \\ - {\tt \hskip1em \hskip1em omsp\_dbg\_uart} & 76 & 135 & 377 MHz & 79 & 139 & 389 MHz \\ - {\tt \hskip1em omsp\_execution\_unit} & 266 & 911 & 80 MHz & 266 & 1034 & 137 MHz \\ - {\tt \hskip1em \hskip1em omsp\_alu} & --- & 202 & \nomhz & --- & 263 & \nomhz \\ - {\tt \hskip1em \hskip1em omsp\_register\_file} & 231 & 478 & 285 MHz & 231 & 506 & 293 MHz \\ - {\tt \hskip1em omsp\_frontend} & 115 & 340 & 178 MHz & 118 & 527 & 206 MHz \\ - {\tt \hskip1em omsp\_mem\_backbone} & 38 & 141 & 1087 MHz & 38 & 144 & 1087 MHz \\ - {\tt \hskip1em omsp\_multiplier} & 73 & 397 & 129 MHz & 102 & 1053 & 55 MHz \\ - {\tt \hskip1em omsp\_sfr} & 6 & 18 & 1023 MHz & 6 & 20 & 1023 MHz \\ - {\tt \hskip1em omsp\_watchdog} & 24 & 53 & 362 MHz & 24 & 70 & 360 MHz \\ - \hline - {\tt or1200\_top} & 7148 & 9969 & 135 MHz & 7173 & 10238 & 108 MHz \\ - {\tt \hskip1em or1200\_alu} & --- & 681 & \nomhz & --- & 641 & \nomhz \\ - {\tt \hskip1em or1200\_cfgr} & --- & 11 & \nomhz & --- & 11 & \nomhz \\ - {\tt \hskip1em or1200\_ctrl} & 175 & 186 & 464 MHz & 174 & 279 & 377 MHz \\ - {\tt \hskip1em or1200\_except} & 241 & 451 & 313 MHz & 241 & 353 & 301 MHz \\ - {\tt \hskip1em or1200\_freeze} & 6 & 18 & 507 MHz & 6 & 16 & 515 MHz \\ - {\tt \hskip1em or1200\_if} & 68 & 143 & 806 MHz & 68 & 139 & 790 MHz \\ - {\tt \hskip1em or1200\_lsu} & 8 & 138 & \nomhz & 12 & 205 & 1306 MHz \\ - {\tt \hskip1em \hskip1em or1200\_mem2reg} & --- & 60 & \nomhz & --- & 66 & \nomhz \\ - {\tt \hskip1em \hskip1em or1200\_reg2mem} & --- & 29 & \nomhz & --- & 29 & \nomhz \\ - {\tt \hskip1em or1200\_mult\_mac} & 394 & 2209 & 240 MHz & 394 & 2230 & 241 MHz \\ - {\tt \hskip1em \hskip1em or1200\_amultp2\_32x32} & 256 & 1783 & 240 MHz & 256 & 1770 & 241 MHz \\ - {\tt \hskip1em or1200\_operandmuxes} & 65 & 129 & 1145 MHz & 65 & 129 & 1145 MHz \\ - {\tt \hskip1em or1200\_rf} & 1041 & 1722 & 822 MHz & 1042 & 1722 & 581 MHz \\ - {\tt \hskip1em or1200\_sprs} & 18 & 432 & 724 MHz & 18 & 469 & 722 MHz \\ - {\tt \hskip1em or1200\_wbmux} & 33 & 93 & \nomhz & 33 & 78 & \nomhz \\ - {\tt \hskip1em or1200\_dc\_top} & --- & 5 & \nomhz & --- & 5 & \nomhz \\ - {\tt \hskip1em or1200\_dmmu\_top} & 2445 & 1004 & \nomhz & 2445 & 1043 & \nomhz \\ - {\tt \hskip1em \hskip1em or1200\_dmmu\_tlb} & 2444 & 975 & \nomhz & 2444 & 1013 & \nomhz \\ - {\tt \hskip1em or1200\_du} & 67 & 56 & 859 MHz & 67 & 56 & 859 MHz \\ - {\tt \hskip1em or1200\_ic\_top} & 39 & 100 & 527 MHz & 41 & 136 & 514 MHz \\ - {\tt \hskip1em \hskip1em or1200\_ic\_fsm} & 40 & 42 & 408 MHz & 40 & 75 & 484 MHz \\ - {\tt \hskip1em or1200\_pic} & 38 & 50 & 1169 MHz & 38 & 50 & 1177 MHz \\ - {\tt \hskip1em or1200\_tt} & 64 & 112 & 370 MHz & 64 & 186 & 437 MHz \\ - \end{tabular} - \caption{Synthesis results (as reported by XST) for OpenMSP430 and OpenRISC 1200} - \label{tab:synth-test} -\end{table} - -\section{Conclusion and Future Work} - -Yosys is capable of correctly synthesizing real-world Verilog designs. The -generated netlists are of a decent quality. However, in cases where dedicated -hardware resources should be used for certain functions it is of course -necessary to implement proper technology mapping for these functions in -Yosys. This can be as easy as calling the {\tt techmap} pass with an -architecture-specific mapping file in the synthesis script. As no such thing -has been done in the above tests, it is only natural that the resulting designs -cannot benefit from these dedicated hardware resources. - -Therefore future work includes the implementation of architecture-specific -technology mappings besides additional frontends (VHDL), backends (EDIF), -and above all else, application specific passes. After all, this was -the main motivation for the development of Yosys in the first place. - diff --git a/manual/CHAPTER_Eval/grep-it.sh b/manual/CHAPTER_Eval/grep-it.sh deleted file mode 100644 index 0f4f95ae5..000000000 --- a/manual/CHAPTER_Eval/grep-it.sh +++ /dev/null @@ -1,84 +0,0 @@ -#!/bin/bash - -openmsp430_mods=" -omsp_alu -omsp_clock_module -omsp_dbg -omsp_dbg_uart -omsp_execution_unit -omsp_frontend -omsp_mem_backbone -omsp_multiplier -omsp_register_file -omsp_sfr -omsp_sync_cell -omsp_sync_reset -omsp_watchdog -openMSP430" - -or1200_mods=" -or1200_alu -or1200_amultp2_32x32 -or1200_cfgr -or1200_ctrl -or1200_dc_top -or1200_dmmu_tlb -or1200_dmmu_top -or1200_du -or1200_except -or1200_fpu -or1200_freeze -or1200_ic_fsm -or1200_ic_ram -or1200_ic_tag -or1200_ic_top -or1200_if -or1200_immu_tlb -or1200_lsu -or1200_mem2reg -or1200_mult_mac -or1200_operandmuxes -or1200_pic -or1200_pm -or1200_qmem_top -or1200_reg2mem -or1200_rf -or1200_sb -or1200_sprs -or1200_top -or1200_tt -or1200_wbmux" - -grep_regs() { - x=$(grep '^ Number of Slice Registers:' $1.syr | sed 's/.*: *//;' | cut -f1 -d' ') - echo $x | sed 's,^ *$,-1,' -} - -grep_luts() { - x=$(grep '^ Number of Slice LUTs:' $1.syr | sed 's/.*: *//;' | cut -f1 -d' ') - echo $x | sed 's,^ *$,-1,' -} - -grep_freq() { - x=$(grep 'Minimum period.*Maximum Frequency' $1.syr | sed 's/\.[0-9]*MHz.*//;' | cut -f3 -d:) - echo $x | sed 's,^ *$,-1,' -} - -for mod in $openmsp430_mods $or1200_mods; do - printf '%-30s s,$, \\& %6d \\& %6d \\& %4d MHz \\& %6d \\& %6d \\& %4d MHz \\\\\\\\,;\n' "/${mod//_/\\\\_}}/" \ - $(grep_regs ${mod}) $(grep_luts ${mod}) $(grep_freq ${mod}) \ - $(grep_regs ${mod}_ys) $(grep_luts ${mod}_ys) $(grep_freq ${mod}_ys) -done - -# for mod in $openmsp430_mods $or1200_mods; do -# [ $mod = "or1200_top" -o $mod = "or1200_dmmu_top" -o $mod = or1200_dmmu_tlb -o $mod = or1200_immu_tlb ] && continue -# regs=$(grep_regs ${mod}) regs_ys=$(grep_regs ${mod}_ys) -# luts=$(grep_luts ${mod}) luts_ys=$(grep_luts ${mod}_ys) -# freq=$(grep_freq ${mod}) freq_ys=$(grep_freq ${mod}_ys) -# if [ $regs -gt 0 -a $regs_ys -gt 0 ]; then regs_p=$(( 100*regs_ys / regs )); else regs_p=NaN; fi -# if [ $luts -gt 0 -a $luts_ys -gt 0 ]; then luts_p=$(( 100*luts_ys / luts )); else luts_p=NaN; fi -# if [ $freq -gt 0 -a $freq_ys -gt 0 ]; then freq_p=$(( 100*freq_ys / freq )); else freq_p=NaN; fi -# printf '%-30s %3s %3s %3s\n' $mod $regs_p $luts_p $freq_p -# -# done - diff --git a/manual/CHAPTER_Eval/openmsp430.prj b/manual/CHAPTER_Eval/openmsp430.prj deleted file mode 100644 index cb8cd2714..000000000 --- a/manual/CHAPTER_Eval/openmsp430.prj +++ /dev/null @@ -1,14 +0,0 @@ -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_sync_cell.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_sync_reset.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_register_file.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_dbg_uart.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_alu.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_watchdog.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_sfr.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_multiplier.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_mem_backbone.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_frontend.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_execution_unit.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_dbg.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/omsp_clock_module.v" -verilog work "../../../../../Work/yosys-tests/openmsp430/rtl/openMSP430.v" diff --git a/manual/CHAPTER_Eval/openmsp430_ys.prj b/manual/CHAPTER_Eval/openmsp430_ys.prj deleted file mode 100644 index 0009c99dc..000000000 --- a/manual/CHAPTER_Eval/openmsp430_ys.prj +++ /dev/null @@ -1 +0,0 @@ -verilog work "openmsp430_ys.v" diff --git a/manual/CHAPTER_Eval/or1200.prj b/manual/CHAPTER_Eval/or1200.prj deleted file mode 100644 index 9496874e0..000000000 --- a/manual/CHAPTER_Eval/or1200.prj +++ /dev/null @@ -1,37 +0,0 @@ -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_spram.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_reg2mem.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_mem2reg.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_dpram.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_amultp2_32x32.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_wbmux.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_sprs.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_rf.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_operandmuxes.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_mult_mac.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_lsu.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_immu_tlb.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_if.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_ic_tag.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_ic_ram.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_ic_fsm.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_genpc.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_freeze.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_fpu.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_except.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_dmmu_tlb.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_ctrl.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_cfgr.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_alu.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_wb_biu.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_tt.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_sb.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_qmem_top.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_pm.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_pic.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_immu_top.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_ic_top.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_du.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_dmmu_top.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_dc_top.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_cpu.v" -verilog work "../../../../../Work/yosys-tests/or1200/rtl/or1200_top.v" diff --git a/manual/CHAPTER_Eval/or1200_ys.prj b/manual/CHAPTER_Eval/or1200_ys.prj deleted file mode 100644 index 4dd5f41a0..000000000 --- a/manual/CHAPTER_Eval/or1200_ys.prj +++ /dev/null @@ -1 +0,0 @@ -verilog work "or1200_ys.v" diff --git a/manual/CHAPTER_Eval/run-it.sh b/manual/CHAPTER_Eval/run-it.sh deleted file mode 100644 index b4a67cebd..000000000 --- a/manual/CHAPTER_Eval/run-it.sh +++ /dev/null @@ -1,74 +0,0 @@ -#!/bin/bash - -openmsp430_mods=" -omsp_alu -omsp_clock_module -omsp_dbg -omsp_dbg_uart -omsp_execution_unit -omsp_frontend -omsp_mem_backbone -omsp_multiplier -omsp_register_file -omsp_sfr -omsp_sync_cell -omsp_sync_reset -omsp_watchdog -openMSP430" - -or1200_mods=" -or1200_alu -or1200_amultp2_32x32 -or1200_cfgr -or1200_ctrl -or1200_dc_top -or1200_dmmu_tlb -or1200_dmmu_top -or1200_du -or1200_except -or1200_fpu -or1200_freeze -or1200_ic_fsm -or1200_ic_ram -or1200_ic_tag -or1200_ic_top -or1200_if -or1200_immu_tlb -or1200_lsu -or1200_mem2reg -or1200_mult_mac -or1200_operandmuxes -or1200_pic -or1200_pm -or1200_qmem_top -or1200_reg2mem -or1200_rf -or1200_sb -or1200_sprs -or1200_top -or1200_tt -or1200_wbmux" - -yosys_cmds="hierarchy -check; proc; opt; fsm; opt; memory; opt; techmap; opt; abc; opt" - -yosys -p "$yosys_cmds" -o openmsp430_ys.v $( cut -f2 -d'"' openmsp430.prj ) -yosys -p "$yosys_cmds" -o or1200_ys.v $( cut -f2 -d'"' or1200.prj ) - -. /opt/Xilinx/14.5/ISE_DS/settings64.sh - -run_single() { - prj_file=$1 top_module=$2 out_file=$3 - sed "s/@prj_file@/$prj_file/g; s/@out_file@/$out_file/g; s/@top_module@/$top_module/g;" < settings.xst > ${out_file}.xst - xst -ifn ${out_file}.xst -ofn ${out_file}.syr -} - -for mod in $openmsp430_mods; do - run_single openmsp430.prj ${mod} ${mod} - run_single openmsp430_ys.prj ${mod} ${mod}_ys -done - -for mod in $or1200_mods; do - run_single or1200.prj ${mod} ${mod} - run_single or1200_ys.prj ${mod} ${mod}_ys -done - diff --git a/manual/CHAPTER_Eval/settings.xst b/manual/CHAPTER_Eval/settings.xst deleted file mode 100644 index 2f381d09d..000000000 --- a/manual/CHAPTER_Eval/settings.xst +++ /dev/null @@ -1,2 +0,0 @@ -run -ifn @prj_file@ -ofn @out_file@ -ofmt NGC -top @top_module@ -p artix7 --use_dsp48 NO -iobuf NO -ram_extract NO -rom_extract NO -fsm_extract YES -fsm_encoding Auto diff --git a/manual/CHAPTER_Intro.tex b/manual/CHAPTER_Intro.tex deleted file mode 100644 index 76e5d847b..000000000 --- a/manual/CHAPTER_Intro.tex +++ /dev/null @@ -1,98 +0,0 @@ - -\chapter{Introduction} -\label{chapter:intro} - -This document presents the Free and Open Source (FOSS) Verilog HDL synthesis tool ``Yosys''. -Its design and implementation as well as its performance on real-world designs -is discussed in this document. - -\section{History of Yosys} - -A Hardware Description Language (HDL) is a computer language used to describe -circuits. A HDL synthesis tool is a computer program that takes a formal -description of a circuit written in an HDL as input and generates a netlist -that implements the given circuit as output. - -Currently the most widely used and supported HDLs for digital circuits are -Verilog \cite{Verilog2005}\cite{VerilogSynth} and -VHDL\footnote{VHDL is an acronym for ``VHSIC hardware description language'' -and VHSIC is an acronym for ``Very-High-Speed Integrated -Circuits''.} \cite{VHDL}\cite{VHDLSynth}. -Both HDLs are used for test and verification purposes as well as logic -synthesis, resulting in a set of synthesizable and a set of non-synthesizable -language features. In this document we only look at the synthesizable subset -of the language features. - -In recent work on heterogeneous coarse-grain reconfigurable -logic \cite{intersynth} the need for a custom application-specific HDL synthesis -tool emerged. It was soon realised that a synthesis tool that understood Verilog -or VHDL would be preferred over a synthesis tool for a custom HDL. Given an -existing Verilog or VHDL front end, the work for writing the necessary -additional features and integrating them in an existing tool can be estimated to be -about the same as writing a new tool with support for a minimalistic custom HDL. - -The proposed custom HDL synthesis tool should be licensed under a Free -and Open Source Software (FOSS) licence. So an existing FOSS Verilog or VHDL -synthesis tool would have been needed as basis to build upon. The main advantages -of choosing Verilog or VHDL is the ability to synthesize existing HDL code and -to mitigate the requirement for circuit-designers to learn a new language. In order to take full advantage of any existing FOSS Verilog or VHDL tool, -such a tool would have to provide a feature-complete implementation of the -synthesizable HDL subset. - -Basic RTL synthesis is a well understood field \cite{LogicSynthesis}. Lexing, -parsing and processing of computer languages \cite{Dragonbook} is a thoroughly -researched field. All the information required to write such tools has been openly -available for a long time, and it is therefore likely that a FOSS HDL synthesis tool -with a feature-complete Verilog or VHDL front end must exist which can be used as a basis for a custom RTL synthesis tool. - -Due to the author's preference for Verilog over VHDL it was decided early -on to go for Verilog instead of VHDL\footnote{A quick investigation into FOSS -VHDL tools yielded similar grim results for FOSS VHDL synthesis tools.}. -So the existing FOSS Verilog synthesis tools were evaluated (see -App.~\ref{chapter:sota}). The results of this evaluation are utterly -devastating. Therefore a completely new Verilog synthesis tool was implemented -and is recommended as basis for custom synthesis tools. This is the tool that -is discussed in this document. - -\section{Structure of this Document} - -The structure of this document is as follows: - -Chapter~\ref{chapter:intro} is this introduction. - -Chapter~\ref{chapter:basics} covers a short introduction to the world of HDL -synthesis. Basic principles and the terminology are outlined in this chapter. - -Chapter~\ref{chapter:approach} gives the quickest possible outline to how the -problem of implementing a HDL synthesis tool is approached in the case of -Yosys. - -Chapter~\ref{chapter:overview} contains a more detailed overview of the -implementation of Yosys. This chapter covers the data structures used in -Yosys to represent a design in detail and is therefore recommended reading -for everyone who is interested in understanding the Yosys internals. - -Chapter~\ref{chapter:celllib} covers the internal cell library used by Yosys. -This is especially important knowledge for anyone who wants to understand the -intermediate netlists used internally by Yosys. - -Chapter~ \ref{chapter:prog} gives a tour to the internal APIs of Yosys. This -is recommended reading for everyone who actually wants to read or write -Yosys source code. The chapter concludes with an example loadable module -for Yosys. - -Chapters~\ref{chapter:verilog}, \ref{chapter:opt}, and \ref{chapter:techmap} -cover three important pieces of the synthesis pipeline: The Verilog frontend, -the optimization passes and the technology mapping to the target architecture, -respectively. - -Chapter~\ref{chapter:eval} covers the evaluation of the performance -(correctness and quality) of Yosys on real-world input data. -The chapter concludes the main part of this document with conclusions and -outlook to future work. - -Various appendices, including a command reference manual -(App.~\ref{commandref}) and an evaluation of pre-existing FOSS Verilog -synthesis tools (App.~\ref{chapter:sota}) complete this document. - - diff --git a/manual/CHAPTER_Optimize.tex b/manual/CHAPTER_Optimize.tex deleted file mode 100644 index eee92ef5c..000000000 --- a/manual/CHAPTER_Optimize.tex +++ /dev/null @@ -1,324 +0,0 @@ - -\chapter{Optimizations} -\label{chapter:opt} - -Yosys employs a number of optimizations to generate better and cleaner results. -This chapter outlines these optimizations. - -\section{Simple Optimizations} - -The Yosys pass {\tt opt} runs a number of simple optimizations. This includes removing unused -signals and cells and const folding. It is recommended to run this pass after each major step -in the synthesis script. At the time of this writing the {\tt opt} pass executes the following -passes that each perform a simple optimization: - -\begin{itemize} -\item Once at the beginning of {\tt opt}: -\begin{itemize} -\item {\tt opt\_expr} -\item {\tt opt\_merge -nomux} -\end{itemize} -\item Repeat until result is stable: -\begin{itemize} -\item {\tt opt\_muxtree} -\item {\tt opt\_reduce} -\item {\tt opt\_merge} -\item {\tt opt\_rmdff} -\item {\tt opt\_clean} -\item {\tt opt\_expr} -\end{itemize} -\end{itemize} - -The following section describes each of the {\tt opt\_*} passes. - -\subsection{The opt\_expr pass} - -This pass performs const folding on the internal combinational cell types -described in Chap.~\ref{chapter:celllib}. This means a cell with all constant -inputs is replaced with the constant value this cell drives. In some cases -this pass can also optimize cells with some constant inputs. - -\begin{table} - \hfil - \begin{tabular}{cc|c} - A-Input & B-Input & Replacement \\ - \hline - any & 0 & 0 \\ - 0 & any & 0 \\ - 1 & 1 & 1 \\ - \hline - X/Z & X/Z & X \\ - 1 & X/Z & X \\ - X/Z & 1 & X \\ - \hline - any & X/Z & 0 \\ - X/Z & any & 0 \\ - \hline - $a$ & 1 & $a$ \\ - 1 & $b$ & $b$ \\ - \end{tabular} - \caption{Const folding rules for {\tt\$\_AND\_} cells as used in {\tt opt\_expr}.} - \label{tab:opt_expr_and} -\end{table} - -Table~\ref{tab:opt_expr_and} shows the replacement rules used for optimizing -an {\tt\$\_AND\_} gate. The first three rules implement the obvious const folding -rules. Note that `any' might include dynamic values calculated by other parts -of the circuit. The following three lines propagate undef (X) states. -These are the only three cases in which it is allowed to propagate an undef -according to Sec.~5.1.10 of IEEE Std. 1364-2005 \cite{Verilog2005}. - -The next two lines assume the value 0 for undef states. These two rules are only -used if no other substitutions are possible in the current module. If other substitutions -are possible they are performed first, in the hope that the `any' will change to -an undef value or a 1 and therefore the output can be set to undef. - -The last two lines simply replace an {\tt\$\_AND\_} gate with one constant-1 -input with a buffer. - -Besides this basic const folding the {\tt opt\_expr} pass can replace 1-bit wide -{\tt \$eq} and {\tt \$ne} cells with buffers or not-gates if one input is constant. - -The {\tt opt\_expr} pass is very conservative regarding optimizing {\tt \$mux} cells, -as these cells are often used to model decision-trees and breaking these trees can -interfere with other optimizations. - -\subsection{The opt\_muxtree pass} - -This pass optimizes trees of multiplexer cells by analyzing the select inputs. -Consider the following simple example: - -\begin{lstlisting}[numbers=left,frame=single,language=Verilog] -module uut(a, y); -input a; -output [1:0] y = a ? (a ? 1 : 2) : 3; -endmodule -\end{lstlisting} - -The output can never be 2, as this would require \lstinline[language=Verilog];a; -to be 1 for the outer multiplexer and 0 for the inner multiplexer. The {\tt -opt\_muxtree} pass detects this contradiction and replaces the inner multiplexer -with a constant 1, yielding the logic for \lstinline[language=Verilog];y = a ? 1 : 3;. - -\subsection{The opt\_reduce pass} - -\begin{sloppypar} -This is a simple optimization pass that identifies and consolidates identical input -bits to {\tt \$reduce\_and} and {\tt \$reduce\_or} cells. It also sorts the input -bits to ease identification of shareable {\tt \$reduce\_and} and {\tt \$reduce\_or} cells -in other passes. -\end{sloppypar} - -This pass also identifies and consolidates identical inputs to multiplexer cells. In this -case the new shared select bit is driven using a {\tt \$reduce\_or} cell that combines -the original select bits. - -Lastly this pass consolidates trees of {\tt \$reduce\_and} cells and trees of -{\tt \$reduce\_or} cells to single large {\tt \$reduce\_and} or {\tt \$reduce\_or} cells. - -These three simple optimizations are performed in a loop until a stable result is -produced. - -\subsection{The opt\_rmdff pass} - -This pass identifies single-bit d-type flip-flops ({\tt \$\_DFF\_*}, {\tt \$dff}, and {\tt -\$adff} cells) with a constant data input and replaces them with a constant driver. - -\subsection{The opt\_clean pass} - -This pass identifies unused signals and cells and removes them from the design. It also -creates an \B{unused\_bits} attribute on wires with unused bits. This attribute can be -used for debugging or by other optimization passes. - -\subsection{The opt\_merge pass} - -This pass performs trivial resource sharing. This means that this pass identifies cells -with identical inputs and replaces them with a single instance of the cell. - -The option {\tt -nomux} can be used to disable resource sharing for multiplexer -cells ({\tt \$mux} and {\tt \$pmux}. This can be useful as -it prevents multiplexer trees to be merged, which might prevent {\tt opt\_muxtree} -to identify possible optimizations. - -\section{FSM Extraction and Encoding} - -The {\tt fsm} pass performs finite-state-machine (FSM) extraction and recoding. The {\tt fsm} -pass simply executes the following other passes: - -\begin{itemize} -\item Identify and extract FSMs: -\begin{itemize} -\item {\tt fsm\_detect} -\item {\tt fsm\_extract} -\end{itemize} - -\item Basic optimizations: -\begin{itemize} -\item {\tt fsm\_opt} -\item {\tt opt\_clean} -\item {\tt fsm\_opt} -\end{itemize} - -\item Expanding to nearby gate-logic (if called with {\tt -expand}): -\begin{itemize} -\item {\tt fsm\_expand} -\item {\tt opt\_clean} -\item {\tt fsm\_opt} -\end{itemize} - -\item Re-code FSM states (unless called with {\tt -norecode}): -\begin{itemize} -\item {\tt fsm\_recode} -\end{itemize} - -\item Print information about FSMs: -\begin{itemize} -\item {\tt fsm\_info} -\end{itemize} - -\item Export FSMs in KISS2 file format (if called with {\tt -export}): -\begin{itemize} -\item {\tt fsm\_export} -\end{itemize} - -\item Map FSMs to RTL cells (unless called with {\tt -nomap}): -\begin{itemize} -\item {\tt fsm\_map} -\end{itemize} -\end{itemize} - -The {\tt fsm\_detect} pass identifies FSM state registers and marks them using the -\B{fsm\_encoding}{\tt = "auto"} attribute. The {\tt fsm\_extract} extracts all -FSMs marked using the \B{fsm\_encoding} attribute (unless \B{fsm\_encoding} is -set to {\tt "none"}) and replaces the corresponding RTL cells with a {\tt \$fsm} -cell. All other {\tt fsm\_*} passes operate on these {\tt \$fsm} cells. The -{\tt fsm\_map} call finally replaces the {\tt \$fsm} cells with RTL cells. - -Note that these optimizations operate on an RTL netlist. I.e.~the {\tt fsm} pass -should be executed after the {\tt proc} pass has transformed all -{\tt RTLIL::Process} objects to RTL cells. - -The algorithms used for FSM detection and extraction are influenced by a more -general reported technique \cite{fsmextract}. - -\subsection{FSM Detection} - -The {\tt fsm\_detect} pass identifies FSM state registers. It sets the -\B{fsm\_encoding}{\tt = "auto"} attribute on any (multi-bit) wire that matches -the following description: - -\begin{itemize} -\item Does not already have the \B{fsm\_encoding} attribute. -\item Is not an output of the containing module. -\item Is driven by single {\tt \$dff} or {\tt \$adff} cell. -\item The \B{D}-Input of this {\tt \$dff} or {\tt \$adff} cell is driven by a multiplexer -tree that only has constants or the old state value on its leaves. -\item The state value is only used in the said multiplexer tree or by simple relational -cells that compare the state value to a constant (usually {\tt \$eq} cells). -\end{itemize} - -This heuristic has proven to work very well. It is possible to overwrite it by setting -\B{fsm\_encoding}{\tt = "auto"} on registers that should be considered FSM state registers -and setting \B{fsm\_encoding}{\tt = "none"} on registers that match the above criteria -but should not be considered FSM state registers. - -Note however that marking state registers with \B{fsm\_encoding} that are not -suitable for FSM recoding can cause synthesis to fail or produce invalid -results. - -\subsection{FSM Extraction} - -The {\tt fsm\_extract} pass operates on all state signals marked with the -\B{fsm\_encoding} ({\tt != "none"}) attribute. For each state signal the following -information is determined: - -\begin{itemize} -\item The state registers -\item The asynchronous reset state if the state registers use asynchronous reset -\item All states and the control input signals used in the state transition functions -\item The control output signals calculated from the state signals and control inputs -\item A table of all state transitions and corresponding control inputs- and outputs -\end{itemize} - -The state registers (and asynchronous reset state, if applicable) is simply determined -by identifying the driver for the state signal. - -From there the {\tt \$mux}-tree driving the state register inputs is -recursively traversed. All select inputs are control signals and the leaves of the -{\tt \$mux}-tree are the states. The algorithm fails if a non-constant leaf -that is not the state signal itself is found. - -The list of control outputs is initialized with the bits from the state signal. -It is then extended by adding all values that are calculated by cells that -compare the state signal with a constant value. - -In most cases this will cover all uses of the state register, thus rendering the -state encoding arbitrary. If however a design uses e.g.~a single bit of the state -value to drive a control output directly, this bit of the state signal will be -transformed to a control output of the same value. - -Finally, a transition table for the FSM is generated. This is done by using the -{\tt ConstEval} C++ helper class (defined in {\tt kernel/consteval.h}) that can -be used to evaluate parts of the design. The {\tt ConstEval} class can be asked -to calculate a given set of result signals using a set of signal-value -assignments. It can also be passed a list of stop-signals that abort the {\tt -ConstEval} algorithm if the value of a stop-signal is needed in order to -calculate the result signals. - -The {\tt fsm\_extract} pass uses the {\tt ConstEval} class in the following way -to create a transition table. For each state: - -\begin{enumerate} -\item Create a {\tt ConstEval} object for the module containing the FSM -\item Add all control inputs to the list of stop signals -\item Set the state signal to the current state -\item Try to evaluate the next state and control output \label{enum:fsm_extract_cealg_try} -\item If step~\ref{enum:fsm_extract_cealg_try} was not successful: -\begin{itemize} -\item Recursively goto step~\ref{enum:fsm_extract_cealg_try} with the offending stop-signal set to 0. -\item Recursively goto step~\ref{enum:fsm_extract_cealg_try} with the offending stop-signal set to 1. -\end{itemize} -\item If step~\ref{enum:fsm_extract_cealg_try} was successful: Emit transition -\end{enumerate} - -Finally a {\tt \$fsm} cell is created with the generated transition table and added to the -module. This new cell is connected to the control signals and the old drivers for the -control outputs are disconnected. - -\subsection{FSM Optimization} - -The {\tt fsm\_opt} pass performs basic optimizations on {\tt \$fsm} cells (not including state -recoding). The following optimizations are performed (in this order): - -\begin{itemize} -\item Unused control outputs are removed from the {\tt \$fsm} cell. The attribute \B{unused\_bits} -(that is usually set by the {\tt opt\_clean} pass) is used to determine which control -outputs are unused. -\item Control inputs that are connected to the same driver are merged. -\item When a control input is driven by a control output, the control input is removed and the transition -table altered to give the same performance without the external feedback path. -\item Entries in the transition table that yield the same output and only -differ in the value of a single control input bit are merged and the different bit is removed -from the sensitivity list (turned into a don't-care bit). -\item Constant inputs are removed and the transition table is altered to give an unchanged behaviour. -\item Unused inputs are removed. -\end{itemize} - -\subsection{FSM Recoding} - -The {\tt fsm\_recode} pass assigns new bit pattern to the states. Usually this -also implies a change in the width of the state signal. At the moment of this -writing only one-hot encoding with all-zero for the reset state is supported. - -The {\tt fsm\_recode} pass can also write a text file with the changes performed -by it that can be used when verifying designs synthesized by Yosys using Synopsys -Formality \citeweblink{Formality}. - -\section{Logic Optimization} - -Yosys can perform multi-level combinational logic optimization on gate-level netlists using the -external program ABC \citeweblink{ABC}. The {\tt abc} pass extracts the combinational gate-level -parts of the design, passes it through ABC, and re-integrates the results. The {\tt abc} pass -can also be used to perform other operations using ABC, such as technology mapping (see -Sec.~\ref{sec:techmap_extern} for details). - diff --git a/manual/CHAPTER_Overview.tex b/manual/CHAPTER_Overview.tex deleted file mode 100644 index 50a56137c..000000000 --- a/manual/CHAPTER_Overview.tex +++ /dev/null @@ -1,560 +0,0 @@ - -\chapter{Implementation Overview} -\label{chapter:overview} - -Yosys is an extensible open source hardware synthesis tool. It is aimed at -designers who are looking for an easily accessible, universal, and -vendor-independent synthesis tool, as well as scientists who do research in -electronic design automation (EDA) and are looking for an open synthesis -framework that can be used to test algorithms on complex real-world designs. - -Yosys can synthesize a large subset of Verilog 2005 and has been tested with a -wide range of real-world designs, including the OpenRISC 1200 CPU -\citeweblink{OR1200}, the openMSP430 CPU \citeweblink{openMSP430}, the -OpenCores I$^2$C master \citeweblink{i2cmaster} and the k68 CPU \citeweblink{k68}. - -As of this writing a Yosys VHDL frontend is in development. - -Yosys is written in C++ (using some features from the new C++11 standard). This -chapter describes some of the fundamental Yosys data structures. For the sake -of simplicity the C++ type names used in the Yosys implementation are used in -this chapter, even though the chapter only explains the conceptual idea behind -it and can be used as reference to implement a similar system in any language. - -\section{Simplified Data Flow} - -Figure~\ref{fig:Overview_flow} shows the simplified data flow within Yosys. -Rectangles in the figure represent program modules and ellipses internal -data structures that are used to exchange design data between the program -modules. - -Design data is read in using one of the frontend modules. The high-level HDL -frontends for Verilog and VHDL code generate an abstract syntax tree (AST) that -is then passed to the AST frontend. Note that both HDL frontends use the same -AST representation that is powerful enough to cover the Verilog HDL and VHDL -language. - -The AST Frontend then compiles the AST to Yosys's main internal data format, -the RTL Intermediate Language (RTLIL). A more detailed description of this format -is given in the next section. - -There is also a text representation of the RTLIL data structure that can be -parsed using the RTLIL Frontend. - -The design data may then be transformed using a series of passes that all -operate on the RTLIL representation of the design. - -Finally the design in RTLIL representation is converted back to text by one -of the backends, namely the Verilog Backend for generating Verilog netlists -and the RTLIL Backend for writing the RTLIL data in the same format that is -understood by the RTLIL Frontend. - -With the exception of the AST Frontend, which is called by the high-level HDL -frontends and can't be called directly by the user, all program modules are -called by the user (usually using a synthesis script that contains text -commands for Yosys). - -By combining passes in different ways and/or adding additional passes to Yosys -it is possible to adapt Yosys to a wide range of applications. For this to be -possible it is key that (1) all passes operate on the same data structure -(RTLIL) and (2) that this data structure is powerful enough to represent the design -in different stages of the synthesis. - -\begin{figure}[t] - \hfil - \begin{tikzpicture} - \tikzstyle{process} = [draw, fill=green!10, rectangle, minimum height=3em, minimum width=10em, node distance=15em] - \tikzstyle{data} = [draw, fill=blue!10, ellipse, minimum height=3em, minimum width=7em, node distance=15em] - \node[process] (vlog) {Verilog Frontend}; - \node[process, dashed, fill=green!5] (vhdl) [right of=vlog] {VHDL Frontend}; - \node[process] (ilang) [right of=vhdl] {RTLIL Frontend}; - \node[data] (ast) [below of=vlog, node distance=5em, xshift=7.5em] {AST}; - \node[process] (astfe) [below of=ast, node distance=5em] {AST Frontend}; - \node[data] (rtlil) [below of=astfe, node distance=5em, xshift=7.5em] {RTLIL}; - \node[process] (pass) [right of=rtlil, node distance=5em, xshift=7.5em] {Passes}; - \node[process] (vlbe) [below of=rtlil, node distance=7em, xshift=-13em] {Verilog Backend}; - \node[process] (ilangbe) [below of=rtlil, node distance=7em, xshift=0em] {RTLIL Backend}; - \node[process, dashed, fill=green!5] (otherbe) [below of=rtlil, node distance=7em, xshift=+13em] {Other Backends}; - - \draw[-latex] (vlog) -- (ast); - \draw[-latex] (vhdl) -- (ast); - \draw[-latex] (ast) -- (astfe); - \draw[-latex] (astfe) -- (rtlil); - \draw[-latex] (ilang) -- (rtlil); - \draw[latex-latex] (rtlil) -- (pass); - \draw[-latex] (rtlil) -- (vlbe); - \draw[-latex] (rtlil) -- (ilangbe); - \draw[-latex] (rtlil) -- (otherbe); - \end{tikzpicture} - \caption{Yosys simplified data flow (ellipses: data structures, rectangles: program modules)} - \label{fig:Overview_flow} -\end{figure} - -\section{The RTL Intermediate Language} - -All frontends, passes and backends in Yosys operate on a design in RTLIL representation. -The only exception are the high-level frontends that use the AST representation as an intermediate step before generating RTLIL -data. - -In order to avoid reinventing names for the RTLIL classes, they are simply referred to by their full C++ name, i.e.~including -the {\tt RTLIL::} namespace prefix, in this document. - -Figure~\ref{fig:Overview_RTLIL} shows a simplified Entity-Relationship Diagram (ER Diagram) of RTLIL. In $1:N$ relationships the arrow -points from the $N$ side to the $1$. For example one RTLIL::Design contains $N$ (zero to many) instances of RTLIL::Module. -A two-pointed arrow indicates a $1:1$ relationship. - -The RTLIL::Design is the root object of the RTLIL data structure. There is always one ``current design'' in memory -which passes operate on, frontends add data to and backends convert to exportable formats. But in some cases passes -internally generate additional RTLIL::Design objects. For example when a pass is reading an auxiliary Verilog file such -as a cell library, it might create an additional RTLIL::Design object and call the Verilog frontend with this -other object to parse the cell library. - -\begin{figure}[t] - \hfil - \begin{tikzpicture} - \tikzstyle{entity} = [draw, fill=gray!10, rectangle, minimum height=3em, minimum width=7em, node distance=5em, font={\ttfamily}] - \node[entity] (design) {RTLIL::Design}; - \node[entity] (module) [right of=design, node distance=11em] {RTLIL::Module} edge [-latex] node[above] {\tiny 1 \hskip3em N} (design); - - \node[entity] (process) [fill=green!10, right of=module, node distance=10em] {RTLIL::Process} (process.west) edge [-latex] (module); - \node[entity] (memory) [fill=red!10, below of=process] {RTLIL::Memory} edge [-latex] (module); - \node[entity] (wire) [fill=blue!10, above of=process] {RTLIL::Wire} (wire.west) edge [-latex] (module); - \node[entity] (cell) [fill=blue!10, above of=wire] {RTLIL::Cell} (cell.west) edge [-latex] (module); - - \node[entity] (case) [fill=green!10, right of=process, node distance=10em] {RTLIL::CaseRule} edge [latex-latex] (process); - \node[entity] (sync) [fill=green!10, above of=case] {RTLIL::SyncRule} edge [-latex] (process); - \node[entity] (switch) [fill=green!10, below of=case] {RTLIL::SwitchRule} edge [-latex] (case); - \draw[latex-] (switch.east) -- ++(1em,0) |- (case.east); - \end{tikzpicture} - \caption{Simplified RTLIL Entity-Relationship Diagram} - \label{fig:Overview_RTLIL} -\end{figure} - -There is only one active RTLIL::Design object that is used by all frontends, -passes and backends called by the user, e.g.~using a synthesis script. The RTLIL::Design then contains -zero to many RTLIL::Module objects. This corresponds to modules in Verilog or entities in VHDL. Each -module in turn contains objects from three different categories: - -\begin{itemize} -\item RTLIL::Cell and RTLIL::Wire objects represent classical netlist data. -\item RTLIL::Process objects represent the decision trees (if-then-else statements, etc.) and synchronization -declarations (clock signals and sensitivity) from Verilog {\tt always} and VHDL {\tt process} blocks. -\item RTLIL::Memory objects represent addressable memories (arrays). -\end{itemize} - -\begin{sloppypar} -Usually the output of the synthesis procedure is a netlist, i.e. all -RTLIL::Process and RTLIL::Memory objects must be replaced by RTLIL::Cell and -RTLIL::Wire objects by synthesis passes. -\end{sloppypar} - -All features of the HDL that cannot be mapped directly to these RTLIL classes must be -transformed to an RTLIL-compatible representation by the HDL frontend. This includes -Verilog-features such as generate-blocks, loops and parameters. - -The following sections contain a more detailed description of the different -parts of RTLIL and rationale behind some of the design decisions. - -\subsection{RTLIL Identifiers} - -All identifiers in RTLIL (such as module names, port names, signal names, cell -types, etc.) follow the following naming convention: they must either start with -a backslash (\textbackslash) or a dollar sign (\$). - -Identifiers starting with a backslash are public visible identifiers. Usually -they originate from one of the HDL input files. For example the signal name ``{\tt \textbackslash sig42}'' -is most likely a signal that was declared using the name ``{\tt sig42}'' in an HDL input file. -On the other hand the signal name ``{\tt \$sig42}'' is an auto-generated signal name. The backends -convert all identifiers that start with a dollar sign to identifiers that do not collide with -identifiers that start with a backslash. - -This has three advantages: - -\begin{itemize} -\item First, it is impossible that an auto-generated identifier collides with -an identifier that was provided by the user. -\item Second, the information about which identifiers were originally -provided by the user is always available which can help guide some optimizations. For example the ``opt\_rmunused'' -tries to preserve signals with a user-provided name but doesn't hesitate to delete signals that have -auto-generated names when they just duplicate other signals. -\item Third, the delicate job of finding suitable auto-generated public visible -names is deferred to one central location. Internally auto-generated names that -may hold important information for Yosys developers can be used without -disturbing external tools. For example the Verilog backend assigns names in the form {\tt \_{\it integer}\_}. -\end{itemize} - -Whitespace and control characters (any character with an ASCII code 32 or less) are not allowed -in RTLIL identifiers; most frontends and backends cannot support these characters in identifiers. - -In order to avoid programming errors, the RTLIL data structures check if all identifiers start -with either a backslash or a dollar sign, and contain no whitespace or control characters. -Violating these rules results in a runtime error. - -All RTLIL identifiers are case sensitive. - -Some transformations, such as flattening, may have to change identifiers provided by the user -to avoid name collisions. When that happens, attribute ``{\tt hdlname}`` is attached to the object -with the changed identifier. This attribute contains one name (if emitted directly by the frontend, -or is a result of disambiguation) or multiple names separated by spaces (if a result of flattening). -All names specified in the ``{\tt hdlname}`` attribute are public and do not include the leading -``\textbackslash``. - -\subsection{RTLIL::Design and RTLIL::Module} - -The RTLIL::Design object is basically just a container for RTLIL::Module objects. In addition to -a list of RTLIL::Module objects the RTLIL::Design also keeps a list of {\it selected objects}, i.e. -the objects that passes should operate on. In most cases the whole design is selected and therefore -passes operate on the whole design. But this mechanism can be useful for more complex synthesis jobs -in which only parts of the design should be affected by certain passes. - -Besides the objects shown in the ER diagram in Fig.~\ref{fig:Overview_RTLIL} an RTLIL::Module object -contains the following additional properties: - -\begin{itemize} -\item The module name -\item A list of attributes -\item A list of connections between wires -\item An optional frontend callback used to derive parametrized variations of the module -\end{itemize} - -The attributes can be Verilog attributes imported by the Verilog frontend or attributes assigned -by passes. They can be used to store additional metadata about modules or just mark them to be -used by certain part of the synthesis script but not by others. - -Verilog and VHDL both support parametric modules (known as ``generic entities'' in VHDL). The RTLIL -format does not support parametric modules itself. Instead each module contains a callback function -into the AST frontend to generate a parametrized variation of the RTLIL::Module as needed. This -callback then returns the auto-generated name of the parametrized variation of the module. (A hash -over the parameters and the module name is used to prohibit the same parametrized variation from being -generated twice. For modules with only a few parameters, a name directly containing all parameters -is generated instead of a hash string.) - -\subsection{RTLIL::Cell and RTLIL::Wire} -\label{sec:rtlil_cell_wire} - -A module contains zero to many RTLIL::Cell and RTLIL::Wire objects. Objects of -these types are used to model netlists. Usually the goal of all synthesis efforts is to convert -all modules to a state where the functionality of the module is implemented only by cells -from a given cell library and wires to connect these cells with each other. Note that module -ports are just wires with a special property. - -An RTLIL::Wire object has the following properties: - -\begin{itemize} -\item The wire name -\item A list of attributes -\item A width (buses are just wires with a width > 1) -\item Bus direction (MSB to LSB or vice versa) -\item Lowest valid bit index (LSB or MSB depending on bus direction) -\item If the wire is a port: port number and direction (input/output/inout) -\end{itemize} - -As with modules, the attributes can be Verilog attributes imported by the -Verilog frontend or attributes assigned by passes. - -In Yosys, busses (signal vectors) are represented using a single wire object -with a width > 1. So Yosys does not convert signal vectors to individual signals. -This makes some aspects of RTLIL more complex but enables Yosys to be used for -coarse grain synthesis where the cells of the target architecture operate on -entire signal vectors instead of single bit wires. - -In Verilog and VHDL, busses may have arbitrary bounds, and LSB can have either -the lowest or the highest bit index. In RTLIL, bit 0 always corresponds to LSB; -however, information from the HDL frontend is preserved so that the bus will be -correctly indexed in error messages, backend output, constraint files, etc. - -An RTLIL::Cell object has the following properties: - -\begin{itemize} -\item The cell name and type -\item A list of attributes -\item A list of parameters (for parametric cells) -\item Cell ports and the connections of ports to wires and constants -\end{itemize} - -The connections of ports to wires are coded by assigning an RTLIL::SigSpec -to each cell port. The RTLIL::SigSpec data type is described in the next section. - -\subsection{RTLIL::SigSpec} -\label{sec:rtlil_sigspec} - -A ``signal'' is everything that can be applied to a cell port. I.e. - -\begin{itemize} -\item Any constant value of arbitrary bit-width \\ -\null\hskip1em For example: \lstinline[language=Verilog]{1337, 16'b0000010100111001, 1'b1, 1'bx} -\item All bits of a wire or a selection of bits from a wire \\ -\null\hskip1em For example: \lstinline[language=Verilog]{mywire, mywire[24], mywire[15:8]} -\item Concatenations of the above \\ -\null\hskip1em For example: \lstinline[language=Verilog]|{16'd1337, mywire[15:8]}| -\end{itemize} - -The RTLIL::SigSpec data type is used to represent signals. The RTLIL::Cell -object contains one RTLIL::SigSpec for each cell port. - -In addition, connections between wires are represented using a pair of -RTLIL::SigSpec objects. Such pairs are needed in different locations. Therefore -the type name RTLIL::SigSig was defined for such a pair. - -\subsection{RTLIL::Process} -\label{sec:rtlil_process} - -When a high-level HDL frontend processes behavioural code it splits it up into -data path logic (e.g.~the expression {\tt a + b} is replaced by the output of an -adder that takes {\tt a} and {\tt b} as inputs) and an RTLIL::Process that models -the control logic of the behavioural code. Let's consider a simple example: - -\begin{lstlisting}[numbers=left,frame=single,language=Verilog] -module ff_with_en_and_async_reset(clock, reset, enable, d, q); -input clock, reset, enable, d; -output reg q; -always @(posedge clock, posedge reset) - if (reset) - q <= 0; - else if (enable) - q <= d; -endmodule -\end{lstlisting} - -In this example there is no data path and therefore the RTLIL::Module generated by -the frontend only contains a few RTLIL::Wire objects and an RTLIL::Process. -The RTLIL::Process in RTLIL syntax: - -\begin{lstlisting}[numbers=left,frame=single,language=rtlil] -process $proc$ff_with_en_and_async_reset.v:4$1 - assign $0\q[0:0] \q - switch \reset - case 1'1 - assign $0\q[0:0] 1'0 - case - switch \enable - case 1'1 - assign $0\q[0:0] \d - case - end - end - sync posedge \clock - update \q $0\q[0:0] - sync posedge \reset - update \q $0\q[0:0] -end -\end{lstlisting} - -This RTLIL::Process contains two RTLIL::SyncRule objects, two RTLIL::SwitchRule -objects and five RTLIL::CaseRule objects. The wire {\tt \$0\textbackslash{}q[0:0]} -is an automatically created wire that holds the next value of {\tt \textbackslash{}q}. The lines -$2 \dots 12$ describe how {\tt \$0\textbackslash{}q[0:0]} should be calculated. The -lines $13 \dots 16$ describe how the value of {\tt \$0\textbackslash{}q[0:0]} is used -to update {\tt \textbackslash{}q}. - -An RTLIL::Process is a container for zero or more RTLIL::SyncRule objects and -exactly one RTLIL::CaseRule object, which is called the {\it root case}. - -An RTLIL::SyncRule object contains an (optional) synchronization condition (signal and edge-type), zero or -more assignments (RTLIL::SigSig), and zero or more memory writes (RTLIL::MemWriteAction). -The {\tt always} synchronization condition is used to break combinatorial -loops when a latch should be inferred instead. - -An RTLIL::CaseRule is a container for zero or more assignments (RTLIL::SigSig) -and zero or more RTLIL::SwitchRule objects. An RTLIL::SwitchRule objects is a -container for zero or more RTLIL::CaseRule objects. - -In the above example the lines $2 \dots 12$ are the root case. Here {\tt \$0\textbackslash{}q[0:0]} is first -assigned the old value {\tt \textbackslash{}q} as default value (line 2). The root case -also contains an RTLIL::SwitchRule object (lines $3 \dots 12$). Such an object is very similar to the C {\tt switch} -statement as it uses a control signal ({\tt \textbackslash{}reset} in this case) to determine -which of its cases should be active. The RTLIL::SwitchRule object then contains one RTLIL::CaseRule -object per case. In this example there is a case\footnote{The -syntax {\tt 1'1} in the RTLIL code specifies a constant with a length of one bit (the first ``1''), -and this bit is a one (the second ``1'').} for {\tt \textbackslash{}reset == 1} that causes -{\tt \$0\textbackslash{}q[0:0]} to be set (lines 4 and 5) and a default case that in turn contains a switch that -sets {\tt \$0\textbackslash{}q[0:0]} to the value of {\tt \textbackslash{}d} if {\tt -\textbackslash{}enable} is active (lines $6 \dots 11$). - -A case can specify zero or more compare values that will determine whether it matches. Each of the compare values -must be the exact same width as the control signal. When more than one compare value is specified, the case matches -if any of them matches the control signal; when zero compare values are specified, the case always matches (i.e. -it is the default case). - -A switch prioritizes cases from first to last: multiple cases can match, but only the first matched case becomes -active. This normally synthesizes to a priority encoder. The {\tt parallel\_case} attribute allows passes to assume -that no more than one case will match, and {\tt full\_case} attribute allows passes to assume that exactly one -case will match; if these invariants are ever dynamically violated, the behavior is undefined. These attributes -are useful when an invariant invisible to the synthesizer causes the control signal to never take certain -bit patterns. - -The lines $13 \dots 16$ then cause {\tt \textbackslash{}q} to be updated whenever there is -a positive clock edge on {\tt \textbackslash{}clock} or {\tt \textbackslash{}reset}. - -In order to generate such a representation, the language frontend must be able to handle blocking -and nonblocking assignments correctly. However, the language frontend does not need to identify -the correct type of storage element for the output signal or generate multiplexers for the -decision tree. This is done by passes that work on the RTLIL representation. Therefore it is -relatively easy to substitute these steps with other algorithms that target different target -architectures or perform optimizations or other transformations on the decision trees before -further processing them. - -One of the first actions performed on a design in RTLIL representation in most -synthesis scripts is identifying asynchronous resets. This is usually done using the {\tt proc\_arst} -pass. This pass transforms the above example to the following RTLIL::Process: - -\begin{lstlisting}[numbers=left,frame=single,language=rtlil] -process $proc$ff_with_en_and_async_reset.v:4$1 - assign $0\q[0:0] \q - switch \enable - case 1'1 - assign $0\q[0:0] \d - case - end - sync posedge \clock - update \q $0\q[0:0] - sync high \reset - update \q 1'0 -end -\end{lstlisting} - -This pass has transformed the outer RTLIL::SwitchRule into a modified RTLIL::SyncRule object -for the {\tt \textbackslash{}reset} signal. Further processing converts the RTLIL::Process -into e.g.~a d-type flip-flop with asynchronous reset and a multiplexer for the enable signal: - -\begin{lstlisting}[numbers=left,frame=single,language=rtlil] -cell $adff $procdff$6 - parameter \ARST_POLARITY 1'1 - parameter \ARST_VALUE 1'0 - parameter \CLK_POLARITY 1'1 - parameter \WIDTH 1 - connect \ARST \reset - connect \CLK \clock - connect \D $0\q[0:0] - connect \Q \q -end -cell $mux $procmux$3 - parameter \WIDTH 1 - connect \A \q - connect \B \d - connect \S \enable - connect \Y $0\q[0:0] -end -\end{lstlisting} - -Different combinations of passes may yield different results. Note that {\tt \$adff} and {\tt -\$mux} are internal cell types that still need to be mapped to cell types from the -target cell library. - -Some passes refuse to operate on modules that still contain RTLIL::Process objects as the -presence of these objects in a module increases the complexity. Therefore the passes to translate -processes to a netlist of cells are usually called early in a synthesis script. The {\tt proc} -pass calls a series of other passes that together perform this conversion in a way that is suitable -for most synthesis tasks. - -\subsection{RTLIL::Memory} -\label{sec:rtlil_memory} - -For every array (memory) in the HDL code an RTLIL::Memory object is created. A -memory object has the following properties: - -\begin{itemize} -\item The memory name -\item A list of attributes -\item The width of an addressable word -\item The size of the memory in number of words -\end{itemize} - -All read accesses to the memory are transformed to {\tt \$memrd} cells and all write accesses to -{\tt \$memwr} cells by the language frontend. These cells consist of independent read- and write-ports -to the memory. Memory initialization is transformed to {\tt \$meminit} cells by the language frontend. -The \B{MEMID} parameter on these cells is used to link them together and to the RTLIL::Memory object they belong to. - -The rationale behind using separate cells for the individual ports versus -creating a large multiport memory cell right in the language frontend is that -the separate {\tt \$memrd} and {\tt \$memwr} cells can be consolidated using resource sharing. -As resource sharing is a non-trivial optimization problem where different synthesis tasks -can have different requirements it lends itself to do the optimisation in separate passes and merge -the RTLIL::Memory objects and {\tt \$memrd} and {\tt \$memwr} cells to multiport memory blocks after resource sharing is completed. - -The {\tt memory} pass performs this conversion and can (depending on the options passed -to it) transform the memories directly to d-type flip-flops and address logic or yield -multiport memory blocks (represented using {\tt \$mem} cells). - -See Sec.~\ref{sec:memcells} for details about the memory cell types. - -\section{Command Interface and Synthesis Scripts} - -Yosys reads and processes commands from synthesis scripts, command line arguments and -an interactive command prompt. Yosys commands consist of a command name and an optional -whitespace separated list of arguments. Commands are terminated using the newline character -or a semicolon ({\tt ;}). Empty lines and lines starting with the hash sign ({\tt \#}) are ignored. -See Sec.~\ref{sec:typusecase} for an example synthesis script. - -The command {\tt help} can be used to access the command reference manual. - -Most commands can operate not only on the entire design but also specifically on {\it selected} -parts of the design. For example the command {\tt dump} will print all selected objects -in the current design while {\tt dump foobar} will only print the module {\tt foobar} -and {\tt dump *} will print the entire design regardless of the current selection. - -The selection mechanism is very powerful. For example the command {\tt dump */t:\$add -\%x:+[A] */w:* \%i} will print all wires that are connected to the \B{A} port of -a {\tt \$add} cell. Detailed documentation of the select framework can be -found in the command reference for the {\tt select} command. - -\section{Source Tree and Build System} - -The Yosys source tree is organized into the following top-level directories: - -\begin{itemize} - -\item {\tt backends/} \\ -This directory contains a subdirectory for each of the backend modules. - -\item {\tt frontends/} \\ -This directory contains a subdirectory for each of the frontend modules. - -\item {\tt kernel/} \\ -This directory contains all the core functionality of Yosys. This includes the -functions and definitions for working with the RTLIL data structures ({\tt -rtlil.h} and {\tt rtlil.cc}), the main() function ({\tt driver.cc}), the -internal framework for generating log messages ({\tt log.h} and {\tt log.cc}), -the internal framework for registering and calling passes ({\tt register.h} and -{\tt register.cc}), some core commands that are not really passes ({\tt -select.cc}, {\tt show.cc}, \dots) and a couple of other small utility libraries. - -\item {\tt passes/} \\ -This directory contains a subdirectory for each pass or group of passes. For example as -of this writing the directory {\tt passes/opt/} contains the code for seven -passes: {\tt opt}, {\tt opt\_expr}, {\tt opt\_muxtree}, {\tt opt\_reduce}, -{\tt opt\_rmdff}, {\tt opt\_rmunused} and {\tt opt\_merge}. - -\item {\tt techlibs/} \\ -This directory contains simulation models and standard implementations for the -cells from the internal cell library. - -\item {\tt tests/} \\ -This directory contains a couple of test cases. Most of the smaller tests are executed -automatically when {\tt make test} is called. The larger tests must be executed -manually. Most of the larger tests require downloading external HDL source code -and/or external tools. The tests range from comparing simulation results of the synthesized -design to the original sources to logic equivalence checking of entire CPU cores. - -\end{itemize} - -\begin{sloppypar} -The top-level Makefile includes {\tt frontends/*/Makefile.inc}, {\tt passes/*/Makefile.inc} -and {\tt backends/*/Makefile.inc}. So when extending Yosys it is enough to create -a new directory in {\tt frontends/}, {\tt passes/} or {\tt backends/} with your sources -and a {\tt Makefile.inc}. The Yosys kernel automatically detects all commands linked with -Yosys. So it is not needed to add additional commands to a central list of commands. -\end{sloppypar} - -Good starting points for reading example source code to learn how to write passes -are {\tt passes/opt/opt\_rmdff.cc} and {\tt passes/opt/opt\_merge.cc}. - -See the top-level README file for a quick {\it Getting Started} guide and build -instructions. The Yosys build is based solely on Makefiles. - -Users of the Qt Creator IDE can generate a QT Creator project file using {\tt -make qtcreator}. Users of the Eclipse IDE can use the ``Makefile Project with -Existing Code'' project type in the Eclipse ``New Project'' dialog (only -available after the CDT plugin has been installed) to create an Eclipse project -in order to programming extensions to Yosys or just browse the Yosys code base. - diff --git a/manual/CHAPTER_Prog.tex b/manual/CHAPTER_Prog.tex deleted file mode 100644 index 49432f73b..000000000 --- a/manual/CHAPTER_Prog.tex +++ /dev/null @@ -1,27 +0,0 @@ - -\chapter{Programming Yosys Extensions} -\label{chapter:prog} - -This chapter contains some bits and pieces of information about programming -yosys extensions. Also consult the section on programming in the ``Yosys -Presentation'' (can be downloaded from the Yosys website as PDF) and don't -be afraid to ask questions on the YosysHQ Slack. - -\section{Guidelines} - -The {\tt guidelines} directory contains notes on various aspects of Yosys development. The files {\tt GettingStarted} and {\tt CodingStyle} may be of particular interest, and are reproduced here. - -\lstinputlisting[title=GettingStarted,numbers=left,frame=single]{../guidelines/GettingStarted} - -\lstinputlisting[title=CodingStyle,numbers=left,frame=single]{../guidelines/CodingStyle} - -\section{The ``stubsnets'' Example Module} - -The following is the complete code of the ``stubsnets'' example module. It is included in the Yosys source distribution as {\tt manual/CHAPTER\_Prog/stubnets.cc}. - - -\lstinputlisting[title=stubnets.cc,numbers=left,frame=single,language=C++]{CHAPTER_Prog/stubnets.cc} - -\lstinputlisting[title=Makefile,numbers=left,frame=single,language=make]{CHAPTER_Prog/Makefile} - -\lstinputlisting[title=test.v,numbers=left,frame=single,language=Verilog]{CHAPTER_Prog/test.v} diff --git a/manual/CHAPTER_Prog/.gitignore b/manual/CHAPTER_Prog/.gitignore deleted file mode 100644 index fa83c3212..000000000 --- a/manual/CHAPTER_Prog/.gitignore +++ /dev/null @@ -1,3 +0,0 @@ -stubnets.so -stubnets.d -*.log diff --git a/manual/CHAPTER_Prog/Makefile b/manual/CHAPTER_Prog/Makefile deleted file mode 100644 index 8e326bdc2..000000000 --- a/manual/CHAPTER_Prog/Makefile +++ /dev/null @@ -1,12 +0,0 @@ -test: stubnets.so - yosys -ql test1.log -m ./stubnets.so test.v -p "stubnets" - yosys -ql test2.log -m ./stubnets.so test.v -p "opt; stubnets" - yosys -ql test3.log -m ./stubnets.so test.v -p "techmap; opt; stubnets -report_bits" - tail test1.log test2.log test3.log - -stubnets.so: stubnets.cc - yosys-config --exec --cxx --cxxflags --ldflags -o $@ -shared $^ --ldlibs - -clean: - rm -f test1.log test2.log test3.log - rm -f stubnets.so stubnets.d diff --git a/manual/CHAPTER_Prog/stubnets.cc b/manual/CHAPTER_Prog/stubnets.cc deleted file mode 100644 index 566d24b18..000000000 --- a/manual/CHAPTER_Prog/stubnets.cc +++ /dev/null @@ -1,130 +0,0 @@ -// This is free and unencumbered software released into the public domain. -// -// Anyone is free to copy, modify, publish, use, compile, sell, or -// distribute this software, either in source code form or as a compiled -// binary, for any purpose, commercial or non-commercial, and by any -// means. - -#include "kernel/yosys.h" -#include "kernel/sigtools.h" - -#include <string> -#include <map> -#include <set> - -USING_YOSYS_NAMESPACE -PRIVATE_NAMESPACE_BEGIN - -// this function is called for each module in the design -static void find_stub_nets(RTLIL::Design *design, RTLIL::Module *module, bool report_bits) -{ - // use a SigMap to convert nets to a unique representation - SigMap sigmap(module); - - // count how many times a single-bit signal is used - std::map<RTLIL::SigBit, int> bit_usage_count; - - // count output lines for this module (needed only for summary output at the end) - int line_count = 0; - - log("Looking for stub wires in module %s:\n", RTLIL::id2cstr(module->name)); - - // For all ports on all cells - for (auto &cell_iter : module->cells_) - for (auto &conn : cell_iter.second->connections()) - { - // Get the signals on the port - // (use sigmap to get a uniqe signal name) - RTLIL::SigSpec sig = sigmap(conn.second); - - // add each bit to bit_usage_count, unless it is a constant - for (auto &bit : sig) - if (bit.wire != NULL) - bit_usage_count[bit]++; - } - - // for each wire in the module - for (auto &wire_iter : module->wires_) - { - RTLIL::Wire *wire = wire_iter.second; - - // .. but only selected wires - if (!design->selected(module, wire)) - continue; - - // add +1 usage if this wire actually is a port - int usage_offset = wire->port_id > 0 ? 1 : 0; - - // we will record which bits of the (possibly multi-bit) wire are stub signals - std::set<int> stub_bits; - - // get a signal description for this wire and split it into separate bits - RTLIL::SigSpec sig = sigmap(wire); - - // for each bit (unless it is a constant): - // check if it is used at least two times and add to stub_bits otherwise - for (int i = 0; i < GetSize(sig); i++) - if (sig[i].wire != NULL && (bit_usage_count[sig[i]] + usage_offset) < 2) - stub_bits.insert(i); - - // continue if no stub bits found - if (stub_bits.size() == 0) - continue; - - // report stub bits and/or stub wires, don't report single bits - // if called with report_bits set to false. - if (GetSize(stub_bits) == GetSize(sig)) { - log(" found stub wire: %s\n", RTLIL::id2cstr(wire->name)); - } else { - if (!report_bits) - continue; - log(" found wire with stub bits: %s [", RTLIL::id2cstr(wire->name)); - for (int bit : stub_bits) - log("%s%d", bit == *stub_bits.begin() ? "" : ", ", bit); - log("]\n"); - } - - // we have outputted a line, increment summary counter - line_count++; - } - - // report summary - if (report_bits) - log(" found %d stub wires or wires with stub bits.\n", line_count); - else - log(" found %d stub wires.\n", line_count); -} - -// each pass contains a singleton object that is derived from Pass -struct StubnetsPass : public Pass { - StubnetsPass() : Pass("stubnets") { } - void execute(std::vector<std::string> args, RTLIL::Design *design) override - { - // variables to mirror information from passed options - bool report_bits = 0; - - log_header(design, "Executing STUBNETS pass (find stub nets).\n"); - - // parse options - size_t argidx; - for (argidx = 1; argidx < args.size(); argidx++) { - std::string arg = args[argidx]; - if (arg == "-report_bits") { - report_bits = true; - continue; - } - break; - } - - // handle extra options (e.g. selection) - extra_args(args, argidx, design); - - // call find_stub_nets() for each module that is either - // selected as a whole or contains selected objects. - for (auto &it : design->modules_) - if (design->selected_module(it.first)) - find_stub_nets(design, it.second, report_bits); - } -} StubnetsPass; - -PRIVATE_NAMESPACE_END diff --git a/manual/CHAPTER_Prog/test.v b/manual/CHAPTER_Prog/test.v deleted file mode 100644 index 201f75006..000000000 --- a/manual/CHAPTER_Prog/test.v +++ /dev/null @@ -1,8 +0,0 @@ -module uut(in1, in2, in3, out1, out2); - -input [8:0] in1, in2, in3; -output [8:0] out1, out2; - -assign out1 = in1 + in2 + (in3 >> 4); - -endmodule diff --git a/manual/CHAPTER_StateOfTheArt.tex b/manual/CHAPTER_StateOfTheArt.tex deleted file mode 100644 index 2d0c77a01..000000000 --- a/manual/CHAPTER_StateOfTheArt.tex +++ /dev/null @@ -1,289 +0,0 @@ - -\chapter{Evaluation of other OSS Verilog Synthesis Tools} -\label{chapter:sota} - -In this appendix\footnote{This appendix is an updated version of an -unpublished student research paper. \cite{VerilogFossEval}} -the existing FOSS Verilog synthesis tools\footnote{To the -author's best knowledge, all relevant tools that existed at the time of this -writing are included. But as there is no formal channel through which such -tools are published it is hard to give any guarantees in that matter.} are -evaluated. Extremely limited or application specific tools (e.g.~pure Verilog -Netlist parsers) as well as Verilog simulators are not included. These existing -solutions are tested using a set of representative Verilog code snippets. It is -shown that no existing FOSS tool implements even close to a sufficient subset -of Verilog to be usable as synthesis tool for a wide range existing Verilog code. - -The packages evaluated are: - -\begin{itemize} -\item Icarus Verilog \citeweblink{Icarus}\footnote{Icarus Verilog is mainly a simulation -tool but also supported synthesis up to version 0.8. Therefore version 0.8.7 is used -for this evaluation.)} -\item Verilog-to-Routing (VTR) / Odin-II \cite{vtr2012}\cite{Odin}\citeweblink{VTR} -\item HDL Analyzer and Netlist Architect (HANA) \citeweblink{HANA} -\item Verilog front-end to VIS (vl2mv) \cite{Cheng93vl2mv:a}\citeweblink{VIS} -\end{itemize} - -In each of the following sections Verilog modules that test a certain Verilog -language feature are presented and the support for these features is tested in all -the tools mentioned above. It is evaluated whether the tools under test -successfully generate netlists for the Verilog input and whether these netlists -match the simulation behavior of the designs using testbenches. - -All test cases are verified to be synthesizeable using Xilinx XST from the Xilinx -WebPACK \citeweblink{XilinxWebPACK} suite. - -Trivial features such as support for simple structural Verilog are not explicitly tested. - -Vl2mv and Odin-II generate output in the BLIF (Berkeley Logic Interchange -Format) and BLIF-MV (an extended version of BLIF) formats respectively. -ABC \citeweblink{ABC} is used to convert this output to Verilog for verification -using testbenches. - -Icarus Verilog generates EDIF (Electronic Design Interchange Format) output -utilizing LPM (Library of Parameterized Modules) cells. The EDIF files are -converted to Verilog using edif2ngd and netgen from Xilinx WebPACK. A -hand-written implementation of the LPM cells utilized by the generated netlists -is used for verification. - -Following these functional tests, a quick analysis of the extensibility of the tools -under test is provided in a separate section. - -The last section of this chapter finally concludes these series of evaluations -with a summary of the results. - -\begin{figure}[t!] - \begin{minipage}{7.7cm} - \lstinputlisting[numbers=left,frame=single,language=Verilog]{CHAPTER_StateOfTheArt/always01_pub.v} - \end{minipage} - \hfill - \begin{minipage}{7.7cm} - \lstinputlisting[frame=single,language=Verilog]{CHAPTER_StateOfTheArt/always02_pub.v} - \end{minipage} - \caption{1st and 2nd Verilog always examples} - \label{fig:StateOfTheArt_always12} -\end{figure} - -\begin{figure}[!] - \lstinputlisting[numbers=left,frame=single,language=Verilog]{CHAPTER_StateOfTheArt/always03.v} - \caption{3rd Verilog always example} - \label{fig:StateOfTheArt_always3} -\end{figure} - -\section{Always blocks and blocking vs.~nonblocking assignments} -\label{sec:blocking_nonblocking} - -The ``always''-block is one of the most fundamental non-trivial Verilog -language features. It can be used to model a combinatorial path (with optional -registers on the outputs) in a way that mimics a regular programming language. - -Within an always block, if- and case-statements can be used to model multiplexers. -Blocking assignments ($=$) and nonblocking assignments ($<=$) are used to populate the -leaf-nodes of these multiplexer trees. Unassigned leaf-nodes default to feedback -paths that cause the output register to hold the previous value. More advanced -synthesis tools often convert these feedback paths to register enable signals or -even generate circuits with clock gating. - -Registers assigned with nonblocking assignments ($<=$) behave differently from -variables in regular programming languages: In a simulation they are not -updated immediately after being assigned. Instead the right-hand sides are -evaluated and the results stored in temporary memory locations. After all -pending updates have been prepared in this way they are executed, thus yielding -semi-parallel execution of all nonblocking assignments. - -For synthesis this means that every occurrence of that register in an expression -addresses the output port of the corresponding register regardless of the question whether the register -has been assigned a new value in an earlier command in the same always block. -Therefore with nonblocking assignments the order of the assignments has no effect -on the resulting circuit as long as the left-hand sides of the assignments are -unique. - -The three example codes in Fig.~\ref{fig:StateOfTheArt_always12} and -Fig.~\ref{fig:StateOfTheArt_always3} use all these features and can thus be used -to test the synthesis tools capabilities to synthesize always blocks correctly. - -The first example is only using the most fundamental Verilog features. All -tools under test were able to successfully synthesize this design. - -\begin{figure}[b!] - \lstinputlisting[numbers=left,frame=single,language=Verilog]{CHAPTER_StateOfTheArt/arrays01.v} - \caption{Verilog array example} - \label{fig:StateOfTheArt_arrays} -\end{figure} - -The 2nd example is functionally identical to the 1st one but is using an -if-statement inside the always block. Odin-II fails to synthesize it and -instead produces the following error message: - -\begin{verbatim} -ERROR: (File: always02.v) (Line number: 13) -You've defined the driver "count~0" twice -\end{verbatim} - -Vl2mv does not produce an error message but outputs an invalid synthesis result -that is not using the reset input at all. - -Icarus Verilog also doesn't produce an error message but generates an invalid output -for this 2nd example. The code generated by Icarus Verilog only implements the reset -path for the count register, effectively setting the output to constant 0. - -So of all tools under test only HANA was able to create correct synthesis results -for the 2nd example. - -The 3rd example is using blocking and nonblocking assignments and many if statements. -Odin also fails to synthesize this example: - -\begin{verbatim} -ERROR: (File: always03.v) (Line number: 8) -ODIN doesn't handle blocking statements in Sequential blocks -\end{verbatim} - -HANA, Icarus Verilog and vl2mv create invalid synthesis results for the 3rd example. - -So unfortunately none of the tools under test provide a complete and correct -implementation of blocking and nonblocking assignments. - -\section{Arrays for memory modelling} - -Verilog arrays are part of the synthesizeable subset of Verilog and are -commonly used to model addressable memory. The Verilog code in -Fig.~\ref{fig:StateOfTheArt_arrays} demonstrates this by implementing a single -port memory. - -For this design HANA, vl2m and ODIN-II generate error messages indicating that -arrays are not supported. - -\begin{figure}[t!] - \lstinputlisting[numbers=left,frame=single,language=Verilog]{CHAPTER_StateOfTheArt/forgen01.v} - \caption{Verilog for loop example} - \label{fig:StateOfTheArt_for} -\end{figure} - -Icarus Verilog produces an invalid output that is using the address only for -reads. Instead of using the address input for writes, the generated design -simply loads the data to all memory locations whenever the write-enable input -is active, effectively turning the design into a single 4-bit D-Flip-Flop with -enable input. - -As all tools under test already fail this simple test, there is nothing to gain -by continuing tests on this aspect of Verilog synthesis such as synthesis of dual port -memories, correct handling of write collisions, and so forth. - -\begin{figure}[t!] - \lstinputlisting[numbers=left,frame=single,language=Verilog]{CHAPTER_StateOfTheArt/forgen02.v} - \caption{Verilog generate example} - \label{fig:StateOfTheArt_gen} -\end{figure} - -\section{For-loops and generate blocks} - -For-loops and generate blocks are more advanced Verilog features. These features -allow the circuit designer to add program code to her design that is evaluated -during synthesis to generate (parts of) the circuits description; something that -could only be done using a code generator otherwise. - -For-loops are only allowed in synthesizeable Verilog if they can be completely -unrolled. Then they can be a powerful tool to generate array logic or static -lookup tables. The code in Fig.~\ref{fig:StateOfTheArt_for} generates a circuit that -tests a 5 bit value for being a prime number using a static lookup table. - -Generate blocks can be used to model array logic in complex parametric designs. The -code in Fig.~\ref{fig:StateOfTheArt_gen} implements a ripple-carry adder with -parametric width from simple assign-statements and logic operations using a Verilog -generate block. - -All tools under test failed to synthesize both test cases. HANA creates invalid -output in both cases. Icarus Verilog creates invalid output for the first -test and fails with an error for the second case. The other two tools fail with -error messages for both tests. - -\section{Extensibility} - -This section briefly discusses the extensibility of the tools under test and -their internal data- and control-flow. As all tools under test already failed -to synthesize simple Verilog always-blocks correctly, not much resources have -been spent on evaluating the extensibility of these tools and therefore only a -very brief discussion of the topic is provided here. - -HANA synthesizes for a built-in library of standard cells using two passes over -an AST representation of the Verilog input. This approach executes fast but -limits the extensibility as everything happens in only two comparable complex -AST walks and there is no universal intermediate representation that is flexible -enough to be used in arbitrary optimizations. - -Odin-II and vl2m are both front ends to existing synthesis flows. As such they -only try to quickly convert the Verilog input into the internal representation -of their respective flows (BLIF). So extensibility is less of an issue here as -potential extensions would likely be implemented in other components of the -flow. - -Icarus Verilog is clearly designed to be a simulation tool rather than a -synthesis tool. The synthesis part of Icarus Verilog is an ad-hoc add-on to -Icarus Verilog that aims at converting an internal representation that is meant -for generation of a virtual machine based simulation code to netlists. - -\section{Summary and Outlook} - -Table~\ref{tab:StateOfTheArt_sum} summarizes the tests performed. Clearly none -of the tools under test make a serious attempt at providing a feature-complete -implementation of Verilog. It can be argued that Odin-II performed best in the -test as it never generated incorrect code but instead produced error messages -indicating that unsupported Verilog features where used in the Verilog input. - -In conclusion, to the best knowledge of the author, there is no FOSS Verilog -synthesis tool other than Yosys that is anywhere near feature completeness and -therefore there is no other candidate for a generic Verilog front end and/or -synthesis framework to be used as a basis for custom synthesis tools. - -Yosys could also replace vl2m and/or Odin-II in their respective flows or -function as a pre-compiler that can translate full-featured Verilog code to the -simple subset of Verilog that is understood by vl2m and Odin-II. - -Yosys is designed for extensibility. It can be used as-is to synthesize Verilog -code to netlists, but its main purpose is to be used as basis for custom tools. -Yosys is structured in a language dependent Verilog front end and language -independent synthesis code (which is in itself structured in independent -passes). This architecture will simplify implementing additional HDL front -ends and/or additional synthesis passes. - -Chapter~\ref{chapter:eval} contains a more detailed evaluation of Yosys using real-world -designs that are far out of reach for any of the other tools discussed in this appendix. - -\vskip2cm -\begin{table}[h] - % yosys hana vis icarus odin - % always01 ok ok ok ok ok - % always02 ok ok failed failed error - % always03 ok failed failed missing error - % arrays01 ok error error failed error - % forgen01 ok failed error failed error - % forgen02 ok failed error error error - \def\ok{\ding{52}} - \def\error{\ding{56}} - \def\failed{$\skull$} - \def\missing{$\skull$} - \rowcolors{2}{gray!25}{white} - \centerline{ - \begin{tabular}{|l|cccc|c|} - \hline - & \bf HANA & \bf VIS / vl2m & \bf Icarus Verilog & \bf Odin-II & \bf Yosys \\ - \hline - \tt always01 & \ok & \ok & \ok & \ok & \ok \\ - \tt always02 & \ok & \failed & \failed & \error & \ok \\ - \tt always03 & \failed & \failed & \missing & \error & \ok \\ - \tt arrays01 & \error & \error & \failed & \error & \ok \\ - \tt forgen01 & \failed & \error & \failed & \error & \ok \\ - \tt forgen02 & \failed & \error & \error & \error & \ok \\ - \hline - \end{tabular} - } - \centerline{ - \ding{52} \dots passed \hskip2em - \ding{56} \dots produced error \hskip2em - $\skull$ \dots incorrect output - } - \caption{Summary of all test results} - \label{tab:StateOfTheArt_sum} -\end{table} - diff --git a/manual/CHAPTER_StateOfTheArt/always01.v b/manual/CHAPTER_StateOfTheArt/always01.v deleted file mode 100644 index 4719ed47e..000000000 --- a/manual/CHAPTER_StateOfTheArt/always01.v +++ /dev/null @@ -1,12 +0,0 @@ -module uut_always01(clock, reset, c3, c2, c1, c0); - -input clock, reset; -output c3, c2, c1, c0; -reg [3:0] count; - -assign {c3, c2, c1, c0} = count; - -always @(posedge clock) - count <= reset ? 0 : count + 1; - -endmodule diff --git a/manual/CHAPTER_StateOfTheArt/always01_pub.v b/manual/CHAPTER_StateOfTheArt/always01_pub.v deleted file mode 100644 index 6a6a4b231..000000000 --- a/manual/CHAPTER_StateOfTheArt/always01_pub.v +++ /dev/null @@ -1,14 +0,0 @@ -module uut_always01(clock, - reset, count); - -input clock, reset; -output [3:0] count; -reg [3:0] count; - -always @(posedge clock) - count <= reset ? - 0 : count + 1; - - - -endmodule diff --git a/manual/CHAPTER_StateOfTheArt/always02.v b/manual/CHAPTER_StateOfTheArt/always02.v deleted file mode 100644 index 63f1ce317..000000000 --- a/manual/CHAPTER_StateOfTheArt/always02.v +++ /dev/null @@ -1,15 +0,0 @@ -module uut_always02(clock, reset, c3, c2, c1, c0); - -input clock, reset; -output c3, c2, c1, c0; -reg [3:0] count; - -assign {c3, c2, c1, c0} = count; - -always @(posedge clock) begin - count <= count + 1; - if (reset) - count <= 0; -end - -endmodule diff --git a/manual/CHAPTER_StateOfTheArt/always02_pub.v b/manual/CHAPTER_StateOfTheArt/always02_pub.v deleted file mode 100644 index 91f1ca16d..000000000 --- a/manual/CHAPTER_StateOfTheArt/always02_pub.v +++ /dev/null @@ -1,14 +0,0 @@ -module uut_always02(clock, - reset, count); - -input clock, reset; -output [3:0] count; -reg [3:0] count; - -always @(posedge clock) begin - count <= count + 1; - if (reset) - count <= 0; -end - -endmodule diff --git a/manual/CHAPTER_StateOfTheArt/always03.v b/manual/CHAPTER_StateOfTheArt/always03.v deleted file mode 100644 index 53386acd6..000000000 --- a/manual/CHAPTER_StateOfTheArt/always03.v +++ /dev/null @@ -1,23 +0,0 @@ -module uut_always03(clock, in1, in2, in3, in4, in5, in6, in7, - out1, out2, out3); - -input clock, in1, in2, in3, in4, in5, in6, in7; -output out1, out2, out3; -reg out1, out2, out3; - -always @(posedge clock) begin - out1 = in1; - if (in2) - out1 = !out1; - out2 <= out1; - if (in3) - out2 <= out2; - if (in4) - if (in5) - out3 <= in6; - else - out3 <= in7; - out1 = out1 ^ out2; -end - -endmodule diff --git a/manual/CHAPTER_StateOfTheArt/arrays01.v b/manual/CHAPTER_StateOfTheArt/arrays01.v deleted file mode 100644 index bd0eda294..000000000 --- a/manual/CHAPTER_StateOfTheArt/arrays01.v +++ /dev/null @@ -1,16 +0,0 @@ -module uut_arrays01(clock, we, addr, wr_data, rd_data); - -input clock, we; -input [3:0] addr, wr_data; -output [3:0] rd_data; -reg [3:0] rd_data; - -reg [3:0] memory [15:0]; - -always @(posedge clock) begin - if (we) - memory[addr] <= wr_data; - rd_data <= memory[addr]; -end - -endmodule diff --git a/manual/CHAPTER_StateOfTheArt/cmp_tbdata.c b/manual/CHAPTER_StateOfTheArt/cmp_tbdata.c deleted file mode 100644 index b188144dd..000000000 --- a/manual/CHAPTER_StateOfTheArt/cmp_tbdata.c +++ /dev/null @@ -1,67 +0,0 @@ -#include <stdio.h> -#include <stdlib.h> -#include <stdbool.h> -#include <string.h> - -int line = 0; -char buffer1[1024]; -char buffer2[1024]; - -void check(bool ok) -{ - if (ok) - return; - // fprintf(stderr, "Error in testbench output compare (line=%d):\n-%s\n+%s\n", line, buffer1, buffer2); - exit(1); -} - -int main(int argc, char **argv) -{ - FILE *f1, *f2; - bool eof1, eof2; - int i; - - check(argc == 3); - - f1 = fopen(argv[1], "r"); - f2 = fopen(argv[2], "r"); - - check(f1 && f2); - - while (!feof(f1) && !feof(f2)) - { - line++; - buffer1[0] = 0; - buffer2[0] = 0; - - eof1 = fgets(buffer1, 1024, f1) == NULL; - eof2 = fgets(buffer2, 1024, f2) == NULL; - - if (*buffer1 && buffer1[strlen(buffer1)-1] == '\n') - buffer1[strlen(buffer1)-1] = 0; - - if (*buffer2 && buffer2[strlen(buffer2)-1] == '\n') - buffer2[strlen(buffer2)-1] = 0; - - check(eof1 == eof2); - - for (i = 0; buffer1[i] || buffer2[i]; i++) - { - check(buffer1[i] != 0 && buffer2[i] != 0); - - // first argument is the reference. An 'z' or 'x' - // here means we don't care about the result. - if (buffer1[i] == 'z' || buffer1[i] == 'x') - continue; - - check(buffer1[i] == buffer2[i]); - } - } - - check(feof(f1) && feof(f2)); - - fclose(f1); - fclose(f2); - return 0; -} - diff --git a/manual/CHAPTER_StateOfTheArt/forgen01.v b/manual/CHAPTER_StateOfTheArt/forgen01.v deleted file mode 100644 index 70ee7e667..000000000 --- a/manual/CHAPTER_StateOfTheArt/forgen01.v +++ /dev/null @@ -1,20 +0,0 @@ -module uut_forgen01(a, y); - -input [4:0] a; -output y; - -integer i, j; -reg [31:0] lut; - -initial begin - for (i = 0; i < 32; i = i+1) begin - lut[i] = i > 1; - for (j = 2; j*j <= i; j = j+1) - if (i % j == 0) - lut[i] = 0; - end -end - -assign y = lut[a]; - -endmodule diff --git a/manual/CHAPTER_StateOfTheArt/forgen02.v b/manual/CHAPTER_StateOfTheArt/forgen02.v deleted file mode 100644 index 14af070c3..000000000 --- a/manual/CHAPTER_StateOfTheArt/forgen02.v +++ /dev/null @@ -1,30 +0,0 @@ -module uut_forgen02(a, b, cin, y, cout); - -parameter WIDTH = 8; - -input [WIDTH-1:0] a, b; -input cin; - -output [WIDTH-1:0] y; -output cout; - -genvar i; -wire [WIDTH-1:0] carry; - -generate - for (i = 0; i < WIDTH; i=i+1) begin:adder - wire [2:0] D; - assign D[1:0] = { a[i], b[i] }; - if (i == 0) begin:chain - assign D[2] = cin; - end else begin:chain - assign D[2] = carry[i-1]; - end - assign y[i] = ^D; - assign carry[i] = &D[1:0] | (^D[1:0] & D[2]); - end -endgenerate - -assign cout = carry[WIDTH-1]; - -endmodule diff --git a/manual/CHAPTER_StateOfTheArt/iverilog-0.8.7-buildfixes.patch b/manual/CHAPTER_StateOfTheArt/iverilog-0.8.7-buildfixes.patch deleted file mode 100644 index 63a03e595..000000000 --- a/manual/CHAPTER_StateOfTheArt/iverilog-0.8.7-buildfixes.patch +++ /dev/null @@ -1,20 +0,0 @@ ---- ./elab_net.cc.orig 2012-10-27 22:11:05.345688820 +0200 -+++ ./elab_net.cc 2012-10-27 22:12:23.398075860 +0200 -@@ -29,6 +29,7 @@ - - # include <iostream> - # include <cstring> -+# include <memory> - - /* - * This is a state flag that determines whether an elaborate_net must ---- ./syn-rules.y.orig 2012-10-27 22:25:38.890020489 +0200 -+++ ./syn-rules.y 2012-10-27 22:25:49.146071350 +0200 -@@ -25,6 +25,7 @@ - # include "config.h" - - # include <iostream> -+# include <stdio.h> - - /* - * This file implements synthesis based on matching threads and diff --git a/manual/CHAPTER_StateOfTheArt/mvsis-1.3.6-buildfixes.patch b/manual/CHAPTER_StateOfTheArt/mvsis-1.3.6-buildfixes.patch deleted file mode 100644 index 4b44320f8..000000000 --- a/manual/CHAPTER_StateOfTheArt/mvsis-1.3.6-buildfixes.patch +++ /dev/null @@ -1,36 +0,0 @@ ---- ./helpers/config.sub.orig 2012-10-27 22:09:04.429089223 +0200 -+++ ./helpers/config.sub 2012-10-27 22:09:11.501124295 +0200 -@@ -158,6 +158,7 @@ - | sparc | sparclet | sparclite | sparc64) - basic_machine=$basic_machine-unknown - ;; -+ x86_64-pc) ;; - # We use `pc' rather than `unknown' - # because (1) that's what they normally are, and - # (2) the word "unknown" tends to confuse beginning users. ---- ./src/base/ntki/ntkiFrames.c.orig 2012-10-27 22:09:26.961200963 +0200 -+++ ./src/base/ntki/ntkiFrames.c 2012-10-27 22:09:32.901230409 +0200 -@@ -23,7 +23,7 @@ - //////////////////////////////////////////////////////////////////////// - - static void Ntk_NetworkAddFrame( Ntk_Network_t * pNetNew, Ntk_Network_t * pNet, int iFrame ); --static void Ntk_NetworkReorderCiCo( Ntk_Network_t * pNet ); -+// static void Ntk_NetworkReorderCiCo( Ntk_Network_t * pNet ); - - extern int Ntk_NetworkVerifyVariables( Ntk_Network_t * pNet1, Ntk_Network_t * pNet2, int fVerbose ); - ---- ./src/graph/wn/wnStrashBin.c.orig 2012-10-27 22:27:29.966571294 +0200 -+++ ./src/graph/wn/wnStrashBin.c 2012-10-27 22:27:55.898699881 +0200 -@@ -76,8 +76,10 @@ - // assert( RetValue ); - - // clean the data of the nodes in the window -- Ntk_NetworkForEachNodeSpecial( pWnd->pNet, pNode ) -- pNode->pCopy = (Ntk_Node_t *)pNode->pData = NULL; -+ Ntk_NetworkForEachNodeSpecial( pWnd->pNet, pNode ) { -+ pNode->pData = NULL; -+ pNode->pCopy = NULL; -+ } - - // set the leaves - pgInputs = Sh_ManagerReadVars( pMan ); diff --git a/manual/CHAPTER_StateOfTheArt/simlib_hana.v b/manual/CHAPTER_StateOfTheArt/simlib_hana.v deleted file mode 100644 index 7fb54fa49..000000000 --- a/manual/CHAPTER_StateOfTheArt/simlib_hana.v +++ /dev/null @@ -1,1139 +0,0 @@ -/* -Copyright (C) 2009-2010 Parvez Ahmad -Written by Parvez Ahmad <parvez_ahmad@yahoo.co.uk>. - -This program is free software: you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 3 of the License, or -(at your option) any later version. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program. If not, see <http://www.gnu.org/licenses/>. */ - - -module BUF (input in, output out); - -assign out = in; - -endmodule - -module TRIBUF(input in, enable, output out); - -assign out = enable ? in : 1'bz; - -endmodule - -module INV(input in, output out); - -assign out = ~in; - -endmodule - -module AND2 #(parameter SIZE = 2) (input [SIZE-1:0] in, output out); - -assign out = ∈ - -endmodule - -module AND3 #(parameter SIZE = 3) (input [SIZE-1:0] in, output out); - -assign out = ∈ - -endmodule - -module AND4 #(parameter SIZE = 4) (input [SIZE-1:0] in, output out); - -assign out = ∈ - -endmodule - -module OR2 #(parameter SIZE = 2) (input [SIZE-1:0] in, output out); - -assign out = |in; - -endmodule - -module OR3 #(parameter SIZE = 3) (input [SIZE-1:0] in, output out); - -assign out = |in; - -endmodule - -module OR4 #(parameter SIZE = 4) (input [SIZE-1:0] in, output out); - -assign out = |in; - -endmodule - - -module NAND2 #(parameter SIZE = 2) (input [SIZE-1:0] in, output out); - -assign out = ~∈ - -endmodule - -module NAND3 #(parameter SIZE = 3) (input [SIZE-1:0] in, output out); - -assign out = ~∈ - -endmodule - -module NAND4 #(parameter SIZE = 4) (input [SIZE-1:0] in, output out); - -assign out = ~∈ - -endmodule - -module NOR2 #(parameter SIZE = 2) (input [SIZE-1:0] in, output out); - -assign out = ~|in; - -endmodule - -module NOR3 #(parameter SIZE = 3) (input [SIZE-1:0] in, output out); - -assign out = ~|in; - -endmodule - -module NOR4 #(parameter SIZE = 4) (input [SIZE-1:0] in, output out); - -assign out = ~|in; - -endmodule - - -module XOR2 #(parameter SIZE = 2) (input [SIZE-1:0] in, output out); - -assign out = ^in; - -endmodule - -module XOR3 #(parameter SIZE = 3) (input [SIZE-1:0] in, output out); - -assign out = ^in; - -endmodule - -module XOR4 #(parameter SIZE = 4) (input [SIZE-1:0] in, output out); - -assign out = ^in; - -endmodule - - -module XNOR2 #(parameter SIZE = 2) (input [SIZE-1:0] in, output out); - -assign out = ~^in; - -endmodule - -module XNOR3 #(parameter SIZE = 3) (input [SIZE-1:0] in, output out); - -assign out = ~^in; - -endmodule - -module XNOR4 #(parameter SIZE = 4) (input [SIZE-1:0] in, output out); - -assign out = ~^in; - -endmodule - -module DEC1 (input in, enable, output reg [1:0] out); - -always @(in or enable) - if(!enable) - out = 2'b00; - else begin - case (in) - 1'b0 : out = 2'b01; - 1'b1 : out = 2'b10; - endcase - end -endmodule - -module DEC2 (input [1:0] in, input enable, output reg [3:0] out); - -always @(in or enable) - if(!enable) - out = 4'b0000; - else begin - case (in) - 2'b00 : out = 4'b0001; - 2'b01 : out = 4'b0010; - 2'b10 : out = 4'b0100; - 2'b11 : out = 4'b1000; - endcase - end -endmodule - -module DEC3 (input [2:0] in, input enable, output reg [7:0] out); - -always @(in or enable) - if(!enable) - out = 8'b00000000; - else begin - case (in) - 3'b000 : out = 8'b00000001; - 3'b001 : out = 8'b00000010; - 3'b010 : out = 8'b00000100; - 3'b011 : out = 8'b00001000; - 3'b100 : out = 8'b00010000; - 3'b101 : out = 8'b00100000; - 3'b110 : out = 8'b01000000; - 3'b111 : out = 8'b10000000; - endcase - end -endmodule - -module DEC4 (input [3:0] in, input enable, output reg [15:0] out); - -always @(in or enable) - if(!enable) - out = 16'b0000000000000000; - else begin - case (in) - 4'b0000 : out = 16'b0000000000000001; - 4'b0001 : out = 16'b0000000000000010; - 4'b0010 : out = 16'b0000000000000100; - 4'b0011 : out = 16'b0000000000001000; - 4'b0100 : out = 16'b0000000000010000; - 4'b0101 : out = 16'b0000000000100000; - 4'b0110 : out = 16'b0000000001000000; - 4'b0111 : out = 16'b0000000010000000; - 4'b1000 : out = 16'b0000000100000000; - 4'b1001 : out = 16'b0000001000000000; - 4'b1010 : out = 16'b0000010000000000; - 4'b1011 : out = 16'b0000100000000000; - 4'b1100 : out = 16'b0001000000000000; - 4'b1101 : out = 16'b0010000000000000; - 4'b1110 : out = 16'b0100000000000000; - 4'b1111 : out = 16'b1000000000000000; - endcase - end -endmodule -module DEC5 (input [4:0] in, input enable, output reg [31:0] out); - -always @(in or enable) - if(!enable) - out = 32'b00000000000000000000000000000000; - else begin - case (in) - 5'b00000 : out = 32'b00000000000000000000000000000001; - 5'b00001 : out = 32'b00000000000000000000000000000010; - 5'b00010 : out = 32'b00000000000000000000000000000100; - 5'b00011 : out = 32'b00000000000000000000000000001000; - 5'b00100 : out = 32'b00000000000000000000000000010000; - 5'b00101 : out = 32'b00000000000000000000000000100000; - 5'b00110 : out = 32'b00000000000000000000000001000000; - 5'b00111 : out = 32'b00000000000000000000000010000000; - 5'b01000 : out = 32'b00000000000000000000000100000000; - 5'b01001 : out = 32'b00000000000000000000001000000000; - 5'b01010 : out = 32'b00000000000000000000010000000000; - 5'b01011 : out = 32'b00000000000000000000100000000000; - 5'b01100 : out = 32'b00000000000000000001000000000000; - 5'b01101 : out = 32'b00000000000000000010000000000000; - 5'b01110 : out = 32'b00000000000000000100000000000000; - 5'b01111 : out = 32'b00000000000000001000000000000000; - 5'b10000 : out = 32'b00000000000000010000000000000000; - 5'b10001 : out = 32'b00000000000000100000000000000000; - 5'b10010 : out = 32'b00000000000001000000000000000000; - 5'b10011 : out = 32'b00000000000010000000000000000000; - 5'b10100 : out = 32'b00000000000100000000000000000000; - 5'b10101 : out = 32'b00000000001000000000000000000000; - 5'b10110 : out = 32'b00000000010000000000000000000000; - 5'b10111 : out = 32'b00000000100000000000000000000000; - 5'b11000 : out = 32'b00000001000000000000000000000000; - 5'b11001 : out = 32'b00000010000000000000000000000000; - 5'b11010 : out = 32'b00000100000000000000000000000000; - 5'b11011 : out = 32'b00001000000000000000000000000000; - 5'b11100 : out = 32'b00010000000000000000000000000000; - 5'b11101 : out = 32'b00100000000000000000000000000000; - 5'b11110 : out = 32'b01000000000000000000000000000000; - 5'b11111 : out = 32'b10000000000000000000000000000000; - endcase - end -endmodule - -module DEC6 (input [5:0] in, input enable, output reg [63:0] out); - -always @(in or enable) - if(!enable) - out = 64'b0000000000000000000000000000000000000000000000000000000000000000; - else begin - case (in) - 6'b000000 : out = 64'b0000000000000000000000000000000000000000000000000000000000000001; - 6'b000001 : out = 64'b0000000000000000000000000000000000000000000000000000000000000010; - 6'b000010 : out = 64'b0000000000000000000000000000000000000000000000000000000000000100; - 6'b000011 : out = 64'b0000000000000000000000000000000000000000000000000000000000001000; - 6'b000100 : out = 64'b0000000000000000000000000000000000000000000000000000000000010000; - 6'b000101 : out = 64'b0000000000000000000000000000000000000000000000000000000000100000; - 6'b000110 : out = 64'b0000000000000000000000000000000000000000000000000000000001000000; - 6'b000111 : out = 64'b0000000000000000000000000000000000000000000000000000000010000000; - 6'b001000 : out = 64'b0000000000000000000000000000000000000000000000000000000100000000; - 6'b001001 : out = 64'b0000000000000000000000000000000000000000000000000000001000000000; - 6'b001010 : out = 64'b0000000000000000000000000000000000000000000000000000010000000000; - 6'b001011 : out = 64'b0000000000000000000000000000000000000000000000000000100000000000; - 6'b001100 : out = 64'b0000000000000000000000000000000000000000000000000001000000000000; - 6'b001101 : out = 64'b0000000000000000000000000000000000000000000000000010000000000000; - 6'b001110 : out = 64'b0000000000000000000000000000000000000000000000000100000000000000; - 6'b001111 : out = 64'b0000000000000000000000000000000000000000000000001000000000000000; - 6'b010000 : out = 64'b0000000000000000000000000000000000000000000000010000000000000000; - 6'b010001 : out = 64'b0000000000000000000000000000000000000000000000100000000000000000; - 6'b010010 : out = 64'b0000000000000000000000000000000000000000000001000000000000000000; - 6'b010011 : out = 64'b0000000000000000000000000000000000000000000010000000000000000000; - 6'b010100 : out = 64'b0000000000000000000000000000000000000000000100000000000000000000; - 6'b010101 : out = 64'b0000000000000000000000000000000000000000001000000000000000000000; - 6'b010110 : out = 64'b0000000000000000000000000000000000000000010000000000000000000000; - 6'b010111 : out = 64'b0000000000000000000000000000000000000000100000000000000000000000; - 6'b011000 : out = 64'b0000000000000000000000000000000000000001000000000000000000000000; - 6'b011001 : out = 64'b0000000000000000000000000000000000000010000000000000000000000000; - 6'b011010 : out = 64'b0000000000000000000000000000000000000100000000000000000000000000; - 6'b011011 : out = 64'b0000000000000000000000000000000000001000000000000000000000000000; - 6'b011100 : out = 64'b0000000000000000000000000000000000010000000000000000000000000000; - 6'b011101 : out = 64'b0000000000000000000000000000000000100000000000000000000000000000; - 6'b011110 : out = 64'b0000000000000000000000000000000001000000000000000000000000000000; - 6'b011111 : out = 64'b0000000000000000000000000000000010000000000000000000000000000000; - - 6'b100000 : out = 64'b0000000000000000000000000000000100000000000000000000000000000000; - 6'b100001 : out = 64'b0000000000000000000000000000001000000000000000000000000000000000; - 6'b100010 : out = 64'b0000000000000000000000000000010000000000000000000000000000000000; - 6'b100011 : out = 64'b0000000000000000000000000000100000000000000000000000000000000000; - 6'b100100 : out = 64'b0000000000000000000000000001000000000000000000000000000000000000; - 6'b100101 : out = 64'b0000000000000000000000000010000000000000000000000000000000000000; - 6'b100110 : out = 64'b0000000000000000000000000100000000000000000000000000000000000000; - 6'b100111 : out = 64'b0000000000000000000000001000000000000000000000000000000000000000; - 6'b101000 : out = 64'b0000000000000000000000010000000000000000000000000000000000000000; - 6'b101001 : out = 64'b0000000000000000000000100000000000000000000000000000000000000000; - 6'b101010 : out = 64'b0000000000000000000001000000000000000000000000000000000000000000; - 6'b101011 : out = 64'b0000000000000000000010000000000000000000000000000000000000000000; - 6'b101100 : out = 64'b0000000000000000000100000000000000000000000000000000000000000000; - 6'b101101 : out = 64'b0000000000000000001000000000000000000000000000000000000000000000; - 6'b101110 : out = 64'b0000000000000000010000000000000000000000000000000000000000000000; - 6'b101111 : out = 64'b0000000000000000100000000000000000000000000000000000000000000000; - 6'b110000 : out = 64'b0000000000000001000000000000000000000000000000000000000000000000; - 6'b110001 : out = 64'b0000000000000010000000000000000000000000000000000000000000000000; - 6'b110010 : out = 64'b0000000000000100000000000000000000000000000000000000000000000000; - 6'b110011 : out = 64'b0000000000001000000000000000000000000000000000000000000000000000; - 6'b110100 : out = 64'b0000000000010000000000000000000000000000000000000000000000000000; - 6'b110101 : out = 64'b0000000000100000000000000000000000000000000000000000000000000000; - 6'b110110 : out = 64'b0000000001000000000000000000000000000000000000000000000000000000; - 6'b110111 : out = 64'b0000000010000000000000000000000000000000000000000000000000000000; - 6'b111000 : out = 64'b0000000100000000000000000000000000000000000000000000000000000000; - 6'b111001 : out = 64'b0000001000000000000000000000000000000000000000000000000000000000; - 6'b111010 : out = 64'b0000010000000000000000000000000000000000000000000000000000000000; - 6'b111011 : out = 64'b0000100000000000000000000000000000000000000000000000000000000000; - 6'b111100 : out = 64'b0001000000000000000000000000000000000000000000000000000000000000; - 6'b111101 : out = 64'b0010000000000000000000000000000000000000000000000000000000000000; - 6'b111110 : out = 64'b0100000000000000000000000000000000000000000000000000000000000000; - 6'b111111 : out = 64'b1000000000000000000000000000000000000000000000000000000000000000; - endcase - end -endmodule - - -module MUX2(input [1:0] in, input select, output reg out); - -always @( in or select) - case (select) - 0: out = in[0]; - 1: out = in[1]; - endcase -endmodule - - -module MUX4(input [3:0] in, input [1:0] select, output reg out); - -always @( in or select) - case (select) - 0: out = in[0]; - 1: out = in[1]; - 2: out = in[2]; - 3: out = in[3]; - endcase -endmodule - - -module MUX8(input [7:0] in, input [2:0] select, output reg out); - -always @( in or select) - case (select) - 0: out = in[0]; - 1: out = in[1]; - 2: out = in[2]; - 3: out = in[3]; - 4: out = in[4]; - 5: out = in[5]; - 6: out = in[6]; - 7: out = in[7]; - endcase -endmodule - -module MUX16(input [15:0] in, input [3:0] select, output reg out); - -always @( in or select) - case (select) - 0: out = in[0]; - 1: out = in[1]; - 2: out = in[2]; - 3: out = in[3]; - 4: out = in[4]; - 5: out = in[5]; - 6: out = in[6]; - 7: out = in[7]; - 8: out = in[8]; - 9: out = in[9]; - 10: out = in[10]; - 11: out = in[11]; - 12: out = in[12]; - 13: out = in[13]; - 14: out = in[14]; - 15: out = in[15]; - endcase -endmodule - -module MUX32(input [31:0] in, input [4:0] select, output reg out); - -always @( in or select) - case (select) - 0: out = in[0]; - 1: out = in[1]; - 2: out = in[2]; - 3: out = in[3]; - 4: out = in[4]; - 5: out = in[5]; - 6: out = in[6]; - 7: out = in[7]; - 8: out = in[8]; - 9: out = in[9]; - 10: out = in[10]; - 11: out = in[11]; - 12: out = in[12]; - 13: out = in[13]; - 14: out = in[14]; - 15: out = in[15]; - 16: out = in[16]; - 17: out = in[17]; - 18: out = in[18]; - 19: out = in[19]; - 20: out = in[20]; - 21: out = in[21]; - 22: out = in[22]; - 23: out = in[23]; - 24: out = in[24]; - 25: out = in[25]; - 26: out = in[26]; - 27: out = in[27]; - 28: out = in[28]; - 29: out = in[29]; - 30: out = in[30]; - 31: out = in[31]; - endcase -endmodule - -module MUX64(input [63:0] in, input [5:0] select, output reg out); - -always @( in or select) - case (select) - 0: out = in[0]; - 1: out = in[1]; - 2: out = in[2]; - 3: out = in[3]; - 4: out = in[4]; - 5: out = in[5]; - 6: out = in[6]; - 7: out = in[7]; - 8: out = in[8]; - 9: out = in[9]; - 10: out = in[10]; - 11: out = in[11]; - 12: out = in[12]; - 13: out = in[13]; - 14: out = in[14]; - 15: out = in[15]; - 16: out = in[16]; - 17: out = in[17]; - 18: out = in[18]; - 19: out = in[19]; - 20: out = in[20]; - 21: out = in[21]; - 22: out = in[22]; - 23: out = in[23]; - 24: out = in[24]; - 25: out = in[25]; - 26: out = in[26]; - 27: out = in[27]; - 28: out = in[28]; - 29: out = in[29]; - 30: out = in[30]; - 31: out = in[31]; - 32: out = in[32]; - 33: out = in[33]; - 34: out = in[34]; - 35: out = in[35]; - 36: out = in[36]; - 37: out = in[37]; - 38: out = in[38]; - 39: out = in[39]; - 40: out = in[40]; - 41: out = in[41]; - 42: out = in[42]; - 43: out = in[43]; - 44: out = in[44]; - 45: out = in[45]; - 46: out = in[46]; - 47: out = in[47]; - 48: out = in[48]; - 49: out = in[49]; - 50: out = in[50]; - 51: out = in[51]; - 52: out = in[52]; - 53: out = in[53]; - 54: out = in[54]; - 55: out = in[55]; - 56: out = in[56]; - 57: out = in[57]; - 58: out = in[58]; - 59: out = in[59]; - 60: out = in[60]; - 61: out = in[61]; - 62: out = in[62]; - 63: out = in[63]; - endcase -endmodule - -module ADD1(input in1, in2, cin, output out, cout); - -assign {cout, out} = in1 + in2 + cin; - -endmodule - -module ADD2 #(parameter SIZE = 2)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 + in2 + cin; - -endmodule - -module ADD4 #(parameter SIZE = 4)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 + in2 + cin; - -endmodule - -module ADD8 #(parameter SIZE = 8)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 + in2 + cin; - -endmodule - -module ADD16 #(parameter SIZE = 16)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 + in2 + cin; - -endmodule - -module ADD32 #(parameter SIZE = 32)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 + in2 + cin; - -endmodule -module ADD64 #(parameter SIZE = 64)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 + in2 + cin; - -endmodule - -module SUB1(input in1, in2, cin, output out, cout); - -assign {cout, out} = in1 - in2 - cin; - -endmodule - -module SUB2 #(parameter SIZE = 2)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 - in2 - cin; - -endmodule - -module SUB4 #(parameter SIZE = 4)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 - in2 - cin; - -endmodule - -module SUB8 #(parameter SIZE = 8)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 - in2 - cin; - -endmodule - -module SUB16 #(parameter SIZE = 16)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 - in2 - cin; - -endmodule - -module SUB32 #(parameter SIZE = 32)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 - in2 - cin; - -endmodule -module SUB64 #(parameter SIZE = 64)(input [SIZE-1:0] in1, in2, - input cin, output [SIZE-1:0] out, output cout); - -assign {cout, out} = in1 - in2 - cin; - -endmodule - -module MUL1 #(parameter SIZE = 1)(input in1, in2, output [2*SIZE-1:0] out); - -assign out = in1*in2; - -endmodule - -module MUL2 #(parameter SIZE = 2)(input [SIZE-1:0] in1, in2, output [2*SIZE-1:0] out); - -assign out = in1*in2; - -endmodule - -module MUL4 #(parameter SIZE = 4)(input [SIZE-1:0] in1, in2, output [2*SIZE-1:0] out); - -assign out = in1*in2; - -endmodule - -module MUL8 #(parameter SIZE = 8)(input [SIZE-1:0] in1, in2, output [2*SIZE-1:0] out); - -assign out = in1*in2; - -endmodule - -module MUL16 #(parameter SIZE = 16)(input [SIZE-1:0] in1, in2, output [2*SIZE-1:0] out); - -assign out = in1*in2; - -endmodule - -module MUL32 #(parameter SIZE = 32)(input [SIZE-1:0] in1, in2, output [2*SIZE-1:0] out); - -assign out = in1*in2; - -endmodule - -module MUL64 #(parameter SIZE = 64)(input [SIZE-1:0] in1, in2, output [2*SIZE-1:0] out); - -assign out = in1*in2; - -endmodule - -module DIV1 #(parameter SIZE = 1)(input in1, in2, output out, rem); - -assign out = in1/in2; -assign rem = in1%in2; - -endmodule - -module DIV2 #(parameter SIZE = 2)(input [SIZE-1:0] in1, in2, - output [SIZE-1:0] out, rem); - -assign out = in1/in2; -assign rem = in1%in2; - -endmodule - -module DIV4 #(parameter SIZE = 4)(input [SIZE-1:0] in1, in2, - output [SIZE-1:0] out, rem); - -assign out = in1/in2; -assign rem = in1%in2; - -endmodule - -module DIV8 #(parameter SIZE = 8)(input [SIZE-1:0] in1, in2, - output [SIZE-1:0] out, rem); - -assign out = in1/in2; -assign rem = in1%in2; - -endmodule - -module DIV16 #(parameter SIZE = 16)(input [SIZE-1:0] in1, in2, - output [SIZE-1:0] out, rem); - -assign out = in1/in2; -assign rem = in1%in2; - -endmodule - -module DIV32 #(parameter SIZE = 32)(input [SIZE-1:0] in1, in2, - output [SIZE-1:0] out, rem); - -assign out = in1/in2; -assign rem = in1%in2; - -endmodule - -module DIV64 #(parameter SIZE = 64)(input [SIZE-1:0] in1, in2, - output [SIZE-1:0] out, rem); - -assign out = in1/in2; -assign rem = in1%in2; - -endmodule - -module FF (input d, clk, output reg q); -always @( posedge clk) - q <= d; -endmodule - - -module RFF(input d, clk, reset, output reg q); -always @(posedge clk or posedge reset) - if(reset) - q <= 0; - else - q <= d; -endmodule - -module SFF(input d, clk, set, output reg q); -always @(posedge clk or posedge set) - if(set) - q <= 1; - else - q <= d; -endmodule - -module RSFF(input d, clk, set, reset, output reg q); -always @(posedge clk or posedge reset or posedge set) - if(reset) - q <= 0; - else if(set) - q <= 1; - else - q <= d; -endmodule - -module SRFF(input d, clk, set, reset, output reg q); -always @(posedge clk or posedge set or posedge reset) - if(set) - q <= 1; - else if(reset) - q <= 0; - else - q <= d; -endmodule - -module LATCH(input d, enable, output reg q); -always @( d or enable) - if(enable) - q <= d; -endmodule - -module RLATCH(input d, reset, enable, output reg q); -always @( d or enable or reset) - if(enable) - if(reset) - q <= 0; - else - q <= d; -endmodule - -module LSHIFT1 #(parameter SIZE = 1)(input in, shift, val, output reg out); - -always @ (in, shift, val) begin - if(shift) - out = val; - else - out = in; -end - -endmodule - - -module LSHIFT2 #(parameter SIZE = 2)(input [SIZE-1:0] in, - input [SIZE-1:0] shift, input val, - output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in << shift; - if(val) - out = out | ({SIZE-1 {1'b1} } >> (SIZE-1-shift)); -end -endmodule - -module LSHIFT4 #(parameter SIZE = 4)(input [SIZE-1:0] in, - input [2:0] shift, input val, output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in << shift; - if(val) - out = out | ({SIZE-1 {1'b1} } >> (SIZE-1-shift)); -end -endmodule - - -module LSHIFT8 #(parameter SIZE = 8)(input [SIZE-1:0] in, - input [3:0] shift, input val, output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in << shift; - if(val) - out = out | ({SIZE-1 {1'b1} } >> (SIZE-1-shift)); -end -endmodule - -module LSHIFT16 #(parameter SIZE = 16)(input [SIZE-1:0] in, - input [4:0] shift, input val, output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in << shift; - if(val) - out = out | ({SIZE-1 {1'b1} } >> (SIZE-1-shift)); -end -endmodule - -module LSHIFT32 #(parameter SIZE = 32)(input [SIZE-1:0] in, - input [5:0] shift, input val, output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in << shift; - if(val) - out = out | ({SIZE-1 {1'b1} } >> (SIZE-1-shift)); -end -endmodule - -module LSHIFT64 #(parameter SIZE = 64)(input [SIZE-1:0] in, - input [6:0] shift, input val, output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in << shift; - if(val) - out = out | ({SIZE-1 {1'b1} } >> (SIZE-1-shift)); -end -endmodule - -module RSHIFT1 #(parameter SIZE = 1)(input in, shift, val, output reg out); - -always @ (in, shift, val) begin - if(shift) - out = val; - else - out = in; -end - -endmodule - -module RSHIFT2 #(parameter SIZE = 2)(input [SIZE-1:0] in, - input [SIZE-1:0] shift, input val, - output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in >> shift; - if(val) - out = out | ({SIZE-1 {1'b1} } << (SIZE-1-shift)); -end - -endmodule - - -module RSHIFT4 #(parameter SIZE = 4)(input [SIZE-1:0] in, - input [2:0] shift, input val, - output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in >> shift; - if(val) - out = out | ({SIZE-1 {1'b1} } << (SIZE-1-shift)); -end -endmodule - -module RSHIFT8 #(parameter SIZE = 8)(input [SIZE-1:0] in, - input [3:0] shift, input val, - output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in >> shift; - if(val) - out = out | ({SIZE-1 {1'b1} } << (SIZE-1-shift)); -end - -endmodule - -module RSHIFT16 #(parameter SIZE = 16)(input [SIZE-1:0] in, - input [4:0] shift, input val, - output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in >> shift; - if(val) - out = out | ({SIZE-1 {1'b1} } << (SIZE-1-shift)); -end -endmodule - - -module RSHIFT32 #(parameter SIZE = 32)(input [SIZE-1:0] in, - input [5:0] shift, input val, - output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in >> shift; - if(val) - out = out | ({SIZE-1 {1'b1} } << (SIZE-1-shift)); -end -endmodule - -module RSHIFT64 #(parameter SIZE = 64)(input [SIZE-1:0] in, - input [6:0] shift, input val, - output reg [SIZE-1:0] out); - -always @(in or shift or val) begin - out = in >> shift; - if(val) - out = out | ({SIZE-1 {1'b1} } << (SIZE-1-shift)); -end -endmodule - -module CMP1 #(parameter SIZE = 1) (input in1, in2, - output reg equal, unequal, greater, lesser); - -always @ (in1 or in2) begin - if(in1 == in2) begin - equal = 1; - unequal = 0; - greater = 0; - lesser = 0; - end - else begin - equal = 0; - unequal = 1; - - if(in1 < in2) begin - greater = 0; - lesser = 1; - end - else begin - greater = 1; - lesser = 0; - end - end -end -endmodule - - -module CMP2 #(parameter SIZE = 2) (input [SIZE-1:0] in1, in2, - output reg equal, unequal, greater, lesser); - -always @ (in1 or in2) begin - if(in1 == in2) begin - equal = 1; - unequal = 0; - greater = 0; - lesser = 0; - end - else begin - equal = 0; - unequal = 1; - - if(in1 < in2) begin - greater = 0; - lesser = 1; - end - else begin - greater = 1; - lesser = 0; - end - end -end -endmodule - -module CMP4 #(parameter SIZE = 4) (input [SIZE-1:0] in1, in2, - output reg equal, unequal, greater, lesser); - -always @ (in1 or in2) begin - if(in1 == in2) begin - equal = 1; - unequal = 0; - greater = 0; - lesser = 0; - end - else begin - equal = 0; - unequal = 1; - - if(in1 < in2) begin - greater = 0; - lesser = 1; - end - else begin - greater = 1; - lesser = 0; - end - end -end -endmodule - -module CMP8 #(parameter SIZE = 8) (input [SIZE-1:0] in1, in2, - output reg equal, unequal, greater, lesser); - -always @ (in1 or in2) begin - if(in1 == in2) begin - equal = 1; - unequal = 0; - greater = 0; - lesser = 0; - end - else begin - equal = 0; - unequal = 1; - - if(in1 < in2) begin - greater = 0; - lesser = 1; - end - else begin - greater = 1; - lesser = 0; - end - end -end -endmodule - -module CMP16 #(parameter SIZE = 16) (input [SIZE-1:0] in1, in2, - output reg equal, unequal, greater, lesser); - -always @ (in1 or in2) begin - if(in1 == in2) begin - equal = 1; - unequal = 0; - greater = 0; - lesser = 0; - end - else begin - equal = 0; - unequal = 1; - - if(in1 < in2) begin - greater = 0; - lesser = 1; - end - else begin - greater = 1; - lesser = 0; - end - end -end -endmodule - -module CMP32 #(parameter SIZE = 32) (input [SIZE-1:0] in1, in2, - output reg equal, unequal, greater, lesser); - -always @ (in1 or in2) begin - if(in1 == in2) begin - equal = 1; - unequal = 0; - greater = 0; - lesser = 0; - end - else begin - equal = 0; - unequal = 1; - - if(in1 < in2) begin - greater = 0; - lesser = 1; - end - else begin - greater = 1; - lesser = 0; - end - end -end -endmodule - -module CMP64 #(parameter SIZE = 64) (input [SIZE-1:0] in1, in2, - output reg equal, unequal, greater, lesser); - -always @ (in1 or in2) begin - if(in1 == in2) begin - equal = 1; - unequal = 0; - greater = 0; - lesser = 0; - end - else begin - equal = 0; - unequal = 1; - - if(in1 < in2) begin - greater = 0; - lesser = 1; - end - else begin - greater = 1; - lesser = 0; - end - end -end -endmodule - -module VCC (output supply1 out); -endmodule - -module GND (output supply0 out); -endmodule - - -module INC1 #(parameter SIZE = 1) (input in, output [SIZE:0] out); - -assign out = in + 1; - -endmodule - -module INC2 #(parameter SIZE = 2) (input [SIZE-1:0] in, output [SIZE:0] out); - -assign out = in + 1; - -endmodule - -module INC4 #(parameter SIZE = 4) (input [SIZE-1:0] in, output [SIZE:0] out); -assign out = in + 1; - -endmodule - -module INC8 #(parameter SIZE = 8) (input [SIZE-1:0] in, output [SIZE:0] out); -assign out = in + 1; - -endmodule - -module INC16 #(parameter SIZE = 16) (input [SIZE-1:0] in, output [SIZE:0] out); -assign out = in + 1; - -endmodule - -module INC32 #(parameter SIZE = 32) (input [SIZE-1:0] in, output [SIZE:0] out); -assign out = in + 1; - -endmodule -module INC64 #(parameter SIZE = 64) (input [SIZE-1:0] in, output [SIZE:0] out); -assign out = in + 1; - -endmodule - diff --git a/manual/CHAPTER_StateOfTheArt/simlib_icarus.v b/manual/CHAPTER_StateOfTheArt/simlib_icarus.v deleted file mode 100644 index fdd7ef61f..000000000 --- a/manual/CHAPTER_StateOfTheArt/simlib_icarus.v +++ /dev/null @@ -1,224 +0,0 @@ - -module cell0(Result0); -output Result0; -assign Result0 = 0; -endmodule - -module cell1(Result0); -output Result0; -assign Result0 = 1; -endmodule - -module ADD4( - DataA0, DataA1, DataA2, DataA3, - DataB0, DataB1, DataB2, DataB3, - Result0, Result1, Result2, Result3, Cout -); -input DataA0, DataA1, DataA2, DataA3; -input DataB0, DataB1, DataB2, DataB3; -output Result0, Result1, Result2, Result3, Cout; -assign {Cout, Result3, Result2, Result1, Result0} = {DataA3, DataA2, DataA1, DataA0} + {DataB3, DataB2, DataB1, DataB0}; -endmodule - -module BUF(DATA, RESULT); -input DATA; -output RESULT; -assign RESULT = DATA; -endmodule - -module INV(DATA, RESULT); -input DATA; -output RESULT; -assign RESULT = ~DATA; -endmodule - -module fd4( - Clock, - Data0, Data1, Data2, Data3, - Q0, Q1, Q2, Q3 -); -input Clock; -input Data0, Data1, Data2, Data3; -output reg Q0, Q1, Q2, Q3; -always @(posedge Clock) - {Q0, Q1, Q2, Q3} <= {Data0, Data1, Data2, Data3}; -endmodule - -module fdce1( - Clock, Enable, - Data0, - Q0 -); -input Clock, Enable; -input Data0; -output reg Q0; -always @(posedge Clock) - if (Enable) - Q0 <= Data0; -endmodule - -module fdce4( - Clock, Enable, - Data0, Data1, Data2, Data3, - Q0, Q1, Q2, Q3 -); -input Clock, Enable; -input Data0, Data1, Data2, Data3; -output reg Q0, Q1, Q2, Q3; -always @(posedge Clock) - if (Enable) - {Q0, Q1, Q2, Q3} <= {Data0, Data1, Data2, Data3}; -endmodule - -module mux4_1_2( - Sel0, - Data0x0, Data0x1, Data0x2, Data0x3, - Data1x0, Data1x1, Data1x2, Data1x3, - Result0, Result1, Result2, Result3 -); -input Sel0; -input Data0x0, Data0x1, Data0x2, Data0x3; -input Data1x0, Data1x1, Data1x2, Data1x3; -output Result0, Result1, Result2, Result3; -assign {Result0, Result1, Result2, Result3} = Sel0 ? {Data1x0, Data1x1, Data1x2, Data1x3} : {Data0x0, Data0x1, Data0x2, Data0x3}; -endmodule - -module mux1_1_2( - Sel0, - Data0x0, - Data1x0, - Result0 -); -input Sel0; -input Data0x0; -input Data1x0; -output Result0; -assign Result0 = Sel0 ? Data1x0 : Data0x0; -endmodule - -module xor2( - DATA0X0, - DATA1X0, - RESULT0 -); -input DATA0X0; -input DATA1X0; -output RESULT0; -assign RESULT0 = DATA1X0 ^ DATA0X0; -endmodule - -module fdce64( - Clock, Enable, - Data0, Data1, Data2, Data3, Data4, Data5, Data6, Data7, Data8, Data9, Data10, Data11, Data12, Data13, Data14, Data15, Data16, Data17, Data18, Data19, Data20, Data21, Data22, Data23, Data24, Data25, Data26, Data27, Data28, Data29, Data30, Data31, Data32, Data33, Data34, Data35, Data36, Data37, Data38, Data39, Data40, Data41, Data42, Data43, Data44, Data45, Data46, Data47, Data48, Data49, Data50, Data51, Data52, Data53, Data54, Data55, Data56, Data57, Data58, Data59, Data60, Data61, Data62, Data63, - Q0, Q1, Q2, Q3, Q4, Q5, Q6, Q7, Q8, Q9, Q10, Q11, Q12, Q13, Q14, Q15, Q16, Q17, Q18, Q19, Q20, Q21, Q22, Q23, Q24, Q25, Q26, Q27, Q28, Q29, Q30, Q31, Q32, Q33, Q34, Q35, Q36, Q37, Q38, Q39, Q40, Q41, Q42, Q43, Q44, Q45, Q46, Q47, Q48, Q49, Q50, Q51, Q52, Q53, Q54, Q55, Q56, Q57, Q58, Q59, Q60, Q61, Q62, Q63 -); -input Clock, Enable; -input Data0, Data1, Data2, Data3, Data4, Data5, Data6, Data7, Data8, Data9, Data10, Data11, Data12, Data13, Data14, Data15, Data16, Data17, Data18, Data19, Data20, Data21, Data22, Data23, Data24, Data25, Data26, Data27, Data28, Data29, Data30, Data31, Data32, Data33, Data34, Data35, Data36, Data37, Data38, Data39, Data40, Data41, Data42, Data43, Data44, Data45, Data46, Data47, Data48, Data49, Data50, Data51, Data52, Data53, Data54, Data55, Data56, Data57, Data58, Data59, Data60, Data61, Data62, Data63; -output reg Q0, Q1, Q2, Q3, Q4, Q5, Q6, Q7, Q8, Q9, Q10, Q11, Q12, Q13, Q14, Q15, Q16, Q17, Q18, Q19, Q20, Q21, Q22, Q23, Q24, Q25, Q26, Q27, Q28, Q29, Q30, Q31, Q32, Q33, Q34, Q35, Q36, Q37, Q38, Q39, Q40, Q41, Q42, Q43, Q44, Q45, Q46, Q47, Q48, Q49, Q50, Q51, Q52, Q53, Q54, Q55, Q56, Q57, Q58, Q59, Q60, Q61, Q62, Q63; -always @(posedge Clock) - if (Enable) - { Q0, Q1, Q2, Q3, Q4, Q5, Q6, Q7, Q8, Q9, Q10, Q11, Q12, Q13, Q14, Q15, Q16, Q17, Q18, Q19, Q20, Q21, Q22, Q23, Q24, Q25, Q26, Q27, Q28, Q29, Q30, Q31, Q32, Q33, Q34, Q35, Q36, Q37, Q38, Q39, Q40, Q41, Q42, Q43, Q44, Q45, Q46, Q47, Q48, Q49, Q50, Q51, Q52, Q53, Q54, Q55, Q56, Q57, Q58, Q59, Q60, Q61, Q62, Q63 } <= { Data0, Data1, Data2, Data3, Data4, Data5, Data6, Data7, Data8, Data9, Data10, Data11, Data12, Data13, Data14, Data15, Data16, Data17, Data18, Data19, Data20, Data21, Data22, Data23, Data24, Data25, Data26, Data27, Data28, Data29, Data30, Data31, Data32, Data33, Data34, Data35, Data36, Data37, Data38, Data39, Data40, Data41, Data42, Data43, Data44, Data45, Data46, Data47, Data48, Data49, Data50, Data51, Data52, Data53, Data54, Data55, Data56, Data57, Data58, Data59, Data60, Data61, Data62, Data63 }; -endmodule - -module mux4_4_16( - Sel0, Sel1, Sel2, Sel3, - Result0, Result1, Result2, Result3, - Data0x0, Data0x1, Data0x2, Data0x3, - Data1x0, Data1x1, Data1x2, Data1x3, - Data2x0, Data2x1, Data2x2, Data2x3, - Data3x0, Data3x1, Data3x2, Data3x3, - Data4x0, Data4x1, Data4x2, Data4x3, - Data5x0, Data5x1, Data5x2, Data5x3, - Data6x0, Data6x1, Data6x2, Data6x3, - Data7x0, Data7x1, Data7x2, Data7x3, - Data8x0, Data8x1, Data8x2, Data8x3, - Data9x0, Data9x1, Data9x2, Data9x3, - Data10x0, Data10x1, Data10x2, Data10x3, - Data11x0, Data11x1, Data11x2, Data11x3, - Data12x0, Data12x1, Data12x2, Data12x3, - Data13x0, Data13x1, Data13x2, Data13x3, - Data14x0, Data14x1, Data14x2, Data14x3, - Data15x0, Data15x1, Data15x2, Data15x3 -); -input Sel0, Sel1, Sel2, Sel3; -output Result0, Result1, Result2, Result3; -input Data0x0, Data0x1, Data0x2, Data0x3; -input Data1x0, Data1x1, Data1x2, Data1x3; -input Data2x0, Data2x1, Data2x2, Data2x3; -input Data3x0, Data3x1, Data3x2, Data3x3; -input Data4x0, Data4x1, Data4x2, Data4x3; -input Data5x0, Data5x1, Data5x2, Data5x3; -input Data6x0, Data6x1, Data6x2, Data6x3; -input Data7x0, Data7x1, Data7x2, Data7x3; -input Data8x0, Data8x1, Data8x2, Data8x3; -input Data9x0, Data9x1, Data9x2, Data9x3; -input Data10x0, Data10x1, Data10x2, Data10x3; -input Data11x0, Data11x1, Data11x2, Data11x3; -input Data12x0, Data12x1, Data12x2, Data12x3; -input Data13x0, Data13x1, Data13x2, Data13x3; -input Data14x0, Data14x1, Data14x2, Data14x3; -input Data15x0, Data15x1, Data15x2, Data15x3; -assign {Result0, Result1, Result2, Result3} = - {Sel3, Sel2, Sel1, Sel0} == 0 ? { Data0x0, Data0x1, Data0x2, Data0x3 } : - {Sel3, Sel2, Sel1, Sel0} == 1 ? { Data1x0, Data1x1, Data1x2, Data1x3 } : - {Sel3, Sel2, Sel1, Sel0} == 2 ? { Data2x0, Data2x1, Data2x2, Data2x3 } : - {Sel3, Sel2, Sel1, Sel0} == 3 ? { Data3x0, Data3x1, Data3x2, Data3x3 } : - {Sel3, Sel2, Sel1, Sel0} == 4 ? { Data4x0, Data4x1, Data4x2, Data4x3 } : - {Sel3, Sel2, Sel1, Sel0} == 5 ? { Data5x0, Data5x1, Data5x2, Data5x3 } : - {Sel3, Sel2, Sel1, Sel0} == 6 ? { Data6x0, Data6x1, Data6x2, Data6x3 } : - {Sel3, Sel2, Sel1, Sel0} == 7 ? { Data7x0, Data7x1, Data7x2, Data7x3 } : - {Sel3, Sel2, Sel1, Sel0} == 8 ? { Data8x0, Data8x1, Data8x2, Data8x3 } : - {Sel3, Sel2, Sel1, Sel0} == 9 ? { Data9x0, Data9x1, Data9x2, Data9x3 } : - {Sel3, Sel2, Sel1, Sel0} == 10 ? { Data10x0, Data10x1, Data10x2, Data10x3 } : - {Sel3, Sel2, Sel1, Sel0} == 11 ? { Data11x0, Data11x1, Data11x2, Data11x3 } : - {Sel3, Sel2, Sel1, Sel0} == 12 ? { Data12x0, Data12x1, Data12x2, Data12x3 } : - {Sel3, Sel2, Sel1, Sel0} == 13 ? { Data13x0, Data13x1, Data13x2, Data13x3 } : - {Sel3, Sel2, Sel1, Sel0} == 14 ? { Data14x0, Data14x1, Data14x2, Data14x3 } : - {Sel3, Sel2, Sel1, Sel0} == 15 ? { Data15x0, Data15x1, Data15x2, Data15x3 } : 'bx; -endmodule - -module mux1_5_32( - Sel0, Sel1, Sel2, Sel3, Sel4, - Data0x0, Data1x0, Data2x0, Data3x0, Data4x0, Data5x0, Data6x0, Data7x0, Data8x0, Data9x0, Data10x0, Data11x0, Data12x0, Data13x0, Data14x0, Data15x0, - Data16x0, Data17x0, Data18x0, Data19x0, Data20x0, Data21x0, Data22x0, Data23x0, Data24x0, Data25x0, Data26x0, Data27x0, Data28x0, Data29x0, Data30x0, Data31x0, - Result0 -); -input Sel0, Sel1, Sel2, Sel3, Sel4; -input Data0x0, Data1x0, Data2x0, Data3x0, Data4x0, Data5x0, Data6x0, Data7x0, Data8x0, Data9x0, Data10x0, Data11x0, Data12x0, Data13x0, Data14x0, Data15x0; -input Data16x0, Data17x0, Data18x0, Data19x0, Data20x0, Data21x0, Data22x0, Data23x0, Data24x0, Data25x0, Data26x0, Data27x0, Data28x0, Data29x0, Data30x0, Data31x0; -output Result0; -assign Result0 = - {Sel4, Sel3, Sel2, Sel1, Sel0} == 0 ? Data0x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 1 ? Data1x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 2 ? Data2x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 3 ? Data3x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 4 ? Data4x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 5 ? Data5x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 6 ? Data6x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 7 ? Data7x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 8 ? Data8x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 9 ? Data9x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 10 ? Data10x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 11 ? Data11x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 12 ? Data12x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 13 ? Data13x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 14 ? Data14x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 15 ? Data15x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 16 ? Data16x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 17 ? Data17x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 18 ? Data18x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 19 ? Data19x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 20 ? Data20x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 21 ? Data21x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 22 ? Data22x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 23 ? Data23x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 24 ? Data24x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 25 ? Data25x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 26 ? Data26x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 27 ? Data27x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 28 ? Data28x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 29 ? Data29x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 30 ? Data30x0 : - {Sel4, Sel3, Sel2, Sel1, Sel0} == 31 ? Data31x0 : 'bx; -endmodule - diff --git a/manual/CHAPTER_StateOfTheArt/simlib_yosys.v b/manual/CHAPTER_StateOfTheArt/simlib_yosys.v deleted file mode 100644 index ec209fa02..000000000 --- a/manual/CHAPTER_StateOfTheArt/simlib_yosys.v +++ /dev/null @@ -1,166 +0,0 @@ -/* - * yosys -- Yosys Open SYnthesis Suite - * - * Copyright (C) 2012 Claire Xenia Wolf <claire@yosyshq.com> - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - * - * --- - * - * The internal logic cell simulation library. - * - * This Verilog library contains simple simulation models for the internal - * logic cells (_NOT_, _AND_, ...) that are generated by the default technology - * mapper (see "stdcells.v" in this directory) and expected by the "abc" pass. - * - */ - -module _NOT_(A, Y); -input A; -output Y; -assign Y = ~A; -endmodule - -module _AND_(A, B, Y); -input A, B; -output Y; -assign Y = A & B; -endmodule - -module _OR_(A, B, Y); -input A, B; -output Y; -assign Y = A | B; -endmodule - -module _XOR_(A, B, Y); -input A, B; -output Y; -assign Y = A ^ B; -endmodule - -module _MUX_(A, B, S, Y); -input A, B, S; -output reg Y; -always @* begin - if (S) - Y = B; - else - Y = A; -end -endmodule - -module _DFF_N_(D, Q, C); -input D, C; -output reg Q; -always @(negedge C) begin - Q <= D; -end -endmodule - -module _DFF_P_(D, Q, C); -input D, C; -output reg Q; -always @(posedge C) begin - Q <= D; -end -endmodule - -module _DFF_NN0_(D, Q, C, R); -input D, C, R; -output reg Q; -always @(negedge C or negedge R) begin - if (R == 0) - Q <= 0; - else - Q <= D; -end -endmodule - -module _DFF_NN1_(D, Q, C, R); -input D, C, R; -output reg Q; -always @(negedge C or negedge R) begin - if (R == 0) - Q <= 1; - else - Q <= D; -end -endmodule - -module _DFF_NP0_(D, Q, C, R); -input D, C, R; -output reg Q; -always @(negedge C or posedge R) begin - if (R == 1) - Q <= 0; - else - Q <= D; -end -endmodule - -module _DFF_NP1_(D, Q, C, R); -input D, C, R; -output reg Q; -always @(negedge C or posedge R) begin - if (R == 1) - Q <= 1; - else - Q <= D; -end -endmodule - -module _DFF_PN0_(D, Q, C, R); -input D, C, R; -output reg Q; -always @(posedge C or negedge R) begin - if (R == 0) - Q <= 0; - else - Q <= D; -end -endmodule - -module _DFF_PN1_(D, Q, C, R); -input D, C, R; -output reg Q; -always @(posedge C or negedge R) begin - if (R == 0) - Q <= 1; - else - Q <= D; -end -endmodule - -module _DFF_PP0_(D, Q, C, R); -input D, C, R; -output reg Q; -always @(posedge C or posedge R) begin - if (R == 1) - Q <= 0; - else - Q <= D; -end -endmodule - -module _DFF_PP1_(D, Q, C, R); -input D, C, R; -output reg Q; -always @(posedge C or posedge R) begin - if (R == 1) - Q <= 1; - else - Q <= D; -end -endmodule - diff --git a/manual/CHAPTER_StateOfTheArt/sis-1.3.6-buildfixes.patch b/manual/CHAPTER_StateOfTheArt/sis-1.3.6-buildfixes.patch deleted file mode 100644 index ad957d6b8..000000000 --- a/manual/CHAPTER_StateOfTheArt/sis-1.3.6-buildfixes.patch +++ /dev/null @@ -1,113 +0,0 @@ -Some minor build fixes for sis-1.3.6 as it can be downloaded from -http://www-cad.eecs.berkeley.edu/~pchong/sis.html or -http://embedded.eecs.berkeley.edu/Alumni/pchong/sis.html - -diff --git a/sis/io/read_kiss.c b/sis/io/read_kiss.c -index 814e526..c862892 100644 ---- a/sis/io/read_kiss.c -+++ b/sis/io/read_kiss.c -@@ -10,7 +10,6 @@ - #ifdef SIS - #include "sis.h" - --extern void read_error(); - extern int read_lineno; - extern char *read_filename; - -diff --git a/sis/pld/act_bdd.c b/sis/pld/act_bdd.c -index 4fb4415..a5cd74c 100644 ---- a/sis/pld/act_bdd.c -+++ b/sis/pld/act_bdd.c -@@ -141,6 +141,8 @@ char *name; - return p_vertex; - } - -+static int compare(); -+ - /* Or 2 ACT's*/ - act_t * - my_or_act_F(array_b,cover, array) -@@ -148,7 +150,6 @@ array_t *array_b; - array_t *array; - sm_row *cover; - { -- static int compare(); - int i; - act_t *up_vertex, *down_vertex, *vertex; - sm_element *p; -diff --git a/sis/pld/act_ite.c b/sis/pld/act_ite.c -index a35f2fb..7b824df 100644 ---- a/sis/pld/act_ite.c -+++ b/sis/pld/act_ite.c -@@ -125,6 +125,8 @@ node_t *fanin; - and the minimum column cover variables in cover, generates an ite for the - original function. */ - -+static int compare(); -+ - ite_vertex * - my_or_ite_F(array_b, cover, array, network) - array_t *array_b; -@@ -132,7 +134,6 @@ array_t *array; - sm_row *cover; - network_t *network; - { -- static int compare(); - int i; - ite_vertex *vertex; - sm_element *p; -diff --git a/sis/pld/xln_merge.c b/sis/pld/xln_merge.c -index 075e6c5..16f4d61 100644 ---- a/sis/pld/xln_merge.c -+++ b/sis/pld/xln_merge.c -@@ -284,6 +284,7 @@ array_t *match1_array, *match2_array; - - } - -+static sm_row *xln_merge_find_neighbor_of_row1_with_minimum_neighbors(); - - /*---------------------------------------------------------------------------------------------------- - An alternate to lindo option. Uses greedy merging. A node with minimum mergeable nodes is picked -@@ -296,7 +297,6 @@ xln_merge_nodes_without_lindo(coeff, cand_node_array, match1_array, match2_array - { - node_t *n1, *n2; - sm_row *row1, *row2; -- static sm_row *xln_merge_find_neighbor_of_row1_with_minimum_neighbors(); - - while (TRUE) { - row1 = sm_shortest_row(coeff); -diff --git a/sis/pld/xln_part_dec.c b/sis/pld/xln_part_dec.c -index 1c856bd..b78828a 100644 ---- a/sis/pld/xln_part_dec.c -+++ b/sis/pld/xln_part_dec.c -@@ -49,13 +49,14 @@ int size; - - - -+static int kernel_value(); -+ - int - split_node(network, node, size) - network_t *network; - node_t *node; - int size; - { -- static int kernel_value(); - int i, value = 1; - kern_node *sorted; - divisor_t *div, *best_div; -diff --git a/xsis/Makefile.am b/xsis/Makefile.am -index 196d98b..686fdf4 100644 ---- a/xsis/Makefile.am -+++ b/xsis/Makefile.am -@@ -1,8 +1,8 @@ - xsis_SOURCES_local = NetPlot.c NetPlot.h NetPlotP.h main.c xastg.c \ - xblif.c xcmd.c xhelp.c xsis.c xsis.h xutil.c \ - blif50.px ghost.px help50.px sis50.px --AM_CPPFLAGS = -I../sis/include -I@SIS_X_INCLUDES@ --AM_LDFLAGS = -L@SIS_X_LIBRARIES@ -+AM_CPPFLAGS = -I../sis/include -+AM_LDFLAGS = - LDADD = ../sis/libsis.a -lXaw -lXmu -lXt -lXext -lX11 -lm - - if SIS_COND_X diff --git a/manual/CHAPTER_StateOfTheArt/synth.sh b/manual/CHAPTER_StateOfTheArt/synth.sh deleted file mode 100755 index 3a7524a29..000000000 --- a/manual/CHAPTER_StateOfTheArt/synth.sh +++ /dev/null @@ -1,64 +0,0 @@ -#!/bin/bash - -yosys_bin="/usr/local/synthesis/src/yosys/yosys" -hana_bin="/usr/local/synthesis/src/hana/bin/hana" -vl2mv_bin="/usr/local/synthesis/bin/vl2mv" -vis_bin="/usr/local/synthesis/bin/vis" -iverilog_bin="/usr/local/synthesis/bin/iverilog-0.8" -odin_bin="/usr/local/synthesis/src/vtr_release/ODIN_II/odin_II.exe" -abc_bin="/usr/local/synthesis/src/alanmi-abc-b5750272659f/abc" -edif2ngd="/opt/Xilinx/14.3/ISE_DS/ISE/bin/lin64/edif2ngd" -netgen="/opt/Xilinx/14.3/ISE_DS/ISE/bin/lin64/netgen" - -all_modes="yosys hana vis icarus odin" -all_sources="always01 always02 always03 arrays01 forgen01 forgen02" - -if [ "$*" == "ALL" ]; then - for mode in $all_modes; do - for src in $all_sources; do - echo "synth.sh $mode $src.v ${src}_${mode}.v" - ( set -x; bash synth.sh $mode $src.v ${src}_${mode}.v || rm -f ${src}_${mode}.v; ) > ${src}_${mode}.log 2>&1 - done - done - exit -fi - -mode="$1" -source="$2" -output="$3" -prefix="${output%.v}" - -help() { - echo "$0 ALL" >&2 - echo "$0 {yosys|hana|vis|icarus|odin} <source-file> <output-file>" >&2 - exit 1 -} - -if [ "$#" != 3 -o ! -f "$source" ]; then - help -fi - -set -ex - -case "$mode" in - yosys) - $yosys_bin -o $output -b "verilog -noattr" -p proc -p opt -p memory -p opt -p techmap -p opt $source ;; - hana) - $hana_bin -s $output $source ;; - vis) - $vl2mv_bin -o $prefix.mv $source - { echo "read_blif_mv $prefix.mv"; echo "write_verilog $output"; } | $abc_bin ;; - icarus) - rm -f $prefix.ngo $prefix.v - $iverilog_bin -t fpga -o $prefix.edif $source - $edif2ngd $prefix.edif $prefix.ngo - $netgen -ofmt verilog $prefix.ngo $prefix.v - sed -re '/timescale/ s,^,//,;' -i $prefix.v ;; - odin) - $odin_bin -o $prefix.blif -V $source - sed -re 's,top\^,,g; s,clock,_clock,g;' -i $prefix.blif - { echo "read_blif $prefix.blif"; echo "write_verilog $output"; } | $abc_bin ;; - *) - help -esac - diff --git a/manual/CHAPTER_StateOfTheArt/validate_tb.sh b/manual/CHAPTER_StateOfTheArt/validate_tb.sh deleted file mode 100755 index b6409eb14..000000000 --- a/manual/CHAPTER_StateOfTheArt/validate_tb.sh +++ /dev/null @@ -1,55 +0,0 @@ -#!/bin/bash - -set -ex - -yosys_bin="/usr/local/synthesis/src/yosys/yosys" -iverilog_bin="iverilog" - -all_modes="yosys hana vis icarus odin" -all_sources="always01 always02 always03 arrays01 forgen01 forgen02" - -gcc -o cmp_tbdata cmp_tbdata.c - -for src in $all_sources; do - echo; echo - $yosys_bin -o ${src}_tb.v -b autotest ${src}.v - $iverilog_bin -o ${src}_tb ${src}_tb.v ${src}.v - ./${src}_tb > ${src}_tb.out - for mode in $all_modes; do - simlib="" - [ -f ${src}_${mode}.v ] || continue - [ -f simlib_${mode}.v ] && simlib="simlib_${mode}.v" - if $iverilog_bin -o ${src}_${mode}_tb -s testbench ${src}_tb.v ${src}_${mode}.v $simlib; then - ./${src}_${mode}_tb > ${src}_${mode}_tb.out - else - rm -f ${src}_${mode}_tb.out - fi - done -done - -set +x -echo; echo; echo - -{ - for mode in $all_modes; do - echo -en "\t$mode" - done; echo - - for src in $all_sources; do - echo -n "$src" - for mode in $all_modes; do - if [ -f ${src}_${mode}.v ]; then - if [ ! -s ${src}_${mode}_tb.out ]; then - echo -en "\tmissing" - elif ./cmp_tbdata ${src}_tb.out ${src}_${mode}_tb.out; then - echo -en "\tok" - else - echo -en "\tfailed" - fi - else - echo -en "\terror" - fi - done; echo - done -} | expand -t12 - diff --git a/manual/CHAPTER_Techmap.tex b/manual/CHAPTER_Techmap.tex deleted file mode 100644 index 13aa8e5a3..000000000 --- a/manual/CHAPTER_Techmap.tex +++ /dev/null @@ -1,102 +0,0 @@ - -\chapter{Technology Mapping} -\label{chapter:techmap} - -Previous chapters outlined how HDL code is transformed into an RTL netlist. The -RTL netlist is still based on abstract coarse-grain cell types like arbitrary -width adders and even multipliers. This chapter covers how an RTL netlist is -transformed into a functionally equivalent netlist utilizing the cell types -available in the target architecture. - -Technology mapping is often performed in two phases. In the first phase RTL cells -are mapped to an internal library of single-bit cells (see Sec.~\ref{sec:celllib_gates}). -In the second phase this netlist of internal gate types is transformed to a netlist -of gates from the target technology library. - -When the target architecture provides coarse-grain cells (such as block ram -or ALUs), these must be mapped to directly form the RTL netlist, as information -on the coarse-grain structure of the design is lost when it is mapped to -bit-width gate types. - -\section{Cell Substitution} - -The simplest form of technology mapping is cell substitution, as performed by -the {\tt techmap} pass. This pass, when provided with a Verilog file that -implements the RTL cell types using simpler cells, simply replaces the RTL -cells with the provided implementation. - -When no map file is provided, {\tt techmap} uses a built-in map file that -maps the Yosys RTL cell types to the internal gate library used by Yosys. -The curious reader may find this map file as {\tt techlibs/common/techmap.v} in -the Yosys source tree. - -Additional features have been added to {\tt techmap} to allow for conditional -mapping of cells (see {\tt help techmap} or Sec.~\ref{cmd:techmap}). This can -for example be useful if the target architecture supports hardware multipliers for -certain bit-widths but not for others. - -A usual synthesis flow would first use the {\tt techmap} pass to directly map -some RTL cells to coarse-grain cells provided by the target architecture (if -any) and then use techmap with the built-in default file to map the remaining -RTL cells to gate logic. - -\section{Subcircuit Substitution} - -Sometimes the target architecture provides cells that are more powerful than -the RTL cells used by Yosys. For example a cell in the target architecture that can -calculate the absolute-difference of two numbers does not match any single -RTL cell type but only combinations of cells. - -For these cases Yosys provides the {\tt extract} pass that can match a given set -of modules against a design and identify the portions of the design that are -identical (i.e.~isomorphic subcircuits) to any of the given modules. These -matched subcircuits are then replaced by instances of the given modules. - -The {\tt extract} pass also finds basic variations of the given modules, -such as swapped inputs on commutative cell types. - -In addition to this the {\tt extract} pass also has limited support for -frequent subcircuit mining, i.e.~the process of finding recurring subcircuits -in the design. This has a few applications, including the design of new -coarse-grain architectures \cite{intersynthFdlBookChapter}. - -The hard algorithmic work done by the {\tt extract} pass (solving the -isomorphic subcircuit problem and frequent subcircuit mining) is performed -using the SubCircuit library that can also be used stand-alone without Yosys -(see Sec.~\ref{sec:SubCircuit}). - -\section{Gate-Level Technology Mapping} -\label{sec:techmap_extern} - -On the gate-level the target architecture is usually described by a ``Liberty -file''. The Liberty file format is an industry standard format that can be -used to describe the behaviour and other properties of standard library cells -\citeweblink{LibertyFormat}. - -Mapping a design utilizing the Yosys internal gate library (e.g.~as a result -of mapping it to this representation using the {\tt techmap} pass) is -performed in two phases. - -First the register cells must be mapped to the registers that are available -on the target architectures. The target architecture might not provide all -variations of d-type flip-flops with positive and negative clock edge, -high-active and low-active asynchronous set and/or reset, etc. Therefore the -process of mapping the registers might add additional inverters to the design -and thus it is important to map the register cells first. - -Mapping of the register cells may be performed by using the {\tt dfflibmap} -pass. This pass expects a Liberty file as argument (using the {\tt -liberty} -option) and only uses the register cells from the Liberty file. - -Secondly the combinational logic must be mapped to the target architecture. -This is done using the external program ABC \citeweblink{ABC} via the -{\tt abc} pass by using the {\tt -liberty} option to the pass. Note that -in this case only the combinatorial cells are used from the cell library. - -Occasionally Liberty files contain trade secrets (such as sensitive timing -information) that cannot be shared freely. This complicates processes such as -reporting bugs in the tools involved. When the information in the Liberty file -used by Yosys and ABC are not part of the sensitive information, the additional -tool {\tt yosys-filterlib} (see Sec.~\ref{sec:filterlib}) can be used to strip -the sensitive information from the Liberty file. - diff --git a/manual/CHAPTER_TextRtlil.tex b/manual/CHAPTER_TextRtlil.tex deleted file mode 100644 index 67eade8bf..000000000 --- a/manual/CHAPTER_TextRtlil.tex +++ /dev/null @@ -1,299 +0,0 @@ -\chapter{RTLIL Text Representation} -\label{chapter:textrtlil} - -% Stolen from stackexchange: calculate indent based on given keyword, -% with some nice hrules added in. -\newlength{\myl} - -\newenvironment{indentgrammar}[1] - {\vspace{0.5cm}\hrule - \setlength{\myl}{\widthof{#1}+2em} - \grammarindent\the\myl - \begin{grammar}} - {\end{grammar} - \hrule} - -This appendix documents the text representation of RTLIL in extended Backus-Naur form (EBNF). - -The grammar is not meant to represent semantic limitations. That is, the grammar is ``permissive'', and later stages of processing perform more rigorous checks. - -The grammar is also not meant to represent the exact grammar used in the RTLIL frontend, since that grammar is specific to processing by lex and yacc, is even more permissive, and is somewhat less understandable than simple EBNF notation. - -Finally, note that all statements (rules ending in \texttt{-stmt}) terminate in an end-of-line. Because of this, a statement cannot be broken into multiple lines. - -\section{Lexical elements} - -\subsection{Characters} - -An RTLIL file is a stream of bytes. Strictly speaking, a ``character'' in an RTLIL file is a single byte. The lexer treats multi-byte encoded characters as consecutive single-byte characters. While other encodings \textit{may} work, UTF-8 is known to be safe to use. Byte order marks at the beginning of the file will cause an error. - -ASCII spaces (32) and tabs (9) separate lexer tokens. - -A \texttt{nonws} character, used in identifiers, is any character whose encoding consists solely of bytes above ASCII space (32). - -An \texttt{eol} is one or more consecutive ASCII newlines (10) and carriage returns (13). - -\subsection{Identifiers} - -There are two types of identifiers in RTLIL: - -\begin{itemize} - \item Publically visible identifiers - \item Auto-generated identifiers -\end{itemize} - -\begin{indentgrammar}{<autogen-id>} -<id> ::= <public-id> | <autogen-id> - -<public-id> ::= "\textbackslash" <nonws>$+$ - -<autogen-id> ::= "\textdollar" <nonws>$+$ -\end{indentgrammar} - -\subsection{Values} - -A \textit{value} consists of a width in bits and a bit representation, most significant bit first. Bits may be any of: -\begin{itemize} - \item \texttt{0}: A logic zero value - \item \texttt{1}: A logic one value - \item \texttt{x}: An unknown logic value (or don't care in case patterns) - \item \texttt{z}: A high-impedance value (or don't care in case patterns) - \item \texttt{m}: A marked bit (internal use only) - \item \texttt{-}: A don't care value -\end{itemize} - -An \textit{integer} is simply a signed integer value in decimal format. \textbf{Warning:} Integer constants are limited to 32 bits. That is, they may only be in the range $[-2147483648, 2147483648)$. Integers outside this range will result in an error. - -\begin{indentgrammar}{<binary-digit>} -<value> ::= <decimal-digit>$+$ \texttt{\textbf{'}} <binary-digit>$*$ - -<decimal-digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" - -<binary-digit> ::= "0" | "1" | "x" | "z" | "m" | "-" - -<integer> ::= "-"$?$ <decimal-digit>$+$ -\end{indentgrammar} - -\subsection{Strings} - -A string is a series of characters delimited by double-quote characters. Within a string, any character except ASCII NUL (0) may be used. In addition, certain escapes can be used: - -\begin{itemize} - \item \texttt{\textbackslash n}: A newline - \item \texttt{\textbackslash t}: A tab - \item \texttt{\textbackslash \textit{ooo}}: A character specified as a one, two, or three digit octal value -\end{itemize} - -All other characters may be escaped by a backslash, and become the following character. Thus: - -\begin{itemize} - \item \texttt{\textbackslash \textbackslash}: A backslash - \item \texttt{\textbackslash ''}: A double-quote - \item \texttt{\textbackslash r}: An 'r' character -\end{itemize} - -\subsection{Comments} - -A comment starts with a \texttt{\textbf{\#}} character and proceeds to the end of the line. All comments are ignored. - -\section{File} - -A file consists of an optional autoindex statement followed by zero or more modules. - -\begin{indentgrammar}{<design>} -<file> ::= <autoidx-stmt>$?$ <module>* -\end{indentgrammar} - -\subsection{Autoindex statements} - -The autoindex statement sets the global autoindex value used by Yosys when it needs to generate a unique name, e.g. \texttt{\textdollar{}flatten\textdollar{}N}. The N part is filled with the value of the global autoindex value, which is subsequently incremented. This global has to be dumped into RTLIL, otherwise e.g. dumping and running a pass would have different properties than just running a pass on a warm design. - -\begin{indentgrammar}{<autoidx-stmt>} -<autoidx-stmt> ::= "autoidx" <integer> <eol> -\end{indentgrammar} - -\subsection{Modules} - -Declares a module, with zero or more attributes, consisting of zero or more wires, memories, cells, processes, and connections. - -\begin{indentgrammar}{<module-body-stmt>} -<module> ::= <attr-stmt>$*$ <module-stmt> <module-body> <module-end-stmt> - -<module-stmt> ::= "module" <id> <eol> - -<module-body> ::= -(<param-stmt> - \alt <wire> - \alt <memory> - \alt <cell> - \alt <process> - \alt <conn-stmt>)$*$ - -<param-stmt> ::= "parameter" <id> <constant>$?$ <eol> - -<constant> ::= <value> | <integer> | <string> - -<module-end-stmt> ::= "end" <eol> -\end{indentgrammar} - -\subsection{Attribute statements} - -Declares an attribute with the given identifier and value. - -\begin{indentgrammar}{<attr-stmt>} -<attr-stmt> ::= "attribute" <id> <constant> <eol> -\end{indentgrammar} - -\subsection{Signal specifications} - -A signal is anything that can be applied to a cell port, i.e. a constant value, all bits or a selection of bits from a wire, or concatenations of those. - -\textbf{Warning:} When an integer constant is a sigspec, it is always 32 bits wide, 2's complement. For example, a constant of $-1$ is the same as \texttt{32'11111111111111111111111111111111}, while a constant of $1$ is the same as \texttt{32'1}. - -See Sec.~\ref{sec:rtlil_sigspec} for an overview of signal specifications. - -\begin{indentgrammar}{<sigspec>} -<sigspec> ::= -<constant> - \alt <wire-id> - \alt <sigspec> "[" <integer> (":" <integer>)$?$ "]" - \alt "\{" <sigspec>$*$ "\}" -\end{indentgrammar} - -\subsection{Connections} - -Declares a connection between the given signals. - -\begin{indentgrammar}{<conn-stmt>} -<conn-stmt> ::= "connect" <sigspec> <sigspec> <eol> -\end{indentgrammar} - -\subsection{Wires} - -Declares a wire, with zero or more attributes, with the given identifier and options in the enclosing module. - -See Sec.~\ref{sec:rtlil_cell_wire} for an overview of wires. - -\begin{indentgrammar}{<wire-option>} -<wire> ::= <attr-stmt>$*$ <wire-stmt> - -<wire-stmt> ::= "wire" <wire-option>$*$ <wire-id> <eol> - -<wire-id> ::= <id> - -<wire-option> ::= -"width" <integer> - \alt "offset" <integer> - \alt "input" <integer> - \alt "output" <integer> - \alt "inout" <integer> - \alt "upto" - \alt "signed" -\end{indentgrammar} - -\subsection{Memories} - -Declares a memory, with zero or more attributes, with the given identifier and options in the enclosing module. - -See Sec.~\ref{sec:rtlil_memory} for an overview of memory cells, and Sec.~\ref{sec:memcells} for details about memory cell types. - -\begin{indentgrammar}{<memory-option>} -<memory> ::= <attr-stmt>$*$ <memory-stmt> - -<memory-stmt> ::= "memory" <memory-option>$*$ <id> <eol> - -<memory-option> ::= -"width" <integer> - \alt "size" <integer> - \alt "offset" <integer> -\end{indentgrammar} - -\subsection{Cells} - -Declares a cell, with zero or more attributes, with the given identifier and type in the enclosing module. - -Cells perform functions on input signals. See Chap.~\ref{chapter:celllib} for a detailed list of cell types. - -\begin{indentgrammar}{<cell-body-stmt>} -<cell> ::= <attr-stmt>$*$ <cell-stmt> <cell-body-stmt>$*$ <cell-end-stmt> - -<cell-stmt> ::= "cell" <cell-type> <cell-id> <eol> - -<cell-id> ::= <id> - -<cell-type> ::= <id> - -<cell-body-stmt> ::= -"parameter" ("signed" | "real")$?$ <id> <constant> <eol> - \alt "connect" <id> <sigspec> <eol> - -<cell-end-stmt> ::= "end" <eol> -\end{indentgrammar} - -\subsection{Processes} - -Declares a process, with zero or more attributes, with the given identifier in the enclosing module. The body of a process consists of zero or more assignments, exactly one switch, and zero or more syncs. - -See Sec.~\ref{sec:rtlil_process} for an overview of processes. - -\begin{indentgrammar}{<switch-end-stmt>} -<process> ::= <attr-stmt>$*$ <proc-stmt> <process-body> <proc-end-stmt> - -<proc-stmt> ::= "process" <id> <eol> - -<process-body> ::= <assign-stmt>$*$ <switch>$?$ <assign-stmt>$*$ <sync>$*$ - -<assign-stmt> ::= "assign" <dest-sigspec> <src-sigspec> <eol> - -<dest-sigspec> ::= <sigspec> - -<src-sigspec> ::= <sigspec> - -<proc-end-stmt> ::= "end" <eol> - -\end{indentgrammar} - -\subsection{Switches} - -Switches test a signal for equality against a list of cases. Each case specifies a comma-separated list of signals to check against. If there are no signals in the list, then the case is the default case. The body of a case consists of zero or more switches and assignments. Both switches and cases may have zero or more attributes. - -\begin{indentgrammar}{<switch-end-stmt>} -<switch> ::= <switch-stmt> <case>$*$ <switch-end-stmt> - -<switch-stmt> := <attr-stmt>$*$ "switch" <sigspec> <eol> - -<case> ::= <attr-stmt>$*$ <case-stmt> <case-body> - -<case-stmt> ::= "case" <compare>$?$ <eol> - -<compare> ::= <sigspec> ("," <sigspec>)$*$ - -<case-body> ::= (<switch> | <assign-stmt>)$*$ - -<switch-end-stmt> ::= "end" <eol> -\end{indentgrammar} - -\subsection{Syncs} - -Syncs update signals with other signals when an event happens. Such an event may be: - -\begin{itemize} - \item An edge or level on a signal - \item Global clock ticks - \item Initialization - \item Always -\end{itemize} - -\begin{indentgrammar}{<dest-sigspec>} -<sync> ::= <sync-stmt> <update-stmt>$*$ - -<sync-stmt> ::= -"sync" <sync-type> <sigspec> <eol> - \alt "sync" "global" <eol> - \alt "sync" "init" <eol> - \alt "sync" "always" <eol> - -<sync-type> ::= "low" | "high" | "posedge" | "negedge" | "edge" - -<update-stmt> ::= "update" <dest-sigspec> <src-sigspec> <eol> -\end{indentgrammar} diff --git a/manual/CHAPTER_Verilog.tex b/manual/CHAPTER_Verilog.tex deleted file mode 100644 index c1ecc0397..000000000 --- a/manual/CHAPTER_Verilog.tex +++ /dev/null @@ -1,854 +0,0 @@ - -\chapter{The Verilog and AST Frontends} -\label{chapter:verilog} - -This chapter provides an overview of the implementation of the Yosys Verilog -and AST frontends. The Verilog frontend reads Verilog-2005 code and creates -an abstract syntax tree (AST) representation of the input. This AST representation -is then passed to the AST frontend that converts it to RTLIL data, as illustrated -in Fig.~\ref{fig:Verilog_flow}. - -\begin{figure}[b!] - \hfil - \begin{tikzpicture} - \tikzstyle{process} = [draw, fill=green!10, rectangle, minimum height=3em, minimum width=10em, node distance=5em, font={\ttfamily}] - \tikzstyle{data} = [draw, fill=blue!10, ellipse, minimum height=3em, minimum width=7em, node distance=5em, font={\ttfamily}] - - \node[data] (n1) {Verilog Source}; - \node[process] (n2) [below of=n1] {Verilog Frontend}; - \node[data] (n3) [below of=n2] {AST}; - \node[process] (n4) [below of=n3] {AST Frontend}; - \node[data] (n5) [below of=n4] {RTLIL}; - - \draw[-latex] (n1) -- (n2); - \draw[-latex] (n2) -- (n3); - \draw[-latex] (n3) -- (n4); - \draw[-latex] (n4) -- (n5); - - \tikzstyle{details} = [draw, fill=yellow!5, rectangle, node distance=6cm, font={\ttfamily}] - - \node[details] (d1) [right of=n2] {\begin{minipage}{5cm} - \hfil - \begin{tikzpicture} - \tikzstyle{subproc} = [draw, fill=green!10, rectangle, minimum height=2em, minimum width=10em, node distance=3em, font={\ttfamily}] - \node (s0) {}; - \node[subproc] (s1) [below of=s0] {Preprocessor}; - \node[subproc] (s2) [below of=s1] {Lexer}; - \node[subproc] (s3) [below of=s2] {Parser}; - \node[node distance=3em] (s4) [below of=s3] {}; - \draw[-latex] (s0) -- (s1); - \draw[-latex] (s1) -- (s2); - \draw[-latex] (s2) -- (s3); - \draw[-latex] (s3) -- (s4); - \end{tikzpicture} - \end{minipage}}; - - \draw[dashed] (n2.north east) -- (d1.north west); - \draw[dashed] (n2.south east) -- (d1.south west); - - \node[details] (d2) [right of=n4] {\begin{minipage}{5cm} - \hfil - \begin{tikzpicture} - \tikzstyle{subproc} = [draw, fill=green!10, rectangle, minimum height=2em, minimum width=10em, node distance=3em, font={\ttfamily}] - \node (s0) {}; - \node[subproc] (s1) [below of=s0] {Simplifier}; - \node[subproc] (s2) [below of=s1] {RTLIL Generator}; - \node[node distance=3em] (s3) [below of=s2] {}; - \draw[-latex] (s0) -- (s1); - \draw[-latex] (s1) -- (s2); - \draw[-latex] (s2) -- (s3); - \end{tikzpicture} - \end{minipage}}; - - \draw[dashed] (n4.north east) -- (d2.north west); - \draw[dashed] (n4.south east) -- (d2.south west); - - \end{tikzpicture} - \caption{Simplified Verilog to RTLIL data flow} - \label{fig:Verilog_flow} -\end{figure} - - -\section{Transforming Verilog to AST} - -The {\it Verilog frontend} converts the Verilog sources to an internal AST representation that closely resembles -the structure of the original Verilog code. The Verilog frontend consists of three components, the -{\it Preprocessor}, the {\it Lexer} and the {\it Parser}. - -The source code to the Verilog frontend can be found in {\tt frontends/verilog/} in the Yosys source tree. - -\subsection{The Verilog Preprocessor} - -The Verilog preprocessor scans over the Verilog source code and interprets some of the Verilog compiler -directives such as \lstinline[language=Verilog]{`include}, \lstinline[language=Verilog]{`define} and -\lstinline[language=Verilog]{`ifdef}. - -It is implemented as a C++ function that is passed a file descriptor as input and returns the -pre-processed Verilog code as a \lstinline[language=C++]{std::string}. - -The source code to the Verilog Preprocessor can be found in {\tt -frontends/verilog/preproc.cc} in the Yosys source tree. - -\subsection{The Verilog Lexer} - -\begin{sloppypar} -The Verilog Lexer is written using the lexer generator {\it flex} \citeweblink{flex}. Its source code -can be found in {\tt frontends/verilog/verilog\_lexer.l} in the Yosys source tree. -The lexer does little more than identifying all keywords and literals -recognised by the Yosys Verilog frontend. -\end{sloppypar} - -The lexer keeps track of the current location in the Verilog source code using -some global variables. These variables are used by the constructor of AST nodes -to annotate each node with the source code location it originated from. - -\begin{sloppypar} -Finally the lexer identifies and handles special comments such as -``\lstinline[language=Verilog]{// synopsys translate_off}'' and -``\lstinline[language=Verilog]{// synopsys full_case}''. (It is recommended to -use \lstinline[language=Verilog]{`ifdef} constructs instead of the Synsopsys -translate\_on/off comments and attributes such as -\lstinline[language=Verilog]{(* full_case *)} over ``\lstinline[language=Verilog]{// synopsys full_case}'' -whenever possible.) -\end{sloppypar} - -\subsection{The Verilog Parser} - -The Verilog Parser is written using the parser generator {\it bison} \citeweblink{bison}. Its source code -can be found in {\tt frontends/verilog/verilog\_parser.y} in the Yosys source tree. - -It generates an AST using the \lstinline[language=C++]{AST::AstNode} data structure -defined in {\tt frontends/ast/ast.h}. An \lstinline[language=C++]{AST::AstNode} object has -the following properties: - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -\begin{table}[b!] -\hfil -\begin{tabular}{>{\raggedright\arraybackslash}p{7cm}>{\raggedright\arraybackslash}p{8cm}} -AST Node Type & Corresponding Verilog Construct \\ -\hline -\hline -\arrayrulecolor{gray} -{\tt AST\_NONE} & This Node type should never be used. \\ -\hline -% -{\tt AST\_DESIGN} & This node type is used for the top node of the AST tree. It -has no corresponding Verilog construct. \\ -\hline -% -{\tt AST\_MODULE}, -{\tt AST\_TASK}, -{\tt AST\_FUNCTION} & -\lstinline[language=Verilog];module;, -\lstinline[language=Verilog];task; and -\lstinline[language=Verilog];function; \\ -\hline -% -{\tt AST\_WIRE} & -\lstinline[language=Verilog];input;, -\lstinline[language=Verilog];output;, -\lstinline[language=Verilog];wire;, -\lstinline[language=Verilog];reg; and -\lstinline[language=Verilog];integer; \\ -\hline -% -{\tt AST\_MEMORY} & -Verilog Arrays \\ -\hline -% -{\tt AST\_AUTOWIRE} & -Created by the simplifier when an undeclared signal name is used. \\ -\hline -% -{\tt AST\_PARAMETER}, -{\tt AST\_LOCALPARAM} & -\lstinline[language=Verilog];parameter; and -\lstinline[language=Verilog];localparam; \\ -\hline -% -{\tt AST\_PARASET} & -Parameter set in cell instantiation \\ -\hline -% -{\tt AST\_ARGUMENT} & -Port connection in cell instantiation \\ -\hline -% -{\tt AST\_RANGE} & -Bit-Index in a signal or element index in array \\ -\hline -% -{\tt AST\_CONSTANT} & -A literal value \\ -\hline -% -{\tt AST\_CELLTYPE} & -The type of cell in cell instantiation \\ -\hline -% -{\tt AST\_IDENTIFIER} & -An Identifier (signal name in expression or cell/task/etc. name in other contexts) \\ -\hline -% -{\tt AST\_PREFIX} & -Construct an identifier in the form {\tt <prefix>[<index>].<suffix>} (used only in -advanced generate constructs) \\ -\hline -% -{\tt AST\_FCALL}, -{\tt AST\_TCALL} & -Call to function or task \\ -\hline -% -{\tt AST\_TO\_SIGNED}, -{\tt AST\_TO\_UNSIGNED} & -The \lstinline[language=Verilog];$signed(); and -\lstinline[language=Verilog];$unsigned(); functions \\ -\hline -\end{tabular} -\caption{AST node types with their corresponding Verilog constructs. \\ (continued on next page)} -\label{tab:Verilog_AstNodeType} -\end{table} - -\begin{table}[t!] -\ContinuedFloat -\hfil -\begin{tabular}{>{\raggedright\arraybackslash}p{7cm}>{\raggedright\arraybackslash}p{8cm}} -AST Node Type & Corresponding Verilog Construct \\ -\hline -\hline -\arrayrulecolor{gray} -{\tt AST\_CONCAT} -{\tt AST\_REPLICATE} & -The \lstinline[language=Verilog];{...}; and -\lstinline[language=Verilog];{...{...}}; operators \\ -\hline -% -{\tt AST\_BIT\_NOT}, -{\tt AST\_BIT\_AND}, -{\tt AST\_BIT\_OR}, -{\tt AST\_BIT\_XOR}, -{\tt AST\_BIT\_XNOR} & -The bitwise operators \break -\lstinline[language=Verilog];~;, -\lstinline[language=Verilog];&;, -\lstinline[language=Verilog];|;, -\lstinline[language=Verilog];^; and -\lstinline[language=Verilog];~^; \\ -\hline -% -{\tt AST\_REDUCE\_AND}, -{\tt AST\_REDUCE\_OR}, -{\tt AST\_REDUCE\_XOR}, -{\tt AST\_REDUCE\_XNOR} & -The unary reduction operators \break -\lstinline[language=Verilog];~;, -\lstinline[language=Verilog];&;, -\lstinline[language=Verilog];|;, -\lstinline[language=Verilog];^; and -\lstinline[language=Verilog];~^; \\ -\hline -% -{\tt AST\_REDUCE\_BOOL} & -Conversion from multi-bit value to boolean value -(equivalent to {\tt AST\_REDUCE\_OR}) \\ -\hline -% -{\tt AST\_SHIFT\_LEFT}, -{\tt AST\_SHIFT\_RIGHT}, -{\tt AST\_SHIFT\_SLEFT}, -{\tt AST\_SHIFT\_SRIGHT} & -The shift operators \break -\lstinline[language=Verilog];<<;, -\lstinline[language=Verilog];>>;, -\lstinline[language=Verilog];<<<; and -\lstinline[language=Verilog];>>>; \\ -\hline -% -{\tt AST\_LT}, -{\tt AST\_LE}, -{\tt AST\_EQ}, -{\tt AST\_NE}, -{\tt AST\_GE}, -{\tt AST\_GT} & -The relational operators \break -\lstinline[language=Verilog];<;, -\lstinline[language=Verilog];<=;, -\lstinline[language=Verilog];==;, -\lstinline[language=Verilog];!=;, -\lstinline[language=Verilog];>=; and -\lstinline[language=Verilog];>; \\ -\hline -% -{\tt AST\_ADD}, -{\tt AST\_SUB}, -{\tt AST\_MUL}, -{\tt AST\_DIV}, -{\tt AST\_MOD}, -{\tt AST\_POW} & -The binary operators \break -\lstinline[language=Verilog];+;, -\lstinline[language=Verilog];-;, -\lstinline[language=Verilog];*;, -\lstinline[language=Verilog];/;, -\lstinline[language=Verilog];%; and -\lstinline[language=Verilog];**; \\ -\hline -% -{\tt AST\_POS}, -{\tt AST\_NEG} & -The prefix operators -\lstinline[language=Verilog];+; and -\lstinline[language=Verilog];-; \\ -\hline -% -{\tt AST\_LOGIC\_AND}, -{\tt AST\_LOGIC\_OR}, -{\tt AST\_LOGIC\_NOT} & -The logic operators -\lstinline[language=Verilog];&&;, -\lstinline[language=Verilog];||; and -\lstinline[language=Verilog];!; \\ -\hline -% -{\tt AST\_TERNARY} & -The ternary \lstinline[language=Verilog];?:;-operator \\ -\hline -% -{\tt AST\_MEMRD} -{\tt AST\_MEMWR} & -Read and write memories. These nodes are generated by -the AST simplifier for writes/reads to/from Verilog arrays. \\ -\hline -% -{\tt AST\_ASSIGN} & -An \lstinline[language=Verilog];assign; statement \\ -\hline -% -{\tt AST\_CELL} & -A cell instantiation \\ -\hline -% -{\tt AST\_PRIMITIVE} & -A primitive cell (\lstinline[language=Verilog];and;, -\lstinline[language=Verilog];nand;, -\lstinline[language=Verilog];or;, etc.) \\ -\hline -% -{\tt AST\_ALWAYS}, -{\tt AST\_INITIAL} & -Verilog \lstinline[language=Verilog];always;- and \lstinline[language=Verilog];initial;-blocks \\ -\hline -% -{\tt AST\_BLOCK} & -A \lstinline[language=Verilog];begin;-\lstinline[language=Verilog];end;-block \\ -\hline -% -{\tt AST\_ASSIGN\_EQ}. -{\tt AST\_ASSIGN\_LE} & -Blocking (\lstinline[language=Verilog];=;) and nonblocking (\lstinline[language=Verilog];<=;) -assignments within an \lstinline[language=Verilog];always;- or \lstinline[language=Verilog];initial;-block \\ -\hline -% -{\tt AST\_CASE}. -{\tt AST\_COND}, -{\tt AST\_DEFAULT} & -The \lstinline[language=Verilog];case; (\lstinline[language=Verilog];if;) statements, conditions within a case -and the default case respectively \\ -\hline -% -{\tt AST\_FOR} & -A \lstinline[language=Verilog];for;-loop with an -\lstinline[language=Verilog];always;- or -\lstinline[language=Verilog];initial;-block \\ -\hline -% -{\tt AST\_GENVAR}, -{\tt AST\_GENBLOCK}, -{\tt AST\_GENFOR}, -{\tt AST\_GENIF} & -The \lstinline[language=Verilog];genvar; and -\lstinline[language=Verilog];generate; keywords and -\lstinline[language=Verilog];for; and \lstinline[language=Verilog];if; within a -generate block. \\ -\hline -% -{\tt AST\_POSEDGE}, -{\tt AST\_NEGEDGE}, -{\tt AST\_EDGE} & -Event conditions for \lstinline[language=Verilog];always; blocks. \\ -\hline -\end{tabular} -\caption{AST node types with their corresponding Verilog constructs. \\ (continuation from previous page)} -\label{tab:Verilog_AstNodeTypeCont} -\end{table} - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -\begin{itemize} -\item {\bf The node type} \\ -This enum (\lstinline[language=C++]{AST::AstNodeType}) specifies the role of the node. -Table~\ref{tab:Verilog_AstNodeType} contains a list of all node types. -\item {\bf The child nodes} \\ -This is a list of pointers to all children in the abstract syntax tree. -\item {\bf Attributes} \\ -As almost every AST node might have Verilog attributes assigned to it, the -\lstinline[language=C++]{AST::AstNode} has direct support for attributes. Note that the -attribute values are again AST nodes. -\item {\bf Node content} \\ -Each node might have additional content data. A series of member variables exist to hold such data. -For example the member \lstinline[language=C++]{std::string str} can hold a string value and is -used e.g.~in the {\tt AST\_IDENTIFIER} node type to store the identifier name. -\item {\bf Source code location} \\ -Each \lstinline[language=C++]{AST::AstNode} is automatically annotated with the current -source code location by the \lstinline[language=C++]{AST::AstNode} constructor. It is -stored in the \lstinline[language=C++]{std::string filename} and \lstinline[language=C++]{int linenum} -member variables. -\end{itemize} - -The \lstinline[language=C++]{AST::AstNode} constructor can be called with up to -two child nodes that are automatically added to the list of child nodes for the new object. -This simplifies the creation of AST nodes for simple expressions a bit. For example the bison -code for parsing multiplications: - -\begin{lstlisting}[numbers=left,frame=single] - basic_expr '*' attr basic_expr { - $$ = new AstNode(AST_MUL, $1, $4); - append_attr($$, $3); - } | -\end{lstlisting} - -The generated AST data structure is then passed directly to the AST frontend -that performs the actual conversion to RTLIL. - -Note that the Yosys command {\tt read\_verilog} provides the options {\tt -yydebug} -and {\tt -dump\_ast} that can be used to print the parse tree or abstract syntax tree -respectively. - -\section{Transforming AST to RTLIL} - -The {\it AST Frontend} converts a set of modules in AST representation to -modules in RTLIL representation and adds them to the current design. This is done -in two steps: {\it simplification} and {\it RTLIL generation}. - -The source code to the AST frontend can be found in {\tt frontends/ast/} in the Yosys source tree. - -\subsection{AST Simplification} - -A full-featured AST is too complex to be transformed into RTLIL directly. Therefore it must -first be brought into a simpler form. This is done by calling the \lstinline[language=C++]{AST::AstNode::simplify()} -method of all {\tt AST\_MODULE} nodes in the AST. This initiates a recursive process that performs the following transformations -on the AST data structure: - -\begin{itemize} -\item Inline all task and function calls. -\item Evaluate all \lstinline[language=Verilog]{generate}-statements and unroll all \lstinline[language=Verilog]{for}-loops. -\item Perform const folding where it is necessary (e.g.~in the value part of {\tt AST\_PARAMETER}, {\tt AST\_LOCALPARAM}, -{\tt AST\_PARASET} and {\tt AST\_RANGE} nodes). -\item Replace {\tt AST\_PRIMITIVE} nodes with appropriate {\tt AST\_ASSIGN} nodes. -\item Replace dynamic bit ranges in the left-hand-side of assignments with {\tt AST\_CASE} nodes with {\tt AST\_COND} children -for each possible case. -\item Detect array access patterns that are too complicated for the {\tt RTLIL::Memory} abstraction and replace them -with a set of signals and cases for all reads and/or writes. -\item Otherwise replace array accesses with {\tt AST\_MEMRD} and {\tt AST\_MEMWR} nodes. -\end{itemize} - -In addition to these transformations, the simplifier also annotates the AST with additional information that is needed -for the RTLIL generator, namely: - -\begin{itemize} -\item All ranges (width of signals and bit selections) are not only const folded but (when a constant value -is found) are also written to member variables in the {\tt AST\_RANGE} node. -\item All identifiers are resolved and all {\tt AST\_IDENTIFIER} nodes are annotated with a pointer to the AST node -that contains the declaration of the identifier. If no declaration has been found, an {\tt AST\_AUTOWIRE} node -is created and used for the annotation. -\end{itemize} - -This produces an AST that is fairly easy to convert to the RTLIL format. - -\subsection{Generating RTLIL} - -After AST simplification, the \lstinline[language=C++]{AST::AstNode::genRTLIL()} method of each {\tt AST\_MODULE} node -in the AST is called. This initiates a recursive process that generates equivalent RTLIL data for the AST data. - -The \lstinline[language=C++]{AST::AstNode::genRTLIL()} method returns an \lstinline[language=C++]{RTLIL::SigSpec} structure. -For nodes that represent expressions (operators, constants, signals, etc.), the cells needed to implement the calculation -described by the expression are created and the resulting signal is returned. That way it is easy to generate the circuits -for large expressions using depth-first recursion. For nodes that do not represent an expression (such as {\tt -AST\_CELL}), the corresponding circuit is generated and an empty \lstinline[language=C++]{RTLIL::SigSpec} is returned. - -\section{Synthesizing Verilog always Blocks} - -For behavioural Verilog code (code utilizing \lstinline[language=Verilog]{always}- and -\lstinline[language=Verilog]{initial}-blocks) it is necessary to also generate \lstinline[language=C++]{RTLIL::Process} -objects. This is done in the following way: - -\begin{itemize} -\item Whenever \lstinline[language=C++]{AST::AstNode::genRTLIL()} encounters an \lstinline[language=Verilog]{always}- -or \lstinline[language=Verilog]{initial}-block, it creates an instance of -\lstinline[language=Verilog]{AST_INTERNAL::ProcessGenerator}. This object then generates the -\lstinline[language=C++]{RTLIL::Process} object for the block. It also calls \lstinline[language=C++]{AST::AstNode::genRTLIL()} -for all right-hand-side expressions contained within the block. -% -\begin{sloppypar} -\item First the \lstinline[language=Verilog]{AST_INTERNAL::ProcessGenerator} creates a list of all signals assigned -within the block. It then creates a set of temporary signals using the naming scheme {\tt \$\it<number>\tt -\textbackslash\it <original\_name>} for each of the assigned signals. -\end{sloppypar} -% -\item Then an \lstinline[language=C++]{RTLIL::Process} is created that assigns all intermediate values for each left-hand-side -signal to the temporary signal in its \lstinline[language=C++]{RTLIL::CaseRule}/\lstinline[language=C++]{RTLIL::SwitchRule} tree. -% -\item Finally a \lstinline[language=C++]{RTLIL::SyncRule} is created for the \lstinline[language=C++]{RTLIL::Process} that -assigns the temporary signals for the final values to the actual signals. -% -\item A process may also contain memory writes. A \lstinline[language=C++]{RTLIL::MemWriteAction} is created for each of them. -% -\item Calls to \lstinline[language=C++]{AST::AstNode::genRTLIL()} are generated for right hand sides as needed. When blocking -assignments are used, \lstinline[language=C++]{AST::AstNode::genRTLIL()} is configured using global variables to use -the temporary signals that hold the correct intermediate values whenever one of the previously assigned signals is used -in an expression. -\end{itemize} - -Unfortunately the generation of a correct \lstinline[language=C++]{RTLIL::CaseRule}/\lstinline[language=C++]{RTLIL::SwitchRule} -tree for behavioural code is a non-trivial task. The AST frontend solves the problem using the approach described on the following -pages. The following example illustrates what the algorithm is supposed to do. Consider the following Verilog code: - -\begin{lstlisting}[numbers=left,frame=single,language=Verilog] -always @(posedge clock) begin - out1 = in1; - if (in2) - out1 = !out1; - out2 <= out1; - if (in3) - out2 <= out2; - if (in4) - if (in5) - out3 <= in6; - else - out3 <= in7; - out1 = out1 ^ out2; -end -\end{lstlisting} - -This is translated by the Verilog and AST frontends into the following RTLIL code (attributes, cell parameters -and wire declarations not included): - -\begin{lstlisting}[numbers=left,frame=single,language=rtlil] -cell $logic_not $logic_not$<input>:4$2 - connect \A \in1 - connect \Y $logic_not$<input>:4$2_Y -end -cell $xor $xor$<input>:13$3 - connect \A $1\out1[0:0] - connect \B \out2 - connect \Y $xor$<input>:13$3_Y -end -process $proc$<input>:1$1 - assign $0\out3[0:0] \out3 - assign $0\out2[0:0] $1\out1[0:0] - assign $0\out1[0:0] $xor$<input>:13$3_Y - switch \in2 - case 1'1 - assign $1\out1[0:0] $logic_not$<input>:4$2_Y - case - assign $1\out1[0:0] \in1 - end - switch \in3 - case 1'1 - assign $0\out2[0:0] \out2 - case - end - switch \in4 - case 1'1 - switch \in5 - case 1'1 - assign $0\out3[0:0] \in6 - case - assign $0\out3[0:0] \in7 - end - case - end - sync posedge \clock - update \out1 $0\out1[0:0] - update \out2 $0\out2[0:0] - update \out3 $0\out3[0:0] -end -\end{lstlisting} - -Note that the two operators are translated into separate cells outside the generated process. The signal -\lstinline[language=Verilog]{out1} is assigned using blocking assignments and therefore \lstinline[language=Verilog]{out1} -has been replaced with a different signal in all expressions after the initial assignment. The signal -\lstinline[language=Verilog]{out2} is assigned using nonblocking assignments and therefore is not substituted -on the right-hand-side expressions. - -The \lstinline[language=C++]{RTLIL::CaseRule}/\lstinline[language=C++]{RTLIL::SwitchRule} -tree must be interpreted the following way: - -\begin{itemize} -\item On each case level (the body of the process is the {\it root case}), first the actions on this level are -evaluated and then the switches within the case are evaluated. (Note that the last assignment on line 13 of the -Verilog code has been moved to the beginning of the RTLIL process to line 13 of the RTLIL listing.) - -I.e.~the special cases deeper in the switch hierarchy override the defaults on the upper levels. The assignments -in lines 12 and 22 of the RTLIL code serve as an example for this. - -Note that in contrast to this, the order within the \lstinline[language=C++]{RTLIL::SwitchRule} objects -within a \lstinline[language=C++]{RTLIL::CaseRule} is preserved with respect to the original AST and -Verilog code. -% -\item \begin{sloppypar} -The whole \lstinline[language=C++]{RTLIL::CaseRule}/\lstinline[language=C++]{RTLIL::SwitchRule} tree -describes an asynchronous circuit. I.e.~the decision tree formed by the switches can be seen independently for -each assigned signal. Whenever one assigned signal changes, all signals that depend on the changed signals -are to be updated. For example the assignments in lines 16 and 18 in the RTLIL code in fact influence the assignment -in line 12, even though they are in the ``wrong order''. -\end{sloppypar} -\end{itemize} - -The only synchronous part of the process is in the \lstinline[language=C++]{RTLIL::SyncRule} object generated at line -35 in the RTLIL code. The sync rule is the only part of the process where the original signals are assigned. The -synchronization event from the original Verilog code has been translated into the synchronization type ({\tt posedge}) -and signal ({\tt \textbackslash clock}) for the \lstinline[language=C++]{RTLIL::SyncRule} object. In the case of -this simple example the \lstinline[language=C++]{RTLIL::SyncRule} object is later simply transformed into a set of -d-type flip-flops and the \lstinline[language=C++]{RTLIL::CaseRule}/\lstinline[language=C++]{RTLIL::SwitchRule} tree -to a decision tree using multiplexers. - -\begin{sloppypar} -In more complex examples (e.g.~asynchronous resets) the part of the -\lstinline[language=C++]{RTLIL::CaseRule}/\lstinline[language=C++]{RTLIL::SwitchRule} -tree that describes the asynchronous reset must first be transformed to the -correct \lstinline[language=C++]{RTLIL::SyncRule} objects. This is done by the {\tt proc\_adff} pass. -\end{sloppypar} - -\subsection{The ProcessGenerator Algorithm} - -The \lstinline[language=C++]{AST_INTERNAL::ProcessGenerator} uses the following internal state variables: - -\begin{itemize} -\item \begin{sloppypar} -\lstinline[language=C++]{subst_rvalue_from} and \lstinline[language=C++]{subst_rvalue_to} \\ -These two variables hold the replacement pattern that should be used by \lstinline[language=C++]{AST::AstNode::genRTLIL()} -for signals with blocking assignments. After initialization of \lstinline[language=C++]{AST_INTERNAL::ProcessGenerator} -these two variables are empty. -\end{sloppypar} -% -\item \lstinline[language=C++]{subst_lvalue_from} and \lstinline[language=C++]{subst_lvalue_to} \\ -These two variables contain the mapping from left-hand-side signals ({\tt \textbackslash \it <name>}) to the current -temporary signal for the same thing (initially {\tt \$0\textbackslash \it <name>}). -% -\item \lstinline[language=C++]{current_case} \\ -A pointer to a \lstinline[language=C++]{RTLIL::CaseRule} object. Initially this is the root case of the -generated \lstinline[language=C++]{RTLIL::Process}. -\end{itemize} - -As the algorithm runs these variables are continuously modified as well as pushed -to the stack and later restored to their earlier values by popping from the stack. - -On startup the ProcessGenerator generates a new -\lstinline[language=C++]{RTLIL::Process} object with an empty root case and -initializes its state variables as described above. Then the \lstinline[language=C++]{RTLIL::SyncRule} objects -are created using the synchronization events from the {\tt AST\_ALWAYS} node and the initial values of -\lstinline[language=C++]{subst_lvalue_from} and \lstinline[language=C++]{subst_lvalue_to}. Then the -AST for this process is evaluated recursively. - -During this recursive evaluation, three different relevant types of AST nodes can be discovered: -{\tt AST\_ASSIGN\_LE} (nonblocking assignments), {\tt AST\_ASSIGN\_EQ} (blocking assignments) and -{\tt AST\_CASE} (\lstinline[language=Verilog]{if} or \lstinline[language=Verilog]{case} statement). - -\subsubsection{Handling of Nonblocking Assignments} - -When an {\tt AST\_ASSIGN\_LE} node is discovered, the following actions are performed by the -ProcessGenerator: - -\begin{itemize} -\item The left-hand-side is evaluated using \lstinline[language=C++]{AST::AstNode::genRTLIL()} and mapped to -a temporary signal name using \lstinline[language=C++]{subst_lvalue_from} and \lstinline[language=C++]{subst_lvalue_to}. -% -\item The right-hand-side is evaluated using \lstinline[language=C++]{AST::AstNode::genRTLIL()}. For this call, -the values of \lstinline[language=C++]{subst_rvalue_from} and \lstinline[language=C++]{subst_rvalue_to} are used to -map blocking-assigned signals correctly. -% -\item Remove all assignments to the same left-hand-side as this assignment from the \lstinline[language=C++]{current_case} -and all cases within it. -% -\item Add the new assignment to the \lstinline[language=C++]{current_case}. -\end{itemize} - -\subsubsection{Handling of Blocking Assignments} - -When an {\tt AST\_ASSIGN\_EQ} node is discovered, the following actions are performed by -the ProcessGenerator: - -\begin{itemize} -\item Perform all the steps that would be performed for a nonblocking assignment (see above). -% -\item Remove the found left-hand-side (before lvalue mapping) from -\lstinline[language=C++]{subst_rvalue_from} and also remove the respective -bits from \lstinline[language=C++]{subst_rvalue_to}. -% -\item Append the found left-hand-side (before lvalue mapping) to \lstinline[language=C++]{subst_rvalue_from} -and append the found right-hand-side to \lstinline[language=C++]{subst_rvalue_to}. -\end{itemize} - -\subsubsection{Handling of Cases and if-Statements} - -\begin{sloppypar} -When an {\tt AST\_CASE} node is discovered, the following actions are performed by -the ProcessGenerator: - -\begin{itemize} -\item The values of \lstinline[language=C++]{subst_rvalue_from}, \lstinline[language=C++]{subst_rvalue_to}, -\lstinline[language=C++]{subst_lvalue_from} and \lstinline[language=C++]{subst_lvalue_to} are pushed to the stack. -% -\item A new \lstinline[language=C++]{RTLIL::SwitchRule} object is generated, the selection expression is evaluated using -\lstinline[language=C++]{AST::AstNode::genRTLIL()} (with the use of \lstinline[language=C++]{subst_rvalue_from} and -\lstinline[language=C++]{subst_rvalue_to}) and added to the \lstinline[language=C++]{RTLIL::SwitchRule} object and the -object is added to the \lstinline[language=C++]{current_case}. -% -\item All lvalues assigned to within the {\tt AST\_CASE} node using blocking assignments are collected and -saved in the local variable \lstinline[language=C++]{this_case_eq_lvalue}. -% -\item New temporary signals are generated for all signals in \lstinline[language=C++]{this_case_eq_lvalue} and stored -in \lstinline[language=C++]{this_case_eq_ltemp}. -% -\item The signals in \lstinline[language=C++]{this_case_eq_lvalue} are mapped using \lstinline[language=C++]{subst_rvalue_from} -and \lstinline[language=C++]{subst_rvalue_to} and the resulting set of signals is stored in -\lstinline[language=C++]{this_case_eq_rvalue}. -\end{itemize} - -Then the following steps are performed for each {\tt AST\_COND} node within the {\tt AST\_CASE} node: - -\begin{itemize} -\item Set \lstinline[language=C++]{subst_rvalue_from}, \lstinline[language=C++]{subst_rvalue_to}, -\lstinline[language=C++]{subst_lvalue_from} and \lstinline[language=C++]{subst_lvalue_to} to the values -that have been pushed to the stack. -% -\item Remove \lstinline[language=C++]{this_case_eq_lvalue} from -\lstinline[language=C++]{subst_lvalue_from}/\lstinline[language=C++]{subst_lvalue_to}. -% -\item Append \lstinline[language=C++]{this_case_eq_lvalue} to \lstinline[language=C++]{subst_lvalue_from} and append -\lstinline[language=C++]{this_case_eq_ltemp} to \lstinline[language=C++]{subst_lvalue_to}. -% -\item Push the value of \lstinline[language=C++]{current_case}. -% -\item Create a new \lstinline[language=C++]{RTLIL::CaseRule}. Set \lstinline[language=C++]{current_case} to the -new object and add the new object to the \lstinline[language=C++]{RTLIL::SwitchRule} created above. -% -\item Add an assignment from \lstinline[language=C++]{this_case_eq_rvalue} to \lstinline[language=C++]{this_case_eq_ltemp} -to the new \lstinline[language=C++]{current_case}. -% -\item Evaluate the compare value for this case using \lstinline[language=C++]{AST::AstNode::genRTLIL()} (with the use of -\lstinline[language=C++]{subst_rvalue_from} and \lstinline[language=C++]{subst_rvalue_to}) modify the new -\lstinline[language=C++]{current_case} accordingly. -% -\item Recursion into the children of the {\tt AST\_COND} node. -% -\item Restore \lstinline[language=C++]{current_case} by popping the old value from the stack. -\end{itemize} - -Finally the following steps are performed: - -\begin{itemize} -\item The values of \lstinline[language=C++]{subst_rvalue_from}, \lstinline[language=C++]{subst_rvalue_to}, -\lstinline[language=C++]{subst_lvalue_from} and \lstinline[language=C++]{subst_lvalue_to} are popped from the stack. -% -\item The signals from \lstinline[language=C++]{this_case_eq_lvalue} are removed from the -\lstinline[language=C++]{subst_rvalue_from}/\lstinline[language=C++]{subst_rvalue_to}-pair. -% -\item The value of \lstinline[language=C++]{this_case_eq_lvalue} is appended to \lstinline[language=C++]{subst_rvalue_from} -and the value of \lstinline[language=C++]{this_case_eq_ltemp} is appended to \lstinline[language=C++]{subst_rvalue_to}. -% -\item Map the signals in \lstinline[language=C++]{this_case_eq_lvalue} using -\lstinline[language=C++]{subst_lvalue_from}/\lstinline[language=C++]{subst_lvalue_to}. -% -\item Remove all assignments to signals in \lstinline[language=C++]{this_case_eq_lvalue} in \lstinline[language=C++]{current_case} -and all cases within it. -% -\item Add an assignment from \lstinline[language=C++]{this_case_eq_ltemp} to \lstinline[language=C++]{this_case_eq_lvalue} -to \lstinline[language=C++]{current_case}. -\end{itemize} -\end{sloppypar} - -\subsubsection{Further Analysis of the Algorithm for Cases and if-Statements} - -With respect to nonblocking assignments the algorithm is easy: later assignments invalidate earlier assignments. -For each signal assigned using nonblocking assignments exactly one temporary variable is generated (with the -{\tt \$0}-prefix) and this variable is used for all assignments of the variable. - -Note how all the \lstinline[language=C++]{_eq_}-variables become empty when no blocking assignments are used -and many of the steps in the algorithm can then be ignored as a result of this. - -For a variable with blocking assignments the algorithm shows the following behaviour: First a new temporary variable -is created. This new temporary variable is then registered as the assignment target for all assignments for this -variable within the cases for this {\tt AST\_CASE} node. Then for each case the new temporary variable is first -assigned the old temporary variable. This assignment is overwritten if the variable is actually assigned in this -case and is kept as a default value otherwise. - -This yields an \lstinline[language=C++]{RTLIL::CaseRule} that assigns the new temporary variable in all branches. -So when all cases have been processed a final assignment is added to the containing block that assigns the new -temporary variable to the old one. Note how this step always overrides a previous assignment to the old temporary -variable. Other than nonblocking assignments, the old assignment could still have an effect somewhere -in the design, as there have been calls to \lstinline[language=C++]{AST::AstNode::genRTLIL()} with a -\lstinline[language=C++]{subst_rvalue_from}/\lstinline[language=C++]{subst_rvalue_to}-tuple that contained -the right-hand-side of the old assignment. - -\subsection{The proc pass} - -The ProcessGenerator converts a behavioural model in AST representation to a behavioural model in -\lstinline[language=C++]{RTLIL::Process} representation. The actual conversion from a behavioural -model to an RTL representation is performed by the {\tt proc} pass and the passes it launches: - -\begin{itemize} -\item {\tt proc\_clean} and {\tt proc\_rmdead} \\ -These two passes just clean up the \lstinline[language=C++]{RTLIL::Process} structure. The {\tt proc\_clean} -pass removes empty parts (eg. empty assignments) from the process and {\tt proc\_rmdead} detects and removes -unreachable branches from the process's decision trees. -% -\item {\tt proc\_arst} \\ -This pass detects processes that describe d-type flip-flops with asynchronous -resets and rewrites the process to better reflect what they are modelling: -Before this pass, an asynchronous reset has two edge-sensitive sync rules and -one top-level \C{RTLIL::SwitchRule} for the reset path. After this pass the -sync rule for the reset is level-sensitive and the top-level -\C{RTLIL::SwitchRule} has been removed. -% -\item {\tt proc\_mux} \\ -This pass converts the \C{RTLIL::CaseRule}/\C{RTLIL::SwitchRule}-tree to a tree -of multiplexers per written signal. After this, the \C{RTLIL::Process} structure only contains -the \C{RTLIL::SyncRule}s that describe the output registers. -% -\item {\tt proc\_dff} \\ -This pass replaces the \C{RTLIL::SyncRule}s to d-type flip-flops (with -asynchronous resets if necessary). -% -\item {\tt proc\_dff} \\ -This pass replaces the \C{RTLIL::MemWriteActions}s with {\tt \$memwr} cells. -% -\item {\tt proc\_clean} \\ -A final call to {\tt proc\_clean} removes the now empty \C{RTLIL::Process} objects. -\end{itemize} - -Performing these last processing steps in passes instead of in the Verilog frontend has two important benefits: - -First it improves the transparency of the process. Everything that happens in a separate pass is easier to debug, -as the RTLIL data structures can be easily investigated before and after each of the steps. - -Second it improves flexibility. This scheme can easily be extended to support other types of storage-elements, such -as sr-latches or d-latches, without having to extend the actual Verilog frontend. - -\section{Synthesizing Verilog Arrays} - -\begin{fixme} -Add some information on the generation of {\tt \$memrd} and {\tt \$memwr} cells -and how they are processed in the {\tt memory} pass. -\end{fixme} - -\section{Synthesizing Parametric Designs} - -\begin{fixme} -Add some information on the \lstinline[language=C++]{RTLIL::Module::derive()} method and how it -is used to synthesize parametric modules via the {\tt hierarchy} pass. -\end{fixme} - diff --git a/manual/appnotes.sh b/manual/appnotes.sh deleted file mode 100755 index 0ae52862e..000000000 --- a/manual/appnotes.sh +++ /dev/null @@ -1,22 +0,0 @@ -#!/bin/bash - -set -ex -for job in APPNOTE_010_Verilog_to_BLIF APPNOTE_011_Design_Investigation APPNOTE_012_Verilog_to_BTOR -do - [ -f $job.ok -a $job.ok -nt $job.tex ] && continue - if [ -f $job/make.sh ]; then - cd $job - bash make.sh - cd .. - fi - old_md5=$([ -f $job.aux ] && md5sum < $job.aux || true) - while - pdflatex -shell-escape -halt-on-error $job.tex || exit - new_md5=$(md5sum < $job.aux) - [ "$old_md5" != "$new_md5" ] - do - old_md5="$new_md5" - done - touch $job.ok -done - diff --git a/manual/command-reference-manual.tex b/manual/command-reference-manual.tex deleted file mode 100644 index 62183801d..000000000 --- a/manual/command-reference-manual.tex +++ /dev/null @@ -1,9592 +0,0 @@ -% Generated using the yosys 'help -write-tex-command-reference-manual' command. - -\section{abc -- use ABC for technology mapping} -\label{cmd:abc} -\begin{lstlisting}[numbers=left,frame=single] - abc [options] [selection] - -This pass uses the ABC tool [1] for technology mapping of yosys's internal gate -library to a target architecture. - - -exe <command> - use the specified command instead of "<yosys-bindir>/yosys-abc" to execute ABC. - This can e.g. be used to call a specific version of ABC or a wrapper. - - -script <file> - use the specified ABC script file instead of the default script. - - if <file> starts with a plus sign (+), then the rest of the filename - string is interpreted as the command string to be passed to ABC. The - leading plus sign is removed and all commas (,) in the string are - replaced with blanks before the string is passed to ABC. - - if no -script parameter is given, the following scripts are used: - - for -liberty/-genlib without -constr: - strash; &get -n; &fraig -x; &put; scorr; dc2; dretime; strash; - &get -n; &dch -f; &nf {D}; &put - - for -liberty/-genlib with -constr: - strash; &get -n; &fraig -x; &put; scorr; dc2; dretime; strash; - &get -n; &dch -f; &nf {D}; &put; buffer; upsize {D}; - dnsize {D}; stime -p - - for -lut/-luts (only one LUT size): - strash; &get -n; &fraig -x; &put; scorr; dc2; dretime; strash; - dch -f; if; mfs2; lutpack {S} - - for -lut/-luts (different LUT sizes): - strash; &get -n; &fraig -x; &put; scorr; dc2; dretime; strash; - dch -f; if; mfs2 - - for -sop: - strash; &get -n; &fraig -x; &put; scorr; dc2; dretime; strash; - dch -f; cover {I} {P} - - otherwise: - strash; &get -n; &fraig -x; &put; scorr; dc2; dretime; strash; - &get -n; &dch -f; &nf {D}; &put - - -fast - use different default scripts that are slightly faster (at the cost - of output quality): - - for -liberty/-genlib without -constr: - strash; dretime; map {D} - - for -liberty/-genlib with -constr: - strash; dretime; map {D}; buffer; upsize {D}; dnsize {D}; - stime -p - - for -lut/-luts: - strash; dretime; if - - for -sop: - strash; dretime; cover {I} {P} - - otherwise: - strash; dretime; map - - -liberty <file> - generate netlists for the specified cell library (using the liberty - file format). - - -genlib <file> - generate netlists for the specified cell library (using the SIS Genlib - file format). - - -constr <file> - pass this file with timing constraints to ABC. - use with -liberty/-genlib. - - a constr file contains two lines: - set_driving_cell <cell_name> - set_load <floating_point_number> - - the set_driving_cell statement defines which cell type is assumed to - drive the primary inputs and the set_load statement sets the load in - femtofarads for each primary output. - - -D <picoseconds> - set delay target. the string {D} in the default scripts above is - replaced by this option when used, and an empty string otherwise. - this also replaces 'dretime' with 'dretime; retime -o {D}' in the - default scripts above. - - -I <num> - maximum number of SOP inputs. - (replaces {I} in the default scripts above) - - -P <num> - maximum number of SOP products. - (replaces {P} in the default scripts above) - - -S <num> - maximum number of LUT inputs shared. - (replaces {S} in the default scripts above, default: -S 1) - - -lut <width> - generate netlist using luts of (max) the specified width. - - -lut <w1>:<w2> - generate netlist using luts of (max) the specified width <w2>. All - luts with width <= <w1> have constant cost. for luts larger than <w1> - the area cost doubles with each additional input bit. the delay cost - is still constant for all lut widths. - - -luts <cost1>,<cost2>,<cost3>,<sizeN>:<cost4-N>,.. - generate netlist using luts. Use the specified costs for luts with 1, - 2, 3, .. inputs. - - -sop - map to sum-of-product cells and inverters - - -g type1,type2,... - Map to the specified list of gate types. Supported gates types are: - AND, NAND, OR, NOR, XOR, XNOR, ANDNOT, ORNOT, MUX, - NMUX, AOI3, OAI3, AOI4, OAI4. - (The NOT gate is always added to this list automatically.) - - The following aliases can be used to reference common sets of gate - types: - simple: AND OR XOR MUX - cmos2: NAND NOR - cmos3: NAND NOR AOI3 OAI3 - cmos4: NAND NOR AOI3 OAI3 AOI4 OAI4 - cmos: NAND NOR AOI3 OAI3 AOI4 OAI4 NMUX MUX XOR XNOR - gates: AND NAND OR NOR XOR XNOR ANDNOT ORNOT - aig: AND NAND OR NOR ANDNOT ORNOT - - The alias 'all' represent the full set of all gate types. - - Prefix a gate type with a '-' to remove it from the list. For example - the arguments 'AND,OR,XOR' and 'simple,-MUX' are equivalent. - - The default is 'all,-NMUX,-AOI3,-OAI3,-AOI4,-OAI4'. - - -dff - also pass $_DFF_?_ and $_DFFE_??_ cells through ABC. modules with many - clock domains are automatically partitioned in clock domains and each - domain is passed through ABC independently. - - -clk [!]<clock-signal-name>[,[!]<enable-signal-name>] - use only the specified clock domain. this is like -dff, but only FF - cells that belong to the specified clock domain are used. - - -keepff - set the "keep" attribute on flip-flop output wires. (and thus preserve - them, for example for equivalence checking.) - - -nocleanup - when this option is used, the temporary files created by this pass - are not removed. this is useful for debugging. - - -showtmp - print the temp dir name in log. usually this is suppressed so that the - command output is identical across runs. - - -markgroups - set a 'abcgroup' attribute on all objects created by ABC. The value of - this attribute is a unique integer for each ABC process started. This - is useful for debugging the partitioning of clock domains. - - -dress - run the 'dress' command after all other ABC commands. This aims to - preserve naming by an equivalence check between the original and - post-ABC netlists (experimental). - -When no target cell library is specified the Yosys standard cell library is -loaded into ABC before the ABC script is executed. - -Note that this is a logic optimization pass within Yosys that is calling ABC -internally. This is not going to "run ABC on your design". It will instead run -ABC on logic snippets extracted from your design. You will not get any useful -output when passing an ABC script that writes a file. Instead write your full -design as BLIF file with write_blif and then load that into ABC externally if -you want to use ABC to convert your design into another format. - -[1] http://www.eecs.berkeley.edu/~alanmi/abc/ -\end{lstlisting} - -\section{abc9 -- use ABC9 for technology mapping} -\label{cmd:abc9} -\begin{lstlisting}[numbers=left,frame=single] - abc9 [options] [selection] - -This script pass performs a sequence of commands to facilitate the use of the -ABC tool [1] for technology mapping of the current design to a target FPGA -architecture. Only fully-selected modules are supported. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -exe <command> - use the specified command instead of "<yosys-bindir>/yosys-abc" to execute ABC. - This can e.g. be used to call a specific version of ABC or a wrapper. - - -script <file> - use the specified ABC script file instead of the default script. - - if <file> starts with a plus sign (+), then the rest of the filename - string is interpreted as the command string to be passed to ABC. The - leading plus sign is removed and all commas (,) in the string are - replaced with blanks before the string is passed to ABC. - - if no -script parameter is given, the following scripts are used: - &scorr; &sweep; &dc2; &dch -f; &ps; &if {C} {W} {D} {R} -v; &mfs - - -fast - use different default scripts that are slightly faster (at the cost - of output quality): - &if {C} {W} {D} {R} -v - - -D <picoseconds> - set delay target. the string {D} in the default scripts above is - replaced by this option when used, and an empty string otherwise - (indicating best possible delay). - - -lut <width> - generate netlist using luts of (max) the specified width. - - -lut <w1>:<w2> - generate netlist using luts of (max) the specified width <w2>. All - luts with width <= <w1> have constant cost. for luts larger than <w1> - the area cost doubles with each additional input bit. the delay cost - is still constant for all lut widths. - - -lut <file> - pass this file with lut library to ABC. - - -luts <cost1>,<cost2>,<cost3>,<sizeN>:<cost4-N>,.. - generate netlist using luts. Use the specified costs for luts with 1, - 2, 3, .. inputs. - - -maxlut <width> - when auto-generating the lut library, discard all luts equal to or - greater than this size (applicable when neither -lut nor -luts is - specified). - - -dff - also pass $_DFF_[NP]_ cells through to ABC. modules with many clock - domains are supported and automatically partitioned by ABC. - - -nocleanup - when this option is used, the temporary files created by this pass - are not removed. this is useful for debugging. - - -showtmp - print the temp dir name in log. usually this is suppressed so that the - command output is identical across runs. - - -box <file> - pass this file with box library to ABC. - -Note that this is a logic optimization pass within Yosys that is calling ABC -internally. This is not going to "run ABC on your design". It will instead run -ABC on logic snippets extracted from your design. You will not get any useful -output when passing an ABC script that writes a file. Instead write your full -design as an XAIGER file with `write_xaiger' and then load that into ABC -externally if you want to use ABC to convert your design into another format. - -[1] http://www.eecs.berkeley.edu/~alanmi/abc/ - - - check: - abc9_ops -check [-dff] (option if -dff) - - map: - abc9_ops -prep_hier [-dff] (option if -dff) - scc -specify -set_attr abc9_scc_id {} - abc9_ops -prep_bypass [-prep_dff] (option if -dff) - design -stash $abc9 - design -load $abc9_map - proc - wbflip - techmap -wb -map %$abc9 -map +/techmap.v A:abc9_flop - opt -nodffe -nosdff - abc9_ops -prep_dff_submod (only if -dff) - setattr -set submod "$abc9_flop" t:$_DFF_?_ %ci* %co* t:$_DFF_?_ %d (only if -dff) - submod (only if -dff) - setattr -mod -set whitebox 1 -set abc9_flop 1 -set abc9_box 1 *_$abc9_flop (only if -dff) - foreach module in design - rename <module-name>_$abc9_flop _TECHMAP_REPLACE_ (only if -dff) - abc9_ops -prep_dff_unmap (only if -dff) - design -copy-to $abc9 =*_$abc9_flop (only if -dff) - delete =*_$abc9_flop (only if -dff) - design -stash $abc9_map - design -load $abc9 - design -delete $abc9 - techmap -wb -max_iter 1 -map %$abc9_map -map +/abc9_map.v [-D DFF] (option if -dff) - design -delete $abc9_map - - pre: - read_verilog -icells -lib -specify +/abc9_model.v - abc9_ops -break_scc -prep_delays -prep_xaiger [-dff] (option for -dff) - abc9_ops -prep_lut <maxlut> (skip if -lut or -luts) - abc9_ops -prep_box (skip if -box) - design -stash $abc9 - design -load $abc9_holes - techmap -wb -map %$abc9 -map +/techmap.v - opt -purge - aigmap - design -stash $abc9_holes - design -load $abc9 - design -delete $abc9 - - exe: - aigmap - foreach module in selection - abc9_ops -write_lut <abc-temp-dir>/input.lut (skip if '-lut' or '-luts') - abc9_ops -write_box <abc-temp-dir>/input.box (skip if '-box') - write_xaiger -map <abc-temp-dir>/input.sym [-dff] <abc-temp-dir>/input.xaig - abc9_exe [options] -cwd <abc-temp-dir> -lut [<abc-temp-dir>/input.lut] -box [<abc-temp-dir>/input.box] - read_aiger -xaiger -wideports -module_name <module-name>$abc9 -map <abc-temp-dir>/input.sym <abc-temp-dir>/output.aig - abc9_ops -reintegrate [-dff] - - unmap: - techmap -wb -map %$abc9_unmap -map +/abc9_unmap.v - design -delete $abc9_unmap - design -delete $abc9_holes - delete =*_$abc9_byp - setattr -mod -unset abc9_box_id -\end{lstlisting} - -\section{abc9\_exe -- use ABC9 for technology mapping} -\label{cmd:abc9_exe} -\begin{lstlisting}[numbers=left,frame=single] - abc9_exe [options] - - -This pass uses the ABC tool [1] for technology mapping of the top module -(according to the (* top *) attribute or if only one module is currently -selected) to a target FPGA architecture. - - -exe <command> - use the specified command instead of "<yosys-bindir>/yosys-abc" to execute ABC. - This can e.g. be used to call a specific version of ABC or a wrapper. - - -script <file> - use the specified ABC script file instead of the default script. - - if <file> starts with a plus sign (+), then the rest of the filename - string is interpreted as the command string to be passed to ABC. The - leading plus sign is removed and all commas (,) in the string are - replaced with blanks before the string is passed to ABC. - - if no -script parameter is given, the following scripts are used: - &scorr; &sweep; &dc2; &dch -f; &ps; &if {C} {W} {D} {R} -v; &mfs - - -fast - use different default scripts that are slightly faster (at the cost - of output quality): - &if {C} {W} {D} {R} -v - - -D <picoseconds> - set delay target. the string {D} in the default scripts above is - replaced by this option when used, and an empty string otherwise - (indicating best possible delay). - - -lut <width> - generate netlist using luts of (max) the specified width. - - -lut <w1>:<w2> - generate netlist using luts of (max) the specified width <w2>. All - luts with width <= <w1> have constant cost. for luts larger than <w1> - the area cost doubles with each additional input bit. the delay cost - is still constant for all lut widths. - - -lut <file> - pass this file with lut library to ABC. - - -luts <cost1>,<cost2>,<cost3>,<sizeN>:<cost4-N>,.. - generate netlist using luts. Use the specified costs for luts with 1, - 2, 3, .. inputs. - - -showtmp - print the temp dir name in log. usually this is suppressed so that the - command output is identical across runs. - - -box <file> - pass this file with box library to ABC. - - -cwd <dir> - use this as the current working directory, inside which the 'input.xaig' - file is expected. temporary files will be created in this directory, and - the mapped result will be written to 'output.aig'. - -Note that this is a logic optimization pass within Yosys that is calling ABC -internally. This is not going to "run ABC on your design". It will instead run -ABC on logic snippets extracted from your design. You will not get any useful -output when passing an ABC script that writes a file. Instead write your full -design as BLIF file with write_blif and then load that into ABC externally if -you want to use ABC to convert your design into another format. - -[1] http://www.eecs.berkeley.edu/~alanmi/abc/ -\end{lstlisting} - -\section{abc9\_ops -- helper functions for ABC9} -\label{cmd:abc9_ops} -\begin{lstlisting}[numbers=left,frame=single] - abc9_ops [options] [selection] - -This pass contains a set of supporting operations for use during ABC technology -mapping, and is expected to be called in conjunction with other operations from -the `abc9' script pass. Only fully-selected modules are supported. - - -check - check that the design is valid, e.g. (* abc9_box_id *) values are - unique, (* abc9_carry *) is only given for one input/output port, etc. - - -prep_hier - derive all used (* abc9_box *) or (* abc9_flop *) (if -dff option) - whitebox modules. with (* abc9_flop *) modules, only those containing - $dff/$_DFF_[NP]_ cells with zero initial state -- due to an ABC - limitation -- will be derived. - - -prep_bypass - create techmap rules in the '$abc9_map' and '$abc9_unmap' designs for - bypassing sequential (* abc9_box *) modules using a combinatorial box - (named *_$abc9_byp). bypassing is necessary if sequential elements (e.g. - $dff, $mem, etc.) are discovered inside so that any combinatorial paths - will be correctly captured. this bypass box will only contain ports that - are referenced by a simple path declaration ($specify2 cell) inside a - specify block. - - -prep_dff - select all (* abc9_flop *) modules instantiated in the design and store - in the named selection '$abc9_flops'. - - -prep_dff_submod - within (* abc9_flop *) modules, rewrite all edge-sensitive path - declarations and $setup() timing checks ($specify3 and $specrule cells) - that share a 'DST' port with the $_DFF_[NP]_.Q port from this 'Q' port - to the DFF's 'D' port. this is to prepare such specify cells to be moved - into the flop box. - - -prep_dff_unmap - populate the '$abc9_unmap' design with techmap rules for mapping - *_$abc9_flop cells back into their derived cell types (where the rules - created by -prep_hier will then map back to the original cell with - parameters). - - -prep_delays - insert `$__ABC9_DELAY' blackbox cells into the design to account for - certain required times. - - -break_scc - for an arbitrarily chosen cell in each unique SCC of each selected - module (tagged with an (* abc9_scc_id = <int> *) attribute) interrupt - all wires driven by this cell's outputs with a temporary - $__ABC9_SCC_BREAKER cell to break the SCC. - - -prep_xaiger - prepare the design for XAIGER output. this includes computing the - topological ordering of ABC9 boxes, as well as preparing the - '$abc9_holes' design that contains the logic behaviour of ABC9 - whiteboxes. - - -dff - consider flop cells (those instantiating modules marked with - (* abc9_flop *)) during -prep_{delays,xaiger,box}. - - -prep_lut <maxlut> - pre-compute the lut library by analysing all modules marked with - (* abc9_lut=<area> *). - - -write_lut <dst> - write the pre-computed lut library to <dst>. - - -prep_box - pre-compute the box library by analysing all modules marked with - (* abc9_box *). - - -write_box <dst> - write the pre-computed box library to <dst>. - - -reintegrate - for each selected module, re-intergrate the module '<module-name>$abc9' - by first recovering ABC9 boxes, and then stitching in the remaining - primary inputs and outputs. -\end{lstlisting} - -\section{add -- add objects to the design} -\label{cmd:add} -\begin{lstlisting}[numbers=left,frame=single] - add <command> [selection] - -This command adds objects to the design. It operates on all fully selected -modules. So e.g. 'add -wire foo' will add a wire foo to all selected modules. - - - add {-wire|-input|-inout|-output} <name> <width> [selection] - -Add a wire (input, inout, output port) with the given name and width. The -command will fail if the object exists already and has different properties -than the object to be created. - - - add -global_input <name> <width> [selection] - -Like 'add -input', but also connect the signal between instances of the -selected modules. - - - add {-assert|-assume|-live|-fair|-cover} <name1> [-if <name2>] - -Add an $assert, $assume, etc. cell connected to a wire named name1, with its -enable signal optionally connected to a wire named name2 (default: 1'b1). - - - add -mod <name[s]> - -Add module[s] with the specified name[s]. -\end{lstlisting} - -\section{aigmap -- map logic to and-inverter-graph circuit} -\label{cmd:aigmap} -\begin{lstlisting}[numbers=left,frame=single] - aigmap [options] [selection] - -Replace all logic cells with circuits made of only $_AND_ and -$_NOT_ cells. - - -nand - Enable creation of $_NAND_ cells - - -select - Overwrite replaced cells in the current selection with new $_AND_, - $_NOT_, and $_NAND_, cells -\end{lstlisting} - -\section{alumacc -- extract ALU and MACC cells} -\label{cmd:alumacc} -\begin{lstlisting}[numbers=left,frame=single] - alumacc [selection] - -This pass translates arithmetic operations like $add, $mul, $lt, etc. to $alu -and $macc cells. -\end{lstlisting} - -\section{anlogic\_eqn -- Anlogic: Calculate equations for luts} -\label{cmd:anlogic_eqn} -\begin{lstlisting}[numbers=left,frame=single] - anlogic_eqn [selection] - -Calculate equations for luts since bitstream generator depends on it. -\end{lstlisting} - -\section{anlogic\_fixcarry -- Anlogic: fix carry chain} -\label{cmd:anlogic_fixcarry} -\begin{lstlisting}[numbers=left,frame=single] - anlogic_fixcarry [options] [selection] - -Add Anlogic adders to fix carry chain if needed. -\end{lstlisting} - -\section{assertpmux -- adds asserts for parallel muxes} -\label{cmd:assertpmux} -\begin{lstlisting}[numbers=left,frame=single] - assertpmux [options] [selection] - -This command adds asserts to the design that assert that all parallel muxes -($pmux cells) have a maximum of one of their inputs enable at any time. - - -noinit - do not enforce the pmux condition during the init state - - -always - usually the $pmux condition is only checked when the $pmux output - is used by the mux tree it drives. this option will deactivate this - additional constraint and check the $pmux condition always. -\end{lstlisting} - -\section{async2sync -- convert async FF inputs to sync circuits} -\label{cmd:async2sync} -\begin{lstlisting}[numbers=left,frame=single] - async2sync [options] [selection] - -This command replaces async FF inputs with sync circuits emulating the same -behavior for when the async signals are actually synchronized to the clock. - -This pass assumes negative hold time for the async FF inputs. For example when -a reset deasserts with the clock edge, then the FF output will still drive the -reset value in the next cycle regardless of the data-in value at the time of -the clock edge. -\end{lstlisting} - -\section{attrmap -- renaming attributes} -\label{cmd:attrmap} -\begin{lstlisting}[numbers=left,frame=single] - attrmap [options] [selection] - -This command renames attributes and/or maps key/value pairs to -other key/value pairs. - - -tocase <name> - Match attribute names case-insensitively and set it to the specified - name. - - -rename <old_name> <new_name> - Rename attributes as specified - - -map <old_name>=<old_value> <new_name>=<new_value> - Map key/value pairs as indicated. - - -imap <old_name>=<old_value> <new_name>=<new_value> - Like -map, but use case-insensitive match for <old_value> when - it is a string value. - - -remove <name>=<value> - Remove attributes matching this pattern. - - -modattr - Operate on module attributes instead of attributes on wires and cells. - -For example, mapping Xilinx-style "keep" attributes to Yosys-style: - - attrmap -tocase keep -imap keep="true" keep=1 \ - -imap keep="false" keep=0 -remove keep=0 -\end{lstlisting} - -\section{attrmvcp -- move or copy attributes from wires to driving cells} -\label{cmd:attrmvcp} -\begin{lstlisting}[numbers=left,frame=single] - attrmvcp [options] [selection] - -Move or copy attributes on wires to the cells driving them. - - -copy - By default, attributes are moved. This will only add - the attribute to the cell, without removing it from - the wire. - - -purge - If no selected cell consumes the attribute, then it is - left on the wire by default. This option will cause the - attribute to be removed from the wire, even if no selected - cell takes it. - - -driven - By default, attriburtes are moved to the cell driving the - wire. With this option set it will be moved to the cell - driven by the wire instead. - - -attr <attrname> - Move or copy this attribute. This option can be used - multiple times. -\end{lstlisting} - -\section{autoname -- automatically assign names to objects} -\label{cmd:autoname} -\begin{lstlisting}[numbers=left,frame=single] - autoname [selection] - -Assign auto-generated public names to objects with private names (the ones -with $-prefix). -\end{lstlisting} - -\section{blackbox -- convert modules into blackbox modules} -\label{cmd:blackbox} -\begin{lstlisting}[numbers=left,frame=single] - blackbox [options] [selection] - -Convert modules into blackbox modules (remove contents and set the blackbox -module attribute). -\end{lstlisting} - -\section{bmuxmap -- transform \$bmux cells to trees of \$mux cells} -\label{cmd:bmuxmap} -\begin{lstlisting}[numbers=left,frame=single] - bmuxmap [selection] - -This pass transforms $bmux cells to trees of $mux cells. -\end{lstlisting} - -\section{bugpoint -- minimize testcases} -\label{cmd:bugpoint} -\begin{lstlisting}[numbers=left,frame=single] - bugpoint [options] [-script <filename> | -command "<command>"] - -This command minimizes the current design that is known to crash Yosys with the -given script into a smaller testcase. It does this by removing an arbitrary part -of the design and recursively invokes a new Yosys process with this modified -design and the same script, repeating these steps while it can find a smaller -design that still causes a crash. Once this command finishes, it replaces the -current design with the smallest testcase it was able to produce. -In order to save the reduced testcase you must write this out to a file with -another command after `bugpoint` like `write_rtlil` or `write_verilog`. - - -script <filename> | -command "<command>" - use this script file or command to crash Yosys. required. - - -yosys <filename> - use this Yosys binary. if not specified, `yosys` is used. - - -grep "<string>" - only consider crashes that place this string in the log file. - - -fast - run `proc_clean; clean -purge` after each minimization step. converges - faster, but produces larger testcases, and may fail to produce any - testcase at all if the crash is related to dangling wires. - - -clean - run `proc_clean; clean -purge` before checking testcase and after - finishing. produces smaller and more useful testcases, but may fail to - produce any testcase at all if the crash is related to dangling wires. - -It is possible to constrain which parts of the design will be considered for -removal. Unless one or more of the following options are specified, all parts -will be considered. - - -modules - try to remove modules. modules with a (* bugpoint_keep *) attribute - will be skipped. - - -ports - try to remove module ports. ports with a (* bugpoint_keep *) attribute - will be skipped (useful for clocks, resets, etc.) - - -cells - try to remove cells. cells with a (* bugpoint_keep *) attribute will - be skipped. - - -connections - try to reconnect ports to 'x. - - -processes - try to remove processes. processes with a (* bugpoint_keep *) attribute - will be skipped. - - -assigns - try to remove process assigns from cases. - - -updates - try to remove process updates from syncs. - - -runner "<prefix>" - child process wrapping command, e.g., "timeout 30", or valgrind. -\end{lstlisting} - -\section{cd -- a shortcut for 'select -module <name>'} -\label{cmd:cd} -\begin{lstlisting}[numbers=left,frame=single] - cd <modname> - -This is just a shortcut for 'select -module <modname>'. - - - cd <cellname> - -When no module with the specified name is found, but there is a cell -with the specified name in the current module, then this is equivalent -to 'cd <celltype>'. - - - cd .. - -Remove trailing substrings that start with '.' in current module name until -the name of a module in the current design is generated, then switch to that -module. Otherwise clear the current selection. - - - cd - -This is just a shortcut for 'select -clear'. -\end{lstlisting} - -\section{check -- check for obvious problems in the design} -\label{cmd:check} -\begin{lstlisting}[numbers=left,frame=single] - check [options] [selection] - -This pass identifies the following problems in the current design: - - - combinatorial loops - - two or more conflicting drivers for one wire - - used wires that do not have a driver - -Options: - - -noinit - also check for wires which have the 'init' attribute set - - -initdrv - also check for wires that have the 'init' attribute set and are not - driven by an FF cell type - - -mapped - also check for internal cells that have not been mapped to cells of the - target architecture - - -allow-tbuf - modify the -mapped behavior to still allow $_TBUF_ cells - - -assert - produce a runtime error if any problems are found in the current design -\end{lstlisting} - -\section{chformal -- change formal constraints of the design} -\label{cmd:chformal} -\begin{lstlisting}[numbers=left,frame=single] - chformal [types] [mode] [options] [selection] - -Make changes to the formal constraints of the design. The [types] options -the type of constraint to operate on. If none of the following options are -given, the command will operate on all constraint types: - - -assert $assert cells, representing assert(...) constraints - -assume $assume cells, representing assume(...) constraints - -live $live cells, representing assert(s_eventually ...) - -fair $fair cells, representing assume(s_eventually ...) - -cover $cover cells, representing cover() statements - -Exactly one of the following modes must be specified: - - -remove - remove the cells and thus constraints from the design - - -early - bypass FFs that only delay the activation of a constraint - - -delay <N> - delay activation of the constraint by <N> clock cycles - - -skip <N> - ignore activation of the constraint in the first <N> clock cycles - - -assert2assume - -assume2assert - -live2fair - -fair2live - change the roles of cells as indicated. these options can be combined -\end{lstlisting} - -\section{chparam -- re-evaluate modules with new parameters} -\label{cmd:chparam} -\begin{lstlisting}[numbers=left,frame=single] - chparam [ -set name value ]... [selection] - -Re-evaluate the selected modules with new parameters. String values must be -passed in double quotes ("). - - - chparam -list [selection] - -List the available parameters of the selected modules. -\end{lstlisting} - -\section{chtype -- change type of cells in the design} -\label{cmd:chtype} -\begin{lstlisting}[numbers=left,frame=single] - chtype [options] [selection] - -Change the types of cells in the design. - - -set <type> - set the cell type to the given type - - -map <old_type> <new_type> - change cells types that match <old_type> to <new_type> -\end{lstlisting} - -\section{clean -- remove unused cells and wires} -\label{cmd:clean} -\begin{lstlisting}[numbers=left,frame=single] - clean [options] [selection] - -This is identical to 'opt_clean', but less verbose. - -When commands are separated using the ';;' token, this command will be executed -between the commands. - -When commands are separated using the ';;;' token, this command will be executed -in -purge mode between the commands. -\end{lstlisting} - -\section{clean\_zerowidth -- clean zero-width connections from the design} -\label{cmd:clean_zerowidth} -\begin{lstlisting}[numbers=left,frame=single] - clean_zerowidth [selection] - -Fixes the selected cells and processes to contain no zero-width connections. -Depending on the cell type, this may be implemented by removing the connection, -widening it to 1-bit, or removing the cell altogether. -\end{lstlisting} - -\section{clk2fflogic -- convert clocked FFs to generic \$ff cells} -\label{cmd:clk2fflogic} -\begin{lstlisting}[numbers=left,frame=single] - clk2fflogic [options] [selection] - -This command replaces clocked flip-flops with generic $ff cells that use the -implicit global clock. This is useful for formal verification of designs with -multiple clocks. - -This pass assumes negative hold time for the async FF inputs. For example when -a reset deasserts with the clock edge, then the FF output will still drive the -reset value in the next cycle regardless of the data-in value at the time of -the clock edge. -\end{lstlisting} - -\section{clkbufmap -- insert clock buffers on clock networks} -\label{cmd:clkbufmap} -\begin{lstlisting}[numbers=left,frame=single] - clkbufmap [options] [selection] - -Inserts clock buffers between nets connected to clock inputs and their drivers. - -In the absence of any selection, all wires without the 'clkbuf_inhibit' -attribute will be considered for clock buffer insertion. -Alternatively, to consider all wires without the 'buffer_type' attribute set to -'none' or 'bufr' one would specify: - 'w:* a:buffer_type=none a:buffer_type=bufr %u %d' -as the selection. - - -buf <celltype> <portname_out>:<portname_in> - Specifies the cell type to use for the clock buffers - and its port names. The first port will be connected to - the clock network sinks, and the second will be connected - to the actual clock source. - - -inpad <celltype> <portname_out>:<portname_in> - If specified, a PAD cell of the given type is inserted on - clock nets that are also top module's inputs (in addition - to the clock buffer, if any). - -At least one of -buf or -inpad should be specified. -\end{lstlisting} - -\section{connect -- create or remove connections} -\label{cmd:connect} -\begin{lstlisting}[numbers=left,frame=single] - connect [-nomap] [-nounset] -set <lhs-expr> <rhs-expr> - -Create a connection. This is equivalent to adding the statement 'assign -<lhs-expr> = <rhs-expr>;' to the Verilog input. Per default, all existing -drivers for <lhs-expr> are unconnected. This can be overwritten by using -the -nounset option. - - - connect [-nomap] -unset <expr> - -Unconnect all existing drivers for the specified expression. - - - connect [-nomap] [-assert] -port <cell> <port> <expr> - -Connect the specified cell port to the specified cell port. - - -Per default signal alias names are resolved and all signal names are mapped -the the signal name of the primary driver. Using the -nomap option deactivates -this behavior. - -The connect command operates in one module only. Either only one module must -be selected or an active module must be set using the 'cd' command. - -The -assert option verifies that the connection already exists, instead of -making it. - -This command does not operate on module with processes. -\end{lstlisting} - -\section{connect\_rpc -- connect to RPC frontend} -\label{cmd:connect_rpc} -\begin{lstlisting}[numbers=left,frame=single] - connect_rpc -exec <command> [args...] - connect_rpc -path <path> - -Load modules using an out-of-process frontend. - - -exec <command> [args...] - run <command> with arguments [args...]. send requests on stdin, read - responses from stdout. - - -path <path> - connect to Unix domain socket at <path>. (Unix) - connect to bidirectional byte-type named pipe at <path>. (Windows) - -A simple JSON-based, newline-delimited protocol is used for communicating with -the frontend. Yosys requests data from the frontend by sending exactly 1 line -of JSON. Frontend responds with data or error message by replying with exactly -1 line of JSON as well. - - -> {"method": "modules"} - <- {"modules": ["<module-name>", ...]} - <- {"error": "<error-message>"} - request for the list of modules that can be derived by this frontend. - the 'hierarchy' command will call back into this frontend if a cell - with type <module-name> is instantiated in the design. - - -> {"method": "derive", "module": "<module-name">, "parameters": { - "<param-name>": {"type": "[unsigned|signed|string|real]", - "value": "<param-value>"}, ...}} - <- {"frontend": "[rtlil|verilog|...]","source": "<source>"}} - <- {"error": "<error-message>"} - request for the module <module-name> to be derived for a specific set of - parameters. <param-name> starts with \ for named parameters, and with $ - for unnamed parameters, which are numbered starting at 1.<param-value> - for integer parameters is always specified as a binary string of - unlimited precision. the <source> returned by the frontend is - hygienically parsedby a built-in Yosys <frontend>, allowing the RPC - frontend to return anyconvenient representation of the module. the - derived module is cached,so the response should be the same whenever the - same set of parameters is provided. -\end{lstlisting} - -\section{connwrappers -- match width of input-output port pairs} -\label{cmd:connwrappers} -\begin{lstlisting}[numbers=left,frame=single] - connwrappers [options] [selection] - -Wrappers are used in coarse-grain synthesis to wrap cells with smaller ports -in wrapper cells with a (larger) constant port size. I.e. the upper bits -of the wrapper output are signed/unsigned bit extended. This command uses this -knowledge to rewire the inputs of the driven cells to match the output of -the driving cell. - - -signed <cell_type> <port_name> <width_param> - -unsigned <cell_type> <port_name> <width_param> - consider the specified signed/unsigned wrapper output - - -port <cell_type> <port_name> <width_param> <sign_param> - use the specified parameter to decide if signed or unsigned - -The options -signed, -unsigned, and -port can be specified multiple times. -\end{lstlisting} - -\section{coolrunner2\_fixup -- insert necessary buffer cells for CoolRunner-II architecture} -\label{cmd:coolrunner2_fixup} -\begin{lstlisting}[numbers=left,frame=single] - coolrunner2_fixup [options] [selection] - -Insert necessary buffer cells for CoolRunner-II architecture. -\end{lstlisting} - -\section{coolrunner2\_sop -- break \$sop cells into ANDTERM/ORTERM cells} -\label{cmd:coolrunner2_sop} -\begin{lstlisting}[numbers=left,frame=single] - coolrunner2_sop [options] [selection] - -Break $sop cells into ANDTERM/ORTERM cells. -\end{lstlisting} - -\section{copy -- copy modules in the design} -\label{cmd:copy} -\begin{lstlisting}[numbers=left,frame=single] - copy old_name new_name - -Copy the specified module. Note that selection patterns are not supported -by this command. -\end{lstlisting} - -\section{cover -- print code coverage counters} -\label{cmd:cover} -\begin{lstlisting}[numbers=left,frame=single] - cover [options] [pattern] - -Print the code coverage counters collected using the cover() macro in the Yosys -C++ code. This is useful to figure out what parts of Yosys are utilized by a -test bench. - - -q - Do not print output to the normal destination (console and/or log file) - - -o file - Write output to this file, truncate if exists. - - -a file - Write output to this file, append if exists. - - -d dir - Write output to a newly created file in the specified directory. - -When one or more pattern (shell wildcards) are specified, then only counters -matching at least one pattern are printed. - - -It is also possible to instruct Yosys to print the coverage counters on program -exit to a file using environment variables: - - YOSYS_COVER_DIR="{dir-name}" yosys {args} - - This will create a file (with an auto-generated name) in this - directory and write the coverage counters to it. - - YOSYS_COVER_FILE="{file-name}" yosys {args} - - This will append the coverage counters to the specified file. - - -Hint: Use the following AWK command to consolidate Yosys coverage files: - - gawk '{ p[$3] = $1; c[$3] += $2; } END { for (i in p) - printf "%-60s %10d %s\n", p[i], c[i], i; }' {files} | sort -k3 - - -Coverage counters are only available in Yosys for Linux. -\end{lstlisting} - -\section{cutpoint -- adds formal cut points to the design} -\label{cmd:cutpoint} -\begin{lstlisting}[numbers=left,frame=single] - cutpoint [options] [selection] - -This command adds formal cut points to the design. - - -undef - set cupoint nets to undef (x). the default behavior is to create a - $anyseq cell and drive the cutpoint net from that -\end{lstlisting} - -\section{debug -- run command with debug log messages enabled} -\label{cmd:debug} -\begin{lstlisting}[numbers=left,frame=single] - debug cmd - -Execute the specified command with debug log messages enabled -\end{lstlisting} - -\section{delete -- delete objects in the design} -\label{cmd:delete} -\begin{lstlisting}[numbers=left,frame=single] - delete [selection] - -Deletes the selected objects. This will also remove entire modules, if the -whole module is selected. - - - delete {-input|-output|-port} [selection] - -Does not delete any object but removes the input and/or output flag on the -selected wires, thus 'deleting' module ports. -\end{lstlisting} - -\section{deminout -- demote inout ports to input or output} -\label{cmd:deminout} -\begin{lstlisting}[numbers=left,frame=single] - deminout [options] [selection] - -"Demote" inout ports to input or output ports, if possible. -\end{lstlisting} - -\section{demuxmap -- transform \$demux cells to \$eq + \$mux cells} -\label{cmd:demuxmap} -\begin{lstlisting}[numbers=left,frame=single] - demuxmap [selection] - -This pass transforms $demux cells to a bunch of equality comparisons. -\end{lstlisting} - -\section{design -- save, restore and reset current design} -\label{cmd:design} -\begin{lstlisting}[numbers=left,frame=single] - design -reset - -Clear the current design. - - - design -save <name> - -Save the current design under the given name. - - - design -stash <name> - -Save the current design under the given name and then clear the current design. - - - design -push - -Push the current design to the stack and then clear the current design. - - - design -push-copy - -Push the current design to the stack without clearing the current design. - - - design -pop - -Reset the current design and pop the last design from the stack. - - - design -load <name> - -Reset the current design and load the design previously saved under the given -name. - - - design -copy-from <name> [-as <new_mod_name>] <selection> - -Copy modules from the specified design into the current one. The selection is -evaluated in the other design. - - - design -copy-to <name> [-as <new_mod_name>] [selection] - -Copy modules from the current design into the specified one. - - - design -import <name> [-as <new_top_name>] [selection] - -Import the specified design into the current design. The source design must -either have a selected top module or the selection must contain exactly one -module that is then used as top module for this command. - - - design -reset-vlog - -The Verilog front-end remembers defined macros and top-level declarations -between calls to 'read_verilog'. This command resets this memory. - - design -delete <name> - -Delete the design previously saved under the given name. -\end{lstlisting} - -\section{dffinit -- set INIT param on FF cells} -\label{cmd:dffinit} -\begin{lstlisting}[numbers=left,frame=single] - dffinit [options] [selection] - -This pass sets an FF cell parameter to the the initial value of the net it -drives. (This is primarily used in FPGA flows.) - - -ff <cell_name> <output_port> <init_param> - operate on the specified cell type. this option can be used - multiple times. - - -highlow - use the string values "high" and "low" to represent a single-bit - initial value of 1 or 0. (multi-bit values are not supported in this - mode.) - - -strinit <string for high> <string for low> - use string values in the command line to represent a single-bit - initial value of 1 or 0. (multi-bit values are not supported in this - mode.) - - -noreinit - fail if the FF cell has already a defined initial value set in other - passes and the initial value of the net it drives is not equal to - the already defined initial value. -\end{lstlisting} - -\section{dfflegalize -- convert FFs to types supported by the target} -\label{cmd:dfflegalize} -\begin{lstlisting}[numbers=left,frame=single] - dfflegalize [options] [selection] - -Converts FFs to types supported by the target. - - -cell <cell_type_pattern> <init_values> - specifies a supported group of FF cells. <cell_type_pattern> - is a yosys internal fine cell name, where ? characters can be - as a wildcard matching any character. <init_values> specifies - which initialization values these FF cells can support, and can - be one of: - - - x (no init value supported) - - 0 - - 1 - - r (init value has to match reset value, only for some FF types) - - 01 (both 0 and 1 supported). - - -mince <num> - specifies a minimum number of FFs that should be using any given - clock enable signal. If a clock enable signal doesn't meet this - threshold, it is unmapped into soft logic. - - -minsrst <num> - specifies a minimum number of FFs that should be using any given - sync set/reset signal. If a sync set/reset signal doesn't meet this - threshold, it is unmapped into soft logic. - -The following cells are supported by this pass (ie. will be ingested, -and can be specified as allowed targets): - -- $_DFF_[NP]_ -- $_DFFE_[NP][NP]_ -- $_DFF_[NP][NP][01]_ -- $_DFFE_[NP][NP][01][NP]_ -- $_ALDFF_[NP][NP]_ -- $_ALDFFE_[NP][NP][NP]_ -- $_DFFSR_[NP][NP][NP]_ -- $_DFFSRE_[NP][NP][NP][NP]_ -- $_SDFF_[NP][NP][01]_ -- $_SDFFE_[NP][NP][01][NP]_ -- $_SDFFCE_[NP][NP][01][NP]_ -- $_SR_[NP][NP]_ -- $_DLATCH_[NP]_ -- $_DLATCH_[NP][NP][01]_ -- $_DLATCHSR_[NP][NP][NP]_ - -The following transformations are performed by this pass: - -- upconversion from a less capable cell to a more capable cell, if the less - capable cell is not supported (eg. dff -> dffe, or adff -> dffsr) -- unmapping FFs with clock enable (due to unsupported cell type or -mince) -- unmapping FFs with sync reset (due to unsupported cell type or -minsrst) -- adding inverters on the control pins (due to unsupported polarity) -- adding inverters on the D and Q pins and inverting the init/reset values - (due to unsupported init or reset value) -- converting sr into adlatch (by tying D to 1 and using E as set input) -- emulating unsupported dffsr cell by adff + adff + sr + mux -- emulating unsupported dlatchsr cell by adlatch + adlatch + sr + mux -- emulating adff when the (reset, init) value combination is unsupported by - dff + adff + dlatch + mux -- emulating adlatch when the (reset, init) value combination is unsupported by -- dlatch + adlatch + dlatch + mux -If the pass is unable to realize a given cell type (eg. adff when only plain dff -is available), an error is raised. -\end{lstlisting} - -\section{dfflibmap -- technology mapping of flip-flops} -\label{cmd:dfflibmap} -\begin{lstlisting}[numbers=left,frame=single] - dfflibmap [-prepare] [-map-only] [-info] -liberty <file> [selection] - -Map internal flip-flop cells to the flip-flop cells in the technology -library specified in the given liberty file. - -This pass may add inverters as needed. Therefore it is recommended to -first run this pass and then map the logic paths to the target technology. - -When called with -prepare, this command will convert the internal FF cells -to the internal cell types that best match the cells found in the given -liberty file, but won't actually map them to the target cells. - -When called with -map-only, this command will only map internal cell -types that are already of exactly the right type to match the target -cells, leaving remaining internal cells untouched. - -When called with -info, this command will only print the target cell -list, along with their associated internal cell types, and the arguments -that would be passed to the dfflegalize pass. The design will not be -changed. -\end{lstlisting} - -\section{dffunmap -- unmap clock enable and synchronous reset from FFs} -\label{cmd:dffunmap} -\begin{lstlisting}[numbers=left,frame=single] - dffunmap [options] [selection] - -This pass transforms FF types with clock enable and/or synchronous reset into -their base type (with neither clock enable nor sync reset) by emulating the -clock enable and synchronous reset with multiplexers on the cell input. - - -ce-only - unmap only clock enables, leave synchronous resets alone. - - -srst-only - unmap only synchronous resets, leave clock enables alone. -\end{lstlisting} - -\section{dump -- print parts of the design in RTLIL format} -\label{cmd:dump} -\begin{lstlisting}[numbers=left,frame=single] - dump [options] [selection] - -Write the selected parts of the design to the console or specified file in -RTLIL format. - - -m - also dump the module headers, even if only parts of a single - module is selected - - -n - only dump the module headers if the entire module is selected - - -o <filename> - write to the specified file. - - -a <filename> - like -outfile but append instead of overwrite -\end{lstlisting} - -\section{echo -- turning echoing back of commands on and off} -\label{cmd:echo} -\begin{lstlisting}[numbers=left,frame=single] - echo on - -Print all commands to log before executing them. - - - echo off - -Do not print all commands to log before executing them. (default) -\end{lstlisting} - -\section{ecp5\_gsr -- ECP5: handle GSR} -\label{cmd:ecp5_gsr} -\begin{lstlisting}[numbers=left,frame=single] - ecp5_gsr [options] [selection] - -Trim active low async resets connected to GSR and resolve GSR parameter, -if a GSR or SGSR primitive is used in the design. - -If any cell has the GSR parameter set to "AUTO", this will be resolved -to "ENABLED" if a GSR primitive is present and the (* nogsr *) attribute -is not set, otherwise it will be resolved to "DISABLED". -\end{lstlisting} - -\section{edgetypes -- list all types of edges in selection} -\label{cmd:edgetypes} -\begin{lstlisting}[numbers=left,frame=single] - edgetypes [options] [selection] - -This command lists all unique types of 'edges' found in the selection. An 'edge' -is a 4-tuple of source and sink cell type and port name. -\end{lstlisting} - -\section{efinix\_fixcarry -- Efinix: fix carry chain} -\label{cmd:efinix_fixcarry} -\begin{lstlisting}[numbers=left,frame=single] - efinix_fixcarry [options] [selection] - -Add Efinix adders to fix carry chain if needed. -\end{lstlisting} - -\section{equiv\_add -- add a \$equiv cell} -\label{cmd:equiv_add} -\begin{lstlisting}[numbers=left,frame=single] - equiv_add [-try] gold_sig gate_sig - -This command adds an $equiv cell for the specified signals. - - - equiv_add [-try] -cell gold_cell gate_cell - -This command adds $equiv cells for the ports of the specified cells. -\end{lstlisting} - -\section{equiv\_induct -- proving \$equiv cells using temporal induction} -\label{cmd:equiv_induct} -\begin{lstlisting}[numbers=left,frame=single] - equiv_induct [options] [selection] - -Uses a version of temporal induction to prove $equiv cells. - -Only selected $equiv cells are proven and only selected cells are used to -perform the proof. - - -undef - enable modelling of undef states - - -seq <N> - the max. number of time steps to be considered (default = 4) - -This command is very effective in proving complex sequential circuits, when -the internal state of the circuit quickly propagates to $equiv cells. - -However, this command uses a weak definition of 'equivalence': This command -proves that the two circuits will not diverge after they produce equal -outputs (observable points via $equiv) for at least <N> cycles (the <N> -specified via -seq). - -Combined with simulation this is very powerful because simulation can give -you confidence that the circuits start out synced for at least <N> cycles -after reset. -\end{lstlisting} - -\section{equiv\_make -- prepare a circuit for equivalence checking} -\label{cmd:equiv_make} -\begin{lstlisting}[numbers=left,frame=single] - equiv_make [options] gold_module gate_module equiv_module - -This creates a module annotated with $equiv cells from two presumably -equivalent modules. Use commands such as 'equiv_simple' and 'equiv_status' -to work with the created equivalent checking module. - - -inames - Also match cells and wires with $... names. - - -blacklist <file> - Do not match cells or signals that match the names in the file. - - -encfile <file> - Match FSM encodings using the description from the file. - See 'help fsm_recode' for details. - -Note: The circuit created by this command is not a miter (with something like -a trigger output), but instead uses $equiv cells to encode the equivalence -checking problem. Use 'miter -equiv' if you want to create a miter circuit. -\end{lstlisting} - -\section{equiv\_mark -- mark equivalence checking regions} -\label{cmd:equiv_mark} -\begin{lstlisting}[numbers=left,frame=single] - equiv_mark [options] [selection] - -This command marks the regions in an equivalence checking module. Region 0 is -the proven part of the circuit. Regions with higher numbers are connected -unproven subcricuits. The integer attribute 'equiv_region' is set on all -wires and cells. -\end{lstlisting} - -\section{equiv\_miter -- extract miter from equiv circuit} -\label{cmd:equiv_miter} -\begin{lstlisting}[numbers=left,frame=single] - equiv_miter [options] miter_module [selection] - -This creates a miter module for further analysis of the selected $equiv cells. - - -trigger - Create a trigger output - - -cmp - Create cmp_* outputs for individual unproven $equiv cells - - -assert - Create a $assert cell for each unproven $equiv cell - - -undef - Create compare logic that handles undefs correctly -\end{lstlisting} - -\section{equiv\_opt -- prove equivalence for optimized circuit} -\label{cmd:equiv_opt} -\begin{lstlisting}[numbers=left,frame=single] - equiv_opt [options] [command] - -This command uses temporal induction to check circuit equivalence before and -after an optimization pass. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to the start of the command list, and empty to - label is synonymous to the end of the command list. - - -map <filename> - expand the modules in this file before proving equivalence. this is - useful for handling architecture-specific primitives. - - -blacklist <file> - Do not match cells or signals that match the names in the file - (passed to equiv_make). - - -assert - produce an error if the circuits are not equivalent. - - -multiclock - run clk2fflogic before equivalence checking. - - -async2sync - run async2sync before equivalence checking. - - -undef - enable modelling of undef states during equiv_induct. - - -nocheck - disable running check before and after the command under test. - -The following commands are executed by this verification command: - - run_pass: - hierarchy -auto-top - design -save preopt - check -assert (unless -nocheck) - [command] - check -assert (unless -nocheck) - design -stash postopt - - prepare: - design -copy-from preopt -as gold A:top - design -copy-from postopt -as gate A:top - - techmap: (only with -map) - techmap -wb -D EQUIV -autoproc -map <filename> ... - - prove: - clk2fflogic (only with -multiclock) - async2sync (only with -async2sync) - equiv_make -blacklist <filename> ... gold gate equiv - equiv_induct [-undef] equiv - equiv_status [-assert] equiv - - restore: - design -load preopt -\end{lstlisting} - -\section{equiv\_purge -- purge equivalence checking module} -\label{cmd:equiv_purge} -\begin{lstlisting}[numbers=left,frame=single] - equiv_purge [options] [selection] - -This command removes the proven part of an equivalence checking module, leaving -only the unproven segments in the design. This will also remove and add module -ports as needed. -\end{lstlisting} - -\section{equiv\_remove -- remove \$equiv cells} -\label{cmd:equiv_remove} -\begin{lstlisting}[numbers=left,frame=single] - equiv_remove [options] [selection] - -This command removes the selected $equiv cells. If neither -gold nor -gate is -used then only proven cells are removed. - - -gold - keep gold circuit - - -gate - keep gate circuit -\end{lstlisting} - -\section{equiv\_simple -- try proving simple \$equiv instances} -\label{cmd:equiv_simple} -\begin{lstlisting}[numbers=left,frame=single] - equiv_simple [options] [selection] - -This command tries to prove $equiv cells using a simple direct SAT approach. - - -v - verbose output - - -undef - enable modelling of undef states - - -short - create shorter input cones that stop at shared nodes. This yields - simpler SAT problems but sometimes fails to prove equivalence. - - -nogroup - disabling grouping of $equiv cells by output wire - - -seq <N> - the max. number of time steps to be considered (default = 1) -\end{lstlisting} - -\section{equiv\_status -- print status of equivalent checking module} -\label{cmd:equiv_status} -\begin{lstlisting}[numbers=left,frame=single] - equiv_status [options] [selection] - -This command prints status information for all selected $equiv cells. - - -assert - produce an error if any unproven $equiv cell is found -\end{lstlisting} - -\section{equiv\_struct -- structural equivalence checking} -\label{cmd:equiv_struct} -\begin{lstlisting}[numbers=left,frame=single] - equiv_struct [options] [selection] - -This command adds additional $equiv cells based on the assumption that the -gold and gate circuit are structurally equivalent. Note that this can introduce -bad $equiv cells in cases where the netlists are not structurally equivalent, -for example when analyzing circuits with cells with commutative inputs. This -command will also de-duplicate gates. - - -fwd - by default this command performans forward sweeps until nothing can - be merged by forwards sweeps, then backward sweeps until forward - sweeps are effective again. with this option set only forward sweeps - are performed. - - -fwonly <cell_type> - add the specified cell type to the list of cell types that are only - merged in forward sweeps and never in backward sweeps. $equiv is in - this list automatically. - - -icells - by default, the internal RTL and gate cell types are ignored. add - this option to also process those cell types with this command. - - -maxiter <N> - maximum number of iterations to run before aborting -\end{lstlisting} - -\section{eval -- evaluate the circuit given an input} -\label{cmd:eval} -\begin{lstlisting}[numbers=left,frame=single] - eval [options] [selection] - -This command evaluates the value of a signal given the value of all required -inputs. - - -set <signal> <value> - set the specified signal to the specified value. - - -set-undef - set all unspecified source signals to undef (x) - - -table <signal> - create a truth table using the specified input signals - - -show <signal> - show the value for the specified signal. if no -show option is passed - then all output ports of the current module are used. -\end{lstlisting} - -\section{exec -- execute commands in the operating system shell} -\label{cmd:exec} -\begin{lstlisting}[numbers=left,frame=single] - exec [options] -- [command] - -Execute a command in the operating system shell. All supplied arguments are -concatenated and passed as a command to popen(3). Whitespace is not guaranteed -to be preserved, even if quoted. stdin and stderr are not connected, while -stdout is logged unless the "-q" option is specified. - - - -q - Suppress stdout and stderr from subprocess - - -expect-return <int> - Generate an error if popen() does not return specified value. - May only be specified once; the final specified value is controlling - if specified multiple times. - - -expect-stdout <regex> - Generate an error if the specified regex does not match any line - in subprocess's stdout. May be specified multiple times. - - -not-expect-stdout <regex> - Generate an error if the specified regex matches any line - in subprocess's stdout. May be specified multiple times. - - - Example: exec -q -expect-return 0 -- echo "bananapie" | grep "nana" -\end{lstlisting} - -\section{expose -- convert internal signals to module ports} -\label{cmd:expose} -\begin{lstlisting}[numbers=left,frame=single] - expose [options] [selection] - -This command exposes all selected internal signals of a module as additional -outputs. - - -dff - only consider wires that are directly driven by register cell. - - -cut - when exposing a wire, create an input/output pair and cut the internal - signal path at that wire. - - -input - when exposing a wire, create an input port and disconnect the internal - driver. - - -shared - only expose those signals that are shared among the selected modules. - this is useful for preparing modules for equivalence checking. - - -evert - also turn connections to instances of other modules to additional - inputs and outputs and remove the module instances. - - -evert-dff - turn flip-flops to sets of inputs and outputs. - - -sep <separator> - when creating new wire/port names, the original object name is suffixed - with this separator (default: '.') and the port name or a type - designator for the exposed signal. -\end{lstlisting} - -\section{extract -- find subcircuits and replace them with cells} -\label{cmd:extract} -\begin{lstlisting}[numbers=left,frame=single] - extract -map <map_file> [options] [selection] - extract -mine <out_file> [options] [selection] - -This pass looks for subcircuits that are isomorphic to any of the modules -in the given map file and replaces them with instances of this modules. The -map file can be a Verilog source file (*.v) or an RTLIL source file (*.il). - - -map <map_file> - use the modules in this file as reference. This option can be used - multiple times. - - -map %<design-name> - use the modules in this in-memory design as reference. This option can - be used multiple times. - - -verbose - print debug output while analyzing - - -constports - also find instances with constant drivers. this may be much - slower than the normal operation. - - -nodefaultswaps - normally builtin port swapping rules for internal cells are used per - default. This turns that off, so e.g. 'a^b' does not match 'b^a' - when this option is used. - - -compat <needle_type> <haystack_type> - Per default, the cells in the map file (needle) must have the - type as the cells in the active design (haystack). This option - can be used to register additional pairs of types that should - match. This option can be used multiple times. - - -swap <needle_type> <port1>,<port2>[,...] - Register a set of swappable ports for a needle cell type. - This option can be used multiple times. - - -perm <needle_type> <port1>,<port2>[,...] <portA>,<portB>[,...] - Register a valid permutation of swappable ports for a needle - cell type. This option can be used multiple times. - - -cell_attr <attribute_name> - Attributes on cells with the given name must match. - - -wire_attr <attribute_name> - Attributes on wires with the given name must match. - - -ignore_parameters - Do not use parameters when matching cells. - - -ignore_param <cell_type> <parameter_name> - Do not use this parameter when matching cells. - -This pass does not operate on modules with unprocessed processes in it. -(I.e. the 'proc' pass should be used first to convert processes to netlists.) - -This pass can also be used for mining for frequent subcircuits. In this mode -the following options are to be used instead of the -map option. - - -mine <out_file> - mine for frequent subcircuits and write them to the given RTLIL file - - -mine_cells_span <min> <max> - only mine for subcircuits with the specified number of cells - default value: 3 5 - - -mine_min_freq <num> - only mine for subcircuits with at least the specified number of matches - default value: 10 - - -mine_limit_matches_per_module <num> - when calculating the number of matches for a subcircuit, don't count - more than the specified number of matches per module - - -mine_max_fanout <num> - don't consider internal signals with more than <num> connections - -The modules in the map file may have the attribute 'extract_order' set to an -integer value. Then this value is used to determine the order in which the pass -tries to map the modules to the design (ascending, default value is 0). - -See 'help techmap' for a pass that does the opposite thing. -\end{lstlisting} - -\section{extract\_counter -- Extract GreenPak4 counter cells} -\label{cmd:extract_counter} -\begin{lstlisting}[numbers=left,frame=single] - extract_counter [options] [selection] - -This pass converts non-resettable or async resettable down counters to -counter cells. Use a target-specific 'techmap' map file to convert those cells -to the actual target cells. - - -maxwidth N - Only extract counters up to N bits wide (default 64) - - -minwidth N - Only extract counters at least N bits wide (default 2) - - -allow_arst yes|no - Allow counters to have async reset (default yes) - - -dir up|down|both - Look for up-counters, down-counters, or both (default down) - - -pout X,Y,... - Only allow parallel output from the counter to the listed cell types - (if not specified, parallel outputs are not restricted) -\end{lstlisting} - -\section{extract\_fa -- find and extract full/half adders} -\label{cmd:extract_fa} -\begin{lstlisting}[numbers=left,frame=single] - extract_fa [options] [selection] - -This pass extracts full/half adders from a gate-level design. - - -fa, -ha - Enable cell types (fa=full adder, ha=half adder) - All types are enabled if none of this options is used - - -d <int> - Set maximum depth for extracted logic cones (default=20) - - -b <int> - Set maximum breadth for extracted logic cones (default=6) - - -v - Verbose output -\end{lstlisting} - -\section{extract\_reduce -- converts gate chains into \$reduce\_* cells} -\label{cmd:extract_reduce} -\begin{lstlisting}[numbers=left,frame=single] - extract_reduce [options] [selection] - -converts gate chains into $reduce_* cells - -This command finds chains of $_AND_, $_OR_, and $_XOR_ cells and replaces them -with their corresponding $reduce_* cells. Because this command only operates on -these cell types, it is recommended to map the design to only these cell types -using the `abc -g` command. Note that, in some cases, it may be more effective -to map the design to only $_AND_ cells, run extract_reduce, map the remaining -parts of the design to AND/OR/XOR cells, and run extract_reduce a second time. - - -allow-off-chain - Allows matching of cells that have loads outside the chain. These cells - will be replicated and folded into the $reduce_* cell, but the original - cell will remain, driving its original loads. -\end{lstlisting} - -\section{extractinv -- extract explicit inverter cells for invertible cell pins} -\label{cmd:extractinv} -\begin{lstlisting}[numbers=left,frame=single] - extractinv [options] [selection] - -Searches the design for all cells with invertible pins controlled by a cell -parameter (eg. IS_CLK_INVERTED on many Xilinx cells) and removes the parameter. -If the parameter was set to 1, inserts an explicit inverter cell in front of -the pin instead. Normally used for output to ISE, which does not support the -inversion parameters. - -To mark a cell port as invertible, use (* invertible_pin = "param_name" *) -on the wire in the blackbox module. The parameter value should have -the same width as the port, and will be effectively XORed with it. - - -inv <celltype> <portname_out>:<portname_in> - Specifies the cell type to use for the inverters and its port names. - This option is required. -\end{lstlisting} - -\section{flatten -- flatten design} -\label{cmd:flatten} -\begin{lstlisting}[numbers=left,frame=single] - flatten [options] [selection] - -This pass flattens the design by replacing cells by their implementation. This -pass is very similar to the 'techmap' pass. The only difference is that this -pass is using the current design as mapping library. - -Cells and/or modules with the 'keep_hierarchy' attribute set will not be -flattened by this command. - - -wb - Ignore the 'whitebox' attribute on cell implementations. -\end{lstlisting} - -\section{flowmap -- pack LUTs with FlowMap} -\label{cmd:flowmap} -\begin{lstlisting}[numbers=left,frame=single] - flowmap [options] [selection] - -This pass uses the FlowMap technology mapping algorithm to pack logic gates -into k-LUTs with optimal depth. It allows mapping any circuit elements that can -be evaluated with the `eval` pass, including cells with multiple output ports -and multi-bit input and output ports. - - -maxlut k - perform technology mapping for a k-LUT architecture. if not specified, - defaults to 3. - - -minlut n - only produce n-input or larger LUTs. if not specified, defaults to 1. - - -cells <cell>[,<cell>,...] - map specified cells. if not specified, maps $_NOT_, $_AND_, $_OR_, - $_XOR_ and $_MUX_, which are the outputs of the `simplemap` pass. - - -relax - perform depth relaxation and area minimization. - - -r-alpha n, -r-beta n, -r-gamma n - parameters of depth relaxation heuristic potential function. - if not specified, alpha=8, beta=2, gamma=1. - - -optarea n - optimize for area by trading off at most n logic levels for fewer LUTs. - n may be zero, to optimize for area without increasing depth. - implies -relax. - - -debug - dump intermediate graphs. - - -debug-relax - explain decisions performed during depth relaxation. -\end{lstlisting} - -\section{fmcombine -- combine two instances of a cell into one} -\label{cmd:fmcombine} -\begin{lstlisting}[numbers=left,frame=single] - fmcombine [options] module_name gold_cell gate_cell - -This pass takes two cells, which are instances of the same module, and replaces -them with one instance of a special 'combined' module, that effectively -contains two copies of the original module, plus some formal properties. - -This is useful for formal test benches that check what differences in behavior -a slight difference in input causes in a module. - - -initeq - Insert assumptions that initially all FFs in both circuits have the - same initial values. - - -anyeq - Do not duplicate $anyseq/$anyconst cells. - - -fwd - Insert forward hint assumptions into the combined module. - - -bwd - Insert backward hint assumptions into the combined module. - (Backward hints are logically equivalend to fordward hits, but - some solvers are faster with bwd hints, or even both -bwd and -fwd.) - - -nop - Don't insert hint assumptions into the combined module. - (This should not provide any speedup over the original design, but - strangely sometimes it does.) - -If none of -fwd, -bwd, and -nop is given, then -fwd is used as default. -\end{lstlisting} - -\section{fminit -- set init values/sequences for formal} -\label{cmd:fminit} -\begin{lstlisting}[numbers=left,frame=single] - fminit [options] <selection> - -This pass creates init constraints (for example for reset sequences) in a formal -model. - - -seq <signal> <sequence> - Set sequence using comma-separated list of values, use 'z for - unconstrained bits. The last value is used for the remainder of the - trace. - - -set <signal> <value> - Add constant value constraint - - -posedge <signal> - -negedge <signal> - Set clock for init sequences -\end{lstlisting} - -\section{formalff -- prepare FFs for formal} -\label{cmd:formalff} -\begin{lstlisting}[numbers=left,frame=single] - formalff [options] [selection] - -This pass transforms clocked flip-flops to prepare a design for formal -verification. If a design contains latches and/or multiple different clocks run -the async2sync or clk2fflogic passes before using this pass. - - -clk2ff - Replace all clocked flip-flops with $ff cells that use the implicit - global clock. This assumes, without checking, that the design uses a - single global clock. If that is not the case, the clk2fflogic pass - should be used instead. - - -ff2anyinit - Replace uninitialized bits of $ff cells with $anyinit cells. An - $anyinit cell behaves exactly like an $ff cell with an undefined - initialization value. The difference is that $anyinit inhibits - don't-care optimizations and is used to track solver-provided values - in witness traces. - - If combined with -clk2ff this also affects newly created $ff cells. - - -anyinit2ff - Replaces $anyinit cells with uninitialized $ff cells. This performs the - reverse of -ff2anyinit and can be used, before running a backend pass - (or similar) that is not yet aware of $anyinit cells. - - Note that after running -anyinit2ff, in general, performing don't-care - optimizations is not sound in a formal verification setting. - - -fine - Emit fine-grained $_FF_ cells instead of coarse-grained $ff cells for - -anyinit2ff. Cannot be combined with -clk2ff or -ff2anyinit. - - -setundef - Find FFs with undefined initialization values for which changing the - initialization does not change the observable behavior and initialize - them. For -ff2anyinit, this reduces the number of generated $anyinit - cells that drive wires with private names. -\end{lstlisting} - -\section{freduce -- perform functional reduction} -\label{cmd:freduce} -\begin{lstlisting}[numbers=left,frame=single] - freduce [options] [selection] - -This pass performs functional reduction in the circuit. I.e. if two nodes are -equivalent, they are merged to one node and one of the redundant drivers is -disconnected. A subsequent call to 'clean' will remove the redundant drivers. - - -v, -vv - enable verbose or very verbose output - - -inv - enable explicit handling of inverted signals - - -stop <n> - stop after <n> reduction operations. this is mostly used for - debugging the freduce command itself. - - -dump <prefix> - dump the design to <prefix>_<module>_<num>.il after each reduction - operation. this is mostly used for debugging the freduce command. - -This pass is undef-aware, i.e. it considers don't-care values for detecting -equivalent nodes. - -All selected wires are considered for rewiring. The selected cells cover the -circuit that is analyzed. -\end{lstlisting} - -\section{fsm -- extract and optimize finite state machines} -\label{cmd:fsm} -\begin{lstlisting}[numbers=left,frame=single] - fsm [options] [selection] - -This pass calls all the other fsm_* passes in a useful order. This performs -FSM extraction and optimization. It also calls opt_clean as needed: - - fsm_detect unless got option -nodetect - fsm_extract - - fsm_opt - opt_clean - fsm_opt - - fsm_expand if got option -expand - opt_clean if got option -expand - fsm_opt if got option -expand - - fsm_recode unless got option -norecode - - fsm_info - - fsm_export if got option -export - fsm_map unless got option -nomap - -Options: - - -expand, -norecode, -export, -nomap - enable or disable passes as indicated above - - -fullexpand - call expand with -full option - - -encoding type - -fm_set_fsm_file file - -encfile file - passed through to fsm_recode pass - -This pass uses a subset of FF types to detect FSMs. Run 'opt -nosdff -nodffe' -before this pass to prepare the design. - -The Verific frontend may merge multiplexers in a way that interferes with FSM -detection. Run 'verific -cfg db_infer_wide_muxes_post_elaboration 0' before -reading the source, and 'bmuxmap' after 'proc' for best results. -\end{lstlisting} - -\section{fsm\_detect -- finding FSMs in design} -\label{cmd:fsm_detect} -\begin{lstlisting}[numbers=left,frame=single] - fsm_detect [selection] - -This pass detects finite state machines by identifying the state signal. -The state signal is then marked by setting the attribute 'fsm_encoding' -on the state signal to "auto". - -Existing 'fsm_encoding' attributes are not changed by this pass. - -Signals can be protected from being detected by this pass by setting the -'fsm_encoding' attribute to "none". - -This pass uses a subset of FF types to detect FSMs. Run 'opt -nosdff -nodffe' -before this pass to prepare the design for fsm_detect. - -The Verific frontend may merge multiplexers in a way that interferes with FSM -detection. Run 'verific -cfg db_infer_wide_muxes_post_elaboration 0' before -reading the source, and 'bmuxmap' after 'proc' for best results. -\end{lstlisting} - -\section{fsm\_expand -- expand FSM cells by merging logic into it} -\label{cmd:fsm_expand} -\begin{lstlisting}[numbers=left,frame=single] - fsm_expand [-full] [selection] - -The fsm_extract pass is conservative about the cells that belong to a finite -state machine. This pass can be used to merge additional auxiliary gates into -the finite state machine. - -By default, fsm_expand is still a bit conservative regarding merging larger -word-wide cells. Call with -full to consider all cells for merging. -\end{lstlisting} - -\section{fsm\_export -- exporting FSMs to KISS2 files} -\label{cmd:fsm_export} -\begin{lstlisting}[numbers=left,frame=single] - fsm_export [-noauto] [-o filename] [-origenc] [selection] - -This pass creates a KISS2 file for every selected FSM. For FSMs with the -'fsm_export' attribute set, the attribute value is used as filename, otherwise -the module and cell name is used as filename. If the parameter '-o' is given, -the first exported FSM is written to the specified filename. This overwrites -the setting as specified with the 'fsm_export' attribute. All other FSMs are -exported to the default name as mentioned above. - - -noauto - only export FSMs that have the 'fsm_export' attribute set - - -o filename - filename of the first exported FSM - - -origenc - use binary state encoding as state names instead of s0, s1, ... -\end{lstlisting} - -\section{fsm\_extract -- extracting FSMs in design} -\label{cmd:fsm_extract} -\begin{lstlisting}[numbers=left,frame=single] - fsm_extract [selection] - -This pass operates on all signals marked as FSM state signals using the -'fsm_encoding' attribute. It consumes the logic that creates the state signal -and uses the state signal to generate control signal and replaces it with an -FSM cell. - -The generated FSM cell still generates the original state signal with its -original encoding. The 'fsm_opt' pass can be used in combination with the -'opt_clean' pass to eliminate this signal. -\end{lstlisting} - -\section{fsm\_info -- print information on finite state machines} -\label{cmd:fsm_info} -\begin{lstlisting}[numbers=left,frame=single] - fsm_info [selection] - -This pass dumps all internal information on FSM cells. It can be useful for -analyzing the synthesis process and is called automatically by the 'fsm' -pass so that this information is included in the synthesis log file. -\end{lstlisting} - -\section{fsm\_map -- mapping FSMs to basic logic} -\label{cmd:fsm_map} -\begin{lstlisting}[numbers=left,frame=single] - fsm_map [selection] - -This pass translates FSM cells to flip-flops and logic. -\end{lstlisting} - -\section{fsm\_opt -- optimize finite state machines} -\label{cmd:fsm_opt} -\begin{lstlisting}[numbers=left,frame=single] - fsm_opt [selection] - -This pass optimizes FSM cells. It detects which output signals are actually -not used and removes them from the FSM. This pass is usually used in -combination with the 'opt_clean' pass (see also 'help fsm'). -\end{lstlisting} - -\section{fsm\_recode -- recoding finite state machines} -\label{cmd:fsm_recode} -\begin{lstlisting}[numbers=left,frame=single] - fsm_recode [options] [selection] - -This pass reassign the state encodings for FSM cells. At the moment only -one-hot encoding and binary encoding is supported. - -encoding <type> - specify the encoding scheme used for FSMs without the - 'fsm_encoding' attribute or with the attribute set to `auto'. - - -fm_set_fsm_file <file> - generate a file containing the mapping from old to new FSM encoding - in form of Synopsys Formality set_fsm_* commands. - - -encfile <file> - write the mappings from old to new FSM encoding to a file in the - following format: - - .fsm <module_name> <state_signal> - .map <old_bitpattern> <new_bitpattern> -\end{lstlisting} - -\section{fst2tb -- generate testbench out of fst file} -\label{cmd:fst2tb} -\begin{lstlisting}[numbers=left,frame=single] - fst2tb [options] [top-level] - -This command generates testbench for the circuit using the given top-level -module and simulus signal from FST file - - -tb <name> - generated testbench name. - files <name>.v and <name>.txt are created as result. - - -r <filename> - read simulation FST file - - -clock <portname> - name of top-level clock input - - -clockn <portname> - name of top-level clock input (inverse polarity) - - -scope <name> - scope of simulation top model - - -start <time> - start co-simulation in arbitary time (default 0) - - -stop <time> - stop co-simulation in arbitary time (default END) - - -n <integer> - number of clock cycles to simulate (default: 20) -\end{lstlisting} - -\section{gatemate\_foldinv -- fold inverters into Gatemate LUT trees} -\label{cmd:gatemate_foldinv} -\begin{lstlisting}[numbers=left,frame=single] - gatemate_foldinv [selection] - - -This pass searches for $__CC_NOT cells and folds them into CC_LUT2, CC_L2T4 -and CC_L2T5 cells as created by LUT tree mapping. -\end{lstlisting} - -\section{glift -- create GLIFT models and optimization problems} -\label{cmd:glift} -\begin{lstlisting}[numbers=left,frame=single] - glift <command> [options] [selection] - -Augments the current or specified module with gate-level information flow -tracking (GLIFT) logic using the "constructive mapping" approach. Also can set -up QBF-SAT optimization problems in order to optimize GLIFT models or trade off -precision and complexity. - - -Commands: - - -create-precise-model - Replaces the current or specified module with one that has corresponding - "taint" inputs, outputs, and internal nets along with precise taint - tracking logic. For example, precise taint tracking logic for an AND gate - is: - - y_t = a & b_t | b & a_t | a_t & b_t - - - -create-imprecise-model - Replaces the current or specified module with one that has corresponding - "taint" inputs, outputs, and internal nets along with imprecise "All OR" - taint tracking logic: - - y_t = a_t | b_t - - - -create-instrumented-model - Replaces the current or specified module with one that has corresponding - "taint" inputs, outputs, and internal nets along with 4 varying-precision - versions of taint tracking logic. Which version of taint tracking logic is - used for a given gate is determined by a MUX selected by an $anyconst cell. - By default, unless the `-no-cost-model` option is provided, an additional - wire named `__glift_weight` with the `keep` and `minimize` attributes is - added to the module along with pmuxes and adders to calculate a rough - estimate of the number of logic gates in the GLIFT model given an assignment - for the $anyconst cells. The four versions of taint tracking logic for an - AND gate are: - y_t = a & b_t | b & a_t | a_t & b_t (like `-create-precise-model`) - y_t = a_t | a & b_t - y_t = b_t | b & a_t - y_t = a_t | b_t (like `-create-imprecise-model`) - - -Options: - - -taint-constants - Constant values in the design are labeled as tainted. - (default: label constants as un-tainted) - - -keep-outputs - Do not remove module outputs. Taint tracking outputs will appear in the - module ports alongside the orignal outputs. - (default: original module outputs are removed) - - -simple-cost-model - Do not model logic area. Instead model the number of non-zero assignments to - $anyconsts. Taint tracking logic versions vary in their size, but all - reduced-precision versions are significantly smaller than the fully-precise - version. A non-zero $anyconst assignment means that reduced-precision taint - tracking logic was chosen for some gate. Only applicable in combination with - `-create-instrumented-model`. (default: use a complex model and give that - wire the "keep" and "minimize" attributes) - - -no-cost-model - Do not model taint tracking logic area and do not create a `__glift_weight` - wire. Only applicable in combination with `-create-instrumented-model`. - (default: model area and give that wire the "keep" and "minimize" - attributes) - - -instrument-more - Allow choice from more versions of (even simpler) taint tracking logic. A - total of 8 versions of taint tracking logic will be added per gate, - including the 4 versions from `-create-instrumented-model` and these - additional versions: - - y_t = a_t - y_t = b_t - y_t = 1 - y_t = 0 - - Only applicable in combination with `-create-instrumented-model`. - (default: do not add more versions of taint tracking logic. -\end{lstlisting} - -\section{greenpak4\_dffinv -- merge greenpak4 inverters and DFF/latches} -\label{cmd:greenpak4_dffinv} -\begin{lstlisting}[numbers=left,frame=single] - greenpak4_dffinv [options] [selection] - -Merge GP_INV cells with GP_DFF* and GP_DLATCH* cells. -\end{lstlisting} - -\section{help -- display help messages} -\label{cmd:help} -\begin{lstlisting}[numbers=left,frame=single] - help ................ list all commands - help <command> ...... print help message for given command - help -all ........... print complete command reference - - help -cells .......... list all cell types - help <celltype> ..... print help message for given cell type - help <celltype>+ .... print verilog code for given cell type -\end{lstlisting} - -\section{hierarchy -- check, expand and clean up design hierarchy} -\label{cmd:hierarchy} -\begin{lstlisting}[numbers=left,frame=single] - hierarchy [-check] [-top <module>] - hierarchy -generate <cell-types> <port-decls> - -In parametric designs, a module might exists in several variations with -different parameter values. This pass looks at all modules in the current -design and re-runs the language frontends for the parametric modules as -needed. It also resolves assignments to wired logic data types (wand/wor), -resolves positional module parameters, unrolls array instances, and more. - - -check - also check the design hierarchy. this generates an error when - an unknown module is used as cell type. - - -simcheck - like -check, but also throw an error if blackbox modules are - instantiated, and throw an error if the design has no top module. - - -smtcheck - like -simcheck, but allow smtlib2_module modules. - - -purge_lib - by default the hierarchy command will not remove library (blackbox) - modules. use this option to also remove unused blackbox modules. - - -libdir <directory> - search for files named <module_name>.v in the specified directory - for unknown modules and automatically run read_verilog for each - unknown module. - - -keep_positionals - per default this pass also converts positional arguments in cells - to arguments using port names. This option disables this behavior. - - -keep_portwidths - per default this pass adjusts the port width on cells that are - module instances when the width does not match the module port. This - option disables this behavior. - - -nodefaults - do not resolve input port default values - - -nokeep_asserts - per default this pass sets the "keep" attribute on all modules - that directly or indirectly contain one or more formal properties. - This option disables this behavior. - - -top <module> - use the specified top module to build the design hierarchy. Modules - outside this tree (unused modules) are removed. - - when the -top option is used, the 'top' attribute will be set on the - specified top module. otherwise a module with the 'top' attribute set - will implicitly be used as top module, if such a module exists. - - -auto-top - automatically determine the top of the design hierarchy and mark it. - - -chparam name value - elaborate the top module using this parameter value. Modules on which - this parameter does not exist may cause a warning message to be output. - This option can be specified multiple times to override multiple - parameters. String values must be passed in double quotes ("). - -In -generate mode this pass generates blackbox modules for the given cell -types (wildcards supported). For this the design is searched for cells that -match the given types and then the given port declarations are used to -determine the direction of the ports. The syntax for a port declaration is: - - {i|o|io}[@<num>]:<portname> - -Input ports are specified with the 'i' prefix, output ports with the 'o' -prefix and inout ports with the 'io' prefix. The optional <num> specifies -the position of the port in the parameter list (needed when instantiated -using positional arguments). When <num> is not specified, the <portname> can -also contain wildcard characters. - -This pass ignores the current selection and always operates on all modules -in the current design. -\end{lstlisting} - -\section{hilomap -- technology mapping of constant hi- and/or lo-drivers} -\label{cmd:hilomap} -\begin{lstlisting}[numbers=left,frame=single] - hilomap [options] [selection] - -Map constants to 'tielo' and 'tiehi' driver cells. - - -hicell <celltype> <portname> - Replace constant hi bits with this cell. - - -locell <celltype> <portname> - Replace constant lo bits with this cell. - - -singleton - Create only one hi/lo cell and connect all constant bits - to that cell. Per default a separate cell is created for - each constant bit. -\end{lstlisting} - -\section{history -- show last interactive commands} -\label{cmd:history} -\begin{lstlisting}[numbers=left,frame=single] - history - -This command prints all commands in the shell history buffer. This are -all commands executed in an interactive session, but not the commands -from executed scripts. -\end{lstlisting} - -\section{ice40\_braminit -- iCE40: perform SB\_RAM40\_4K initialization from file} -\label{cmd:ice40_braminit} -\begin{lstlisting}[numbers=left,frame=single] - ice40_braminit - -This command processes all SB_RAM40_4K blocks with a non-empty INIT_FILE -parameter and converts it into the required INIT_x attributes -\end{lstlisting} - -\section{ice40\_dsp -- iCE40: map multipliers} -\label{cmd:ice40_dsp} -\begin{lstlisting}[numbers=left,frame=single] - ice40_dsp [options] [selection] - -Map multipliers ($mul/SB_MAC16) and multiply-accumulate ($mul/SB_MAC16 + $add) -cells into iCE40 DSP resources. -Currently, only the 16x16 multiply mode is supported and not the 2 x 8x8 mode. - -Pack input registers (A, B, {C,D}; with optional hold), pipeline registers -({F,J,K,G}, H), output registers (O -- full 32-bits or lower 16-bits only; with -optional hold), and post-adder into into the SB_MAC16 resource. - -Multiply-accumulate operations using the post-adder with feedback on the {C,D} -input will be folded into the DSP. In this scenario only, resetting the -the accumulator to an arbitrary value can be inferred to use the {C,D} input. -\end{lstlisting} - -\section{ice40\_opt -- iCE40: perform simple optimizations} -\label{cmd:ice40_opt} -\begin{lstlisting}[numbers=left,frame=single] - ice40_opt [options] [selection] - -This command executes the following script: - - do - <ice40 specific optimizations> - opt_expr -mux_undef -undriven [-full] - opt_merge - opt_dff - opt_clean - while <changed design> -\end{lstlisting} - -\section{ice40\_wrapcarry -- iCE40: wrap carries} -\label{cmd:ice40_wrapcarry} -\begin{lstlisting}[numbers=left,frame=single] - ice40_wrapcarry [selection] - -Wrap manually instantiated SB_CARRY cells, along with their associated SB_LUT4s, -into an internal $__ICE40_CARRY_WRAPPER cell for preservation across technology -mapping. - -Attributes on both cells will have their names prefixed with 'SB_CARRY.' or -'SB_LUT4.' and attached to the wrapping cell. -A (* keep *) attribute on either cell will be logically OR-ed together. - - -unwrap - unwrap $__ICE40_CARRY_WRAPPER cells back into SB_CARRYs and SB_LUT4s, - including restoring their attributes. -\end{lstlisting} - -\section{insbuf -- insert buffer cells for connected wires} -\label{cmd:insbuf} -\begin{lstlisting}[numbers=left,frame=single] - insbuf [options] [selection] - -Insert buffer cells into the design for directly connected wires. - - -buf <celltype> <in-portname> <out-portname> - Use the given cell type instead of $_BUF_. (Notice that the next - call to "clean" will remove all $_BUF_ in the design.) -\end{lstlisting} - -\section{iopadmap -- technology mapping of i/o pads (or buffers)} -\label{cmd:iopadmap} -\begin{lstlisting}[numbers=left,frame=single] - iopadmap [options] [selection] - -Map module inputs/outputs to PAD cells from a library. This pass -can only map to very simple PAD cells. Use 'techmap' to further map -the resulting cells to more sophisticated PAD cells. - - -inpad <celltype> <in_port>[:<ext_port>] - Map module input ports to the given cell type with the - given output port name. if a 2nd portname is given, the - signal is passed through the pad cell, using the 2nd - portname as the port facing the module port. - - -outpad <celltype> <out_port>[:<ext_port>] - -inoutpad <celltype> <io_port>[:<ext_port>] - Similar to -inpad, but for output and inout ports. - - -toutpad <celltype> <oe_port>:<out_port>[:<ext_port>] - Merges $_TBUF_ cells into the output pad cell. This takes precedence - over the other -outpad cell. The first portname is the enable input - of the tristate driver, which can be prefixed with `~` for negative - polarity enable. - - -tinoutpad <celltype> <oe_port>:<in_port>:<out_port>[:<ext_port>] - Merges $_TBUF_ cells into the inout pad cell. This takes precedence - over the other -inoutpad cell. The first portname is the enable input - of the tristate driver and the 2nd portname is the internal output - buffering the external signal. Like with `-toutpad`, the enable can - be marked as negative polarity by prefixing the name with `~`. - - -ignore <celltype> <portname>[:<portname>]* - Skips mapping inputs/outputs that are already connected to given - ports of the given cell. Can be used multiple times. This is in - addition to the cells specified as mapping targets. - - -widthparam <param_name> - Use the specified parameter name to set the port width. - - -nameparam <param_name> - Use the specified parameter to set the port name. - - -bits - create individual bit-wide buffers even for ports that - are wider. (the default behavior is to create word-wide - buffers using -widthparam to set the word size on the cell.) - -Tristate PADS (-toutpad, -tinoutpad) always operate in -bits mode. -\end{lstlisting} - -\section{jny -- write design and metadata} -\label{cmd:jny} -\begin{lstlisting}[numbers=left,frame=single] - jny [options] [selection] - -Write JSON netlist metadata for the current design - - -o <filename> - write to the specified file. - - -no-connections - Don't include connection information in the netlist output. - - -no-attributes - Don't include attributed information in the netlist output. - - -no-properties - Don't include property information in the netlist output. - -See 'help write_jny' for a description of the JSON format used. -\end{lstlisting} - -\section{json -- write design in JSON format} -\label{cmd:json} -\begin{lstlisting}[numbers=left,frame=single] - json [options] [selection] - -Write a JSON netlist of all selected objects. - - -o <filename> - write to the specified file. - - -aig - also include AIG models for the different gate types - - -compat-int - emit 32-bit or smaller fully-defined parameter values directly - as JSON numbers (for compatibility with old parsers) - -See 'help write_json' for a description of the JSON format used. -\end{lstlisting} - -\section{log -- print text and log files} -\label{cmd:log} -\begin{lstlisting}[numbers=left,frame=single] - log string - -Print the given string to the screen and/or the log file. This is useful for TCL -scripts, because the TCL command "puts" only goes to stdout but not to -logfiles. - - -stdout - Print the output to stdout too. This is useful when all Yosys is - executed with a script and the -q (quiet operation) argument to notify - the user. - - -stderr - Print the output to stderr too. - - -nolog - Don't use the internal log() command. Use either -stdout or -stderr, - otherwise no output will be generated at all. - - -n - do not append a newline -\end{lstlisting} - -\section{logger -- set logger properties} -\label{cmd:logger} -\begin{lstlisting}[numbers=left,frame=single] - logger [options] - -This command sets global logger properties, also available using command line -options. - - -[no]time - enable/disable display of timestamp in log output. - - -[no]stderr - enable/disable logging errors to stderr. - - -warn regex - print a warning for all log messages matching the regex. - - -nowarn regex - if a warning message matches the regex, it is printed as regular - message instead. - - -werror regex - if a warning message matches the regex, it is printed as error - message instead and the tool terminates with a nonzero return code. - - -[no]debug - globally enable/disable debug log messages. - - -experimental <feature> - do not print warnings for the specified experimental feature - - -expect <type> <regex> <expected_count> - expect log, warning or error to appear. matched errors will terminate - with exit code 0. - - -expect-no-warnings - gives error in case there is at least one warning that is not expected. - - -check-expected - verifies that the patterns previously set up by -expect have actually - been met, then clears the expected log list. If this is not called - manually, the check will happen at yosys exist time instead. -\end{lstlisting} - -\section{ls -- list modules or objects in modules} -\label{cmd:ls} -\begin{lstlisting}[numbers=left,frame=single] - ls [selection] - -When no active module is selected, this prints a list of modules. - -When an active module is selected, this prints a list of objects in the module. -\end{lstlisting} - -\section{ltp -- print longest topological path} -\label{cmd:ltp} -\begin{lstlisting}[numbers=left,frame=single] - ltp [options] [selection] - -This command prints the longest topological path in the design. (Only considers -paths within a single module, so the design must be flattened.) - - -noff - automatically exclude FF cell types -\end{lstlisting} - -\section{lut2mux -- convert \$lut to \$\_MUX\_} -\label{cmd:lut2mux} -\begin{lstlisting}[numbers=left,frame=single] - lut2mux [options] [selection] - -This pass converts $lut cells to $_MUX_ gates. -\end{lstlisting} - -\section{maccmap -- mapping macc cells} -\label{cmd:maccmap} -\begin{lstlisting}[numbers=left,frame=single] - maccmap [-unmap] [selection] - -This pass maps $macc cells to yosys $fa and $alu cells. When the -unmap option -is used then the $macc cell is mapped to $add, $sub, etc. cells instead. -\end{lstlisting} - -\section{memory -- translate memories to basic cells} -\label{cmd:memory} -\begin{lstlisting}[numbers=left,frame=single] - memory [-norom] [-nomap] [-nordff] [-nowiden] [-nosat] [-memx] [-no-rw-check] [-bram <bram_rules>] [selection] - -This pass calls all the other memory_* passes in a useful order: - - opt_mem - opt_mem_priority - opt_mem_feedback - memory_bmux2rom (skipped if called with -norom) - memory_dff [-no-rw-check] (skipped if called with -nordff or -memx) - opt_clean - memory_share [-nowiden] [-nosat] - opt_mem_widen - memory_memx (when called with -memx) - opt_clean - memory_collect - memory_bram -rules <bram_rules> (when called with -bram) - memory_map (skipped if called with -nomap) - -This converts memories to word-wide DFFs and address decoders -or multiport memory blocks if called with the -nomap option. -\end{lstlisting} - -\section{memory\_bmux2rom -- convert muxes to ROMs} -\label{cmd:memory_bmux2rom} -\begin{lstlisting}[numbers=left,frame=single] - memory_bmux2rom [options] [selection] - -This pass converts $bmux cells with constant A input to ROMs. -\end{lstlisting} - -\section{memory\_bram -- map memories to block rams} -\label{cmd:memory_bram} -\begin{lstlisting}[numbers=left,frame=single] - memory_bram -rules <rule_file> [selection] - -This pass converts the multi-port $mem memory cells into block ram instances. -The given rules file describes the available resources and how they should be -used. - -The rules file contains configuration options, a set of block ram description -and a sequence of match rules. - -The option 'attr_icase' configures how attribute values are matched. The value 0 -means case-sensitive, 1 means case-insensitive. - -A block ram description looks like this: - - bram RAMB1024X32 # name of BRAM cell - init 1 # set to '1' if BRAM can be initialized - abits 10 # number of address bits - dbits 32 # number of data bits - groups 2 # number of port groups - ports 1 1 # number of ports in each group - wrmode 1 0 # set to '1' if this groups is write ports - enable 4 1 # number of enable bits - transp 0 2 # transparent (for read ports) - clocks 1 2 # clock configuration - clkpol 2 2 # clock polarity configuration - endbram - -For the option 'transp' the value 0 means non-transparent, 1 means transparent -and a value greater than 1 means configurable. All groups with the same -value greater than 1 share the same configuration bit. - -For the option 'clocks' the value 0 means non-clocked, and a value greater -than 0 means clocked. All groups with the same value share the same clock -signal. - -For the option 'clkpol' the value 0 means negative edge, 1 means positive edge -and a value greater than 1 means configurable. All groups with the same value -greater than 1 share the same configuration bit. - -Using the same bram name in different bram blocks will create different variants -of the bram. Verilog configuration parameters for the bram are created as -needed. - -It is also possible to create variants by repeating statements in the bram block -and appending '@<label>' to the individual statements. - -A match rule looks like this: - - match RAMB1024X32 - max waste 16384 # only use this bram if <= 16k ram bits are unused - min efficiency 80 # only use this bram if efficiency is at least 80% - endmatch - -It is possible to match against the following values with min/max rules: - - words ........ number of words in memory in design - abits ........ number of address bits on memory in design - dbits ........ number of data bits on memory in design - wports ....... number of write ports on memory in design - rports ....... number of read ports on memory in design - ports ........ number of ports on memory in design - bits ......... number of bits in memory in design - dups .......... number of duplications for more read ports - - awaste ....... number of unused address slots for this match - dwaste ....... number of unused data bits for this match - bwaste ....... number of unused bram bits for this match - waste ........ total number of unused bram bits (bwaste*dups) - efficiency ... total percentage of used and non-duplicated bits - - acells ....... number of cells in 'address-direction' - dcells ....... number of cells in 'data-direction' - cells ........ total number of cells (acells*dcells*dups) - -A match containing the command 'attribute' followed by a list of space -separated 'name[=string_value]' values requires that the memory contains any -one of the given attribute name and string values (where specified), or name -and integer 1 value (if no string_value given, since Verilog will interpret -'(* attr *)' as '(* attr=1 *)'). -A name prefixed with '!' indicates that the attribute must not exist. - -The interface for the created bram instances is derived from the bram -description. Use 'techmap' to convert the created bram instances into -instances of the actual bram cells of your target architecture. - -A match containing the command 'or_next_if_better' is only used if it -has a higher efficiency than the next match (and the one after that if -the next also has 'or_next_if_better' set, and so forth). - -A match containing the command 'make_transp' will add external circuitry -to simulate 'transparent read', if necessary. - -A match containing the command 'make_outreg' will add external flip-flops -to implement synchronous read ports, if necessary. - -A match containing the command 'shuffle_enable A' will re-organize -the data bits to accommodate the enable pattern of port A. -\end{lstlisting} - -\section{memory\_collect -- creating multi-port memory cells} -\label{cmd:memory_collect} -\begin{lstlisting}[numbers=left,frame=single] - memory_collect [selection] - -This pass collects memories and memory ports and creates generic multiport -memory cells. -\end{lstlisting} - -\section{memory\_dff -- merge input/output DFFs into memory read ports} -\label{cmd:memory_dff} -\begin{lstlisting}[numbers=left,frame=single] - memory_dff [-no-rw-check] [selection] - -This pass detects DFFs at memory read ports and merges them into the memory -port. I.e. it consumes an asynchronous memory port and the flip-flops at its -interface and yields a synchronous memory port. - - -no-rw-check - marks all recognized read ports as "return don't-care value on - read/write collision" (same result as setting the no_rw_check - attribute on all memories). -\end{lstlisting} - -\section{memory\_libmap -- map memories to cells} -\label{cmd:memory_libmap} -\begin{lstlisting}[numbers=left,frame=single] - memory_libmap -lib <library_file> [-D <condition>] [selection] - -This pass takes a description of available RAM cell types and maps -all selected memories to one of them, or leaves them to be mapped to FFs. - - -lib <library_file> - Selects a library file containing RAM cell definitions. This option - can be passed more than once to select multiple libraries. - See passes/memory/memlib.md for description of the library format. - - -D <condition> - Enables a condition that can be checked within the library file - to eg. select between slightly different hardware variants. - This option can be passed any number of times. - - -logic-cost-rom <num> - -logic-cost-ram <num> - Sets the cost of a single bit for memory lowered to soft logic. - - -no-auto-distributed - -no-auto-block - -no-auto-huge - Disables automatic mapping of given kind of RAMs. Manual mapping - (using ram_style or other attributes) is still supported. -\end{lstlisting} - -\section{memory\_map -- translate multiport memories to basic cells} -\label{cmd:memory_map} -\begin{lstlisting}[numbers=left,frame=single] - memory_map [options] [selection] - -This pass converts multiport memory cells as generated by the memory_collect -pass to word-wide DFFs and address decoders. - - -attr !<name> - do not map memories that have attribute <name> set. - - -attr <name>[=<value>] - for memories that have attribute <name> set, only map them if its value - is a string <value> (if specified), or an integer 1 (otherwise). if this - option is specified multiple times, map the memory if the attribute is - to any of the values. - - -iattr - for -attr, ignore case of <value>. - - -rom-only - only perform conversion for ROMs (memories with no write ports). - - -keepdc - when mapping ROMs, keep x-bits shared across read ports. - - -formal - map memories for a global clock based formal verification flow. - This implies -keepdc, uses $ff cells for ROMs and sets hdlname - attributes. It also has limited support for async write ports - as generated by clk2fflogic. -\end{lstlisting} - -\section{memory\_memx -- emulate vlog sim behavior for mem ports} -\label{cmd:memory_memx} -\begin{lstlisting}[numbers=left,frame=single] - memory_memx [selection] - -This pass adds additional circuitry that emulates the Verilog simulation -behavior for out-of-bounds memory reads and writes. -\end{lstlisting} - -\section{memory\_narrow -- split up wide memory ports} -\label{cmd:memory_narrow} -\begin{lstlisting}[numbers=left,frame=single] - memory_narrow [options] [selection] - -This pass splits up wide memory ports into several narrow ports. -\end{lstlisting} - -\section{memory\_nordff -- extract read port FFs from memories} -\label{cmd:memory_nordff} -\begin{lstlisting}[numbers=left,frame=single] - memory_nordff [options] [selection] - -This pass extracts FFs from memory read ports. This results in a netlist -similar to what one would get from not calling memory_dff. -\end{lstlisting} - -\section{memory\_share -- consolidate memory ports} -\label{cmd:memory_share} -\begin{lstlisting}[numbers=left,frame=single] - memory_share [-nosat] [-nowiden] [selection] - -This pass merges share-able memory ports into single memory ports. - -The following methods are used to consolidate the number of memory ports: - - - When multiple write ports access the same address then this is converted - to a single write port with a more complex data and/or enable logic path. - - - When multiple read or write ports access adjacent aligned addresses, they - are merged to a single wide read or write port. This transformation can be - disabled with the "-nowiden" option. - - - When multiple write ports are never accessed at the same time (a SAT - solver is used to determine this), then the ports are merged into a single - write port. This transformation can be disabled with the "-nosat" option. - -Note that in addition to the algorithms implemented in this pass, the $memrd -and $memwr cells are also subject to generic resource sharing passes (and other -optimizations) such as "share" and "opt_merge". -\end{lstlisting} - -\section{memory\_unpack -- unpack multi-port memory cells} -\label{cmd:memory_unpack} -\begin{lstlisting}[numbers=left,frame=single] - memory_unpack [selection] - -This pass converts the multi-port $mem memory cells into individual $memrd and -$memwr cells. It is the counterpart to the memory_collect pass. -\end{lstlisting} - -\section{miter -- automatically create a miter circuit} -\label{cmd:miter} -\begin{lstlisting}[numbers=left,frame=single] - miter -equiv [options] gold_name gate_name miter_name - -Creates a miter circuit for equivalence checking. The gold- and gate- modules -must have the same interfaces. The miter circuit will have all inputs of the -two source modules, prefixed with 'in_'. The miter circuit has a 'trigger' -output that goes high if an output mismatch between the two source modules is -detected. - - -ignore_gold_x - a undef (x) bit in the gold module output will match any value in - the gate module output. - - -make_outputs - also route the gold- and gate-outputs to 'gold_*' and 'gate_*' outputs - on the miter circuit. - - -make_outcmp - also create a cmp_* output for each gold/gate output pair. - - -make_assert - also create an 'assert' cell that checks if trigger is always low. - - -flatten - call 'flatten -wb; opt_expr -keepdc -undriven;;' on the miter circuit. - - - -cross - allow output ports on the gold module to match input ports on the - gate module. This is useful when the gold module contains additional - logic to drive some of the gate module inputs. - - - miter -assert [options] module [miter_name] - -Creates a miter circuit for property checking. All input ports are kept, -output ports are discarded. An additional output 'trigger' is created that -goes high when an assert is violated. Without a miter_name, the existing -module is modified. - - -make_outputs - keep module output ports. - - -flatten - call 'flatten -wb; opt_expr -keepdc -undriven;;' on the miter circuit. -\end{lstlisting} - -\section{mutate -- generate or apply design mutations} -\label{cmd:mutate} -\begin{lstlisting}[numbers=left,frame=single] - mutate -list N [options] [selection] - -Create a list of N mutations using an even sampling. - - -o filename - Write list to this file instead of console output - - -s filename - Write a list of all src tags found in the design to the specified file - - -seed N - RNG seed for selecting mutations - - -none - Include a "none" mutation in the output - - -ctrl name width value - Add -ctrl options to the output. Use 'value' for first mutation, then - simply count up from there. - - -mode name - -module name - -cell name - -port name - -portbit int - -ctrlbit int - -wire name - -wirebit int - -src string - Filter list of mutation candidates to those matching - the given parameters. - - -cfg option int - Set a configuration option. Options available: - weight_pq_w weight_pq_b weight_pq_c weight_pq_s - weight_pq_mw weight_pq_mb weight_pq_mc weight_pq_ms - weight_cover pick_cover_prcnt - - - mutate -mode MODE [options] - -Apply the given mutation. - - -ctrl name width value - Add a control signal with the given name and width. The mutation is - activated if the control signal equals the given value. - - -module name - -cell name - -port name - -portbit int - -ctrlbit int - Mutation parameters, as generated by 'mutate -list N'. - - -wire name - -wirebit int - -src string - Ignored. (They are generated by -list for documentation purposes.) -\end{lstlisting} - -\section{muxcover -- cover trees of MUX cells with wider MUXes} -\label{cmd:muxcover} -\begin{lstlisting}[numbers=left,frame=single] - muxcover [options] [selection] - -Cover trees of $_MUX_ cells with $_MUX{4,8,16}_ cells - - -mux4[=cost], -mux8[=cost], -mux16[=cost] - Cover $_MUX_ trees using the specified types of MUXes (with optional - integer costs). If none of these options are given, the effect is the - same as if all of them are. - Default costs: $_MUX4_ = 220, $_MUX8_ = 460, - $_MUX16_ = 940 - - -mux2=cost - Use the specified cost for $_MUX_ cells when making covering decisions. - Default cost: $_MUX_ = 100 - - -dmux=cost - Use the specified cost for $_MUX_ cells used in decoders. - Default cost: 90 - - -nodecode - Do not insert decoder logic. This reduces the number of possible - substitutions, but guarantees that the resulting circuit is not - less efficient than the original circuit. - - -nopartial - Do not consider mappings that use $_MUX<N>_ to select from less - than <N> different signals. -\end{lstlisting} - -\section{muxpack -- \$mux/\$pmux cascades to \$pmux} -\label{cmd:muxpack} -\begin{lstlisting}[numbers=left,frame=single] - muxpack [selection] - -This pass converts cascaded chains of $pmux cells (e.g. those create from case -constructs) and $mux cells (e.g. those created by if-else constructs) into -$pmux cells. - -This optimisation is conservative --- it will only pack $mux or $pmux cells -whose select lines are driven by '$eq' cells with other such cells if it can be -certain that their select inputs are mutually exclusive. -\end{lstlisting} - -\section{nlutmap -- map to LUTs of different sizes} -\label{cmd:nlutmap} -\begin{lstlisting}[numbers=left,frame=single] - nlutmap [options] [selection] - -This pass uses successive calls to 'abc' to map to an architecture. That -provides a small number of differently sized LUTs. - - -luts N_1,N_2,N_3,... - The number of LUTs with 1, 2, 3, ... inputs that are - available in the target architecture. - - -assert - Create an error if not all logic can be mapped - -Excess logic that does not fit into the specified LUTs is mapped back -to generic logic gates ($_AND_, etc.). -\end{lstlisting} - -\section{onehot -- optimize \$eq cells for onehot signals} -\label{cmd:onehot} -\begin{lstlisting}[numbers=left,frame=single] - onehot [options] [selection] - -This pass optimizes $eq cells that compare one-hot signals against constants - - -v, -vv - verbose output -\end{lstlisting} - -\section{opt -- perform simple optimizations} -\label{cmd:opt} -\begin{lstlisting}[numbers=left,frame=single] - opt [options] [selection] - -This pass calls all the other opt_* passes in a useful order. This performs -a series of trivial optimizations and cleanups. This pass executes the other -passes in the following order: - - opt_expr [-mux_undef] [-mux_bool] [-undriven] [-noclkinv] [-fine] [-full] [-keepdc] - opt_merge [-share_all] -nomux - - do - opt_muxtree - opt_reduce [-fine] [-full] - opt_merge [-share_all] - opt_share (-full only) - opt_dff [-nodffe] [-nosdff] [-keepdc] [-sat] (except when called with -noff) - opt_clean [-purge] - opt_expr [-mux_undef] [-mux_bool] [-undriven] [-noclkinv] [-fine] [-full] [-keepdc] - while <changed design> - -When called with -fast the following script is used instead: - - do - opt_expr [-mux_undef] [-mux_bool] [-undriven] [-noclkinv] [-fine] [-full] [-keepdc] - opt_merge [-share_all] - opt_dff [-nodffe] [-nosdff] [-keepdc] [-sat] (except when called with -noff) - opt_clean [-purge] - while <changed design in opt_dff> - -Note: Options in square brackets (such as [-keepdc]) are passed through to -the opt_* commands when given to 'opt'. -\end{lstlisting} - -\section{opt\_clean -- remove unused cells and wires} -\label{cmd:opt_clean} -\begin{lstlisting}[numbers=left,frame=single] - opt_clean [options] [selection] - -This pass identifies wires and cells that are unused and removes them. Other -passes often remove cells but leave the wires in the design or reconnect the -wires but leave the old cells in the design. This pass can be used to clean up -after the passes that do the actual work. - -This pass only operates on completely selected modules without processes. - - -purge - also remove internal nets if they have a public name -\end{lstlisting} - -\section{opt\_demorgan -- Optimize reductions with DeMorgan equivalents} -\label{cmd:opt_demorgan} -\begin{lstlisting}[numbers=left,frame=single] - opt_demorgan [selection] - -This pass pushes inverters through $reduce_* cells if this will reduce the -overall gate count of the circuit -\end{lstlisting} - -\section{opt\_dff -- perform DFF optimizations} -\label{cmd:opt_dff} -\begin{lstlisting}[numbers=left,frame=single] - opt_dff [-nodffe] [-nosdff] [-keepdc] [-sat] [selection] - -This pass converts flip-flops to a more suitable type by merging clock enables -and synchronous reset multiplexers, removing unused control inputs, or -potentially removes the flip-flop altogether, converting it to a constant -driver. - - -nodffe - disables dff -> dffe conversion, and other transforms recognizing clock - enable - - -nosdff - disables dff -> sdff conversion, and other transforms recognizing sync - resets - - -simple-dffe - only enables clock enable recognition transform for obvious cases - - -sat - additionally invoke SAT solver to detect and remove flip-flops (with - non-constant inputs) that can also be replaced with a constant driver - - -keepdc - some optimizations change the behavior of the circuit with respect to - don't-care bits. for example in 'a+0' a single x-bit in 'a' will cause - all result bits to be set to x. this behavior changes when 'a+0' is - replaced by 'a'. the -keepdc option disables all such optimizations. -\end{lstlisting} - -\section{opt\_expr -- perform const folding and simple expression rewriting} -\label{cmd:opt_expr} -\begin{lstlisting}[numbers=left,frame=single] - opt_expr [options] [selection] - -This pass performs const folding on internal cell types with constant inputs. -It also performs some simple expression rewriting. - - -mux_undef - remove 'undef' inputs from $mux, $pmux and $_MUX_ cells - - -mux_bool - replace $mux cells with inverters or buffers when possible - - -undriven - replace undriven nets with undef (x) constants - - -noclkinv - do not optimize clock inverters by changing FF types - - -fine - perform fine-grain optimizations - - -full - alias for -mux_undef -mux_bool -undriven -fine - - -keepdc - some optimizations change the behavior of the circuit with respect to - don't-care bits. for example in 'a+0' a single x-bit in 'a' will cause - all result bits to be set to x. this behavior changes when 'a+0' is - replaced by 'a'. the -keepdc option disables all such optimizations. -\end{lstlisting} - -\section{opt\_ffinv -- push inverters through FFs} -\label{cmd:opt_ffinv} -\begin{lstlisting}[numbers=left,frame=single] - opt_ffinv [selection] - -This pass pushes inverters to the other side of a FF when they can be merged -into LUTs on the other side. -\end{lstlisting} - -\section{opt\_lut -- optimize LUT cells} -\label{cmd:opt_lut} -\begin{lstlisting}[numbers=left,frame=single] - opt_lut [options] [selection] - -This pass combines cascaded $lut cells with unused inputs. - - -dlogic <type>:<cell-port>=<LUT-input>[:<cell-port>=<LUT-input>...] - preserve connections to dedicated logic cell <type> that has ports - <cell-port> connected to LUT inputs <LUT-input>. this includes - the case where both LUT and dedicated logic input are connected to - the same constant. - - -limit N - only perform the first N combines, then stop. useful for debugging. -\end{lstlisting} - -\section{opt\_lut\_ins -- discard unused LUT inputs} -\label{cmd:opt_lut_ins} -\begin{lstlisting}[numbers=left,frame=single] - opt_lut_ins [options] [selection] - -This pass removes unused inputs from LUT cells (that is, inputs that can not -influence the output signal given this LUT's value). While such LUTs cannot -be directly emitted by ABC, they can be a result of various post-ABC -transformations, such as mapping wide LUTs (not all sub-LUTs will use the -full set of inputs) or optimizations such as xilinx_dffopt. - - -tech <technology> - Instead of generic $lut cells, operate on LUT cells specific - to the given technology. Valid values are: xilinx, ecp5, gowin. -\end{lstlisting} - -\section{opt\_mem -- optimize memories} -\label{cmd:opt_mem} -\begin{lstlisting}[numbers=left,frame=single] - opt_mem [options] [selection] - -This pass performs various optimizations on memories in the design. -\end{lstlisting} - -\section{opt\_mem\_feedback -- convert memory read-to-write port feedback paths to write enables} -\label{cmd:opt_mem_feedback} -\begin{lstlisting}[numbers=left,frame=single] - opt_mem_feedback [selection] - -This pass detects cases where an asynchronous read port is only connected via -a mux tree to a write port with the same address. When such a connection is -found, it is replaced with a new condition on an enable signal, allowing -for removal of the read port. -\end{lstlisting} - -\section{opt\_mem\_priority -- remove priority relations between write ports that can never collide} -\label{cmd:opt_mem_priority} -\begin{lstlisting}[numbers=left,frame=single] - opt_mem_priority [selection] - -This pass detects cases where one memory write port has priority over another -even though they can never collide with each other -- ie. there can never be -a situation where a given memory bit is written by both ports at the same -time, for example because of always-different addresses, or mutually exclusive -enable signals. In such cases, the priority relation is removed. -\end{lstlisting} - -\section{opt\_mem\_widen -- optimize memories where all ports are wide} -\label{cmd:opt_mem_widen} -\begin{lstlisting}[numbers=left,frame=single] - opt_mem_widen [options] [selection] - -This pass looks for memories where all ports are wide and adjusts the base -memory width up until that stops being the case. -\end{lstlisting} - -\section{opt\_merge -- consolidate identical cells} -\label{cmd:opt_merge} -\begin{lstlisting}[numbers=left,frame=single] - opt_merge [options] [selection] - -This pass identifies cells with identical type and input signals. Such cells -are then merged to one cell. - - -nomux - Do not merge MUX cells. - - -share_all - Operate on all cell types, not just built-in types. - - -keepdc - Do not merge flipflops with don't-care bits in their initial value. -\end{lstlisting} - -\section{opt\_muxtree -- eliminate dead trees in multiplexer trees} -\label{cmd:opt_muxtree} -\begin{lstlisting}[numbers=left,frame=single] - opt_muxtree [selection] - -This pass analyzes the control signals for the multiplexer trees in the design -and identifies inputs that can never be active. It then removes this dead -branches from the multiplexer trees. - -This pass only operates on completely selected modules without processes. -\end{lstlisting} - -\section{opt\_reduce -- simplify large MUXes and AND/OR gates} -\label{cmd:opt_reduce} -\begin{lstlisting}[numbers=left,frame=single] - opt_reduce [options] [selection] - -This pass performs two interlinked optimizations: - -1. it consolidates trees of large AND gates or OR gates and eliminates -duplicated inputs. - -2. it identifies duplicated inputs to MUXes and replaces them with a single -input with the original control signals OR'ed together. - - -fine - perform fine-grain optimizations - - -full - alias for -fine -\end{lstlisting} - -\section{opt\_share -- merge mutually exclusive cells of the same type that share an input signal} -\label{cmd:opt_share} -\begin{lstlisting}[numbers=left,frame=single] - opt_share [selection] - -This pass identifies mutually exclusive cells of the same type that: - (a) share an input signal, - (b) drive the same $mux, $_MUX_, or $pmux multiplexing cell, - -allowing the cell to be merged and the multiplexer to be moved from -multiplexing its output to multiplexing the non-shared input signals. -\end{lstlisting} - -\section{paramap -- renaming cell parameters} -\label{cmd:paramap} -\begin{lstlisting}[numbers=left,frame=single] - paramap [options] [selection] - -This command renames cell parameters and/or maps key/value pairs to -other key/value pairs. - - -tocase <name> - Match attribute names case-insensitively and set it to the specified - name. - - -rename <old_name> <new_name> - Rename attributes as specified - - -map <old_name>=<old_value> <new_name>=<new_value> - Map key/value pairs as indicated. - - -imap <old_name>=<old_value> <new_name>=<new_value> - Like -map, but use case-insensitive match for <old_value> when - it is a string value. - - -remove <name>=<value> - Remove attributes matching this pattern. - -For example, mapping Diamond-style ECP5 "init" attributes to Yosys-style: - - paramap -tocase INIT t:LUT4 -\end{lstlisting} - -\section{peepopt -- collection of peephole optimizers} -\label{cmd:peepopt} -\begin{lstlisting}[numbers=left,frame=single] - peepopt [options] [selection] - -This pass applies a collection of peephole optimizers to the current design. -\end{lstlisting} - -\section{plugin -- load and list loaded plugins} -\label{cmd:plugin} -\begin{lstlisting}[numbers=left,frame=single] - plugin [options] - -Load and list loaded plugins. - - -i <plugin_filename> - Load (install) the specified plugin. - - -a <alias_name> - Register the specified alias name for the loaded plugin - - -l - List loaded plugins -\end{lstlisting} - -\section{pmux2shiftx -- transform \$pmux cells to \$shiftx cells} -\label{cmd:pmux2shiftx} -\begin{lstlisting}[numbers=left,frame=single] - pmux2shiftx [options] [selection] - -This pass transforms $pmux cells to $shiftx cells. - - -v, -vv - verbose output - - -min_density <percentage> - specifies the minimum density for the shifter - default: 50 - - -min_choices <int> - specified the minimum number of choices for a control signal - default: 3 - - -onehot ignore|pmux|shiftx - select strategy for one-hot encoded control signals - default: pmux - - -norange - disable $sub inference for "range decoders" -\end{lstlisting} - -\section{pmuxtree -- transform \$pmux cells to trees of \$mux cells} -\label{cmd:pmuxtree} -\begin{lstlisting}[numbers=left,frame=single] - pmuxtree [selection] - -This pass transforms $pmux cells to trees of $mux cells. -\end{lstlisting} - -\section{portlist -- list (top-level) ports} -\label{cmd:portlist} -\begin{lstlisting}[numbers=left,frame=single] - portlist [options] [selection] - -This command lists all module ports found in the selected modules. - -If no selection is provided then it lists the ports on the top module. - - -m - print verilog blackbox module definitions instead of port lists -\end{lstlisting} - -\section{prep -- generic synthesis script} -\label{cmd:prep} -\begin{lstlisting}[numbers=left,frame=single] - prep [options] - -This command runs a conservative RTL synthesis. A typical application for this -is the preparation stage of a verification flow. This command does not operate -on partly selected designs. - - -top <module> - use the specified module as top module (default='top') - - -auto-top - automatically determine the top of the design hierarchy - - -flatten - flatten the design before synthesis. this will pass '-auto-top' to - 'hierarchy' if no top module is specified. - - -ifx - passed to 'proc'. uses verilog simulation behavior for verilog if/case - undef handling. this also prevents 'wreduce' from being run. - - -memx - simulate verilog simulation behavior for out-of-bounds memory accesses - using the 'memory_memx' pass. - - -nomem - do not run any of the memory_* passes - - -rdff - call 'memory_dff'. This enables merging of FFs into - memory read ports. - - -nokeepdc - do not call opt_* with -keepdc - - -run <from_label>[:<to_label>] - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -The following commands are executed by this synthesis command: - - begin: - hierarchy -check [-top <top> | -auto-top] - - coarse: - proc [-ifx] - flatten (if -flatten) - opt_expr -keepdc - opt_clean - check - opt -noff -keepdc - wreduce -keepdc [-memx] - memory_dff (if -rdff) - memory_memx (if -memx) - opt_clean - memory_collect - opt -noff -keepdc -fast - - check: - stat - check -\end{lstlisting} - -\section{printattrs -- print attributes of selected objects} -\label{cmd:printattrs} -\begin{lstlisting}[numbers=left,frame=single] - printattrs [selection] - -Print all attributes of the selected objects. -\end{lstlisting} - -\section{proc -- translate processes to netlists} -\label{cmd:proc} -\begin{lstlisting}[numbers=left,frame=single] - proc [options] [selection] - -This pass calls all the other proc_* passes in the most common order. - - proc_clean - proc_rmdead - proc_prune - proc_init - proc_arst - proc_rom - proc_mux - proc_dlatch - proc_dff - proc_memwr - proc_clean - opt_expr -keepdc - -This replaces the processes in the design with multiplexers, -flip-flops and latches. - -The following options are supported: - - -nomux - Will omit the proc_mux pass. - - -norom - Will omit the proc_rom pass. - - -global_arst [!]<netname> - This option is passed through to proc_arst. - - -ifx - This option is passed through to proc_mux. proc_rmdead is not - executed in -ifx mode. - - -noopt - Will omit the opt_expr pass. -\end{lstlisting} - -\section{proc\_arst -- detect asynchronous resets} -\label{cmd:proc_arst} -\begin{lstlisting}[numbers=left,frame=single] - proc_arst [-global_arst [!]<netname>] [selection] - -This pass identifies asynchronous resets in the processes and converts them -to a different internal representation that is suitable for generating -flip-flop cells with asynchronous resets. - - -global_arst [!]<netname> - In modules that have a net with the given name, use this net as async - reset for registers that have been assign initial values in their - declaration ('reg foobar = constant_value;'). Use the '!' modifier for - active low reset signals. Note: the frontend stores the default value - in the 'init' attribute on the net. -\end{lstlisting} - -\section{proc\_clean -- remove empty parts of processes} -\label{cmd:proc_clean} -\begin{lstlisting}[numbers=left,frame=single] - proc_clean [options] [selection] - - -quiet - do not print any messages. - -This pass removes empty parts of processes and ultimately removes a process -if it contains only empty structures. -\end{lstlisting} - -\section{proc\_dff -- extract flip-flops from processes} -\label{cmd:proc_dff} -\begin{lstlisting}[numbers=left,frame=single] - proc_dff [selection] - -This pass identifies flip-flops in the processes and converts them to -d-type flip-flop cells. -\end{lstlisting} - -\section{proc\_dlatch -- extract latches from processes} -\label{cmd:proc_dlatch} -\begin{lstlisting}[numbers=left,frame=single] - proc_dlatch [selection] - -This pass identifies latches in the processes and converts them to -d-type latches. -\end{lstlisting} - -\section{proc\_init -- convert initial block to init attributes} -\label{cmd:proc_init} -\begin{lstlisting}[numbers=left,frame=single] - proc_init [selection] - -This pass extracts the 'init' actions from processes (generated from Verilog -'initial' blocks) and sets the initial value to the 'init' attribute on the -respective wire. -\end{lstlisting} - -\section{proc\_memwr -- extract memory writes from processes} -\label{cmd:proc_memwr} -\begin{lstlisting}[numbers=left,frame=single] - proc_memwr [selection] - -This pass converts memory writes in processes into $memwr cells. -\end{lstlisting} - -\section{proc\_mux -- convert decision trees to multiplexers} -\label{cmd:proc_mux} -\begin{lstlisting}[numbers=left,frame=single] - proc_mux [options] [selection] - -This pass converts the decision trees in processes (originating from if-else -and case statements) to trees of multiplexer cells. - - -ifx - Use Verilog simulation behavior with respect to undef values in - 'case' expressions and 'if' conditions. -\end{lstlisting} - -\section{proc\_prune -- remove redundant assignments} -\label{cmd:proc_prune} -\begin{lstlisting}[numbers=left,frame=single] - proc_prune [selection] - -This pass identifies assignments in processes that are always overwritten by -a later assignment to the same signal and removes them. -\end{lstlisting} - -\section{proc\_rmdead -- eliminate dead trees in decision trees} -\label{cmd:proc_rmdead} -\begin{lstlisting}[numbers=left,frame=single] - proc_rmdead [selection] - -This pass identifies unreachable branches in decision trees and removes them. -\end{lstlisting} - -\section{proc\_rom -- convert switches to ROMs} -\label{cmd:proc_rom} -\begin{lstlisting}[numbers=left,frame=single] - proc_rom [selection] - -This pass converts switches into read-only memories when appropriate. -\end{lstlisting} - -\section{qbfsat -- solve a 2QBF-SAT problem in the circuit} -\label{cmd:qbfsat} -\begin{lstlisting}[numbers=left,frame=single] - qbfsat [options] [selection] - -This command solves an "exists-forall" 2QBF-SAT problem defined over the -currently selected module. Existentially-quantified variables are declared by -assigning a wire "$anyconst". Universally-quantified variables may be -explicitly declared by assigning a wire "$allconst", but module inputs will be -treated as universally-quantified variables by default. - - -nocleanup - Do not delete temporary files and directories. Useful for debugging. - - -dump-final-smt2 <file> - Pass the --dump-smt2 option to yosys-smtbmc. - - -assume-outputs - Add an "$assume" cell for the conjunction of all one-bit module output - wires. - - -assume-negative-polarity - When adding $assume cells for one-bit module output wires, assume they - are negative polarity signals and should always be low, for example like - the miters created with the `miter` command. - - -nooptimize - Ignore "\minimize" and "\maximize" attributes, do not emit - "(maximize)" or "(minimize)" in the SMT-LIBv2, and generally make no - attempt to optimize anything. - - -nobisection - If a wire is marked with the "\minimize" or "\maximize" attribute, - do not attempt to optimize that value with the default iterated solving - and threshold bisection approach. Instead, have yosys-smtbmc emit a - "(minimize)" or "(maximize)" command in the SMT-LIBv2 output and - hope that the solver supports optimizing quantified bitvector problems. - - -solver <solver> - Use a particular solver. Choose one of: "z3", "yices", and "cvc4". - (default: yices) - - -solver-option <name> <value> - Set the specified solver option in the SMT-LIBv2 problem file. - - -timeout <value> - Set the per-iteration timeout in seconds. - (default: no timeout) - - -O0, -O1, -O2 - Control the use of ABC to simplify the QBF-SAT problem before solving. - - -sat - Generate an error if the solver does not return "sat". - - -unsat - Generate an error if the solver does not return "unsat". - - -show-smtbmc - Print the output from yosys-smtbmc. - - -specialize - If the problem is satisfiable, replace each "$anyconst" cell with its - corresponding constant value from the model produced by the solver. - - -specialize-from-file <solution file> - Do not run the solver, but instead only attempt to replace each - "$anyconst" cell in the current module with a constant value provided - by the specified file. - - -write-solution <solution file> - If the problem is satisfiable, write the corresponding constant value - for each "$anyconst" cell from the model produced by the solver to the - specified file. -\end{lstlisting} - -\section{qwp -- quadratic wirelength placer} -\label{cmd:qwp} -\begin{lstlisting}[numbers=left,frame=single] - qwp [options] [selection] - -This command runs quadratic wirelength placement on the selected modules and -annotates the cells in the design with 'qwp_position' attributes. - - -ltr - Add left-to-right constraints: constrain all inputs on the left border - outputs to the right border. - - -alpha - Add constraints for inputs/outputs to be placed in alphanumerical - order along the y-axis (top-to-bottom). - - -grid N - Number of grid divisions in x- and y-direction. (default=16) - - -dump <html_file_name> - Dump a protocol of the placement algorithm to the html file. - - -v - Verbose solver output for profiling or debugging - -Note: This implementation of a quadratic wirelength placer uses exact -dense matrix operations. It is only a toy-placer for small circuits. -\end{lstlisting} - -\section{read -- load HDL designs} -\label{cmd:read} -\begin{lstlisting}[numbers=left,frame=single] - read {-vlog95|-vlog2k|-sv2005|-sv2009|-sv2012|-sv|-formal} <verilog-file>.. - -Load the specified Verilog/SystemVerilog files. (Full SystemVerilog support -is only available via Verific.) - -Additional -D<macro>[=<value>] options may be added after the option indicating -the language version (and before file names) to set additional verilog defines. - - - read {-vhdl87|-vhdl93|-vhdl2k|-vhdl2008|-vhdl} <vhdl-file>.. - -Load the specified VHDL files. (Requires Verific.) - - - read {-edif} <edif-file>.. - -Load the specified EDIF files. (Requires Verific.) - - - read {-liberty} <liberty-file>.. - -Load the specified Liberty files. - - -lib - only create empty blackbox modules - - - read {-f|-F} <command-file> - -Load and execute the specified command file. (Requires Verific.) -Check verific command for more information about supported commands in file. - - - read -define <macro>[=<value>].. - -Set global Verilog/SystemVerilog defines. - - - read -undef <macro>.. - -Unset global Verilog/SystemVerilog defines. - - - read -incdir <directory> - -Add directory to global Verilog/SystemVerilog include directories. - - - read -verific - read -noverific - -Subsequent calls to 'read' will either use or not use Verific. Calling 'read' -with -verific will result in an error on Yosys binaries that are built without -Verific support. The default is to use Verific if it is available. -\end{lstlisting} - -\section{read\_aiger -- read AIGER file} -\label{cmd:read_aiger} -\begin{lstlisting}[numbers=left,frame=single] - read_aiger [options] [filename] - -Load module from an AIGER file into the current design. - - -module_name <module_name> - name of module to be created (default: <filename>) - - -clk_name <wire_name> - if specified, AIGER latches to be transformed into $_DFF_P_ cells - clocked by wire of this name. otherwise, $_FF_ cells will be used - - -map <filename> - read file with port and latch symbols - - -wideports - merge ports that match the pattern 'name[int]' into a single - multi-bit port 'name' - - -xaiger - read XAIGER extensions -\end{lstlisting} - -\section{read\_blif -- read BLIF file} -\label{cmd:read_blif} -\begin{lstlisting}[numbers=left,frame=single] - read_blif [options] [filename] - -Load modules from a BLIF file into the current design. - - -sop - Create $sop cells instead of $lut cells - - -wideports - Merge ports that match the pattern 'name[int]' into a single - multi-bit port 'name'. -\end{lstlisting} - -\section{read\_ilang -- (deprecated) alias of read\_rtlil} -\label{cmd:read_ilang} -\begin{lstlisting}[numbers=left,frame=single] -See `help read_rtlil`. -\end{lstlisting} - -\section{read\_json -- read JSON file} -\label{cmd:read_json} -\begin{lstlisting}[numbers=left,frame=single] - read_json [filename] - -Load modules from a JSON file into the current design See "help write_json" -for a description of the file format. -\end{lstlisting} - -\section{read\_liberty -- read cells from liberty file} -\label{cmd:read_liberty} -\begin{lstlisting}[numbers=left,frame=single] - read_liberty [filename] - -Read cells from liberty file as modules into current design. - - -lib - only create empty blackbox modules - - -wb - mark imported cells as whiteboxes - - -nooverwrite - ignore re-definitions of modules. (the default behavior is to - create an error message if the existing module is not a blackbox - module, and overwrite the existing module if it is a blackbox module.) - - -overwrite - overwrite existing modules with the same name - - -ignore_miss_func - ignore cells with missing function specification of outputs - - -ignore_miss_dir - ignore cells with a missing or invalid direction - specification on a pin - - -ignore_miss_data_latch - ignore latches with missing data and/or enable pins - - -setattr <attribute_name> - set the specified attribute (to the value 1) on all loaded modules -\end{lstlisting} - -\section{read\_rtlil -- read modules from RTLIL file} -\label{cmd:read_rtlil} -\begin{lstlisting}[numbers=left,frame=single] - read_rtlil [filename] - -Load modules from an RTLIL file to the current design. (RTLIL is a text -representation of a design in yosys's internal format.) - - -nooverwrite - ignore re-definitions of modules. (the default behavior is to - create an error message if the existing module is not a blackbox - module, and overwrite the existing module if it is a blackbox module.) - - -overwrite - overwrite existing modules with the same name - - -lib - only create empty blackbox modules -\end{lstlisting} - -\section{read\_verilog -- read modules from Verilog file} -\label{cmd:read_verilog} -\begin{lstlisting}[numbers=left,frame=single] - read_verilog [options] [filename] - -Load modules from a Verilog file to the current design. A large subset of -Verilog-2005 is supported. - - -sv - enable support for SystemVerilog features. (only a small subset - of SystemVerilog is supported) - - -formal - enable support for SystemVerilog assertions and some Yosys extensions - replace the implicit -D SYNTHESIS with -D FORMAL - - -nosynthesis - don't add implicit -D SYNTHESIS - - -noassert - ignore assert() statements - - -noassume - ignore assume() statements - - -norestrict - ignore restrict() statements - - -assume-asserts - treat all assert() statements like assume() statements - - -assert-assumes - treat all assume() statements like assert() statements - - -debug - alias for -dump_ast1 -dump_ast2 -dump_vlog1 -dump_vlog2 -yydebug - - -dump_ast1 - dump abstract syntax tree (before simplification) - - -dump_ast2 - dump abstract syntax tree (after simplification) - - -no_dump_ptr - do not include hex memory addresses in dump (easier to diff dumps) - - -dump_vlog1 - dump ast as Verilog code (before simplification) - - -dump_vlog2 - dump ast as Verilog code (after simplification) - - -dump_rtlil - dump generated RTLIL netlist - - -yydebug - enable parser debug output - - -nolatches - usually latches are synthesized into logic loops - this option prohibits this and sets the output to 'x' - in what would be the latches hold condition - - this behavior can also be achieved by setting the - 'nolatches' attribute on the respective module or - always block. - - -nomem2reg - under certain conditions memories are converted to registers - early during simplification to ensure correct handling of - complex corner cases. this option disables this behavior. - - this can also be achieved by setting the 'nomem2reg' - attribute on the respective module or register. - - This is potentially dangerous. Usually the front-end has good - reasons for converting an array to a list of registers. - Prohibiting this step will likely result in incorrect synthesis - results. - - -mem2reg - always convert memories to registers. this can also be - achieved by setting the 'mem2reg' attribute on the respective - module or register. - - -nomeminit - do not infer $meminit cells and instead convert initialized - memories to registers directly in the front-end. - - -ppdump - dump Verilog code after pre-processor - - -nopp - do not run the pre-processor - - -nodpi - disable DPI-C support - - -noblackbox - do not automatically add a (* blackbox *) attribute to an - empty module. - - -lib - only create empty blackbox modules. This implies -DBLACKBOX. - modules with the (* whitebox *) attribute will be preserved. - (* lib_whitebox *) will be treated like (* whitebox *). - - -nowb - delete (* whitebox *) and (* lib_whitebox *) attributes from - all modules. - - -specify - parse and import specify blocks - - -noopt - don't perform basic optimizations (such as const folding) in the - high-level front-end. - - -icells - interpret cell types starting with '$' as internal cell types - - -pwires - add a wire for each module parameter - - -nooverwrite - ignore re-definitions of modules. (the default behavior is to - create an error message if the existing module is not a black box - module, and overwrite the existing module otherwise.) - - -overwrite - overwrite existing modules with the same name - - -defer - only read the abstract syntax tree and defer actual compilation - to a later 'hierarchy' command. Useful in cases where the default - parameters of modules yield invalid or not synthesizable code. - - -noautowire - make the default of `default_nettype be "none" instead of "wire". - - -setattr <attribute_name> - set the specified attribute (to the value 1) on all loaded modules - - -Dname[=definition] - define the preprocessor symbol 'name' and set its optional value - 'definition' - - -Idir - add 'dir' to the directories which are used when searching include - files - -The command 'verilog_defaults' can be used to register default options for -subsequent calls to 'read_verilog'. - -Note that the Verilog frontend does a pretty good job of processing valid -verilog input, but has not very good error reporting. It generally is -recommended to use a simulator (for example Icarus Verilog) for checking -the syntax of the code, rather than to rely on read_verilog for that. - -Depending on if read_verilog is run in -formal mode, either the macro -SYNTHESIS or FORMAL is defined automatically, unless -nosynthesis is used. -In addition, read_verilog always defines the macro YOSYS. - -See the Yosys README file for a list of non-standard Verilog features -supported by the Yosys Verilog front-end. -\end{lstlisting} - -\section{rename -- rename object in the design} -\label{cmd:rename} -\begin{lstlisting}[numbers=left,frame=single] - rename old_name new_name - -Rename the specified object. Note that selection patterns are not supported -by this command. - - - - rename -output old_name new_name - -Like above, but also make the wire an output. This will fail if the object is -not a wire. - - - rename -src [selection] - -Assign names auto-generated from the src attribute to all selected wires and -cells with private names. - - - rename -wire [selection] [-suffix <suffix>] - -Assign auto-generated names based on the wires they drive to all selected -cells with private names. Ignores cells driving privatly named wires. -By default, the cell is named after the wire with the cell type as suffix. -The -suffix option can be used to set the suffix to the given string instead. - - - rename -enumerate [-pattern <pattern>] [selection] - -Assign short auto-generated names to all selected wires and cells with private -names. The -pattern option can be used to set the pattern for the new names. -The character % in the pattern is replaced with a integer number. The default -pattern is '_%_'. - - - rename -witness - -Assigns auto-generated names to all $any*/$all* output wires and containing -cells that do not have a public name. This ensures that, during formal -verification, a solver-found trace can be fully specified using a public -hierarchical names. - - - rename -hide [selection] - -Assign private names (the ones with $-prefix) to all selected wires and cells -with public names. This ignores all selected ports. - - - rename -top new_name - -Rename top module. - - - rename -scramble-name [-seed <seed>] [selection] - -Assign randomly-generated names to all selected wires and cells. The seed option -can be used to change the random number generator seed from the default, but it -must be non-zero. -\end{lstlisting} - -\section{rmports -- remove module ports with no connections} -\label{cmd:rmports} -\begin{lstlisting}[numbers=left,frame=single] - rmports [selection] - -This pass identifies ports in the selected modules which are not used or -driven and removes them. -\end{lstlisting} - -\section{sat -- solve a SAT problem in the circuit} -\label{cmd:sat} -\begin{lstlisting}[numbers=left,frame=single] - sat [options] [selection] - -This command solves a SAT problem defined over the currently selected circuit -and additional constraints passed as parameters. - - -all - show all solutions to the problem (this can grow exponentially, use - -max <N> instead to get <N> solutions) - - -max <N> - like -all, but limit number of solutions to <N> - - -enable_undef - enable modeling of undef value (aka 'x-bits') - this option is implied by -set-def, -set-undef et. cetera - - -max_undef - maximize the number of undef bits in solutions, giving a better - picture of which input bits are actually vital to the solution. - - -set <signal> <value> - set the specified signal to the specified value. - - -set-def <signal> - add a constraint that all bits of the given signal must be defined - - -set-any-undef <signal> - add a constraint that at least one bit of the given signal is undefined - - -set-all-undef <signal> - add a constraint that all bits of the given signal are undefined - - -set-def-inputs - add -set-def constraints for all module inputs - - -set-def-formal - add -set-def constraints for formal $anyinit, $anyconst, $anyseq cells - - -show <signal> - show the model for the specified signal. if no -show option is - passed then a set of signals to be shown is automatically selected. - - -show-inputs, -show-outputs, -show-ports - add all module (input/output) ports to the list of shown signals - - -show-regs, -show-public, -show-all - show all registers, show signals with 'public' names, show all signals - - -ignore_div_by_zero - ignore all solutions that involve a division by zero - - -ignore_unknown_cells - ignore all cells that can not be matched to a SAT model - -The following options can be used to set up a sequential problem: - - -seq <N> - set up a sequential problem with <N> time steps. The steps will - be numbered from 1 to N. - - note: for large <N> it can be significantly faster to use - -tempinduct-baseonly -maxsteps <N> instead of -seq <N>. - - -set-at <N> <signal> <value> - -unset-at <N> <signal> - set or unset the specified signal to the specified value in the - given timestep. this has priority over a -set for the same signal. - - -set-assumes - set all assumptions provided via $assume cells - - -set-def-at <N> <signal> - -set-any-undef-at <N> <signal> - -set-all-undef-at <N> <signal> - add undef constraints in the given timestep. - - -set-init <signal> <value> - set the initial value for the register driving the signal to the value - - -set-init-undef - set all initial states (not set using -set-init) to undef - - -set-init-def - do not force a value for the initial state but do not allow undef - - -set-init-zero - set all initial states (not set using -set-init) to zero - - -dump_vcd <vcd-file-name> - dump SAT model (counter example in proof) to VCD file - - -dump_json <json-file-name> - dump SAT model (counter example in proof) to a WaveJSON file. - - -dump_cnf <cnf-file-name> - dump CNF of SAT problem (in DIMACS format). in temporal induction - proofs this is the CNF of the first induction step. - -The following additional options can be used to set up a proof. If also -seq -is passed, a temporal induction proof is performed. - - -tempinduct - Perform a temporal induction proof. In a temporal induction proof it is - proven that the condition holds forever after the number of time steps - specified using -seq. - - -tempinduct-def - Perform a temporal induction proof. Assume an initial state with all - registers set to defined values for the induction step. - - -tempinduct-baseonly - Run only the basecase half of temporal induction (requires -maxsteps) - - -tempinduct-inductonly - Run only the induction half of temporal induction - - -tempinduct-skip <N> - Skip the first <N> steps of the induction proof. - - note: this will assume that the base case holds for <N> steps. - this must be proven independently with "-tempinduct-baseonly - -maxsteps <N>". Use -initsteps if you just want to set a - minimal induction length. - - -prove <signal> <value> - Attempt to proof that <signal> is always <value>. - - -prove-x <signal> <value> - Like -prove, but an undef (x) bit in the lhs matches any value on - the right hand side. Useful for equivalence checking. - - -prove-asserts - Prove that all asserts in the design hold. - - -prove-skip <N> - Do not enforce the prove-condition for the first <N> time steps. - - -maxsteps <N> - Set a maximum length for the induction. - - -initsteps <N> - Set initial length for the induction. - This will speed up the search of the right induction length - for deep induction proofs. - - -stepsize <N> - Increase the size of the induction proof in steps of <N>. - This will speed up the search of the right induction length - for deep induction proofs. - - -timeout <N> - Maximum number of seconds a single SAT instance may take. - - -verify - Return an error and stop the synthesis script if the proof fails. - - -verify-no-timeout - Like -verify but do not return an error for timeouts. - - -falsify - Return an error and stop the synthesis script if the proof succeeds. - - -falsify-no-timeout - Like -falsify but do not return an error for timeouts. -\end{lstlisting} - -\section{scatter -- add additional intermediate nets} -\label{cmd:scatter} -\begin{lstlisting}[numbers=left,frame=single] - scatter [selection] - -This command adds additional intermediate nets on all cell ports. This is used -for testing the correct use of the SigMap helper in passes. If you don't know -what this means: don't worry -- you only need this pass when testing your own -extensions to Yosys. - -Use the opt_clean command to get rid of the additional nets. -\end{lstlisting} - -\section{scc -- detect strongly connected components (logic loops)} -\label{cmd:scc} -\begin{lstlisting}[numbers=left,frame=single] - scc [options] [selection] - -This command identifies strongly connected components (aka logic loops) in the -design. - - -expect <num> - expect to find exactly <num> SCCs. A different number of SCCs will - produce an error. - - -max_depth <num> - limit to loops not longer than the specified number of cells. This - can e.g. be useful in identifying small local loops in a module that - implements one large SCC. - - -nofeedback - do not count cells that have their output fed back into one of their - inputs as single-cell scc. - - -all_cell_types - Usually this command only considers internal non-memory cells. With - this option set, all cells are considered. For unknown cells all ports - are assumed to be bidirectional 'inout' ports. - - -set_attr <name> <value> - set the specified attribute on all cells that are part of a logic - loop. the special token {} in the value is replaced with a unique - identifier for the logic loop. - - -select - replace the current selection with a selection of all cells and wires - that are part of a found logic loop - - -specify - examine specify rules to detect logic loops in whitebox/blackbox cells -\end{lstlisting} - -\section{scratchpad -- get/set values in the scratchpad} -\label{cmd:scratchpad} -\begin{lstlisting}[numbers=left,frame=single] - scratchpad [options] - -This pass allows to read and modify values from the scratchpad of the current -design. Options: - - -get <identifier> - print the value saved in the scratchpad under the given identifier. - - -set <identifier> <value> - save the given value in the scratchpad under the given identifier. - - -unset <identifier> - remove the entry for the given identifier from the scratchpad. - - -copy <identifier_from> <identifier_to> - copy the value of the first identifier to the second identifier. - - -assert <identifier> <value> - assert that the entry for the given identifier is set to the given - value. - - -assert-set <identifier> - assert that the entry for the given identifier exists. - - -assert-unset <identifier> - assert that the entry for the given identifier does not exist. - -The identifier may not contain whitespace. By convention, it is usually prefixed -by the name of the pass that uses it, e.g. 'opt.did_something'. If the value -contains whitespace, it must be enclosed in double quotes. -\end{lstlisting} - -\section{script -- execute commands from file or wire} -\label{cmd:script} -\begin{lstlisting}[numbers=left,frame=single] - script <filename> [<from_label>:<to_label>] - script -scriptwire [selection] - -This command executes the yosys commands in the specified file (default -behaviour), or commands embedded in the constant text value connected to the -selected wires. - -In the default (file) case, the 2nd argument can be used to only execute the -section of the file between the specified labels. An empty from label is -synonymous with the beginning of the file and an empty to label is synonymous -with the end of the file. - -If only one label is specified (without ':') then only the block -marked with that label (until the next label) is executed. - -In "-scriptwire" mode, the commands on the selected wire(s) will be executed -in the scope of (and thus, relative to) the wires' owning module(s). This -'-module' mode can be exited by using the 'cd' command. -\end{lstlisting} - -\section{select -- modify and view the list of selected objects} -\label{cmd:select} -\begin{lstlisting}[numbers=left,frame=single] - select [ -add | -del | -set <name> ] {-read <filename> | <selection>} - select [ -unset <name> ] - select [ <assert_option> ] {-read <filename> | <selection>} - select [ -list | -write <filename> | -count | -clear ] - select -module <modname> - -Most commands use the list of currently selected objects to determine which part -of the design to operate on. This command can be used to modify and view this -list of selected objects. - -Note that many commands support an optional [selection] argument that can be -used to override the global selection for the command. The syntax of this -optional argument is identical to the syntax of the <selection> argument -described here. - - -add, -del - add or remove the given objects to the current selection. - without this options the current selection is replaced. - - -set <name> - do not modify the current selection. instead save the new selection - under the given name (see @<name> below). to save the current selection, - use "select -set <name> %" - - -unset <name> - do not modify the current selection. instead remove a previously saved - selection under the given name (see @<name> below). - - -assert-none - do not modify the current selection. instead assert that the given - selection is empty. i.e. produce an error if any object or module - matching the selection is found. - - -assert-any - do not modify the current selection. instead assert that the given - selection is non-empty. i.e. produce an error if no object or module - matching the selection is found. - - -assert-count N - do not modify the current selection. instead assert that the given - selection contains exactly N objects. - - -assert-max N - do not modify the current selection. instead assert that the given - selection contains less than or exactly N objects. - - -assert-min N - do not modify the current selection. instead assert that the given - selection contains at least N objects. - - -list - list all objects in the current selection - - -write <filename> - like -list but write the output to the specified file - - -read <filename> - read the specified file (written by -write) - - -count - count all objects in the current selection - - -clear - clear the current selection. this effectively selects the whole - design. it also resets the selected module (see -module). use the - command 'select *' to select everything but stay in the current module. - - -none - create an empty selection. the current module is unchanged. - - -module <modname> - limit the current scope to the specified module. - the difference between this and simply selecting the module - is that all object names are interpreted relative to this - module after this command until the selection is cleared again. - -When this command is called without an argument, the current selection -is displayed in a compact form (i.e. only the module name when a whole module -is selected). - -The <selection> argument itself is a series of commands for a simple stack -machine. Each element on the stack represents a set of selected objects. -After this commands have been executed, the union of all remaining sets -on the stack is computed and used as selection for the command. - -Pushing (selecting) object when not in -module mode: - - <mod_pattern> - select the specified module(s) - - <mod_pattern>/<obj_pattern> - select the specified object(s) from the module(s) - -Pushing (selecting) object when in -module mode: - - <obj_pattern> - select the specified object(s) from the current module - -By default, patterns will not match black/white-box modules or their -contents. To include such objects, prefix the pattern with '='. - -A <mod_pattern> can be a module name, wildcard expression (*, ?, [..]) -matching module names, or one of the following: - - A:<pattern>, A:<pattern>=<pattern> - all modules with an attribute matching the given pattern - in addition to = also <, <=, >=, and > are supported - - N:<pattern> - all modules with a name matching the given pattern - (i.e. 'N:' is optional as it is the default matching rule) - -An <obj_pattern> can be an object name, wildcard expression, or one of -the following: - - w:<pattern> - all wires with a name matching the given wildcard pattern - - i:<pattern>, o:<pattern>, x:<pattern> - all inputs (i:), outputs (o:) or any ports (x:) with matching names - - s:<size>, s:<min>:<max> - all wires with a matching width - - m:<pattern> - all memories with a name matching the given pattern - - c:<pattern> - all cells with a name matching the given pattern - - t:<pattern> - all cells with a type matching the given pattern - - p:<pattern> - all processes with a name matching the given pattern - - a:<pattern> - all objects with an attribute name matching the given pattern - - a:<pattern>=<pattern> - all objects with a matching attribute name-value-pair. - in addition to = also <, <=, >=, and > are supported - - r:<pattern>, r:<pattern>=<pattern> - cells with matching parameters. also with <, <=, >= and >. - - n:<pattern> - all objects with a name matching the given pattern - (i.e. 'n:' is optional as it is the default matching rule) - - @<name> - push the selection saved prior with 'select -set <name> ...' - -The following actions can be performed on the top sets on the stack: - - % - push a copy of the current selection to the stack - - %% - replace the stack with a union of all elements on it - - %n - replace top set with its invert - - %u - replace the two top sets on the stack with their union - - %i - replace the two top sets on the stack with their intersection - - %d - pop the top set from the stack and subtract it from the new top - - %D - like %d but swap the roles of two top sets on the stack - - %c - create a copy of the top set from the stack and push it - - %x[<num1>|*][.<num2>][:<rule>[:<rule>..]] - expand top set <num1> num times according to the specified rules. - (i.e. select all cells connected to selected wires and select all - wires connected to selected cells) The rules specify which cell - ports to use for this. the syntax for a rule is a '-' for exclusion - and a '+' for inclusion, followed by an optional comma separated - list of cell types followed by an optional comma separated list of - cell ports in square brackets. a rule can also be just a cell or wire - name that limits the expansion (is included but does not go beyond). - select at most <num2> objects. a warning message is printed when this - limit is reached. When '*' is used instead of <num1> then the process - is repeated until no further object are selected. - - %ci[<num1>|*][.<num2>][:<rule>[:<rule>..]] - %co[<num1>|*][.<num2>][:<rule>[:<rule>..]] - similar to %x, but only select input (%ci) or output cones (%co) - - %xe[...] %cie[...] %coe - like %x, %ci, and %co but only consider combinatorial cells - - %a - expand top set by selecting all wires that are (at least in part) - aliases for selected wires. - - %s - expand top set by adding all modules that implement cells in selected - modules - - %m - expand top set by selecting all modules that contain selected objects - - %M - select modules that implement selected cells - - %C - select cells that implement selected modules - - %R[<num>] - select <num> random objects from top selection (default 1) - -Example: the following command selects all wires that are connected to a -'GATE' input of a 'SWITCH' cell: - - select */t:SWITCH %x:+[GATE] */t:SWITCH %d -\end{lstlisting} - -\section{setattr -- set/unset attributes on objects} -\label{cmd:setattr} -\begin{lstlisting}[numbers=left,frame=single] - setattr [ -mod ] [ -set name value | -unset name ]... [selection] - -Set/unset the given attributes on the selected objects. String values must be -passed in double quotes ("). - -When called with -mod, this command will set and unset attributes on modules -instead of objects within modules. -\end{lstlisting} - -\section{setparam -- set/unset parameters on objects} -\label{cmd:setparam} -\begin{lstlisting}[numbers=left,frame=single] - setparam [ -type cell_type ] [ -set name value | -unset name ]... [selection] - -Set/unset the given parameters on the selected cells. String values must be -passed in double quotes ("). - -The -type option can be used to change the cell type of the selected cells. -\end{lstlisting} - -\section{setundef -- replace undef values with defined constants} -\label{cmd:setundef} -\begin{lstlisting}[numbers=left,frame=single] - setundef [options] [selection] - -This command replaces undef (x) constants with defined (0/1) constants. - - -undriven - also set undriven nets to constant values - - -expose - also expose undriven nets as inputs (use with -undriven) - - -zero - replace with bits cleared (0) - - -one - replace with bits set (1) - - -undef - replace with undef (x) bits, may be used with -undriven - - -anyseq - replace with $anyseq drivers (for formal) - - -anyconst - replace with $anyconst drivers (for formal) - - -random <seed> - replace with random bits using the specified integer as seed - value for the random number generator. - - -init - also create/update init values for flip-flops - - -params - replace undef in cell parameters -\end{lstlisting} - -\section{share -- perform sat-based resource sharing} -\label{cmd:share} -\begin{lstlisting}[numbers=left,frame=single] - share [options] [selection] - -This pass merges shareable resources into a single resource. A SAT solver -is used to determine if two resources are share-able. - - -force - Per default the selection of cells that is considered for sharing is - narrowed using a list of cell types. With this option all selected - cells are considered for resource sharing. - - IMPORTANT NOTE: If the -all option is used then no cells with internal - state must be selected! - - -aggressive - Per default some heuristics are used to reduce the number of cells - considered for resource sharing to only large resources. This options - turns this heuristics off, resulting in much more cells being considered - for resource sharing. - - -fast - Only consider the simple part of the control logic in SAT solving, resulting - in much easier SAT problems at the cost of maybe missing some opportunities - for resource sharing. - - -limit N - Only perform the first N merges, then stop. This is useful for debugging. -\end{lstlisting} - -\section{shell -- enter interactive command mode} -\label{cmd:shell} -\begin{lstlisting}[numbers=left,frame=single] - shell - -This command enters the interactive command mode. This can be useful -in a script to interrupt the script at a certain point and allow for -interactive inspection or manual synthesis of the design at this point. - -The command prompt of the interactive shell indicates the current -selection (see 'help select'): - - yosys> - the entire design is selected - - yosys*> - only part of the design is selected - - yosys [modname]> - the entire module 'modname' is selected using 'select -module modname' - - yosys [modname]*> - only part of current module 'modname' is selected - -When in interactive shell, some errors (e.g. invalid command arguments) -do not terminate yosys but return to the command prompt. - -This command is the default action if nothing else has been specified -on the command line. - -Press Ctrl-D or type 'exit' to leave the interactive shell. -\end{lstlisting} - -\section{show -- generate schematics using graphviz} -\label{cmd:show} -\begin{lstlisting}[numbers=left,frame=single] - show [options] [selection] - -Create a graphviz DOT file for the selected part of the design and compile it -to a graphics file (usually SVG or PostScript). - - -viewer <viewer> - Run the specified command with the graphics file as parameter. - On Windows, this pauses yosys until the viewer exits. - - -format <format> - Generate a graphics file in the specified format. Use 'dot' to just - generate a .dot file, or other <format> strings such as 'svg' or 'ps' - to generate files in other formats (this calls the 'dot' command). - - -lib <verilog_or_rtlil_file> - Use the specified library file for determining whether cell ports are - inputs or outputs. This option can be used multiple times to specify - more than one library. - - note: in most cases it is better to load the library before calling - show with 'read_verilog -lib <filename>'. it is also possible to - load liberty files with 'read_liberty -lib <filename>'. - - -prefix <prefix> - generate <prefix>.* instead of ~/.yosys_show.* - - -color <color> <object> - assign the specified color to the specified object. The object can be - a single selection wildcard expressions or a saved set of objects in - the @<name> syntax (see "help select" for details). - - -label <text> <object> - assign the specified label text to the specified object. The object can - be a single selection wildcard expressions or a saved set of objects in - the @<name> syntax (see "help select" for details). - - -colors <seed> - Randomly assign colors to the wires. The integer argument is the seed - for the random number generator. Change the seed value if the colored - graph still is ambiguous. A seed of zero deactivates the coloring. - - -colorattr <attribute_name> - Use the specified attribute to assign colors. A unique color is - assigned to each unique value of this attribute. - - -width - annotate buses with a label indicating the width of the bus. - - -signed - mark ports (A, B) that are declared as signed (using the [AB]_SIGNED - cell parameter) with an asterisk next to the port name. - - -stretch - stretch the graph so all inputs are on the left side and all outputs - (including inout ports) are on the right side. - - -pause - wait for the user to press enter to before returning - - -enum - enumerate objects with internal ($-prefixed) names - - -long - do not abbreviate objects with internal ($-prefixed) names - - -notitle - do not add the module name as graph title to the dot file - - -nobg - don't run viewer in the background, IE wait for the viewer tool to - exit before returning - -When no <format> is specified, 'dot' is used. When no <format> and <viewer> is -specified, 'xdot' is used to display the schematic (POSIX systems only). - -The generated output files are '~/.yosys_show.dot' and '~/.yosys_show.<format>', -unless another prefix is specified using -prefix <prefix>. - -Yosys on Windows and YosysJS use different defaults: The output is written -to 'show.dot' in the current directory and new viewer is launched each time -the 'show' command is executed. -\end{lstlisting} - -\section{shregmap -- map shift registers} -\label{cmd:shregmap} -\begin{lstlisting}[numbers=left,frame=single] - shregmap [options] [selection] - -This pass converts chains of $_DFF_[NP]_ gates to target specific shift register -primitives. The generated shift register will be of type $__SHREG_DFF_[NP]_ and -will use the same interface as the original $_DFF_*_ cells. The cell parameter -'DEPTH' will contain the depth of the shift register. Use a target-specific -'techmap' map file to convert those cells to the actual target cells. - - -minlen N - minimum length of shift register (default = 2) - (this is the length after -keep_before and -keep_after) - - -maxlen N - maximum length of shift register (default = no limit) - larger chains will be mapped to multiple shift register instances - - -keep_before N - number of DFFs to keep before the shift register (default = 0) - - -keep_after N - number of DFFs to keep after the shift register (default = 0) - - -clkpol pos|neg|any - limit match to only positive or negative edge clocks. (default = any) - - -enpol pos|neg|none|any_or_none|any - limit match to FFs with the specified enable polarity. (default = none) - - -match <cell_type>[:<d_port_name>:<q_port_name>] - match the specified cells instead of $_DFF_N_ and $_DFF_P_. If - ':<d_port_name>:<q_port_name>' is omitted then 'D' and 'Q' is used - by default. E.g. the option '-clkpol pos' is just an alias for - '-match $_DFF_P_', which is an alias for '-match $_DFF_P_:D:Q'. - - -params - instead of encoding the clock and enable polarity in the cell name by - deriving from the original cell name, simply name all generated cells - $__SHREG_ and use CLKPOL and ENPOL parameters. An ENPOL value of 2 is - used to denote cells without enable input. The ENPOL parameter is - omitted when '-enpol none' (or no -enpol option) is passed. - - -zinit - assume the shift register is automatically zero-initialized, so it - becomes legal to merge zero initialized FFs into the shift register. - - -init - map initialized registers to the shift reg, add an INIT parameter to - generated cells with the initialization value. (first bit to shift out - in LSB position) - - -tech greenpak4 - map to greenpak4 shift registers. -\end{lstlisting} - -\section{sim -- simulate the circuit} -\label{cmd:sim} -\begin{lstlisting}[numbers=left,frame=single] - sim [options] [top-level] - -This command simulates the circuit using the given top-level module. - - -vcd <filename> - write the simulation results to the given VCD file - - -fst <filename> - write the simulation results to the given FST file - - -aiw <filename> - write the simulation results to an AIGER witness file - (requires a *.aim file via -map) - - -hdlname - use the hdlname attribute when writing simulation results - (preserves hierarchy in a flattened design) - - -x - ignore constant x outputs in simulation file. - - -date - include date and full version info in output. - - -clock <portname> - name of top-level clock input - - -clockn <portname> - name of top-level clock input (inverse polarity) - - -multiclock - mark that witness file is multiclock. - - -reset <portname> - name of top-level reset input (active high) - - -resetn <portname> - name of top-level inverted reset input (active low) - - -rstlen <integer> - number of cycles reset should stay active (default: 1) - - -zinit - zero-initialize all uninitialized regs and memories - - -timescale <string> - include the specified timescale declaration in the vcd - - -n <integer> - number of clock cycles to simulate (default: 20) - - -a - use all nets in VCD/FST operations, not just those with public names - - -w - writeback mode: use final simulation state as new init state - - -r - read simulation results file - File formats supported: FST, VCD, AIW and WIT - VCD support requires vcd2fst external tool to be present - - -map <filename> - read file with port and latch symbols, needed for AIGER witness input - - -scope <name> - scope of simulation top model - - -at <time> - sets start and stop time - - -start <time> - start co-simulation in arbitary time (default 0) - - -stop <time> - stop co-simulation in arbitary time (default END) - - -sim - simulation with stimulus from FST (default) - - -sim-cmp - co-simulation expect exact match - - -sim-gold - co-simulation, x in simulation can match any value in FST - - -sim-gate - co-simulation, x in FST can match any value in simulation - - -q - disable per-cycle/sample log message - - -d - enable debug output -\end{lstlisting} - -\section{simplemap -- mapping simple coarse-grain cells} -\label{cmd:simplemap} -\begin{lstlisting}[numbers=left,frame=single] - simplemap [selection] - -This pass maps a small selection of simple coarse-grain cells to yosys gate -primitives. The following internal cell types are mapped by this pass: - - $not, $pos, $and, $or, $xor, $xnor - $reduce_and, $reduce_or, $reduce_xor, $reduce_xnor, $reduce_bool - $logic_not, $logic_and, $logic_or, $mux, $tribuf - $sr, $ff, $dff, $dffe, $dffsr, $dffsre, $adff, $adffe, $aldff, $aldffe, $sdff, - $sdffe, $sdffce, $dlatch, $adlatch, $dlatchsr -\end{lstlisting} - -\section{splice -- create explicit splicing cells} -\label{cmd:splice} -\begin{lstlisting}[numbers=left,frame=single] - splice [options] [selection] - -This command adds $slice and $concat cells to the design to make the splicing -of multi-bit signals explicit. This for example is useful for coarse grain -synthesis, where dedicated hardware is needed to splice signals. - - -sel_by_cell - only select the cell ports to rewire by the cell. if the selection - contains a cell, than all cell inputs are rewired, if necessary. - - -sel_by_wire - only select the cell ports to rewire by the wire. if the selection - contains a wire, than all cell ports driven by this wire are wired, - if necessary. - - -sel_any_bit - it is sufficient if the driver of any bit of a cell port is selected. - by default all bits must be selected. - - -wires - also add $slice and $concat cells to drive otherwise unused wires. - - -no_outputs - do not rewire selected module outputs. - - -port <name> - only rewire cell ports with the specified name. can be used multiple - times. implies -no_output. - - -no_port <name> - do not rewire cell ports with the specified name. can be used multiple - times. can not be combined with -port <name>. - -By default selected output wires and all cell ports of selected cells driven -by selected wires are rewired. -\end{lstlisting} - -\section{splitnets -- split up multi-bit nets} -\label{cmd:splitnets} -\begin{lstlisting}[numbers=left,frame=single] - splitnets [options] [selection] - -This command splits multi-bit nets into single-bit nets. - - -format char1[char2[char3]] - the first char is inserted between the net name and the bit index, the - second char is appended to the netname. e.g. -format () creates net - names like 'mysignal(42)'. the 3rd character is the range separation - character when creating multi-bit wires. the default is '[]:'. - - -ports - also split module ports. per default only internal signals are split. - - -driver - don't blindly split nets in individual bits. instead look at the driver - and split nets so that no driver drives only part of a net. -\end{lstlisting} - -\section{sta -- perform static timing analysis} -\label{cmd:sta} -\begin{lstlisting}[numbers=left,frame=single] - sta [options] [selection] - -This command performs static timing analysis on the design. (Only considers -paths within a single module, so the design must be flattened.) -\end{lstlisting} - -\section{stat -- print some statistics} -\label{cmd:stat} -\begin{lstlisting}[numbers=left,frame=single] - stat [options] [selection] - -Print some statistics (number of objects) on the selected portion of the -design. - - -top <module> - print design hierarchy with this module as top. if the design is fully - selected and a module has the 'top' attribute set, this module is used - default value for this option. - - -liberty <liberty_file> - use cell area information from the provided liberty file - - -tech <technology> - print area estemate for the specified technology. Currently supported - values for <technology>: xilinx, cmos - - -width - annotate internal cell types with their word width. - e.g. $add_8 for an 8 bit wide $add cell. - - -json - output the statistics in a machine-readable JSON format. - this is output to the console; use "tee" to output to a file. -\end{lstlisting} - -\section{submod -- moving part of a module to a new submodule} -\label{cmd:submod} -\begin{lstlisting}[numbers=left,frame=single] - submod [options] [selection] - -This pass identifies all cells with the 'submod' attribute and moves them to -a newly created module. The value of the attribute is used as name for the -cell that replaces the group of cells with the same attribute value. - -This pass can be used to create a design hierarchy in flat design. This can -be useful for analyzing or reverse-engineering a design. - -This pass only operates on completely selected modules with no processes -or memories. - - -copy - by default the cells are 'moved' from the source module and the source - module will use an instance of the new module after this command is - finished. call with -copy to not modify the source module. - - -name <name> - don't use the 'submod' attribute but instead use the selection. only - objects from one module might be selected. the value of the -name option - is used as the value of the 'submod' attribute instead. - - -hidden - instead of creating submodule ports with public names, create ports with - private names so that a subsequent 'flatten; clean' call will restore - the original module with original public names. -\end{lstlisting} - -\section{supercover -- add hi/lo cover cells for each wire bit} -\label{cmd:supercover} -\begin{lstlisting}[numbers=left,frame=single] - supercover [options] [selection] - -This command adds two cover cells for each bit of each selected wire, one -checking for a hi signal level and one checking for lo level. -\end{lstlisting} - -\section{synth -- generic synthesis script} -\label{cmd:synth} -\begin{lstlisting}[numbers=left,frame=single] - synth [options] - -This command runs the default synthesis script. This command does not operate -on partly selected designs. - - -top <module> - use the specified module as top module (default='top') - - -auto-top - automatically determine the top of the design hierarchy - - -flatten - flatten the design before synthesis. this will pass '-auto-top' to - 'hierarchy' if no top module is specified. - - -encfile <file> - passed to 'fsm_recode' via 'fsm' - - -lut <k> - perform synthesis for a k-LUT architecture. - - -nofsm - do not run FSM optimization - - -noabc - do not run abc (as if yosys was compiled without ABC support) - - -noalumacc - do not run 'alumacc' pass. i.e. keep arithmetic operators in - their direct form ($add, $sub, etc.). - - -nordff - passed to 'memory'. prohibits merging of FFs into memory read ports - - -noshare - do not run SAT-based resource sharing - - -run <from_label>[:<to_label>] - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -abc9 - use new ABC9 flow (EXPERIMENTAL) - - -flowmap - use FlowMap LUT techmapping instead of ABC - - -no-rw-check - marks all recognized read ports as "return don't-care value on - read/write collision" (same result as setting the no_rw_check - attribute on all memories). - - -The following commands are executed by this synthesis command: - - begin: - hierarchy -check [-top <top> | -auto-top] - - coarse: - proc - flatten (if -flatten) - opt_expr - opt_clean - check - opt -nodffe -nosdff - fsm (unless -nofsm) - opt - wreduce - peepopt - opt_clean - techmap -map +/cmp2lut.v -map +/cmp2lcu.v (if -lut) - alumacc (unless -noalumacc) - share (unless -noshare) - opt - memory -nomap - opt_clean - - fine: - opt -fast -full - memory_map - opt -full - techmap - techmap -map +/gate2lut.v (if -noabc and -lut) - clean; opt_lut (if -noabc and -lut) - flowmap -maxlut K (if -flowmap and -lut) - opt -fast - abc -fast (unless -noabc, unless -lut) - abc -fast -lut k (unless -noabc, if -lut) - opt -fast (unless -noabc) - - check: - hierarchy -check - stat - check -\end{lstlisting} - -\section{synth\_achronix -- synthesis for Acrhonix Speedster22i FPGAs.} -\label{cmd:synth_achronix} -\begin{lstlisting}[numbers=left,frame=single] - synth_achronix [options] - -This command runs synthesis for Achronix Speedster eFPGAs. This work is still experimental. - - -top <module> - use the specified module as top module (default='top') - - -vout <file> - write the design to the specified Verilog netlist file. writing of an - output file is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -retime - run 'abc' with '-dff -D 1' options - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -sv -lib +/achronix/speedster22i/cells_sim.v - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - tribuf -logic - deminout - - coarse: - synth -run coarse - - fine: - opt -fast -mux_undef -undriven -fine -full - memory_map - opt -undriven -fine - opt -fine - techmap -map +/techmap.v - opt -full - clean -purge - setundef -undriven -zero - dfflegalize -cell $_DFF_P_ x - abc -markgroups -dff -D 1 (only if -retime) - - map_luts: - abc -lut 4 - clean - - map_cells: - iopadmap -bits -outpad $__outpad I:O -inpad $__inpad O:I - techmap -map +/achronix/speedster22i/cells_map.v - clean -purge - - check: - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - vout: - write_verilog -nodec -attr2comment -defparam -renameprefix syn_ <file-name> -\end{lstlisting} - -\section{synth\_anlogic -- synthesis for Anlogic FPGAs} -\label{cmd:synth_anlogic} -\begin{lstlisting}[numbers=left,frame=single] - synth_anlogic [options] - -This command runs synthesis for Anlogic FPGAs. - - -top <module> - use the specified module as top module - - -edif <file> - write the design to the specified EDIF file. writing of an output file - is omitted if this parameter is not specified. - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -retime - run 'abc' with '-dff -D 1' options - - -nolutram - do not use EG_LOGIC_DRAM16X4 cells in output netlist - - -nobram - do not use EG_PHY_BRAM or EG_PHY_BRAM32K cells in output netlist - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib +/anlogic/cells_sim.v +/anlogic/eagle_bb.v - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - tribuf -logic - deminout - - coarse: - synth -run coarse - - map_ram: - memory_libmap -lib +/anlogic/lutrams.txt -lib +/anlogic/brams.txt [-no-auto-block] [-no-auto-distributed] (-no-auto-block if -nobram, -no-auto-distributed if -nolutram) - techmap -map +/anlogic/lutrams_map.v -map +/anlogic/brams_map.v - - map_ffram: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - - map_gates: - techmap -map +/techmap.v -map +/anlogic/arith_map.v - opt -fast - abc -dff -D 1 (only if -retime) - - map_ffs: - dfflegalize -cell $_DFFE_P??P_ r -cell $_SDFFE_P??P_ r -cell $_DLATCH_N??_ r - techmap -D NO_LUT -map +/anlogic/cells_map.v - opt_expr -mux_undef - simplemap - - map_luts: - abc -lut 4:6 - clean - - map_cells: - techmap -map +/anlogic/cells_map.v - clean - - map_anlogic: - anlogic_fixcarry - anlogic_eqn - - check: - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - edif: - write_edif <file-name> - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_coolrunner2 -- synthesis for Xilinx Coolrunner-II CPLDs} -\label{cmd:synth_coolrunner2} -\begin{lstlisting}[numbers=left,frame=single] - synth_coolrunner2 [options] - -This command runs synthesis for Coolrunner-II CPLDs. This work is experimental. -It is intended to be used with https://github.com/azonenberg/openfpga as the -place-and-route. - - -top <module> - use the specified module as top module (default='top') - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -retime - run 'abc' with '-dff -D 1' options - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib +/coolrunner2/cells_sim.v - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - tribuf -logic - - coarse: - synth -run coarse - - fine: - extract_counter -dir up -allow_arst no - techmap -map +/coolrunner2/cells_counter_map.v - clean - opt -fast -full - techmap -map +/techmap.v -map +/coolrunner2/cells_latch.v - opt -fast - dfflibmap -prepare -liberty +/coolrunner2/xc2_dff.lib - - map_tff: - abc -g AND,XOR - clean - extract -map +/coolrunner2/tff_extract.v - - map_pla: - abc -sop -I 40 -P 56 - clean - - map_cells: - dfflibmap -liberty +/coolrunner2/xc2_dff.lib - dffinit -ff FDCP Q INIT - dffinit -ff FDCP_N Q INIT - dffinit -ff FTCP Q INIT - dffinit -ff FTCP_N Q INIT - dffinit -ff LDCP Q INIT - dffinit -ff LDCP_N Q INIT - coolrunner2_sop - clean - iopadmap -bits -inpad IBUF O:I -outpad IOBUFE I:IO -inoutpad IOBUFE O:IO -toutpad IOBUFE E:I:IO -tinoutpad IOBUFE E:O:I:IO - attrmvcp -attr src -attr LOC t:IOBUFE n:* - attrmvcp -attr src -attr LOC -driven t:IBUF n:* - coolrunner2_fixup - splitnets - clean - - check: - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_easic -- synthesis for eASIC platform} -\label{cmd:synth_easic} -\begin{lstlisting}[numbers=left,frame=single] - synth_easic [options] - -This command runs synthesis for eASIC platform. - - -top <module> - use the specified module as top module - - -vlog <file> - write the design to the specified structural Verilog file. writing of - an output file is omitted if this parameter is not specified. - - -etools <path> - set path to the eTools installation. (default=/opt/eTools) - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -retime - run 'abc' with '-dff -D 1' options - - -The following commands are executed by this synthesis command: - - begin: - read_liberty -lib <etools_phys_clk_lib> - read_liberty -lib <etools_logic_lut_lib> - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - - coarse: - synth -run coarse - - fine: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - techmap - opt -fast - abc -dff -D 1 (only if -retime) - opt_clean (only if -retime) - - map: - dfflibmap -liberty <etools_phys_clk_lib> - abc -liberty <etools_logic_lut_lib> - opt_clean - - check: - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - vlog: - write_verilog -noexpr -attr2comment <file-name> -\end{lstlisting} - -\section{synth\_ecp5 -- synthesis for ECP5 FPGAs} -\label{cmd:synth_ecp5} -\begin{lstlisting}[numbers=left,frame=single] - synth_ecp5 [options] - -This command runs synthesis for ECP5 FPGAs. - - -top <module> - use the specified module as top module - - -blif <file> - write the design to the specified BLIF file. writing of an output file - is omitted if this parameter is not specified. - - -edif <file> - write the design to the specified EDIF file. writing of an output file - is omitted if this parameter is not specified. - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -dff - run 'abc'/'abc9' with -dff option - - -retime - run 'abc' with '-dff -D 1' options - - -noccu2 - do not use CCU2 cells in output netlist - - -nodffe - do not use flipflops with CE in output netlist - - -nobram - do not use block RAM cells in output netlist - - -nolutram - do not use LUT RAM cells in output netlist - - -nowidelut - do not use PFU muxes to implement LUTs larger than LUT4s - - -asyncprld - use async PRLD mode to implement ALDFF (EXPERIMENTAL) - - -abc2 - run two passes of 'abc' for slightly improved logic density - - -abc9 - use new ABC9 flow (EXPERIMENTAL) - - -vpr - generate an output netlist (and BLIF file) suitable for VPR - (this feature is experimental and incomplete) - - -nodsp - do not map multipliers to MULT18X18D - - -no-rw-check - marks all recognized read ports as "return don't-care value on - read/write collision" (same result as setting the no_rw_check - attribute on all memories). - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib -specify +/ecp5/cells_sim.v +/ecp5/cells_bb.v - hierarchy -check -top <top> - - coarse: - proc - flatten - tribuf -logic - deminout - opt_expr - opt_clean - check - opt -nodffe -nosdff - fsm - opt - wreduce - peepopt - opt_clean - share - techmap -map +/cmp2lut.v -D LUT_WIDTH=4 - opt_expr - opt_clean - techmap -map +/mul2dsp.v -map +/ecp5/dsp_map.v -D DSP_A_MAXWIDTH=18 -D DSP_B_MAXWIDTH=18 -D DSP_A_MINWIDTH=2 -D DSP_B_MINWIDTH=2 -D DSP_NAME=$__MUL18X18 (unless -nodsp) - chtype -set $mul t:$__soft_mul (unless -nodsp) - alumacc - opt - memory -nomap [-no-rw-check] - opt_clean - - map_ram: - memory_libmap -lib +/ecp5/lutrams.txt -lib +/ecp5/brams.txt [-no-auto-block] [-no-auto-distributed] (-no-auto-block if -nobram, -no-auto-distributed if -nolutram) - techmap -map +/ecp5/lutrams_map.v -map +/ecp5/brams_map.v - - map_ffram: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - - map_gates: - techmap -map +/techmap.v -map +/ecp5/arith_map.v - opt -fast - abc -dff -D 1 (only if -retime) - - map_ffs: - opt_clean - dfflegalize -cell $_DFF_?_ 01 -cell $_DFF_?P?_ r -cell $_SDFF_?P?_ r [-cell $_DFFE_??_ 01 -cell $_DFFE_?P??_ r -cell $_SDFFE_?P??_ r] [-cell $_ALDFF_?P_ x -cell $_ALDFFE_?P?_ x] [-cell $_DLATCH_?_ x] ($_ALDFF_*_ only if -asyncprld, $_DLATCH_* only if not -asyncprld, $_*DFFE_* only if not -nodffe) - zinit -all w:* t:$_DFF_?_ t:$_DFFE_??_ t:$_SDFF* (only if -abc9 and -dff) - techmap -D NO_LUT -map +/ecp5/cells_map.v - opt_expr -undriven -mux_undef - simplemap - ecp5_gsr - attrmvcp -copy -attr syn_useioff - opt_clean - - map_luts: - abc (only if -abc2) - techmap -map +/ecp5/latches_map.v (skip if -asyncprld) - abc -dress -lut 4:7 - clean - - map_cells: - techmap -map +/ecp5/cells_map.v (skip if -vpr) - opt_lut_ins -tech ecp5 - clean - - check: - autoname - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - blif: - opt_clean -purge (vpr mode) - write_blif -attr -cname -conn -param <file-name> (vpr mode) - write_blif -gates -attr -param <file-name> (non-vpr mode) - - edif: - write_edif <file-name> - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_efinix -- synthesis for Efinix FPGAs} -\label{cmd:synth_efinix} -\begin{lstlisting}[numbers=left,frame=single] - synth_efinix [options] - -This command runs synthesis for Efinix FPGAs. - - -top <module> - use the specified module as top module - - -edif <file> - write the design to the specified EDIF file. writing of an output file - is omitted if this parameter is not specified. - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -retime - run 'abc' with '-dff -D 1' options - - -nobram - do not use EFX_RAM_5K cells in output netlist - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib +/efinix/cells_sim.v - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - tribuf -logic - deminout - - coarse: - synth -run coarse - - map_ram: - memory_libmap -lib +/efinix/brams.txt - techmap -map +/efinix/brams_map.v - - map_ffram: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - - map_gates: - techmap -map +/techmap.v -map +/efinix/arith_map.v - opt -fast - abc -dff -D 1 (only if -retime) - - map_ffs: - dfflegalize -cell $_DFFE_????_ 0 -cell $_SDFFE_????_ 0 -cell $_SDFFCE_????_ 0 -cell $_DLATCH_?_ x - techmap -D NO_LUT -map +/efinix/cells_map.v - opt_expr -mux_undef - simplemap - - map_luts: - abc -lut 4 - clean - - map_cells: - techmap -map +/efinix/cells_map.v - clean - - map_gbuf: - clkbufmap -buf $__EFX_GBUF O:I - techmap -map +/efinix/gbuf_map.v - efinix_fixcarry - clean - - check: - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - edif: - write_edif <file-name> - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_fabulous -- FABulous synthesis script} -\label{cmd:synth_fabulous} -\begin{lstlisting}[numbers=left,frame=single] - synth_fabulous [options] - -This command runs synthesis for FPGA fabrics generated with FABulous. This command does not operate -on partly selected designs. - - -top <module> - use the specified module as top module (default='top') - - -auto-top - automatically determine the top of the design hierarchy - - -blif <file> - write the design to the specified BLIF file. writing of an output file - is omitted if this parameter is not specified. - - -edif <file> - write the design to the specified EDIF file. writing of an output file - is omitted if this parameter is not specified. - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -lut <k> - perform synthesis for a k-LUT architecture (default 4). - - -vpr - perform synthesis for the FABulous VPR flow (using slightly different techmapping). - - -plib <primitive_library.v> - use the specified Verilog file as a primitive library. - - -extra-plib <primitive_library.v> - use the specified Verilog file for extra primitives (can be specified multiple - times). - - -extra-map <techamp.v> - use the specified Verilog file for extra techmap rules (can be specified multiple - times). - - -encfile <file> - passed to 'fsm_recode' via 'fsm' - - -nofsm - do not run FSM optimization - - -noalumacc - do not run 'alumacc' pass. i.e. keep arithmetic operators in - their direct form ($add, $sub, etc.). - - -noregfile - do not map register files - - -iopad - enable automatic insertion of IO buffers (otherwise a wrapper - with manually inserted and constrained IO should be used.) - - -complex-dff - enable support for FFs with enable and synchronous SR (must also be - supported by the target fabric.) - - -noflatten - do not flatten design after elaboration - - -nordff - passed to 'memory'. prohibits merging of FFs into memory read ports - - -noshare - do not run SAT-based resource sharing - - -run <from_label>[:<to_label>] - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -no-rw-check - marks all recognized read ports as "return don't-care value on - read/write collision" (same result as setting the no_rw_check - attribute on all memories). - - -The following commands are executed by this synthesis command: - read_verilog -lib +/fabulous/prims.v - read_verilog -lib <extra_plib.v> (for each -extra-plib) - - begin: - hierarchy -check - proc - - flatten: (unless -noflatten) - flatten - tribuf -logic - deminout - - coarse: - tribuf -logic - deminout - opt_expr - opt_clean - check - opt -nodffe -nosdff - fsm (unless -nofsm) - opt - wreduce - peepopt - opt_clean - techmap -map +/cmp2lut.v -map +/cmp2lcu.v (if -lut) - alumacc (unless -noalumacc) - share (unless -noshare) - opt - memory -nomap - opt_clean - - map_ram: - memory_libmap -lib +/fabulous/ram_regfile.txt - techmap -map +/fabulous/regfile_map.v - - map_ffram: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - - map_gates: - opt -full - techmap -map +/techmap.v - opt -fast - - map_iopad: (if -iopad) - - map_ffs: - dfflegalize -cell $_DFF_P_ 0 -cell $_DLATCH_?_ x without -complex-dff - techmap -map +/fabulous/latches_map.v - techmap -map +/fabulous/ff_map.v - techmap -map <extra_map.v>... (for each -extra-map) - clean - - map_luts: - abc -lut 4 -dress - clean - - map_cells: - techmap -D LUT_K=4 -map +/fabulous/cells_map.v - clean - - check: - hierarchy -check - stat - - blif: - opt_clean -purge - write_blif -attr -cname -conn -param <file-name> - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_gatemate -- synthesis for Cologne Chip GateMate FPGAs} -\label{cmd:synth_gatemate} -\begin{lstlisting}[numbers=left,frame=single] - synth_gatemate [options] - -This command runs synthesis for Cologne Chip AG GateMate FPGAs. - - -top <module> - use the specified module as top module. - - -vlog <file> - write the design to the specified verilog file. Writing of an output - file is omitted if this parameter is not specified. - - -json <file> - write the design to the specified JSON file. Writing of an output file - is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). An empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis. - - -nobram - do not use CC_BRAM_20K or CC_BRAM_40K cells in output netlist. - - -noaddf - do not use CC_ADDF full adder cells in output netlist. - - -nomult - do not use CC_MULT multiplier cells in output netlist. - - -nomx8, -nomx4 - do not use CC_MX{8,4} multiplexer cells in output netlist. - - -luttree - use new LUT tree mapping approach (EXPERIMENTAL). - - -dff - run 'abc' with -dff option - - -retime - run 'abc' with '-dff -D 1' options - - -noiopad - disable I/O buffer insertion (useful for hierarchical or - out-of-context flows). - - -noclkbuf - disable automatic clock buffer insertion. - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib -specify +/gatemate/cells_sim.v +/gatemate/cells_bb.v - hierarchy -check -top <top> - - prepare: - proc - flatten - tribuf -logic - deminout - opt_expr - opt_clean - check - opt -nodffe -nosdff - fsm - opt - wreduce - peepopt - opt_clean - muxpack - share - techmap -map +/cmp2lut.v -D LUT_WIDTH=4 - opt_expr - opt_clean - - map_mult: (skip if '-nomult') - techmap -map +/gatemate/mul_map.v - - coarse: - alumacc - opt - memory -nomap - opt_clean - - map_bram: (skip if '-nobram') - memory_libmap -lib +/gatemate/brams.txt - techmap -map +/gatemate/brams_map.v - - map_ffram: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - - map_gates: - techmap -map +/techmap.v -map +/gatemate/arith_map.v - opt -fast - - map_io: (skip if '-noiopad') - iopadmap -bits -inpad CC_IBUF Y:I -outpad CC_OBUF A:O -toutpad CC_TOBUF ~T:A:O -tinoutpad CC_IOBUF ~T:Y:A:IO - clean - - map_regs: - opt_clean - dfflegalize -cell $_DFFE_????_ x -cell $_DLATCH_???_ x - techmap -map +/gatemate/reg_map.v - opt_expr -mux_undef - simplemap - opt_clean - - map_muxs: - muxcover -mux4 -mux8 - opt -full - techmap -map +/gatemate/mux_map.v - - map_luts: - abc -genlib +/gatemate/lut_tree_cells.genlib (with -luttree) - techmap -map +/gatemate/lut_tree_map.v (with -luttree) - gatemate_foldinv (with -luttree) - techmap -map +/gatemate/inv_map.v (with -luttree) - abc -dress -lut 4 (without -luttree) - clean - - map_cells: - techmap -map +/gatemate/lut_map.v - clean - - map_bufg: (skip if '-noclkbuf') - clkbufmap -buf CC_BUFG O:I - clean - - check: - hierarchy -check - stat -width - check -noinit - blackbox =A:whitebox - - vlog: - opt_clean -purge - write_verilog -noattr <file-name> - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_gowin -- synthesis for Gowin FPGAs} -\label{cmd:synth_gowin} -\begin{lstlisting}[numbers=left,frame=single] - synth_gowin [options] - -This command runs synthesis for Gowin FPGAs. This work is experimental. - - -top <module> - use the specified module as top module (default='top') - - -vout <file> - write the design to the specified Verilog netlist file. writing of an - output file is omitted if this parameter is not specified. - - -json <file> - write the design to the specified JSON netlist file. writing of an - output file is omitted if this parameter is not specified. - This disables features not yet supported by nexpnr-gowin. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -nodffe - do not use flipflops with CE in output netlist - - -nobram - do not use BRAM cells in output netlist - - -nolutram - do not use distributed RAM cells in output netlist - - -noflatten - do not flatten design before synthesis - - -retime - run 'abc' with '-dff -D 1' options - - -nowidelut - do not use muxes to implement LUTs larger than LUT4s - - -noiopads - do not emit IOB at top level ports - - -noalu - do not use ALU cells - - -abc9 - use new ABC9 flow (EXPERIMENTAL) - - -no-rw-check - marks all recognized read ports as "return don't-care value on - read/write collision" (same result as setting the no_rw_check - attribute on all memories). - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -specify -lib +/gowin/cells_sim.v - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - tribuf -logic - deminout - - coarse: - synth -run coarse [-no-rw-check] - - map_ram: - memory_libmap -lib +/gowin/lutrams.txt -lib +/gowin/brams.txt [-no-auto-block] [-no-auto-distributed] (-no-auto-block if -nobram, -no-auto-distributed if -nolutram) - techmap -map +/gowin/lutrams_map.v -map +/gowin/brams_map.v - - map_ffram: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - - map_gates: - techmap -map +/techmap.v -map +/gowin/arith_map.v - opt -fast - abc -dff -D 1 (only if -retime) - iopadmap -bits -inpad IBUF O:I -outpad OBUF I:O -toutpad TBUF ~OEN:I:O -tinoutpad IOBUF ~OEN:O:I:IO (unless -noiopads) - - map_ffs: - opt_clean - dfflegalize -cell $_DFF_?_ 0 -cell $_DFFE_?P_ 0 -cell $_SDFF_?P?_ r -cell $_SDFFE_?P?P_ r -cell $_DFF_?P?_ r -cell $_DFFE_?P?P_ r - techmap -map +/gowin/cells_map.v - opt_expr -mux_undef - simplemap - - map_luts: - abc -lut 4:8 - clean - - map_cells: - techmap -map +/gowin/cells_map.v - opt_lut_ins -tech gowin - setundef -undriven -params -zero - hilomap -singleton -hicell VCC V -locell GND G - splitnets -ports (only if -vout used) - clean - autoname - - check: - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - vout: - write_verilog -simple-lhs -decimal -attr2comment -defparam -renameprefix gen <file-name> - write_json <file-name> -\end{lstlisting} - -\section{synth\_greenpak4 -- synthesis for GreenPAK4 FPGAs} -\label{cmd:synth_greenpak4} -\begin{lstlisting}[numbers=left,frame=single] - synth_greenpak4 [options] - -This command runs synthesis for GreenPAK4 FPGAs. This work is experimental. -It is intended to be used with https://github.com/azonenberg/openfpga as the -place-and-route. - - -top <module> - use the specified module as top module (default='top') - - -part <part> - synthesize for the specified part. Valid values are SLG46140V, - SLG46620V, and SLG46621V (default). - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -retime - run 'abc' with '-dff -D 1' options - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib +/greenpak4/cells_sim.v - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - tribuf -logic - - coarse: - synth -run coarse - - fine: - extract_counter -pout GP_DCMP,GP_DAC -maxwidth 14 - clean - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - techmap -map +/techmap.v -map +/greenpak4/cells_latch.v - dfflibmap -prepare -liberty +/greenpak4/gp_dff.lib - opt -fast -noclkinv -noff - abc -dff -D 1 (only if -retime) - - map_luts: - nlutmap -assert -luts 0,6,8,2 (for -part SLG46140V) - nlutmap -assert -luts 2,8,16,2 (for -part SLG46620V) - nlutmap -assert -luts 2,8,16,2 (for -part SLG46621V) - clean - - map_cells: - shregmap -tech greenpak4 - dfflibmap -liberty +/greenpak4/gp_dff.lib - dffinit -ff GP_DFF Q INIT - dffinit -ff GP_DFFR Q INIT - dffinit -ff GP_DFFS Q INIT - dffinit -ff GP_DFFSR Q INIT - iopadmap -bits -inpad GP_IBUF OUT:IN -outpad GP_OBUF IN:OUT -inoutpad GP_OBUF OUT:IN -toutpad GP_OBUFT OE:IN:OUT -tinoutpad GP_IOBUF OE:OUT:IN:IO - attrmvcp -attr src -attr LOC t:GP_OBUF t:GP_OBUFT t:GP_IOBUF n:* - attrmvcp -attr src -attr LOC -driven t:GP_IBUF n:* - techmap -map +/greenpak4/cells_map.v - greenpak4_dffinv - clean - - check: - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_ice40 -- synthesis for iCE40 FPGAs} -\label{cmd:synth_ice40} -\begin{lstlisting}[numbers=left,frame=single] - synth_ice40 [options] - -This command runs synthesis for iCE40 FPGAs. - - -device < hx | lp | u > - relevant only for '-abc9' flow, optimise timing for the specified - device. default: hx - - -top <module> - use the specified module as top module - - -blif <file> - write the design to the specified BLIF file. writing of an output file - is omitted if this parameter is not specified. - - -edif <file> - write the design to the specified EDIF file. writing of an output file - is omitted if this parameter is not specified. - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -dff - run 'abc'/'abc9' with -dff option - - -retime - run 'abc' with '-dff -D 1' options - - -nocarry - do not use SB_CARRY cells in output netlist - - -nodffe - do not use SB_DFFE* cells in output netlist - - -dffe_min_ce_use <min_ce_use> - do not use SB_DFFE* cells if the resulting CE line would go to less - than min_ce_use SB_DFFE* in output netlist - - -nobram - do not use SB_RAM40_4K* cells in output netlist - - -spram - enable automatic inference of SB_SPRAM256KA - - -dsp - use iCE40 UltraPlus DSP cells for large arithmetic - - -noabc - use built-in Yosys LUT techmapping instead of abc - - -abc2 - run two passes of 'abc' for slightly improved logic density - - -vpr - generate an output netlist (and BLIF file) suitable for VPR - (this feature is experimental and incomplete) - - -abc9 - use new ABC9 flow (EXPERIMENTAL) - - -flowmap - use FlowMap LUT techmapping instead of abc (EXPERIMENTAL) - - -no-rw-check - marks all recognized read ports as "return don't-care value on - read/write collision" (same result as setting the no_rw_check - attribute on all memories). - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -D ICE40_HX -lib -specify +/ice40/cells_sim.v - hierarchy -check -top <top> - proc - - flatten: (unless -noflatten) - flatten - tribuf -logic - deminout - - coarse: - opt_expr - opt_clean - check - opt -nodffe -nosdff - fsm - opt - wreduce - peepopt - opt_clean - share - techmap -map +/cmp2lut.v -D LUT_WIDTH=4 - opt_expr - opt_clean - memory_dff [-no-rw-check] - wreduce t:$mul - techmap -map +/mul2dsp.v -map +/ice40/dsp_map.v -D DSP_A_MAXWIDTH=16 -D DSP_B_MAXWIDTH=16 -D DSP_A_MINWIDTH=2 -D DSP_B_MINWIDTH=2 -D DSP_Y_MINWIDTH=11 -D DSP_NAME=$__MUL16X16 (if -dsp) - select a:mul2dsp (if -dsp) - setattr -unset mul2dsp (if -dsp) - opt_expr -fine (if -dsp) - wreduce (if -dsp) - select -clear (if -dsp) - ice40_dsp (if -dsp) - chtype -set $mul t:$__soft_mul (if -dsp) - alumacc - opt - memory -nomap [-no-rw-check] - opt_clean - - map_ram: - memory_libmap -lib +/ice40/brams.txt -lib +/ice40/spram.txt -no-auto-huge [-no-auto-huge] [-no-auto-block] (-no-auto-huge unless -spram, -no-auto-block if -nobram) - techmap -map +/ice40/brams_map.v -map +/ice40/spram_map.v - ice40_braminit - - map_ffram: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - - map_gates: - ice40_wrapcarry - techmap -map +/techmap.v -map +/ice40/arith_map.v - opt -fast - abc -dff -D 1 (only if -retime) - ice40_opt - - map_ffs: - dfflegalize -cell $_DFF_?_ 0 -cell $_DFFE_?P_ 0 -cell $_DFF_?P?_ 0 -cell $_DFFE_?P?P_ 0 -cell $_SDFF_?P?_ 0 -cell $_SDFFCE_?P?P_ 0 -cell $_DLATCH_?_ x -mince -1 - techmap -map +/ice40/ff_map.v - opt_expr -mux_undef - simplemap - ice40_opt -full - - map_luts: - abc (only if -abc2) - ice40_opt (only if -abc2) - techmap -map +/ice40/latches_map.v - simplemap (if -noabc or -flowmap) - techmap -map +/gate2lut.v -D LUT_WIDTH=4 (only if -noabc) - flowmap -maxlut 4 (only if -flowmap) - abc -dress -lut 4 (skip if -noabc) - ice40_wrapcarry -unwrap - techmap -map +/ice40/ff_map.v - clean - opt_lut -dlogic SB_CARRY:I0=1:I1=2:CI=3 -dlogic SB_CARRY:CO=3 - - map_cells: - techmap -map +/ice40/cells_map.v (skip if -vpr) - clean - - check: - autoname - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - blif: - opt_clean -purge (vpr mode) - write_blif -attr -cname -conn -param <file-name> (vpr mode) - write_blif -gates -attr -param <file-name> (non-vpr mode) - - edif: - write_edif <file-name> - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_intel -- synthesis for Intel (Altera) FPGAs.} -\label{cmd:synth_intel} -\begin{lstlisting}[numbers=left,frame=single] - synth_intel [options] - -This command runs synthesis for Intel FPGAs. - - -family <max10 | cyclone10lp | cycloneiv | cycloneive> - generate the synthesis netlist for the specified family. - MAX10 is the default target if no family argument specified. - For Cyclone IV GX devices, use cycloneiv argument; for Cyclone IV E, use - cycloneive. For Cyclone V and Cyclone 10 GX, use the synth_intel_alm - backend instead. - - -top <module> - use the specified module as top module (default='top') - - -vqm <file> - write the design to the specified Verilog Quartus Mapping File. Writing - of an output file is omitted if this parameter is not specified. - Note that this backend has not been tested and is likely incompatible - with recent versions of Quartus. - - -vpr <file> - write BLIF files for VPR flow experiments. The synthesized BLIF output - file is not compatible with the Quartus flow. Writing of an - output file is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -iopads - use IO pad cells in output netlist - - -nobram - do not use block RAM cells in output netlist - - -noflatten - do not flatten design before synthesis - - -retime - run 'abc' with '-dff -D 1' options - -The following commands are executed by this synthesis command: - - begin: - - family: - read_verilog -sv -lib +/intel/max10/cells_sim.v - read_verilog -sv -lib +/intel/common/m9k_bb.v - read_verilog -sv -lib +/intel/common/altpll_bb.v - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - tribuf -logic - deminout - - coarse: - synth -run coarse - - map_bram: (skip if -nobram) - memory_bram -rules +/intel/common/brams_m9k.txt (if applicable for family) - techmap -map +/intel/common/brams_map_m9k.v (if applicable for family) - - map_ffram: - opt -fast -mux_undef -undriven -fine -full - memory_map - opt -undriven -fine - techmap -map +/techmap.v - opt -full - clean -purge - setundef -undriven -zero - abc -markgroups -dff -D 1 (only if -retime) - - map_ffs: - dfflegalize -cell $_DFFE_PN0P_ 01 - techmap -map +/intel/common/ff_map.v - - map_luts: - abc -lut 4 - clean - - map_cells: - iopadmap -bits -outpad $__outpad I:O -inpad $__inpad O:I (if -iopads) - techmap -map +/intel/max10/cells_map.v - clean -purge - - check: - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - vqm: - write_verilog -attr2comment -defparam -nohex -decimal -renameprefix syn_ <file-name> - - vpr: - opt_clean -purge - write_blif <file-name> - - -WARNING: THE 'synth_intel' COMMAND IS EXPERIMENTAL. -\end{lstlisting} - -\section{synth\_intel\_alm -- synthesis for ALM-based Intel (Altera) FPGAs.} -\label{cmd:synth_intel_alm} -\begin{lstlisting}[numbers=left,frame=single] - synth_intel_alm [options] - -This command runs synthesis for ALM-based Intel FPGAs. - - -top <module> - use the specified module as top module - - -family <family> - target one of: - "cyclonev" - Cyclone V (default) - "arriav" - Arria V (non-GZ) - "cyclone10gx" - Cyclone 10GX - - -vqm <file> - write the design to the specified Verilog Quartus Mapping File. Writing - of an output file is omitted if this parameter is not specified. Implies - -quartus. - - -noflatten - do not flatten design before synthesis; useful for per-module area - statistics - - -quartus - output a netlist using Quartus cells instead of MISTRAL_* cells - - -dff - pass DFFs to ABC to perform sequential logic optimisations - (EXPERIMENTAL) - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -nolutram - do not use LUT RAM cells in output netlist - - -nobram - do not use block RAM cells in output netlist - - -nodsp - do not map multipliers to MISTRAL_MUL cells - - -noiopad - do not instantiate IO buffers - - -noclkbuf - do not insert global clock buffers - -The following commands are executed by this synthesis command: - - begin: - read_verilog -specify -lib -D <family> +/intel_alm/common/alm_sim.v - read_verilog -specify -lib -D <family> +/intel_alm/common/dff_sim.v - read_verilog -specify -lib -D <family> +/intel_alm/common/dsp_sim.v - read_verilog -specify -lib -D <family> +/intel_alm/common/mem_sim.v - read_verilog -specify -lib -D <family> +/intel_alm/common/misc_sim.v - read_verilog -specify -lib -D <family> -icells +/intel_alm/common/abc9_model.v - read_verilog -lib +/intel/common/altpll_bb.v - read_verilog -lib +/intel_alm/common/megafunction_bb.v - hierarchy -check -top <top> - - coarse: - proc - flatten (skip if -noflatten) - tribuf -logic - deminout - opt_expr - opt_clean - check - opt -nodffe -nosdff - fsm - opt - wreduce - peepopt - opt_clean - share - techmap -map +/cmp2lut.v -D LUT_WIDTH=6 - opt_expr - opt_clean - techmap -map +/mul2dsp.v [...] (unless -nodsp) - alumacc - iopadmap -bits -outpad MISTRAL_OB I:PAD -inpad MISTRAL_IB O:PAD -toutpad MISTRAL_IO OE:O:PAD -tinoutpad MISTRAL_IO OE:O:I:PAD A:top (unless -noiopad) - techmap -map +/intel_alm/common/arith_alm_map.v -map +/intel_alm/common/dsp_map.v - opt - memory -nomap - opt_clean - - map_bram: (skip if -nobram) - memory_bram -rules +/intel_alm/common/bram_<bram_type>.txt - techmap -map +/intel_alm/common/bram_<bram_type>_map.v - - map_lutram: (skip if -nolutram) - memory_bram -rules +/intel_alm/common/lutram_mlab.txt (for Cyclone V / Cyclone 10GX) - - map_ffram: - memory_map - opt -full - - map_ffs: - techmap - dfflegalize -cell $_DFFE_PN0P_ 0 -cell $_SDFFCE_PP0P_ 0 - techmap -map +/intel_alm/common/dff_map.v - opt -full -undriven -mux_undef - clean -purge - clkbufmap -buf MISTRAL_CLKBUF Q:A (unless -noclkbuf) - - map_luts: - techmap -map +/intel_alm/common/abc9_map.v - abc9 [-dff] -maxlut 6 -W 600 - techmap -map +/intel_alm/common/abc9_unmap.v - techmap -map +/intel_alm/common/alm_map.v - opt -fast - autoname - clean - - check: - hierarchy -check - stat - check - blackbox =A:whitebox - - quartus: - rename -hide w:*[* w:*]* - setundef -zero - hilomap -singleton -hicell __MISTRAL_VCC Q -locell __MISTRAL_GND Q - techmap -D <family> -map +/intel_alm/common/quartus_rename.v - - vqm: - write_verilog -attr2comment -defparam -nohex -decimal <file-name> -\end{lstlisting} - -\section{synth\_machxo2 -- synthesis for MachXO2 FPGAs. This work is experimental.} -\label{cmd:synth_machxo2} -\begin{lstlisting}[numbers=left,frame=single] - synth_machxo2 [options] - -This command runs synthesis for MachXO2 FPGAs. - - -top <module> - use the specified module as top module - - -blif <file> - write the design to the specified BLIF file. writing of an output file - is omitted if this parameter is not specified. - - -edif <file> - write the design to the specified EDIF file. writing of an output file - is omitted if this parameter is not specified. - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -nobram - do not use block RAM cells in output netlist - - -nolutram - do not use LUT RAM cells in output netlist - - -noflatten - do not flatten design before synthesis - - -noiopad - do not insert IO buffers - - -vpr - generate an output netlist (and BLIF file) suitable for VPR - (this feature is experimental and incomplete) - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib -icells +/machxo2/cells_sim.v - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - tribuf -logic - deminout - - coarse: - synth -run coarse - - map_ram: - memory_libmap -lib +/machxo2/lutrams.txt -lib +/machxo2/brams.txt [-no-auto-block] [-no-auto-distributed] (-no-auto-block if -nobram, -no-auto-distributed if -nolutram) - techmap -map +/machxo2/lutrams_map.v -map +/machxo2/brams_map.v - - fine: - memory_map - opt -full - techmap -map +/techmap.v - opt -fast - - map_ios: (unless -noiopad) - iopadmap -bits -outpad $__FACADE_OUTPAD I:O -inpad $__FACADE_INPAD O:I -toutpad $__FACADE_TOUTPAD ~T:I:O -tinoutpad $__FACADE_TINOUTPAD ~T:O:I:B A:top - attrmvcp -attr src -attr LOC t:$__FACADE_OUTPAD %x:+[O] t:$__FACADE_TOUTPAD %x:+[O] t:$__FACADE_TINOUTPAD %x:+[B] - attrmvcp -attr src -attr LOC -driven t:$__FACADE_INPAD %x:+[I] - - map_ffs: - dfflegalize -cell $_DFF_P_ 0 - - map_luts: - abc -lut 4 -dress - clean - - map_cells: - techmap -map +/machxo2/cells_map.v - clean - - check: - hierarchy -check - stat - blackbox =A:whitebox - - blif: - opt_clean -purge (vpr mode) - write_blif -attr -cname -conn -param <file-name> (vpr mode) - write_blif -gates -attr -param <file-name> (non-vpr mode) - - edif: - write_edif <file-name> - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_nexus -- synthesis for Lattice Nexus FPGAs} -\label{cmd:synth_nexus} -\begin{lstlisting}[numbers=left,frame=single] - synth_nexus [options] - -This command runs synthesis for Lattice Nexus FPGAs. - - -top <module> - use the specified module as top module - - -family <device> - run synthesis for the specified Nexus device - supported values: lifcl, lfd2nx - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -vm <file> - write the design to the specified structural Verilog file. writing of - an output file is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -dff - run 'abc'/'abc9' with -dff option - - -retime - run 'abc' with '-dff -D 1' options - - -noccu2 - do not use CCU2 cells in output netlist - - -nodffe - do not use flipflops with CE in output netlist - - -nolram - do not use large RAM cells in output netlist - note that large RAM must be explicitly requested with a (* lram *) - attribute on the memory. - - -nobram - do not use block RAM cells in output netlist - - -nolutram - do not use LUT RAM cells in output netlist - - -nowidelut - do not use PFU muxes to implement LUTs larger than LUT4s - - -noiopad - do not insert IO buffers - - -nodsp - do not infer DSP multipliers - - -abc9 - use new ABC9 flow (EXPERIMENTAL) - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib -specify +/nexus/cells_sim.v +/nexus/cells_xtra.v - hierarchy -check -top <top> - - coarse: - proc - flatten - tribuf -logic - deminout - opt_expr - opt_clean - check - opt -nodffe -nosdff - fsm - opt - wreduce - peepopt - opt_clean - share - techmap -map +/cmp2lut.v -D LUT_WIDTH=4 - opt_expr - opt_clean - techmap -map +/mul2dsp.v [...] (unless -nodsp) - techmap -map +/nexus/dsp_map.v (unless -nodsp) - alumacc - opt - memory -nomap - opt_clean - - map_ram: - memory_libmap -lib +/nexus/lutrams.txt -lib +/nexus/brams.txt -lib +/nexus/lrams.txt -no-auto-huge [-no-auto-block] [-no-auto-distributed] (-no-auto-block if -nobram, -no-auto-distributed if -nolutram) - techmap -map +/nexus/lutrams_map.v -map +/nexus/brams_map.v -map +/nexus/lrams_map.v - - map_ffram: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - - map_gates: - techmap -map +/techmap.v -map +/nexus/arith_map.v - iopadmap -bits -outpad OB I:O -inpad IB O:I -toutpad OBZ ~T:I:O -tinoutpad BB ~T:O:I:B A:top (skip if '-noiopad') - opt -fast - abc -dff -D 1 (only if -retime) - - map_ffs: - opt_clean - dfflegalize -cell $_DFF_P_ 01 -cell $_DFF_PP?_ r -cell $_SDFF_PP?_ r -cell $_DLATCH_?_ x [-cell $_DFFE_PP_ 01 -cell $_DFFE_PP?P_ r -cell $_SDFFE_PP?P_ r] ($_*DFFE_* only if not -nodffe) - zinit -all w:* t:$_DFF_?_ t:$_DFFE_??_ t:$_SDFF* (only if -abc9 and -dff - techmap -D NO_LUT -map +/nexus/cells_map.v - opt_expr -undriven -mux_undef - simplemap - attrmvcp -copy -attr syn_useioff - opt_clean - - map_luts: - techmap -map +/nexus/latches_map.v - abc -dress -lut 4:5 - clean - - map_cells: - techmap -map +/nexus/cells_map.v - setundef -zero - hilomap -singleton -hicell VHI Z -locell VLO Z - clean - - check: - autoname - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - json: - write_json <file-name> - - vm: - write_verilog <file-name> -\end{lstlisting} - -\section{synth\_quicklogic -- Synthesis for QuickLogic FPGAs} -\label{cmd:synth_quicklogic} -\begin{lstlisting}[numbers=left,frame=single] - synth_quicklogic [options] -This command runs synthesis for QuickLogic FPGAs - - -top <module> - use the specified module as top module - - -family <family> - run synthesis for the specified QuickLogic architecture - generate the synthesis netlist for the specified family. - supported values: - - pp3: PolarPro 3 - - -blif <file> - write the design to the specified BLIF file. writing of an output file - is omitted if this parameter is not specified. - - -verilog <file> - write the design to the specified verilog file. writing of an output - file is omitted if this parameter is not specified. - - -abc - use old ABC flow, which has generally worse mapping results but is less - likely to have bugs. - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib -specify +/quicklogic/cells_sim.v +/quicklogic/pp3_cells_sim.v - read_verilog -lib -specify +/quicklogic/lut_sim.v - hierarchy -check -top <top> - - coarse: - proc - flatten - tribuf -logic - deminout - opt_expr - opt_clean - check - opt -nodffe -nosdff - fsm - opt - wreduce - peepopt - opt_clean - share - techmap -map +/cmp2lut.v -D LUT_WIDTH=4 - opt_expr - opt_clean - alumacc - pmuxtree - opt - memory -nomap - opt_clean - - map_ffram: - opt -fast -mux_undef -undriven -fine - memory_map -iattr -attr !ram_block -attr !rom_block -attr logic_block -attr syn_ramstyle=auto -attr syn_ramstyle=registers -attr syn_romstyle=auto -attr syn_romstyle=logic - opt -undriven -fine - - map_gates: - techmap - opt -fast - muxcover -mux8 -mux4 - - map_ffs: - opt_expr - dfflegalize -cell $_DFFSRE_PPPP_ 0 -cell $_DLATCH_?_ x - techmap -map +/quicklogic/pp3_cells_map.v -map +/quicklogic/pp3_ffs_map.v - opt_expr -mux_undef - - map_luts: - techmap -map +/quicklogic/pp3_latches_map.v - read_verilog -lib -specify -icells +/quicklogic/abc9_model.v - techmap -map +/quicklogic/abc9_map.v - abc9 -maxlut 4 -dff - techmap -map +/quicklogic/abc9_unmap.v - clean - - map_cells: - techmap -map +/quicklogic/pp3_lut_map.v - clean - - check: - autoname - hierarchy -check - stat - check -noinit - - iomap: - clkbufmap -inpad ckpad Q:P - iopadmap -bits -outpad outpad A:P -inpad inpad Q:P -tinoutpad bipad EN:Q:A:P A:top - - finalize: - setundef -zero -params -undriven - hilomap -hicell logic_1 A -locell logic_0 A -singleton A:top - opt_clean -purge - check - blackbox =A:whitebox - - blif: - write_blif -attr -param -auto-top - - verilog: - write_verilog -noattr -nohex <file-name> -\end{lstlisting} - -\section{synth\_sf2 -- synthesis for SmartFusion2 and IGLOO2 FPGAs} -\label{cmd:synth_sf2} -\begin{lstlisting}[numbers=left,frame=single] - synth_sf2 [options] - -This command runs synthesis for SmartFusion2 and IGLOO2 FPGAs. - - -top <module> - use the specified module as top module - - -edif <file> - write the design to the specified EDIF file. writing of an output file - is omitted if this parameter is not specified. - - -vlog <file> - write the design to the specified Verilog file. writing of an output - file is omitted if this parameter is not specified. - - -json <file> - write the design to the specified JSON file. writing of an output file - is omitted if this parameter is not specified. - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -noflatten - do not flatten design before synthesis - - -noiobs - run synthesis in "block mode", i.e. do not insert IO buffers - - -clkbuf - insert direct PAD->global_net buffers - - -discard-ffinit - discard FF init value instead of emitting an error - - -retime - run 'abc' with '-dff -D 1' options - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib +/sf2/cells_sim.v - hierarchy -check -top <top> - - flatten: (unless -noflatten) - proc - flatten - tribuf -logic - deminout - - coarse: - attrmap -remove init (only if -discard-ffinit) - synth -run coarse - - fine: - opt -fast -mux_undef -undriven -fine - memory_map - opt -undriven -fine - techmap -map +/techmap.v -map +/sf2/arith_map.v - opt -fast - abc -dff -D 1 (only if -retime) - - map_ffs: - dfflegalize -cell $_DFFE_PN?P_ x -cell $_SDFFCE_PN?P_ x -cell $_DLATCH_PN?_ x - techmap -D NO_LUT -map +/sf2/cells_map.v - opt_expr -mux_undef - simplemap - - map_luts: - abc -lut 4 - clean - - map_cells: - techmap -map +/sf2/cells_map.v - clean - - map_iobs: - clkbufmap -buf CLKINT Y:A [-inpad CLKBUF Y:PAD] (unless -noiobs, -inpad only passed if -clkbuf) - iopadmap -bits -inpad INBUF Y:PAD -outpad OUTBUF D:PAD -toutpad TRIBUFF E:D:PAD -tinoutpad BIBUF E:Y:D:PAD (unless -noiobs) - clean -purge - - check: - hierarchy -check - stat - check -noinit - blackbox =A:whitebox - - edif: - write_edif -gndvccy <file-name> - - vlog: - write_verilog <file-name> - - json: - write_json <file-name> -\end{lstlisting} - -\section{synth\_xilinx -- synthesis for Xilinx FPGAs} -\label{cmd:synth_xilinx} -\begin{lstlisting}[numbers=left,frame=single] - synth_xilinx [options] - -This command runs synthesis for Xilinx FPGAs. This command does not operate on -partly selected designs. At the moment this command creates netlists that are -compatible with 7-Series Xilinx devices. - - -top <module> - use the specified module as top module - - -family <family> - run synthesis for the specified Xilinx architecture - generate the synthesis netlist for the specified family. - supported values: - - xcup: Ultrascale Plus - - xcu: Ultrascale - - xc7: Series 7 (default) - - xc6s: Spartan 6 - - xc6v: Virtex 6 - - xc5v: Virtex 5 (EXPERIMENTAL) - - xc4v: Virtex 4 (EXPERIMENTAL) - - xc3sda: Spartan 3A DSP (EXPERIMENTAL) - - xc3sa: Spartan 3A (EXPERIMENTAL) - - xc3se: Spartan 3E (EXPERIMENTAL) - - xc3s: Spartan 3 (EXPERIMENTAL) - - xc2vp: Virtex 2 Pro (EXPERIMENTAL) - - xc2v: Virtex 2 (EXPERIMENTAL) - - xcve: Virtex E, Spartan 2E (EXPERIMENTAL) - - xcv: Virtex, Spartan 2 (EXPERIMENTAL) - - -edif <file> - write the design to the specified edif file. writing of an output file - is omitted if this parameter is not specified. - - -blif <file> - write the design to the specified BLIF file. writing of an output file - is omitted if this parameter is not specified. - - -ise - generate an output netlist suitable for ISE - - -nobram - do not use block RAM cells in output netlist - - -nolutram - do not use distributed RAM cells in output netlist - - -nosrl - do not use distributed SRL cells in output netlist - - -nocarry - do not use XORCY/MUXCY/CARRY4 cells in output netlist - - -nowidelut - do not use MUXF[5-9] resources to implement LUTs larger than native for - the target - - -nodsp - do not use DSP48*s to implement multipliers and associated logic - - -noiopad - disable I/O buffer insertion (useful for hierarchical or - out-of-context flows) - - -noclkbuf - disable automatic clock buffer insertion - - -uram - infer URAM288s for large memories (xcup only) - - -widemux <int> - enable inference of hard multiplexer resources (MUXF[78]) for muxes at - or above this number of inputs (minimum value 2, recommended value >= 5) - default: 0 (no inference) - - -run <from_label>:<to_label> - only run the commands between the labels (see below). an empty - from label is synonymous to 'begin', and empty to label is - synonymous to the end of the command list. - - -flatten - flatten design before synthesis - - -dff - run 'abc'/'abc9' with -dff option - - -retime - run 'abc' with '-D 1' option to enable flip-flop retiming. - implies -dff. - - -abc9 - use new ABC9 flow (EXPERIMENTAL) - - -The following commands are executed by this synthesis command: - - begin: - read_verilog -lib -specify +/xilinx/cells_sim.v - read_verilog -lib +/xilinx/cells_xtra.v - hierarchy -check -auto-top - - prepare: - proc - flatten (with '-flatten') - tribuf -logic - deminout - opt_expr - opt_clean - check - opt -nodffe -nosdff - fsm - opt - wreduce [-keepdc] (option for '-widemux') - peepopt - opt_clean - muxpack ('-widemux' only) - pmux2shiftx (skip if '-nosrl' and '-widemux=0') - clean (skip if '-nosrl' and '-widemux=0') - - map_dsp: (skip if '-nodsp') - memory_dff - techmap -map +/mul2dsp.v -map +/xilinx/{family}_dsp_map.v {options} - select a:mul2dsp - setattr -unset mul2dsp - opt_expr -fine - wreduce - select -clear - xilinx_dsp -family <family> - chtype -set $mul t:$__soft_mul - - coarse: - techmap -map +/cmp2lut.v -map +/cmp2lcu.v -D LUT_WIDTH=[46] - alumacc - share - opt - memory -nomap - opt_clean - - map_memory: - memory_libmap [...] - techmap -map +/xilinx/lutrams_<family>_map.v - techmap -map +/xilinx/brams_<family>_map.v - - map_ffram: - opt -fast -full - memory_map - - fine: - simplemap t:$mux ('-widemux' only) - muxcover <internal options> ('-widemux' only) - opt -full - xilinx_srl -variable -minlen 3 (skip if '-nosrl') - techmap -map +/techmap.v -D LUT_SIZE=[46] [-map +/xilinx/mux_map.v] -map +/xilinx/arith_map.v - opt -fast - - map_cells: - iopadmap -bits -outpad OBUF I:O -inpad IBUF O:I -toutpad OBUFT ~T:I:O -tinoutpad IOBUF ~T:O:I:IO A:top (skip if '-noiopad') - techmap -map +/techmap.v -map +/xilinx/cells_map.v - clean - - map_ffs: - dfflegalize -cell $_DFFE_?P?P_ 01 -cell $_SDFFE_?P?P_ 01 -cell $_DLATCH_?P?_ 01 (for xc6v, xc7, xcu, xcup) - zinit -all w:* t:$_SDFFE_* ('-dff' only) - techmap -map +/xilinx/ff_map.v ('-abc9' only) - - map_luts: - opt_expr -mux_undef -noclkinv - abc -luts 2:2,3,6:5[,10,20] [-dff] [-D 1] (option for '-nowidelut', '-dff', '-retime') - clean - techmap -map +/xilinx/ff_map.v (only if not '-abc9') - xilinx_srl -fixed -minlen 3 (skip if '-nosrl') - techmap -map +/xilinx/lut_map.v -map +/xilinx/cells_map.v -D LUT_WIDTH=[46] - xilinx_dffopt [-lut4] - opt_lut_ins -tech xilinx - - finalize: - clkbufmap -buf BUFG O:I (skip if '-noclkbuf') - extractinv -inv INV O:I (only if '-ise') - clean - - check: - hierarchy -check - stat -tech xilinx - check -noinit - blackbox =A:whitebox - - edif: - write_edif -pvector bra - - blif: - write_blif -\end{lstlisting} - -\section{tcl -- execute a TCL script file} -\label{cmd:tcl} -\begin{lstlisting}[numbers=left,frame=single] - tcl <filename> [args] - -This command executes the tcl commands in the specified file. -Use 'yosys cmd' to run the yosys command 'cmd' from tcl. - -The tcl command 'yosys -import' can be used to import all yosys -commands directly as tcl commands to the tcl shell. Yosys commands -'proc' and 'rename' are wrapped to tcl commands 'procs' and 'renames' -in order to avoid a name collision with the built in commands. - -If any arguments are specified, these arguments are provided to the script via -the standard $argc and $argv variables. - -Note, tcl will not recieve the output of any yosys command. If the output -of the tcl commands are needed, use the yosys command 'tee -s result.string' -to redirect yosys's output to the 'result.string' scratchpad value. -\end{lstlisting} - -\section{techmap -- generic technology mapper} -\label{cmd:techmap} -\begin{lstlisting}[numbers=left,frame=single] - techmap [-map filename] [selection] - -This pass implements a very simple technology mapper that replaces cells in -the design with implementations given in form of a Verilog or RTLIL source -file. - - -map filename - the library of cell implementations to be used. - without this parameter a builtin library is used that - transforms the internal RTL cells to the internal gate - library. - - -map %<design-name> - like -map above, but with an in-memory design instead of a file. - - -extern - load the cell implementations as separate modules into the design - instead of inlining them. - - -max_iter <number> - only run the specified number of iterations on each module. - default: unlimited - - -recursive - instead of the iterative breadth-first algorithm use a recursive - depth-first algorithm. both methods should yield equivalent results, - but may differ in performance. - - -autoproc - Automatically call "proc" on implementations that contain processes. - - -wb - Ignore the 'whitebox' attribute on cell implementations. - - -assert - this option will cause techmap to exit with an error if it can't map - a selected cell. only cell types that end on an underscore are accepted - as final cell types by this mode. - - -D <define>, -I <incdir> - this options are passed as-is to the Verilog frontend for loading the - map file. Note that the Verilog frontend is also called with the - '-nooverwrite' option set. - -When a module in the map file has the 'techmap_celltype' attribute set, it will -match cells with a type that match the text value of this attribute. Otherwise -the module name will be used to match the cell. Multiple space-separated cell -types can be listed, and wildcards using [] will be expanded (ie. -"$_DFF_[PN]_" is the same as "$_DFF_P_ $_DFF_N_"). - -When a module in the map file has the 'techmap_simplemap' attribute set, techmap -will use 'simplemap' (see 'help simplemap') to map cells matching the module. - -When a module in the map file has the 'techmap_maccmap' attribute set, techmap -will use 'maccmap' (see 'help maccmap') to map cells matching the module. - -When a module in the map file has the 'techmap_wrap' attribute set, techmap -will create a wrapper for the cell and then run the command string that the -attribute is set to on the wrapper module. - -When a port on a module in the map file has the 'techmap_autopurge' attribute -set, and that port is not connected in the instantiation that is mapped, then -then a cell port connected only to such wires will be omitted in the mapped -version of the circuit. - -All wires in the modules from the map file matching the pattern _TECHMAP_* -or *._TECHMAP_* are special wires that are used to pass instructions from -the mapping module to the techmap command. At the moment the following special -wires are supported: - - _TECHMAP_FAIL_ - When this wire is set to a non-zero constant value, techmap will not - use this module and instead try the next module with a matching - 'techmap_celltype' attribute. - - When such a wire exists but does not have a constant value after all - _TECHMAP_DO_* commands have been executed, an error is generated. - - _TECHMAP_DO_* - This wires are evaluated in alphabetical order. The constant text value - of this wire is a yosys command (or sequence of commands) that is run - by techmap on the module. A common use case is to run 'proc' on modules - that are written using always-statements. - - When such a wire has a non-constant value at the time it is to be - evaluated, an error is produced. That means it is possible for such a - wire to start out as non-constant and evaluate to a constant value - during processing of other _TECHMAP_DO_* commands. - - A _TECHMAP_DO_* command may start with the special token 'CONSTMAP; '. - in this case techmap will create a copy for each distinct configuration - of constant inputs and shorted inputs at this point and import the - constant and connected bits into the map module. All further commands - are executed in this copy. This is a very convenient way of creating - optimized specializations of techmap modules without using the special - parameters described below. - - A _TECHMAP_DO_* command may start with the special token 'RECURSION; '. - then techmap will recursively replace the cells in the module with their - implementation. This is not affected by the -max_iter option. - - It is possible to combine both prefixes to 'RECURSION; CONSTMAP; '. - - _TECHMAP_REMOVEINIT_<port-name>_ - When this wire is set to a constant value, the init attribute of the - wire(s) connected to this port will be consumed. This wire must have - the same width as the given port, and for every bit that is set to 1 in - the value, the corresponding init attribute bit will be changed to 1'bx. - If all bits of an init attribute are left as x, it will be removed. - -In addition to this special wires, techmap also supports special parameters in -modules in the map file: - - _TECHMAP_CELLTYPE_ - When a parameter with this name exists, it will be set to the type name - of the cell that matches the module. - - _TECHMAP_CELLNAME_ - When a parameter with this name exists, it will be set to the name - of the cell that matches the module. - - _TECHMAP_CONSTMSK_<port-name>_ - _TECHMAP_CONSTVAL_<port-name>_ - When this pair of parameters is available in a module for a port, then - former has a 1-bit for each constant input bit and the latter has the - value for this bit. The unused bits of the latter are set to undef (x). - - _TECHMAP_WIREINIT_<port-name>_ - When a parameter with this name exists, it will be set to the initial - value of the wire(s) connected to the given port, as specified by the - init attribute. If the attribute doesn't exist, x will be filled for the - missing bits. To remove the init attribute bits used, use the - _TECHMAP_REMOVEINIT_*_ wires. - - _TECHMAP_BITS_CONNMAP_ - _TECHMAP_CONNMAP_<port-name>_ - For an N-bit port, the _TECHMAP_CONNMAP_<port-name>_ parameter, if it - exists, will be set to an N*_TECHMAP_BITS_CONNMAP_ bit vector containing - N words (of _TECHMAP_BITS_CONNMAP_ bits each) that assign each single - bit driver a unique id. The values 0-3 are reserved for 0, 1, x, and z. - This can be used to detect shorted inputs. - -When a module in the map file has a parameter where the according cell in the -design has a port, the module from the map file is only used if the port in -the design is connected to a constant value. The parameter is then set to the -constant value. - -A cell with the name _TECHMAP_REPLACE_ in the map file will inherit the name -and attributes of the cell that is being replaced. -A cell with a name of the form `_TECHMAP_REPLACE_.<suffix>` in the map file will -be named thus but with the `_TECHMAP_REPLACE_' prefix substituted with the name -of the cell being replaced. -Similarly, a wire named in the form `_TECHMAP_REPLACE_.<suffix>` will cause a -new wire alias to be created and named as above but with the `_TECHMAP_REPLACE_' -prefix also substituted. - -See 'help extract' for a pass that does the opposite thing. - -See 'help flatten' for a pass that does flatten the design (which is -essentially techmap but using the design itself as map library). -\end{lstlisting} - -\section{tee -- redirect command output to file} -\label{cmd:tee} -\begin{lstlisting}[numbers=left,frame=single] - tee [-q] [-o logfile|-a logfile] cmd - -Execute the specified command, optionally writing the commands output to the -specified logfile(s). - - -q - Do not print output to the normal destination (console and/or log file). - - -o logfile - Write output to this file, truncate if exists. - - -a logfile - Write output to this file, append if exists. - - -s scratchpad - Write output to this scratchpad value, truncate if it exists. - - +INT, -INT - Add/subtract INT from the -v setting for this command. -\end{lstlisting} - -\section{test\_abcloop -- automatically test handling of loops in abc command} -\label{cmd:test_abcloop} -\begin{lstlisting}[numbers=left,frame=single] - test_abcloop [options] - -Test handling of logic loops in ABC. - - -n {integer} - create this number of circuits and test them (default = 100). - - -s {positive_integer} - use this value as rng seed value (default = unix time). -\end{lstlisting} - -\section{test\_autotb -- generate simple test benches} -\label{cmd:test_autotb} -\begin{lstlisting}[numbers=left,frame=single] - test_autotb [options] [filename] - -Automatically create primitive Verilog test benches for all modules in the -design. The generated testbenches toggle the input pins of the module in -a semi-random manner and dumps the resulting output signals. - -This can be used to check the synthesis results for simple circuits by -comparing the testbench output for the input files and the synthesis results. - -The backend automatically detects clock signals. Additionally a signal can -be forced to be interpreted as clock signal by setting the attribute -'gentb_clock' on the signal. - -The attribute 'gentb_constant' can be used to force a signal to a constant -value after initialization. This can e.g. be used to force a reset signal -low in order to explore more inner states in a state machine. - -The attribute 'gentb_skip' can be attached to modules to suppress testbench -generation. - - -n <int> - number of iterations the test bench should run (default = 1000) - - -seed <int> - seed used for pseudo-random number generation (default = 0). - a value of 0 will cause an arbitrary seed to be chosen, based on - the current system time. -\end{lstlisting} - -\section{test\_cell -- automatically test the implementation of a cell type} -\label{cmd:test_cell} -\begin{lstlisting}[numbers=left,frame=single] - test_cell [options] {cell-types} - -Tests the internal implementation of the given cell type (for example '$add') -by comparing SAT solver, EVAL and TECHMAP implementations of the cell types.. - -Run with 'all' instead of a cell type to run the test on all supported -cell types. Use for example 'all /$add' for all cell types except $add. - - -n {integer} - create this number of cell instances and test them (default = 100). - - -s {positive_integer} - use this value as rng seed value (default = unix time). - - -f {rtlil_file} - don't generate circuits. instead load the specified RTLIL file. - - -w {filename_prefix} - don't test anything. just generate the circuits and write them - to RTLIL files with the specified prefix - - -map {filename} - pass this option to techmap. - - -simlib - use "techmap -D SIMLIB_NOCHECKS -map +/simlib.v -max_iter 2 -autoproc" - - -aigmap - instead of calling "techmap", call "aigmap" - - -muxdiv - when creating test benches with dividers, create an additional mux - to mask out the division-by-zero case - - -script {script_file} - instead of calling "techmap", call "script {script_file}". - - -const - set some input bits to random constant values - - -nosat - do not check SAT model or run SAT equivalence checking - - -noeval - do not check const-eval models - - -edges - test cell edges db creator against sat-based implementation - - -v - print additional debug information to the console - - -vlog {filename} - create a Verilog test bench to test simlib and write_verilog -\end{lstlisting} - -\section{test\_pmgen -- test pass for pmgen} -\label{cmd:test_pmgen} -\begin{lstlisting}[numbers=left,frame=single] - test_pmgen -reduce_chain [options] [selection] - -Demo for recursive pmgen patterns. Map chains of AND/OR/XOR to $reduce_*. - - - test_pmgen -reduce_tree [options] [selection] - -Demo for recursive pmgen patterns. Map trees of AND/OR/XOR to $reduce_*. - - - test_pmgen -eqpmux [options] [selection] - -Demo for recursive pmgen patterns. Optimize EQ/NE/PMUX circuits. - - - test_pmgen -generate [options] <pattern_name> - -Create modules that match the specified pattern. -\end{lstlisting} - -\section{torder -- print cells in topological order} -\label{cmd:torder} -\begin{lstlisting}[numbers=left,frame=single] - torder [options] [selection] - -This command prints the selected cells in topological order. - - -stop <cell_type> <cell_port> - do not use the specified cell port in topological sorting - - -noautostop - by default Q outputs of internal FF cells and memory read port outputs - are not used in topological sorting. this option deactivates that. -\end{lstlisting} - -\section{trace -- redirect command output to file} -\label{cmd:trace} -\begin{lstlisting}[numbers=left,frame=single] - trace cmd - -Execute the specified command, logging all changes the command performs on -the design in real time. -\end{lstlisting} - -\section{tribuf -- infer tri-state buffers} -\label{cmd:tribuf} -\begin{lstlisting}[numbers=left,frame=single] - tribuf [options] [selection] - -This pass transforms $mux cells with 'z' inputs to tristate buffers. - - -merge - merge multiple tri-state buffers driving the same net - into a single buffer. - - -logic - convert tri-state buffers that do not drive output ports - to non-tristate logic. this option implies -merge. - - -formal - convert all tri-state buffers to non-tristate logic and - add a formal assertion that no two buffers are driving the - same net simultaneously. this option implies -merge. -\end{lstlisting} - -\section{uniquify -- create unique copies of modules} -\label{cmd:uniquify} -\begin{lstlisting}[numbers=left,frame=single] - uniquify [selection] - -By default, a module that is instantiated by several other modules is only -kept once in the design. This preserves the original modularity of the design -and reduces the overall size of the design in memory. But it prevents certain -optimizations and other operations on the design. This pass creates unique -modules for all selected cells. The created modules are marked with the -'unique' attribute. - -This commands only operates on modules that by themself have the 'unique' -attribute set (the 'top' module is unique implicitly). -\end{lstlisting} - -\section{verific -- load Verilog and VHDL designs using Verific} -\label{cmd:verific} -\begin{lstlisting}[numbers=left,frame=single] - verific {-vlog95|-vlog2k|-sv2005|-sv2009|-sv2012|-sv} <verilog-file>.. - -Load the specified Verilog/SystemVerilog files into Verific. - -All files specified in one call to this command are one compilation unit. -Files passed to different calls to this command are treated as belonging to -different compilation units. - -Additional -D<macro>[=<value>] options may be added after the option indicating -the language version (and before file names) to set additional verilog defines. -The macros YOSYS, SYNTHESIS, and VERIFIC are defined implicitly. - - - verific -formal <verilog-file>.. - -Like -sv, but define FORMAL instead of SYNTHESIS. - - - verific {-vhdl87|-vhdl93|-vhdl2k|-vhdl2008|-vhdl} <vhdl-file>.. - -Load the specified VHDL files into Verific. - - - verific {-edif} <edif-file>.. - -Load the specified EDIF files into Verific. - - - verific {-liberty} <liberty-file>.. - -Load the specified Liberty files into Verific. -Default library when -work is not present is one specified in liberty file. -To use from SystemVerilog or VHDL use -L to specify liberty library. - -lib - only create empty blackbox modules - - - verific {-f|-F} [-vlog95|-vlog2k|-sv2005|-sv2009| - -sv2012|-sv|-formal] <command-file> - -Load and execute the specified command file. -Override verilog parsing mode can be set. -The macros YOSYS, SYNTHESIS/FORMAL, and VERIFIC are defined implicitly. - -Command file parser supports following commands in file: - +define+<MACRO>=<VALUE> - defines macro - -u - upper case all identifier (makes Verilog parser - case insensitive) - -v <filepath> - register library name (file) - -y <filepath> - register library name (directory) - +incdir+<filepath> - specify include dir - +libext+<filepath> - specify library extension - +liborder+<id> - add library in ordered list - +librescan - unresolved modules will be always searched - starting with the first library specified - by -y/-v options. - -f/-file <filepath> - nested -f option - -F <filepath> - nested -F option (relative path) - parse files: - <filepath> - +systemverilogext+<filepath> - +verilog1995ext+<filepath> - +verilog2001ext+<filepath> - - analysis mode: - -ams - +v2k - -sverilog - - - verific [-work <libname>] {-sv|-vhdl|...} <hdl-file> - -Load the specified Verilog/SystemVerilog/VHDL file into the specified library. -(default library when -work is not present: "work") - - - verific [-L <libname>] {-sv|-vhdl|...} <hdl-file> - -Look up external definitions in the specified library. -(-L may be used more than once) - - - verific -vlog-incdir <directory>.. - -Add Verilog include directories. - - - verific -vlog-libdir <directory>.. - -Add Verilog library directories. Verific will search in this directories to -find undefined modules. - - - verific -vlog-libext <extension>.. - -Add Verilog library extensions, used when searching in library directories. - - - verific -vlog-define <macro>[=<value>].. - -Add Verilog defines. - - - verific -vlog-undef <macro>.. - -Remove Verilog defines previously set with -vlog-define. - - - verific -set-error <msg_id>.. - verific -set-warning <msg_id>.. - verific -set-info <msg_id>.. - verific -set-ignore <msg_id>.. - -Set message severity. <msg_id> is the string in square brackets when a message -is printed, such as VERI-1209. -Also errors, warnings, infos and comments could be used to set new severity for -all messages of certain type. - - - verific -import [options] <top>.. - -Elaborate the design for the specified top modules or configurations, import to -Yosys and reset the internal state of Verific. - -Import options: - - -all - Elaborate all modules, not just the hierarchy below the given top - modules. With this option the list of modules to import is optional. - - -gates - Create a gate-level netlist. - - -flatten - Flatten the design in Verific before importing. - - -extnets - Resolve references to external nets by adding module ports as needed. - - -autocover - Generate automatic cover statements for all asserts - - -fullinit - Keep all register initializations, even those for non-FF registers. - - -cells - Import all cell definitions from Verific loaded libraries even if they are - unused in design. Useful with "-edif" and "-liberty" option. - - -chparam name value - Elaborate the specified top modules (all modules when -all given) using - this parameter value. Modules on which this parameter does not exist will - cause Verific to produce a VERI-1928 or VHDL-1676 message. This option - can be specified multiple times to override multiple parameters. - String values must be passed in double quotes ("). - - -v, -vv - Verbose log messages. (-vv is even more verbose than -v.) - - -pp <filename> - Pretty print design after elaboration to specified file. - -The following additional import options are useful for debugging the Verific -bindings (for Yosys and/or Verific developers): - - -k - Keep going after an unsupported verific primitive is found. The - unsupported primitive is added as blockbox module to the design. - This will also add all SVA related cells to the design parallel to - the checker logic inferred by it. - - -V - Import Verific netlist as-is without translating to Yosys cell types. - - -nosva - Ignore SVA properties, do not infer checker logic. - - -L <int> - Maximum number of ctrl bits for SVA checker FSMs (default=16). - - -n - Keep all Verific names on instances and nets. By default only - user-declared names are preserved. - - -d <dump_file> - Dump the Verific netlist as a verilog file. - - - verific [-work <libname>] -pp [options] <filename> [<module>].. - -Pretty print design (or just module) to the specified file from the -specified library. (default library when -work is not present: "work") - -Pretty print options: - - -verilog - Save output for Verilog/SystemVerilog design modules (default). - - -vhdl - Save output for VHDL design units. - - - verific -cfg [<name> [<value>]] - -Get/set Verific runtime flags. - - -Use YosysHQ Tabby CAD Suite if you need Yosys+Verific. -https://www.yosyshq.com/ - -Contact office@yosyshq.com for free evaluation -binaries of YosysHQ Tabby CAD Suite. -\end{lstlisting} - -\section{verilog\_defaults -- set default options for read\_verilog} -\label{cmd:verilog_defaults} -\begin{lstlisting}[numbers=left,frame=single] - verilog_defaults -add [options] - -Add the specified options to the list of default options to read_verilog. - - - verilog_defaults -clear - -Clear the list of Verilog default options. - - - verilog_defaults -push - verilog_defaults -pop - -Push or pop the list of default options to a stack. Note that -push does -not imply -clear. -\end{lstlisting} - -\section{verilog\_defines -- define and undefine verilog defines} -\label{cmd:verilog_defines} -\begin{lstlisting}[numbers=left,frame=single] - verilog_defines [options] - -Define and undefine verilog preprocessor macros. - - -Dname[=definition] - define the preprocessor symbol 'name' and set its optional value - 'definition' - - -Uname[=definition] - undefine the preprocessor symbol 'name' - - -reset - clear list of defined preprocessor symbols - - -list - list currently defined preprocessor symbols -\end{lstlisting} - -\section{wbflip -- flip the whitebox attribute} -\label{cmd:wbflip} -\begin{lstlisting}[numbers=left,frame=single] - wbflip [selection] - -Flip the whitebox attribute on selected cells. I.e. if it's set, unset it, and -vice-versa. Blackbox cells are not effected by this command. -\end{lstlisting} - -\section{wreduce -- reduce the word size of operations if possible} -\label{cmd:wreduce} -\begin{lstlisting}[numbers=left,frame=single] - wreduce [options] [selection] - -This command reduces the word size of operations. For example it will replace -the 32 bit adders in the following code with adders of more appropriate widths: - - module test(input [3:0] a, b, c, output [7:0] y); - assign y = a + b + c + 1; - endmodule - -Options: - - -memx - Do not change the width of memory address ports. Use this options in - flows that use the 'memory_memx' pass. - - -mux_undef - remove 'undef' inputs from $mux, $pmux and $_MUX_ cells - - -keepdc - Do not optimize explicit don't-care values. -\end{lstlisting} - -\section{write\_aiger -- write design to AIGER file} -\label{cmd:write_aiger} -\begin{lstlisting}[numbers=left,frame=single] - write_aiger [options] [filename] - -Write the current design to an AIGER file. The design must be flattened and -must not contain any cell types except $_AND_, $_NOT_, simple FF types, -$assert and $assume cells, and $initstate cells. - -$assert and $assume cells are converted to AIGER bad state properties and -invariant constraints. - - -ascii - write ASCII version of AIGER format - - -zinit - convert FFs to zero-initialized FFs, adding additional inputs for - uninitialized FFs. - - -miter - design outputs are AIGER bad state properties - - -symbols - include a symbol table in the generated AIGER file - - -map <filename> - write an extra file with port and latch symbols - - -vmap <filename> - like -map, but more verbose - - -no-startoffset - make indexes zero based, enable using map files with smt solvers. - - -ywmap <filename> - write a map file for conversion to and from yosys witness traces. - - -I, -O, -B, -L - If the design contains no input/output/assert/flip-flop then create one - dummy input/output/bad_state-pin or latch to make the tools reading the - AIGER file happy. -\end{lstlisting} - -\section{write\_blif -- write design to BLIF file} -\label{cmd:write_blif} -\begin{lstlisting}[numbers=left,frame=single] - write_blif [options] [filename] - -Write the current design to an BLIF file. - - -top top_module - set the specified module as design top module - - -buf <cell-type> <in-port> <out-port> - use cells of type <cell-type> with the specified port names for buffers - - -unbuf <cell-type> <in-port> <out-port> - replace buffer cells with the specified name and port names with - a .names statement that models a buffer - - -true <cell-type> <out-port> - -false <cell-type> <out-port> - -undef <cell-type> <out-port> - use the specified cell types to drive nets that are constant 1, 0, or - undefined. when '-' is used as <cell-type>, then <out-port> specifies - the wire name to be used for the constant signal and no cell driving - that wire is generated. when '+' is used as <cell-type>, then <out-port> - specifies the wire name to be used for the constant signal and a .names - statement is generated to drive the wire. - - -noalias - if a net name is aliasing another net name, then by default a net - without fanout is created that is driven by the other net. This option - suppresses the generation of this nets without fanout. - -The following options can be useful when the generated file is not going to be -read by a BLIF parser but a custom tool. It is recommended to not name the -output file *.blif when any of this options is used. - - -icells - do not translate Yosys's internal gates to generic BLIF logic - functions. Instead create .subckt or .gate lines for all cells. - - -gates - print .gate instead of .subckt lines for all cells that are not - instantiations of other modules from this design. - - -conn - do not generate buffers for connected wires. instead use the - non-standard .conn statement. - - -attr - use the non-standard .attr statement to write cell attributes - - -param - use the non-standard .param statement to write cell parameters - - -cname - use the non-standard .cname statement to write cell names - - -iname, -iattr - enable -cname and -attr functionality for .names statements - (the .cname and .attr statements will be included in the BLIF - output after the truth table for the .names statement) - - -blackbox - write blackbox cells with .blackbox statement. - - -impltf - do not write definitions for the $true, $false and $undef wires. -\end{lstlisting} - -\section{write\_btor -- write design to BTOR file} -\label{cmd:write_btor} -\begin{lstlisting}[numbers=left,frame=single] - write_btor [options] [filename] - -Write a BTOR description of the current design. - - -v - Add comments and indentation to BTOR output file - - -s - Output only a single bad property for all asserts - - -c - Output cover properties using 'bad' statements instead of asserts - - -i <filename> - Create additional info file with auxiliary information - - -x - Output symbols for internal netnames (starting with '$') -\end{lstlisting} - -\section{write\_cxxrtl -- convert design to C++ RTL simulation} -\label{cmd:write_cxxrtl} -\begin{lstlisting}[numbers=left,frame=single] - write_cxxrtl [options] [filename] - -Write C++ code that simulates the design. The generated code requires a driver -that instantiates the design, toggles its clock, and interacts with its ports. - -The following driver may be used as an example for a design with a single clock -driving rising edge triggered flip-flops: - - #include "top.cc" - - int main() { - cxxrtl_design::p_top top; - top.step(); - while (1) { - /* user logic */ - top.p_clk.set(false); - top.step(); - top.p_clk.set(true); - top.step(); - } - } - -Note that CXXRTL simulations, just like the hardware they are simulating, are -subject to race conditions. If, in the example above, the user logic would run -simultaneously with the rising edge of the clock, the design would malfunction. - -This backend supports replacing parts of the design with black boxes implemented -in C++. If a module marked as a CXXRTL black box, its implementation is ignored, -and the generated code consists only of an interface and a factory function. -The driver must implement the factory function that creates an implementation of -the black box, taking into account the parameters it is instantiated with. - -For example, the following Verilog code defines a CXXRTL black box interface for -a synchronous debug sink: - - (* cxxrtl_blackbox *) - module debug(...); - (* cxxrtl_edge = "p" *) input clk; - input en; - input [7:0] i_data; - (* cxxrtl_sync *) output [7:0] o_data; - endmodule - -For this HDL interface, this backend will generate the following C++ interface: - - struct bb_p_debug : public module { - value<1> p_clk; - bool posedge_p_clk() const { /* ... */ } - value<1> p_en; - value<8> p_i_data; - wire<8> p_o_data; - - bool eval() override; - bool commit() override; - - static std::unique_ptr<bb_p_debug> - create(std::string name, metadata_map parameters, metadata_map attributes); - }; - -The `create' function must be implemented by the driver. For example, it could -always provide an implementation logging the values to standard error stream: - - namespace cxxrtl_design { - - struct stderr_debug : public bb_p_debug { - bool eval() override { - if (posedge_p_clk() && p_en) - fprintf(stderr, "debug: %02x\n", p_i_data.data[0]); - p_o_data.next = p_i_data; - return bb_p_debug::eval(); - } - }; - - std::unique_ptr<bb_p_debug> - bb_p_debug::create(std::string name, cxxrtl::metadata_map parameters, - cxxrtl::metadata_map attributes) { - return std::make_unique<stderr_debug>(); - } - - } - -For complex applications of black boxes, it is possible to parameterize their -port widths. For example, the following Verilog code defines a CXXRTL black box -interface for a configurable width debug sink: - - (* cxxrtl_blackbox, cxxrtl_template = "WIDTH" *) - module debug(...); - parameter WIDTH = 8; - (* cxxrtl_edge = "p" *) input clk; - input en; - (* cxxrtl_width = "WIDTH" *) input [WIDTH - 1:0] i_data; - (* cxxrtl_width = "WIDTH" *) output [WIDTH - 1:0] o_data; - endmodule - -For this parametric HDL interface, this backend will generate the following C++ -interface (only the differences are shown): - - template<size_t WIDTH> - struct bb_p_debug : public module { - // ... - value<WIDTH> p_i_data; - wire<WIDTH> p_o_data; - // ... - static std::unique_ptr<bb_p_debug<WIDTH>> - create(std::string name, metadata_map parameters, metadata_map attributes); - }; - -The `create' function must be implemented by the driver, specialized for every -possible combination of template parameters. (Specialization is necessary to -enable separate compilation of generated code and black box implementations.) - - template<size_t SIZE> - struct stderr_debug : public bb_p_debug<SIZE> { - // ... - }; - - template<> - std::unique_ptr<bb_p_debug<8>> - bb_p_debug<8>::create(std::string name, cxxrtl::metadata_map parameters, - cxxrtl::metadata_map attributes) { - return std::make_unique<stderr_debug<8>>(); - } - -The following attributes are recognized by this backend: - - cxxrtl_blackbox - only valid on modules. if specified, the module contents are ignored, - and the generated code includes only the module interface and a factory - function, which will be called to instantiate the module. - - cxxrtl_edge - only valid on inputs of black boxes. must be one of "p", "n", "a". - if specified on signal `clk`, the generated code includes edge detectors - `posedge_p_clk()` (if "p"), `negedge_p_clk()` (if "n"), or both (if - "a"), simplifying implementation of clocked black boxes. - - cxxrtl_template - only valid on black boxes. must contain a space separated sequence of - identifiers that have a corresponding black box parameters. for each - of them, the generated code includes a `size_t` template parameter. - - cxxrtl_width - only valid on ports of black boxes. must be a constant expression, which - is directly inserted into generated code. - - cxxrtl_comb, cxxrtl_sync - only valid on outputs of black boxes. if specified, indicates that every - bit of the output port is driven, correspondingly, by combinatorial or - synchronous logic. this knowledge is used for scheduling optimizations. - if neither is specified, the output will be pessimistically treated as - driven by both combinatorial and synchronous logic. - -The following options are supported by this backend: - - -print-wire-types, -print-debug-wire-types - enable additional debug logging, for pass developers. - - -header - generate separate interface (.h) and implementation (.cc) files. - if specified, the backend must be called with a filename, and filename - of the interface is derived from filename of the implementation. - otherwise, interface and implementation are generated together. - - -namespace <ns-name> - place the generated code into namespace <ns-name>. if not specified, - "cxxrtl_design" is used. - - -nohierarchy - use design hierarchy as-is. in most designs, a top module should be - present as it is exposed through the C API and has unbuffered outputs - for improved performance; it will be determined automatically if absent. - - -noflatten - don't flatten the design. fully flattened designs can evaluate within - one delta cycle if they have no combinatorial feedback. - note that the debug interface and waveform dumps use full hierarchical - names for all wires even in flattened designs. - - -noproc - don't convert processes to netlists. in most designs, converting - processes significantly improves evaluation performance at the cost of - slight increase in compilation time. - - -O <level> - set the optimization level. the default is -O6. higher optimization - levels dramatically decrease compile and run time, and highest level - possible for a design should be used. - - -O0 - no optimization. - - -O1 - unbuffer internal wires if possible. - - -O2 - like -O1, and localize internal wires if possible. - - -O3 - like -O2, and inline internal wires if possible. - - -O4 - like -O3, and unbuffer public wires not marked (*keep*) if possible. - - -O5 - like -O4, and localize public wires not marked (*keep*) if possible. - - -O6 - like -O5, and inline public wires not marked (*keep*) if possible. - - -g <level> - set the debug level. the default is -g4. higher debug levels provide - more visibility and generate more code, but do not pessimize evaluation. - - -g0 - no debug information. the C API is disabled. - - -g1 - include bare minimum of debug information necessary to access all design - state. the C API is enabled. - - -g2 - like -g1, but include debug information for all public wires that are - directly accessible through the C++ interface. - - -g3 - like -g2, and include debug information for public wires that are tied - to a constant or another public wire. - - -g4 - like -g3, and compute debug information on demand for all public wires - that were optimized out. -\end{lstlisting} - -\section{write\_edif -- write design to EDIF netlist file} -\label{cmd:write_edif} -\begin{lstlisting}[numbers=left,frame=single] - write_edif [options] [filename] - -Write the current design to an EDIF netlist file. - - -top top_module - set the specified module as design top module - - -nogndvcc - do not create "GND" and "VCC" cells. (this will produce an error - if the design contains constant nets. use "hilomap" to map to custom - constant drivers first) - - -gndvccy - create "GND" and "VCC" cells with "Y" outputs. (the default is - "G" for "GND" and "P" for "VCC".) - - -attrprop - create EDIF properties for cell attributes - - -keep - create extra KEEP nets by allowing a cell to drive multiple nets. - - -pvector {par|bra|ang} - sets the delimiting character for module port rename clauses to - parentheses, square brackets, or angle brackets. - -Unfortunately there are different "flavors" of the EDIF file format. This -command generates EDIF files for the Xilinx place&route tools. It might be -necessary to make small modifications to this command when a different tool -is targeted. -\end{lstlisting} - -\section{write\_file -- write a text to a file} -\label{cmd:write_file} -\begin{lstlisting}[numbers=left,frame=single] - write_file [options] output_file [input_file] - -Write the text from the input file to the output file. - - -a - Append to output file (instead of overwriting) - - -Inside a script the input file can also can a here-document: - - write_file hello.txt <<EOT - Hello World! - EOT -\end{lstlisting} - -\section{write\_firrtl -- write design to a FIRRTL file} -\label{cmd:write_firrtl} -\begin{lstlisting}[numbers=left,frame=single] - write_firrtl [options] [filename] - -Write a FIRRTL netlist of the current design. -The following commands are executed by this command: - pmuxtree - bmuxmap - demuxmap -\end{lstlisting} - -\section{write\_ilang -- (deprecated) alias of write\_rtlil} -\label{cmd:write_ilang} -\begin{lstlisting}[numbers=left,frame=single] -See `help write_rtlil`. -\end{lstlisting} - -\section{write\_intersynth -- write design to InterSynth netlist file} -\label{cmd:write_intersynth} -\begin{lstlisting}[numbers=left,frame=single] - write_intersynth [options] [filename] - -Write the current design to an 'intersynth' netlist file. InterSynth is -a tool for Coarse-Grain Example-Driven Interconnect Synthesis. - - -notypes - do not generate celltypes and conntypes commands. i.e. just output - the netlists. this is used for postsilicon synthesis. - - -lib <verilog_or_rtlil_file> - Use the specified library file for determining whether cell ports are - inputs or outputs. This option can be used multiple times to specify - more than one library. - - -selected - only write selected modules. modules must be selected entirely or - not at all. - -http://bygone.clairexen.net/intersynth/ -\end{lstlisting} - -\section{write\_jny -- generate design metadata} -\label{cmd:write_jny} -\begin{lstlisting}[numbers=left,frame=single] - jny [options] [selection] - -Write JSON netlist metadata for the current design - - -no-connections - Don't include connection information in the netlist output. - - -no-attributes - Don't include attributed information in the netlist output. - - -no-properties - Don't include property information in the netlist output. - -The JSON schema for JNY output files is located in the "jny.schema.json" file -which is located at "https://raw.githubusercontent.com/YosysHQ/yosys/master/misc/jny.schema.json" -\end{lstlisting} - -\section{write\_json -- write design to a JSON file} -\label{cmd:write_json} -\begin{lstlisting}[numbers=left,frame=single] - write_json [options] [filename] - -Write a JSON netlist of the current design. - - -aig - include AIG models for the different gate types - - -compat-int - emit 32-bit or smaller fully-defined parameter values directly - as JSON numbers (for compatibility with old parsers) - - -The general syntax of the JSON output created by this command is as follows: - - { - "creator": "Yosys <version info>", - "modules": { - <module_name>: { - "attributes": { - <attribute_name>: <attribute_value>, - ... - }, - "parameter_default_values": { - <parameter_name>: <parameter_value>, - ... - }, - "ports": { - <port_name>: <port_details>, - ... - }, - "cells": { - <cell_name>: <cell_details>, - ... - }, - "memories": { - <memory_name>: <memory_details>, - ... - }, - "netnames": { - <net_name>: <net_details>, - ... - } - } - }, - "models": { - ... - }, - } - -Where <port_details> is: - - { - "direction": <"input" | "output" | "inout">, - "bits": <bit_vector> - "offset": <the lowest bit index in use, if non-0> - "upto": <1 if the port bit indexing is MSB-first> - "signed": <1 if the port is signed> - } - -The "offset" and "upto" fields are skipped if their value would be 0. -They don't affect connection semantics, and are only used to preserve original -HDL bit indexing.And <cell_details> is: - - { - "hide_name": <1 | 0>, - "type": <cell_type>, - "model": <AIG model name, if -aig option used>, - "parameters": { - <parameter_name>: <parameter_value>, - ... - }, - "attributes": { - <attribute_name>: <attribute_value>, - ... - }, - "port_directions": { - <port_name>: <"input" | "output" | "inout">, - ... - }, - "connections": { - <port_name>: <bit_vector>, - ... - }, - } - -And <memory_details> is: - - { - "hide_name": <1 | 0>, - "attributes": { - <attribute_name>: <attribute_value>, - ... - }, - "width": <memory width> - "start_offset": <the lowest valid memory address> - "size": <memory size> - } - -And <net_details> is: - - { - "hide_name": <1 | 0>, - "bits": <bit_vector> - "offset": <the lowest bit index in use, if non-0> - "upto": <1 if the port bit indexing is MSB-first> - "signed": <1 if the port is signed> - } - -The "hide_name" fields are set to 1 when the name of this cell or net is -automatically created and is likely not of interest for a regular user. - -The "port_directions" section is only included for cells for which the -interface is known. - -Module and cell ports and nets can be single bit wide or vectors of multiple -bits. Each individual signal bit is assigned a unique integer. The <bit_vector> -values referenced above are vectors of this integers. Signal bits that are -connected to a constant driver are denoted as string "0", "1", "x", or -"z" instead of a number. - -Bit vectors (including integers) are written as string holding the binary -representation of the value. Strings are written as strings, with an appended -blank in cases of strings of the form /[01xz]* */. - -For example the following Verilog code: - - module test(input x, y); - (* keep *) foo #(.P(42), .Q(1337)) - foo_inst (.A({x, y}), .B({y, x}), .C({4'd10, {4{x}}})); - endmodule - -Translates to the following JSON output: - - { - "creator": "Yosys 0.9+2406 (git sha1 fb1168d8, clang 9.0.1 -fPIC -Os)", - "modules": { - "test": { - "attributes": { - "cells_not_processed": "00000000000000000000000000000001", - "src": "test.v:1.1-4.10" - }, - "ports": { - "x": { - "direction": "input", - "bits": [ 2 ] - }, - "y": { - "direction": "input", - "bits": [ 3 ] - } - }, - "cells": { - "foo_inst": { - "hide_name": 0, - "type": "foo", - "parameters": { - "P": "00000000000000000000000000101010", - "Q": "00000000000000000000010100111001" - }, - "attributes": { - "keep": "00000000000000000000000000000001", - "module_not_derived": "00000000000000000000000000000001", - "src": "test.v:3.1-3.55" - }, - "connections": { - "A": [ 3, 2 ], - "B": [ 2, 3 ], - "C": [ 2, 2, 2, 2, "0", "1", "0", "1" ] - } - } - }, - "netnames": { - "x": { - "hide_name": 0, - "bits": [ 2 ], - "attributes": { - "src": "test.v:1.19-1.20" - } - }, - "y": { - "hide_name": 0, - "bits": [ 3 ], - "attributes": { - "src": "test.v:1.22-1.23" - } - } - } - } - } - } - -The models are given as And-Inverter-Graphs (AIGs) in the following form: - - "models": { - <model_name>: [ - /* 0 */ [ <node-spec> ], - /* 1 */ [ <node-spec> ], - /* 2 */ [ <node-spec> ], - ... - ], - ... - }, - -The following node-types may be used: - - [ "port", <portname>, <bitindex>, <out-list> ] - - the value of the specified input port bit - - [ "nport", <portname>, <bitindex>, <out-list> ] - - the inverted value of the specified input port bit - - [ "and", <node-index>, <node-index>, <out-list> ] - - the ANDed value of the specified nodes - - [ "nand", <node-index>, <node-index>, <out-list> ] - - the inverted ANDed value of the specified nodes - - [ "true", <out-list> ] - - the constant value 1 - - [ "false", <out-list> ] - - the constant value 0 - -All nodes appear in topological order. I.e. only nodes with smaller indices -are referenced by "and" and "nand" nodes. - -The optional <out-list> at the end of a node specification is a list of -output portname and bitindex pairs, specifying the outputs driven by this node. - -For example, the following is the model for a 3-input 3-output $reduce_and cell -inferred by the following code: - - module test(input [2:0] in, output [2:0] out); - assign in = &out; - endmodule - - "$reduce_and:3U:3": [ - /* 0 */ [ "port", "A", 0 ], - /* 1 */ [ "port", "A", 1 ], - /* 2 */ [ "and", 0, 1 ], - /* 3 */ [ "port", "A", 2 ], - /* 4 */ [ "and", 2, 3, "Y", 0 ], - /* 5 */ [ "false", "Y", 1, "Y", 2 ] - ] - -Future version of Yosys might add support for additional fields in the JSON -format. A program processing this format must ignore all unknown fields. -\end{lstlisting} - -\section{write\_rtlil -- write design to RTLIL file} -\label{cmd:write_rtlil} -\begin{lstlisting}[numbers=left,frame=single] - write_rtlil [filename] - -Write the current design to an RTLIL file. (RTLIL is a text representation -of a design in yosys's internal format.) - - -selected - only write selected parts of the design. -\end{lstlisting} - -\section{write\_simplec -- convert design to simple C code} -\label{cmd:write_simplec} -\begin{lstlisting}[numbers=left,frame=single] - write_simplec [options] [filename] - -Write simple C code for simulating the design. The C code written can be used to -simulate the design in a C environment, but the purpose of this command is to -generate code that works well with C-based formal verification. - - -verbose - this will print the recursive walk used to export the modules. - - -i8, -i16, -i32, -i64 - set the maximum integer bit width to use in the generated code. - -THIS COMMAND IS UNDER CONSTRUCTION -\end{lstlisting} - -\section{write\_smt2 -- write design to SMT-LIBv2 file} -\label{cmd:write_smt2} -\begin{lstlisting}[numbers=left,frame=single] - write_smt2 [options] [filename] - -Write a SMT-LIBv2 [1] description of the current design. For a module with name -'<mod>' this will declare the sort '<mod>_s' (state of the module) and will -define and declare functions operating on that state. - -The following SMT2 functions are generated for a module with name '<mod>'. -Some declarations/definitions are printed with a special comment. A prover -using the SMT2 files can use those comments to collect all relevant metadata -about the design. - - ; yosys-smt2-module <mod> - (declare-sort |<mod>_s| 0) - The sort representing a state of module <mod>. - - (define-fun |<mod>_h| ((state |<mod>_s|)) Bool (...)) - This function must be asserted for each state to establish the - design hierarchy. - - ; yosys-smt2-input <wirename> <width> - ; yosys-smt2-output <wirename> <width> - ; yosys-smt2-register <wirename> <width> - ; yosys-smt2-wire <wirename> <width> - (define-fun |<mod>_n <wirename>| (|<mod>_s|) (_ BitVec <width>)) - (define-fun |<mod>_n <wirename>| (|<mod>_s|) Bool) - For each port, register, and wire with the 'keep' attribute set an - accessor function is generated. Single-bit wires are returned as Bool, - multi-bit wires as BitVec. - - ; yosys-smt2-cell <submod> <instancename> - (declare-fun |<mod>_h <instancename>| (|<mod>_s|) |<submod>_s|) - There is a function like that for each hierarchical instance. It - returns the sort that represents the state of the sub-module that - implements the instance. - - (declare-fun |<mod>_is| (|<mod>_s|) Bool) - This function must be asserted 'true' for initial states, and 'false' - otherwise. - - (define-fun |<mod>_i| ((state |<mod>_s|)) Bool (...)) - This function must be asserted 'true' for initial states. For - non-initial states it must be left unconstrained. - - (define-fun |<mod>_t| ((state |<mod>_s|) (next_state |<mod>_s|)) Bool (...)) - This function evaluates to 'true' if the states 'state' and - 'next_state' form a valid state transition. - - (define-fun |<mod>_a| ((state |<mod>_s|)) Bool (...)) - This function evaluates to 'true' if all assertions hold in the state. - - (define-fun |<mod>_u| ((state |<mod>_s|)) Bool (...)) - This function evaluates to 'true' if all assumptions hold in the state. - - ; yosys-smt2-assert <id> <filename:linenum> - (define-fun |<mod>_a <id>| ((state |<mod>_s|)) Bool (...)) - Each $assert cell is converted into one of this functions. The function - evaluates to 'true' if the assert statement holds in the state. - - ; yosys-smt2-assume <id> <filename:linenum> - (define-fun |<mod>_u <id>| ((state |<mod>_s|)) Bool (...)) - Each $assume cell is converted into one of this functions. The function - evaluates to 'true' if the assume statement holds in the state. - - ; yosys-smt2-cover <id> <filename:linenum> - (define-fun |<mod>_c <id>| ((state |<mod>_s|)) Bool (...)) - Each $cover cell is converted into one of this functions. The function - evaluates to 'true' if the cover statement is activated in the state. - -Options: - - -verbose - this will print the recursive walk used to export the modules. - - -stbv - Use a BitVec sort to represent a state instead of an uninterpreted - sort. As a side-effect this will prevent use of arrays to model - memories. - - -stdt - Use SMT-LIB 2.6 style datatypes to represent a state instead of an - uninterpreted sort. - - -nobv - disable support for BitVec (FixedSizeBitVectors theory). without this - option multi-bit wires are represented using the BitVec sort and - support for coarse grain cells (incl. arithmetic) is enabled. - - -nomem - disable support for memories (via ArraysEx theory). this option is - implied by -nobv. only $mem cells without merged registers in - read ports are supported. call "memory" with -nordff to make sure - that no registers are merged into $mem read ports. '<mod>_m' functions - will be generated for accessing the arrays that are used to represent - memories. - - -wires - create '<mod>_n' functions for all public wires. by default only ports, - registers, and wires with the 'keep' attribute are exported. - - -tpl <template_file> - use the given template file. the line containing only the token '%%' - is replaced with the regular output of this command. - - -solver-option <option> <value> - emit a `; yosys-smt2-solver-option` directive for yosys-smtbmc to write - the given option as a `(set-option ...)` command in the SMT-LIBv2. - -[1] For more information on SMT-LIBv2 visit http://smt-lib.org/ or read David -R. Cok's tutorial: https://smtlib.github.io/jSMTLIB/SMTLIBTutorial.pdf - ---------------------------------------------------------------------------- - -Example: - -Consider the following module (test.v). We want to prove that the output can -never transition from a non-zero value to a zero value. - - module test(input clk, output reg [3:0] y); - always @(posedge clk) - y <= (y << 1) | ^y; - endmodule - -For this proof we create the following template (test.tpl). - - ; we need QF_UFBV for this proof - (set-logic QF_UFBV) - - ; insert the auto-generated code here - %% - - ; declare two state variables s1 and s2 - (declare-fun s1 () test_s) - (declare-fun s2 () test_s) - - ; state s2 is the successor of state s1 - (assert (test_t s1 s2)) - - ; we are looking for a model with y non-zero in s1 - (assert (distinct (|test_n y| s1) #b0000)) - - ; we are looking for a model with y zero in s2 - (assert (= (|test_n y| s2) #b0000)) - - ; is there such a model? - (check-sat) - -The following yosys script will create a 'test.smt2' file for our proof: - - read_verilog test.v - hierarchy -check; proc; opt; check -assert - write_smt2 -bv -tpl test.tpl test.smt2 - -Running 'cvc4 test.smt2' will print 'unsat' because y can never transition -from non-zero to zero in the test design. -\end{lstlisting} - -\section{write\_smv -- write design to SMV file} -\label{cmd:write_smv} -\begin{lstlisting}[numbers=left,frame=single] - write_smv [options] [filename] - -Write an SMV description of the current design. - - -verbose - this will print the recursive walk used to export the modules. - - -tpl <template_file> - use the given template file. the line containing only the token '%%' - is replaced with the regular output of this command. - -THIS COMMAND IS UNDER CONSTRUCTION -\end{lstlisting} - -\section{write\_spice -- write design to SPICE netlist file} -\label{cmd:write_spice} -\begin{lstlisting}[numbers=left,frame=single] - write_spice [options] [filename] - -Write the current design to an SPICE netlist file. - - -big_endian - generate multi-bit ports in MSB first order - (default is LSB first) - - -neg net_name - set the net name for constant 0 (default: Vss) - - -pos net_name - set the net name for constant 1 (default: Vdd) - - -buf DC|subckt_name - set the name for jumper element (default: DC) - (used to connect different nets) - - -nc_prefix - prefix for not-connected nets (default: _NC) - - -inames - include names of internal ($-prefixed) nets in outputs - (default is to use net numbers instead) - - -top top_module - set the specified module as design top module -\end{lstlisting} - -\section{write\_table -- write design as connectivity table} -\label{cmd:write_table} -\begin{lstlisting}[numbers=left,frame=single] - write_table [options] [filename] - -Write the current design as connectivity table. The output is a tab-separated -ASCII table with the following columns: - - module name - cell name - cell type - cell port - direction - signal - -module inputs and outputs are output using cell type and port '-' and with -'pi' (primary input) or 'po' (primary output) or 'pio' as direction. -\end{lstlisting} - -\section{write\_verilog -- write design to Verilog file} -\label{cmd:write_verilog} -\begin{lstlisting}[numbers=left,frame=single] - write_verilog [options] [filename] - -Write the current design to a Verilog file. - - -sv - with this option, SystemVerilog constructs like always_comb are used - - -norename - without this option all internal object names (the ones with a dollar - instead of a backslash prefix) are changed to short names in the - format '_<number>_'. - - -renameprefix <prefix> - insert this prefix in front of auto-generated instance names - - -noattr - with this option no attributes are included in the output - - -attr2comment - with this option attributes are included as comments in the output - - -noexpr - without this option all internal cells are converted to Verilog - expressions. - - -siminit - add initial statements with hierarchical refs to initialize FFs when - in -noexpr mode. - - -nodec - 32-bit constant values are by default dumped as decimal numbers, - not bit pattern. This option deactivates this feature and instead - will write out all constants in binary. - - -decimal - dump 32-bit constants in decimal and without size and radix - - -nohex - constant values that are compatible with hex output are usually - dumped as hex values. This option deactivates this feature and - instead will write out all constants in binary. - - -nostr - Parameters and attributes that are specified as strings in the - original input will be output as strings by this back-end. This - deactivates this feature and instead will write string constants - as binary numbers. - - -simple-lhs - Connection assignments with simple left hand side without - concatenations. - - -extmem - instead of initializing memories using assignments to individual - elements, use the '$readmemh' function to read initialization data - from a file. This data is written to a file named by appending - a sequential index to the Verilog filename and replacing the extension - with '.mem', e.g. 'write_verilog -extmem foo.v' writes 'foo-1.mem', - 'foo-2.mem' and so on. - - -defparam - use 'defparam' statements instead of the Verilog-2001 syntax for - cell parameters. - - -blackboxes - usually modules with the 'blackbox' attribute are ignored. with - this option set only the modules with the 'blackbox' attribute - are written to the output file. - - -selected - only write selected modules. modules must be selected entirely or - not at all. - - -v - verbose output (print new names of all renamed wires and cells) - -Note that RTLIL processes can't always be mapped directly to Verilog -always blocks. This frontend should only be used to export an RTLIL -netlist, i.e. after the "proc" pass has been used to convert all -processes to logic networks and registers. A warning is generated when -this command is called on a design with RTLIL processes. -\end{lstlisting} - -\section{write\_xaiger -- write design to XAIGER file} -\label{cmd:write_xaiger} -\begin{lstlisting}[numbers=left,frame=single] - write_xaiger [options] [filename] - -Write the top module (according to the (* top *) attribute or if only one module -is currently selected) to an XAIGER file. Any non $_NOT_, $_AND_, (optionally -$_DFF_N_, $_DFF_P_), or non (* abc9_box *) cells will be converted into psuedo- -inputs and pseudo-outputs. Whitebox contents will be taken from the equivalent -module in the '$abc9_holes' design, if it exists. - - -ascii - write ASCII version of AIGER format - - -map <filename> - write an extra file with port and box symbols - - -dff - write $_DFF_[NP]_ cells -\end{lstlisting} - -\section{xilinx\_dffopt -- Xilinx: optimize FF control signal usage} -\label{cmd:xilinx_dffopt} -\begin{lstlisting}[numbers=left,frame=single] - xilinx_dffopt [options] [selection] - -Converts hardware clock enable and set/reset signals on FFs to emulation -using LUTs, if doing so would improve area. Operates on post-techmap Xilinx -cells (LUT*, FD*). - - -lut4 - Assume a LUT4-based device (instead of a LUT6-based device). -\end{lstlisting} - -\section{xilinx\_dsp -- Xilinx: pack resources into DSPs} -\label{cmd:xilinx_dsp} -\begin{lstlisting}[numbers=left,frame=single] - xilinx_dsp [options] [selection] - -Pack input registers (A2, A1, B2, B1, C, D, AD; with optional enable/reset), -pipeline registers (M; with optional enable/reset), output registers (P; with -optional enable/reset), pre-adder and/or post-adder into Xilinx DSP resources. - -Multiply-accumulate operations using the post-adder with feedback on the 'C' -input will be folded into the DSP. In this scenario only, the 'C' input can be -used to override the current accumulation result with a new value, which will -be added to the multiplier result to form the next accumulation result. - -Use of the dedicated 'PCOUT' -> 'PCIN' cascade path is detected for 'P' -> 'C' -connections (optionally, where 'P' is right-shifted by 17-bits and used as an -input to the post-adder -- a pattern common for summing partial products to -implement wide multipliers). Limited support also exists for similar cascading -for A and B using '[AB]COUT' -> '[AB]CIN'. Currently, cascade chains are limited -to a maximum length of 20 cells, corresponding to the smallest Xilinx 7 Series -device. - -This pass is a no-op if the scratchpad variable 'xilinx_dsp.multonly' is set -to 1. - - -Experimental feature: addition/subtractions less than 12 or 24 bits with the -'(* use_dsp="simd" *)' attribute attached to the output wire or attached to -the add/subtract operator will cause those operations to be implemented using -the 'SIMD' feature of DSPs. - -Experimental feature: the presence of a `$ge' cell attached to the registered -P output implementing the operation "(P >= <power-of-2>)" will be transformed -into using the DSP48E1's pattern detector feature for overflow detection. - - -family {xcup|xcu|xc7|xc6v|xc5v|xc4v|xc6s|xc3sda} - select the family to target - default: xc7 -\end{lstlisting} - -\section{xilinx\_srl -- Xilinx shift register extraction} -\label{cmd:xilinx_srl} -\begin{lstlisting}[numbers=left,frame=single] - xilinx_srl [options] [selection] - -This pass converts chains of built-in flops (bit-level: $_DFF_[NP]_, $_DFFE_* -and word-level: $dff, $dffe) as well as Xilinx flops (FDRE, FDRE_1) into a -$__XILINX_SHREG cell. Chains must be of the same cell type, clock, clock -polarity, enable, and enable polarity (where relevant). -Flops with resets cannot be mapped to Xilinx devices and will not be inferred. - - -minlen N - min length of shift register (default = 3) - - -fixed - infer fixed-length shift registers. - - -variable - infer variable-length shift registers (i.e. fixed-length shifts where - each element also fans-out to a $shiftx cell). -\end{lstlisting} - -\section{zinit -- add inverters so all FF are zero-initialized} -\label{cmd:zinit} -\begin{lstlisting}[numbers=left,frame=single] - zinit [options] [selection] - -Add inverters as needed to make all FFs zero-initialized. - - -all - also add zero initialization to uninitialized FFs -\end{lstlisting} - diff --git a/manual/literature.bib b/manual/literature.bib deleted file mode 100644 index 86652eb46..000000000 --- a/manual/literature.bib +++ /dev/null @@ -1,163 +0,0 @@ - -@inproceedings{intersynth, - title={Example-driven interconnect synthesis for heterogeneous coarse-grain reconfigurable logic}, - author={C. Wolf and Johann Glaser and Florian Schupfer and Jan Haase and Christoph Grimm}, - booktitle={FDL Proceeding of the 2012 Forum on Specification and Design Languages}, - pages={194--201}, - year={2012} -} - -@incollection{intersynthFdlBookChapter, - title={Methodology and Example-Driven Interconnect Synthesis for Designing Heterogeneous Coarse-Grain Reconfigurable Architectures}, - author={Johann Glaser and C. Wolf}, - booktitle={Advances in Models, Methods, and Tools for Complex Chip Design --- Selected contributions from FDL'12}, - editor={Jan Haase}, - publisher={Springer}, - year={2013}, - note={to appear} -} - -@unpublished{BACC, - author = {C. Wolf}, - title = {Design and Implementation of the Yosys Open SYnthesis Suite}, - note = {Bachelor Thesis, Vienna University of Technology}, - year = {2013} -} - -@unpublished{VerilogFossEval, - author = {C. Wolf}, - title = {Evaluation of Open Source Verilog Synthesis Tools for Feature-Completeness and Extensibility}, - note = {Unpublished Student Research Paper, Vienna University of Technology}, - year = {2012} -} - -@article{ABEL, - title={A High-Level Design Language for Programmable Logic Devices}, - author={Kyu Y. Lee and Michael Holley and Mary Bailey and Walter Bright}, - journal={VLSI Design (Manhasset NY: CPM Publications)}, - year={June 1985}, - pages={50-62} -} - -@MISC{Cheng93vl2mv:a, - author = {S-T Cheng and G York and R K Brayton}, - title = {VL2MV: A Compiler from Verilog to BLIF-MV}, - year = {1993} -} - -@MISC{Odin, - author = {Peter Jamieson and Jonathan Rose}, - title = {A VERILOG RTL SYNTHESIS TOOL FOR HETEROGENEOUS FPGAS}, - year = {2005} -} - -@inproceedings{vtr2012, - title={The VTR Project: Architecture and CAD for FPGAs from Verilog to Routing}, - author={Jonathan Rose and Jason Luu and Chi Wai Yu and Opal Densmore and Jeff Goeders and Andrew Somerville and Kenneth B. Kent and Peter Jamieson and Jason Anderson}, - booktitle={Proceedings of the 20th ACM/SIGDA International Symposium on Field-Programmable Gate Arrays}, - pages={77--86}, - year={2012}, - organization={ACM} -} - -@MISC{LogicSynthesis, - author = {G D Hachtel and F Somenzi}, - title = {Logic Synthesis and Verification Algorithms}, - year = {1996} -} - -@ARTICLE{Verilog2005, - journal={IEEE Std 1364-2005 (Revision of IEEE Std 1364-2001)}, - title={IEEE Standard for Verilog Hardware Description Language}, - year={2006}, - doi={10.1109/IEEESTD.2006.99495} -} - -@ARTICLE{VerilogSynth, - journal={IEEE Std 1364.1-2002}, - title={IEEE Standard for Verilog Register Transfer Level Synthesis}, - year={2002}, - doi={10.1109/IEEESTD.2002.94220} -} - -@ARTICLE{VHDL, - journal={IEEE Std 1076-2008 (Revision of IEEE Std 1076-2002)}, title={IEEE Standard VHDL Language Reference Manual}, - year={2009}, - month={26}, - doi={10.1109/IEEESTD.2009.4772740} -} - -@ARTICLE{VHDLSynth, - journal={IEEE Std 1076.6-2004 (Revision of IEEE Std 1076.6-1999)}, title={IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis}, - year={2004}, - doi={10.1109/IEEESTD.2004.94802} -} - -@ARTICLE{IP-XACT, -journal={IEEE Std 1685-2009}, title={IEEE Standard for IP-XACT, Standard Structure for Packaging, Integrating, and Reusing IP within Tools Flows}, -year={2010}, -pages={C1-360}, -keywords={abstraction definitions, address space specification, bus definitions, design environment, EDA, electronic design automation, electronic system level, ESL, implementation constraints, IP-XACT, register transfer level, RTL, SCRs, semantic consistency rules, TGI, tight generator interface, tool and data interoperability, use models, XML design meta-data, XML schema}, -doi={10.1109/IEEESTD.2010.5417309},} - -@book{Dragonbook, -author = {Aho, Alfred V. and Sethi, Ravi and Ullman, Jeffrey D.}, -title = {Compilers: principles, techniques, and tools}, -year = {1986}, -isbn = {0-201-10088-6}, -publisher = {Addison-Wesley Longman Publishing Co., Inc.}, -address = {Boston, MA, USA}, -} - -@INPROCEEDINGS{Cummings00, -author = {Clifford E. Cummings and Sunburst Design Inc}, -title = {Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill}, -booktitle = {SNUG (Synopsys Users Group) 2000 User Papers, section-MC1 (1 st paper}, -year = {2000} -} - -@ARTICLE{MURPHY, - author={D. L. Klipstein}, - journal={Cahners Publishing Co., EEE Magazine, Vol. 15, No. 8}, - title={The Contributions of Edsel Murphy to the Understanding of the Behavior of Inanimate Objects}, - year={August 1967} -} - -@INPROCEEDINGS{fsmextract, -author={Yiqiong Shi and Chan Wai Ting and Bah-Hwee Gwee and Ye Ren}, -booktitle={Circuits and Systems (ISCAS), Proceedings of 2010 IEEE International Symposium on}, -title={A highly efficient method for extracting FSMs from flattened gate-level netlist}, -year={2010}, -pages={2610-2613}, -keywords={circuit CAD;finite state machines;microcontrollers;FSM;control-intensive circuits;finite state machines;flattened gate-level netlist;state register elimination technique;Automata;Circuit synthesis;Continuous wavelet transforms;Design automation;Digital circuits;Hardware design languages;Logic;Microcontrollers;Registers;Signal processing}, -doi={10.1109/ISCAS.2010.5537093},} - -@ARTICLE{MultiLevelLogicSynth, -author={Brayton, R.K. and Hachtel, G.D. and Sangiovanni-Vincentelli, A.L.}, -journal={Proceedings of the IEEE}, -title={Multilevel logic synthesis}, -year={1990}, -volume={78}, -number={2}, -pages={264-300}, -keywords={circuit layout CAD;integrated logic circuits;logic CAD;capsule summaries;definitions;detailed analysis;in-depth background;logic decomposition;logic minimisation;logic synthesis;logic synthesis techniques;multilevel combinational logic;multilevel logic synthesis;notation;perspective;survey;synthesis methods;technology mapping;testing;Application specific integrated circuits;Design automation;Integrated circuit synthesis;Logic design;Logic devices;Logic testing;Network synthesis;Programmable logic arrays;Signal synthesis;Silicon}, -doi={10.1109/5.52213}, -ISSN={0018-9219},} - -@article{UllmannSubgraphIsomorphism, - author = {Ullmann, J. R.}, - title = {An Algorithm for Subgraph Isomorphism}, - journal = {J. ACM}, - issue_date = {Jan. 1976}, - volume = {23}, - number = {1}, - month = jan, - year = {1976}, - issn = {0004-5411}, - pages = {31--42}, - numpages = {12}, - doi = {10.1145/321921.321925}, - acmid = {321925}, - publisher = {ACM}, - address = {New York, NY, USA}, -} diff --git a/manual/manual.sh b/manual/manual.sh deleted file mode 100755 index c4673938a..000000000 --- a/manual/manual.sh +++ /dev/null @@ -1,59 +0,0 @@ -#!/bin/bash - -fast_mode=false -update_mode=false - -set -- $(getopt fu "$@") -while [ $# -gt 0 ]; do - case "$1" in - -f) - fast_mode=true - ;; - -u) - update_mode=true - ;; - --) - shift - break - ;; - -*) - echo "$0: error - unrecognized option $1" 1>&2 - exit 1 - ;; - *) - break - esac - shift -done - -PDFTEX_OPT="-shell-escape -halt-on-error" - -if $update_mode; then - make -C .. - ../yosys -p 'help -write-tex-command-reference-manual' -fi - -if ! $fast_mode; then - md5sum *.aux *.bbl *.blg > autoloop.old -fi - -set -ex - -pdflatex $PDFTEX_OPT manual.tex - -if ! $fast_mode; then - bibtex manual.aux - bibtex weblink.aux - - while - md5sum *.aux *.bbl *.blg > autoloop.new - ! cmp autoloop.old autoloop.new - do - cp autoloop.new autoloop.old - pdflatex $PDFTEX_OPT manual.tex - done - - rm -f autoloop.old - rm -f autoloop.new -fi - diff --git a/manual/manual.tex b/manual/manual.tex deleted file mode 100644 index 1914df989..000000000 --- a/manual/manual.tex +++ /dev/null @@ -1,230 +0,0 @@ -\documentclass[oneside,a4paper]{book} - -\usepackage[T1]{fontenc} % required for luximono! -\usepackage{lmodern} -\usepackage[scaled=0.8]{luximono} % typewriter font with bold face - -% To install the luximono font files: -% getnonfreefonts-sys --all or -% getnonfreefonts-sys luximono -% -% when there are trouble you might need to: -% - Create /etc/texmf/updmap.d/99local-luximono.cfg -% containing the single line: Map ul9.map -% - Run update-updmap followed by mktexlsr and updmap-sys -% -% This commands must be executed as root with a root environment -% (i.e. run "sudo su" and then execute the commands in the root -% shell, don't just prefix the commands with "sudo"). - -% formats the text according the set language -\usepackage[english]{babel} -\usepackage[table,usenames]{xcolor} -% generates indices with the "\index" command -\usepackage{makeidx} -% enables import of graphics. We use pdflatex here so do the pdf optimisation. -%\usepackage[dvips]{graphicx} -\usepackage[pdftex]{graphicx} -\usepackage{pdfpages} -% includes floating objects like tables and figures. -\usepackage{float} -% for generating subfigures with ohne indented captions -\usepackage[hang]{subfigure} -% redefines and smartens captions of figures and tables (indentation, smaller and boldface) -\usepackage[hang,small,bf,center]{caption} -% enables tabstops and the numeration of lines -\usepackage{moreverb} -% enables user defined header and footer lines (former "fancyheadings") -\usepackage{fancyhdr} -% Some smart mathematical stuff -\usepackage{amsmath} -% Package for rotating several objects -\usepackage{rotating} -\usepackage{natbib} -\usepackage{epsf} -\usepackage{dsfont} -\usepackage[algochapter, boxruled, vlined]{algorithm2e} -%Activating and setting of character protruding - if you like -%\usepackage[activate,DVIoutput]{pdfcprot} -% If you really need special chars... -\usepackage[latin1]{inputenc} -% Hyperlinks -\usepackage[colorlinks,hyperindex,plainpages=false,% -pdftitle={Yosys Manual},% -pdfauthor={Claire Xenia Wolf},% -%pdfkeywords={keyword},% -pdfpagelabels,% -pagebackref,% -bookmarksopen=false% -]{hyperref} -% For the two different reference lists ... -\usepackage{multibib} -\usepackage{multirow} -\usepackage{booktabs} -\usepackage{pdfpages} - -\usepackage{listings} -\usepackage{pifont} -\usepackage{skull} -% \usepackage{draftwatermark} - -\usepackage{tikz} -\usetikzlibrary{calc} -\usetikzlibrary{arrows} -\usetikzlibrary{scopes} -\usetikzlibrary{through} -\usetikzlibrary{shapes.geometric} - -\usepackage{calc} -\usepackage[nounderscore]{syntax} - -\lstset{basicstyle=\ttfamily} - -\def\B#1{{\tt\textbackslash{}#1}} -\def\C#1{\lstinline[language=C++]{#1}} -\def\V#1{\lstinline[language=Verilog]{#1}} - -\newsavebox{\fixmebox} -\newenvironment{fixme}% -{\newcommand\colboxcolor{FFBBBB}% -\begin{lrbox}{\fixmebox}% -\begin{minipage}{\dimexpr\columnwidth-2\fboxsep\relax}} -{\end{minipage}\end{lrbox}\textbf{FIXME: }\\% -\colorbox[HTML]{\colboxcolor}{\usebox{\fixmebox}}} - -\newcites{weblink}{Internet References} - -\setcounter{secnumdepth}{3} -\makeindex - -\setlength{\oddsidemargin}{4mm} -\setlength{\evensidemargin}{-6mm} -\setlength{\textwidth}{162mm} -\setlength{\textheight}{230mm} -\setlength{\topmargin}{-5mm} - -\setlength{\parskip}{1.5ex plus 1ex minus 0.5ex} -\setlength{\parindent}{0pt} - -\lstdefinelanguage{liberty}{ - morecomment=[s]{/*}{*/}, - morekeywords={library,cell,area,pin,direction,function,clocked_on,next_state,clock,ff}, - morestring=[b]", -} - -\lstdefinelanguage{rtlil}{ - morecomment=[l]{\#}, - morekeywords={module,attribute,parameter,wire,memory,auto,width,offset,size,input,output,inout,cell,connect,switch,case,assign,sync,low,high,posedge,negedge,edge,always,update,process,end}, - morestring=[b]", -} - - - -\begin{document} - -\fancypagestyle{mypagestyle}{% -\fancyhf{}% -\fancyhead[C]{\leftmark}% -\fancyfoot[C]{\thepage}% -\renewcommand{\headrulewidth}{0pt}% -\renewcommand{\footrulewidth}{0pt}} -\pagestyle{mypagestyle} - -\thispagestyle{empty} -\null\vfil - -\begin{center} -\bf\Huge Yosys Manual - -\bigskip -\large Claire Xenia Wolf -\end{center} - -\vfil\null -\eject - -\chapter*{Abstract} -Most of today's digital design is done in HDL code (mostly Verilog or VHDL) and -with the help of HDL synthesis tools. - -In special cases such as synthesis for coarse-grain cell libraries or when -testing new synthesis algorithms it might be necessary to write a custom HDL -synthesis tool or add new features to an existing one. In these cases the -availability of a Free and Open Source (FOSS) synthesis tool that can be used -as basis for custom tools would be helpful. - -In the absence of such a tool, the Yosys Open SYnthesis Suite (Yosys) was -developed. This document covers the design and implementation of this tool. -At the moment the main focus of Yosys lies on the high-level aspects of -digital synthesis. The pre-existing FOSS logic-synthesis tool ABC is used -by Yosys to perform advanced gate-level optimizations. - -An evaluation of Yosys based on real-world designs is included. It is shown -that Yosys can be used as-is to synthesize such designs. The results produced -by Yosys in this tests where successfully verified using formal verification -and are comparable in quality to the results produced by a commercial -synthesis tool. - -\bigskip - -This document was originally published as bachelor thesis at the Vienna -University of Technology \cite{BACC}. - -\chapter*{Abbreviations} -\begin{tabular}{ll} -AIG & And-Inverter-Graph \\ -ASIC & Application-Specific Integrated Circuit \\ -AST & Abstract Syntax Tree \\ -BDD & Binary Decision Diagram \\ -BLIF & Berkeley Logic Interchange Format \\ -EDA & Electronic Design Automation \\ -EDIF & Electronic Design Interchange Format \\ -ER Diagram & Entity-Relationship Diagram \\ -FOSS & Free and Open-Source Software \\ -FPGA & Field-Programmable Gate Array \\ -FSM & Finite-state machine \\ -HDL & Hardware Description Language \\ -LPM & Library of Parameterized Modules \\ -RTLIL & RTL Intermediate Language \\ -RTL & Register Transfer Level \\ -SAT & Satisfiability Problem \\ -% SSA & Static Single Assignment Form \\ -VHDL & VHSIC Hardware Description Language \\ -VHSIC & Very-High-Speed Integrated Circuit \\ -YOSYS & Yosys Open SYnthesis Suite \\ -\end{tabular} - -\tableofcontents - -\include{CHAPTER_Intro} -\include{CHAPTER_Basics} -\include{CHAPTER_Approach} -\include{CHAPTER_Overview} -\include{CHAPTER_CellLib} -\include{CHAPTER_Prog} - -\include{CHAPTER_Verilog} -\include{CHAPTER_Optimize} -\include{CHAPTER_Techmap} -% \include{CHAPTER_Eval} - -\appendix - -\include{CHAPTER_Auxlibs} -\include{CHAPTER_Auxprogs} - -\chapter{Command Reference Manual} -\label{commandref} -\input{command-reference-manual} - -\include{CHAPTER_TextRtlil} -\include{CHAPTER_Appnotes} -% \include{CHAPTER_StateOfTheArt} - -\bibliography{literature} -\bibliographystyle{alphadin} - -\bibliographyweblink{weblinks} -\bibliographystyleweblink{abbrv} - -\end{document} diff --git a/manual/weblinks.bib b/manual/weblinks.bib deleted file mode 100644 index 23ddbc38b..000000000 --- a/manual/weblinks.bib +++ /dev/null @@ -1,134 +0,0 @@ - -@misc{YosysGit, - author = {Claire Xenia Wolf}, - title = {{Yosys Open SYnthesis Suite (YOSYS)}}, - note = {\url{http://github.com/YosysHQ/yosys}} -} - -@misc{YosysTestsGit, - author = {Claire Xenia Wolf}, - title = {{Yosys Test Bench}}, - note = {\url{http://github.com/YosysHQ/yosys-tests}} -} - -@misc{VlogHammer, - author = {Claire Xenia Wolf}, - title = {{VlogHammer Verilog Synthesis Regression Tests}}, - note = {\url{http://github.com/YosysHQ/VlogHammer}} -} - -@misc{Icarus, - author = {Stephen Williams}, - title = {{Icarus Verilog}}, - note = {Version 0.8.7, \url{http://iverilog.icarus.com/}} -} - -@misc{VTR, - author= {Jonathan Rose and Jason Luu and Chi Wai Yu and Opal Densmore and Jeff Goeders and Andrew Somerville and Kenneth B. Kent and Peter Jamieson and Jason Anderson}, - title = {{The Verilog-to-Routing (VTR) Project for FPGAs}}, - note = {Version 1.0, \url{https://code.google.com/p/vtr-verilog-to-routing/}} -} - -@misc{HANA, - author = {Parvez Ahmad}, - title = {{HDL Analyzer and Netlist Architect (HANA)}}, - note = {Verison linux64-1.0-alpha (2012-10-14), \url{http://sourceforge.net/projects/sim-sim/}} -} - -@misc{MVSIS, - author = {MVSIS group at Berkeley studies logic synthesis and verification for VLSI design}, - title = {{MVSIS: Logic Synthesis and Verification}}, - note = {Version 3.0, \url{http://embedded.eecs.berkeley.edu/mvsis/}} -} - -@misc{VIS, - author = {{The VIS group}}, - title = {{VIS: A system for Verification and Synthesis}}, - note = {Version 2.4, \url{http://vlsi.colorado.edu/~vis/}} -} - -@misc{ABC, - author = {{Berkeley Logic Synthesis and Verification Group}}, - title = {{ABC: A System for Sequential Synthesis and Verification}}, - note = {HQ Rev b5750272659f, 2012-10-28, \url{http://www.eecs.berkeley.edu/~alanmi/abc/}} -} - -@misc{AIGER, - author = {{Armin Biere, Johannes Kepler University Linz, Austria}}, - title = {{AIGER}}, - note = {\url{http://fmv.jku.at/aiger/}} -} - -@misc{XilinxWebPACK, - author = {{Xilinx, Inc.}}, - title = {{ISE WebPACK Design Software}}, - note = {\url{http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm}} -} - -@misc{QuartusWeb, - author = {{Altera, Inc.}}, - title = {{Quartus II Web Edition Software}}, - note = {\url{http://www.altera.com/products/software/quartus-ii/web-edition/qts-we-index.html}} -} - -@misc{OR1200, - title = {{OpenRISC 1200 CPU}}, - note = {\url{http://opencores.org/or1k/OR1200\_OpenRISC\_Processor}} -} - -@misc{openMSP430, - title = {{openMSP430 CPU}}, - note = {\url{http://opencores.org/project,openmsp430}} -} - -@misc{i2cmaster, - title = {{OpenCores I$^2$C Core}}, - note = {\url{http://opencores.org/project,i2c}} -} - -@misc{k68, - title = {{OpenCores k68 Core}}, - note = {\url{http://opencores.org/project,k68}} -} - -@misc{bison, - title = {{GNU Bison}}, - note = {\url{http://www.gnu.org/software/bison/}} -} - -@misc{flex, - title = {{Flex}}, - note = {\url{http://flex.sourceforge.net/}} -} - -@misc{C_to_Verilog, - title = {{C-to-Verilog}}, - note = {\url{http://www.c-to-verilog.com/}} -} - -@misc{LegUp, - title = {{LegUp}}, - note = {\url{http://legup.eecg.utoronto.ca/}} -} - -@misc{LibertyFormat, - title = {{The Liberty Library Modeling Standard}}, - note = {\url{http://www.opensourceliberty.org/}} -} - -@misc{ASIC-WORLD, - title = {{World of ASIC}}, - note = {\url{http://www.asic-world.com/}} -} - -@misc{Formality, - title = {{Synopsys Formality Equivalence Checking}}, - note = {\url{http://www.synopsys.com/Tools/Verification/FormalEquivalence/Pages/Formality.aspx}}, -} - -@misc{bigint, - author = {Matt McCutchen}, - title = {{C++ Big Integer Library}}, - note = {\url{http://mattmccutchen.net/bigint/}} -} - |