8 ms·

LowRISC: Open-source RISC-V SoC

135 points by br0ke 12y ago

alain94040 12y ago
Volume silicon manufacture is planned I highly doubt it. But if it's true, that would be the missing link for all open source hardware design. It would also be nice if they gave some idea of the kind of performance or implementation they are considering.
- wmf 12y ago
  People are making volumes of Bitcoin ASICs for surprisingly small amounts of money, so it is possible. The question in my mind is who's going to be buying volume quantities of this chip and why.
  - higherpurpose 12y ago
    A company like Silent Circle/Blackphone could buy a million or two in the future. Maybe some Raspberry Pi competitors, too.
    - jondtaylor 12y ago
      One of the team members was a co founder of the Raspberry pi.
- jontaylor 12y ago
  So you would say this isn't a low risc proposition?
cottonseed 12y ago
I'm not familiar with the IP issues. Would it be possible to center open-source processor development around the ARM instruction set? It looks like the privileged part of the RISC-V ISA is not finished yet. This is a great project, but it seems a long way off.
- wmf 12y ago
  Historically, ARM really, really did not like unlicensed or open-source ARM processors. But times change, so I wouldn't be surprised to see them take some easy PR from openwashing at some point.
  - higherpurpose 12y ago
    That seems highly unlikely - unless we're talking about 3rd generation behind the latest tech chips. I could see them open source say the ARMv6 architecture in 3+ years, when ARMv8 has already taken off, and ARMv7 is in legacy mode. But meh.
    - sitkack 12y ago
      ARM would very aggressively go after any open source implementation of the ARM ISA. For the longest time you couldn't find any ARM documentation on the net because it was all behind a license agreement that read, "won't be used to make an open source version of our schwag"
- makomk 12y ago
  I'm surprised they don't just use OpenRISC, there's already hardware shipping that uses ASIC implementations of that internally.
  - mjn 12y ago
    They discuss their reasoning briefly in the manual [1, p. 3]: We are far from the first to contemplate an open ISA design suitable for hardware implementation. We also considered other existing open ISA designs, of which the closest to our goals was the OpenRISC architecture. We decided against adopting the OpenRISC ISA for several technical reasons: -- OpenRISC has condition codes and branch delay slots, which complicate higher performance implementations. -- OpenRISC uses a fixed 32-bit encoding and 16-bit immediates, which precludes a denser instruction encoding and limits space for later expansion of the ISA. -- OpenRISC does not support the 2008 revision to the IEEE 754 floating-point standard. -- The OpenRISC 64-bit design had not been completed when we began. [1] http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.html http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54...
cjdrake 12y ago
That hardware implementation of RISC-V listed on their website is written in Scala (using Chisel). That's very cool. I want to see synthesis results.
- billylindeman 12y ago
  wow. yeah i totally missed this the first time i skimmed this. Very Cool.
- _chris_ 12y ago
  Hi, are you talking about the Sodor cores? I wrote those and wouldn't mind answering any questions about RISC-V or Chisel. Regarding Sodor, they're designed to be instructional (we use them on our undergrads at Berkeley) and open for anybody with a C++ compiler so they can learn about Chisel and RISC-V. I pushed them through synthesis once just for kicks, but I didn't work on making them FPGA-ready. Chisel will give you the Verilog of the core, but you'd still need to write a test-harness that's specific to your FPGA. The RISC-V user manual lists some of our existing RISC-V silicon implementations (8 so far, listed in Section 19.2), whose RTL aren't (yet) open-source.
  - trsohmers 12y ago
    Hey, I've been interested in RISC-V and Chisel, and am a bay area local (Live in Oakland)... what is the best way to get in contact with you and others at UCB?
    - _chris_ 12y ago
      Hmmm, I actually have no idea! Chisel has a google group that you can post any comments or questions you have (chisel.eecs.berkeley.edu). If you wait a week, we should have something similar up at (riscv.org) too. Chisel has an occasional "boot-camp" where you can come and learn how to use it, and RISC-V will have something similar too I believe in January.
  - cjdrake 12y ago
    Yes, that's what I was talking about. Dave Patterson was giving a talk in Portland about three years ago on heterogeneous computing, and he mentioned Chisel. And now it seems to be relatively mature. I am happy to see innovation in both the HDL and uArch space.
ajross 12y ago
Hm... the link only talks about the CPU, but calls itself a SoC. There's a lot more than needs to go on any chip that calls itself a "SoC", and much of it is very poorly served by existing "open source" solutions: + DRAM + I2C + GPIO (with stuff like 3.3v, tristate outputs, pull up/down, etc...) + USB2 host/device + SD/MMC And that's just at the very basic level. Once you get into the consumer world you need to start talking about video output, camera input, video decode and encode acceleration, programmable GPUs,... Really the CPU is, in some sense, the most solved problem from the perspective of open source. The designs themselves may be closed IP, but the instruction sets are meticulously documented and their behavior is very standard across many vendors and ISAs.
- nullc 12y ago
  Greetings. I use some of those aforementioned very standard CPUs and have an issue: Many tasks I use the computer for are far more security critical than performance critical I would like have someone augment a cpu design that I'm using to give it 256 bit 'pointers' which pack 64 bit start, end, and offset, and a set of fine grained permissions and special privileged instructions for modifying these pointers. This way huge classes of security vulnerabilities will be prevented by the hardware. I won't mind if it's 10x slower— though the thousands of times slower that I'd get with a software simulation would likely be too slow to be practical. What? You say that the chips I currently used have closed and secret designs and are not available for modification? But I thought you said that the CPU is the most solved problem from the perspective of open source?? I guess it's good that people are working on actually open CPUs so that things like http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ can be built.
  - delinka 12y ago
    And with an "actually open CPU," how does one verify that the silicon in the final package is actually what's in the design and that no "closed and secret designs" have been added by the fabricator?
    - 12y ago
userbinator 12y ago
RISC-V looks like MIPS but with some of the more dubious design decisions of the time (e.g. branch delay slots) fixed. The mix of 16-bit and 32-bit instruction lengths is reminiscent of ARC. In other words, the characteristics of SoCs using this core will likely be very similar to the many out there using MIPS: cheap and simple, with performance that's acceptable for applications like routers and other embedded devices.
- sitkack 12y ago
  I would attempt a nibble based compact instruction representation to reduce external memory bandwidth. Fixed width instructions kinda suck now that memory is such a bottleneck.
  - TheLoneWolfling 12y ago
    I've long wished of a middle ground between FPGAs and CPUs - namely a CPU with user-changable instructions. Have a CPU that is a CISC (but internally a microcoded TTA), but with a large chunk of the microcode user-writable (So you have push-inst and pop-inst, where push-inst pushes the new instruction microcode into the microcode storage and copies the old instruction microcode onto the stack and pop-inst does the opposite). It keeps the advantages of fixed-width instructions while, depending on how the microcode is encoded, potentially having significant memory savings.
    - sitkack 12y ago
      JITs could synth new instructions.
    - rst 12y ago
      The arc processor line from Synopsys does this commercially, I believe. Risc-v seems to be trying to support this sort of thing; there is reserved opcode space for implementation specific extensions
      - TheLoneWolfling 12y ago
CHY872 12y ago
I've spent some time with Robert Mullins and he is an absolutely stand-up guy. It was a pleasure to be taught by him.
FullyFunctional 12y ago
(Disclaimer: I'm developing my own RV64 FPGA implementation.) I wish the page was a little more clear on what the intentions are, etc, but seeing RV64 in silicon would be immensely exciting. Producing a simple in-order machine, even with usual set of peripherals isn't very hard at all and nor that expensive on an older process node, but there's a world of difference if we start talking superscalar out-of-order multi-core SMP. Seeing OpenRISC on the Advisory Board I suspect it's more the former than the latter.

135 points by br0ke 12y ago

Volume silicon manufacture is planned I highly doubt it. But if it's true, that would be the missing link for all open source hardware design. It would also be nice if they gave some idea of the kind of performance or implementation they are considering.

wmf 12y ago
People are making volumes of Bitcoin ASICs for surprisingly small amounts of money, so it is possible. The question in my mind is who's going to be buying volume quantities of this chip and why.
- higherpurpose 12y ago
  A company like Silent Circle/Blackphone could buy a million or two in the future. Maybe some Raspberry Pi competitors, too.
  - jondtaylor 12y ago
    One of the team members was a co founder of the Raspberry pi.
jontaylor 12y ago
So you would say this isn't a low risc proposition?

cottonseed 12y ago

I'm not familiar with the IP issues. Would it be possible to center open-source processor development around the ARM instruction set? It looks like the privileged part of the RISC-V ISA is not finished yet. This is a great project, but it seems a long way off.

wmf 12y ago
Historically, ARM really, really did not like unlicensed or open-source ARM processors. But times change, so I wouldn't be surprised to see them take some easy PR from openwashing at some point.
- higherpurpose 12y ago
  That seems highly unlikely - unless we're talking about 3rd generation behind the latest tech chips. I could see them open source say the ARMv6 architecture in 3+ years, when ARMv8 has already taken off, and ARMv7 is in legacy mode. But meh.
  - sitkack 12y ago
    ARM would very aggressively go after any open source implementation of the ARM ISA. For the longest time you couldn't find any ARM documentation on the net because it was all behind a license agreement that read, "won't be used to make an open source version of our schwag"
makomk 12y ago
I'm surprised they don't just use OpenRISC, there's already hardware shipping that uses ASIC implementations of that internally.
- mjn 12y ago
  They discuss their reasoning briefly in the manual [1, p. 3]: We are far from the first to contemplate an open ISA design suitable for hardware implementation. We also considered other existing open ISA designs, of which the closest to our goals was the OpenRISC architecture. We decided against adopting the OpenRISC ISA for several technical reasons: -- OpenRISC has condition codes and branch delay slots, which complicate higher performance implementations. -- OpenRISC uses a fixed 32-bit encoding and 16-bit immediates, which precludes a denser instruction encoding and limits space for later expansion of the ISA. -- OpenRISC does not support the 2008 revision to the IEEE 754 floating-point standard. -- The OpenRISC 64-bit design had not been completed when we began. [1] http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.html http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54...

cjdrake 12y ago

That hardware implementation of RISC-V listed on their website is written in Scala (using Chisel). That's very cool. I want to see synthesis results.

billylindeman 12y ago
wow. yeah i totally missed this the first time i skimmed this. Very Cool.
_chris_ 12y ago
Hi, are you talking about the Sodor cores? I wrote those and wouldn't mind answering any questions about RISC-V or Chisel. Regarding Sodor, they're designed to be instructional (we use them on our undergrads at Berkeley) and open for anybody with a C++ compiler so they can learn about Chisel and RISC-V. I pushed them through synthesis once just for kicks, but I didn't work on making them FPGA-ready. Chisel will give you the Verilog of the core, but you'd still need to write a test-harness that's specific to your FPGA. The RISC-V user manual lists some of our existing RISC-V silicon implementations (8 so far, listed in Section 19.2), whose RTL aren't (yet) open-source.
- trsohmers 12y ago
  Hey, I've been interested in RISC-V and Chisel, and am a bay area local (Live in Oakland)... what is the best way to get in contact with you and others at UCB?
  - _chris_ 12y ago
    Hmmm, I actually have no idea! Chisel has a google group that you can post any comments or questions you have (chisel.eecs.berkeley.edu). If you wait a week, we should have something similar up at (riscv.org) too. Chisel has an occasional "boot-camp" where you can come and learn how to use it, and RISC-V will have something similar too I believe in January.
- cjdrake 12y ago
  Yes, that's what I was talking about. Dave Patterson was giving a talk in Portland about three years ago on heterogeneous computing, and he mentioned Chisel. And now it seems to be relatively mature. I am happy to see innovation in both the HDL and uArch space.

ajross 12y ago

Hm... the link only talks about the CPU, but calls itself a SoC. There's a lot more than needs to go on any chip that calls itself a "SoC", and much of it is very poorly served by existing "open source" solutions: + DRAM + I2C + GPIO (with stuff like 3.3v, tristate outputs, pull up/down, etc...) + USB2 host/device + SD/MMC And that's just at the very basic level. Once you get into the consumer world you need to start talking about video output, camera input, video decode and encode acceleration, programmable GPUs,... Really the CPU is, in some sense, the most solved problem from the perspective of open source. The designs themselves may be closed IP, but the instruction sets are meticulously documented and their behavior is very standard across many vendors and ISAs.

nullc 12y ago
Greetings. I use some of those aforementioned very standard CPUs and have an issue: Many tasks I use the computer for are far more security critical than performance critical I would like have someone augment a cpu design that I'm using to give it 256 bit 'pointers' which pack 64 bit start, end, and offset, and a set of fine grained permissions and special privileged instructions for modifying these pointers. This way huge classes of security vulnerabilities will be prevented by the hardware. I won't mind if it's 10x slower— though the thousands of times slower that I'd get with a software simulation would likely be too slow to be practical. What? You say that the chips I currently used have closed and secret designs and are not available for modification? But I thought you said that the CPU is the most solved problem from the perspective of open source?? I guess it's good that people are working on actually open CPUs so that things like http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ can be built.
- delinka 12y ago
  And with an "actually open CPU," how does one verify that the silicon in the final package is actually what's in the design and that no "closed and secret designs" have been added by the fabricator?
  - 12y ago

userbinator 12y ago

RISC-V looks like MIPS but with some of the more dubious design decisions of the time (e.g. branch delay slots) fixed. The mix of 16-bit and 32-bit instruction lengths is reminiscent of ARC. In other words, the characteristics of SoCs using this core will likely be very similar to the many out there using MIPS: cheap and simple, with performance that's acceptable for applications like routers and other embedded devices.

sitkack 12y ago
I would attempt a nibble based compact instruction representation to reduce external memory bandwidth. Fixed width instructions kinda suck now that memory is such a bottleneck.
- TheLoneWolfling 12y ago
  I've long wished of a middle ground between FPGAs and CPUs - namely a CPU with user-changable instructions. Have a CPU that is a CISC (but internally a microcoded TTA), but with a large chunk of the microcode user-writable (So you have push-inst and pop-inst, where push-inst pushes the new instruction microcode into the microcode storage and copies the old instruction microcode onto the stack and pop-inst does the opposite). It keeps the advantages of fixed-width instructions while, depending on how the microcode is encoded, potentially having significant memory savings.
  - sitkack 12y ago
    JITs could synth new instructions.
  - rst 12y ago
    The arc processor line from Synopsys does this commercially, I believe. Risc-v seems to be trying to support this sort of thing; there is reserved opcode space for implementation specific extensions
    - TheLoneWolfling 12y ago

CHY872 12y ago

I've spent some time with Robert Mullins and he is an absolutely stand-up guy. It was a pleasure to be taught by him.

FullyFunctional 12y ago

(Disclaimer: I'm developing my own RV64 FPGA implementation.) I wish the page was a little more clear on what the intentions are, etc, but seeing RV64 in silicon would be immensely exciting. Producing a simple in-order machine, even with usual set of peripherals isn't very hard at all and nor that expensive on an older process node, but there's a world of difference if we start talking superscalar out-of-order multi-core SMP. Seeing OpenRISC on the Advisory Board I suspect it's more the former than the latter.