Hackaday has open-source running deep in our veins — and that goes for hardware as well as software. After all, it’s great to run open-source software, but if it’s running on black-box hardware, the system is only half open. While software has benefited mightily from all of the advantages of community development, the hardware world has been only recently catching up. And so we’ve been following the RISC-V open-source CPU development with our full attention.
Our keynote speaker for the 2019 Hackaday Superconference is Dr. Megan Wachs, the VP of Engineering at SiFive, the company founded by the creators of the RISC-V instruction-set architecture (ISA). She has also chaired the RISC-V Foundation Debug Task Group, so it’s safe to say that she knows RISC-V inside and out. If there’s one talk we’d like to hear on the past, present, and future of the architecture, this is it.
The RISC-V isn’t a particular chip, but rather it’s a design for how a CPU works, and a standard for the lowest-level language that the machine speaks. In contrast to proprietary CPUs, RISC-V CPUs from disparate vendors can all use the same software tools, unifying and opening their development. Moreover, open hardware implementations for the silicon itself mean that new players can enter the space more easily, bring their unique ideas to life faster, and we’ll all benefit. We can all work together.
It’s no coincidence that this year’s Supercon badge has two RISC-V cores running in its FPGA fabric. When we went shopping around for an open CPU core design, we had a few complete RISC-V systems to pick from, full compiler and development toolchains to write code for them, and of course, implementations in Verilog ready to flash into the FPGA. The rich, open ecosystem around RISC-V made it a no-brainer for us, just as it does for companies making neural-network peripherals or even commodity microcontrollers. You’ll be seeing a lot more RISC-V systems in the near future, on your workbench and in your pocket.
We’re tremendously excited to hear more about the project from the inside, and absolutely looking forward to Megan’s keynote speech!
The Hackaday Superconference is completely sold out, but that doesn’t mean that you have to miss out. We’ll be live-streaming the keynote and all other talks on the Supercon main stage, so subscribe our YouTube channel and you won’t miss a thing.
“Hackaday has open-source running deep in our veins”
Articles under CC?
Good point.
Contact us with your needs.
When companies say “we love Open Source!” what they invariably mean is that they love using IP generated for free by other people, but sorry, their own IP has to be proprietary because business.
It is indeed truly awful, that restaurants can use linux systems for cash registers but they don’t have to publish their recipes. It’s also quite terrible you can’t get the answers to jeopardy ahead of time, how can they justify keeping such secrets when surely there must be some free software here somewhere.
C’mon N,
you know very well what we talk about…
keep your ridiculous false equivalences for yourself.
“Dr. Wachs, making her own wedding ring.”
Please tell me she embedded a RISC-V chip in the ring. (c:
I was sure the caption will be:
Dr. Wachs, making her own RISC-V chip.
And was like “didn’t know it’s such a physical work” ;)
Forgive my complete and total ignorance here, but how does sifive make money? I know I live in fairyland, but what incentive does SiFive have to not scoop up this design and eventually make proprietary? I’m not trying to be an ass the way I’m asking this, but I don’t want this CPU going the way of eagle PCB and everything else that was once great.
licensing IP and subcontracting work mostly. Not all their work are opensource now I think, albeit they contribute a lot to the risc-v opensource community.
This all works UNTIL the VC guys get greedy or the company gets bought.
I can’t wait to see this happen, to refresh people’s memories about the difference between Open and Free.
Yeah, people love to forget the bad things, anyway.
My understanding of this: The RISC-V ISA cannot ever become proprietary. It is maintained by a separate organization. SiFive just creates silicon implementations of the RISC-V ISA, starting from the open-source code or their own proprietary designs.
“We can all work together.”
Well… huh… the documents that describe how to contribute to the architecture are under NDA.
What and why do you think all those deep-pocketed sponsors pay for ?
Those deep-pocketed sponsors are well aware of the state of the Intel x86 CPU, so they are making alternatives possible.
So we agree that the promise of openness and unicorns is just wishful thinking ?
I’m a bit fed up with RISC-V.
It’s not a very interesting nor innovative instruction set, somewhat deliberately to allow students to implement a basic CPU in a semester, and maybe because they feared patents from ARM or others.
I hope that, instead of making hundreds of RISC-V implementations, open source developers will continue to implement other ISAs, such as the recently freed PowerPC, or old stuff like SuperH or VAX, or something really original…
It’s a bit sad that all that efforts around OSes and compilers is devoted to an architecture which isn’t very good.
Thanks, I was feeling lonely :-)
But RISC-V is not meant to be “good”.
Worse, it’s meant to be “rather good at everything” and as we know, you can’t be the best at everything, so just like other all-encompassing architectures (such as Intel’s infamous monopoly on desktops) it will shine only by the efforts on the physical implementation and industrial mastery.
It’s not bad either, it’s just… it feels it could be so much better !
It’s a pretty boring base instruction set, that’s for sure. I think the real innovation has to come from the extensions: for instance, the vector extensions look more interesting. Aside from that, you can say what you want about RiscV, bit I[d posit that e.g. PowerPC or MIPS wouldn’t be freed if it didn’t exist.
How would you improve RISC-V? As far as I can tell, it’s designed to make out-of-order implementations as simple as possible (which isn’t very simple!), and a lot of the useful things you could add (for instance, load+math opcodes) have to be broken down into multiple micro-ops in out-of-order implementations anyways, which limits the potential upsides (since you could just make the front-end wider instead of adding new opcodes, and you’d have the same result).
“How would you improve RISC-V?”
I wouldn’t since it’s not my goal. It’s Patterson’s baby, with his own agenda.
However I know of people who want to enhance it with vector operations and other things (at http://libre-riscv.org/ ) and they are being treated with, at best, contempt, if they are not in conflict with Patterson. I heard that there has been a trademark fight… So I treat RISC-V with precaution.
Concerning computer architecture, I have published most of my own design rules at https://hackaday.io/project/46000-pdp-processor-design-principles
Some more rules are being evaluated and I try to avoid OOO execution (though OOO completion is fine) so I come up with a different perspective, compared to RISC-V and many other cores.
For example, instead of trying to be “good at everything”, the CPU cores I design are matched to a given range of applications, just use another core if your application needs fewer or more data bits. My cores cover 8, 16-32 and 32-64 bits wide data, also increasing in complexity and opcode features. The larger cores can easily emulate the smaller ones with minimal circuit complexity because they are subsets of the larger ones (just translate/lookup the opcode and move some fields around).
It’s also different because I try to solve other problems than RISC-V… I’m looking beyond the “OOOe with load/store” paradigm that is more than 25 years old now. It works but we already see the limits.
(my last message is still awaiting moderation, probably because of a couple of links)
“How would you improve RISC-V?”
I wouldn’t since it’s not my goal. It’s Patterson’s baby, with his own agenda.
However I know of people who want to enhance it with vector operations and other things (see libre-riscv dot org) and they are being treated with, at best, contempt, if they are not in conflict with Patterson. I heard that there has been a trademark fight (lost by Patterson)… So I treat RISC-V with precaution.
Concerning computer architecture, I have published most of my own design rules on Hackaday io (project n° 46000 “PDP – Processor Design Principles” )
Some more rules are being evaluated and I try to avoid OOO execution (though OOO completion is fine) so I come up with a different perspective, compared to RISC-V and many other cores.
For example, instead of trying to be “good at everything”, the CPU cores I design are matched to a given range of applications, just use another core if your application needs fewer or more data bits. My cores cover 8, 16-32 and 32-64 bits wide data, also increasing in complexity and opcode features. The larger cores can easily emulate the smaller ones with minimal circuit complexity because they are subsets of the larger ones (just translate/lookup the opcode and move some fields around).
It’s also different because I try to solve other problems than RISC-V… I’m looking beyond the “OOOe with load/store” paradigm that is more than 25 years old now. It works but we already see the limits.
Next to what YGDES already said (RISC-V tends to be ‘rather good at everything’) there’s couple of things where RISC-V really shines:
1) As X86 has shown, we now know that for the modern big out-of-order processors, instruction set doesn’t matter very much. Yet it still matters at the lower end. Risc-v makes it easy to implement very efficient CPUs with minimum amount of transistors due to the fact that instruction set was designed in a way as to be able to build a register file with only two read ports. Yes, the tradeoff is that there are a few common operations that will need to be encoded into two instructions instead of one (which big CPUs will fuse into one anyway), but what you get is a really efficient and lean core for the bottom end (IOT, Arduinos, ESPs etc). It is also very power efficient.
2) Considering that most implementations will support the GC extensions, which includes simple compressed instructions, it has by far the densest 64-bit code density of all modern CPUs (X86-64 code density is rather big, whereas ARM doesn’t have any Thumb extension for 64-bit. It has been shown that the compressed ISA extension can be implemented with less than 1000 gates.
3) The Vector extension of RISC-V is on a completely new level.
4) Considering the implementation simplicity and transistors required… if you wish to become the next Nvidia competitor and build a 4096 core GPU with a generic instruction set (most of GPUs are in-order architectures to save power and space) and your job will be much easier with RISC-V than any other contemporary ISAs.
And regarding the “recently freed PowerPC”: the only instruction set that is more bloated than PowerPC is X86 (and not by much). RISC-V and PowerPC are on totally opposite ends of RISC ISAs.
1) You can build CPUs with single port RAM as registers, or more, this is a poor justification, except extreme simplicity for students. For example, in pipelined CPUs (particularly superscalar ones), you can sometimes trade register read ports with the pipeline bypass results, … many, many options.
2) So we have compressed instructions + op fusion = variable length instructions for complex operations. Great, you’ve re-invented CISC. ARM deliberately choose to have fixed size OPs but with rich semantics.
3) It’s a SIMD extension, many exists for many instruction sets. Doesnt’ change much to the base instruction set.
4) If you wish to become the next nVidia you’d better optimise your architecture, carefully analysing the software you want to run (raytracing, AI, shaders…) GPUs have avoided so far to need binary compatibility. So a RISC-V GPU is a nice toy, maybe usable for a variety of applications, but there is very little chance that it can be used for best in class GPUs (and due to economy of volume, the higher demand, GPUs and sometimes cryptocurrencies, next AI will dictate the architecture, yielding instruction sets and cache hierarchy quite different than general purpose CPUs)
5) Probably PowerPC wouldn’t be free without RISC-V, but the base architecture is old enough to allow free implementations, a PowerMAC would be doable in an FPGA. The PowerPC instruction set isn’t really bloated, it’s just that there are variants of many instructions (about condition codes), but it doesn’t really makes the decoder far more complex.
Nobody looks at the x86 as a great design, but it’s still interesting. By chance, there are a few details which makes it unexpectitly efficient (for example it is a CISC but 99% of the instructions executed can be easiliy pipelined, only the first 2-3 bytes need to be parsed to determine length of most instructions (contrary to VAX),…).
A bit like RISC-V has addressed the worst defects of SPARC and MIPS (delayed branches, register windows…), I wish there would be a new CISC ISA, some kind of MC68K with fewer addressing modes, no condition codes updates on moves,…
Thanks TREZA,
I was feeling too lazy to make such a detailed reply.
are you longing for a CRISC architecture ? :-D
BTW Coldfire could be what you’re looking for.
Who cares about source this and acronym that the Dr made her own wedding ring.That”s cool.
Any link to the keynote? Can’t find it on the Hackaday YouTube channel.
Hopefully _work in progress_ as there were more talks as there now videos publish.
Let see what happens in the next few days. Meanwhile think about where report _hey, I do miss some videos from the HaD superconference_.