portarcs: New command to derive propagation arcs

[povik]

What are the reasons/motivation for this change?

To preserve boundaries of arithmetic operators we need to synthesize them separately and box them for synthesis of the surrounding logic. We need to characterize the propagation delay of this box so the technology mapper is aware of it, this characterization step is where this new command comes in.

Help sample:

    portarcs [options] [selection]

This command characterizes the combinational content of selected modules and
derives timing arcs going from module inputs to module outputs representing the
propagation delay of the module.

    -draw
        plot the computed delay table to the terminal

    -icells
        assign unit delay to gates from the internal Yosys cell library

    -write
        write the computed arcs back into the module as $specify2 instances

[povik]

Sample plot of a mapped $alu (columns inputs, rows outputs):

[Ravenslofty]

To review #4737 I should probably look at what this does.

My first question is: where's the timing data coming from? The timinginfo.h stuff deals with Verilog specify rules, and this is intended for use in ASIC flows, right? Does this assume the gates have already been STA'd and turned into specify rules for Yosys to parse?

(or is the idea to just use -icells and punt that problem down the road?)

[povik]

Does this assume the gates have already been STA'd and turned into specify rules for Yosys to parse?

It does assume having specify rules for the gates, currently the main way to get those is with read_liberty -unit_delay; later we can have read_liberty -gain_model X to match ABC's read_lib -G X

The philosophy here is that $specify2 arcs on gate definitions are enough to match the timing model used by ABC internally

[Ravenslofty]

This is maybe a little big to Just Merge It, but I don't think there's much to discuss/dispute, so whatever.