Scratchpad Config

[abejgonzalez]

Fixes #381.

Adds a configuration that removes off-chip memory interface in favor of a configurable scratchpad hanging off the mbus. This builds Verilog but I haven't tested any code with this.

Based on #347 so this must go in after that. (Ill change the base branch when the other PR is done).

[jerryz123]

Can we make this stuff belong in testchipip instead? 1) it reduces code bloat in Chipyard core. 2) a backing scratchpad feels like a "testchip" feature.

[abejgonzalez]

Can we make this stuff belong in testchipip instead? 1) it reduces code bloat in Chipyard core. 2) a backing scratchpad feels like a "testchip" feature.

None of this code is "new" per-se... it is just using Rocket Chip. IMO testchipip is a collection of testing IP. This doesn't really fit under that umbrella.

[jerryz123]

Even if all the components are Rocket Chip, it adds a new Field and a new Trait. The guidelines for Keys/Traits in #347 specified that keys and traits should be defined in submodules, since they deal with custom modifications that not all people will use.

The only exception to this rule is for the example widgets.

[jwright6323]

Looks fine- how did you test it?

@jerryz123 I think this should go here. I think you might be able to make an argument that the stuff in TopCakes could go into testchipip, but it's so small I think it's overkill. The rest obviously has to go in chipyard.

[abejgonzalez]

While I agree that TopCakes.scala is a bit small for now (and seems excessive), I think there should be a place for pure RC changes (that require little to no "extra" code). As John said, this can live in testchipip but I think it is better to have it in example.

As for the testing, I just finished running the asm/bmark tests and they passed.

[jwright6323]

LGTM