Introduction Last time we talked about how we would approach building our RISC-V vector instruction implementation, here we’re going to talk a bit more about how we plan on doing it. Background We selected an initial design where the renamer breaks each vector instruction into multiple beats - issuing cloned copies of the instruction into the commitQ. This has the advantage that they can then be…
Introduction We’ve started work on our vector support, trying to figure out how to fit it into our existing design, this blog entry is about a couple of possible ways to implement RISC-V’s vector instruction set on VRoom! and the tradeoffs between them. Background First a reminder of how our basic architecture works: Instructions are decoded, renamed and the inserted into the commitQ. ALUs are…
Introduction We’ve been working on the Trace Cache - if you read back a couple of blog entries you will remember that it was performing better than not having a trace cache - but suffered from mispredicted branches (while equivalent non trace-cache cases didn’t). Now we’ve upgraded the trace cache to include some local prediction history - it gives us another 10% performance bringing our Dhrystone…
Introduction The last couple of weeks we’ve been running and writing regression tests - found some interesting bugs …. Our current full regression testing regime takes ~18 hours. Trace Cache The hardest problem to track down was in one of the generic RISC-V compliance tests - the test ran OK and generated the correct output, but the actual output phase generated an extra new line between each line…
Introduction Last week we found some Dhrystone performance we’d left unreported from when we had implemented the B instructions, but largely for a couple of months now our performance has been limited by the issue rate in the fetch/decode stages, in Dhrystone this is limited by the branchy nature of the instruction stream. This week we resurrected our broken trace cache and got a further 5%…
Introduction This week we’ve done some more experiments in macro op fusion, and found an unrelated surprising performance boost - ~12% to 9.76 DMips/Mhz - almost at 10! Limits A reminder from last time, we’ve set some limits on our macro op fusion experiments: we’re going to avoid creating new instructions that would require adding more read/write register ports to ALUs we’re also going to avoid…
Introduction Spent some time this week experimenting with macro op fusion. Many of the arguments around the RISCV ISA have been addressed with “you can solve that with macro op fusion” which is the idea that you can take adjacent instructions, next to each other, in an instruction stream and merge them into a single instruction that by itself can’t be expressed directly in the instruction set.…
Introduction Over the past few weeks we’ve announced a bunch of new VRoom! incremental performance increases, this week we found another To recap One of the fixes we’d found a couple of weeks ago was able to pull in an extra clock from the load data path - essentially our commit Q entries predict when an instruction will be completed a clock before the data becomes ready, this way the instructions…
Introduction Last week we announced a new Dhrystone number 7.16 DMips/MHz at an average ~2.8 IPC (instructions per clock) - we keep quoting DMips/MHz because it’s a great number for measuring what a particular architectural implementation can do. IPC is more specific it tells us something about how our particular architecture is doing - in our case we can peak issue 8 instructions per clock (if we…
TLDR After the past new work we went to spend some time just going over the core pipes at the micro level looking to make sure we hadn’t broken anything - and found something that’s been broken since we rewrote the load/store unit. Essentially the commit units are usually able to predict when an instruction will be completed one clock ahead of when its resulting data will be available to be…
Introduction With FP out of the way the decks have been cleared and we’re quickly moving along, rapidly adding support for more ratified extensions. Lots of new stuff here today! Results - new Dhrystone numbers ~6.74 DMips/MHz - increased by ~5% Note: we use the term “crypto” here - in this context it has all to do with cryptography and absolutely nothing to do with cryptocurrencies. Bitfield…
Introduction We finally finished the FP unit, it passes all the compliance tests and our extended FP data tests. Exceptions After finishing the sub-FP functional units (add/multiply/div) the one main missing piece was generating exceptions - on a RISC-V CPU FP exceptions are not system traps, they are accumulated bit masks in the CSR unit - generating them is not hard, getting them correct is…
Introduction This blog entry is about floating point divide and square root and in particular the algorithms we use. Divide So let’s talk about how we do division - starting with integer divide - in the multiplier unit we use a pretty simple integer divide algorithm, essentially it’s the the same algorithm we all learned in primary school - a 64-bit unsigned divide goes something like: count = 64;…
Introduction Work has slowed, we’ve not been getting a lot of time to work on FP …. this is an update as we move from one part of the FP unit to the next. New Stuff Most of the work in the past couple of months has been a rewrite of the multiplier to add fused multiply-add to the FP ALU - in the end this involved pulling the whole thing apart and a major rewrite, this is now done. At the same time…
Bugs A quick note, still working on FP, but spent some time fixing bugs - thanks to Hirosh who’s been playing with VRoom! I went back and ran some old code fragments and discovered they locked up, that led to rerunning our standard set of regressikons we used before switching to running linux on AWS - turns out a lot of code to do with fence instructions and load conditional instructions were…
Introduction We started work on FP quite a while ago - building an FP adder and multiplier, that part of the design had previously passed a few million test vectors but has been sitting on the shelf. What we’re working on now is integrating these blocks along with the missing instructions into a schedulable FP unit, N of which can then be added to a VRoom! - we’re not done yet so this blog post is…
Introduction The past few weeks we’ve been working on two relatively simple changes in the register renamer: renaming registers known to be 0 to register x0, and optimizing register to register moves. These are important classes of optimizations on x86 class CPUs, a real hot topic - previously I worked on an x86 clone where instructions were cracked into micro-ops - lots of these moves were…
Introduction It’s been a couple of months since I last posted about our work on a trace cache for VRroom, it’s become a bit of slog - trace cache bugs are the worst: suddenly out of nowhere your code branches off into the weeds, often caused by something that happened tens of thousands of clocks before. Short story, we’re pausing work on my trace cache implementation to get more important stuff…
Introduction I’ve spent the past month working on adding a trace cache to VRoom! - it’s not done yet but is mildly functional. Here’s a quick write up of what I’ve done so far. What is a Trace cache? Essentially a trace cache is an instruction cache of already decoded instructions. On a CISC CPU like an Intel/AMD x86 it might contain RISC-like micro-operations decoded from complicated CISC…
Introduction Wow, this was a fun week VRoom! made it to the front page of HackerNews - for those new here this is an occasional blog post on architectural issues as they are investigated - VRoom! is very much a work in progress. This particular blog entry is about a recent exploration around the way that we handle branches and ALUs. Branch units vs ALU units The current design has 1 branch unit…
Introduction Not really an architectural posting, more about tooling, skip if it’s not really your thing, also new some performance numbers. New Performance Numbers I found the bug in the BTC - mispredicted 4-byte branches that crossed a 16 byte boundary (our instruction bundle size) this is now fixed and we have better dhrystone numbers: 6.33 DMIPS/MHz at an IPC of 2.51 - better than I expected!…
Introduction I’ve not posted in 2 months, mostly because I’ve been spending time redesigning the load/store unit this posting is about these changes. This is a long post, but then I’ve been doing a lot of work. The problem Back when I was bringing up Linux on the system I spent a lot of time looking at low level assembler trace, watching instructions flow through the CPU it became obvious that one…
Introduction Booting Linux isn’t going to work without some form of virtual memory, RISC-V has a well defined spec for VM, implementation isn’t hard - page tables are well defined, there’s nothing particularly unusual or surprising there L1 TLBs We have separate Instruction and Data level one TLBs, they’re fully associative which means that we’re not practically limited to power of two sizes…
Introduction I started doing VLSI design in the early ’90s building graphics accelerators at 2um and later in the decade building CPUs at 1.8u-0.5u - gates and pins were expensive - we once bet the company on the viability of a 208 pin plastic package, something that paid off magnificently. I started this project with the vague idea of “what happens if I throw a lot of gates at it?” - my original…
Introduction A short post this week about physical memory layout and a little bit about booting. I’ll talk more about virtual memory another time Physical memory layout We currently use a 56-bit physical address, this is the address used with the MMU disabled or after a virtual address has been translated. Addresses with bit 55 (the most significant bit) set to 0 are treated as cacheable memory…
Introduction This week we’re going to try and explain as simply as possible how our core architecture works. Here’s an overview of the system: The core structure is a first-in-first out queue called the ‘commitQ’. Instruction-bundles are inserted in-order at one end, and removed in-order at the other end once they have been committed. While in the commitQ instructions can be executed in any order…
This is the third of an occasional series of articles on the VRoom!/RVoom RISC-V CPU. This week a shorter update, we’re going to talk about how we can create speculative entries in the Branch Target Cache (BTC) call-return stack. A quick reminder of some of what we learned in the previous blog. we decode large bundles of many instructions every clock we predict bundles not instructions we maintain…
This is the second of an occasional series of articles on the VRoom!/RVoom RISC-V CPU. This week we’re going to talk about how we can create speculative entries in the Branch Target Cache (BTC). A quick reminder of some of what we learned in the previous blog. we decode large bundles of many instructions every clock we predict bundles not instructions System Architecture Let’s have a look at an…
This is going to be the first of an occasional series of articles on the VRoom!/RVoom RISC-V CPU. I’m going to start with issues around the Branch Target Caches (BTC). Until recently our BTC has been pretty broken - this was a good thing as it forced our core to exercise its partial pipeline shootdown logic a lot - experience tells us that this is where one finds the hardest bugs ….. Now that it’s…
Executive Summary Very high end RISC-V implementation – goal cloud server class Out of order, super scalar, speculative RV64-IMAFDCHB(V) Up to 8 IPC (instructions per clock) peak, goal ~4 average on ALU heavy work 2-way simultaneous multithreading capable Multi-core Early (low) dhrystone numbers: ~3.6 DMips/MHz - still a work in progress. Goal ~4-5 Currently boots Linux on an AWS-FPGA instance…