A typical use of `bugpoint` would involve a script with a pass under
test, e.g.:
flowmap -relax -optarea 100
and would be invoked as:
bugpoint -yosys ./yosys -script flowmap.ys -clean -cells
This replaces the current design with the minimal design that still
crashes the `flowmap.ys` script.
`bugpoint` can also be used to perform generic design minimization
using `select`, e.g. the following script:
select i:* %x t:$_MUX_ %i -assert-max 0
would remove all parts of the design except for an unbroken path from
an input to an output port that goes through exactly one $_MUX_ cell.
(The condition is inverted.)
The initial list of hits was generated with the codespell command
below, and each hit was evaluated and fixed manually while taking
context into consideration.
DIRS="kernel/ frontends/ backends/ passes/ techlibs/"
DIRS="${DIRS} libs/ezsat/ libs/subcircuit"
codespell $DIRS -S *.o -L upto,iff,thru,synopsys,uint
More hits were found by looking through comments and strings manually.
o Not all derived methods were marked 'override', but it is a great
feature of C++11 that we should make use of.
o While at it: touched header files got a -*- c++ -*- for emacs to
provide support for that language.
o use YS_OVERRIDE for all override keywords (though we should probably
use the plain keyword going forward now that C++11 is established)
The PR prints the name of the module when displaying the final area count.
Pros:
- Easier for the user to `grep` for area information about a specific module
Cons:
- Arguably more verbose, less "pretty" than author desires
Verification:
~~~~
30c30
< Chip area for this module: 20616.349000
---
> Chip area for module '$paramod$d1738fc0bb353d517bc2caf8fef2abb20bced034\picorv32': 20616.349000
70c70
< Chip area for this module: 88.697700
---
> Chip area for module '\picorv32_axi_adapter': 88.697700
102c102
< Chip area for this module: 20705.046700
---
> Chip area for top module '\picorv32_axi': 20705.046700
~~~~