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.