From 6627e03550b4e99b0cb698f8b4e21032a462c54b Mon Sep 17 00:00:00 2001 From: PythonLinks <34622952+PythonLinks@users.noreply.github.com> Date: Sat, 9 Mar 2024 12:05:19 +0100 Subject: [PATCH 1/4] A better version of the "Why a new Design" Thank you for the excellent feedback. Usually when I approach a new project, I try to update its documentation to make it friendlier to newbies like me. Often the pull requests get ignored without explanation. In your case you gave a clear explanation, and so I am able to update my pull request. I just deleted the old version, forked again and am issuing a new pull request. It was very helpful to update the documentation. I now understand that the newer version is easier to understand, that is what I should be starting with, particularly since my goal is getting educated, rather than a specific client deliverable. There are now two versions of "Why a New Design?" One for new users, one for existing users. I am not sure what you will want to do about that. I also corrected some of the English in your original version. I am a native English speaker. I also speak French. --- source/VexiiRiscv/Introduction/index.rst | 32 +++++++++++++++++------- 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/source/VexiiRiscv/Introduction/index.rst b/source/VexiiRiscv/Introduction/index.rst index fdcb312..077e681 100644 --- a/source/VexiiRiscv/Introduction/index.rst +++ b/source/VexiiRiscv/Introduction/index.rst @@ -52,17 +52,31 @@ Here is a list of important assumptions and things to know about : - In the execute pipeline, stage.up(RS1/RS2) is the value to be used, while stage.down(RS1/RS2) should not be used, as it implement the bypassing for the next stage - Fetch.ctrl(0) isn't persistant. -About VexRiscv (not VexiiRiscv) +Why a New Design? ------------------------------------ -There is few reasons why VexiiRiscv exists instead of doing incremental upgrade on VexRiscv +The original VexRiscv is a successful design. But we have reached the limits of what it can accomplish, and in the process of improving it, we added too much complexity. We now have a newer and better abstraction. Specifically the new VexiiRiscv abstraction: -- Mostly, all the VexRiscv parts could be subject for upgrades -- VexRiscv frontend / branch prediction is quite messy -- The whole VexRiscv pipeline would have need a complete overhaul in oder to support multiple issue / late-alu -- The VexRiscv plugin system has hits some limits -- VexRiscv accumulated quite a bit of technical debt over time (2017) -- The VexRiscv data cache being write though start to create issues the faster the frequency goes (DRAM can't follow) -- The VexRiscv verification infrastructure based on its own golden model isn't great. +- Supports more parallelism with optionally multiple issues and multiple early and late alus. +- Has a much cleaner frontend / branch prediction design. +- Has a more flexible plugin system. +- Has a much better verification approach. +- Works better with DDRAM than the existing write through data cache. + +Really almost the whole VexRiscv system would need to rewritten, so it is better to start anew. This can be done faster than carrying around the old baggage. + +What was Wrong with the Old Design? +------------------------------------ + +There are a few reasons why we are creating a new VexiiRiscv instead of doing incremental upgrade on VexRiscv: + +- Almost all of the VexRiscv parts need to be upgraded. +- VexRiscv front end amd branch prediction is quite messy. +- The whole VexRiscv pipeline would have need a complete overhaul in oder to support multiple issue / late-alu. +- The VexRiscv plugin system has hits some limits. +- VexRiscv accumulated quite a bit of technical debt since it was introduced in 2017. +- The VexRiscv data cache being write though starts to have issues as frequency increases (DRAM can't follow). +- The VexRiscv verification infrastructure being based on its own golden model isn't great. So, enough is enough, it was time to start fresh :D + From 63336c7c5bf8afb2d918fc8e62031d7342e43fef Mon Sep 17 00:00:00 2001 From: PythonLinks <34622952+PythonLinks@users.noreply.github.com> Date: Sat, 9 Mar 2024 13:43:24 +0100 Subject: [PATCH 2/4] Update index.rst This first commit responds to your recommended changes. --- source/VexiiRiscv/Introduction/index.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/source/VexiiRiscv/Introduction/index.rst b/source/VexiiRiscv/Introduction/index.rst index 077e681..e6a6998 100644 --- a/source/VexiiRiscv/Introduction/index.rst +++ b/source/VexiiRiscv/Introduction/index.rst @@ -52,25 +52,25 @@ Here is a list of important assumptions and things to know about : - In the execute pipeline, stage.up(RS1/RS2) is the value to be used, while stage.down(RS1/RS2) should not be used, as it implement the bypassing for the next stage - Fetch.ctrl(0) isn't persistant. -Why a New Design? +Why VexiiRiscv? ------------------------------------ -The original VexRiscv is a successful design. But we have reached the limits of what it can accomplish, and in the process of improving it, we added too much complexity. We now have a newer and better abstraction. Specifically the new VexiiRiscv abstraction: +The original VexRiscv is a successful design. But we have reached the limits of what it can accomplish, and in the process of improving it, we added too much complexity. We now have a newer and better framework. Specifically the new VexiiRiscv framework: - Supports more parallelism with optionally multiple issues and multiple early and late alus. - Has a much cleaner frontend / branch prediction design. - Has a more flexible plugin system. - Has a much better verification approach. -- Works better with DDRAM than the existing write through data cache. +- Works better with DRAM at higher frequencies. Really almost the whole VexRiscv system would need to rewritten, so it is better to start anew. This can be done faster than carrying around the old baggage. -What was Wrong with the Old Design? +What was Wrong with VexRiscv? ------------------------------------ There are a few reasons why we are creating a new VexiiRiscv instead of doing incremental upgrade on VexRiscv: -- Almost all of the VexRiscv parts need to be upgraded. +- Almost all of the VexRiscv parts need to be migrated to the new framework. - VexRiscv front end amd branch prediction is quite messy. - The whole VexRiscv pipeline would have need a complete overhaul in oder to support multiple issue / late-alu. - The VexRiscv plugin system has hits some limits. From 3155b4c6e5e9ca04470f087c55cd6af3ecd4046e Mon Sep 17 00:00:00 2001 From: PythonLinks <34622952+PythonLinks@users.noreply.github.com> Date: Sat, 9 Mar 2024 14:09:39 +0100 Subject: [PATCH 3/4] Merged the original Introduction with the new "Why a new design" As you suggested. it is very common that active developers have less energy for the documentation. Particularly if it is in a foreign language. On the other hand to attract new users, it is critical. The saying is: "You only get one chance to make a good first impression. " And from a newbies perspective reading the documentation is so much easier than trying to read the source code. Like a friend of mine said: "Poor documentation is a show stopper. " You have done the harder work of creating all of this over the last 5 years. So I am happy to help some with the documentation. Thank you for your patience when I get it wrong. --- source/VexiiRiscv/Introduction/index.rst | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/source/VexiiRiscv/Introduction/index.rst b/source/VexiiRiscv/Introduction/index.rst index e6a6998..1b13957 100644 --- a/source/VexiiRiscv/Introduction/index.rst +++ b/source/VexiiRiscv/Introduction/index.rst @@ -1,20 +1,18 @@ Introduction ============ +VexiiRiscv is the next generation of VexRiscv, enabling things which are not possible with the current VexRisc framework. The new VexiiRiscv framework: -About VexiiRiscv ------------------------------- - -VexiiRiscv is a from scratch second iteration of VexRiscv, with the following goals : - -- RISCV 32/64 bits IMAFDC -- Could start around as small as VexRiscv, but could scale further in performance -- Optional late-alu -- Optional multi issue -- Optional multi threading -- Providing a cleaner implementation, getting ride of the technical debt, especially the frontend -- Proper branch prediction -- ... +- Supports both the 32 bit and the 64 bit Risc-V Instruction sets. +- Supports more parallelism with optional: + - multithreading, + - multiple issues and + - multiple early and late alus. +- Has a much cleaner frontend / branch prediction design. +- Has a more flexible plugin system. +- Has a much better verification approach. +- Works better with DRAM at higher frequencies. +- Could be as small as VexRiscv, but could scale further in performance. On this date (08/03/2024) the status is : From 2cef2a2c5121b0682672bd9ec9779455c108e378 Mon Sep 17 00:00:00 2001 From: PythonLinks <34622952+PythonLinks@users.noreply.github.com> Date: Sat, 9 Mar 2024 14:12:05 +0100 Subject: [PATCH 4/4] A few additional edits. --- source/VexiiRiscv/Introduction/index.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/source/VexiiRiscv/Introduction/index.rst b/source/VexiiRiscv/Introduction/index.rst index 1b13957..b40c36d 100644 --- a/source/VexiiRiscv/Introduction/index.rst +++ b/source/VexiiRiscv/Introduction/index.rst @@ -1,7 +1,7 @@ Introduction ============ -VexiiRiscv is the next generation of VexRiscv, enabling things which are not possible with the current VexRisc framework. The new VexiiRiscv framework: +VexiiRiscv is the next generation of VexRiscv, enabling things which are not possible with the current VexRiscv framework. The new VexiiRiscv framework: - Supports both the 32 bit and the 64 bit Risc-V Instruction sets. - Supports more parallelism with optional: @@ -12,7 +12,8 @@ VexiiRiscv is the next generation of VexRiscv, enabling things which are not pos - Has a more flexible plugin system. - Has a much better verification approach. - Works better with DRAM at higher frequencies. -- Could be as small as VexRiscv, but could scale further in performance. +- Could be as small as the smallest VexRiscv, but +- can also be much faster than the fastest VexRiscv. On this date (08/03/2024) the status is :