Add support for heterogenous SoCs (BOOM + Hwacha)

[abejgonzalez]

Adds support for heterogeneous configs with both BOOM and Rocket.

• New subsystems, example system, and test harnesses
• Mixin to renumber harts based on the cores in the system

Also fixes the BOOM configs that were currently pushed in the repo to work.

• Forgot to specify Build variable so test harness could generate a system

Depends on the following PR's being merged in first:
#91
riscv-boom/riscv-boom#270

Preferably wait for (nicer prints for boom):
riscv-boom/riscv-boom#269

Todo:

• Bump BOOM when PR fix to allow more than 2 boom cores in configs riscv-boom/riscv-boom#270 is merged
• Rebase on rename output | helper rules to run binaries #91 once done
• Add CI for the configs (if memory allows)
• Remove debug prints in the tile

[abejgonzalez]

Note: Some parts of this have to change with the BOOM + Rocket Chip version bump. So... keep that in mind.

[abejgonzalez]

Preferably merged after riscv-boom/riscv-boom#271 is merged.

[abejgonzalez]

I will work on documentation this weekend so Ill put that in a different PR (since I want the "meaty" PRs to be done for David to continue on his FireSim work without major outstanding PRs)

[alonamid]

BoomAndRocket doesn't really roll off my fingertips... but I guess we're already down too many naming debates right now to contain another one.
Should we have a naming convention for these heterogeneous configs that might make them easier to manage?

[jerryz123]

So now we have boomexample, example, and boomandrocketexample.
Is there any way to roll all these together?

[abejgonzalez]

@alonamid Agreed. However, this is what I went with for now because it makes thing extremely explicit at the cost of long strings. One option... though in the future... is to name the configs based on the name of the repo, i.e. RebarConfig, MarbleConfig, etc...

@jerryz123 The main difference between the two is that the boomexample and boomrocketexample share the BoomAndRocket... infrastructure while the example subproject uses a Rocket only top and harness. One option to reduce the amount of duplication could be to just use the heterogeneous infrastructure. However, we then don't have an example of using just a Rocket based system (we will only have the tile and harness that support both). It also makes the example project depend on boom even though it really has nothing to do with it.

[jerryz123]

Is there a good reason to keep around a Rocket-only system if the BoomAndRocket system has strictly more functionality?

[abejgonzalez]

IMO its wierd to have example which is just used for Rocket based systems only, to use BoomAndRocket based components (esp. when example never uses boom)

[jerryz123]

I guess the point is we could change example to support all possible combinations of Boom/Rocket.

[abejgonzalez]

So the more I think about it... the more I think it is fine if example uses the heter-base subsystem in which case we can combine it. The only thing is that you now have to have the end user specify which CONFIG to use and portray that correctly in the documentation. Thoughts anyone?

[alonamid]

I think if we can have a "catch-all" heter-base subsystem in which you have to change only the CONFIG, and it doesn't have an RTL overhead, then that's better

[colinschmidt]

LGTM assuming you make the small comment updates.

[abejgonzalez]

Yea. About to do that.