Support workflow for early exploration of designs with alpha-release flow

[oharboe]

I believe it would be useful to be able to run designs through the alpha-release flow while setting an enumerated list of modules to black boxes to get statistics on the design as early feedback to the design process.

To set modules to black boxes is useful in the case where the current implementation is not yet ready or is impossible to realize in the alpha-release flow automatically: multipliers, RAM, too complex modules, etc.

I naively expect black boxes to be moduled as zero size, infinitely fast modules when there's no other information. This is course unrealistic, but as long as the interesting areas of the design to study are not involved in these parts of the design(for instance that the fMax problems are elsewhere), then zero size, infinitely fast black boxes is a perfectly good way to model parts of the design. Another advantage of of setting modules to such black boxes is to simply to speed up turnaround times for builds.

I'd be happy to provide a pull-request that demonstrates this workflow and demonstrates the failure belwo, but first it would be good to hear that there's agreement that this is a useful use-case for alpha-release.

To reproduce

When I try to modify synth.tcl to do a less agressive optimization and set certain modules to black boxes, the workflow fails in the floorplan with the error message below.

Modification to synth.tcl:

+blackbox ThingAMaBobUnit
+
 # generic synthesis
-synth -top $::env(DESIGN_NAME) -flatten
+synth -noshare -noalumacc -top $::env(DESIGN_NAME) 

Error message:

# make DESIGN_CONFIG=`pwd`/designs/harness.mk DESIGN_NAME=MyTopLevelModule
[deleted]
Mon Nov  4 08:17:24 UTC 2019
        ____      _____ _     ___   ___  ____  ____  _        _    _   _ 
       |___ \    |  ___| |   / _ \ / _ \|  _ \|  _ \| |      / \  | \ | |
         __) |   | |_  | |  | | | | | | | |_) | |_) | |     / _ \ |  \| |
        / __/ _  |  _| | |__| |_| | |_| |  _ <|  __/| |___ / ___ \| |\  |
       |_____(_) |_|   |_____\___/ \___/|_| \_\_|   |_____/_/   \_\_| \_|
                                                                         
verilog2def \
[deleted]
Tcl_SetObjLength: negative length requested: -2147483644 (integer overflow?)

[tajayi]

Hi @oharboe,
Can you please elaborate on the exact "statistics" or "early feedback" or "interesting areas of the design to study" you are looking to get?

Yosys natively supports blackboxes in a variety of ways (using blackbox command, using RTL pragmas/comments, etc). From here you can get a lot of information based on synthesis results (e.g max fanout, etc).

Unfortunately, mostly place and route till will require physical information about the blackbox (height, width, pin locations, blockages, etc). This is usually in the form of an abstracted lef and a timing model (*.lib). Most place and route tools (even commercial tools) will fail at initialization time if the proper physical information is missing.

[oharboe]

@tajayi

Interesting statistics:

• Yosys statistics, which I'm getting using this approach
• The RePlaCe animation is surprisingly helpful in tell me how easy it is to lay out the design, but I would like to have something quantifiable to tell me where the placement and routing pain-points are in our design. Final area numbers, congestion numbers, etc.
• Backannotated timing(timing after P&R)

In our design, we believe that we've mapped out which modules are going to be the tricky ones to get to perfom as required. However, I want to know that the rest of the design doesn't contain any nasty surprises.

If OpenROAD can easily do a full place and route and give me backannotated timing for the rest of the design that I have not marked as black box, then we have a pretty good indications that our efforts are not misdirected.

[oharboe]

@tajayi Really I'm interested in any and all data and reports generated by alpha-release flow, because I'm starting with zero quantifiable information about the design, so anything at all is an enormous improvement.

[tajayi]

Unfortunately, a lot of the tools beyond synthesis will need the physical/timing information to proceed. I would recommend 2 approaches:

1. Explore the "resizer" tool which is able to read the verilog right after yosys. It can generate reports and a lot of useful information. In the current flow, we use it to quickly handle nets with large fanouts, however it can do a whole lot more and it doesn't need to know about the physical layout
   https://github.com/The-OpenROAD-Project/alpha-release/blob/master/flow/Makefile#L136

2. Generate fake abstracts for the blocks in question. This may be a little harder and it conflicts with perhaps some desire to explore the design at a low cost. I am in the final phases of testing and integrating https://github.com/bespoke-silicon-group/bsg_fakeram that can allow the generation of these "fake" abstracts to help go through the flow.
   A similar approach to "other black boxes" may be to just have a generator that arbitrarily fakes collateral for blackboxes

[oharboe]

@tajayi I see. Maybe it would make sense to have a "explore" target that invokes those steps that can be performed?