Add barstools

[jwright6323]

Waiting on ucb-bar/barstools#35.

This adds barstools to project-template and changes the make targets to generate separate top and harness files, as well as generates external memories from SeqMems. By default these memories are implemented as synthesizeable flops, but this makes plugging in a VLSI flow easier.

[zhemao]

I'm not so sure about putting tapeout-specific generation in the regular makefiles. Shouldn't these be going into tapeout-specific directories instead? So instead of modifying Makefrag and vsim/Makefile, the custom stuff should go in a tapeout/Makefile instead.

[edwardcwang]

Another thought to this: since project-template is a widely used repo with many dependencies (e.g. in firesim) and barstools/Hammer is not as stable, perhaps it would make sense to use a branch of barstools once ucb-bar/barstools#35 is merged? This could enable us to be more agile on some of the passes in there.

Alternatively a hammer-passes repo may also work for faster iteration if branches on barstools is undesirable for various reasons.

If project-template was fast/easy to test, we could just PR a corresponding fix to project-template, but that's not the case since it's slow/difficult to test project-template. I think a danger in just using a revision is that it makes it hard to pull in a fix without pulling in all new changes (continuous integration).

Having said that if the interface is via CLI/JAR it may not be so bad.

[jwright6323]

@zhemao The motivation of this PR is to put the bare minimum set of stuff in the Makefrag that makes everything work. "TAPEOUT" is a bit of a misnomer, that's just what the barstools project is called- all the TAPEOUT pass does is split the DUT from the test harness, which is generally useful to all types of projects. The MacroCompiler step replaces the SeqMems with external modules so that they can be replaced with SRAMs, but retains the "default" functionality of synthesizeable-register-based seq mems by generating that file as well. For VLSI flows we'd just omit that and use our own. FPGA flows could either map to FPGA resources in a similar manner or use the generated file. I suppose tapeout/Makefile would work, but it sounds like we'd be doubling the maintenance effort. We'll see what the firesim folks say; we did discuss this beforehand.

@edwardcwang What else did you want to add to barstools, specifically? I agree that we should keep the ASIC-flow stuff as separate and easy-to-iterate-on as possible, so a hammer-passes (branch of barstools) may be the right way to go there.

[edwardcwang]

e.g. passes that extract e.g. clock inverter annotations and then generate Hammer IR. You can imagine passes like this for the hammer APIs we have. Maybe those should go in hammer-passes as you mention.

[colinschmidt]

Given that there is no change in behavior for vsim is there still an issue @zhemao?
I think new features should always be on branches so if @edwardcwang is going to write new barstools passes they can live on a branch until they are robust enough. Although I will note that most barstools passes are not as robust as they should be since they are often nearly single-user.
I will be vary happy to have this kind of infrastructure more public and used.

[colinschmidt]

LGTM. Lets see if @sagark @davidbiancolin have any thoughts

[jwright6323]

Cool, this is ready to go now that ucb-bar/barstools#35 is done. Will wait for signoff from everyone here, though.

[zhemao]

We don't use these makefiles for firesim, so that won't be an issue. I'm fine with merging this.

[zhemao]

Can you fix the Makefile in verisim as well?

[edwardcwang]

In general stuff living on branches tends to have continuous integration issues and discoverability issues so maybe they would go into hammer-passes just so they have a proper place to live. Maybe they can link against barstools as needed.

[colinschmidt]

Yeah I agree with @zhemao that all makefiles should use this.

@edwardcwang I think the question is whether the passes you write should eventually live in barstools or not? If they won't ever live there then you can have your own repo and integration probably lives in your downstream *-template repo. If they eventually will be integrated into barstools its best to keep them on a branch. Its easier to have fewer repos in general.

[sagark]

We don't use any of this in firesim directly, so I have no problem with what's here.

[jwright6323]

@zhemao Fixed verisim/Makefile