I agree it's isn't easy (nor needed at this point) to port/switch/migrate
AXI related interconnects to a different implementation.
The approach you mentioned is "agile" and make sense for lowRISC project,
other issues are by far more important. like Ethernet interfacing.
What I'm suggesting here is having a DRY structure by using baseline from
rocket-chip repo (which already includes hardfloat and riscv-tools ..etc).
I just remembered rocket-chip have a recommended template project that uses
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
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 .. manually).
I'm mainly interested in lowRISC as FPGA based multi-core Linux-capable SMP
SoC with interrupt I/O off-loading capabilities (via minion ..etc).
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:
> Hello Alex,
> Thank you for the prompt explanation, I checked out the "update" branch
> 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)
> 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.
> Best Regards,
> Ahmed Khalaf
> 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> wrote:
>>> 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
>>> longer accessible
>>> As far as I understand, lowRISC will continue on its own generator, but
>>> 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
>> core subsystems.