[rebar] add sifive blocks | add rebar configs for boom

[abejgonzalez]

Added sifive-blocks without actually using it. Added BOOM rebar configurations.

Question to the pro Chisel devs in the group. Is there any way for the BuildTop parameter to be general so that both BoomTop and RocketTop work? Similar to a upper bound type for a class parameter? I was unable to figure this out, but I figured this was sufficient for now since it matches firechip

[alonamid]

Why does boomexample need to be a separate package than example?
Do you have an example of a config that has both a boom core and a rocket core?
Might also be worth changing the names of current ExampleTop to RocketExampleTop (to keep in symmetrical with BoomExampleTop).

[colinschmidt]

You should add an example that has some sifive-block peripheral maybe GPIOs?
I'm ok with that being a separate PR if you think it would be cleaner.

[colinschmidt]

I also agree with Alon about creating extra packages.

[abejgonzalez]

@alonamid @colinschmidt

1. Separate packages: The separate packages were just following what firechip did. I will go ahead and combine it into a single package (although names will get a bit longer so there are no naming conflicts)

2. Boom + Rocket: No, I don't have a config for that yet. I was going to not put a heterogeneous multicore config in this PR.

3. ExampleTop naming: Sounds like a plan

4. SiFive Peripheral: I think that would be a separate PR. Which one do we want?

[abejgonzalez]

Actually, are you all in favor of getting rid of the example in all the class names and just having a comment header saying "THESE ARE EXAMPLE CONFIGS". Otherwise, adding example everywhere is kinda redundant.

[colinschmidt]

Can you make sure you can run an assembly test on both boom and rocket before merging this?
Otherwise things make sense.

[abejgonzalez]

Okay, I think this PR is ready to be merged in.

I addressed @colinschmidt concerns about building rocket. See the SUB_PROJECT=rocketchip to see the proper configs to set.

Additionally, made sure that asm tests ran correctly on rebar boom, rebar rocket, rocketchip, and boom.

[davidbiancolin]

This looks good.

Spitballing here, but I'm wondering if we can just mandate that all designs extend a trait "tieOffIOInTestHarness", that has a method (implicit p) => Unit that just barfs out all of the requisite hardware for RTL simulation, BuildTop can just return a Module that extends that trait and this can be invoked in the testHarness.