> 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

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&gt; 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 >

> 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&gt; 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&gt; 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&gt; >> 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 >>>