diff options
Diffstat (limited to 'manual/CHAPTER_StateOfTheArt.tex')
| -rw-r--r-- | manual/CHAPTER_StateOfTheArt.tex | 289 |
1 files changed, 0 insertions, 289 deletions
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} - |