RISC-V development plans

[Krste Asanovic]

Dear RISC-V community,

It's been a whirlwind ride this last couple of years, as the momentum
behind RISC-V just keeps on building. While there has been a
tremendous amount of activity behind the scenes in RISC-V land, the
core team has been guilty of not communicating well to the larger
community, and I'd like to try to help remedy that with a series of
unfortunately long emails to help explain where we are and what we
think we need to do.

Many of the machinations involved setting up the Foundation and
arriving at sound and acceptable legal structure for many things. We
viewed these as vital precursors for making sure RISC-V can succeed
and persist, and thankfully it looks like at least the initial wave of
these issues have been resolved. Some visible results of this
activity are the large number of founding members on the website (and
many more waiting in the wings), the board and committees being
established, and finally the upstreaming progress.

Hopefully the core team can now help focus on the more fun technical
and planning matters, and I think we're all keen to be better about
communicating with the whole community and expanding the core team to
help make everything happen. Although I'm looking forward to the next
workshop, November 29-30 at Google, I realize only a few of you can
actually make it there, and that many of you who are now actively
contributing have never been, and may never attend, a workshop (please
try to attend - they're fun!). I would like to keep using the mailing
lists as the obvious place to communicate with the whole community,
and although there has been a large upsurge in mailings, I think the
community can begin to self-police threads (or start new
topic-specific lists), to prevent the signal-to-noise ratio degrading.

There have been some frustrations expressed on the mailing list, some
of which are due to understandable confusion about "the plan". I
wanted to write to the community to help orient everyone on where
things are and where things are going, at least from my own
perspective. In this email I want to focus on status and plans.
Further emails will focus on some specific areas that need work.

Please try to respond on-topic to the correct thread - this one is
about overall plan not individual technical topics.

1) Background and overall RISC-V philosophy

This seems to get a bit lost causing some discussions to run awry.
RISC-V is designed as a modular system. The ISA is composed of
modules, which comprise the base ISA plus extensions. Other important
modules are the calling convention, ELF encoding etc. A given
platform will define a complete hardware/software interface (e.g.,
ABI) using some combination of the standard modules - the ABI is
really what defines what is mandatory for a platform not the ISA. One
goal of RISC-V is to support the widest range of systems by reusing
the work done to create each module.

For example, we can divide the systems in which RISC-V will be used
between native and foreign platforms. A native platform is one
designed around RISC-V, while a foreign platform is one defined around
another architecture into which RISC-V cores are inserted. Some
important native platforms are tiny microcontrollers (e.g., Arduino),
small networked microcontrollers (e.g., IoT), real-time
microcontrollers (e.g., cars), and Unix-capable platforms (everything
from Raspberry-Pi to servers/supercomputers/mainframes). Foreign
platforms include existing versions of all of these, and more. Each of
these has very different needs and a different software stack, but a
clear goal in RISC-V is to avoid gratuitous incompatibilities across
these widely varying application spaces.

RISC-V is also designed to work across a wide range of implementation
styles, so proposals for ISA standards should consider how they're
constraining implementations across the range. Numerically, most
RISC-V cores will be tiny and not run an OS. Economically, high-end
multicore systems running virtualization will be very important.

2) Status of the ISA and specs

Our group at UC Berkeley developed the original set of specifications
and reference implementation (Spike), and these are what development
has been based on. However, these have not been formally ratified by
the Foundation. The different components are at the following stages
of "doneness":

Base Version Frozen at UCB?
RV32I 2.0 Y
RV32E 1.9 N
RV64I 2.0 Y
RV128I 1.7 N

Extension Version Frozen at UCB?
M 2.0 Y
A 2.0 Y
F 2.0 Y
D 2.0 Y
Q 2.0 Y
L 0.0 N
C 1.9 N
V 0.1 N
B 0.0 N
T 0.0 N
P 0.1 N
N 1.5 N

where version 0.0 implies nothing has happened but intent is there.
0.1 implies some thought or framework is there, but no full spec
proposal, 1.9 implies we think it's close to frozen. "Frozen at UCB"
means we thought it was fine as is. Even here there are some
unresolved issues that will need to get fixed before officially
standardized, the big one being the memory model. A minor one is the
real-time counter. Separate emails later on these.

The calling convention seems mostly stable, but needs documenting.

The ABI and ELF encoding need fixing up and documenting.

The privileged architecture is at 1.9.1, and not frozen, as more work
is clearly needed. Boot process and configuration string issues for
Unix-capable systems need to be resolved. More on this in later
email.

3) Status of software ecosystem.

This has been filling out at incredible speed, though is obviously
hampered by the spec evolution and lack of native hardware. We all
felt upstreaming as much as possible of the existing software stack
was key to having a mature and maintainable toolchain, and this has
consumed a lot of the core team's bandwidth in the last few months,
and will continue to do so for the next few months.

There is still much to do here, but this is perhaps the part that is
most easily parallelized across the community, especially as
lower-level specs stabilize, code is upstreamed, and hardware appears.

There does need to be better coordination to avoid duplicate effort,
and better release management for the "blessed" toolchain, which is
another function for the Foundation technical committee to organize.

4) Status of hardware implementations.

Perhaps the biggest surprise to me personally has been how far all the
software development has gone without any commercially available
RISC-V silicon shipping. This is both a blessing and a curse. The
blessing is that there is no legacy right now, and things can change
(as has happened) to remove bugs and warts discovered in porting
efforts that will hamper all future systems. The curse is that there
are no real systems to develop on at speed (QEMU and FPGA systems
help, but are not quite the same as a native silicon attached to real
devices).

The honeymoon will be over soon, as several groups are trying to
prepare commercial RISC-V silicon and will need to commit to a version
of the spec (despite warnings that it's not done yet) and will not
want their hardware to become incompatible in the next spec release.

Avoiding hardware fragmentation is vital to keep the community
together and viable. The aggregate software investment needed to
build an ecosystem dwarfs any one company's hardware development
budget, and having an open and vibrant RISC-V software ecosystem is
perhaps the most valuable component of the RISC-V project.

5) A roadmap / plan

RISC-V will never be "finished', but HW and SW developers need a
roadmap and milestones to plan against. The following is a proposal
for an agressive but possible timeline for development of RISC-V
system specs.

Nov 2016 - 5th workshop
* Agree/tweak plan, assign more leaders and doers

Feb 2017
* Debug spec ratified by Foundation
* Calling convention fixed and documented
* ELF format fixed and documented
* Priv-1.10.0
* M-mode/S-mode changes must be backwards-compatible after this date

March 2017
* Memory model changes must be backwards-compatible after this date

May 2017 - 6th workshop
* Priv-1.11.0
* RV32EMAC RV32IMAFDQC RV64IMAFDQC ratified by Foundation

Aug 2017
* Priv-1.12.0

Nov 2017 - 7th workshop
* V ratified by Foundation
* Priv-1.13.0 -> Priv-2.0 ratified?
* Complete Linux/KVM platform spec agreed, supports other OS (FreeBSD
etc.)

The goal of this proposed plan is that hardware developers should be
able to commit to complex silicon designs by first quarter/half of
next year knowing they will be (and remain) compatible. I've focused
on a Linux/KVM server platform spec as the capstone, as that only
requires S-mode to be finalized (not H), and is the most requested OS
variant. The platform spec should be developed with input from other
OS ports too (e.g., *BSD, Akaros, etc).

The user ISA modules are not likely to change much before
ratification, though there could be a few possible tweaks that we will
want to make clear to community. The memory model is a troublesome
beast, but we should have solid plan well before summer. I'm going to
send out more emails over where I think the possible modifications are
for each piece separately.

With this plan, I'm hoping to focus core developer effort on finishing
the standard, must-be-frozen, RISC-V core specs. All ISAs and
platforms do evolve. The goal is to set up the baseline that will
become our legacy, within which we'll have to work more conservatively
when changing things. There will be plenty of time to fill out the
more esoteric components later.

Thanks,
Krste

[Stefan O'Rear]

On Sat, Nov 5, 2016 at 2:52 PM, Krste Asanovic <kr...@berkeley.edu> wrote:
>
> Dear RISC-V community,
>
> It's been a whirlwind ride this last couple of years, as the momentum
> behind RISC-V just keeps on building. While there has been a
> tremendous amount of activity behind the scenes in RISC-V land, the
> core team has been guilty of not communicating well to the larger
> community, and I'd like to try to help remedy that with a series of
> unfortunately long emails to help explain where we are and what we
> think we need to do.

Thank you very much for taking the time to detail this. I understand
that there are many things to do, and I would like to help where I
can.

> Many of the machinations involved setting up the Foundation and
> arriving at sound and acceptable legal structure for many things. We
> viewed these as vital precursors for making sure RISC-V can succeed
> and persist, and thankfully it looks like at least the initial wave of
> these issues have been resolved. Some visible results of this
> activity are the large number of founding members on the website (and
> many more waiting in the wings), the board and committees being
> established, and finally the upstreaming progress.

Work is truly appreciated, even as I've wished y'all could do
everything at once...

The modularity and third-party extensibility is, IMO, our crucial
value proposition. Without that there is nothing.

Yes, thank you, we do need a bit here.

> The calling convention seems mostly stable, but needs documenting.
>
> The ABI and ELF encoding need fixing up and documenting.
>
> The privileged architecture is at 1.9.1, and not frozen, as more work
> is clearly needed. Boot process and configuration string issues for
> Unix-capable systems need to be resolved. More on this in later
> email.

I look forward to discussing that

Agree completely

+1

> The user ISA modules are not likely to change much before
> ratification, though there could be a few possible tweaks that we will
> want to make clear to community. The memory model is a troublesome
> beast, but we should have solid plan well before summer. I'm going to
> send out more emails over where I think the possible modifications are
> for each piece separately.
>
> With this plan, I'm hoping to focus core developer effort on finishing
> the standard, must-be-frozen, RISC-V core specs. All ISAs and
> platforms do evolve. The goal is to set up the baseline that will
> become our legacy, within which we'll have to work more conservatively
> when changing things. There will be plenty of time to fill out the
> more esoteric components later.

> Thanks,
> Krste

And thank you again

-s

[Keith Evans]

I know that it's been a while since this post, but I wanted to say that it was very informative. I do have a question about one minor part.

>Extension Version Frozen at UCB?

>...
>N 1.5 N

Does anyone know what extension N is referring to?

Regards,
Keith

[Andrew Waterman]

User-mode interrupts.

It's alluded to in the privileged architecture in a few places (e.g.
https://github.com/riscv/riscv-isa-manual/blob/master/src/priv-csrs.tex#L153)
but isn't written down in once place yet.

> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3afcde79-a88d-4a88-844a-785f547f664e%40groups.riscv.org.

[Bruce Hoult]

User-mode interrupts is one of the three key things that made Mitch Alsup (M88k, AMD64, NVIDIA, Samsung GPU) do his (so far only paper) design for the "my66000" ISA.

Have you seen his spec for that?

[the other two things were 1) instructions to allow fast "precise" floating point arithmetic, defined as allowing the programmer to access result bits that would normally be truncated/rounded away. FMA is often useful for this, he adds FADD3 and also instructions to manipulate FP exponents; 2) ESM (Exotic Synchronization Mechanism) primitives for large scale synchronization]

On Fri, Apr 14, 2017 at 3:59 AM, Andrew Waterman <and...@sifive.com> wrote:

User-mode interrupts.

It's alluded to in the privileged architecture in a few places (e.g.
https://github.com/riscv/riscv-isa-manual/blob/master/src/priv-csrs.tex#L153)
but isn't written down in once place yet.

On Thu, Apr 13, 2017 at 5:51 PM, Keith Evans <chen....@gmail.com> wrote:
> I know that it's been a while since this post, but I wanted to say that it
> was very informative. I do have a question about one minor part.
>
>>Extension Version Frozen at UCB?
>>...
>>N 1.5 N
>
> Does anyone know what extension N is referring to?
>
> Regards,
> Keith
>
> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to isa-dev+unsubscribe@groups.riscv.org.

> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3afcde79-a88d-4a88-844a-785f547f664e%40groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0AEWHyW%3DM-tYpTKZfb01WqhesdNuJSrggtOSKNuO1KLow%40mail.gmail.com.