2013-11-22 10:33:59 -06:00
|
|
|
|
2013-11-23 10:33:26 -06:00
|
|
|
% 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}
|
2013-11-23 13:04:51 -06:00
|
|
|
\author{Clifford Wolf \\ November 2013}
|
2013-11-23 10:33:26 -06:00
|
|
|
\maketitle
|
|
|
|
|
|
|
|
\begin{abstract}
|
2013-11-22 10:33:59 -06:00
|
|
|
Verilog-2005 is a powerful Hardware Description Language (HDL) that can be used
|
2013-11-23 13:04:51 -06:00
|
|
|
to easily create complex designs from small HDL code. It is the preferred
|
2013-11-22 10:33:59 -06:00
|
|
|
method of design entry for many designers\footnote{The other half prefers VHDL,
|
2013-11-23 13:04:51 -06:00
|
|
|
a very different but -- of course -- equally powerful language.}.
|
2013-11-22 10:33:59 -06:00
|
|
|
|
2015-03-22 03:49:46 -05:00
|
|
|
The Berkeley Logic Interchange Format (BLIF) \cite{blif} is a simple file format for
|
2013-11-22 10:33:59 -06:00
|
|
|
exchanging sequential logic between programs. It is easy to generate and
|
2013-11-23 13:04:51 -06:00
|
|
|
easy to parse and is therefore the preferred method of design entry for
|
2013-11-22 10:33:59 -06:00
|
|
|
many authors of logic synthesis tools.
|
|
|
|
|
2013-11-23 10:33:26 -06:00
|
|
|
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}
|
2013-11-22 10:33:59 -06:00
|
|
|
|
|
|
|
\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
|
2013-11-23 13:04:51 -06:00
|
|
|
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}.
|
2013-11-22 10:33:59 -06:00
|
|
|
|
|
|
|
\bigskip
|
|
|
|
|
2013-11-23 13:04:51 -06:00
|
|
|
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.
|
2013-11-22 10:33:59 -06:00
|
|
|
|
|
|
|
\section{Getting Started}
|
|
|
|
|
2013-11-23 13:04:51 -06:00
|
|
|
We start our tour with the Navré processor from yosys-bigsim. The Navré
|
|
|
|
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.
|
2013-11-22 10:33:59 -06:00
|
|
|
|
|
|
|
Converting {\tt softusb\_navre.v} to {\tt softusb\_navre.blif} could not be
|
|
|
|
easier:
|
|
|
|
|
2013-11-22 22:46:51 -06:00
|
|
|
\begin{figure}[H]
|
2013-11-23 10:33:26 -06:00
|
|
|
\begin{lstlisting}[language=sh]
|
2013-11-23 13:04:51 -06:00
|
|
|
yosys -o softusb_navre.blif -S softusb_navre.v
|
2013-11-22 10:33:59 -06:00
|
|
|
\end{lstlisting}
|
2013-11-22 22:46:51 -06:00
|
|
|
\renewcommand{\figurename}{Listing}
|
|
|
|
\caption{Calling Yosys without script file}
|
|
|
|
\end{figure}
|
2013-11-22 10:33:59 -06:00
|
|
|
|
|
|
|
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
|
2013-11-23 13:04:51 -06:00
|
|
|
with a semicolon-separated list of commands. But in most cases it is more
|
|
|
|
convenient to use an actual script file.
|
2013-11-22 10:33:59 -06:00
|
|
|
|
|
|
|
\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:
|
|
|
|
|
2013-11-22 22:46:51 -06:00
|
|
|
\begin{figure}[H]
|
2013-11-23 10:33:26 -06:00
|
|
|
\begin{lstlisting}[language=sh]
|
2013-11-22 10:33:59 -06:00
|
|
|
read_verilog softusb_navre.v
|
|
|
|
hierarchy
|
|
|
|
proc; opt; memory; opt; techmap; opt
|
|
|
|
write_blif softusb_navre.blif
|
|
|
|
\end{lstlisting}
|
2013-11-22 22:46:51 -06:00
|
|
|
\renewcommand{\figurename}{Listing}
|
|
|
|
\caption{\tt softusb\_navre.ys}
|
|
|
|
\end{figure}
|
2013-11-22 10:33:59 -06:00
|
|
|
|
|
|
|
The first and last line obviously read the Verilog file and write the BLIF
|
2015-07-02 04:14:30 -05:00
|
|
|
file.
|
2013-11-22 10:33:59 -06:00
|
|
|
|
|
|
|
\medskip
|
|
|
|
|
2015-07-02 04:14:30 -05:00
|
|
|
The 2nd line checks the design hierarchy and instantiates parametrized
|
2013-11-22 10:33:59 -06:00
|
|
|
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
|
2013-11-23 13:04:51 -06:00
|
|
|
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}.
|
2013-11-22 10:33:59 -06:00
|
|
|
\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).
|
2015-07-02 04:14:30 -05:00
|
|
|
\item The command {\tt memory} converts Yosys' internal representations of
|
2013-11-22 10:33:59 -06:00
|
|
|
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}
|
|
|
|
|
2013-11-23 13:04:51 -06:00
|
|
|
Now Yosys can be run with the filename of the synthesis script as argument:
|
2013-11-22 10:33:59 -06:00
|
|
|
|
2013-11-22 22:46:51 -06:00
|
|
|
\begin{figure}[H]
|
2013-11-23 10:33:26 -06:00
|
|
|
\begin{lstlisting}[language=sh]
|
2013-11-22 22:46:51 -06:00
|
|
|
yosys softusb_navre.ys
|
2013-11-22 12:08:29 -06:00
|
|
|
\end{lstlisting}
|
2013-11-22 22:46:51 -06:00
|
|
|
\renewcommand{\figurename}{Listing}
|
|
|
|
\caption{Calling Yosys with script file}
|
|
|
|
\end{figure}
|
2013-11-22 12:08:29 -06:00
|
|
|
|
|
|
|
\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
|
2013-11-23 13:04:51 -06:00
|
|
|
call to the {\tt hierarchy} command:
|
2013-11-22 12:08:29 -06:00
|
|
|
|
|
|
|
Whenever it is known that there are no implicit blackboxes in the design, i.e.
|
2013-11-23 13:04:51 -06:00
|
|
|
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.
|
2013-11-22 12:08:29 -06:00
|
|
|
|
|
|
|
\medskip
|
|
|
|
|
|
|
|
For many designs it is also desired to optimize the encodings for the finite
|
2013-11-23 13:04:51 -06:00
|
|
|
state machines (FSMs) in the design. The {\tt fsm} command finds FSMs, extracts
|
2013-11-22 12:08:29 -06:00
|
|
|
them, performs some basic optimizations and then generate a circuit from
|
|
|
|
the extracted and optimized description. It would also be possible to tell
|
2013-11-23 13:04:51 -06:00
|
|
|
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.
|
2013-11-22 12:08:29 -06:00
|
|
|
|
|
|
|
\medskip
|
|
|
|
|
|
|
|
So now we have the final synthesis script for generating a BLIF file
|
2013-11-23 13:04:51 -06:00
|
|
|
for the Navré CPU:
|
2013-11-22 12:08:29 -06:00
|
|
|
|
2013-11-22 22:46:51 -06:00
|
|
|
\begin{figure}[H]
|
2013-11-23 10:33:26 -06:00
|
|
|
\begin{lstlisting}[language=sh]
|
2013-11-22 10:33:59 -06:00
|
|
|
read_verilog softusb_navre.v
|
|
|
|
hierarchy -check -top softusb_navre
|
2013-11-23 13:04:51 -06:00
|
|
|
proc; opt; memory; opt; fsm; opt; techmap; opt
|
2013-11-22 10:33:59 -06:00
|
|
|
write_blif softusb_navre.blif
|
|
|
|
\end{lstlisting}
|
2013-11-22 22:46:51 -06:00
|
|
|
\renewcommand{\figurename}{Listing}
|
|
|
|
\caption{{\tt softusb\_navre.ys} (improved)}
|
|
|
|
\end{figure}
|
2013-11-22 10:33:59 -06:00
|
|
|
|
|
|
|
\section{Advanced Example: The Amber23 ARMv2a CPU}
|
|
|
|
|
2013-11-23 10:33:26 -06:00
|
|
|
Our 2nd example is the Amber23 \cite{amber}
|
2013-11-22 12:08:29 -06:00
|
|
|
ARMv2a CPU. Once again we base our example on the Verilog code that is included
|
2013-11-23 10:33:26 -06:00
|
|
|
in yosys-bigsim \cite{bigsim}.
|
2013-11-22 12:08:29 -06:00
|
|
|
|
2013-11-22 22:46:51 -06:00
|
|
|
\begin{figure}[b!]
|
2013-11-23 10:33:26 -06:00
|
|
|
\begin{lstlisting}[language=sh]
|
2013-11-22 12:08:29 -06:00
|
|
|
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
|
2013-11-22 22:46:51 -06:00
|
|
|
opt; memory; opt; fsm; opt; techmap
|
2013-11-22 12:08:29 -06:00
|
|
|
write_blif amber23.blif
|
|
|
|
\end{lstlisting}
|
2013-11-22 22:46:51 -06:00
|
|
|
\renewcommand{\figurename}{Listing}
|
|
|
|
\caption{\tt amber23.ys}
|
|
|
|
\label{aber23.ys}
|
|
|
|
\end{figure}
|
|
|
|
|
2013-11-23 13:04:51 -06:00
|
|
|
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
|
2013-11-22 22:46:51 -06:00
|
|
|
implementation. This design can not be expressed in BLIF as it is. Instead we
|
2013-11-23 13:04:51 -06:00
|
|
|
need to use a synthesis script that transforms this form to synchronous resets that
|
2013-11-22 22:46:51 -06:00
|
|
|
can be expressed in BLIF.
|
|
|
|
|
2013-11-23 13:04:51 -06:00
|
|
|
(Note that there is no problem if this coding techniques are used to model
|
2013-11-23 10:33:26 -06:00
|
|
|
ROM, where the register is initialized using this syntax but is never updated
|
|
|
|
otherwise.)
|
|
|
|
|
2013-11-22 22:46:51 -06:00
|
|
|
\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
|
2013-11-23 13:04:51 -06:00
|
|
|
to each module in the design hierarchy and then all module instantiations are
|
2013-11-22 22:46:51 -06:00
|
|
|
altered so that this new signal is connected throughout the whole design
|
|
|
|
hierarchy.
|
|
|
|
|
|
|
|
\begin{figure}[t!]
|
2013-11-23 10:33:26 -06:00
|
|
|
\begin{lstlisting}[language=Verilog]
|
2013-11-22 22:46:51 -06:00
|
|
|
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!]
|
2013-11-23 10:33:26 -06:00
|
|
|
\begin{lstlisting}[language=Verilog]
|
|
|
|
(* techmap_celltype = "$adff" *)
|
|
|
|
module adff2dff (CLK, ARST, D, Q);
|
2013-11-22 22:46:51 -06:00
|
|
|
|
|
|
|
parameter WIDTH = 1;
|
2013-11-23 10:33:26 -06:00
|
|
|
parameter CLK_POLARITY = 1;
|
|
|
|
parameter ARST_POLARITY = 1;
|
2013-11-22 22:46:51 -06:00
|
|
|
parameter ARST_VALUE = 0;
|
|
|
|
|
|
|
|
input CLK, ARST;
|
|
|
|
input [WIDTH-1:0] D;
|
|
|
|
output reg [WIDTH-1:0] Q;
|
|
|
|
|
2013-11-23 10:33:26 -06:00
|
|
|
wire [1023:0] _TECHMAP_DO_ = "proc";
|
|
|
|
|
2013-11-22 22:46:51 -06:00
|
|
|
wire _TECHMAP_FAIL_ =
|
|
|
|
!CLK_POLARITY || !ARST_POLARITY;
|
|
|
|
|
|
|
|
always @(posedge CLK)
|
2013-11-23 10:33:26 -06:00
|
|
|
if (ARST)
|
|
|
|
Q <= ARST_VALUE;
|
|
|
|
else
|
|
|
|
Q <= D;
|
2013-11-22 22:46:51 -06:00
|
|
|
|
|
|
|
endmodule
|
|
|
|
\end{lstlisting}
|
2013-11-23 10:33:26 -06:00
|
|
|
\renewcommand{\figurename}{Listing}
|
2013-11-22 22:46:51 -06:00
|
|
|
\caption{\tt adff2dff.v}
|
|
|
|
\label{adff2dff.v}
|
|
|
|
\end{figure}
|
|
|
|
|
2013-11-23 10:33:26 -06:00
|
|
|
In line 18 the {\tt proc} command is called. But in this script the signal name
|
2013-11-23 13:04:51 -06:00
|
|
|
{\tt globrst} is passed to the command as a global reset signal for resetting
|
|
|
|
the registers to their assigned initial values.
|
2013-11-22 22:46:51 -06:00
|
|
|
|
|
|
|
Finally in line 19 the {\tt techmap} command is used to replace all instances
|
2013-11-23 10:33:26 -06:00
|
|
|
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
|
2013-11-23 13:04:51 -06:00
|
|
|
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
|
2013-11-23 10:33:26 -06:00
|
|
|
\_TECHMAP\_DO\_} wire in line 13 provides a mini synthesis-script to be used to
|
|
|
|
process this cell.
|
|
|
|
|
|
|
|
\begin{figure*}
|
|
|
|
\begin{lstlisting}[language=C]
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <stdbool.h>
|
|
|
|
|
|
|
|
#define BITMAP_SIZE 64
|
|
|
|
#define OUTPORT 0x10000000
|
|
|
|
|
2013-12-05 11:15:14 -06:00
|
|
|
static uint32_t bitmap[BITMAP_SIZE/32];
|
2013-11-23 10:33:26 -06:00
|
|
|
|
|
|
|
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}
|
2013-11-23 13:04:51 -06:00
|
|
|
\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.}
|
2013-11-23 10:33:26 -06:00
|
|
|
\label{sieve}
|
|
|
|
\end{figure*}
|
|
|
|
|
2013-11-23 13:04:51 -06:00
|
|
|
\section{Verification of the Amber23 CPU}
|
2013-11-23 10:33:26 -06:00
|
|
|
|
|
|
|
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
|
2013-11-23 13:04:51 -06:00
|
|
|
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.
|
2013-11-23 10:33:26 -06:00
|
|
|
|
|
|
|
For simulation the BLIF file was converted back to Verilog using ABC
|
|
|
|
\cite{ABC}. So this test includes the successful transformation of the BLIF
|
2013-11-23 13:04:51 -06:00
|
|
|
file into ABC's internal format as well.
|
2013-11-23 10:33:26 -06:00
|
|
|
|
2013-11-23 13:04:51 -06:00
|
|
|
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
|
2013-12-05 11:15:14 -06:00
|
|
|
calculating the first 31 primes the author has ever conducted.
|
2013-11-23 10:33:26 -06:00
|
|
|
|
|
|
|
\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}
|
|
|
|
Clifford Wolf. The Yosys Open SYnthesis Suite. \\
|
|
|
|
\url{http://www.clifford.at/yosys/}
|
|
|
|
|
|
|
|
\bibitem{bigsim}
|
|
|
|
yosys-bigsim, a collection of real-world Verilog designs for regression testing purposes. \\
|
|
|
|
\url{https://github.com/cliffordwolf/yosys-bigsim}
|
|
|
|
|
|
|
|
\bibitem{navre}
|
|
|
|
Sebastien Bourdeauducq. Navré 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/}
|
|
|
|
|
2015-03-22 03:49:46 -05:00
|
|
|
\bibitem{blif}
|
|
|
|
Berkeley Logic Interchange Format (BLIF) \\
|
|
|
|
\url{http://vlsi.colorado.edu/~vis/blif.ps}
|
|
|
|
|
2013-11-23 10:33:26 -06:00
|
|
|
\end{thebibliography}
|
2013-11-22 12:08:29 -06:00
|
|
|
|
2013-11-22 10:33:59 -06:00
|
|
|
|
2013-11-23 10:33:26 -06:00
|
|
|
\end{document}
|