(no commit message)

[libreriscv.git] / x-list.mdwn

Hi All,

I think the time has come that someone constructs a list FAQ that we can
put on the footer of posts. I’m not the best person to write it as like
anyone I have unconscious biases that need to be moderated. It should be
moderated and edited by several people. Nevertheless, I’ve had a go at
a starting point. We need to put a stop to some of the recent behaviour
on the list. Misinformation, speculation, gossip and negativity towards
the current RISC-V standards track e.g. attacks on RISC-V suitability
for use in X are not appropriate. We need to move the discussion back to
purely technical issues, such as evolutionary and positive steps forward
vs revolutionary rhetoric that attacks towards RISC-V. This requires
some policy.

This starting point for the list FAQ has a number of list misdemeanours
including ones committed by me in the past, with lack of knowledge as a
newcomer. Recent list traffic has crowded out the largest contributors
to the specs and has made reading the list cringe material. The rhetoric
on the list is occupying the mental bandwidth of many readers to the
point where the list is becoming unreadable. This needs to stop. The
traffic doesn’t represent the track of the many people who have
contributed to the current base, which is the apex in which RISC-V
will evolve from. RISC-V is not intended to be revolutionary rather it
represents the next step in evolution from CISC, proprietary ISAs and
the expiration of patents that allow for the construction of a royalty
free open standard at the hardware level in a similar vain to what has
happened with Linux at the software level. This is an industry standard
group for an open standard.

I’m not apologising for my long email. I’ve added bullets so one can
skim through. I’m not apologising for my bias. I support the existing
RISC-V standards track and open tools which represents the huge amount
of work done by many contributors to date and I support the existing
standards and its careful quantitative evolution.

Work on a reference implementations for proposals and test them in RTL,
Gem5, QEMU, spike or other. Ideas are not the time-consuming work. Testing
them is…

My response mirrors the discourse. It is not technical, or when it is,
it is not consensus oriented. I find this difficult to digest. Particular
because my recent focus has been on a faithful and accurate representation
of the current specifications with a focus on backward and forward
binary compatibility.

-
https://www.sifive.com/blog/2018/04/25/risc-v-qemu-part-2-the-risc-v-qemu-port-is-upstream/

A lot of the recent discourse is at odds with the current standards
track and stated goals of the foundation, such as agnosticism towards
proprietary or open implementations. I believe the choice for openness
is out of pragmatism vs ideology. DRM is going to be one of those things
that gets implemented on RISC-V whether we personally agree with it or
not. We should refrain from attaching emotive language to implementation
choices that are legal for which we disagree with.

I tend towards consensus seeking behaviour. This list has become
somewhat exhausting to read and I can’t contribute to the current
style of discussions. It has occupied too much of my mental bandwidth
which compelled me to write this email, instead of working on what I’m
supposed to be working on. I do think we have a problem on this list
which we need to resolve.\

The founders of the ISA should be able to respond constructively and
positively to proposals on the list. The fact that they are not is an
indication that something is wrong.

This email is not intended to start a discussion. It’s more one of
despair. i.e. being nearly ready to hit “unsubscribe”.

Sincerely, X-Michael.



## X-RISC-V ISA Development Mailing List FAQ


* Advocate for RISC-V on this mailing list

Constructive criticism is essential for evolution of the RISC-V
specifications, however opinions without quantitative assessment or that
contain a general disillusionment towards RISC-V are not in the spirit
of this list. Things can and will be improved as the specifications
evolve. Quirks exist. They can be ironed out. To improve the ISA we
need to maintain a generally positive attitude towards the evolution
of the specifications, keeping in mind binary compatibility with the
existing specifications. Editing the specifications is hard work. Gossip,
speculation and inaccurate accounts of computer history are not on topic.


* Read Computer Architecture, Sixth Edition: A Quantitative Approach

As we all know, this book contains the foundation of the RISC-V
quantitative design. Quoting Amazon: “Computer Architecture:
A Quantitative Approach, Sixth Edition has been considered essential
reading by instructors, students and practitioners of computer design for
over 20 years. The sixth edition of this classic textbook from Hennessy
and Patterson, winners of the 2017 ACM A.M. Turing Award recognizing
contributions of lasting and major technical importance to the computing
field, is fully revised with the latest developments in processor and
system architecture. The text now features examples from the RISC-V
(RISC Five) instruction set architecture, a modern RISC instruction set
developed and designed to be a free and openly adoptable standard. It
also includes a new chapter on domain-specific architectures and an
updated chapter on warehouse-scale computing that features the first
public information on Google’s newest WSC.”


* RISC origins at Berkeley

Rhetoric that compares RISC-V to a student project is defamatory and
belies the fact that there is widespread support and adoption for RISC-V
in the MCU space with companies committing to ship billions of RISC-V
processors in deeply embedded applications. The RISC-V Foundation
represents the apex of the academic-industrial complex and this is
shown by the Foundation membership. Please respect that this list is for
supporters of RISC-V and includes some of the most brilliant minds in the
industry. argumentum ad hominem and conspiracy theories should be avoided.


* The RISC-V Foundation has a large number of committed member companies.

There are newcomers on the list who are not aware that they are
broadcasting to a large Foundation of committed RISC-V member companies
who support the RISC-V standards. General rules for constructive
criticism and neutral discourse apply as indeed they would for any
industry working group.


* The privileged ISA is not a POSIX/Linux ISA

The only thing in the privileged specification that supports a
UNIX/POSIX-like OS is S-mode page based address translation and
the Supervisor mode / User mode privilege separation. These are
optional. These functions are not limited to POSIX. Windows NT with its
roots in VMS could use these facilities with PE/COFF and UEFI to run
ntoskrnl.exe on RISC-V. The System V ELF ABI and calling convention is
documented in a separate processor supplement ABI document. The Linux
ABI is not part of the ISA.


* Binary compatibility is important for MCUs

The machine mode registers should be consistent across
implementations. Binary compatibility for micro controllers is just
as important as OS level binary compatibility (which is distinct) as
it allows RISC-V system level code to be shared across heterogenous
implementations.


* Modularity makes small implementations easier

The modularity of the RISC-V specifications is very well thought
through and is one of its strengths; credit to the ISA designers. RVI
plus minimal M-mode is as easy to implement as one would expect for a
simple MCU with in the order of a few hundred bits for processor state
on top of the register file.


* A minimal M-mode implementation is not onerous

An M-mode only implementation requires approximately 11 CSRs (mcycle,
minstret, mstatus, misa, mie, mtvec, mscratch, mepc, mcause, mtval, mip)
out of a set of 18 CSRs. This is not onerous. Several only require 1
bit of state in a minimal configuration.

Below are the 18 CSRs with the minimal 11 identified which are necessary
to implement a processor confirming to the M-mode subset of the Privileged
ISA as distinct from the User-level ISA which only specifies the runtime
aspects of the ISA, versus privilege modes (M-mode is mandatory, S and U
are optional). An implementation with < 11 XLEN machine words is possible.

        /* machine counters */ mcycle - (useful to implement) minstret -
        (useful to implement)

        /* machine information */ mvendorid - (can wire to 0) marchid -
        (can wire to 0) mimplid - (can wire to 0) mhartid - (single core
        can wire to 0)

        /* machine trap setup */ mstatus - (requires MIE) 1-bit misa -
        (1 bit: ‘E’ or ‘I’) 1-bit mideleg - (can wire to 0)
        medeleg - (can wire to 0) mie - (require to enable external and
        timer interrupts MEIE, MTIE) 2-bits mtvec - (required for ISR
        entry, address, can be hardwired e.g to 0x10000) mcounteren -
        (can wire to 0)

        /* machine trap handling */ mscratch - (required register for
        ISR stack pointer) mepc - (required register for ISR return
        address) mcause - (required register for ISR cause: exception or
        interrupt) mtval - (required register for ISR exception info) mip
        - (required register for ISR to see which interrupts are pending)


* RISC-V Control and status registers are accessed with an immediate

Control and status registers are accessed via an instruction
immediate. This means there is no register read required to decode the
CSR. This makes pipelined and Out Of Order implementations easier to
implement. Thus it doesn’t favour one implementation style over the
other. CSRs could be present in an MMIO address space however the CSR
instructions are the interface, not loads or stores. The spec doesn’t
preclude the CSR instructions from fronting MMIO backed register space and
I believe it was a design considerations and a plausible implementation
choice. However, the specified instructions for accessing processor
state use an immediate. This simplifies implementation. Indirection of
access to CSRs via a register would remove the ability to rename and
force serialisation as CSRs can change the state of instructions before
and after them. This would be similar to loads and stores to IO space
which need to be ordered. The current design supports tiny MCUs up to
large multi-core OoO application processors.


* Micro controllers have different memory maps

The only thing limiting binary compatibility between bare metal apps are
typically a linker script because the “memory map” differs between
implementations and they require different device drivers. Bare metal apps
need to have custom chip bringup code for the MCU which is part of a BSP
(Board Support Package). Fortunately the privileged ISA is a constant
across implementations. Moving privileged ISA function into a memory map
won't improve this situation. It will worsen binary compatibility. Higher
level OSes like Linux have user level ABIs and virtual memory to hide the
physical memory map visible to the OS which makes binary portability
easier at higher layers in the application stack. Bare metal code
typically depends on a specific memory map but good design can factor
out the differences between different processors from different vendors.

Many RISC-V vendors are actively working on solutions to these
problems. For medium size systems there is even the possibility of
implementing arm’s EBBR standard which includes a cut down version of
UEFI designed to work with device-tree instead of ACPI. The interface
surface area is tractable for moderately sized embedded systems.

For smaller MCUs, the memory map and devices are likely to be unique.
Systems that have scratchpads that may be too small to hold device-tree
parser (like SiFive’s HiFive1) will of course need custom linker scripts
and custom BSPs. This is par for the course for the type of system that
when scaled may cost several cents and can be used on a smart conference
badge and in systems that are in the 1mm^2 range excluding packaging.


* Standard privilege status and control registers allow for portable
bare-metal code

The standard machine mode registers minimise friction when adapting code
to processors with different memory maps because developers can rely on
a standard control mechanism for traps (interrupts and exceptions).


* An ISA can’t disallow software, on the contrary it is designed to
support it

arm’s EBBR subset of UEFI is actually not that onerous and provides
a relatively clean interface for binary compatible booting on medium
size embedded devices. It is not appropriate for the smallest of
implementations that just depend on the presence of the 11 CRSs mentioned
above. But given RISC-V is an ISA, it can’t prevent someone from porting
UEFI, PE/COFF, coreboot, u-boot, or any OS for that matter. The ISA can
however enforce binary compatibility at the M-mode level.


* Secure implementations that support digital right management are
supported

Mask ROM code that verifies EEPROM payload with signature checks
using a public key in OTP are supported e.g. a Trusted Computing
Base. RISC-V member companies are actively working on boot integrity
across heterogenous RISC-V systems. Customers of chip vendors that have
intellectual property to protect are not excluded. RISC-V is agnostic
towards end-use and doesn’t have any restrictions on endeavours besides
compliance with the technical requirements of the ISA, for reasons of
binary compatibility.


* RISC-V has several ISA variants

At the moment MCUs and application processors with the same ISA share
the same calling convention, but there are several ISA variants with
different calling conventions in the RISC-V suite depending on the
presence of F, D, E. The C extension also creates an ISA variant (GC
code is not compatible with G), hence its presence in ‘misa’.


* MCUs don’t need to save/restore all registers

In the future, users of the open source tools will be able to do things
for the MCU profile like hide the ISR setup and entry assembly behind
C/C++ attributes, so programmers don’t need to worry about these
low-level details. It is possible, today, with existing tools, to model
an MCU ABI that has less register save restore overhead by compiling ISRs
(bottom half) with a different set of registers to top half code. It
is not necessary to make wholesale changes to the Privileged ISA to
achieve this. Optimising trap/entry exit clearly requires some thought
and using the standard C ABI may not be optimal. Luckily we can write
bare functions and use inline asm, etc.

Save/restore overhead can be reduced now with thoughtful use of compiler
flags (-ffixed-reg) or hand coded assembly. Special compiler support will
make this even easier in the future. Also, if code is purely interrupt
driven, then ISRs can also avoid save/restore alttogether. They are
many techniques to minimise interrupt overhead that don’t require ISA
changes. Recursive interrupts are of course a distinct issue that requires
thoughtful design… and I suspect will be addressed in a future version
of the spec, in an evolutionary vs revolutionary manner.

When a competitive RISC-V system can run at an order of magnitude faster
clock speed in the same process and area, then claims of these overheads
are “bunkem”


* Is forking the RISC-V ISA a good idea

Folk are free to fork the architecture , as it is CC licensed, and folk
can even call it RISC-V if they comply with the specifications and if
implementing a processor, an implementation need to implement the 11
or so M-mode registers (and several more wired to 0). The User-Level
ISA can only be used alone as part of an AEE. This is outlined in the
current specs. Custom additions have to follow the conventions set out
in the specification.


* Should RISC-V trademark rules should be enforced

Members could potentially be violating the RISC-V trademark usage
guidelines and I believe they should be enforced:

- https://riscv.org/risc-v-trademark-usage/

Example 1:  https://emb-riscv.github.io/

Implementation proposal that does not comply with the minimal M mode
requirements and may not be RISC-V compliant. The “Embedded RISC-V”
initiative may very well comply with the Base ISA however as far as
I am aware, a complete processor must implement M mode unless it only
aims for AEE compliance. Use of the RISC-V logo in a way that suggests
endorsement from the foundation without explicit permission should be
questioned e.g. is “Embedded RISC-V” the official embedded working
group and who is the chair? Using something like X-Embedded might be
less risky assuming this may or may not be the Foundation’s official
Embedded Working Group? It is hard to tell. It is suggestive.

Example 2:
https://github.com/cliffordwolf/xbitmanip/blob/master/xbitmanip-draft.pdf

Uses X- prefix, extends the specifications, doesn’t modify the RISC-V
logo. Clearly fair use.


* Do we need an embedded working group.

I’d like to know more about the embedded working group. I think it would
be a disservice to the other foundation members if it was run by one
member acting without consideration of the existing specifications and
the needs of other members. I imagine minimising binary incompatibility
would be a mandate for the group with an objective to create “minimal”
differences or additions to the Privileged ISA versus a radical departure
that throws out the most minimal portion of the Privileged ISA.


* Folk should be free to experiment, within reasonable bounds

Certainly there needs to be a balance of freedom to experiment with the
RISC-V architecture i.e. academic or research use, versus commercial
implementations that would be subject to compliance assessment. Look at
how other commercial and individual members of the RISC-V Foundation
use the RISC-V logo and represent their custom “extensions”. Very
carefully. e.g. preceding specifications with X or noting said
specifications are “unofficial proposals”. My advice would be to avoid
wholesale replacement of portions of the specification and representing
it as “Industrial RISC-V” and the “RISC-V Industrial Profile”
versus “RISC-V X-Industrial Profile”. Someone could easily perceive
these as a projects that are endorsed by the foundation.

The mandatory portions for a minimal processor implementing M-mode and
RVI are indeed by all accounts small, so if an additive X-custom micro
controller profile is available, it may very well be accepted, assuming
it is compatible.


* RISC-V ISA is open but agnostic to free and open source versus
proprietary implementations alike

Regarding a Trusted Computing Base, RISC-V is available for use by
proprietary and open source implementations alike. This is clearly
stated on the foundation website. If implementations were restricted
to the hardware equivalent of GPL, then adoption in industry would be
very limited. The choice for on an open standard ISA is out of pragmatism
(cost reduction, shared common interest, industry competitive ISA that is
also a base for computer architecture research). It is not idealogical
(anti-DRM, tit-for-tat licensing schemes, prevents proprietary usage
or proprietary additions, or alternatively prevents open usage or open
additions). Many RISC-V Foundation members have intellectual property they
want to continue to protect and RISC-V is completely open to supporting
these implementations.


* RISC-V Base ISA requires 2-read ports 1-write port

Newcomers to the list might propose things that are inappropriate based
on design decisions that are already set in stone or frozen. We should
maintain a list FAQ for things that have already been discussed on the
list, such as instructions that require 3 read ports. FMA in F and D is
an exception and why. The Vector ISA allows for predicated operations
and the intent, as i’ve witnessed it, is to keep the implementation
requirements for the Base ISA to 2-read ports 1-write port. This means
two input operands. The Base ISA has no exceptions to this rule. F and
D which are optional extensions have some instructions with 3 input
operands and/or use implicit state. e.g. floating point instructions
read ‘frm’ and write to ‘fflags’. We can then simply reply with
a pointer to the FAQ.


* Inflammatory language vs neutral tone

Avoid inflammatory language and slang on the list. Words such as
“bunkem” and “treacherous” are examples of words that are not
appropriate for use on the list. “misinformation” is a more neutral
and correct. Avoid sensationalising issues and/or grandstanding.


* Long emails

If you want to send long emails, keep their frequency very low. I’ve
added bullets to this email so folk could skip ahead. i.e. “brevity
is the sole of wit”. A long email every few weeks is better than
occupying > 50% of the list bandwidth with distant goals when there are
more immediate and practical issues to solve. This involves discussing
and submitting edits to the “existing” specs versus occupying
the list with a deluge of radical departures from the current ISA
specifications. Post at a low frequency and gather feedback off list if
you write very long proposals, link to them


* Fragmentation, gossip, opinion and speculation

Fragmentation, gossip, opinion and speculation on this list is harmful. We
need to keep the discussions on this list technical and refrain from
industry gossip, fear mongering and opinion. Let’s keep things technical
and let’s focus this list on small incremental additions to the parts of
the ISA that are not frozen. I thought discussing something like a SELECT
instruction was quite controversial (3 operand form of conditional move
that requires a third bit-line read port and a zero comparator on each
physical register). Very uncontroversial in comparison to the recent
rampant expletive filled sagas on this list.


* Inclusivity and digesting

The list should remain open, inclusive and friendly towards newcomers. If
the discussion veers off topic, or becomes time consuming, point someone
to a book, FAQ or other material. Newcomers however should not post
material at a rate that a large number of members on the list can’t
possibly digest. Care for other peoples consciousness and their ability
to digest information. Its possible to overload people and occupy peoples
consciousness to their detriment if they are regular readers of this list.


* My own view. I’m not speaking on behalf of the foundation or my
employer

This should be implicit. This is a public list. I’m speaking in my
personal capacity. I would not dare to represent anything as RISC-V
without appropriate approval. Discussing the RISC-V ISA is on-topic on
this list. Proposing additions to the official specs via established
channels such as the working groups and this mailing list is on topic.