7 ms·
Hi, I'm a Ph.D. student at UC Berkeley on the RISC-V team. Happy to answer any questions about the RISC-V ISA or Rocket, our open-source reference implementatio
by zhemao 11y ago
Hi, I'm a Ph.D. student at UC Berkeley on the RISC-V team. Happy to answer any questions about the RISC-V ISA or Rocket, our open-source reference implementation.
Since there's always confusion about it, I'll start off by clarifying the difference between the two. RISC-V is an open-source ISA standard. Rocket is an implementation of this ISA which also happens to be open source. We do not intend for the ISA to be tied to a single reference implementation. The intention for RISC-V is to enable many different implementations (whether open-source or proprietary). These different implementations can all run an open-source software ecosystem, which currently consists of a GNU toolchain, LLVM, and Linux kernel port.
- 1ris 11y agoGreat! I heard somewhere here on HN that a modern x86 decoder is smaller than a modern arm decoder. Do you know if this is true? Also, how big is the decoder of risc-v and does it even matter? (I mean the size)
- zhemao 11y ago> a modern x86 decoder is smaller than a modern arm decoder That's because the ARM ISA is not small either by any stretch of the imagination. On the other hand, the instruction listing of the base RISC-V ISA and the standard extensions can fit on a single powerpoint slide. http://riscv.org/workshop-jun2015/riscv-intro-workshop-june2015.pdf http://riscv.org/workshop-jun2015/riscv-intro-workshop-june2... I wasn't involved in any of the recent tape-outs, so I can't say exactly how big the decoder is. But it's quite small relative to the other chip components. Currently, the integer pipeline of the chip is roughly the same size as the FPU, and these two together are roughly the same size as the L1 cache. All of those components together are smaller than the L2 cache (depends on the size of the L2 cache, though). So decoder size doesn't really matter in the grand scheme of things. Decoder speed probably does matter, though. Currently, we can decode an instruction in a single cycle (1 ns). The x86 decoder, on the other hand, can take multiple cycles depending on instruction. But maybe this isn't a fair comparison since the instructions are decomposed into uops. I have no idea about the performance of ARM decoders.
- wolf550e 11y agoHow can you be multiscalar with a decoder that only does 1 ops/cycle? Intel does 6: > From the original Core 2 through Haswell/Broadwell, Intel has used a four-wide front-end for fetching instructions. Skylake is the first change to this aspect in roughly a decade, with the ability to now fetch up to six micro-ops per cycle. Intel doesn’t indicate how many execution units are available in Skylake’s back-end, but we know everything from Core 2 through Sandy Bridge had six execution units while Haswell has eight execution ports. We can assume Skylake is now more than eight, and likely the ability to dispatch more micro-ops as well, but Intel didn’t provide any specifics. http://www.maximumpc.com/idf-2015-san-francisco-skylake-deep-dive/ http://www.maximumpc.com/idf-2015-san-francisco-skylake-deep...
- luismarques 11y agoI think he meant that the decoding latency is 1 cycle, not that per 1 cycle the core can only decode one instruction. That is, each baby takes 9 cycles to form, but per 9 cycles the population can have more than one baby.
- Symmetry 11y agoHe was talking about latency, you're talking about throughput.
- Symmetry 11y agoIs that for a decoder that can decode multiple instructions per clock cycle? I think it would be somewhat interesting for a single instruction decoder but it would be quite remarkable for a decoder of greater width since x86 instructions aren't even self synchronizing (you can read the same sequence of bytes in different valid ways depending on where you start) while ARM is fixed width.
- FullyFunctional 11y agoThere are two, Berkeley's BOOM and another from Macaque Labs in India (SHAKTI OO core).
- Symmetry 11y agoThose don't seem to be tiny x86 decoders, as far as I can tell.
- deleted 11y ago[deleted]
- orionblastar 11y agoWhat operating systems have been ported to RISC-V so far? I would assume GNU/Linux, Android, Solaris because of the companies involved. Am I correct?
- privong 11y agoThe article says: > Currently RISC-V runs Linux and NetBSD, but not Android, Windows or any major embedded RTOSes. Support for other operating systems is expected in 2016. No mention of Solaris, so I assume that would be forthcoming?
- heshamelmatary 11y agoThere are initial/working ports of RTEMS (as an RTOS) as well as seL4 microkernel. http://heshamelmatary.blogspot.co.uk/2015/12/rtems-port-for-risc-v-withwithout-sel4.html http://heshamelmatary.blogspot.co.uk/2015/12/rtems-port-for-...
- justin66 11y agoIf anyone has a RISC-V processor that will run Solaris, let alone a port of Solaris, they haven't announced it. It really would be interesting to know why Oracle got involved, though, since their involvement is not the universal sign of pending success for an open source project.
- richardwhiuk 11y agoTo be a cynic, one of the best ways to kill a project is to get involved and make a mess from the inside.
- rodgerd 11y agoThat would be my bet.
- BogusIKnow 11y agoWasn't that in the CIA operations manual that surfaced some time ago? https://news.ycombinator.com/item?id=4831363 https://news.ycombinator.com/item?id=4831363
- rwmj 11y agoIn reality, how far are you from having silicon?
- zhemao 11y agoWe have taped out several chips for our own research. But as a university research lab, we do not have any plans for a commercial manufacturing run. The lowRISC team can say more about the roadmap to a commercial dev board.
- _chris_ 11y agoBerkeley has done 11+ tape-outs of RISC-V chips. LowRISC is looking to do a silicon run in a year-ish, and there's already one company that's publicly stated they've already been shipping RISC-V cores in their cameras.
- jychang 11y ago> RISC-V cores in their cameras Got a source on that?
- _chris_ 11y agoI've talked with them in person at the RISC-V workshops. But for better proof, Slide 35: http://riscv.org/workshop-jun2015/riscv-intro-workshop-june2015.pdf http://riscv.org/workshop-jun2015/riscv-intro-workshop-june2...
- legulere 11y agoThe GNU toolchain, LLVM and Linux port seem not to be mainlined yet. Is there a plan when patches will get submitted for inclusion?
- _chris_ 11y agoIt's a work-in-progress. But yes, expect it to happen Sometime (tm).
- FullyFunctional 11y agoYes, this is actively being worked on, see the mailing list archives.
- Natsu 11y agoWhen can we expect to see the license terms? This claims that "The terms will specify a zero-royalty RAND license as well as verification suites licensees must run to use the RISC-V logo" but it appears that free (libre) implementations might not be permissible.
- _chris_ 11y agoRISC-V is a standard. Anybody can implement a CPU with the standard and then do whatever they want with that CPU. There are plenty of open-sourced RISCV cores already. Copyleft vs copyright is only an issue regarding how much of the extra "libraries"/layouts/foundry tooling has to be made available too. Of course, somebody is also FREE to implement something that's "totally not RISC-V", and call it whatever they want. They can change one tiny thing or even nothing. The major win here is: a) if somebody WANTS to call their thing "RISC-V compatible", it must implement the same core ISA instruction set as everybody else and b) all of these companies are pooling their resources regarding lawsuits or patent fights against the core ISA.
- rsync 11y agoHello Zhemao, I live in the SFBA. Is it possible to come to Berkeley and see the reference implementation running ? Nothing special - I would just be fascinated to see something like this in person.
- zhemao 11y agoUm, it depends on what exactly you mean by "reference implementation" or "running". If you mean one of the silicon test chips, that might be hard to swing. I don't have them at my desk and they take a lot of setup to actually use (a setup process which I am unfamiliar with). I'd have to ask the grad student who worked on the bring-up to help me. But if you'd be satisfied with seeing the reference RTL run on an FPGA, that would certainly be possible.
- FullyFunctional 11y agoOr just run it yourself. I brought up Rocket on a Zedboard following the instructions. Rocket isn't ideal if your ultimate target is an FPGA, but IIRC it's currently the only that includes the virtual memory support that is needed to boot Linux.
- zhemao 11y agoBOOM also has virtual memory support. But yes, if you have a Zedboard, you can run the reference RTL yourself. Of course, those things are pretty costly, so I understand if you'd like to see someone else do it.
- FullyFunctional 11y agoI'd add to that that there are already more implementations than I can count. Rocket isn't the only ASIC game in town, and there are countless soft-cores (FPGA implementations).
- jeffdavis 11y agoDoes RISCV also specify privileged instructions? Or only the instructions an application would use?
- _chris_ 11y agoA privileged spec is available, although it's not frozen yet. A Linux port already exists.