It is tempting to keep it all together in one tree, but the tools are
getting so humongous they
probably deserve separate treatment. The real nifty trick would be to
have just one install for the
compiler and to choose the version of rocket
on the command line when compiling, but perhaps this is impossible.
On 14/11/17 20:04, Christopher Celio wrote:
> Having rocket has a submodule was ideal for us, and as you point
out
> copying code in to the src/ subdirectory has serious disadvantages and
> is really a stop-gap measure.
My assumption here is any code that I have to duplicate I'm going to modify
significantly enough anyways that it "becomes my code" regardless. So long as
the interfaces remain relatively unchanged, I think I can manage. Maybe I'll regret
that.
My naive recommendation is basically your Option #2:
lowrisc-template (aka, lowrisc-chip):
- lowrisc-tools (your fork/replacement for riscv-tools)
- rocket-chip (god willing, just a copy of master; otherwise your fork)
- lowrisc
- src/main/scala/stuff (your new tagged memories, etc.)
- src/main/scala/system/ (ExampleLowriscSystem, ExampleTestharness, etc.)
- scripts/
- build-tools.sh (so the correct tools gets built)
In a perfect world, lowRISC things like "TaggedDCache" would be a subclass that
inherits from, let's say, rocket's HellaCacheModule. Not all of the necessary
pieces of rocket-chip facilitate replacing one subclass for another, but I think this
would be a useful discussion to have with upstream: "What blocks can we abstract out
to a common interface and provide a mechanism to drop in a different
cache/router/etc."? There is already a buildCore mechanism to drop in another core
that respects CoreIO.
I think part of the challenge here is the lack of enough public existence proofs of
downstream users of rocket-chip, so it's less obvious how and where it is profitable
to make rocket-chip more "plug and play". The ROCC co-processor interface is one
success story.
Wish this was easier...
-Chris
> On Nov 14, 2017, at 10:58 AM, Alex Bradbury <asb(a)asbradbury.org> wrote:
>
> That's a good question. We've discussed "boxing up" different parts
of
> the SoC to better allow that sort of use case, allowing cores and
> other IP blocks to be more easily swapped out for other
> implementations (whether they be in Chisel, SystemVerilog, VHDL, or
> whatever). However that's an ambition rather than what we have today.
> The work Wei has done with diplomacy makes it easier to instantiate
> SystemVerilog IP, but we could probably move further in that
> direction.
>
> Having rocket has a submodule was ideal for us, and as you point out
> copying code in to the src/ subdirectory has serious disadvantages and
> is really a stop-gap measure. It seems to me that that upstream
> rocket-chip moving rocket out of a submodule makes things easier for
> upstream rocket-chip, but perhaps a little less convenient for
> downstream integrators like ourselves who would much rather consume
> module as an isolated submodule.
>
> Options seem to be:
> 1. Have upstream rocket-chip as a submodule. Not really viable for us,
> as we need patches for e.g. tagged memory support, and may want
> different riscv-tools version and so on.
> 2. Fork rocket-chip and have that as a submodule. I'd probably drop
> the riscv-tools submodule in the fork and instead have our preferred
> riscv-tools version in the top-level lowrisc-chip repo.
> 3. Have a forked rocket-chip repo as the top-level lowrisc-chip. Not
> clear there are significant advantages vs the previous options.
>
> 2) feels like the best option to me, and seems roughly in line with
> the boom-template setup shared by Chris (thanks for the pointers
> Chris!).
>
> Best,
>
> Alex
>
> On 14 November 2017 at 12:22, Ahmed Khalaf <me(a)ahmedkhalaf.com> wrote:
>> Chris, that's really an interesting move.
>> I am working (playing around is more like it) with boom nowadays and I was
>> wandering which approach is better. I think you the process you describe
>> makes sense.
>>
>> More projects reusing from rocket will help the "configurability" and
>> "mainlining", of course at the expense of some growing pain as you
>> mentioned.
>>
>> The question I have in mind is, what if someone (that's me, but I don't
>> wanna personalize the argument) wants to re-use from both Boom and lowRISC ?
>>
>> I guess there is no straightforward answer at the moment .. would be great
>> to see this as a long term direction.
>>
>> Best Regards,
>> Ahmed Khalaf
>>
>> On Tue, Nov 14, 2017 at 1:47 AM, Christopher Celio
<celio(a)eecs.berkeley.edu>
>> wrote:
>>
>>>> Getting git workflow right isn't easy indeed, UCB Boom project opted
for
>>> a
>>>> slightly obvious strategy which is forking rocket-chip into a branch of
>>>> their own in which they include their git repo as a sub-module.
>>>>
https://github.com/ucb-bar/riscv-boom
>>>
>>> For BOOM, I'm experimenting with a new code/repo organization which is
>>> based off of Berkeley's "project-template":
>>>
>>>
https://github.com/ccelio/boom-template
>>>
>>> An other example system that follow this organization is the SiFive
>>> Freedom platform (
https://github.com/sifive/freedom).
>>>
>>> The idea is that boom-template provides an "Example BOOM chip" with
an
>>> example TestHarness and example BoomCoreplex.
>>>
>>> The BOOM source code is a submodule of this boom-template. More
>>> interesting, the master branch of rocket-chip is also a submodule of
>>> boom-template, which is now treated as a library of components. Anything
>>> that needs to be modified for BOOM's is pulled into the BOOM repo. Going
>>> forward, BOOM will no longer be a fork within rocket-chip. That was too
>>> painful to manage.
>>>
>>> There is still going to be some growing pains (hopefully this new setup
>>> will be less painful than the hard fork), and I am still learning how best
>>> to interface my stuff to upstream rocket-chip and the broader OSHW
>>> community.
>>>
>>> I also realize that my changes/differences relative to rocket do not
>>> compare to the wider, sweeping changes of lowRISC's efforts. =(
>>>
>>>
>>> -Chris
>>>