I love computers (but only in a manly-man way, you understand). I’m not talking about the end-products that sit on our desks, hang out in our pockets, or lurk around us as we meander our way through the world, although I’m certainly fond of these little rascals—I’m much more interested in their “brains” in the form of their processing units where all the decision-making and number-crunching takes place.
As an aside, speaking of brains (which, of course, makes me think of Abby Normal), I just started reading Other Minds: The Octopus, the Sea, and the Deep Origins of Consciousness by Peter Godfrey-Smith. I’m only a few pages in but I can tell that this is going to be a gem—it’s already given me food for thought with respect to the early days in the evolution of the nervous system—but we digress…
As we recently discussed in Building a Computer, Should You Inadvertently Travel Back in Time Part 1 and Part 2 (with Part 3 to follow whenever I get a few free moments), I spend more time than is good for me worrying about how I would make my way if I were to fall through a timeslip and find myself transported back to the 1930s. Happily, I think I could find gainful employment with the teams creating early digital computers.
I also think I could make my mark in the 1970s when the first microcontrollers started to appear on the scene—the 4004 in 1971, the 8008 in 1972, the 8080 and 6800 in 1974, the 6502 in 1975, and the Z80 in 1976, to name but a few.
Over time, various processor architectures grew in prominence and subsequently faded into obscurity, like the SPARC from Sun Microsystems, the Clipper from Fairchild Semiconductor, the MIPS from MIPS Computer Systems, and the PowerPC from the Apple-IBM-Motorola (AIM) alliance. (Note that these are just a couple of contenders off the top of my head—can you suggest any more?)
Eventually, two architectures became dominant in the collective consciousness: the X86 from Intel and the myriad incarnations of the ARM architecture family from Arm.
To be honest, when I first heard the name RISC-V (pronounced “risk-five”) being bandied about by those who don the undergarments of authority and stride the corridors of power, I thought of it only as an interesting project for academia. As you may recall, RISC_V commenced as a “short, three-month project over the summer” headed by Krste Asanović at the University of California, Berkeley, but this bodacious beauty has since grown beyond its instigator’s wildest imaginings.
RISC-V is an open-standard instruction set architecture (ISA) that is provided under open-source licenses that do not require a fee to use. The instruction set, whose specification defines 32-bit and 64-bit address space variants, is designed for a wide range of uses. The base instruction set has a fixed length of 32-bit naturally aligned instructions, and the ISA supports variable length extensions, where each instruction can be any number of 16-bit parcels in length. Different subsets support everything from small embedded systems to personal computers to supercomputers with vector processors to warehouse-scale rack-mounted parallel computers.
Throughout much of the 1970s, the concept of personal computers (PCs) in the context of home and business applications didn’t really attract as much attention as we might have hoped for, especially with the benefit of hindsight (which is the one exact science). In fact, it wasn’t until 1981 when IBM announced the first IBM PC that a lot of people started to sit up and pay notice (there used to be a catch phrase in the industry that “Nobody ever got fired for buying IBM”). Similarly, although RISC-V already counts a lot of big names as its supporters—and although a wide variety of soft and hard RISC-V processors and tools are already available—I think the announcement in February 2022 that Intel joined the RISC-V International global open hardware standards organization at the Premier membership level will mark the turning point for many potential adopters (“If it’s good enough for Intel, it’s good enough for me”).
The reason I’m waffling on about all of this here is that there was a flurry of RISC-V-based activity at the recent Embedded World 2022 Exhibition and Conference, which was held just a week ago as I pen these words. First, RISC-V International leapt into the limelight with the following announcements:
- E-Trace for RISC-V defines a highly efficient approach to processor tracing that uses a branch trace, ideal for debugging any type of application from tiny embedded designs to super powerful computers. E-Trace for RISC-V documentation specifies the signals between the RISC-V core and the encoder (or ingress port), a compressed branch trace algorithm, and a packet format to encapsulate compressed branch trace information. Development and ratification of this specification was led by Gajinder Panesar of Picocom and RISC-V’s E-Trace Task Group.
- RISC-V specification for SBI architects a firmware layer between the hardware platform and the operating system kernel using an application binary interface in supervisor mode (S-mode or VS-mode). This abstraction enables common platform services across all RISC-V operating system implementations. Many RISC-V members have already implemented the RISC-V SBI specification in their RISC-V solutions, so ratifying the specification will ensure a standard approach across the entire RISC-V ecosystem, ensuring compatibility. Development and ratification of this specification were led by Atish Patra of Rivos, with work conducted in the Platform Horizontal Steering Committee.
- RISC-V UEFI Protocols bring existing UEFI standards onto RISC-V platforms. Development and ratification of this specification were led by Sunil V L, Ventana Micro and Philipp Tomsich, VRULL GmbH, with work conducted in the Privileged Software Technical Working Group.
- RISC-V Zmmul Multiply Only enables low-cost implementations that require multiplication operations, but not division, and is part of the RISC-V Unprivileged Specification. Development and ratification of this extension were led by Allen Baum, with work conducted in the Unprivileged ISA Committee.
These announcements were complemented and amplified by an impressive barrage of news emanating from all corners of the RISC-V movement, such as the following:
- Ashling + Embecosm: A partnership to provide best-in-class embedded tools, services and solutions for RISC-V
- Codasip:
- Green Hills Software: The company’s Automotive Zonal and Domain Controller RTOS now supports the latest high-performance, multicore automotive microcontrollers
- Imagination Technologies: The IMG RTXM-2200 is the company’s first real-time embedded RISC-V CPU
- Imperas: OpenHW’s CV32E40P Core verified by Imperas RISC-V golden reference model
- MikroElektronika (MIKROE): The NECTO Studio 2.0
- OpenHW Group: The RISC-V-based CORE-V MCU Development Kit for IoT, built with open-source hardware and software
- RISC-V International: First new specifications of 2022, adding to 16 ratified in 2021
- SiFive: Enhancements to its X280 processor IP to meet accelerating demand for vector processing
- Think Silicon: The industry’s first RISC-V 3D GPU
- XtremeEDA: Now working with Crypto Quantique to deploy IoT security
I don’t care what anyone says, I think RISC-V is here to stay. But it’s not all about me (it should be, but it’s not). What about you? What do you think about me? I’m sorry, what I meant to say was, “What are your thoughts regarding the RISC-V universe?”
Hi Max, your article brings up a conundrum I have had recently involving a proposal specifying a processor to be used in conjunction with an FPGA. I ended up selecting RISC-V processor IP to be used but really without a good reason why. Sometimes you go along to get along. Maybe you could enlighten us to this point? I am fully committed to RISC-V processors I just need some reinforcement as to why I am.
Well — the open-source part is a big one — also the fact that RISC-V is being designed from the ground up based on all of the things we’ve discovered (and learned our lessons from) in previous processor designs. The fact that so many people are jumping on board — not least Intel — means that your design will be more portable in the future — I could say more but my wife wants me home for supper 🙂
Hi Max, I think one of the reason a lot of us out here follow you is not just your entertaining writing style and the information presented but the fact that you always reply. Thank you.
I hope you are right, “means that your design will be more portable in the future”, because it certainly influences my decision to use RISC-V. I am most interested in the instruction set and not so much in the hardware to implement it. I will leave the Turing Machine architecture to others much more skilled in the art, as they say. I just hope I will be able to unplug the RISC-V IP from one vendor and use the RISC-V IP from another vendor without extensive changes to the interfaces used. If this turns out to be true, I definitely made the right decision.
Thank you for your kind words — my fingers and toes are crossed for you for good luck — I think you are going to be happy with your selection because I’m hearing nothing but good things regarding RISC-V.