3 ms·
As you point out current VROOM! is 4-8 into the decoder depending on the mix of incoming instructions, each decode block can decode one 32-bit instruction, or 2
by Taniwha 3y ago
As you point out current VROOM! is 4-8 into the decoder depending on the mix of incoming instructions, each decode block can decode one 32-bit instruction, or 2 16-bit ones.
A VERY general rule of thumb is that every 5th instruction is a branch, decoding more than 8 may be pointless
However VROOM! can replay 8 instructions per clock out of the trace cache .... (they're already decoded and get pushed into the pipe after the decoders)
- sweetjuly 3y agoHey! I looked at your blog and loved your bug analysis, it's extremely rare to see this stuff publicly but I'm excited for more as the FOSS CPU scene speeds up. Hopefully the wide decode will be more useful when trace cache lands. Is VROOM primarily targeting ASICs of FPGAs? I know BOOM is primarily meant for ASICs but I feel like there is still a lot of room to build a good OoO FPGA core, particularly since us mere mortals can't get a spot on a wafer big enough to support even the smallest configs of BOOM (or presumably VROOM) since the efabless Sky130 shuttles, while "affordable", are hardly big enough to most OoO cores. I've been thinking about taking the ideas from this paper [1] and adding it to BOOM to try and make it more FPGA friendly since that seems like the most realistic way to get a very high performance custom core at this point. [1] https://ieeexplore.ieee.org/document/8977924/ https://ieeexplore.ieee.org/document/8977924/
- Taniwha 3y agoI've previously been an ASIC designer, so that's what I've been aiming it at. FPGAs are just a great way to find bugs (you'll notice I've spent no time on performance) though now the design is too big for even that I've been assuming that anyone building one would be building hand built data paths/register files/caches/TLBs/etc largely because I've come from that world