Hackr News App

<@dkjaudyeqooe> 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.

<@dkjaudyeqooe> 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.

<@dkjaudyeqooe> I don't know if that kind of collaboration has ever worked in chip design. It seems simpler for one company to design the core and license it out (which is the Arm business model).

<@dkjaudyeqooe> 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.

<@dkjaudyeqooe> > 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.

<@Pet_Ant> 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.

<@Pet_Ant> > 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> 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.

<@Pet_Ant> 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.

<@sylware> I suppose everything that isn't a toy implementation has a store queue.

Even the U54 Core Complex (later U54-MC) manual from August 2018 states in Section 3.4 "Stores are pipelined and commit on cycles where the data memory system is otherwise idle. Loads to addresses currently in the store pipeline result in a five-cycle penalty."

It probably inherited this from Rocket.

<@sylware> I'm pretty sure XiangShan has a store queue. I expect the other chips mentioned do too - as I understand it it's a standard optimisation.