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.
The peripherals you list span a wide range of complexity.
GPIO, I2C, and SD interfaces (in approximately increasing order of complexity from my point of view) are one-person jobs for the right person. I've been in charge of all the GPIO for complex mixed-signal chips several times in the past, and I could crank these out in no time. But someone who's never designed for ESD and latchup, beyond-the-rail inputs, etc., would probably find these pretty nasty.
Forget using fab-supplied GPIO; those designs are almost always much (3-5x or more) larger than they need to be, and in advanced nodes, they tend to add additional processing cost. Specifically, most fabs want to stick with per-pad snapback clamps, which are (1) big and (2) require (in processes newer than about 0.13u; you can get away without it in earlier nodes) an additional "ESD" layer to fix doping gradients so that the devices don't destroy themselves as soon as they snap back. A much better solution, for many reasons, is transient rail clamps and steering diodes. First, because diodes can handle insane amounts of current per micron of perimeter (think: easily 50 mA / um of perimeter for a diode, vs single digit mA / um for snapback devices), their layouts are more compact, and they don't require ballasting to prevent current crowding. Second, and more importantly, clamps and diodes can be simulated (and the simulations, if not correct, are at least predictable in the way they fail depending on the models the fab gives you). Snapback is effectively voodoo: design what looks like it should work, test it, and hope that some circuit you accidentally put too close to the pad doesn't change the behavior enough to cause failures.
DRAM controllers are another step up in complexity. Depending what standard you're going after, this is going to take some reasonable work.
USB2 is, in a word, hideous. A team starting fresh is looking at several person-years (or more) for a well-designed physical interface, control logic, etc.
One wonders if they can convince someone to donate designs. Come to think of it, I'd do their GPIO/ESD/latchup design for them just for the fun of it; my current employer certainly wouldn't object.
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??
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.
That raises an interesting point -- the original MIPS ISA hasn't been patent encumbered in quite a while (and even then, only two non-essential instructions were patent protected). Why should a person is this unknown ISA instead of MIPS?
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.
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.
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.
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.
If I remember correctly, the last time I checked 586-level x86 was fully open and some of the P6 patents were close to expiring, so it might make another contender for an open-source CPU. Since Intel and AMD don't license x86 soft-cores unlike ARM and MIPS (which RISC-V is similar to), I think there could be fewer legal issues. Compatibility is another bonus; it's possible to put an entire PC-compatible on a single chip: http://www.vortex86.com/dx
(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.
[+] [-] ajross|11 years ago|reply
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.
[+] [-] kwantam|11 years ago|reply
GPIO, I2C, and SD interfaces (in approximately increasing order of complexity from my point of view) are one-person jobs for the right person. I've been in charge of all the GPIO for complex mixed-signal chips several times in the past, and I could crank these out in no time. But someone who's never designed for ESD and latchup, beyond-the-rail inputs, etc., would probably find these pretty nasty.
Forget using fab-supplied GPIO; those designs are almost always much (3-5x or more) larger than they need to be, and in advanced nodes, they tend to add additional processing cost. Specifically, most fabs want to stick with per-pad snapback clamps, which are (1) big and (2) require (in processes newer than about 0.13u; you can get away without it in earlier nodes) an additional "ESD" layer to fix doping gradients so that the devices don't destroy themselves as soon as they snap back. A much better solution, for many reasons, is transient rail clamps and steering diodes. First, because diodes can handle insane amounts of current per micron of perimeter (think: easily 50 mA / um of perimeter for a diode, vs single digit mA / um for snapback devices), their layouts are more compact, and they don't require ballasting to prevent current crowding. Second, and more importantly, clamps and diodes can be simulated (and the simulations, if not correct, are at least predictable in the way they fail depending on the models the fab gives you). Snapback is effectively voodoo: design what looks like it should work, test it, and hope that some circuit you accidentally put too close to the pad doesn't change the behavior enough to cause failures.
DRAM controllers are another step up in complexity. Depending what standard you're going after, this is going to take some reasonable work.
USB2 is, in a word, hideous. A team starting fresh is looking at several person-years (or more) for a well-designed physical interface, control logic, etc.
One wonders if they can convince someone to donate designs. Come to think of it, I'd do their GPIO/ESD/latchup design for them just for the fun of it; my current employer certainly wouldn't object.
[+] [-] nullc|11 years ago|reply
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/ can be built.
[+] [-] userbinator|11 years ago|reply
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.
[+] [-] hajile|11 years ago|reply
[+] [-] renox|11 years ago|reply
MIPS has also MIPS16..
[+] [-] sitkack|11 years ago|reply
[+] [-] cjdrake|11 years ago|reply
[+] [-] _chris_|11 years ago|reply
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.
[+] [-] billylindeman|11 years ago|reply
[+] [-] alain94040|11 years ago|reply
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|11 years ago|reply
[+] [-] jontaylor|11 years ago|reply
[+] [-] cottonseed|11 years ago|reply
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.
[+] [-] makomk|11 years ago|reply
[+] [-] wmf|11 years ago|reply
[+] [-] userbinator|11 years ago|reply
[+] [-] FullyFunctional|11 years ago|reply
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.
[+] [-] CHY872|11 years ago|reply