[topgen] topgen flow

[tjaychen]

Currently, topgen's flow goes something like the following

1. gather all non-top hjson configurations (ips, including top generated ips and xbar)
2. validate all hjsons, including consistency checks between top and xbar/ips
3. if validation passes, merge all hjsons into top_earlgrey.gen.hjson
4. generate other downstream collateral such as top related ips

This generally works, however issues pop-up for top generated ip's. Specifically..

1. The first time top generated ips are included (rvplic, alert_handler) there is no hjson to be validated and merged in steps 2/3 above
2. If a particular hjson is generated based on gathering results of other ip.hjson (alert_handler, clks/pwr/rst may all fall into this category), it creates a dependency where either the hjsons are not there (problem above), or the hjsons included may be outdated.

There are many ways to solve this, but one thought that was quickly discussed with @eunchan is to allow for a generate step between 1/2. There are some blocks (for example clk) who don't actually need ip information to perform generation (it only needs top information).

For other blocks that do have dependencies, it might make sense to some kind of dependency graph and handle those later or in a second / third pass of topgen. For example, assuming the dependency is as follows:

ips -> pwrmgr -> alert_handler -> rvplic

This potentially could be 4 passes of topgen (or we hardcode the order of when things are run) and then the final topgen merge is done.

There are definitely many other ideas, so this issue mostly is just trying to frame the problem so it is not forgotten.

[eunchan]

Thanks. As we get more generated IPs, I keep thinking that splitting out the generated part into separate modules in topgen makes sense.

For instance, clkmgr generation (validation also) codes is in util/topgen/clock_manager.py and it has common function such as validate(), elaborate(), generate() etc. These functions are same across all the topgen plug-able libraries such as interrupt, alert, intermodule, etc.

Topgen, then, should have a code that calls the functions at certain stages in the main code. As you mentioned, it may calls prior to load ip objects, after loaded ip objects, etc..

[tjaychen]

yeah i tend to agree with this. I feel like if we have separate clk_manager.py, then that same code could also be used for the examples in the individual hw/ip/clkmgr directory. That way everything stays consistent.

On Wed, Apr 29, 2020 at 5:52 PM Eunchan Kim notifications@github.com wrote:

Thanks. As we get more generated IPs, I keep thinking that splitting out the generated part into separate modules in topgen makes sense.

For instance, clkmgr generation (validation also) codes is in util/topgen/clock_manager.py and it has common function such as validate(), elaborate(), generate() etc. These functions are same across all the topgen plug-able libraries such as interrupt, alert, intermodule, etc.

Topgen, then, should have a code that calls the functions at certain stages in the main code. As you mentioned, it may calls prior to load ip objects, after loaded ip objects, etc..

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/opentitan/issues/2083#issuecomment-621548204, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2RSUSFY4L6CGJMDS3W6DRPDDWBANCNFSM4MTJLM5A .