diff --git a/Makefile b/Makefile index 6a3b4fc0d..a51bfa1ce 100644 --- a/Makefile +++ b/Makefile @@ -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 diff --git a/README.md b/README.md index df2f54930..f3a63cbec 100644 --- a/README.md +++ b/README.md @@ -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/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 + .... 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, "
  • ", cmd.c_str()); - - escape_html(cmd); - escape_html(title); - escape_html(text); - - fprintf(idxf, "%s %s\n", cmd.c_str(), title.c_str()); - - fprintf(f, "@cmd_header %s@\n", cmd.c_str()); - fprintf(f, "

    %s - %s

    \n", cmd.c_str(), title.c_str()); - fprintf(f, "
    %s
    \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 -#include - -#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 '} 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 : -- :}. -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 :} 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 } -option. Secondly it is possible to load cell libraries into the design with -the {\tt read\_verilog -lib } 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 } 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 /}. 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 -}. It can later be recalled using {\tt select @}. In fact, the {\tt -@} 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="{{ A| B| Y}|$g0\nNOR|{}}" ]; -c11 [ shape=record, label="{{ A| Y}|$g1\nNOT|{}}" ]; -c12 [ shape=record, label="{{ A| Y}|$g2\nNOT|{}}" ]; -c13 [ shape=record, label="{{ A| B| Y}|$g3\nNOR|{}}" ]; -x0 [ shape=record, style=rounded, label=" 1:1 - 0:0 " ]; -x0:e -> c13:p9:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c14 [ shape=record, label="{{ A| B| Y}|$g4\nNOR|{}}" ]; -x1 [ shape=record, style=rounded, label=" 1:1 - 0:0 " ]; -x1:e -> c14:p8:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -x2 [ shape=record, style=rounded, label=" 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="{{ A| B}|$g0\nNOR|{ Y}}" ]; -c12 [ shape=record, label="{{ A}|$g1\nNOT|{ Y}}" ]; -c13 [ shape=record, label="{{ A}|$g2\nNOT|{ Y}}" ]; -c14 [ shape=record, label="{{ A| B}|$g3\nNOR|{ Y}}" ]; -c15 [ shape=record, label="{{ A| B}|$g4\nNOR|{ 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="{{ A| B}|$2\n$add|{ Y}}" ]; -v0 [ label="2'00" ]; -c14 [ shape=record, label="{{ A| B| S}|$3\n$mux|{ 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="{{ A| B}|$2\n$add|{ Y}}" ]; -c18 [ shape=record, label="{{ CLK| D}|$7\n$dff|{ Q}}" ]; -c20 [ shape=record, label="{{ A| B| S}|$5\n$mux|{ Y}}" ]; -v0 [ label="2'00" ]; -c21 [ shape=record, label="{{ A| B| S}|$3\n$mux|{ 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="{{ A| B}|$2\n$add|{ Y}}" ]; -c15 [ shape=record, label="{{ CLK| D}|$7\n$dff|{ Q}}" ]; -c17 [ shape=record, label="{{ A| B| S}|$5\n$mux|{ 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="{{ A| B}|$2\n$add|{ 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="{{ A| B}|$28\n$add|{ Y}}" ]; -c37 [ shape=record, label="{{ A| B}|$31\n$add|{ Y}}" ]; -c38 [ shape=record, label="{{ A| B}|$34\n$add|{ Y}}" ]; -c39 [ shape=record, label="{{ A| B}|$37\n$add|{ Y}}" ]; -c41 [ shape=record, label="{{ A| B| S}|$110\n$mux|{ Y}}" ]; -x0 [ shape=record, style=rounded, label=" 1:1 - 0:0 " ]; -x0:e -> c41:p40:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c42 [ shape=record, label="{{ A| B| S}|$113\n$mux|{ Y}}" ]; -x1 [ shape=record, style=rounded, label=" 0:0 - 0:0 " ]; -x1:e -> c42:p40:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c43 [ shape=record, label="{{ A| B| S}|$116\n$mux|{ Y}}" ]; -x2 [ shape=record, style=rounded, label=" 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="{{ A| B}|$145\n$and|{ Y}}" ]; -v4 [ label="1'1" ]; -c45 [ shape=record, label="{{ A| B}|$175\n$and|{ Y}}" ]; -v5 [ label="1'1" ]; -c46 [ shape=record, label="{{ A| B}|$205\n$and|{ Y}}" ]; -v6 [ label="1'1" ]; -c47 [ shape=record, label="{{ A| B}|$235\n$and|{ Y}}" ]; -v7 [ label="2'00" ]; -c48 [ shape=record, label="{{ A| B}|$143\n$eq|{ Y}}" ]; -v8 [ label="2'01" ]; -c49 [ shape=record, label="{{ A| B}|$173\n$eq|{ Y}}" ]; -v9 [ label="2'10" ]; -c50 [ shape=record, label="{{ A| B}|$203\n$eq|{ Y}}" ]; -v10 [ label="2'11" ]; -c51 [ shape=record, label="{{ A| B}|$233\n$eq|{ Y}}" ]; -c52 [ shape=record, label="{{ A| B| S}|$147\n$mux|{ Y}}" ]; -c53 [ shape=record, label="{{ A| B| S}|$177\n$mux|{ Y}}" ]; -c54 [ shape=record, label="{{ A| B| S}|$207\n$mux|{ Y}}" ]; -c55 [ shape=record, label="{{ A| B| S}|$237\n$mux|{ Y}}" ]; -c59 [ shape=record, label="{{ CLK| D}|$66\n$dff|{ Q}}" ]; -c60 [ shape=record, label="{{ CLK| D}|$68\n$dff|{ Q}}" ]; -c61 [ shape=record, label="{{ CLK| D}|$70\n$dff|{ Q}}" ]; -c62 [ shape=record, label="{{ CLK| D}|$72\n$dff|{ Q}}" ]; -c63 [ shape=record, label="{{ CLK| D}|$59\n$dff|{ Q}}" ]; -c64 [ shape=record, label="{{ CLK| D}|$63\n$dff|{ Q}}" ]; -c65 [ shape=record, label="{{ CLK| D}|$64\n$dff|{ Q}}" ]; -c66 [ shape=record, label="{{ A}|$39\n$reduce_bool|{ Y}}" ]; -v11 [ label="4'0000" ]; -c67 [ shape=record, label="{{ A| B| S}|$40\n$mux|{ Y}}" ]; -x12 [ shape=record, style=rounded, label=" 3:2 - 1:0 | 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="{{ A| B}|$38\n$xor|{ Y}}" ]; -x13 [ shape=record, style=rounded, label=" 1:0 - 3:2 | 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="{{ A| B| S}|$110\n$mux|{ Y}}" ]; -v1 [ label="$0\\s2[1:0] [0]" ]; -c14 [ shape=record, label="{{ A| B| S}|$113\n$mux|{ Y}}" ]; -v2 [ label="$0\\s2[1:0] [0]" ]; -c15 [ shape=record, label="{{ A| B| S}|$116\n$mux|{ Y}}" ]; -v3 [ label="clk" ]; -c19 [ shape=record, label="{{ CLK| D}|$64\n$dff|{ 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="{{ A}|$2\n$neg|{ Y}}" ]; -x0 [ shape=record, style=rounded, label=" 1:0 - 3:2 | 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=" 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="{{ A}|$1\n$not|{ Y}}" ]; -x2 [ shape=record, style=rounded, label=" 1:0 - 3:2 | 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=" 3:2 - 1:0 | 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=" 0:0 - 1:1 | 1:1 - 0:0 " ]; -x5 [ shape=record, style=rounded, label=" 1:0 - 3:2 | 1:0 - 1:0 " ]; -x6 [ shape=record, style=rounded, label=" 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="{{ CLK| D}|$59\n$dff|{ Q}}" ]; -c18 [ shape=record, label="{{ CLK| D}|$63\n$dff|{ Q}}" ]; -c20 [ shape=record, label="{{ clk| mem[0]| mem[1]| mem[2]| mem[3]| n1}|outstage\noutstage|{ y}}" ]; -c21 [ shape=record, label="{{ clk| d| n1}|scramble\nscramble|{ mem[0]| mem[1]| mem[2]| mem[3]}}" ]; -c23 [ shape=record, label="{{ d| s1| s2}|selstage\nselstage|{ n1| 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="{{ A| B}|$28\n$add|{ Y}}" ]; -c28 [ shape=record, label="{{ A| B}|$31\n$add|{ Y}}" ]; -c29 [ shape=record, label="{{ A| B}|$34\n$add|{ Y}}" ]; -c30 [ shape=record, label="{{ A| B}|$37\n$add|{ Y}}" ]; -v0 [ label="1'1" ]; -c31 [ shape=record, label="{{ A| B}|$145\n$and|{ Y}}" ]; -v1 [ label="1'1" ]; -c32 [ shape=record, label="{{ A| B}|$175\n$and|{ Y}}" ]; -v2 [ label="1'1" ]; -c33 [ shape=record, label="{{ A| B}|$205\n$and|{ Y}}" ]; -v3 [ label="1'1" ]; -c34 [ shape=record, label="{{ A| B}|$235\n$and|{ Y}}" ]; -v4 [ label="2'00" ]; -c35 [ shape=record, label="{{ A| B}|$143\n$eq|{ Y}}" ]; -v5 [ label="2'01" ]; -c36 [ shape=record, label="{{ A| B}|$173\n$eq|{ Y}}" ]; -v6 [ label="2'10" ]; -c37 [ shape=record, label="{{ A| B}|$203\n$eq|{ Y}}" ]; -v7 [ label="2'11" ]; -c38 [ shape=record, label="{{ A| B}|$233\n$eq|{ Y}}" ]; -c40 [ shape=record, label="{{ A| B| S}|$147\n$mux|{ Y}}" ]; -c41 [ shape=record, label="{{ A| B| S}|$177\n$mux|{ Y}}" ]; -c42 [ shape=record, label="{{ A| B| S}|$207\n$mux|{ Y}}" ]; -c43 [ shape=record, label="{{ A| B| S}|$237\n$mux|{ Y}}" ]; -c47 [ shape=record, label="{{ CLK| D}|$66\n$dff|{ Q}}" ]; -c48 [ shape=record, label="{{ CLK| D}|$68\n$dff|{ Q}}" ]; -c49 [ shape=record, label="{{ CLK| D}|$70\n$dff|{ Q}}" ]; -c50 [ shape=record, label="{{ CLK| D}|$72\n$dff|{ 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="{{ A| B| S}|$110\n$mux|{ Y}}" ]; -x0 [ shape=record, style=rounded, label=" 1:1 - 0:0 " ]; -x0:e -> c15:p13:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c16 [ shape=record, label="{{ A| B| S}|$113\n$mux|{ Y}}" ]; -x1 [ shape=record, style=rounded, label=" 0:0 - 0:0 " ]; -x1:e -> c16:p13:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c17 [ shape=record, label="{{ A| B| S}|$116\n$mux|{ Y}}" ]; -x2 [ shape=record, style=rounded, label=" 0:0 - 0:0 " ]; -x2:e -> c17:p13:w [arrowhead=odiamond, arrowtail=odiamond, dir=both, color="black", label=""]; -c21 [ shape=record, label="{{ CLK| D}|$64\n$dff|{ 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="{{ A}|$39\n$reduce_bool|{ Y}}" ]; -v0 [ label="4'0000" ]; -c13 [ shape=record, label="{{ A| B| S}|$40\n$mux|{ Y}}" ]; -x1 [ shape=record, style=rounded, label=" 3:2 - 1:0 | 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="{{ A| B}|$38\n$xor|{ Y}}" ]; -x2 [ shape=record, style=rounded, label=" 1:0 - 3:2 | 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="{{ A| B}|$1\n$add|{ Y}}" ]; -v3 [ label="$1_Y" ]; -v4 [ label="c" ]; -v5 [ label="sum" ]; -c5 [ shape=record, label="{{ A| B}|$2\n$add|{ 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="{{ A| B}|$1\n$add|{ Y}}" ]; -c10 [ shape=record, label="{{ A| B}|$2\n$add|{ 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="{{ A| B}|$4\n$mul|{ 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="{{ A| B}|$4\n$mul|{ 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="{{ A| B}|$3\n$mul|{ Y}}" ]; -c8 [ shape=record, label="{{ A| B}|$4\n$mul|{ 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 -#include -#include - -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 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 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 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 -#include -#include -#include - -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 - # include -+# include - - /* - * 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 -+# include - - /* - * 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 . - -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 . */ - - -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 - * - * 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} " >&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}{} - ::= | - - ::= "\textbackslash" $+$ - - ::= "\textdollar" $+$ -\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}{} - ::= $+$ \texttt{\textbf{'}} $*$ - - ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" - - ::= "0" | "1" | "x" | "z" | "m" | "-" - - ::= "-"$?$ $+$ -\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}{} - ::= $?$ * -\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" -\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" - - ::= -( - \alt - \alt - \alt - \alt - \alt )$*$ - - ::= "parameter" $?$ - - ::= | | - - ::= "end" -\end{indentgrammar} - -\subsection{Attribute statements} - -Declares an attribute with the given identifier and value. - -\begin{indentgrammar}{} - ::= "attribute" -\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}{} - ::= - - \alt - \alt "[" (":" )$?$ "]" - \alt "\{" $*$ "\}" -\end{indentgrammar} - -\subsection{Connections} - -Declares a connection between the given signals. - -\begin{indentgrammar}{} - ::= "connect" -\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" $*$ - - ::= - - ::= -"width" - \alt "offset" - \alt "input" - \alt "output" - \alt "inout" - \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" $*$ - - ::= -"width" - \alt "size" - \alt "offset" -\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" - - ::= - - ::= - - ::= -"parameter" ("signed" | "real")$?$ - \alt "connect" - - ::= "end" -\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}{} - ::= $*$ - - ::= "process" - - ::= $*$ $?$ $*$ $*$ - - ::= "assign" - - ::= - - ::= - - ::= "end" - -\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" - - ::= $*$ - - ::= "case" $?$ - - ::= ("," )$*$ - - ::= ( | )$*$ - - ::= "end" -\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}{} - ::= $*$ - - ::= -"sync" - \alt "sync" "global" - \alt "sync" "init" - \alt "sync" "always" - - ::= "low" | "high" | "posedge" | "negedge" | "edge" - - ::= "update" -\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 [].} (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\tt -\textbackslash\it } 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$:4$2 - connect \A \in1 - connect \Y $logic_not$:4$2_Y -end -cell $xor $xor$:13$3 - connect \A $1\out1[0:0] - connect \B \out2 - connect \Y $xor$:13$3_Y -end -process $proc$:1$1 - assign $0\out3[0:0] \out3 - assign $0\out2[0:0] $1\out1[0:0] - assign $0\out1[0:0] $xor$:13$3_Y - switch \in2 - case 1'1 - assign $1\out1[0:0] $logic_not$: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 }) to the current -temporary signal for the same thing (initially {\tt \$0\textbackslash \it }). -% -\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 - use the specified command instead of "/yosys-abc" to execute ABC. - This can e.g. be used to call a specific version of ABC or a wrapper. - - -script - use the specified ABC script file instead of the default script. - - if 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 - generate netlists for the specified cell library (using the liberty - file format). - - -genlib - generate netlists for the specified cell library (using the SIS Genlib - file format). - - -constr - pass this file with timing constraints to ABC. - use with -liberty/-genlib. - - a constr file contains two lines: - set_driving_cell - set_load - - 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 - 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 - maximum number of SOP inputs. - (replaces {I} in the default scripts above) - - -P - maximum number of SOP products. - (replaces {P} in the default scripts above) - - -S - maximum number of LUT inputs shared. - (replaces {S} in the default scripts above, default: -S 1) - - -lut - generate netlist using luts of (max) the specified width. - - -lut : - generate netlist using luts of (max) the specified width . All - luts with width <= have constant cost. for luts larger than - the area cost doubles with each additional input bit. the delay cost - is still constant for all lut widths. - - -luts ,,,:,.. - 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 [!][,[!]] - 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 : - 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 - use the specified command instead of "/yosys-abc" to execute ABC. - This can e.g. be used to call a specific version of ABC or a wrapper. - - -script - use the specified ABC script file instead of the default script. - - if 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 - 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 - generate netlist using luts of (max) the specified width. - - -lut : - generate netlist using luts of (max) the specified width . All - luts with width <= have constant cost. for luts larger than - the area cost doubles with each additional input bit. the delay cost - is still constant for all lut widths. - - -lut - pass this file with lut library to ABC. - - -luts ,,,:,.. - generate netlist using luts. Use the specified costs for luts with 1, - 2, 3, .. inputs. - - -maxlut - 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 - 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 _$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 (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 /input.lut (skip if '-lut' or '-luts') - abc9_ops -write_box /input.box (skip if '-box') - write_xaiger -map /input.sym [-dff] /input.xaig - abc9_exe [options] -cwd -lut [/input.lut] -box [/input.box] - read_aiger -xaiger -wideports -module_name $abc9 -map /input.sym /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 - use the specified command instead of "/yosys-abc" to execute ABC. - This can e.g. be used to call a specific version of ABC or a wrapper. - - -script - use the specified ABC script file instead of the default script. - - if 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 - 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 - generate netlist using luts of (max) the specified width. - - -lut : - generate netlist using luts of (max) the specified width . All - luts with width <= have constant cost. for luts larger than - the area cost doubles with each additional input bit. the delay cost - is still constant for all lut widths. - - -lut - pass this file with lut library to ABC. - - -luts ,,,:,.. - 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 - pass this file with box library to ABC. - - -cwd - 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 = *) 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 - pre-compute the lut library by analysing all modules marked with - (* abc9_lut= *). - - -write_lut - write the pre-computed lut library to . - - -prep_box - pre-compute the box library by analysing all modules marked with - (* abc9_box *). - - -write_box - write the pre-computed box library to . - - -reintegrate - for each selected module, re-intergrate the module '$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 [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} [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 [selection] - -Like 'add -input', but also connect the signal between instances of the -selected modules. - - - add {-assert|-assume|-live|-fair|-cover} [-if ] - -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 - -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 - Match attribute names case-insensitively and set it to the specified - name. - - -rename - Rename attributes as specified - - -map = = - Map key/value pairs as indicated. - - -imap = = - Like -map, but use case-insensitive match for when - it is a string value. - - -remove = - 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 - 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 | -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 | -command "" - use this script file or command to crash Yosys. required. - - -yosys - use this Yosys binary. if not specified, `yosys` is used. - - -grep "" - 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 "" - child process wrapping command, e.g., "timeout 30", or valgrind. -\end{lstlisting} - -\section{cd -- a shortcut for 'select -module '} -\label{cmd:cd} -\begin{lstlisting}[numbers=left,frame=single] - cd - -This is just a shortcut for 'select -module '. - - - cd - -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 '. - - - 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 - delay activation of the constraint by clock cycles - - -skip - ignore activation of the constraint in the first 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 - set the cell type to the given type - - -map - change cells types that match to -\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 : - 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 : - 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 - -Create a connection. This is equivalent to adding the statement 'assign - = ;' to the Verilog input. Per default, all existing -drivers for are unconnected. This can be overwritten by using -the -nounset option. - - - connect [-nomap] -unset - -Unconnect all existing drivers for the specified expression. - - - connect [-nomap] [-assert] -port - -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 [args...] - connect_rpc -path - -Load modules using an out-of-process frontend. - - -exec [args...] - run with arguments [args...]. send requests on stdin, read - responses from stdout. - - -path - connect to Unix domain socket at . (Unix) - connect to bidirectional byte-type named pipe at . (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": ["", ...]} - <- {"error": ""} - 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 is instantiated in the design. - - -> {"method": "derive", "module": ", "parameters": { - "": {"type": "[unsigned|signed|string|real]", - "value": ""}, ...}} - <- {"frontend": "[rtlil|verilog|...]","source": ""}} - <- {"error": ""} - request for the module to be derived for a specific set of - parameters. starts with \ for named parameters, and with $ - for unnamed parameters, which are numbered starting at 1. - for integer parameters is always specified as a binary string of - unlimited precision. the returned by the frontend is - hygienically parsedby a built-in Yosys , 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 - -unsigned - consider the specified signed/unsigned wrapper output - - -port - 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 - -Save the current design under the given name. - - - design -stash - -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 - -Reset the current design and load the design previously saved under the given -name. - - - design -copy-from [-as ] - -Copy modules from the specified design into the current one. The selection is -evaluated in the other design. - - - design -copy-to [-as ] [selection] - -Copy modules from the current design into the specified one. - - - design -import [-as ] [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 - -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 - 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 - 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 - specifies a supported group of FF cells. - is a yosys internal fine cell name, where ? characters can be - as a wildcard matching any character. 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 - 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 - 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 [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 - write to the specified file. - - -a - 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 - 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 cycles (the -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 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 - Do not match cells or signals that match the names in the file. - - -encfile - 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 : - 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 - expand the modules in this file before proving equivalence. this is - useful for handling architecture-specific primitives. - - -blacklist - 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 ... - - prove: - clk2fflogic (only with -multiclock) - async2sync (only with -async2sync) - equiv_make -blacklist ... 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 - 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 - 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 - 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 - set the specified signal to the specified value. - - -set-undef - set all unspecified source signals to undef (x) - - -table - create a truth table using the specified input signals - - -show - 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 - 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 - Generate an error if the specified regex does not match any line - in subprocess's stdout. May be specified multiple times. - - -not-expect-stdout - 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 - 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 [options] [selection] - extract -mine [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 - use the modules in this file as reference. This option can be used - multiple times. - - -map % - 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 - 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 ,[,...] - Register a set of swappable ports for a needle cell type. - This option can be used multiple times. - - -perm ,[,...] ,[,...] - Register a valid permutation of swappable ports for a needle - cell type. This option can be used multiple times. - - -cell_attr - Attributes on cells with the given name must match. - - -wire_attr - Attributes on wires with the given name must match. - - -ignore_parameters - Do not use parameters when matching cells. - - -ignore_param - 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 - mine for frequent subcircuits and write them to the given RTLIL file - - -mine_cells_span - only mine for subcircuits with the specified number of cells - default value: 3 5 - - -mine_min_freq - only mine for subcircuits with at least the specified number of matches - default value: 10 - - -mine_limit_matches_per_module - when calculating the number of matches for a subcircuit, don't count - more than the specified number of matches per module - - -mine_max_fanout - don't consider internal signals with more than 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 - Set maximum depth for extracted logic cones (default=20) - - -b - 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 : - 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 [,,...] - 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] - -This pass creates init constraints (for example for reset sequences) in a formal -model. - - -seq - 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 - Add constant value constraint - - -posedge - -negedge - 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 - stop after reduction operations. this is mostly used for - debugging the freduce command itself. - - -dump - dump the design to __.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 - specify the encoding scheme used for FSMs without the - 'fsm_encoding' attribute or with the attribute set to `auto'. - - -fm_set_fsm_file - generate a file containing the mapping from old to new FSM encoding - in form of Synopsys Formality set_fsm_* commands. - - -encfile - write the mappings from old to new FSM encoding to a file in the - following format: - - .fsm - .map -\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 - generated testbench name. - files .v and .txt are created as result. - - -r - read simulation FST file - - -clock - name of top-level clock input - - -clockn - name of top-level clock input (inverse polarity) - - -scope - scope of simulation top model - - -start