Do you know how balanced your design is or are those choices mostly based on napkin estimates and guesses?
The ROB and PRF are bigger than what the K8 had. If I understand you correctly, Slice-1 can decode two instructions per cycle (and they don't expand to multiple internal instructions) and it can retire two per cycle. If I do, then that's less than the K8 (and K7, K6, and P6).
You are not clear about the ALU/AGU/branch resources that the OOO engine has. If it can execute two instructions per cycle then it's less than the K8. It doesn't say what limitations there are -- can it handle more than 1 branch per cycle? Can it handle more than 1 load/store per cycle?
I'm asking because I'm really curious, both about your choices and about how practical it is to estimate these things as an amateur. Do you have a performance model for your architecture or is the Verilog code everything, including the performance model? Do you have the ability to execute instruction traces to compare different microarchitectural choices?
Do you know if conflict misses are much of a problem? And if so, if a small victim cache would help enough to be worth it?
Do you know why the CSR block is so slow? Too much fanout because it needs to handle access to many CSRs? Would it make sense to make it a two-cycle block instead? Or split it into a single-cycle block for common CSRs and a two-cycle block for the rest (if you are really ambitious)?
Do you know why the AGU block is so slow? Isn't it just at most two numbers that need to be added together? Your ALU block can do it twice as fast. Is it sign extension for offsets? If so, can't you sign extend them before that block (parallel with register reads, perhaps)? Or because it doesn't use the fancy adder?
Why are the TLBs so slow? Is it partly because they are single-cycle? I mean, they are only 4-way so I'm a bit surprised.
I should make clear that I am not complaining, I'm just surprised at the relative estimated speeds of the blocks you have synthesized.
A block diagram in the style of chips and cheese would help a lot, btw. It doesn't need to have the fancy pastel colours, black and white is fine.
---
There are some pages you forgot to have the AI translate from Turkish:
This is the place to look for anybody wanting to know more about the microarchitecture. It's out of sync with the README but it has a lot more meat (details).
> Do you know why the AGU block is so slow? Isn't it just at most two numbers that need to be added together? Your ALU block can do it twice as fast. Is it sign extension for offsets? If so, can't you sign extend them before that block (parallel with register reads, perhaps)? Or because it doesn't use the fancy adder?
It doesn't use the fancy adder. I also noticed that there are two implementations of the fancy adder (they are different) and they are inlined into rtl/core/fursoy_s1_alu.sv and rtl/core/fursoy_s1_branch_unit.sv
That one was easy!
> Do you have a performance model for your architecture or is the Verilog code everything, including the performance model?
The Verilog code is indeed everything, including the performance model. There's a module that handles performance counters: rtl/core/fursoy_s1_hpm.sv
The Verilator test bench(es) dump(s) the performance counters at the end of a run.
> Do you have the ability to execute instruction traces to compare different microarchitectural choices?
Seemingly not. There's only real execution using real memory/IO access and real interrupts from real devices.
---
If anybody else is following along at home: there are apparently two RISC-V implementations: Slice-0 and Slice-1. Slice-0 is a dead simple single-scalar in-order CPU with two stages (fetch and execute). It does have TLB(s?) and caches so it's not entirely simple. Slice-1 is the OOO CPU (fetch/decode/execute/retire widths: 2/2/3/2, 10 stages). They are sometimes abbreviated as s0 and s1.
There are Verilator test benches but there's no model checking.
It looks like Slice-1 is still quite early in its development. I bet the code will be cleaned up (with the two Kogge-Stone adders merged into one and moved to a separate module, for example, or the ITLB being in a module of its own but the DTLB dumped inside the load-store unit module) and optimized further. Also tested further, of course. It doesn't seem like floating-point and vectors have received much testing love yet, for example.
The code seems very straightforward and readable (as much as Verilog can be readable -- I have seen far worse code do far less) but not well-commented. The doc files for each module are a bit too short and assume too much knowledge about the microarchitecture to be known already. Perfectly fine for a solo project, too cryptic for others to read.
There are still some LaTeX issues, for example section 2.2.3 in slice1-core-v1.md.
At least it doesn't error out, it's just a rendering thing. I don't know why the rendering is wrong, it looks to me like you did it correctly in the markdown file.
> and slice1-core-v1.md drifting from the README. I cleaned those up in the repo and added an ASCII pipeline diagram along with an explicit execution-port breakdown in the README
There's a bit more to sync up in slice1-core-v1.md. It only mentions F1 and F2, for example, and it also says "10-stage". Of course, you can always claim that the word "conceptual" covers you there.
The README is much better now. I see now that I misunderstood both the pipeline length (fetch takes more stages than I thought) and the width of the OOO part.
I did see some mentions of SRAM and that it wasn't done yet but I hadn't caught on to it affecting the way the TLBs were handled. Of course they are slow at the moment! That also explains why you haven't bothered to show the synthesis of the caches (and I guess the load/store queues -- well, all queues, really).
cpu.fursoy.com looks pretty (and very AI generated) and there is indeed a link to it on the github page, but I had no idea there would be anything useful there. It should probably also be mentioned in the README.
I'm going to play around a bit with cpu.fursoy.com and maybe report back later.
Good luck with the project!
(Your post was flagged and dead for some reason, btw.)
> the hardware PTW snoops dirty L1D sets non-destructively so Linux page-table updates are visible directly
Neat! Andy Glew has talked about wanting the TLB hardware to snoop on page table updates for a long time. I don't think he ever got to implement it in a shipping CPU, though.
Have you considered doing TLB invalidation on other cores without needing IPIs? Perhaps by extending an MOESI-style cache protocol a bit?
If the fuel (+ oxidizer) ends up costing as much as 1% of the cost of launching a conventional single-use rocket then the people behind it will be very happy. That means that their rocket (+ cost of ground facilities + all the people prepping the rocket and monitoring the launch) is very cheap.
The fuel (+ oxidizer) is basically free compared to all the other costs.
The two big causes of homelessness are substance addiction and craziness. Semaglutide is the first medical intervention that can help to some extent with the desire part of addiction.
Electric brain stimulation is likely able to help with mood disorders. Maybe even OCD and schizophrenia. If nothing else, proper measurements (lots of good data) of both healthy brains and mentally ill brains should help. We've had almost none of that, with EEGs being rather pathetic.
Nobody is going to "solve" homelessness tomorrow or next year. Not the people who think they can just spend more money -- someone's money, not their own, not the people who think charity is the way forward, and not the people who think what is needed is cures.
We can do some almost immediately if we are willing to institutionalize more people but it's not a good or complete solution and we aren't willing to, anyway.
The real improvements are likely to eventually come from things like semaglutide (and more likely more research into the instincts that drive addiction, now that we finally have a molecule that can affect them) and things that both provide data (that we sorely need) and can provide interventions directly in the brain.
Still waiting on the promised $25,000 EV though. If Neuralink is anything like American EVs, psychiatric patients might as well move to China for treatment.
Probably easier to "just" emulate the LaserWriter. The firmware for some of the models is available, the 68K/68020 emulator can be downloaded from somewhere, and the rest is actually documented well enough for some models that writing an emulator is a very realistic prospect.
It's now been true for longer than we have had VLSI memory.
RAM chips won out over core memory in the early 70's. We've had caches to compensate for the relative slowness of memory since around 1990. That's for mainstream computers (486, Pentium). Mainframe computers have had caches for longer.
reply