Current & Short Term
Current builds reach an fmax of a whopping 10MHz-30MHz depending on options, but the remaining slow part seems to be mostly the ALU output (the rest was probably just my testing I/O).
This means if I’ve got my current assessment right then the design probably currently aligns with typical performance expectations for simple pipelined cores and should be able to be optimised further accordingly, maybe pushing to around 50MHz or higher (this depends on FPGA as well of course).
The extended options do still add additional drag, so there will probably need to be some delicate balance between “add every additional optimisation possible” and “try not to weigh down the design further leading to more complex logic or slower FPGA placements”.
The short term performance goal is to push it above or around 50MHz with more reliability testing and to come up with a plan for faster & more full featured models.
Towards 100+MHz: Two Options
My next real performance goal after making some smaller improvements will be either pushing over 100MHz or reaching equivalent performance some other way e.g.
- Either I keep extending the one main CPU core design and try to make it do everything and have every configuration option for every possible optimisation, convince everyone it’s the best design in the world, get it to run on every single FPGA model, get it manufactured on the latest equipment to push the performance, …
- Or, I market the 305/306 as the main design with efficient multithreading, but just pair it with alternative soft CPUs based on other open-source designs for other performance niches, all supported by the same software
Easy Option For Higher Single-Threaded Performance
Given that I’m largely limited by FPGA performance bounds as much as by my ability to keep simplifying pathways in the design, I think I can probably come up with a faster single-threaded alternative perhaps testing 32-bit/64-bit performance differences to see if I can easily juice higher clock speeds out of a 32-bit design (in theory this should cut out large parts of the slow stuff…).
My hypothesis is that the typical theory on 5-stage/6-stage cores is a leftover from 32-bit cores where maybe the ALU operations were proportionally less slow in relation to other processor mechanisms, whereas for 64-bit designs we probably need to break up the ALU or other internal calculations much more (breaking it into at least 7 stages). But I’m not sure yet, my current issues can probably be optimised away further in 64-bit too.
Leave a Reply