riscv
/
yosys
mirror of https://github.com/YosysHQ/yosys.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #1470 from YosysHQ/clifford/subpassdoc 

Add CodingReadme section on script passes
This commit is contained in:
Clifford Wolf 2019-11-10 11:00:38 +01:00 committed by GitHub
parent 65f197e28f c3ad375200
commit 1d148491c5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 46 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
CodingReadme
View File

@ -202,6 +202,52 @@ of how to use the Yosys API:
manual/PRESENTATION_Prog/my_cmd.cc
Script Passes
-------------
The ScriptPass base class can be used to implement passes that just call other passes,
like a script. Examples for such passes are:
techlibs/common/prep.cc
techlibs/common/synth.cc
In some cases it is easier to implement such a pass as regular pass, for example when
ScriptPass doesn't provide the type of flow control desired. (But many of the
script passes in Yosys that don't use ScriptPass simply predate the ScriptPass base
class.) Examples for such passes are:
passes/opt/opt.cc
passes/proc/proc.cc
Whether they use the ScriptPass base-class or not, a pass should always either
call other passes without doing any non-trivial work itself, or should implement
a non-trivial algorithm but not call any other passes. The reason for this is that
this helps containing complexity in individual passes and simplifies debugging the
entire system.
Exceptions to this rule should be rare and limited to cases where calling other
passes is optional and only happens when requested by the user (such as for
example `techmap -autoproc`), or where it is about commands that are "top-level
commands" in their own right, not components to be used in regular synthesis
flows (such as the `bugpoint` command).
A pass that would "naturally" call other passes and also do some work itself
should be re-written in one of two ways:
1) It could be re-written as script pass with the parts that are not calls
to other passes factored out into individual new passes. Usually in those
cases the new sub passes share the same prefix as the top-level script pass.
2) It could be re-written so that it already expects the design in a certain
state, expecting the calling script to set up this state before calling the
pass in questions.
Many back-ends are examples for the 2nd approach. For example, `write_aiger`
does not convert the design into AIG representation, but expects the design
to be already in this form, and prints an `Unsupported cell type` error
message otherwise.
Notes on the existing codebase
------------------------------