Thanks for raising this issue. There are several reasons why LowRISC
lags behind the latest Rocket release. The primary target for Rocket as
far as I am aware is a Zync board, where the Rocket works in conjunction
with an ARM host. This does not suit our primary paradigm which is code
execution security, since the ARM part of the IP cannot be modified.
Hence our focus on untethering the Rocket core from the host interface
and running standalone MIG memory interface and exclusively bare-metal
The update to the latest Rocket has been under investigation for some
time and so far we have held back from releasing a LowRISC based on the
latest Rocket because the framework of TileLink2 lacks an L2 cache,
which we feel is an important aspect of the whole from a performance,
realism, and teaching point of view. We fully understand why SiFive are
reluctant to release this part of the code until they have working
silicon of their U500 core.
The released Chisel requires considerable to integrate our security
extensions and for this reason we cannot stabilize our releases without
branching the main Rocket repository. It seems unlikely that our changes
could be incorporated upstream giving the rapid rate of refactoring of
the upstream code.
On the Ethernet side of things that you mentioned I have better news, we
have a working solution for the Nexys4_DDR in-house, based on the
ethernet-v0.5 branch of our code. This uses the userland from the
poky-linux project, including dropbear ssh server. As with all our
projects, none of our work in progress is held back from our
collaborators and users. However, although it is operational, we still
need to document and review this code before it can be released with the
blessing of LowRISC CIC.
If you examine the way Rocket code is released you do not see stable,
update and release branches. This makes it difficult to tell when a new
feature has stabilized. Furthermore since hardware design is not
compositional, it would be difficult to make viable ports based on
continuous integration of upstream repositories. There will always be
conflicts such as I/O pins, busses, memory maps, conflicting timing
constraints, and area constraints needing to be manually reconciled.
On 13/11/17 11:35, Ahmed Khalaf wrote:
I agree it's isn't easy (nor needed at this point) to
port/switch/migrate AXI related interconnects to a different
The approach you mentioned is "agile" and make sense for lowRISC
project, other issues are by far more important. like Ethernet
What I'm suggesting here is having a DRY structure by using baseline
from rocket-chip repo (which already includes hardfloat and
I just remembered rocket-chip have a recommended template project that
uses similar structure.
Ideally, the aim of reuse is to maximize focus (and effort) in a
project going into features (differentiating factors) by re-using
Rocket and PULPino and the corresponding tool-chain and Linux
infrastructure since both are FPGA+ASIC proven already.
However, this needs to be enabled via a continuous integration strategy.
From my point of view, the main drawbacks for the current structure I
think at the moment are:
1- Lacking a clear baseline against rocket-chip, prevents me (as
potential community) from understanding the differences and being able
to efficiently navigate problems/design modifications:
Because files are copied into lowRISC and modified, I need to figure
out from which change-set does the rocket-chip files come then
checkout the corresponding baseline/branch ..etc and diff the files.
2- Hindering the ability to update frequently, the more manual taking
over updates from rocket core + linux stuff the more effort it requires
Less frequent updates will make it more difficult to catch up with
updates "exponentially" over time.
3- Reduced maintainability: ideally, all modifications/patches to
rocket-chip shall be submitted back to rocket-chip project to allow
configuration and/or contributing a fix/design change. otherwise,
lowRISC will have to re-apply these changes with every update (or not
I'm mainly interested in lowRISC as FPGA based multi-core
Linux-capable SMP SoC with interrupt I/O off-loading capabilities (via
Currently, this is not working as far as I understood through
experimenting and from the issues on github:
#51 when will lowRISC support SMP well [opened on Jun 8]
So, even if I wanted to contribute a fix to this issue for example ..
I will have to spend significant time on irrelevant logistics just to
know where we stand.
If needed, please let me know if you agree to refactoring, I might be
able to contribute to this effort.
On Sat, Nov 11, 2017 at 6:34 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk
We several implementations of AXI, the premier one for Xilinx
being the MIG dynamic memory interface generator.
As long as we need that, there is no harm in using a variety of
AXI components from the Xilinx subsystem.
There is also the SOCIP subsystem which offers simplified
functionality but limited configurability.
Then there is the chisel version of AMBA in the rocket tree
itself, however as a chisel neophyte I am not clear
if we extract standalone AXI interfaces components from this.
Finally there is the AXI infrastructure that is
delivered as part of the Pulpino (Minion) infrastructure. This
seems to me to have a lot of usage limitations also.
If and when we get sufficient stability and momentum to make a
real chip, we would have to see what components
should be used in the ASIC.
On 11/11/17 15:54, Ahmed Khalaf wrote:
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
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
history in a different structure (in addition to using a
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
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
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 <mailto:firstname.lastname@example.org>> wrote:
On 11 November 2017 at 14:58, Ahmed Khalaf
<me(a)ahmedkhalaf.com <mailto:email@example.com>> wrote:
I have noticed lowRISC git repo doesn't rely on
has forked some
sub-modules from github.com/ucb-bar/
git repos (like
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
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
I believe this will make lowRISC difficult to
maintain, and missing new
features (like AMOs). most importantly, it will make
differences between rocket-chip project and lowRISC
Can you please elaborate on the strategy lowRISC will
Hi Ahmed, thanks for the questions. We build on top of the
Rocket codebase and aim to minimise differences where
Unfortunately, large-scale refactoring of the rocket-chip
made it quite difficult to stay in-sync. Wei has been
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
bus, with the aim of minimising the amount of Chisel you
need to know
to get started. Integrating upstream changes is an ongoing
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