search

ucb-bar / hammer

Hammer: Highly Agile Masks Made Effortlessly from RTL
BSD 3-Clause "New" or "Revised" License
241 stars 55 forks source link

Stage/Phase based flow manager #532

Open sequencer opened 4 years ago

sequencer commented 4 years ago

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.

harrisonliew commented 4 years ago

This could also be a solution to #430.

colinschmidt commented 4 years ago

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.

sequencer commented 4 years ago

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.

colinschmidt commented 4 years ago

Can you explain the other use cases, that are not solved by technology plugins being able to add their own hooks?

sequencer commented 4 years ago

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.

colinschmidt commented 4 years ago

Your link is broken. I think I'm still confused without the image.

sequencer commented 4 years ago

Your link is broken.

Sorry, fixed now.

jwright6323 commented 4 years ago

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.

seldridge commented 4 years ago

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.