VRoom A high end RISC-V implementation
moonbaseotago.github.io
VRoom A high end RISC-V implementation
1–10 of 135 posts
Re: VRoom A high end RISC-V implementation
#2The Architectural presentation linked from the GitHub repository for this project is an incredibly good resource on how these kinds of things are designed.
Re: VRoom A high end RISC-V implementation
#3The architectural details here were pretty interesting:
https://moonbaseotago.github.io/talk/index.html
It would be nice to get actual performance numbers rather than just frequency scaled Dhrystone but I suppose we have to be patient.
Re: VRoom A high end RISC-V implementation
#4What does GPL mean for a chip design?
I understand how it applies to the HDL, but I doubt that it obligates you have to open your code to users of physical chips.
Re: VRoom A high end RISC-V implementation
#5The Architectural presentation linked from the GitHub repository for this project is an incredibly good resource on how these kinds of things are designed.
Yes, there is a huge lack of open and approachable information sources in micro-architecture.
Be aware though, the micro-architecture used here is very interesting but differs in many ways from state of the art industrial high-end micro-architectures for superscalar out-of-order speculative processor.
I am quite curious about how the author came up with these choices
Re: VRoom A high end RISC-V implementation
#6What does GPL mean for a chip design? I understand how it applies to the HDL, but I doubt that it obligates you have to open your code to users of physical chips.
IANAL, but as far as I know it's very important it's GPLv3 which means the antitivoization clause, which means that hardware that uses this firmware must provide full source code and a way to let you use your own firmware.
If somehow this code is not in a firmware... No idea.
Re: VRoom A high end RISC-V implementation
#7What does GPL mean for a chip design? I understand how it applies to the HDL, but I doubt that it obligates you have to open your code to users of physical chips.
Also IANAL, but as I understand it, the HDL would compile down to a sequence of gates, and presumably we'd treat that the same way as a binary - a "Non-Source Form" as the GPL calls it. So anyone that receives a copy of those gates (either as a binary blob for a FPGA, or pre-flashed on a FPGA, or made on actual silicon) would be entitled to the source as per GPL3 section 6 "Conveying Non-Source Forms".
I don't think the GPL anti-tivoization clause has much bearing there other than presumably you'd have to provide the full tool chain that resulted in the final gates - presumably this would affect companies producing actual chips the most since you couldn't have any propriety optimization or layout steps in producing the actual chip design, though also no DRM for FPGAs (is that even a thing?)
Re: VRoom A high end RISC-V implementation
#8This is a very ambitious project, so respect and good luck.
I am wondering if the performance will pan out in practice, as it doesn't seem to have a very deep pipeline, so getting high clockspeeds may be a challenge. In particular the 5 clock branch mispredict penalty suggest the pipeline design is fairly simple. Production CPUs live and die by the gate depth and hit/miss latency of caches and predictors. A longer pipeline is the typical answer to gate delay issues. Cache design (and register file design!) is also super subtle; L1 is extremely important.
Re: VRoom A high end RISC-V implementation
#9Any recommendations for resources on learning to makes things like this in general?
Re: VRoom A high end RISC-V implementation
#10Any recommendations for resources on learning to makes things like this in general?
Computer Architecture: A Quantitative Approach[1] is the textbook that gets recommended the most on the topic, I believe.