13 ms·

RISC-V: What’s Missing and Who’s Competing

186 points by SemiTom 6y ago

azhenley 6y ago
I’ve had a lot of fun learning RISC-V assembly off and on over the last year. I went through a colleague of mine’s tutorial series on implementing an operating system targeting RISC-V using Rust. Now I’m working on my own small assembler for RISC-V. It’s been so much more fun to learn than x86! Edit: link to the tutorial (http://osblog.stephenmarz.com/ http://osblog.stephenmarz.com/)
- faitswulff 6y ago
  Is this the tutorial you mentioned? EDIT - ah nevermind, turns out there are at least two RISC-V OS tutorials in Rust: - https://gist.github.com/cb372/5f6bf16ca0682541260ae52fc11ea3bb https://gist.github.com/cb372/5f6bf16ca0682541260ae52fc11ea3... - http://osblog.stephenmarz.com/ http://osblog.stephenmarz.com/
  - azhenley 6y ago
    The second one! Sorry, I meant to include it. I updated my comment.
- msla 6y ago
  To me, a fun ISA is one which provides opportunities for golf, which basically means CISC ISAs with lots of different ways to do things. RISC-V is proudly, definitively not that and that's a good design decision, but you'll never be able to replace a stretch of straightforward code with a handful of more obscure opcodes and complicated addressing modes. I'll always have SIMH.
  - garmaine 6y ago
    Yeah that’s a bit like saying you enjoy spelling bees, whereas a language that is idiomatic enough to allow for competitive spelling to exist as a real thing has fundamentally failed at its job.
    - msla 6y ago
      Orthography is orthogonal to a language, as transliteration proves. Putonghua is Putonghua regardless of whether it's written in Sinitic characters, Yale Romanization, or Pinyin. Also, don't run down someone else's hobbies. It's uncouth.
      - garmaine 6y ago
        I’m not..? It’s fine to play code golf with CISC-y architectures. But being able to do that is an anti-goal to a compiler-friendly architecture, as RISC tries to be.
  - tux3 6y ago
    The base ISA is very plain and RISCy. But I'd encourage you to go read the Bitmanip extension and find an opcode in there that doesn't have at least one obscure alternate use! =) As for addressing modes, yeah I do wish we had a little bit more as a software person (but not as a hobby/toy cpu writer!). The current stuff can encode a surprising number of simple loops efficiently if you do it right, but of course if you come from x86 you'll have to do more with less...
    - Taniwha 6y ago
      Essentially it wouldn't be RISC is there were more complex addressing modes (if you can't do it in one clock at speed .....)
      - msla 6y ago
        Complex addressing modes are un-RISCy because they're harder to pipeline: Memory accesses might result in page faults, and if you have complicated addressing modes, all of a sudden you have some nontrivial ALU state to back out before you can handle the fault. It's a lot simpler to have rock-dumb load/store opcodes and then do all ALU work in terms of register-register opcodes which don't touch memory. John Mashey (helped design the MIPS architecture) has a great account of how complex addressing modes are difficult to work with partway down this page: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html I can't link to it directly, but it starts with this text: > General comment: this may sound weird, but in the long term, it might be easier to deal with a really complicated bunch of instruction formats, than with a complex set of addressing modes, because at least the former is more amenable to pre-decoding into a cache of decoded instructions that can be pipelined reasonably, whereas the pipeline on the latter can get very tricky (examples to follow). This can lead to the funny effect that a relatively "clean", orthogonal archiecture may actually be harder to make run fast than one that is less clean. Obviously, every weirdness has it's penalties.... But consider the fundamental difficulty of pipelining something like (on a VAX): ADDL @(R1)+,@(R1)+,@(R2)+ > (I.e., something that, might theoretically arise from: register **r1, **r2; **r2++ = **r1++ + **r1++; ... and he then goes on a detailed step-by-step process of what has to happen to execute that opcode in the world of page faults and unaligned memory accesses, another thing classic RISC chips were very down on, but I think they've gotten a bit looser on them in recent decades.
  - zozbot234 6y ago
    > but you'll never be able to replace a stretch of straightforward code with a handful of more obscure opcodes and complicated addressing modes. It just changes the target for a (human or computer) superoptimizer. Instead of using weird CISCy instructions, you're optimizing things like register allocation and the binary 'interfaces' between parts of your code. At a slightly higher level than a single insn, assembly coding is always about having "lots of different ways to do things"!
  - rwmj 6y ago
    Sort of. The fun optimizations are a little different now: Can you choose your registers so you can make maximum use of Compressed instructions? And for higher performance chips, can you select sequences of instructions that trigger macro-op fusion?
- pjmlp 6y ago
  I grew up with Z80, back in the day when business applications had enough Assembly into them. Used 68000 and all x86 variants until Pentium (by then it was too much effort to write Assembly by hand), also had to deal with MIPS, PowerPC, SPARC, ARM and various bytecode formats. X86 remains my favourite, in tooling and high level opcodes with cool tricks.
  - rwmj 6y ago
    Really? Z80 and even moreso 68000 had lovely orthogonal assembly languages which were a pleasure to program in.
    - pjmlp 6y ago
      Yes really, I never got the point of that, specially given the weaker addressing modes. Actually the only thing that pissed me off, but was sorted out with 386 anyway, was the segmented memory.
- fwsgonzo 6y ago
  Is there a std-variant for rv64g? And if not, how easy is it to setup for rv64gc? I have an emulator with a known rv64gc bug, and it's faster to emulate uncompressed instructions (until I start translating them, I guess). Also, what language is the assembler written in? Is it embeddable?
TimSchumann 6y ago
I actually just ordered a HiFive1 Rev B to play around with. Kinda excited for the potential of RISC-V, we'll see how much wind this article takes out of my sails. Thanks for sharing it.
01100011 6y ago
Does anyone know how well RISC-V will be able to compete with ARM in the higher end? It seems pretty easy to come up with a processor design that is competitive in low-compute load applications, but what about more advanced designs? I'm curious what it is that ARM brings to the table there and if there is a chance that RISC-V will ever offer serious competition. Certainly RISC-V does not need to be the best to survive as a viable option for most designs. It may absorb a lot of market share from ARM in the long run. It will be interesting to see how it develops.
- TimSchumann 6y ago
  I'd say that depends on the higher end of what? Control over the firmware, understanding of the actual bits you're flipping and the architecture, power consumption, or raw computer per clock?
  - mastazi 6y ago
    I’m not parent but personally I’m interested in performance per Watt
    - ljhsiung 6y ago
      The ISA design has very little impact on actual energy consumption rather than an actual CPU's uArch. This is a conception that hasn't been true for at least 20 years. It was somewhat true in the days where memory was expensive, and so smaller instructions were a good idea. But this came at the cost of increased area and thus energy (since you need more decoding logic). As time went on, transistors shrank, so this cost kept decreasing; at the same time, memory got better and we developed techniques to hide the latency more, so the upside also kept decreasing. Ultimately in modern times any difference in ISA results in some ~1% difference in energy consumption. You would gain far more efficiency (on the order of 2.5x) in just designing your uArch in a better way-- say, in-order vs OoO. [1] In my opinion, the reason CISC vs. RISC is still very alive today is because ARM has done a fabulous job in marketing and executing itself as energy efficient. The big.Little architectures are an example in cementing this idea. Conversely, Intel has done a similarly fabulous job in marketing and executing itself as performant, allowing both companies to live happily in their respective areas. The introduction of hyperthreading is another example of pushing this edge. But these design decisions are NOT ISA intrinsic, and these misconceptions are changing incredibly fast (though I think ARM is doing a much better job than Intel at changing these paradigms). [1] https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-struggles.pdf https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa...
ape4 6y ago
No integer overflow instruction I read on Hacker News the other day.
- dbcurtis 6y ago
  What does that even mean? It has an integer add instruction, surely, and integer add can overflow. Do you mean you get no exception? or no status flag to check?
  - sgtnoodle 6y ago
    I vaguely recall risc-v having no status flags, instead preferring explicit instructions to check for such things. The idea is that, instead of implicitly paying for the checks on every operation whether or not you need it, you explicitly pay for it when you need it. At the hardware level, there's less interconnects and so all operations can be implemented simpler or faster. Integer overflow on addition of two unsigned values can be detected by comparing the result to one of the operands to see if it's smaller, which can probably be done in one additional instruction. I'm sure there's suitably clever tricks for signed addition as well as subtraction. All stuff that a compiler can implement appropriately. Maybe this limits the relative usefulness of risc-v silicon for programming languages that do a lot of safety checking. If your CPU spends 10% of its time doing additional runtime "safety" instructions vs. other architectures, but takes up 10% less space or runs 10% faster due to the simplicity, it seems like a wash though. Programs that don't need the runtime safety can then run 10% faster. Additionally, nothing is stopping someone from designing hardware that accelerates common instruction sequences. A CPU could still internally implement status flags and decode common compiler instruction sequences faster than otherwise.
    - andrekandre 6y ago
      i think for integer operations, there are no status flags, but for floating point you can check the fcsr register for exceptions [0] [0] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20200727-8088ba4/riscv-spec.pdf https://github.com/riscv/riscv-isa-manual/releases/download/... EXCERPT Overflow checking for unsigned addition requires only a single additional branch instruction after the addition: add t0, t1, t2; bltu t0, t1, overflow. For signed addition, if one operand’s sign is known, overflow checking requires only a single branch after the addition: addi t0, t1, +imm; blt t0, t1, overflow. This covers the common case of addition with an immediate operand. FLOATING POINT As allowed by the standard, we do not support traps on floating-point exceptions in the base ISA, but instead require explicit checks of the flags in software. We considered adding branches controlled directly by the contents of the floating-point accrued exception flags, but ultimately chose to omit these instructions to keep the ISA simple.
ncmncm 6y ago
I can tell you what's missing: a POPCOUNT instruction. Yes, there is one in the proposed "B" extension. Not good enough: it won't be in the smaller chips, or even in the biggest ones for a good while. But the article is interesting in noting all the stuff that we just don't see when we buy a gadget. The amount of sheer engineering effort that goes into real products that millions of people rely on is stunning. It takes a very large amount of actual money changing hands to generate the amount of invisible effort that is needed to support the things we use every day. The lack of that expenditure will make RISC-V adoption much slower than we might otherwise expect.
- avianes 6y ago
  > it won't be in the smaller chips, or even in the biggest ones for a good while. Where does this statement come from? Do you have any sources or arguments to justify that?
  - AnimalMuppet 6y ago
    I'm not the one you're asking. But... there's many a slip between spec and chip. That is, creating a spec that says that it includes a POPCOUNT instruction is easier (except perhaps for politics and bureaucracy) than actually implementing one in a chip, going through layout, producing masks, and starting production. Then it takes a while for those chips to work their way through the supply chain to general availability. How long? I don't know. But I suspect that it's a non-trivial amount of time. How long until that instruction is available in all chips that are manufactured? Longer.
    - avianes 6y ago
      Frist, we are talking about RISC-V. The ISA is not finished. So yes, it will take time, but that's not the point. > How long until that instruction is available in all chips that are manufactured? Longer. The author didn't say it would take a long time, he said that "it won't be in the smaller chips". And "even in the biggest ones for a good while". But what is "for a good while" when nobody is already using RISC-V for performance?
denotational 6y ago
Very frustrating reading the comments from the Aldec marketing head, and it's really disappointing to see such comments coming from a company which has previously engaged so much with the open-source community (they've actually put some effort into proper support for co-simulation using the Python-based cocotb). For example: > Q: What’s still missing out of the design flow? Do all the tools work with RISC-V? > A: The main thing is the lack of UVM support. This answer just seems like a category error: UVM is (for all intents and purposes) a library for SystemVerilog; an ISA does not "have UVM support", they just aren't even closely related. Perhaps he means that (open-source) implementations of RISC-V cores haven't been verified using UVM, or that open-source functional-verification tooling typically doesn't support UVM? There are two reasons that no-one is using UVM in the open-source community: it's absolutely unbelievably dreadful, and full SystemVerilog support is generally lacking from open-source tooling. Unless you've got $$$$ to spend on a Big-3 simulator (let's be honest, no-one is using Aldec simulators to tape out an ASIC), you can't use UVM even if you wanted to. > UVM would give you constrained random verification, functional coverage, and re-usability. UVM (along with most of the "software" features of SystemVerilog, and pretty much everything else that's come out of Accellera) is a load of utter rubbish that unfortunately won't die. These advantages have absolutely nothing to do with UVM, or even to do with using SystemVerilog as a verification language: they can all be achieved by co-simulating designs with testbenches written in a better language, for example cocotb testbenches written in Python. The reason why UVM is so prevalent has absolutely nothing to do with its suitability or superiority over other frameworks, and everything to do with the cabal of EDA vendors who are trying to maximise their profit: just consider that Cadence has net profits over double that of Arm, and it becomes apparent that the companies who use these tools are "small fish" compared to the companies making them, as perverse as this may be. Arm would much rather write RTL than tooling, so they're completely at the mercy of the Big-3: if Cadence says that UVM is the only way forward, Arm (and the rest of the industry) is pretty much compelled to follow. > Along those lines, we see big problems on the business side. The open-source business model makes it very difficult for companies to make an investment. We do see open source becoming a huge movement, and we’ve already seen that happen in the software domain. But for EDA, and particularly hardware verification tools, we’re still gauging what we’re going do with it. You need to make sure that whatever you invest is going to generate a return on that investment. The subtext here is that EDA vendors absolutely don't under any circumstances want a strong open-source community in the hardware design space: as soon as the community reaches a critical mass, open-source EDA tooling might start to become a more-and-more viable alternative for use in industry, and the EDA vendors might actually have to start doing some work. I'm convinced that the first place this will happen is formal verification: SiFive is already using Kami [1], which came from Adam Chlipala's group at MIT and is open-source. The costs of formal verification are absolutely worth it in expensive ASIC projects, but it seems EDA vendors (and even companies like Arm) have been really slow to see the light. There's a continuous stream of developments in this space coming out of academia which can be used for real-world projects. The general state of the EDA industry is dire. My employer recently spent about $1.5MM renewing licences for a Big-3 simulator: this is the same tool which I can consistently make segfault in about 10 different ways. The quality of tooling is appalling, and the industry is incredibly slow to react. I'm really hopeful that projects such as RISC-V will stimulate the open-source hardware community enough that we might actually see some change in this space. [1] : https://github.com/sifive/Kami https://github.com/sifive/Kami
lawrenceyan 6y ago
FYI, if you'd like to try your hand at designing your own open source RISC-V processor, you can fab it for free here: https://fossi-foundation.org/2020/06/30/skywater-pdk https://fossi-foundation.org/2020/06/30/skywater-pdk
- etaioinshrdlu 6y ago
  Interestingly the shuttle includes a RISCV core as a "harness" that you cannot modify or remove.
  - lawrenceyan 6y ago
    I'm not sure what exactly you're referring to here. Do you mind providing a link to what you're looking at?
rramadass 6y ago
The "Shakti" RISC-V based open source processor - https://shakti.org.in/ https://shakti.org.in/
- Abishek_Muthian 6y ago
  Has any manufacturer expressed interest in bringing Shakti processor(E/C class) to the market?
  - rramadass 6y ago
    I haven't heard anything specific. It may be because it is still a little too early and that the Indian startups/companies are not familiar with chip/semiconductor company economics (huge upfront investment, long time periods etc.) Hopefully, with the "Make in India" push that might change. That said, there has already been a couple of tapeouts and govt. agencies (ISRO and defence sector companies) are playing with them. A company "Incore Semiconductors"(https://incoresemi.com/ https://incoresemi.com/) in the model of "ARM Holdings" has also been formed to sell the technology. Related: https://www.electronicsb2b.com/eb-specials/indias-chips-how-good-is-desi/ https://www.electronicsb2b.com/eb-specials/indias-chips-how-... https://www.eetindia.co.in/ajit-agumbe-pruthvi-and-shakti-india-made-chips/ https://www.eetindia.co.in/ajit-agumbe-pruthvi-and-shakti-in...
    - Abishek_Muthian 6y ago
      Thanks, I don't think anyone can even think about fabrication not just Indian startups, at this point TMSC is defacto for anyone thinking about semiconductor. IMO, we need to do what Espressif did with ESP8266/ESP32 for Shakti. Incore semi sounds interesting, will check them out.
      - Abishek_Muthian 6y ago
        *TSMC.
      - rramadass 6y ago
Teknoman117 6y ago
I've personally been having a lot of fun trying to write a rv32im processor in an HDL. I know people have already done this, but this is for a fun learning experience!
farseer 6y ago
Why would companies prefer riscv over openPower?
- jlokier 6y ago
  Because other companies do, so that's where the action is now. What matters is can we benefit from each others' work, and is there a lot of work being done and shared by others, to benefit from. It's a (business as well as developer) community, network effect thing. You might as well ask, why did RISC-V succeed while OpenRISC failed? The ISA doesn't really matter. It's not like the RISC-V ISA is mind-blowingly special or anything. It's sensible, it does the job about as well as others. (I say this even though I'm an enthusiast and member of the RISC-V Foundation. I don't think the ISA is the special secret sauce, I think community and sharing are). There are some great ISA extensions, but many of them came after RISC-V had already gained momentum. And those extensions are mostly because there's a diverse community of companies and developers producing them. OpenPower has some of that, but not as much.
  - drivebycomment 6y ago
    Another important advantage of RISC-V is academia. RISC-V has much more mindshare/backing from the university researchers, being started in UC Berkeley with big names like David Patterson. OpenPower...not so much. And I strongly believe university research being on top of RISC-V is the biggest advantage in the long term - what that means is that masters and PhD students will be fully trained on RISC-V ISA, and many new architectural research will be already based on the ISA. OpenPower never had, and likely never will have academic backing. Why would a university research choose OpenPower ? The only scenario I can imagine is if they are pursuing a funding from OpenPower companies, but OpenPower is already a small minority in ISA mind-share and market share, and I don't see any chance of them catching up.
- Narishma 6y ago
  Probably for the same reasons Rust is more popular than Ada or D.

186 points by SemiTom 6y ago

I’ve had a lot of fun learning RISC-V assembly off and on over the last year. I went through a colleague of mine’s tutorial series on implementing an operating system targeting RISC-V using Rust. Now I’m working on my own small assembler for RISC-V. It’s been so much more fun to learn than x86! Edit: link to the tutorial (http://osblog.stephenmarz.com/ http://osblog.stephenmarz.com/)

faitswulff 6y ago
Is this the tutorial you mentioned? EDIT - ah nevermind, turns out there are at least two RISC-V OS tutorials in Rust: - https://gist.github.com/cb372/5f6bf16ca0682541260ae52fc11ea3bb https://gist.github.com/cb372/5f6bf16ca0682541260ae52fc11ea3... - http://osblog.stephenmarz.com/ http://osblog.stephenmarz.com/
- azhenley 6y ago
  The second one! Sorry, I meant to include it. I updated my comment.
msla 6y ago
To me, a fun ISA is one which provides opportunities for golf, which basically means CISC ISAs with lots of different ways to do things. RISC-V is proudly, definitively not that and that's a good design decision, but you'll never be able to replace a stretch of straightforward code with a handful of more obscure opcodes and complicated addressing modes. I'll always have SIMH.
- garmaine 6y ago
  Yeah that’s a bit like saying you enjoy spelling bees, whereas a language that is idiomatic enough to allow for competitive spelling to exist as a real thing has fundamentally failed at its job.
  - msla 6y ago
    Orthography is orthogonal to a language, as transliteration proves. Putonghua is Putonghua regardless of whether it's written in Sinitic characters, Yale Romanization, or Pinyin. Also, don't run down someone else's hobbies. It's uncouth.
    - garmaine 6y ago
      I’m not..? It’s fine to play code golf with CISC-y architectures. But being able to do that is an anti-goal to a compiler-friendly architecture, as RISC tries to be.
- tux3 6y ago
  The base ISA is very plain and RISCy. But I'd encourage you to go read the Bitmanip extension and find an opcode in there that doesn't have at least one obscure alternate use! =) As for addressing modes, yeah I do wish we had a little bit more as a software person (but not as a hobby/toy cpu writer!). The current stuff can encode a surprising number of simple loops efficiently if you do it right, but of course if you come from x86 you'll have to do more with less...
  - Taniwha 6y ago
    Essentially it wouldn't be RISC is there were more complex addressing modes (if you can't do it in one clock at speed .....)
    - msla 6y ago
      Complex addressing modes are un-RISCy because they're harder to pipeline: Memory accesses might result in page faults, and if you have complicated addressing modes, all of a sudden you have some nontrivial ALU state to back out before you can handle the fault. It's a lot simpler to have rock-dumb load/store opcodes and then do all ALU work in terms of register-register opcodes which don't touch memory. John Mashey (helped design the MIPS architecture) has a great account of how complex addressing modes are difficult to work with partway down this page: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html I can't link to it directly, but it starts with this text: > General comment: this may sound weird, but in the long term, it might be easier to deal with a really complicated bunch of instruction formats, than with a complex set of addressing modes, because at least the former is more amenable to pre-decoding into a cache of decoded instructions that can be pipelined reasonably, whereas the pipeline on the latter can get very tricky (examples to follow). This can lead to the funny effect that a relatively "clean", orthogonal archiecture may actually be harder to make run fast than one that is less clean. Obviously, every weirdness has it's penalties.... But consider the fundamental difficulty of pipelining something like (on a VAX): ADDL @(R1)+,@(R1)+,@(R2)+ > (I.e., something that, might theoretically arise from: register **r1, **r2; **r2++ = **r1++ + **r1++; ... and he then goes on a detailed step-by-step process of what has to happen to execute that opcode in the world of page faults and unaligned memory accesses, another thing classic RISC chips were very down on, but I think they've gotten a bit looser on them in recent decades.
- zozbot234 6y ago
  > but you'll never be able to replace a stretch of straightforward code with a handful of more obscure opcodes and complicated addressing modes. It just changes the target for a (human or computer) superoptimizer. Instead of using weird CISCy instructions, you're optimizing things like register allocation and the binary 'interfaces' between parts of your code. At a slightly higher level than a single insn, assembly coding is always about having "lots of different ways to do things"!
- rwmj 6y ago
  Sort of. The fun optimizations are a little different now: Can you choose your registers so you can make maximum use of Compressed instructions? And for higher performance chips, can you select sequences of instructions that trigger macro-op fusion?
pjmlp 6y ago
I grew up with Z80, back in the day when business applications had enough Assembly into them. Used 68000 and all x86 variants until Pentium (by then it was too much effort to write Assembly by hand), also had to deal with MIPS, PowerPC, SPARC, ARM and various bytecode formats. X86 remains my favourite, in tooling and high level opcodes with cool tricks.
- rwmj 6y ago
  Really? Z80 and even moreso 68000 had lovely orthogonal assembly languages which were a pleasure to program in.
  - pjmlp 6y ago
    Yes really, I never got the point of that, specially given the weaker addressing modes. Actually the only thing that pissed me off, but was sorted out with 386 anyway, was the segmented memory.
fwsgonzo 6y ago
Is there a std-variant for rv64g? And if not, how easy is it to setup for rv64gc? I have an emulator with a known rv64gc bug, and it's faster to emulate uncompressed instructions (until I start translating them, I guess). Also, what language is the assembler written in? Is it embeddable?

TimSchumann 6y ago

I actually just ordered a HiFive1 Rev B to play around with. Kinda excited for the potential of RISC-V, we'll see how much wind this article takes out of my sails. Thanks for sharing it.

01100011 6y ago

Does anyone know how well RISC-V will be able to compete with ARM in the higher end? It seems pretty easy to come up with a processor design that is competitive in low-compute load applications, but what about more advanced designs? I'm curious what it is that ARM brings to the table there and if there is a chance that RISC-V will ever offer serious competition. Certainly RISC-V does not need to be the best to survive as a viable option for most designs. It may absorb a lot of market share from ARM in the long run. It will be interesting to see how it develops.

TimSchumann 6y ago
I'd say that depends on the higher end of what? Control over the firmware, understanding of the actual bits you're flipping and the architecture, power consumption, or raw computer per clock?
- mastazi 6y ago
  I’m not parent but personally I’m interested in performance per Watt
  - ljhsiung 6y ago
    The ISA design has very little impact on actual energy consumption rather than an actual CPU's uArch. This is a conception that hasn't been true for at least 20 years. It was somewhat true in the days where memory was expensive, and so smaller instructions were a good idea. But this came at the cost of increased area and thus energy (since you need more decoding logic). As time went on, transistors shrank, so this cost kept decreasing; at the same time, memory got better and we developed techniques to hide the latency more, so the upside also kept decreasing. Ultimately in modern times any difference in ISA results in some ~1% difference in energy consumption. You would gain far more efficiency (on the order of 2.5x) in just designing your uArch in a better way-- say, in-order vs OoO. [1] In my opinion, the reason CISC vs. RISC is still very alive today is because ARM has done a fabulous job in marketing and executing itself as energy efficient. The big.Little architectures are an example in cementing this idea. Conversely, Intel has done a similarly fabulous job in marketing and executing itself as performant, allowing both companies to live happily in their respective areas. The introduction of hyperthreading is another example of pushing this edge. But these design decisions are NOT ISA intrinsic, and these misconceptions are changing incredibly fast (though I think ARM is doing a much better job than Intel at changing these paradigms). [1] https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-struggles.pdf https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa...

ape4 6y ago

No integer overflow instruction I read on Hacker News the other day.

dbcurtis 6y ago
What does that even mean? It has an integer add instruction, surely, and integer add can overflow. Do you mean you get no exception? or no status flag to check?
- sgtnoodle 6y ago
  I vaguely recall risc-v having no status flags, instead preferring explicit instructions to check for such things. The idea is that, instead of implicitly paying for the checks on every operation whether or not you need it, you explicitly pay for it when you need it. At the hardware level, there's less interconnects and so all operations can be implemented simpler or faster. Integer overflow on addition of two unsigned values can be detected by comparing the result to one of the operands to see if it's smaller, which can probably be done in one additional instruction. I'm sure there's suitably clever tricks for signed addition as well as subtraction. All stuff that a compiler can implement appropriately. Maybe this limits the relative usefulness of risc-v silicon for programming languages that do a lot of safety checking. If your CPU spends 10% of its time doing additional runtime "safety" instructions vs. other architectures, but takes up 10% less space or runs 10% faster due to the simplicity, it seems like a wash though. Programs that don't need the runtime safety can then run 10% faster. Additionally, nothing is stopping someone from designing hardware that accelerates common instruction sequences. A CPU could still internally implement status flags and decode common compiler instruction sequences faster than otherwise.
  - andrekandre 6y ago
    i think for integer operations, there are no status flags, but for floating point you can check the fcsr register for exceptions [0] [0] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20200727-8088ba4/riscv-spec.pdf https://github.com/riscv/riscv-isa-manual/releases/download/... EXCERPT Overflow checking for unsigned addition requires only a single additional branch instruction after the addition: add t0, t1, t2; bltu t0, t1, overflow. For signed addition, if one operand’s sign is known, overflow checking requires only a single branch after the addition: addi t0, t1, +imm; blt t0, t1, overflow. This covers the common case of addition with an immediate operand. FLOATING POINT As allowed by the standard, we do not support traps on floating-point exceptions in the base ISA, but instead require explicit checks of the flags in software. We considered adding branches controlled directly by the contents of the floating-point accrued exception flags, but ultimately chose to omit these instructions to keep the ISA simple.

ncmncm 6y ago

I can tell you what's missing: a POPCOUNT instruction. Yes, there is one in the proposed "B" extension. Not good enough: it won't be in the smaller chips, or even in the biggest ones for a good while. But the article is interesting in noting all the stuff that we just don't see when we buy a gadget. The amount of sheer engineering effort that goes into real products that millions of people rely on is stunning. It takes a very large amount of actual money changing hands to generate the amount of invisible effort that is needed to support the things we use every day. The lack of that expenditure will make RISC-V adoption much slower than we might otherwise expect.

avianes 6y ago
> it won't be in the smaller chips, or even in the biggest ones for a good while. Where does this statement come from? Do you have any sources or arguments to justify that?
- AnimalMuppet 6y ago
  I'm not the one you're asking. But... there's many a slip between spec and chip. That is, creating a spec that says that it includes a POPCOUNT instruction is easier (except perhaps for politics and bureaucracy) than actually implementing one in a chip, going through layout, producing masks, and starting production. Then it takes a while for those chips to work their way through the supply chain to general availability. How long? I don't know. But I suspect that it's a non-trivial amount of time. How long until that instruction is available in all chips that are manufactured? Longer.
  - avianes 6y ago
    Frist, we are talking about RISC-V. The ISA is not finished. So yes, it will take time, but that's not the point. > How long until that instruction is available in all chips that are manufactured? Longer. The author didn't say it would take a long time, he said that "it won't be in the smaller chips". And "even in the biggest ones for a good while". But what is "for a good while" when nobody is already using RISC-V for performance?

denotational 6y ago

Very frustrating reading the comments from the Aldec marketing head, and it's really disappointing to see such comments coming from a company which has previously engaged so much with the open-source community (they've actually put some effort into proper support for co-simulation using the Python-based cocotb). For example: > Q: What’s still missing out of the design flow? Do all the tools work with RISC-V? > A: The main thing is the lack of UVM support. This answer just seems like a category error: UVM is (for all intents and purposes) a library for SystemVerilog; an ISA does not "have UVM support", they just aren't even closely related. Perhaps he means that (open-source) implementations of RISC-V cores haven't been verified using UVM, or that open-source functional-verification tooling typically doesn't support UVM? There are two reasons that no-one is using UVM in the open-source community: it's absolutely unbelievably dreadful, and full SystemVerilog support is generally lacking from open-source tooling. Unless you've got $$$$ to spend on a Big-3 simulator (let's be honest, no-one is using Aldec simulators to tape out an ASIC), you can't use UVM even if you wanted to. > UVM would give you constrained random verification, functional coverage, and re-usability. UVM (along with most of the "software" features of SystemVerilog, and pretty much everything else that's come out of Accellera) is a load of utter rubbish that unfortunately won't die. These advantages have absolutely nothing to do with UVM, or even to do with using SystemVerilog as a verification language: they can all be achieved by co-simulating designs with testbenches written in a better language, for example cocotb testbenches written in Python. The reason why UVM is so prevalent has absolutely nothing to do with its suitability or superiority over other frameworks, and everything to do with the cabal of EDA vendors who are trying to maximise their profit: just consider that Cadence has net profits over double that of Arm, and it becomes apparent that the companies who use these tools are "small fish" compared to the companies making them, as perverse as this may be. Arm would much rather write RTL than tooling, so they're completely at the mercy of the Big-3: if Cadence says that UVM is the only way forward, Arm (and the rest of the industry) is pretty much compelled to follow. > Along those lines, we see big problems on the business side. The open-source business model makes it very difficult for companies to make an investment. We do see open source becoming a huge movement, and we’ve already seen that happen in the software domain. But for EDA, and particularly hardware verification tools, we’re still gauging what we’re going do with it. You need to make sure that whatever you invest is going to generate a return on that investment. The subtext here is that EDA vendors absolutely don't under any circumstances want a strong open-source community in the hardware design space: as soon as the community reaches a critical mass, open-source EDA tooling might start to become a more-and-more viable alternative for use in industry, and the EDA vendors might actually have to start doing some work. I'm convinced that the first place this will happen is formal verification: SiFive is already using Kami [1], which came from Adam Chlipala's group at MIT and is open-source. The costs of formal verification are absolutely worth it in expensive ASIC projects, but it seems EDA vendors (and even companies like Arm) have been really slow to see the light. There's a continuous stream of developments in this space coming out of academia which can be used for real-world projects. The general state of the EDA industry is dire. My employer recently spent about $1.5MM renewing licences for a Big-3 simulator: this is the same tool which I can consistently make segfault in about 10 different ways. The quality of tooling is appalling, and the industry is incredibly slow to react. I'm really hopeful that projects such as RISC-V will stimulate the open-source hardware community enough that we might actually see some change in this space. [1] : https://github.com/sifive/Kami https://github.com/sifive/Kami

lawrenceyan 6y ago

FYI, if you'd like to try your hand at designing your own open source RISC-V processor, you can fab it for free here: https://fossi-foundation.org/2020/06/30/skywater-pdk https://fossi-foundation.org/2020/06/30/skywater-pdk

etaioinshrdlu 6y ago
Interestingly the shuttle includes a RISCV core as a "harness" that you cannot modify or remove.
- lawrenceyan 6y ago
  I'm not sure what exactly you're referring to here. Do you mind providing a link to what you're looking at?

rramadass 6y ago

The "Shakti" RISC-V based open source processor - https://shakti.org.in/ https://shakti.org.in/

Abishek_Muthian 6y ago
Has any manufacturer expressed interest in bringing Shakti processor(E/C class) to the market?
- rramadass 6y ago
  I haven't heard anything specific. It may be because it is still a little too early and that the Indian startups/companies are not familiar with chip/semiconductor company economics (huge upfront investment, long time periods etc.) Hopefully, with the "Make in India" push that might change. That said, there has already been a couple of tapeouts and govt. agencies (ISRO and defence sector companies) are playing with them. A company "Incore Semiconductors"(https://incoresemi.com/ https://incoresemi.com/) in the model of "ARM Holdings" has also been formed to sell the technology. Related: https://www.electronicsb2b.com/eb-specials/indias-chips-how-good-is-desi/ https://www.electronicsb2b.com/eb-specials/indias-chips-how-... https://www.eetindia.co.in/ajit-agumbe-pruthvi-and-shakti-india-made-chips/ https://www.eetindia.co.in/ajit-agumbe-pruthvi-and-shakti-in...
  - Abishek_Muthian 6y ago
    Thanks, I don't think anyone can even think about fabrication not just Indian startups, at this point TMSC is defacto for anyone thinking about semiconductor. IMO, we need to do what Espressif did with ESP8266/ESP32 for Shakti. Incore semi sounds interesting, will check them out.
    - Abishek_Muthian 6y ago
      *TSMC.
    - rramadass 6y ago

Teknoman117 6y ago

I've personally been having a lot of fun trying to write a rv32im processor in an HDL. I know people have already done this, but this is for a fun learning experience!

farseer 6y ago

Why would companies prefer riscv over openPower?

jlokier 6y ago
Because other companies do, so that's where the action is now. What matters is can we benefit from each others' work, and is there a lot of work being done and shared by others, to benefit from. It's a (business as well as developer) community, network effect thing. You might as well ask, why did RISC-V succeed while OpenRISC failed? The ISA doesn't really matter. It's not like the RISC-V ISA is mind-blowingly special or anything. It's sensible, it does the job about as well as others. (I say this even though I'm an enthusiast and member of the RISC-V Foundation. I don't think the ISA is the special secret sauce, I think community and sharing are). There are some great ISA extensions, but many of them came after RISC-V had already gained momentum. And those extensions are mostly because there's a diverse community of companies and developers producing them. OpenPower has some of that, but not as much.
- drivebycomment 6y ago
  Another important advantage of RISC-V is academia. RISC-V has much more mindshare/backing from the university researchers, being started in UC Berkeley with big names like David Patterson. OpenPower...not so much. And I strongly believe university research being on top of RISC-V is the biggest advantage in the long term - what that means is that masters and PhD students will be fully trained on RISC-V ISA, and many new architectural research will be already based on the ISA. OpenPower never had, and likely never will have academic backing. Why would a university research choose OpenPower ? The only scenario I can imagine is if they are pursuing a funding from OpenPower companies, but OpenPower is already a small minority in ISA mind-share and market share, and I don't see any chance of them catching up.
Narishma 6y ago
Probably for the same reasons Rust is more popular than Ada or D.