mirror of https://github.com/YosysHQ/yosys.git
376 lines
13 KiB
Plaintext
376 lines
13 KiB
Plaintext
|
|
/-----------------------------------------------------------------------------\
|
|
| |
|
|
| yosys -- Yosys Open SYnthesis Suite |
|
|
| |
|
|
| Copyright (C) 2012 - 2015 Clifford Wolf <clifford@clifford.at> |
|
|
| |
|
|
| 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. |
|
|
| |
|
|
\-----------------------------------------------------------------------------/
|
|
|
|
|
|
yosys -- Yosys Open SYnthesis Suite
|
|
===================================
|
|
|
|
This is a framework for RTL synthesis tools. It currently has
|
|
extensive Verilog-2005 support and provides a basic set of
|
|
synthesis algorithms for various application domains.
|
|
|
|
Yosys can be adapted to perform any synthesis job by combining
|
|
the existing passes (algorithms) using synthesis scripts and
|
|
adding additional passes as needed by extending the yosys C++
|
|
code base.
|
|
|
|
Yosys is free software licensed under the ISC license (a GPL
|
|
compatible license that is similar in terms to the MIT license
|
|
or the 2-clause BSD license).
|
|
|
|
|
|
Web Site
|
|
========
|
|
|
|
More information and documentation can be found on the Yosys web site:
|
|
|
|
http://www.clifford.at/yosys/
|
|
|
|
|
|
Getting Started
|
|
===============
|
|
|
|
You need a C++ compiler with C++11 support (up-to-date CLANG or GCC is
|
|
recommended) and some standard tools such as GNU Flex, GNU Bison, and GNU Make.
|
|
TCL, readline and libffi are optional (see ENABLE_* settings in Makefile).
|
|
Xdot (graphviz) is used by the "show" command in yosys to display schematics.
|
|
For example on Ubuntu Linux 14.04 LTS the following commands will install all
|
|
prerequisites for building yosys:
|
|
|
|
$ yosys_deps="build-essential clang bison flex libreadline-dev gawk
|
|
tcl-dev libffi-dev git mercurial graphviz xdot pkg-config"
|
|
$ sudo apt-get install $yosys_deps
|
|
|
|
There are also pre-compiled Yosys binary packages for Ubuntu and Win32 as well
|
|
as a source distribution for Visual Studio. Visit the Yosys download page for
|
|
more information:
|
|
|
|
http://www.clifford.at/yosys/download.html
|
|
|
|
To configure the build system to use a specific compiler, use one of
|
|
|
|
$ make config-clang
|
|
$ make config-gcc
|
|
|
|
For other compilers and build configurations it might be
|
|
necessary to make some changes to the config section of the
|
|
Makefile.
|
|
|
|
$ vi Makefile ..or..
|
|
$ vi Makefile.conf
|
|
|
|
To build Yosys simply type 'make' in this directory.
|
|
|
|
$ make
|
|
$ make test
|
|
$ sudo make install
|
|
|
|
Note that this also downloads, builds and installs ABC (using yosys-abc
|
|
as executeable name).
|
|
|
|
Yosys can be used with the interactive command shell, with
|
|
synthesis scripts or with command line arguments. Let's perform
|
|
a simple synthesis job using the interactive command shell:
|
|
|
|
$ ./yosys
|
|
yosys>
|
|
|
|
the command "help" can be used to print a list of all available
|
|
commands and "help <command>" to print details on the specified command:
|
|
|
|
yosys> help help
|
|
|
|
reading the design using the verilog frontend:
|
|
|
|
yosys> read_verilog tests/simple/fiedler-cooley.v
|
|
|
|
writing the design to the console in yosys's internal format:
|
|
|
|
yosys> write_ilang
|
|
|
|
elaborate design hierarchy:
|
|
|
|
yosys> hierarchy
|
|
|
|
convert processes ("always" blocks) to netlist elements and perform
|
|
some simple optimizations:
|
|
|
|
yosys> proc; opt
|
|
|
|
display design netlist using xdot:
|
|
|
|
yosys> show
|
|
|
|
the same thing using 'gv' as postscript viewer:
|
|
|
|
yosys> show -format ps -viewer gv
|
|
|
|
translating netlist to gate logic and perform some simple optimizations:
|
|
|
|
yosys> techmap; opt
|
|
|
|
write design netlist to a new verilog file:
|
|
|
|
yosys> write_verilog synth.v
|
|
|
|
a similar synthesis can be performed using yosys command line options only:
|
|
|
|
$ ./yosys -o synth.v -p hierarchy -p proc -p opt \
|
|
-p techmap -p opt tests/simple/fiedler-cooley.v
|
|
|
|
or using a simple synthesis script:
|
|
|
|
$ cat synth.ys
|
|
read_verilog tests/simple/fiedler-cooley.v
|
|
hierarchy; proc; opt; techmap; opt
|
|
write_verilog synth.v
|
|
|
|
$ ./yosys synth.ys
|
|
|
|
It is also possible to only have the synthesis commands but not the read/write
|
|
commands in the synthesis script:
|
|
|
|
$ cat synth.ys
|
|
hierarchy; proc; opt; techmap; opt
|
|
|
|
$ ./yosys -o synth.v tests/simple/fiedler-cooley.v synth.ys
|
|
|
|
The following very basic synthesis script should work well with all designs:
|
|
|
|
# check design hierarchy
|
|
hierarchy
|
|
|
|
# translate processes (always blocks)
|
|
proc; opt
|
|
|
|
# detect and optimize FSM encodings
|
|
fsm; opt
|
|
|
|
# implement memories (arrays)
|
|
memory; opt
|
|
|
|
# convert to gate logic
|
|
techmap; opt
|
|
|
|
If ABC is enabled in the Yosys build configuration and a cell library is given
|
|
in the liberty file mycells.lib, the following synthesis script will synthesize
|
|
for the given cell library:
|
|
|
|
# the high-level stuff
|
|
hierarchy; proc; fsm; opt; memory; opt
|
|
|
|
# mapping to internal cell library
|
|
techmap; opt
|
|
|
|
# mapping flip-flops to mycells.lib
|
|
dfflibmap -liberty mycells.lib
|
|
|
|
# mapping logic to mycells.lib
|
|
abc -liberty mycells.lib
|
|
|
|
# cleanup
|
|
clean
|
|
|
|
If you do not have a liberty file but want to test this synthesis script,
|
|
you can use the file techlibs/cmos/cmos_cells.lib from the yosys sources.
|
|
|
|
Various more complex liberty files (for testing) can be found here:
|
|
|
|
http://vlsiarch.ecen.okstate.edu/flows/MOSIS_SCMOS/latest/..
|
|
../cadence/lib/tsmc025/signalstorm/osu025_stdcells.lib
|
|
../cadence/lib/ami035/signalstorm/osu035_stdcells.lib
|
|
../cadence/lib/tsmc018/signalstorm/osu018_stdcells.lib
|
|
../cadence/lib/ami05/signalstorm/osu05_stdcells.lib
|
|
|
|
The command "synth" provides a good default synthesis script (see "help synth").
|
|
If possible a synthesis script should borrow from "synth". For example:
|
|
|
|
# the high-level stuff
|
|
hierarchy
|
|
synth -run coarse
|
|
|
|
# mapping to internal cells
|
|
techmap; opt -fast
|
|
dfflibmap -liberty mycells.lib
|
|
abc -liberty mycells.lib
|
|
clean
|
|
|
|
Yosys is under construction. A more detailed documentation will follow.
|
|
|
|
|
|
Unsupported Verilog-2005 Features
|
|
=================================
|
|
|
|
The following Verilog-2005 features are not supported by
|
|
yosys and there are currently no plans to add support
|
|
for them:
|
|
|
|
- Non-sythesizable language features as defined in
|
|
IEC 62142(E):2005 / IEEE Std. 1364.1(E):2002
|
|
|
|
- The "tri", "triand", "trior", "wand" and "wor" net types
|
|
|
|
- The "config" keyword and library map files
|
|
|
|
- The "disable", "primitive" and "specify" statements
|
|
|
|
- Latched logic (is synthesized as logic with feedback loops)
|
|
|
|
|
|
Verilog Attributes and non-standard features
|
|
============================================
|
|
|
|
- The 'full_case' attribute on case statements is supported
|
|
(also the non-standard "// synopsys full_case" directive)
|
|
|
|
- The 'parallel_case' attribute on case statements is supported
|
|
(also the non-standard "// synopsys parallel_case" directive)
|
|
|
|
- The "// synopsys translate_off" and "// synopsys translate_on"
|
|
directives are also supported (but the use of `ifdef .. `endif
|
|
is strongly recommended instead).
|
|
|
|
- The "nomem2reg" attribute on modules or arrays prohibits the
|
|
automatic early conversion of arrays to separate registers. This
|
|
is potentially dangerous. Usually the front-end has good reasons
|
|
for converting an array to a list of registers. Prohibiting this
|
|
step will likely result in incorrect synthesis results.
|
|
|
|
- The "mem2reg" attribute on modules or arrays forces the early
|
|
conversion of arrays to separate registers.
|
|
|
|
- The "nomeminit" attribute on modules or arrays prohibits the
|
|
creation of initialized memories. This effectively puts "mem2reg"
|
|
on all memories that are written to in an "initial" block and
|
|
are not ROMs.
|
|
|
|
- The "nolatches" attribute on modules or always-blocks
|
|
prohibits the generation of logic-loops for latches. Instead
|
|
all not explicitly assigned values default to x-bits. This does
|
|
not affect clocked storage elements such as flip-flops.
|
|
|
|
- The "nosync" attribute on registers prohibits the generation of a
|
|
storage element. The register itself will always have all bits set
|
|
to 'x' (undefined). The variable may only be used as blocking assigned
|
|
temporary variable within an always block. This is mostly used internally
|
|
by yosys to synthesize verilog functions and access arrays.
|
|
|
|
- The "onehot" attribute on wires mark them as onehot state register. This
|
|
is used for example for memory port sharing and set by the fsm_map pass.
|
|
|
|
- The "blackbox" attribute on modules is used to mark empty stub modules
|
|
that have the same ports as the real thing but do not contain information
|
|
on the internal configuration. This modules are only used by the synthesis
|
|
passes to identify input and output ports of cells. The verilog backend
|
|
also does not output blackbox modules on default.
|
|
|
|
- The "keep" attribute on cells and wires is used to mark objects that should
|
|
never be removed by the optimizer. This is used for example for cells that
|
|
have hidden connections that are not part of the netlist, such as IO pads.
|
|
Setting the "keep" attribute on a module has the same effect as setting it
|
|
on all instances of the module.
|
|
|
|
- The "init" attribute on wires is set by the frontend when a register is
|
|
initialized "FPGA-style" with 'reg foo = val'. It can be used during synthesis
|
|
to add the necessary reset logic.
|
|
|
|
- The "top" attribute on a module marks this module as the top of the
|
|
design hierarchy. The "hierarchy" command sets this attribute when called
|
|
with "-top". Other commands, such as "flatten" and various backends
|
|
use this attribute to determine the top module.
|
|
|
|
- In addition to the (* ... *) attribute syntax, yosys supports
|
|
the non-standard {* ... *} attribute syntax to set default attributes
|
|
for everything that comes after the {* ... *} statement. (Reset
|
|
by adding an empty {* *} statement.)
|
|
|
|
- Modules can be declared with "module mod_name(...);" (with three dots
|
|
instead of a list of module ports). With this syntax it is sufficient
|
|
to simply declare a module port as 'input' or 'output' in the module
|
|
body.
|
|
|
|
- When defining a macro with `define, all text between tripple double quotes
|
|
is interpreted as macro body, even if it contains unescaped newlines. The
|
|
tripple double quotes are removed from the macro body. For example:
|
|
|
|
`define MY_MACRO(a, b) """
|
|
assign a = 23;
|
|
assign b = 42;
|
|
"""
|
|
|
|
- The attribute "via_celltype" can be used to implement a verilog task or
|
|
function by instantiating the specified cell type. The value is the name
|
|
of the cell type to use. For functions the name of the output port can
|
|
be specified by appending it to the cell type separated by a whitespace.
|
|
The body of the task or function is unused in this case and can be used
|
|
to specify a behavioral model of the cell type for simulation. For example:
|
|
|
|
module my_add3(A, B, C, Y);
|
|
parameter WIDTH = 8;
|
|
input [WIDTH-1:0] A, B, C;
|
|
output [WIDTH-1:0] Y;
|
|
...
|
|
endmodule
|
|
|
|
module top;
|
|
...
|
|
(* via_celltype = "my_add3 Y" *)
|
|
(* via_celltype_defparam_WIDTH = 32 *)
|
|
function [31:0] add3;
|
|
input [31:0] A, B, C;
|
|
begin
|
|
add3 = A + B + C;
|
|
end
|
|
endfunction
|
|
...
|
|
endmodule
|
|
|
|
- A limited subset of DPI-C functions is supported. The plugin mechanism
|
|
(see "help plugin") can be used load .so files with implementations of
|
|
DPI-C routines. As a non-standard extension it is possible to specify
|
|
a plugin alias using the "<alias>:" syntax. for example:
|
|
|
|
module dpitest;
|
|
import "DPI-C" function foo:round = real my_round (real);
|
|
parameter real r = my_round(12.345);
|
|
endmodule
|
|
|
|
$ yosys -p 'plugin -a foo -i /lib/libm.so; read_verilog dpitest.v'
|
|
|
|
- Sized constants (the syntax <size>'s?[bodh]<value>) support constant
|
|
expressions as <size>. If the expresion is not a simple identifier, it
|
|
must be put in parentheses. Examples: WIDTH'd42, (4+2)'b101010
|
|
|
|
|
|
Supported features from SystemVerilog
|
|
=====================================
|
|
|
|
When read_verilog is called with -sv, it accepts some language features
|
|
from SystemVerilog:
|
|
|
|
- The "assert" statement from SystemVerilog is supported in its most basic
|
|
form. In module context: "assert property (<expression>);" and within an
|
|
always block: "assert(<expression>);". It is transformed to a $assert cell.
|
|
|
|
- The keywords "always_comb", "always_ff" and "always_latch", "logic" and
|
|
"bit" are supported.
|
|
|