Comment by dkjaudyeqooe 3 days ago
I feel like an open source RV CPU is very likely in the high-performance space.
The amount of effort required to design and implement such a device makes it difficult for a single company to invest in, but many interested users of it could band together to create a viable open source implementation.
I guess it's a question of a project that such an effort can crystalize around.
I don't think open source will be getting anywhere near leading edge in the near future, but I feel like a really good n12 or n7 chip might be possible. That would be enough to get to ~Zen1 levels of performance (or maybe a bit higher since we know Zen1 had some fairly avoidable mistakes)
In a way I am not too worried about the ISA, but having a set boot system that you can target the system with. This is where x86 still wins and ARM have dropped the ball. You can boot something like FreeDOS on an 8086 or the latest i9 with the exact same code base thanks to BIOS compatibility. But with ARM you are looking at hundreds of different targets.
The issue with ARM looks to be creeping into Risc V because anyone can make an additional processor entirely to their own target. For better or worse.
A standard boot target is much more useful to the end user than an open chip behind yet another boot standard. That I am praising the mediocre and closed x86 for this is a little showing of how bad the situation can be.
> The amount of effort required to design and implement such a device makes it difficult for a single company to invest in, but many interested users of it could band together to create a viable open source implementation.
There are lots of companies that have their own high-performance accelerator cores (though not general purpose). Multiple generations. Eg every FAANG (except Netflix, that I know of).
There are exactly zero such OSS cores.
So I think you have this exactly backwards.
Unfortunately, a lot of the architecture is decided by your technology node as well as library. Examples include cache architecture as well as performance-power tradeoffs. There are thousands of standard cells in libraries now, and that's all custom tuned for each technology node.
Don't forget how much of a "high-performance" implementation is due to the physical implementation, a lot of engineering effort is put into that post-HDL. And much below HDL is hard to share, as it relies too much on (closed) fab IP libraries and PDK specifics. And then the verification of that result.
Which might discourage an Open Source hardware project with shared ownership as large as a high performance implementation would require - as each cooperating company would end up using rather different products anyway.
I fear it'll become just an "Dump Over The Wall An Old Snapshot" of a few different companies work at best, rather than true cooperation.