I wonder if they are considering RISC-V. Probably not - they don’t sound like risk-taking people. But given the timelines of chip production, I would think a couple years from now a solid RISC-V server might be very much in demand.
As a side note, a couple of jobs on their careers page seem to want ARM assembly experience...so it's likely to be an ARM core?
"Knowledge of library cells and optimizations from ARM, TSMC, and other high performance library vendors"
https://nuviainc.com/job-listing/nuvia-4csrj
"Familiarity with coherent bus protocols like ARM AMBA and CHI bus protocols"
Plenty of people seem to have been caught up in the hype of RISC-V taking over the world and doing everything, but that's never going to happen. The ISA is heavily optimized towards making very low-end devices very cheap. Like, don't think cellphone chips, think appliances. This is not a bad call, as it's the area where greenfield designs with cost advantage have the best chance to get market share. However, there is no path of extending the ISA that will make it competitive with ARM or x86 on high-end devices. The only way to do that is to design RISC-VI, that abandons most of the things that RISC-V what it is.
I have to dispute this. RISC-V was specifically intended to make high-end designs (i.e. out-of-order architectures, multicore, SMT etc.) not just feasible but relatively easy. It's also designed for extensibility from the ground up, which few others architectures are.
https://www.sifive.com/blog/incredibly-scalable-high-perform...
A72 is a mobile chip, so still not particularly relevant to tuna-fish's claim about high end servers. The raspberry pi 4 is not a high end server.
> half the die area
Much of this is free when comparing a 16nm design to a 7nm design. See footnote 1 in your link.
EDIT: I was curious, so I looked up the transistor density of tsmc 16nm vs 7nm.
16nm: 28.8 MTr/mm^2
7nm: 96.5 MTr/mm^2
So I think that sifive core with "half the area" is actually not quite as good as a die shrink of the A72.
So is Apple A13. And yet it's been reported to outperform all Intel desktop CPUs in single core performance (I find the benchmark dubious, but I do believe it's close, and faster than it has any right to be given the super low power consumption). The only reason it doesn't do so in multicore perf is the limited TDP - a concern which does not exist in high end chips.
By default, code density on RISC-V is pretty bad. You can try to solve that by using variable length instructions which many high end RISC-V projects intend to do but having variable length instructions means your front end is going to have to be more complicated to reach the same level of performance that a fixed width instruction machine can achieve.
More instructions for a task means your back end also has to execute more instructions to reach the same level of performance. One way to do better is to fuse together ISA-level instructions into a smaller number of more complex instructions that get executed in your core. This is something that basically every high end design does but RISC-V would have to do it far more extensively than other architectures to achieve a similar level of density on the back end which makes designing a high end core more complex and possibly uses extra pipeline stages making mispredicts more costly.
And more more criticisms here: https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99...
EDIT: But in fairness it looks like conditional move might be getting added to the bit manipulation RISC-V extension which would fix one big pain point.
This isn't to say that RISC-V is bad. It's simplicity makes it wonderful for low end designs. It's extensibility makes it great for higher level embedded uses where you might want to add some instruction that makes your life easier for your hard driver controller or whatever in a way that would require a very expensive architecture license if you were using ARM. It's open, which would be great if you were making a high end open-source core for other people to use except the Power ISA just opened up so if I were to start a project like that I'd use that instead.
Code density with the C extension is competitive with x86, which is very good for a RISC. And the C extension is not even that hard on the decoder, since most or even all 'compressed' instructions have a single uncompressed counterpart. It's easier to implement than what ARM32 does with Thumb.
> One way to do better is to fuse together ISA-level instructions into a smaller number of more complex instructions that get executed in your core.
Insn fusion has in fact been endorsed by the designers of RISC-V as an expected approach in high-end designs. The RISC-V spec even gives "suggested" sequences for things like overflow checking, that can be transparently insn-fused if an implementation supports it.
What you should take seriously is that three of the four big RISC ISAs - MIPS, ARM, and POWER - all have extensions for variable length instructions. They all use them in embedded systems where program memory size is a big factor in your bill of materials and reducing that can save you money. But none of them use it on their high end processors. So I think we can conclude that the power/transistor cost of fetching a number of variable length instructions per clock is higher than the cost of expanding the L1 instruction cache to deal with full size instructions.
The real cost you're looking at is the complexity for instructions to straddle cache lines and MMU pages, but even then it's less of a deal than you might think.
RISC-V on the other hand has an encoding scheme that already from the beginning allowed instructions with longer and shorter encodings. You can just mix compressed instructions with normal ones.
It must be a pain to design its instruction decoder, but I don’t think that’s insurmountable for high end processors.
Or do I misunderstand your argument?
- Like somebody already pointed out, thumb is a different mode, whereas RISC-V C (RVC) can be freely mixed with normal 32-bit instructions.
- And speaking of higher end processors, x86 does very well in that space despite requiring much more complex decode than RVC.
- Aarch64 has more complex addressing modes (base + index<<shift in particular) whereas RISC-V needs both RVC and fusion to do the same with similar code size and execution slot occupation. Personally, I'm leaving towards thinking that it was a mistake for RISC-V to not support such addressing modes. Unless you're aiming for something really super-constrained in terms of gate counts, having an adder and small shifter as part of your memory pipeline(s) seem like an obvious choice. And thus, having single instructions to use those pipelines isn't really committing any sins against the RISC philosophy.
Not all servers need to be high end. There’s a big market for small websites.