Difference between revisions of "Logic optimization across hierarchy boundaries"
| Line 1: | Line 1: | ||
| − | '''Q: Does Verific support design optimizations such as constant propagation and dead-code elimination across | + | '''Q: Does Verific support design optimizations such as constant propagation and dead-code elimination across hierarchy boundaries?''' |
The optimization done during elaboration flow in Verific does not cross hierarchy boundary. This is because Verific netlist database is folded (same netlist may represent more than one instances, although there are compile/runtime flags to force uniquify all instances, those flags normally stay off). | The optimization done during elaboration flow in Verific does not cross hierarchy boundary. This is because Verific netlist database is folded (same netlist may represent more than one instances, although there are compile/runtime flags to force uniquify all instances, those flags normally stay off). | ||
Latest revision as of 15:19, 22 July 2019
Q: Does Verific support design optimizations such as constant propagation and dead-code elimination across hierarchy boundaries?
The optimization done during elaboration flow in Verific does not cross hierarchy boundary. This is because Verific netlist database is folded (same netlist may represent more than one instances, although there are compile/runtime flags to force uniquify all instances, those flags normally stay off).
However, basic routines being available (to work inside hierarchy), it is not too difficult to extend the work across hierarchy (and uniquify the netlist for the respective instances). In fact, Verific already provides an application example to show how this can be done using Verific netlist database:
Please check the example (in Verific distribution) examples/verilog/propagate_constant_thru_hierarchy. The same can be extended to the dead-code elimination as well.
Word level netlist severely limits the scope of most optimization. For the efficiency of the algorithm, when runtime flag "db_infer_wide_operators" is turned on, even the very first netlist created during elaboration is mostly at word level. There are however some more transformations at the netlist level to increase word level operators (e.g. for latches). This is done under runtime flag "db_infer_wide_operators_post_elaboration". This is a pure netlist level transformation and can be deferred to a later stage (post optimization across hierarchy).
