One thing that worries me about RISC-V is how much encoding space for (major) opcodes they already used up.
There are 7 bits to encode the opcodes. Of those 128 possible values, 3/4 are used for 16-bit compressed/thumb instructions.
The remaining 32 values are allocated as follows:
* 4 are for custom instructions
* 4 are for larger than 32-bit instructions
* 21 are already used
* 3 are reserved for future use
While there is some space for minor opcodes (encoded via func3/func7) inside of the already allocated major opcodes, this allocation seems overly generous to me considering how young the instruction set still is.
I would have felt far more comfortable with compressed instructions only taking 1/2 instead of 3/4 of the total available space.
RISC-V isn't limited to 32 bit instructions. In fact RISC-V insns are variable length, and as well as 16 bit (compressed extension) they can be longer than 32 bits -- in fact much much longer.
What RISC-V needs for high adoption, is a well-marketed product similar to the Raspberry Pi.
Give me an open source model board with a kernel, network, graphics, peripherals, and general-purpose I/O. Give it to me cheap. Give it to me with a desktop environment.
Give me example simple real-world use cases ("build a ping response box!", "build a home video recorder!", "build an internet-enabled light switch!", "build a sound amp!", "build a robot to take over the world!", etc) and the hardware and software for a DIY-er to... do it by themselves.
Give people hardware, software, and examples (monkey see, monkey do), and you'll find more people adopting RISC-V.
That's a big ask. Right now RISC-V has a handful of open source CPU cores. There's no open source network, graphics, peripheral and GPIO hardware that can be cheaply plugged into a synthesized design that can be sold at the price you want. Which is to say, while there's plenty of stuff out there that someone made work on a FPGA once, there's nothing with a track record and validation/driver stack ready that you can throw into your tools and expect to get a working chip with. And that's what those SoCs you find in the Pi and similar boards need if you want to get them out at the small-integer-dollars price point: no-brainer existing IP that won't surprise anyone along the manufacturing and support chain.
> There's no open source network, graphics, peripheral and GPIO hardware that can be cheaply plugged into a synthesized design that can be sold at the price you want.
Why not PCIe? Aren't there already a bunch of design/validation/verification tools for it? A RISC-V CPU with just a bunch of PCIe lanes (and a couple of channels of fast DDR4) coming off of it (and maybe an IOMMU) would be a lot easier to integrate with existing hardware, rather than trying to recreate open-source equivalents of modern GPUs and network hardware.
I like the idea, but unfortunately PCIe isn't easy or cheap to implement on silicon. The problem is that you'd need the PHY, which is the high speed, analog interface, and that needs to be designed and tuned for the fab and process node you're targeting. In practice the only sane way to get PCIe on your chip is to buy a PCIe IP block from Faraday or Synopsys. The same goes for SATA.
Ethernet and USB on the other hand is available in discrete PHY chips, so writing some open-source controller RTL for RGMII and ULPI is much more reasonable for an open-source chip.
(Obviously, if someone would cough up the money for taping out a RISC-V SoC with PCIe PHYs onboard and make it in a large enough volume that the price gets down to reasonable levels, I'd be buying a bunch of'em.)
There are simple open source cores for quite a few IO standards. Some ARM SoCs use Cadence or Synopsys cores.
What could be a good advert for RISC-V would be to design a SoC that used a full featured RV64 main core and simpler RV32I cores as offload engines for each IO device.
"Our open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board."
Includes one of the Rpi co-founders.
Edit: Others have pointed out that it won't likely be in the same price range as the Rpi. Probably closer to the Beaglebone range.
>
What RISC-V needs for high adoption, is a well-marketed product similar to the Raspberry Pi[...] Give it to me cheap.
The economies of scales that made the Pi's low price possible are totally absent for RISC-V: There isn't a SOC inventory glut like the one that got induced by the demand for smartphone components.
Wow, that video is a lecture by one of the leaders of RISC-V. I had no idea there was a RISC-2 and RISC-3, and that they were optimized for SmallTalk and Lisp respectively. Wonder what Alan Kay has to say about RISC-V? He's been banging on about how Intel messed up their chip design, does he approve of RISC-V? Seems like the perfect time to get things done right.
At the end of the day, RISC-V will only succeed if I can buy a board where I can attach some SATA drive, a monitor and keyboard/mouse the same way people buy some ITX board.
This might be tough to hear for people discussing the ins and outs of RISC-V and why is so much better than x86 or ARM and the big name sponsors don't make it any better with the usual tight hugs and lullabies. But you need to put it in the hands of the people just like "the PC", otherwise it will be a pet project waiting to be forgotten by everybody other than the nostalgic ones.
There's gazillions of embedded processor cores in every device you own. Your SSD, network card, phone, motherboard, router, TV, modem, car, fridge, you name it all have multiple processor cores running some piece of firmware you never see. RISC-V has a pretty good value proposition for those: an open standard with no licensing costs with a rapidly maturing software ecosystem. To say that RISC-V will only succeed if you can attach a monitor to it only betrays a very narrow view of where processors are actually used.
Intel - Intel - tried to compete in the embedded market and has recently quietly withdrawn several of its products. It's a tougher market than it sounds, and it's also more conservative than you'd expect.
True, many are indeed using ARM (in house designs are also more popular than you might think in deeply embedded SoCs), but a lot of companies would love to be able to throw out ARM due to licensing cost & hassle, or at least have a viable option in RISC-V to throw at ARM at the bargaining table.
Intel didn't really try. You know who did really try ? espressif, with their famous ESP32.
Or the startups: indie-semi, who sell mcu's built as lego's from multiple dies, affordably! which allows them to do custom-design and semi-custom design of mcu's per customer , while offering a large library of standard mcu's.
Or terechip, who built a chip packaging process who can handle dies orders of magnitude smaller than current systems - opening possibilities for far cheaper mcu's and other simple chips.
Or even ambiq-micro, which created a way to design mcu's that take ~10x(?) less power by enabling transistors to work on an extremely low supply voltage.
This is how you compete with entrenched competitors. By doing something they cannot do.
And Intel ? their fab doesn't even fit mcu's(no flash on logic processes, not good fit for analog). They had no advantage, no differentiation( maybe besides their neural network, a feature that didn't seem to attract customers). How did they expect to win ?
Its almost as if they expect that just putting chips into a market makes that market have to buy it, almost as if they have gotten to used to not needing to compete. How could a chip vendor that has thoroughly cornered a few major market segments and might be considered to have some amount of monopoly status ever get into such situation?
Intel is expensive, and not very power efficient in tiny chips.
ARM is much cheaper and more efficient. RISC-V is similar to ARM, but even more cheaper.
I think a combination of things, really. They never scaled down properly to really low end devices. The Intel systems had poor peripherals for some reason with high latency. They didn't really grasp the detail of what was needed for either the "maker" or industrial markets. And of course it wasn't a licensable IP.
That metric of success will never be achieved if you don't win the heart and minds of "regular folks" and remember, to "make" a phone, router, TV or fridge you first need to plug your keyboard somewhere.
Don't try to conquer ARM doing what ARM has done, time doesn't go back and the small world of embed big wigs will ignore you.
That what you need to make RISC-V a popular success. But really, it's already a success in a research context. I really wish something like it had been around when I was doing my thesis and by all accounts lots of researchers are using it as a base design that can be modified in various interesting ways.
And there are lots of successful architectures out there that don't go into PCs. On the low end there's AVR, at the high end there's MIPS, and then there's ARM that's sort of eating everything. ARM started out as a desktop but it spend a long time as an embedded only processor before returning to popular consciousness. If RISC-V takes over cell towers or NAS boxes or robots or flying cars or whatever it could be quite successful without ever penetrating popular consciousness.
And that's exactly my point, if some NVIDIA exec has some bad night's sleep there goes your success the next morning.
These big players are only in this because they are afraid of missing out and have enough bucks to burn, when one of those things stop to happen, bye bye RISC-V.
I used to be a big champion of RISC-V, just look at my submission history, but I've become increasingly weary due to SiFive's dubious leadership.
1) It's still impossible for anyone to get their hands on an FE310 chip over half-a-year on from the release of the HiFive board.
2) They promised open-source cores, but somehow backtracked due to "customer requests". How does this make any sense? And if so, just have an open-source version, and a closed-source one that, I dunno, has a SiFive logo on the mask.
I was really inspired by them, now I'm mostly dejected. Still, I'm hoping someone like ST takes their peripherals and makes an MCU with a RISC-V.
What's needed, and possible, today, is a competitive and relatively simple AVR or ARM-M0/M3/M4 replacement (with I2S). Such a chip is likely to receive stellar support from the maker-community.
My gut feeling says that such a chip is likely to come from Samsung, but NXP and Expressif are also likely candidates. All are RISC-V members.
Anything more complex should wait until the specs are complete.
Production of chips that support the privileged specification, which is needed for operating systems like Linux to run. So far there is only one microcontroller chip being produced.
I hope this refers to ring-0-like instructions such as x86 STI, and not some kind of OEM/manufacturer "you can only use this set of instructions if you pay us" type privilege?
So, how does RISC-V compare with Donald Knuth's MMIX instruction set? Did they use it as a starting base? Consider it at all? Be cool to program MMIX in actual hardware.
If you consider an FPGA board real hardware, then yes, I've run MMIX programs, including graphics, on real hardware: https://github.com/tommythorn/fpgammix Caveats: this is some of the worst Verilog I've even written; I was explicitly racing ahead learning about MMIX as I went along. In the end I had a large subset (integer usermode) when I abandoned it. As much as I wanted to like it, it's really a pretty terrible architecture from most perspectives: it's impossible to scale down, hard to scale up, and nearly impossible to generate good code for. In contrast, RISC-V is IMO the nicest RISC ISA ever design.
Cool! Thanks for the hard work, and the insight. For those of us that don't speak Verilog, do you have a paper or some other writeup of the things that make MMIX less than ideal? Other than the scaling up/scaling down. Does that primarily consist of the 256 registers? Neither more or less?
Thank you. Boy, this was a long time ago and I haven't written anything. I suspect it will be obvious for anyone skilled in the act, but I had to go look at my code at bit to remember some of this.
First a quick word from the POV of a compiler: the register windows are supposed to make function call easier and I suppose it works as designed for hand written code, but it actually adds a lot of complexity to indirect call/virtual functions and is a disaster for anything that switches stack (context switches, coroutines, etc). Another problem is the immediate fields which are just 8-bit unsigned, very often too small. And in practical terms, the GCC port really struggles to make good code for MMIX. Try it!
From the implementation POV: even ignoring the resource requirement for the full MMIX (which besides 256 registers includes a LOT of functionality), it's hard to pipeline as MMIX actually have fairly complicated semantics; just look at the state machine, the S_XXX symbols in https://github.com/tommythorn/fpgammix/blob/master/rtl/core....
While you can obviously deal with that (as witnessed by x86), it requires you to speculate a lot (for starters, speculate that you didn't get an interrupt). All speculation add complication as you need to recover from mis-speculation. This in term hurts cycle time by making stages more complicated and is a MAJOR source of verification work (AKA bugs).
My implementation is nearly completely un-pipelined, very similar to a simple interpreter but in Verilog. Once I had enough functionality that I could look back and consider a more realistic implementation, I really lost the enthusiasm and instead focused on MIPS which is dramatically more efficient and easier to implement (pesky branch delay-slot not withstanding). Of course, later a friend leaked word of nascent RISC-V and the world was forever different.
I actually asked Don directly why he hadn't gone with something like MIPS, but he answered vaguely that he wanted something for education.
On the positive side, I found a bug and scored a $2.56 check (real dollars) and a couple of MMIX T-shirts :)
There are 7 bits to encode the opcodes. Of those 128 possible values, 3/4 are used for 16-bit compressed/thumb instructions.
The remaining 32 values are allocated as follows:
* 4 are for custom instructions * 4 are for larger than 32-bit instructions * 21 are already used * 3 are reserved for future use
While there is some space for minor opcodes (encoded via func3/func7) inside of the already allocated major opcodes, this allocation seems overly generous to me considering how young the instruction set still is.
I would have felt far more comfortable with compressed instructions only taking 1/2 instead of 3/4 of the total available space.