mirror of
https://github.com/YosysHQ/yosys
synced 2025-06-06 14:13:23 +00:00
Merge pull request #5153 from garytwong/typo-fix
This commit is contained in:
commit
d96d1e3630
4 changed files with 7 additions and 7 deletions
|
@ -72,7 +72,7 @@ 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 .
|
||||
synthesis there are also a number of FOSS tools for high level synthesis.
|
||||
|
||||
Behavioural level
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
@ -185,7 +185,7 @@ 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 .
|
||||
Good FOSS tools exists for multi-level logic synthesis.
|
||||
|
||||
Yosys contains basic logic synthesis functionality but can also use ABC for the
|
||||
logic synthesis step. Using ABC is recommended.
|
||||
|
@ -221,7 +221,7 @@ 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
|
||||
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.
|
||||
|
||||
|
@ -572,7 +572,7 @@ of lexical tokens given in :numref:`Tab. %s <tab:Basics_tokens>`.
|
|||
TOK_SEMICOLON \-
|
||||
============== ===============
|
||||
|
||||
The lexer is usually generated by a lexer generator (e.g. flex ) from a
|
||||
The lexer is usually generated by a lexer generator (e.g. flex) from a
|
||||
description file that is using regular expressions to specify the text pattern
|
||||
that should match the individual tokens.
|
||||
|
||||
|
|
|
@ -73,7 +73,7 @@ contain bits that are not 0 or 1 (i.e. ``x`` or ``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.
|
||||
load. Signals that are multiple bits wide are shown as thick arrows.
|
||||
|
||||
Finally *processes* are shown in boxes with round corners. Processes are Yosys'
|
||||
internal representation of the decision-trees and synchronization events
|
||||
|
|
|
@ -176,5 +176,5 @@ implemented as whiteboxes too.
|
|||
Boxes are arguably the biggest advantage that ABC9 has over ABC: by being aware
|
||||
of carry chains and DSPs, it avoids optimising for a path that isn't the actual
|
||||
critical path, while the generally-longer paths result in ABC9 being able to
|
||||
reduce design area by mapping other logic to larger-but-slower cells.
|
||||
reduce design area by mapping other logic to smaller-but-slower cells.
|
||||
|
||||
|
|
|
@ -626,7 +626,7 @@ pass and the passes it launches:
|
|||
| This pass replaces the ``RTLIL::SyncRule``\ s to d-type flip-flops (with
|
||||
asynchronous resets if necessary).
|
||||
|
||||
- | `proc_dff`
|
||||
- | `proc_memwr`
|
||||
| This pass replaces the ``RTLIL::MemWriteAction``\ s with `$memwr` cells.
|
||||
|
||||
- | `proc_clean`
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue