hammer
hammer copied to clipboard
ucb-bar
Stage/Phase based flow manager
In #511, we are struggling to deliver a flow to shrink gds, which is an unexpected flow in physical design flow, but physical design always has such flows for special design or special process, and we leak of a method to inject to specific step in the hammer flow(we use hook to do such things).
Maybe Hammer can absorb some idea from freechipsproject/firrtl#1005:
storing data in Annotation
using Phase to consume some Annotation and generate another Annotation for next Phase.
I think we want to be careful about reinventing too much, or solving general problems when we only have specific versions of those problems. If this is just about technologies wanting to be able to inject hooks. This is a problem we've identified long ago see #311 If there is some other requirement please elaborate.
Yes, if we really want implement this, it will entirely reinvent the base system, which is hard to accept currently, but we can take it as a feature todo which might solve problems like this.
Can you explain the other use cases, that are not solved by technology plugins being able to add their own hooks?
Basically, current flow is quite straightforward, that RTL -> Synthesis -> PaR -> DRC/LVS -> SIM -> tapeout if we consider a more real-world demo: Each step should relay on another step's information and need to feed back to Timing/Power analysis, DRC/LVS. And it separates HFNS and CTS, which introduces more complexity.
I don't really see how the firrtl proposal applies here. We already have plans on supporting timing/power analysis within the existing infrastructure. It would be nice to reduce the amount of boilerplate code for adding tools and perhaps add an explicit dependency graph, but I think those are both separate issues.
Stage/Phase and it's Dependency API help solve the triple aims/problems of (1) reworking Chisel/FIRRTL/Testers/Treadle/etc. within a functional programming framework where a sequence of transformations over a type are applied to some input, (2) determining a linear ordering of transformations based on a dependency API that includes prerequisites and invalidations, and (3) allowing users to inject transformations with dependencies into this process.
If you find yourself needing to resolve dependencies with invalidations (foo needs bar, but it also invalidates bar, and you'd like to run both) or if there's some motivation to convert everything to one big foldLeft then it may be worth taking a look at, drawing inspiration from, or stealing the dependency resolution algorithm from.
Basically, if the hooks approach starts to break down or you want to solve a very, very general problem Stage/Phase may be worth looking into.
