Comment by Taniwha | Hacker News Reader

Comment by Taniwha | Hacker News Reader

Parent Full thread

I think they're great - I earned my VLSI chops building stuff in the 90s and I can write Verilog about as fast as I can think so it's my goto language. I've also written a couple of compilers over the years so I know it really well (you can thank me for the '' in "always @()"). That's just my personal bias.

Inertia in tooling is a REALLY BIG deal - if you can't run your design through simulation, (and FPGA simulation), synthesis, layout/etc you'll never build a chip - it can take a 5-10 years for a new language feature to become ubiquitous enough so that you can depend on it en ough to use it in a design (I've been struggling with this using System Verilog interfaces this month).

If you look closely at VRoom! you'll see I'm stepping beyond some Verilog limitations by adding tiny programs that generate bespoke bits of Verilog as part of the build process - this stops me from fat fingering some bit in a giant encoder but also helps me make things that SV doesn't do so well (big 1-hot muxes, priority schedulers etc)

Possibly crazy thought. With wider CPUs needing more ports (read and write) on the register file, would it make sense to use accumulators as registers so basic boolean and math ops could be done locally with a single read port that the alu could tap?

Modern CPUs have a structure called the bypass network that lets different ALUs forward their outputs to another's inputs without having to hit the register file. It's not exactly like a local accumulator but it's something in the same direction.

Modern OoO CPUs solve the need for more physical registers than logic registers with renaming. https://docs.boom-core.org/en/latest/sections/rename-stage.h...

Yes VRoom! with renaming has as many registers as it has commitQ entries plus the architectural ones. So 64/32 + 31 (integer) + 32 (fp) + 32 (vector)

The idea was to have as many simple ALUs as registers. Results are kept in the ALU/register. All reads are essentially result forwarding. For example a simple RV32I requires 2 read ports and one write port on each register. If we use 2 R/W ports and put an ALU on each register, you reduce from 3 to 2 busses and can also do operations 2 at a time when an instruction clobbers one of its inputs. Or an ALU op along with a load/store.

err HN swallowed my * there as in: "(you can thank me for the '*' in "always @(*)")"

Reply on news.ycombinator.com