I don't think that's quite fair - this guy is clearly quite familiar with CPU design, it's very easy to run coremark, dhrystone, etc. to get a decent idea of performance, and for verification there's a reference model written in Sail you can compare against (though tbf it sounds like he didn't). AI is good at writing large test corpuses these days too.
So I would say it is relatively easy to tell if a vibe coded RISC-V CPU is actually good today. It's not like non-vibe coded RISC-V CPUs were amazingly well verified before anyway (except Ibex anyway). Even CVA6 has had some embarrassing bugs.
I expect this is a decent RISC-V core, but I also expect I could make one just as easily.
I do know about physical design too. Just because somebody doesn't explain every single thing in a comment doesn't mean you win the argument by highlighting something they didn't mention.
I built Fursoy Slice-1, a 64-bit out-of-order superscalar RISC-V core (RV64IMAFDV + Zba/Zbb/Zicsr/Zifencei) in SystemVerilog, along with a minimal SoC (5-master crossbar, CLINT, PLIC, 16550 UART, and custom SBI v2.0 firmware).
At a high level, the core is 2-wide fetch/decode/rename/retire with a 128-entry ROB, 160-entry integer PRF, 8 branch checkpoints for single-cycle speculative RAT rollback, and separate Int/Mem/FP/Vec issue queues. On the memory side, it has a dual-port Sv39 DTLB (64-entry 4-way Tree-PLRU + 8-entry 2 MiB/1 GiB superpage CAM), ITLB, and a 16 KiB 8-bank non-blocking L1D. Instead of flushing dirty lines on every page-table walk, the hardware PTW snoops dirty L1D sets non-destructively so Linux page-table updates are visible directly, paired with store-queue drain on SFENCE.VMA.
In Verilator, it boots mainline Linux 6.6.50 and BusyBox userspace in ~89.8M cycles (~76.2M retired instructions, 2,255 page faults handled) while checking an 8-bucket single-owner CPI conservation invariant every cycle with 0 cycle leakage. Synthesizing the 8 main core logic blocks standalone with sv2v + Yosys + OpenSTA on Nangate 45nm (SRAMs/PRFs black-boxed, pre-P&R) meets 500 MHz across all 8/8 blocks at ~219 kGE, after rebuilding the ALU and branch unit as Kogge-Stone prefix trees and balancing high-fanout CSR/TLB paths.
I used an AI-agent-assisted workflow for RTL iteration and verification scaffolding while driving the microarchitecture, timing closure, and debugging myself. The nastiest late bug was a Linux boot livelock around ~90M cycles: per RISC-V Priv Spec §3.1.9, CSR read-modify-write instructions on `mip` have to operate on the software-writable `mip_q[9]` bit rather than the live `irq_seip_i` wire—our CSR block was feeding `mip_val` back into RMW, so whenever SBI cleared `STIP` while a PLIC IRQ was high, it permanently latched `SEIP` and trapped the kernel in `plic_handle_irq`.
For folks who have built Sv39 cores or open-source ASIC flows: do you prefer letting the PTW snoop dirty L1D lines directly like this, or forcing a clean/drain path? Also curious what people would tackle next on a single-core tree like this—an inclusive L2 cache or jumping straight to dual-core coherency.
True, just writing some SystemVerilog that can be simulated does not guarantee working hardware. The OP does point out that he took it all the way to a netlist targeting a real hardware library. Place and route and actual fabrication, or building it for an FPGA and testing there are still needed to fully prove the design, but if the synthesis tools he used are reliable then there's not a lot of room for it to fail at this point. The clock speed is based on the netlist only, so it'll probably not be that fast after actual place and route, so it'll probably have to be clocked a little slower than 500 MHz, but it should work
Who hurt you? This is a fantastic project with effort put into simulating the RTL against a PDK. I don’t understand why you would gate your approval. If someone showed off a game on HN would you say it wasn’t a real game until you could buy it at your local Best Buy or GameStop?
Do post it on Reddit in https://www.reddit.com/r/RISCV/
I have seen more excitement and community around these kinds of projects there than here.
Doing OOO in a one-person project is impressive.
Maybe 6 months ago. Today anyone vaguely familiar with CPU design can do it.
Lol it's always cute to see the amount of confidence that people have for AI when they can't tell if the work it did is actually good.
I don't think that's quite fair - this guy is clearly quite familiar with CPU design, it's very easy to run coremark, dhrystone, etc. to get a decent idea of performance, and for verification there's a reference model written in Sail you can compare against (though tbf it sounds like he didn't). AI is good at writing large test corpuses these days too.
So I would say it is relatively easy to tell if a vibe coded RISC-V CPU is actually good today. It's not like non-vibe coded RISC-V CPUs were amazingly well verified before anyway (except Ibex anyway). Even CVA6 has had some embarrassing bugs.
I expect this is a decent RISC-V core, but I also expect I could make one just as easily.
I don't think chip design comes down to knocking out a theoretically correct design. Then you fab it and it can't run at more than 37mhz LOL.
I think you don't know what you don't know here.
I wish you’d use your knowledge to add to the discussion rather than discourage others.
I do know about physical design too. Just because somebody doesn't explain every single thing in a comment doesn't mean you win the argument by highlighting something they didn't mention.
and a bit of cloude:
"Make me an OOO RISC-V core in SystemVerilog. No mistakes."
I am somewhat of vaguely familiar with CPU design myself.
I built Fursoy Slice-1, a 64-bit out-of-order superscalar RISC-V core (RV64IMAFDV + Zba/Zbb/Zicsr/Zifencei) in SystemVerilog, along with a minimal SoC (5-master crossbar, CLINT, PLIC, 16550 UART, and custom SBI v2.0 firmware).
At a high level, the core is 2-wide fetch/decode/rename/retire with a 128-entry ROB, 160-entry integer PRF, 8 branch checkpoints for single-cycle speculative RAT rollback, and separate Int/Mem/FP/Vec issue queues. On the memory side, it has a dual-port Sv39 DTLB (64-entry 4-way Tree-PLRU + 8-entry 2 MiB/1 GiB superpage CAM), ITLB, and a 16 KiB 8-bank non-blocking L1D. Instead of flushing dirty lines on every page-table walk, the hardware PTW snoops dirty L1D sets non-destructively so Linux page-table updates are visible directly, paired with store-queue drain on SFENCE.VMA.
In Verilator, it boots mainline Linux 6.6.50 and BusyBox userspace in ~89.8M cycles (~76.2M retired instructions, 2,255 page faults handled) while checking an 8-bucket single-owner CPI conservation invariant every cycle with 0 cycle leakage. Synthesizing the 8 main core logic blocks standalone with sv2v + Yosys + OpenSTA on Nangate 45nm (SRAMs/PRFs black-boxed, pre-P&R) meets 500 MHz across all 8/8 blocks at ~219 kGE, after rebuilding the ALU and branch unit as Kogge-Stone prefix trees and balancing high-fanout CSR/TLB paths.
I used an AI-agent-assisted workflow for RTL iteration and verification scaffolding while driving the microarchitecture, timing closure, and debugging myself. The nastiest late bug was a Linux boot livelock around ~90M cycles: per RISC-V Priv Spec §3.1.9, CSR read-modify-write instructions on `mip` have to operate on the software-writable `mip_q[9]` bit rather than the live `irq_seip_i` wire—our CSR block was feeding `mip_val` back into RMW, so whenever SBI cleared `STIP` while a PLIC IRQ was high, it permanently latched `SEIP` and trapped the kernel in `plic_handle_irq`.
For folks who have built Sv39 cores or open-source ASIC flows: do you prefer letting the PTW snoop dirty L1D lines directly like this, or forcing a clean/drain path? Also curious what people would tackle next on a single-core tree like this—an inclusive L2 cache or jumping straight to dual-core coherency.
Very cool. Any plans to have this fabbed? Or built into a bitstream for an FPGA?
Nice try but Verilog is not real hardware. I hate projects like that - you didn't produce new cpu- you just emulate it.
Build it and then I would be fan number 1!
True, just writing some SystemVerilog that can be simulated does not guarantee working hardware. The OP does point out that he took it all the way to a netlist targeting a real hardware library. Place and route and actual fabrication, or building it for an FPGA and testing there are still needed to fully prove the design, but if the synthesis tools he used are reliable then there's not a lot of room for it to fail at this point. The clock speed is based on the netlist only, so it'll probably not be that fast after actual place and route, so it'll probably have to be clocked a little slower than 500 MHz, but it should work
I'm not sure what you consider real. Verilog or System Verilog is used industry wide to describe hardware that then becomes chips.
YoU wOuLdN'T dOwNlOaD a CpU!1!!
Who hurt you? This is a fantastic project with effort put into simulating the RTL against a PDK. I don’t understand why you would gate your approval. If someone showed off a game on HN would you say it wasn’t a real game until you could buy it at your local Best Buy or GameStop?