RISC-V Pushes into the Mainstream
semiengineering.com
semiengineering.com
The biggest hindrance to it is lack of software and distro support.
The VisionFive2 is a lovely board but so far we only have a barren bootrom. No idea of OpenGl, OpenCl work on it!
Someone lied about distro support being confirmed. StarFive probably...
But those lies could torpedo the whole project.
The early days of android were bogged down with complaints of fragmentation, patchy support.
It just launched, give it time. The whole point of VisionFive 2 is precisely to get these boards to developers in large numbers so that it can all be bootstrapped.
I hope that's changed?
https://debian.starfivetech.com/
Ubuntu is working on it as well. May already be done I'm not sure
As for software see RISC-V Summit 2022—StarFive's Efforts in Fuelling RISC V Software Ecosystem[0]
There is a lot of work being put into this, not only by StarFive but by other companies, the Chinese government (via the Chinese Academy of Sciences), researchers and hobbyists (once boards arive).
though 4k monitors dont work yet from hdmi... seems some kind of bug...
It is the first raspberry-pi like <$100 RISC-V SBC, and it only started shipping to customers last week.
It is also the first board with a large run (long thousands vs short hundreds).
Maybe there's just one Debian image and little documentation on how to get it all up and running, but that's today.
In a month, it'll be a different story. That's the whole point of getting these into the hands of developers.
Sadly I haven't found much new it enables yet either (because at this point Xtensa is quite well supported too).
I like that the ESP32-C3 is a RISC-V chip, but I realized after playing with it for a week that it turned out to not mean much - that's probably because I'm a pretty simplistic user though.
I actually think this ought to be a positive for customers who are clearly abiding by the terms of their contracts.
Most firms will have legal departments can look at this case on its merits and decide whether or not Arm is acting in bad faith.
If I'm another Arm customer I definitely don't want a competitor playing fast and loose with its Arm contract.
Because nobody wants to fight over the licensing of a product they're shackled to. If you could buy a RISC-V board with software support similar to a Raspberry Pi, ARM's goose would be cooked. Every enthusiast would ditch ARM in a heartbeat for a more open ISA, and ARM licensees would see it as an opportunity to finally wiggle free of ARM's insane license restrictions. All we need is the software support, which should be pretty forthcoming since most projects have already been optimized for RISC.
ARM could unseat x86 because both ISAs were encumbered with licenses at the time. Now, ARM is competing with much less restrictive architectures, and all it would take is a FOSS RISC instruction set to ruin their value prop.
So when a firm licenses a RISC-V core from SiFive they should be free do whatever they want with that core irrespective of the license terms?
I find it odd how Qualcomm is portrayed as though they were innocently minding their own business when they suddenly got sued. They bought Nuvia knowing what was in the two sets of contracts.
Also Qualcomm had and still has the ability to design their own Arm cores.
If Qualcomm is a relevant topic regarding ARM's success, then they've arguably already failed.
Most of these firms are licensing a core from a third party. There is no such thing as ‘on their own terms’.
I'm not so sure it's the expensive large chips, made in relatively small quantities, that make ARM the most money, do you have a source? I'd have guessed they actually make more on the billions of small ARM cores that ship every year that end up by multiples in pretty much every device with a battery or power cord. And these, I think, are at the biggest risk of leaving ARM. RISC-V development is mature enough at this end of the market that it's relatively easy for users to transition, there are multiple competitive cores on the market, and there's no concern here about backwards compatibility because these are embedded systems where there's usually not an expectation of having to run user code at all. It will be much harder for the likes of Qualcomm where there's a huge ecosystem built around their ARM processors - but as a share of cost-per-processor, they probably stand to gain the most. Qualcomm is a founding member of the RISC-V foundation after all.
No, ARM is 100% owned by SoftBank. Apple sold their shares a while ago.
Overall ARM doesen't really make that much money, especially compared to some of their clients. It's not even obvious to me if would make sense financially even for Qualcomm to design their own RISC-V cores compared to licensing from ARM.
I mean they could and did design their own cores but they are still using ARM designed ones for their top-end chips.
Or they believe that designing their own cores would be cost prohibitive and prefer licensing them from ARM.
It's also not obvious to me than licensing conditions for RISC-V could be more favorable than what ARM is offering. Why would you anyone even license competitive cores their competitors if they can make more money selling them themselves?
There simply isn't that much money in designing cores. The money is in selling SoCs or devices. Arm at least has made increasingly high quality cores available at reasonable prices to all comers. A future where Arm's business is made unviable is not necessarily better for consumers.
You can license RISC-V cores from Si-Five today but they if reports are correct they were in discussions to sell to Intel. If that were to happen who knows what would happen to their offering. There will be others of course but as you say it's not obvious that what they offer will be any better that what Arm offers today.
And for the foreseeable future Arm is immune to takeover by any of its deep-pocketed customers.
I'm very happy that RISC-V exists from a number of perspectives but there needs to be a realistic assessment of its potential impact.
No one is saying that they should or shouldn't (or at least I haven't seen anyone saying this).
But, when you exercise a right, there are social consequences. Freedom of speech is a right (in the US at least), but picketing funerals will still get you dis-invited from a lot of parties. Suing big customers (unless you're obviously in the right when viewed from the outside) will make at least some people more nervous to do business with you.
Facebook, Oracle, and Qualcomm are all with Original Sin. You will hardly find any support regardless of its situation.
You're assuming high end RISC cores will be available for free and or under much more favorable licensing than ARM cores. Which seems unlikely, why would someone sell their cores to a competitor for less than a company whose only business is designing them?
Also hardware is pretty different than software. Hardware design (and obviously manufacturing) requires much more significant investment.
> These contributors aren't really in the business of selling compilers and simply
That's the thing. Apple was/is not in the business of selling compilers, nor are the people/companies who contributed to gcc and most other open-source projects. They have basically nothing to lose and a lot to gain from contributing to open-source software.
It's not obvious to me CPU design could work that way. For starters everyone who could develop advanced RISC-V cores is unlikely to give them anyway to their competitors since they would be in the business of selling CPUs. i.e. do you really think Qualcomm, Apple etc. would make their designs free? Why?
> Alibaba/T-Head and their open source cores
Because at this point they have more to gain than by keeping them proprietary. RISC-V is not yet overall competitive with ARM. So it's not like these RISC-V cores could be commercialized that successfully. Keeping them open probably makes further development faster.
This open source core is about equivalent to a Cortex-X1. https://github.com/OpenXiangShan/XiangShan A collab between Alibaba, Tencent, and the Chinese Academy of Sciences.
Freedom from licensing etc. shouldn't be a problem for Apple unless maybe if they want to sell their chips to 3rd parties which doesn't seem too likely.
https://www.tomshardware.com/news/apple-looking-for-risc-v-p...
RISC-V is probably 5-10 years behind on the upper end though
But I do know they have a perpetual free RISC-V license like everybody else.
They will migrate when there is a major performance advantage (as in the past).
I heard from some of the people on the CPU team that Apple did not have to pass those tests because they had an exemption from ARM. Apple was one of the original ARM investors when it was spun off from Acorn in 1990. I think that agreement allows them to do things with ARM like adding custom things that other ARM licensees aren't allowed to do.
You are making it sound like a burden, but I do not understand why it would be. Surely you are interested in safety checks giving you more confidence that you are positioning yourself to take advantage of the Arm ecosystem (instead of releasing something that is not supportable by compilers and OS experts)?.. Or am I misunderstanding the nature of the compliance tests?
You mention ARM ecosystem and that is precisely the point. Apple controls their ecosystems. How do you write apps for the iPhone? You use Apple's development environment with Apple's compiler. If Apple decided NOT to implement an instruction for some reason they could simply make their compiler never output that instruction.
I worked on chips that ran embedded applications with no ability for ordinary users to change the software. What is the value of meeting an external ARM controlled spec for that?
I also worked on chips that only ran Android and nothing else. If you are also the company porting Android and writing all drivers for your own platform then people may argue whether it is worth only being 99% compatible.
Later I worked on chips where people may run Android, Windows Mobile, or plain Linux on this chip using GCC, Clang, Microsoft's compiler, or whatever. For that you definitely wanted to comply with specs.
I hope someone pitches this idea to these companies. I think some people at Google may be thinking in this direction being that they are paying for tape out of open hardware at no cost to the developers and are investing in tooling.
Working at the MCU-register level and higher, is there any difference in RISC-V? Or does it only matter if writing compilers and toolchains?
Maybe the way you handle interrupts changes? Eg you would no longer use a cortex-m library to handle them. Maybe low power modes too, since those use ARM registers in addition to MCU-specific ones?
As disappointing as it may be to some people, architecture rarely winds up mattering much (although you might be able to argue that some elements that make it into the peripherals are "architectural"). At least for software developers, there will never be a reason to dig into architecture. Maybe for some stuff interrupt, or hardware exception related.
I've found that the specific chipset and compiler tend to be more important for software developers working close to hardware. Even ASM code probably won't really matter, unless you plan to heavily rely on it; I would guess it could come into play if you plan on writing heavy ASM code, which I doubt you'd ever do on a modern architecture... maybe you're REALLY trying to save memory, or think you can improve CPU performance for some reason. Seems far fetched in almost every application, but I bet people out there are doing it for good reasons.
Of course, there may always be little places where you end up doing stuff with ASM, but again IME they tend to be where the peripherals and architecture meet.
What makes me a hypocrite to some degree is addiction to devices like my Apple Watch. The freedom to not carry a phone and still get texts and phone calls is awesome, and also be able to check weather, etc.
As I “get more retired” I am so tempted to drop the entire Apple ecosystem that drives my work and content creating work flow and just chill with a Linux laptop for recreational learning projects.
https://www.reddit.com/r/RISCV/comments/z6xzu0/multi_core_im...
When I got my ECE degree in 1999, I was so excited to start an open source project for at least a 256+ core (MIPS?) processor in VHDL on an FPGA to compete with GPUs so I could mess with stuff like genetic algorithms. I felt at the time that too much emphasis was being placed on manual layout, when even then, tools like Mentor Graphics, Cadence and Synopsys could synthesize layouts that were 80% as dense as what humans could come up with (sorry if I'm mixing terms, I'm rusty).
Unfortunately the Dot Bomb, 9/11 and outsourcing pretty much gutted R&D and I felt discouraged from working on such things. But supply chain issues and GPU price hikes for crypto have revealed that it's maybe not wise to rely on the status quo anymore. Here's a figure that shows just how far behind CPUs have fallen since Dennard scaling ended when smartphones arrived in 2007 and cost/power became the priority over performance:
https://www.researchgate.net/figure/The-Dennard-scaling-fail...
FPGA performance on embarrassingly parallel tasks scales linearly with the number of transistors, so more closely approaches the top line.
I did a quick search and found these intros:
https://www.youtube.com/watch?v=gJno9TloDj8
https://www.hackster.io/pablotrujillojuan/creating-a-risc-v-...
https://en.wikipedia.org/wiki/Field-programmable_gate_array
https://www.napatech.com/road-to-fpga-reconfigurable-computi...
Looks like the timeline went:
2000: 100-500 million transistors
2010: 3-5 billion transistors
2020: 50-100 billion transistors
https://www.umc.com/en/News/press_release/Content/technology...
https://www.design-reuse.com/news/27611/xilinx-virtex-7-2000...
https://www.hpcwire.com/off-the-wire/xilinx-announces-genera...
I did a quick search on Digi-Key, and it looks like FPGAs are overpriced by a factor of about 10-100 with prices as high as $10,000. Since most of the patents have probably run out by now, that would be a huge opportunity for someone like Micron to make use of Inflation Reduction Act money and introduce a 100+ billion transistor 1 GHz FPGA for a similar price as something like an Intel i9, say $500 or less.
Looks like about 75 transistors per gate, so I'm mainly interested in how many transistors it takes to make a 32 or 64 bit ALU, and for RAM or DRAM. I'm envisioning an 8x8 array of RISC-V cores, each with perhaps 64 MB of memory for 16 GB total. That would compete with Apple's M1, but with no special heterogenous computing hardware, so we could get back to generic multicore desktop programming and not have to deal with proprietary GPU drivers and function coloring problems around CPU code vs shaders.
But, for what it's worth, there do seem to be some practical considerations why your idea of a hugely parallel computer would not meaningfully rival the M1 (or any other modern processor). The issue that everyone has struggled with for decades now is that lots of tasks are simply very difficult to parallelize. Hardware people would love to be able to just give software N times more cores and make it go N times faster, but that's not how it works. The most famous enunciation of this is Amdahl's Law [2]. So, for most programs people use today, 1024 tiny slow cores may very well be significantly worse than the eight fast, wide cores you can get on an M1.
[1] https://chipyard.readthedocs.io/en/stable/Chipyard-Basics/in...
In single threaded programming you have almost infinite flexibility, you can acquire infinite resources in any arbitrary order. In multithreaded programming you must limit the number of accessible resources and the order is preferably well defined.
In my opinion expecting people to write parallel algorithms is too much, not because it is too difficult but rather because it has to permeate through your entire codebase. That is a nonstarter unless the required changes are not unreasonable.
The challenge then becomes, how do we let people write single threaded programs that can run on multiple cores and gracefully degrade to being single threaded the worse the code is optimized?
I don't have the perfect answer but I think there is an opportunity for a trinity of techniques that can be used in combination: lock hierarchies, STM and the actor model.
There is a unit of parallelism like the actor model that executes code in a sequentially single threaded fashion. Multiple of these units work in parallel, however, rather than communicating through messages, STM is used to optimistically execute code and obtain a runtime heuristic of the acquired locks. If there are no conflicts, then performance scales linearly, if there are conflicts, then by carefully defining a hierarchy of the resources, you can calculate the optimal level in the hierarchy to execute the STM transaction in. This will allow the STM transaction to succeed with a much higher chance which then eliminates the primary downside of STM: performance loss due to failed transactions whose failure rate creeps up the more resources are being acquired.
A lock hierarchy could look like this: object, person, neighborhood, city, state, country, planet.
You write an STM transaction that looks like single threaded code. It loops around all people in the times square and would thereby acquire their locks. However, if that transaction was executed on the object level, it would almost certainly fail because out of thousands of people only one needs to be changed by another transaction to fail. The STM transaction acquired a thousand people, therefore it's optimal level in the hierarchy is the neighborhood. This means only one lock needs to be acquired to process thousands of people. If it turns out that the algorithm needs information like the postal address of these people, it is possible that some of them are tourists and you therefore acquire resources that are all over the world, you might need to execute this transaction at the highest level of the hierarchy for it to finish.
The primary objection would be the dependence on STM for obtaining the necessary information about which resources have been acquired. This means that ideally, all state is immutable to make software transactional memory as cheap as possible to implement. This is not a killer but it means that if you were to water this approach down, then the acquired resources must be static, i.e. known at compile time to remove the need for optimistic execution. That still works and it lets you get away with a lot more single threaded code than you might think, especially legacy code bases.
But the big problem isn't really the hardware. You can go create and simulate a robust design in a number of HDLs, there are all kinds of tools to do it now, though they aren't as fancy as proprietary ones. It's doable. But it's having a good software stack that matters. You can blow a billion dollars on a chip and still lose because of the software. Nvidia figured this out 10 years ago and everybody else is still playing catch up.
And it takes an insane amounts of software engineering to make a good compute stack. That's why Nvidia is still on top. Luckily there are some efforts to help minimize this e.g. PyTorch-MLIR for ML users, though more general compute stack needs, such as accelerated BLAS or graph analytics libraries or OpenMPI, are all still "on you" to deliver. But if you stick your head in the sand about this very important point, you're going to have a bad time and waste a lot of money.
It sounds to me that the real problem is still that the ideal programming model hasn't been created yet.
What would it look like? Compile a C function into an FPGA pipeline? A dataflow language where you explicitly define processes and their implementation?
I mean imagine if you could take a mathematical formula, how would it translate into a series of additions, subtractions and multiplications? You could write it down in Fortran and then you would have a well defined and ordered tree of operations. Do we just translate that tree into hardware? Like, you have 100 instructions with no control flow and you just translate it into 100 ALUs? Does it make sense to reuse the ALUs and therefore have 100 instructions map to less than 100 ALUs?
If we assume the above model, then there are specific requirements for the hardware.
What if need more than one algorithm? Can I switch the implementation fast enough? Can the hardware have multiple programmed algorithms for the same ALUs?
Programmable ALUs sound awfully close to what a CPU does but in theory you would just have a register file with say 16 different ALU configurations and the data you are sending through the ALUs is prefixed with a 4 bit opcode that tells the ALU which configuration to use. We are getting further and further away from what an FPGA does and closer to how CPUs work but we still have the concept of programming the hardware for specific algorithms.
These are just random thoughts but they reveal that the idea of a pure FPGA is clearly not what the accelerator market needs.
That isn't actually true. It takes commitment to the platform. My AMD GPU from 2017 had its ROCm support dropped in 2021. Very nice. That sends a signal that ROCm isn't worth supporting by application developers. In other words, AMD decided that there are ROCm and gaming GPUs whereas with Nvidia there is no distinction.
RISC-V is maybe finally something that will stick because it can't be killed by a stupid company.
Also, if you are using a high-end RISC-V (none on the market currently), then the implementation is going to be proprietary and decidedly non-trivial.
I'm not sure in which sense you expect to "understand your computer".
> I'm not sure in which sense you expect to "understand
How about this? https://riscv.org/technical/specifications/ If there are a few extensions buried in the chip that doesn't materially change what I said.
In the class, there were competitions for the highest benchmark scores (in emulation) and highest ratio of benchmark score to gate count (again, in emulation). The high performance implementations end up having 5 stage pipelines with bypass networks to avoid having to wait for intermediate results to hit the register file. I remember even having the carry logic in my ALU alternate the sense of the carry at every level up the tree in order to save one gate delay at each level. My year, I don't think anyone implemented register renaming, but I wouldn't put it past some students.
I would love to see 6.004 switch from Beta to RISC-V and also for the Stanford compilers class to switch from MIPS to RISC-V.
After decades of open-source software, finally we have open-source CPU.
RISC-V is an open instruction set, so anyone can implement their own design using it, often with their own proprietary extensions.
Because the instruction set is open, there are indeed hundreds of open source RISC-V designs out there, because basic CPU design is fun, easy and educational.
However, at the moment, nearly all physical RISC-V CPUs you can actually buy, dev boards etc, and devices containing them, use closed source CPU designs.
Not bad at all for an open source core.
Dead how? I don't get it.
They're literally everywhere, dominating the numbers both shipping right now and cumulative.
Every new ISA of any significance in the last 3+ decades is RISC.
The only pre-RISC legacy ISA in use is x86, and it is only losing market share.
The only pre-RISC legacy ISA in wide use is x86, but AFAIK the legacy ISA from IBM mainframes (s390/s390x), which is still supported by mainstream enterprise Linux distributions, is also a pre-RISC one.
And for many generations now, x86 machines are basically RISC processors with a CISC frontend.
Empirically it seems that CISC has 'failed' as a way to design processors, and it's better to let the compiler do that job when you're building a general purpose computer.
We even had some false starts: when vector operations were first created, they were quite complex, then they were simplified into better reusable components; also when encryption operators started to appear, they were very complex, then they broken into much more flexible primitives. There is nothing really saying that we will be able to break down all kinds of operations forever.
But still, I wouldn't bet on any CISC architecture on this decade.
Anyway, the reason x86 lasted for so long was Moore's law. This is patently clear on retrospect, and obvious enough that a lot of people called it forward since the 90's. Well, Moore's law is gone now, and we are watching the consequences.
If you can break your specialized instruction into a few much more generic ones, it's probably a gain.
Other designs from the same time followed on from the wunderchild of the time - the Vax which everyone loved and wanted to emulate.
The big change of the time though was changes in memory hierarchy, caches pushed closer to CPUs (eventually got pulled on-die) which favoured less densely encoded ISAs more registers and instruction sets that didn't require a full memory access for every instruction.
In my professional life time we've gone from 'big' mainframes with 1MHz core cycle times (memory cost more than $1M/megabyte) to those Vax's (actual silicon dram!), to what's sitting on my lap at the moment (5Ghz 8/16 cores 64Gb dram etc).
I don't think CISC 'failed', it was simply a child of it's time and the constraints changed as we moved things from giant wirewrapped mainframes with microcode to minimise ifetch bandwidth, to LSI minicomputers to VLSI SOCs with multimegabyte on-chip caches
The reason for that is that a lot of features in a CPU instruction are just the result of toggling some part of the CPU on or off so having four one bit flags is better than encoding the same value in two bits. What this means is that you can have more possible instructions available on the uop layer than on the ISA layer. When that is the case you can hardly call the internal design a "RISC" processor. Especially when the ISA wars were specifically about ISAs and not microarchitecture. Even if we say that uops are RISC instructions that still is an argument against RISC ISAs because why bother with RISC as an external interface if you can just emulate it? Your comment seems rather one sided.
CISC or RISC is a characteristic of the ISA.
Usage of microops doesn't change the ISA. It is an opaque microarchitecture artifact.
No ISA/architecture licensing fees, no restrictions on what you can do with it - you can build an open source core or you could sell your design to others. ARM/x86 doest have this, its all locked up behind lawyers.
Scalable so the same ISA (with/without certain extensions) can be used from the smallest microprocessor to high end CPUs.
Compressed instructions gives very high code density (and unlike ARM Thumb doesn't require weird mode switching and is available for 64-bit ISA)
It's not the first popular open ISA. There was OpenRISC before it, but it was fatally flawed (branch delay slots). So RISC-V is arguably the first good popular open ISA.
Or is RISC-V stictly better than it?
RISC-V is more modular and and by now has far more support behind it.
If you want an OpenPOWER design to play with, look at Microwatt ( https://github.com/antonblanchard/microwatt ) which is complete enough to boot Linux.
ARM cores run most phones, routers, etc, and it's an acronym for Acorn RISC Machine.
This enables far more competing RISC-V implementations, with more choice and more ability to modify things to your needs.
On the downside you could see eco-system fragmentation and lots of subtle incompatibilities causing issues for broad software support.
Ultimately anything technical happening is secondary to this, this is the reason RISC-V is taking off, not anything to do with technical superiority (it simply needs to be good enough).
RISC-V doesn't have to displace M2/Epyc/Xeon to be important. There are a trillion cores a year being shipped in embedded devices where "cheap and configurable" is more important than raw performance.
What surprises me is that we haven't seen more "built to emulate" designs yet. Many of those "trillion cores" are zombie architectures with terrible price/performance ratios, but nobody wants to rewrite their software or retool things (anything 8051, AVR or PIC seems vulnerable). I could see replacement modules using a cheap-due-to-scale RISC-V core that just emulates the old chip in baked-in firmware.
RISC is hardly dead. It more accurate to say it won so comprehensively that it's pervasive. The design principles are now used in every significant chip (including x86).