-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expanded support for CFUs. #14
base: master
Are you sure you want to change the base?
Conversation
- Now submodule ext/VexRiscv uses tip of `dev` branch - Added ext/SpinalHDL submodule, also `dev` branch - Modified `build.sbt` to bring up to date with current `dev` VexRiscv - Modified `src/main/scala/vexriscv/GenCoreDefault.scala` to add a `--cfu` option, to add the CFU interface - Added `VexRiscv_FullCfu.v` and `VexRiscv_FullCfuDebug.v` (and yamls), and updated `Makefile` to build them - I did **not** rebuild the other .v/.yaml files Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Both L1 caches are changed from 4k direct-mapped to 8k 2-way associative. The change to 2-way was required since each "way" can be 4k max. Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Rebuilt just the CFU-enabled Vex Verilogs. Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Tweak Fomu variant for performance and LCs.
Signed-off-by: Joey Bushagour <[email protected]>
Require a memory and writeback stage for the CFU plugin.
… variant. Signed-off-by: Joey Bushagour <[email protected]>
Update the Fomu CPU Variant for performance.
Also increase "Slim" D$ to 4kB, I$ to 2kB. Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Also remove obsolete genWrapper.py script. Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
Signed-off-by: Tim Callahan <[email protected]>
@tcal-x: This create lots of variants very specific to https://github.com/google/CFU-Playground project and I'm not sure this should be integrated here where we try to provide more generic variants. This would probably be better to integrate these variants directly in the CFU project or in a fork, as is doing Betrusted project for example for the specific variants that have been created for it: https://github.com/betrusted-io/pythondata-cpu-vexriscv. Fomu is also not a good name for a variant (I imagine it has been created to limit resource usage on iCE40) since we would also want to use it on the iCEBreaker, so we could eventually integrate this one, but would probably have to find a proper name. |
@@ -17,6 +17,16 @@ src/main/scala/vexriscv GenCoreDefault.scala | |||
- Available in normal an -Debug, with the Debug bus exposed | |||
|
|||
|
|||
## Changes in `tcal-x`'s fork |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs fixing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, definitely.
@@ -6,10 +6,12 @@ import spinal.lib._ | |||
import spinal.lib.sim.Phase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why this is changing a scala file? Shouldn't this be part of the source module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the top generator script that handles user options and then builds the VexRiscv accordingly, adding the plugins etc.. It's not part of the VexRiscv "library". It is local to the pythondata_cpu_vexriscv repo.
For example, cache line size is currently hardcoded in this file. If we want to make it an option that can be changed, we'd alter this file to add an user option and then pass the value to where the caches are instantiated.
@enjoy-digital - I think we might need a way to provide |
@@ -1,6 +1,6 @@ | |||
// Generator : SpinalHDL v1.6.0 git head : 73c8d8e2b86b45646e9d0b2e729291f2b65e6be3 | |||
// Component : VexRiscv | |||
// Git hash : 6276bf628be9d0a58c0284dca83137b71ef29098 | |||
// Git hash : 593e180abf5ba39e7fa33d4f371646453f84496a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't change anything in this file, but hash. This looks weird
@@ -1,6 +1,6 @@ | |||
// Generator : SpinalHDL v1.6.0 git head : 73c8d8e2b86b45646e9d0b2e729291f2b65e6be3 | |||
// Component : VexRiscv | |||
// Git hash : 6276bf628be9d0a58c0284dca83137b71ef29098 | |||
// Git hash : 593e180abf5ba39e7fa33d4f371646453f84496a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't change anything in this file, but hash. This looks weird
@@ -1,6 +1,6 @@ | |||
// Generator : SpinalHDL v1.6.0 git head : 73c8d8e2b86b45646e9d0b2e729291f2b65e6be3 | |||
// Component : VexRiscv | |||
// Git hash : 6276bf628be9d0a58c0284dca83137b71ef29098 | |||
// Git hash : 593e180abf5ba39e7fa33d4f371646453f84496a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't change anything in this file, but hash. This looks weird
@@ -1,34 +0,0 @@ | |||
*.class |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do you remove gitignore?
@@ -1,6 +1,6 @@ | |||
// Generator : SpinalHDL v1.6.0 git head : 73c8d8e2b86b45646e9d0b2e729291f2b65e6be3 | |||
// Component : VexRiscv | |||
// Git hash : 6276bf628be9d0a58c0284dca83137b71ef29098 | |||
// Git hash : 593e180abf5ba39e7fa33d4f371646453f84496a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hash only
@@ -1,6 +1,6 @@ | |||
// Generator : SpinalHDL v1.6.0 git head : 73c8d8e2b86b45646e9d0b2e729291f2b65e6be3 | |||
// Component : VexRiscv | |||
// Git hash : 6276bf628be9d0a58c0284dca83137b71ef29098 | |||
// Git hash : 593e180abf5ba39e7fa33d4f371646453f84496a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again hash (there are many such updates in this PR)
@mithro: This could be that yes, people doing specialized variants would also have to ensure they are not reusing existing names to avoid confusion (Betrusted added a Betrusted suffix for example, similarly to whas is done with CFU variants). Another option would also be to do things similarly to VexRiscv-SMP where CPU parameters are directly exposed to the user and the CPU is automatically rebuilt when the variant is not found in the cached ones, but this requires SBT and VexRiscv toolchain installed on the machine. That's what is used currently in Linux-on-LiteX-VexRiscv to avoid too much cached variants, which I'm also trying to avoid here. |
@tcal-x, @mithro: It seems the auto-build feature is already in place in CFU playground: google/CFU-Playground#305 so it would probably be better to use it and cache some CPU variants if you want to ease access to users. |
Hello @enjoy-digital , I agree with all of your points. And thank you for keeping the change rate low in One thing I now realize is that this wouldn't be the last update -- we are still iterating on the ideal CPU for our use case, so we continue to need somewhere to commit and share experimental variants. I've now thought through some of the alternatives.
@kgugala , I've realized that there are a number of problems with the implementation of google/CFU-Playground#305 , so while parts of it might be adapted to one of the last two alternatives above, it won't go in as-is. |
Perhaps google/CFU-Playground#309 is a better place for any continued discussion / suggestions. |
@tcal-x: My concern was mainly about the number of pre-generated variants added to the repository. A temporary approach could be to:
For 4) if you are able in the end to limit the number of pre-generated versions you want to provide to user, I would be fine having them directly in the main branch. But while this is still experimented, we could have the pre-generated version in a branch (that we could eventually delete later) or in a CFU specific dev fork that would be the main + just a different Makefile + more pre-generated variants. |
The new Fomu variants are very hacked, so use carefully. They have removed many safety checks (alignment, etc). Also, they have a hard multiplier but no divider, so you would need to compile with "
-march=rv32im -mabi=ilp32 -mno-div
".