[HN Gopher] Open-Source RISC-V: Energy Efficiency of Superscalar...
___________________________________________________________________
Open-Source RISC-V: Energy Efficiency of Superscalar, Out-of-Order
Execution
Author : PaulHoule
Score : 42 points
Date : 2025-06-16 16:46 UTC (6 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| Pet_Ant wrote:
| > some (e.g. BOOM, Xiangshan) are developed in Chisel with
| limited support from industrial electronic design automation
| (EDA) tools
|
| Isn't translating between languages something that LLMs should
| excel at? I mean I'm sure it's more than just pasting it into
| ChatGPT but if the design has been validated and it's understood,
| validating the translated version should be several orders of
| magnitude easier than starting from scratch.
| dkjaudyeqooe wrote:
| > Isn't translating between languages something that LLMs
| should excel at?
|
| No, not at all. Unless there is a large amount of training data
| relevant to the translation then LLMs are likely just to make
| up nonsense. Chisel is a very niche hardware description
| language.
| Pet_Ant wrote:
| Very niche? That's suprising to hear. I'm not in the space,
| and I know it's not in the big 2/3 (is SystemVerilog distinct
| from Verilog), but it's been around for 13 years and even
| DARPA has it on their radar:
|
| > Chisel is mentioned by the Defense Advanced Research
| Projects Agency (DARPA) as a technology to improve the
| efficiency of electronic design, where smaller design teams
| do larger designs. Google has used Chisel to develop a Tensor
| Processing Unit for edge computing
|
| [0] https://en.wikipedia.org/wiki/Chisel_(programming_languag
| e)#...
| bee_rider wrote:
| I wonder if they just mean niche in the context of
| languages generally--human or programming? I mean there
| are, relatively speaking, boatloads and boatloads of open
| source software projects out there. Hardware open source
| projects, well a few exist...
| zozbot234 wrote:
| Chisel can be compiled to Verilog out of the box, and Verilog
| itself should have the required support from existing EDA
| tools. That remark from the paper may perhaps be somewhat
| confused.
| IshKebab wrote:
| This is true, but unless great care is taken to generate
| _nice_ Verilog you 're going to run into issues when you try
| to integrate standard tools like functional coverage, formal
| SVA, etc.
|
| I haven't looked at the Chisel SVA but I do recall another
| HDL touting readable Verilog generation as a feature in
| response to Chisel's being bad (can't remember which one) so
| I guess it can't be great.
|
| I think Veryl stands a decent chance of success precisely
| because it hews so closely to SystemVerilog - you don't lose
| access to all the feature industry uses. It's kind of the
| Typescript of SystemVerilog.
|
| https://veryl-lang.org/
| eigenform wrote:
| I'm not sure this sentence [from the paper] makes a lot of
| sense. The only thing non-standard is the use of Chisel (and
| then probably CIRCT to lower it into Verilog) - if you're
| actually taping these out, you're still feeding that to
| industry-standard EDA tools.
| dlcarrier wrote:
| To the contrary, it's something especially suited to being done
| parametrically. Effectively, you can make a really big regex
| string to convert one language into a subset of another, then
| let the optimizer of the second language make it performant.
| dkjaudyeqooe wrote:
| 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.
| kimixa wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-16 23:00 UTC)