Thank you for the prompt explanation, I checked out the "update" branch and
it seems to me following the upstream codebase from rocket-chip is getting
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.
I'm not sure whether this would work for lowRISC because there is already
history in a different structure (in addition to using a SystemVerilog
One option would be to include rocket-chip as a submodule, which will make
updates a bit easier and more visible to "outsiders".
Regarding AXI, I think there is already an AMBA (AXI4/AHB-lite/APB) package
within Rocket-chip project as it's being migrated to use AXI too.
I have no idea whether this would be considered an option for lowRISC, as
it seems Chisel might not be "the" preferred option here.
On Sat, Nov 11, 2017 at 5:20 PM, Alex Bradbury <asb(a)lowrisc.org> wrote:
On 11 November 2017 at 14:58, Ahmed Khalaf <me(a)ahmedkhalaf.com>
> I have noticed lowRISC git repo doesn't rely on rocket-chip
and has forked some
> sub-modules from github.com/ucb-bar/
git repos (like hardfloat), this
> However, for rocket core, it seems UCB removed the sub-module repo from
> rocket-chip parent repo in July and also the rocket git repo itself is no
> longer accessible
> As far as I understand, lowRISC will continue on its own generator, but I
> think Rocket core has become different from the one used in rocket-chip
> master branch:
> I believe this will make lowRISC difficult to maintain, and missing new
> features (like AMOs). most importantly, it will make understanding
> differences between rocket-chip project and lowRISC difficult.
> Can you please elaborate on the strategy lowRISC will re-use components
> from rocket-chip?
Hi Ahmed, thanks for the questions. We build on top of the upstream
Rocket codebase and aim to minimise differences where feasible.
Unfortunately, large-scale refactoring of the rocket-chip codebase has
made it quite difficult to stay in-sync. Wei has been incorporating
code from a more recent Rocket for the next lowRISC release, and you
can see this work in the 'update' branch of lowrisc-chip
In general, we prefer to provide a SystemVerilog top-level, and to
make it as easy as possible to hook up SystemVerilog IP to the AXI
bus, with the aim of minimising the amount of Chisel you need to know
to get started. Integrating upstream changes is an ongoing challenge
and I don't think we've arrived at a final solution yet. In
particular, we do want to spend more time thinking about easy
configuration of the lowRISC SoC, including both the Rocket and minion