Hijacking barstools for tapeout passes

[shunshou]

@azidar @colinschmidt and I talked about using barstools for writing tapeout-related Firrtl passes.

Here are a list of passes that exist in other locations that should eventually be moved here:

• Reparent circuit
• Replace submodule with blackboxes
• Clock transform -- get list of different clks coming from top level input or blackbox clock sources.

Future stuff:

• IO Pad annotation + black boxing (similar to create_pads.py) -- that's what I'll be working on in the next n days
  • Some dependency on passing annotations through bundles (which currently doesn't work?)
  • Can specify fast/slow analog, etc. to point to foundry/custom pads
• Generalize clk transform to print out tcl-y things like derived_clk and accept clks from modules annotated as clk sources
  • Useful b/c you can make crappy derived clks with shift registers, and based off of how you parameterize the module, if you need a lot of phases, this might be the easiest way to propagate all the clk info on slow clocks you want
• Voltage domain annotation might be useful
  • rocket-chip or w/e can stay pure, but tapeout-specific wrappers can contain the appropriate, useful annotations

[shunshou]

@chick do you need any of the files currently in the repo? Looks like this was all experimentation you did that's now been integrated w/ Chisel?

[chick]

@shunshou You are correct, I do not need anything that is in this repo.

[colinschmidt]

Thanks for creating the issue. I started working on some of this and hope to have it done over the weekend.

[shunshou]

@colinschmidt I started a branch called tapeout with basic scala style / build.sbt + Adam's ResetInverter thing. If you don't already have one, maybe I should just PR and merge?

[colinschmidt]

Let's just merge your branch. I have the scala style directory and build.sbt but the pfpmp contents, so I can just base my changes on yours.

[shunshou]

Ok, I PRed. One thing I briefly asked Adam is -- with the new transform methodology, it's not evident which order the passes/transformed are run (since you're not adding them manually via your custom compiler). He thinks (and can correct me if I'm wrong) that it's just based off of which annotation is seen first. In case passes/transforms might depend on each other, there needs to be a mechanism to state pass priority. (i.e. inferrw must happen before replseqmem). At least among the passes I mentioned in this issue, there's prob no need, but just food for thought.

[colinschmidt]

Yeah thats a good point. The GenerateTop and GenerateHarness need to be ordered to achieve the desired affect. I guess we'll need another firrtl feature request @azidar :)

[colinschmidt]

We will need to track chipsalliance/firrtl#446 for ordering firrtl passes via annotations.