[lowrisc-dev] lowRISC versus the rest of the RISCV world (rant?)

Alex Bradbury asb at asbradbury.org
Wed Jul 20 11:58:12 BST 2016

On 14 July 2016 at 22:16, Reinoud Zandijk <reinoud at netbsd.org> wrote:
> Dear folks,
> with horror I've read the current discussion on DRAM/MMIO/devtree/etc
> discussion. We're really missing the point of what lowRISC can be and in a
> kind of sense, what RISCV can become.
> The current discussion boils down to defining a new mode of transportation
> complete with infrastructure but at the same time demanding it needs to have 4
> wheels, run on petrol, has a customized Ford engine and needs 4 seats. If you
> get my drift, thats not really designing a new mode of transportation but
> defining yet another car. If its again just another car, why bother developing
> it if the only thing it distinguishes from the competition is the fact that it
> has a good service manual.

Yes, I take your point here - if you're going to be different to the
de facto standard you might as well rethink a whole bunch of

> We are now in the unique position to be able to create a new software and
> hardware ecosystem so why settle for the fluke of the day.  Now I can't speak
> for the rest of the RISCV community and they might have good reasons to do it
> their way, who am I to question that, but for lowRISC we ought to aim a LOT
> higher.
> (shameless plug here :)
> Hence my proposal I posted earlier; it deals with virtualisation, device
> discovery, extended debuging, hypervisor, security, strict memory isolation,
> minions, software devices, etc. etc. Could very well be extended with NOMA
> etc.
> Less drastic solutions might be fine too, and lots of variants are possible
> too so feel free to comment on it or try to shoot it down, but at least its an
> effort to create something new and not follow the beaten track of say ARM.

With lowRISC we're very interested in pursuing new hardware and
software features, and going beyond just replicating something that
looks like a typical ARM/MIPS SoC. This is the reason for our focus on
minion cores and tagged memory. That said, there are major benefits in
supporting the integration of traditional devices and in reusing as
much operating system and driver code as possible. As you point out,
if you try too hard to be fully compatible with everything existing
today you'll end up looking just like everything that exists today.
There's hopefully a sensible balance somewhere between the two
extremes of throwing every existing out of the window and in
unambitiously recreating precisely a standard current-day SoC

At the RISC-V workshop last week, Krste suggested the model for
proposals to the RISC-V Foundation be that these proposals are in-line
with the minimal spirit of the RISC-V ISA and that they are
accompanied by implementations. I think a similar approach would be
useful with lowRISC. You're certainly keenly aligned with the focus on
simplicity, but it's hard to truly judge a proposal and ensure all the
details have been thought through until it has been implemented.
There's a bit of a chicken/egg problem as I can understand reluctance
to implement even a qemu/spike model of an idea until you think it's
likely to be accepted. I do think trial implementations are key
though. I hope work like the xv6 port will also help to provide a very
simple minimal OS that might be a good target for experiments that
would be difficult in a much larger codebase such as Linux or *BSD.



More information about the lowrisc-dev mailing list