mirror of https://github.com/YosysHQ/yosys.git
Markdownify README even further
This commit is contained in:
Aleks-Daniel Jakimenko-Aleksejev
parent
e01382739d
commit
751ad3c618
120
README.md
120
README.md
|
|
@ -47,7 +47,7 @@ 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.
|
||||
Xdot (graphviz) is used by the ``show`` command in yosys to display schematics.
|
||||
For example on Ubuntu Linux 16.04 LTS the following commands will install all
|
||||
prerequisites for building yosys:
|
||||
|
||||
|
|
@ -87,8 +87,8 @@ 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:
|
||||
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
|
||||
|
||||
|
|
@ -104,16 +104,16 @@ elaborate design hierarchy:
|
|||
|
||||
yosys> hierarchy
|
||||
|
||||
convert processes ("always" blocks) to netlist elements and perform
|
||||
convert processes (``always`` blocks) to netlist elements and perform
|
||||
some simple optimizations:
|
||||
|
||||
yosys> proc; opt
|
||||
|
||||
display design netlist using xdot:
|
||||
display design netlist using ``xdot``:
|
||||
|
||||
yosys> show
|
||||
|
||||
the same thing using 'gv' as postscript viewer:
|
||||
the same thing using ``gv`` as postscript viewer:
|
||||
|
||||
yosys> show -format ps -viewer gv
|
||||
|
||||
|
|
@ -165,7 +165,7 @@ The following very basic synthesis script should work well with all designs:
|
|||
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
|
||||
in the liberty file ``mycells.lib``, the following synthesis script will synthesize
|
||||
for the given cell library:
|
||||
|
||||
# the high-level stuff
|
||||
|
|
@ -184,7 +184,7 @@ for the given cell library:
|
|||
clean
|
||||
|
||||
If you do not have a liberty file but want to test this synthesis script,
|
||||
you can use the file examples/cmos/cmos_cells.lib from the yosys sources.
|
||||
you can use the file ``examples/cmos/cmos_cells.lib`` from the yosys sources.
|
||||
|
||||
Liberty file downloads for and information about free and open ASIC standard
|
||||
cell libraries can be found here:
|
||||
|
|
@ -192,8 +192,8 @@ cell libraries can be found here:
|
|||
- http://www.vlsitechnology.org/html/libraries.html
|
||||
- http://www.vlsitechnology.org/synopsys/vsclib013.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 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
|
||||
|
|
@ -218,11 +218,11 @@ for them:
|
|||
- Non-synthesizable 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 ``tri``, ``triand``, ``trior``, ``wand`` and ``wor`` net types
|
||||
|
||||
- The "config" keyword and library map files
|
||||
- The ``config`` keyword and library map files
|
||||
|
||||
- The "disable", "primitive" and "specify" statements
|
||||
- The ``disable``, ``primitive`` and ``specify`` statements
|
||||
|
||||
- Latched logic (is synthesized as logic with feedback loops)
|
||||
|
||||
|
|
@ -230,70 +230,70 @@ for them:
|
|||
Verilog Attributes and non-standard features
|
||||
============================================
|
||||
|
||||
- The 'full_case' attribute on case statements is supported
|
||||
(also the non-standard "// synopsys full_case" directive)
|
||||
- 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 ``parallel_case`` attribute on case statements is supported
|
||||
(also the non-standard ``// synopsys parallel_case`` directive)
|
||||
|
||||
- The "// synopsys translate_off" and "// synopsys translate_on"
|
||||
- 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
|
||||
- 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
|
||||
- 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
|
||||
- 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
|
||||
- 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
|
||||
- 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
|
||||
- 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
|
||||
- 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
|
||||
- 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
|
||||
Setting the ``keep`` attribute on a module has the same effect as setting it
|
||||
on all instances of the module.
|
||||
|
||||
- The "keep_hierarchy" attribute on cells and modules keeps the "flatten"
|
||||
- The ``keep_hierarchy`` attribute on cells and modules keeps the ``flatten``
|
||||
command from flattening the indicated cells and modules.
|
||||
|
||||
- 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
|
||||
- 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
|
||||
- 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.
|
||||
|
||||
- The "src" attribute is set on cells and wires created by to the string
|
||||
"<hdl-file-name>:<line-number>" by the HDL front-end and is then carried
|
||||
- The ``src`` attribute is set on cells and wires created by to the string
|
||||
``<hdl-file-name>:<line-number>`` by the HDL front-end and is then carried
|
||||
through the synthesis. When entities are combined, a new |-separated
|
||||
string is created that contains all the string from the original entities.
|
||||
|
||||
|
|
@ -306,7 +306,7 @@ Verilog Attributes and non-standard features
|
|||
lists, a trailing comma is ignored. This simplifies writing verilog code
|
||||
generators a bit in some cases.
|
||||
|
||||
- Modules can be declared with "module mod_name(...);" (with three dots
|
||||
- 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.
|
||||
|
|
@ -320,7 +320,7 @@ Verilog Attributes and non-standard features
|
|||
assign b = 42;
|
||||
"""
|
||||
|
||||
- The attribute "via_celltype" can be used to implement a Verilog task or
|
||||
- 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.
|
||||
|
|
@ -348,9 +348,9 @@ Verilog Attributes and non-standard features
|
|||
endmodule
|
||||
|
||||
- A limited subset of DPI-C functions is supported. The plugin mechanism
|
||||
(see "help plugin") can be used to load .so files with implementations
|
||||
(see ``help plugin``) can be used to 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:
|
||||
a plugin alias using the ``<alias>:`` syntax. For example:
|
||||
|
||||
module dpitest;
|
||||
import "DPI-C" function foo:round = real my_round (real);
|
||||
|
|
@ -359,11 +359,11 @@ Verilog Attributes and non-standard features
|
|||
|
||||
$ yosys -p 'plugin -a foo -i /lib/libm.so; read_verilog dpitest.v'
|
||||
|
||||
- Sized constants (the syntax <size>'s?[bodh]<value>) support constant
|
||||
- Sized constants (the syntax ``<size>'s?[bodh]<value>``) support constant
|
||||
expressions as <size>. If the expression is not a simple identifier, it
|
||||
must be put in parentheses. Examples: WIDTH'd42, (4+2)'b101010
|
||||
must be put in parentheses. Examples: ``WIDTH'd42``, ``(4+2)'b101010``
|
||||
|
||||
- The system tasks $finish and $display are supported in initial blocks
|
||||
- The system tasks ``$finish`` and ``$display`` are supported in initial blocks
|
||||
in an unconditional context (only if/case statements on parameters
|
||||
and constant values). The intended use for this is synthesis-time DRC.
|
||||
|
||||
|
|
@ -371,42 +371,42 @@ Verilog Attributes and non-standard features
|
|||
Non-standard or SystemVerilog features for formal verification
|
||||
==============================================================
|
||||
|
||||
- Support for "assert", "assume", and "restrict" is enabled when
|
||||
read_verilog is called with -formal.
|
||||
- Support for ``assert``, ``assume``, and ``restrict`` is enabled when
|
||||
``read_verilog`` is called with ``-formal``.
|
||||
|
||||
- The system task $initstate evaluates to 1 in the initial state and
|
||||
- The system task ``$initstate`` evaluates to 1 in the initial state and
|
||||
to 0 otherwise.
|
||||
|
||||
- The system task $anyconst evaluates to any constant value.
|
||||
- The system task ``$anyconst`` evaluates to any constant value.
|
||||
|
||||
- The system task $anyseq evaluates to any value, possibly a different
|
||||
- The system task ``$anyseq`` evaluates to any value, possibly a different
|
||||
value in each cycle.
|
||||
|
||||
- The SystemVerilog tasks $past, $stable, $rose and $fell are supported
|
||||
- The SystemVerilog tasks ``$past``, ``$stable``, ``$rose`` and ``$fell`` are supported
|
||||
in any clocked block.
|
||||
|
||||
- The syntax @($global_clock) can be used to create FFs that have no
|
||||
- The syntax ``@($global_clock)`` can be used to create FFs that have no
|
||||
explicit clock input ($ff cells).
|
||||
|
||||
|
||||
Supported features from SystemVerilog
|
||||
=====================================
|
||||
|
||||
When read_verilog is called with -sv, it accepts some language features
|
||||
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 ``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 "assume" and "restrict" statements from SystemVerilog are also
|
||||
supported. The same limitations as with the "assert" statement apply.
|
||||
- The ``assume`` and ``restrict`` statements from SystemVerilog are also
|
||||
supported. The same limitations as with the ``assert`` statement apply.
|
||||
|
||||
- The keywords "always_comb", "always_ff" and "always_latch", "logic" and
|
||||
"bit" are supported.
|
||||
- The keywords ``always_comb``, ``always_ff`` and ``always_latch``, ``logic`` and
|
||||
``bit`` are supported.
|
||||
|
||||
- SystemVerilog packages are supported. Once a SystemVerilog file is read
|
||||
into a design with "read_verilog", all its packages are available to
|
||||
into a design with ``read_verilog``, all its packages are available to
|
||||
SystemVerilog files being read into the same design afterwards.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue