Dear Ahmed,
If you want to try ethernet-v0.5 prior to release, proceed as follows
(adjusting as necessary to suit your environment):
git clone -b ethernet-v0.5
--recursive lowrisc-chip-ethernet-v0.5
cd lowrisc-chip-ethernet-v0.5
source set_env.sh
cd riscv-tools/
bash build.sh
cd riscv-gnu-toolchain
cd build/
../configure --prefix=$RISCV
make linux -j 4
cd ../..
cd ../fpga/board/nexys4_ddr/
source /opt/Xilinx/Vivado/2015.4/settings64.sh # Your Xilinx tools could
be installed elsewhere
unset LD_LIBRARY_PATH
make bitstream
make cfgmem
make program-cfgmem
pushd ../../../riscv-tools/
sh fetch_and_patch_busybox.sh
sh fetch_and_patch_linux.sh
pushd
make boot0000.bin
#Your card may get mounted elsewhere
sudo mount /dev/sde1 /mnt
sudo cp boot0000.bin /mnt/
sudo rm /mnt/*
sudo umount /mnt
#Replace card and turn-on SW1, ensure MODE switch is QSPI, reconfigure board
This will not install the userland or demonstrate the remote booting
feature, but it will perhaps allow you to see whether it is likely to be
worth further efforts to get to grips with it. Right now performance
when running networked will be an issue that needs to be addressed (the
board runs permanently in promiscuous mode).
Regards,
Jonathan
On 13/11/17 13:53, Ahmed Khalaf wrote:
Dear Dr. Jonathan,
Thank you for the detailed explanation, it's indeed a tricky issue.
Great news there on Ethernet, thanks for sharing .. I will definitely
have a look on that branch, Ethernet networking is one of the most
"wanted" features on RISC-V.
I completely, agree rocket-chip repo is lacking important features and
change management practices (similar to the ones lowRISC have) in
order to enable cleaner reuse and update.
Realistically, I understand that enabling continuous integration from
upstream will not be seamless (at least not possible for next few
releases after aiming for it).
I believe it could be an achievable goal on longer-term and it
requires pressure from rocket-chip users in order to push for the
needed "configurability" and visibility.
I think this is also aligned with the team in UC BAR vision to enable
software best practices in hardware design domain as they describe
in “the Chisel Plan” and I hope they would support such efforts.
By continuous integration, I don't mean fully automatic build as in
software .. for sure there needs to be "conflict reconciliation", but
semi-structured integration strategy.
With my limited knowledge I thought of directory structure, pointing
to rocket-chip repo and having lowRISC changes on a branch (via fork
if needed).
This will make updates a bit easier but as you mentioned "portability"
will be still a bit far.
I believe this will enhance over time, SiFive had an interesting take
on interconnect parameter negotiation with the "diplomacy" package
making it possible for parameters to be "dynamically negotiated
between modules" .. sorry, it's still a Chisel extension.
I do appreciate the openness and ambitiousness lowRISC brings to the
digital design ecosystem and I expect no less than a game changer
like Raspberry Pi.
Thank you very much.
Regards,
Ahmed Khalaf
On Mon, Nov 13, 2017 at 3:01 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk
<mailto:jrrk2@cam.ac.uk>> wrote:
Dear Ahmed,
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 compatible peripherals.
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.
Regards,
Jonathan
On 13/11/17 11:35, Ahmed Khalaf wrote:
> Hello again
>
> 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 similar structure.
>
https://github.com/ucb-bar/project-template
> <
https://github.com/ucb-bar/project-template>
>
> 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 .. 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]
> <
https://github.com/lowRISC/lowrisc-chip/issues/51>
>
> 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.
>
> Thank you.
>
> Best Regards,
> Ahmed Khalaf
>
> On Sat, Nov 11, 2017 at 6:34 PM, Dr Jonathan Kimmitt
> <jrrk2(a)cam.ac.uk <mailto:jrrk2@cam.ac.uk>> wrote:
>
> Hi Ahmed,
>
> 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.
>
> Regards,
> Jonathan
>
>
> On 11/11/17 15:54, Ahmed Khalaf wrote:
>
> Hello Alex,
>
> 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
> tedious.
>
> 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
> <
https://github.com/ucb-bar/riscv-boom>
>
> 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
> top-level).
> 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.
>
> Best Regards,
> Ahmed Khalaf
>
> On Sat, Nov 11, 2017 at 5:20 PM, Alex Bradbury
> <asb(a)lowrisc.org <mailto:asb@lowrisc.org>> wrote:
>
> On 11 November 2017 at 14:58, Ahmed Khalaf
> <me(a)ahmedkhalaf.com <mailto:me@ahmedkhalaf.com>> wrote:
>
> Hello,
>
> I have noticed lowRISC git repo doesn't rely on
> rocket-chip
> <
https://github.com/freechipsproject/rocket-chip
> <
https://github.com/freechipsproject/rocket-chip>>
> and has forked some
> sub-modules from
github.com/ucb-bar/
> <
http://github.com/ucb-bar/> git repos (like
> hardfloat), this
>
> makes
>
> sense.
>
> 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
>
https://github.com/ucb-bar/rocket/
> <
https://github.com/ucb-bar/rocket/>
>
> 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:
>
https://github.com/freechipsproject/rocket-chip/
> <
https://github.com/freechipsproject/rocket-chip/>
>
> blob/master/src/main/scala/rocket/RocketCore.scala
>
> 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
>
https://github.com/lowRISC/lowrisc-chip/tree/update
> <
https://github.com/lowRISC/lowrisc-chip/tree/update>
>
> 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.
>
> Best,
>
> Alex
>
>
>
>