Comments (3)
@BrunoLevy - Doing this potentially means FemtoRV could be an alternative CPU option for usage in the CFU Playground (http://cfu-playground.rtfd.io/). It looks like FemtoRV is already an option in the LiteX ecosystem?.
from learn-fpga.
@tcal-x Yes, PicoRV32 has PCPI, but I vote against the idea - the FemtoRV32 cores are meant to be easy to modify, and I would encourage anybody who wishes to add their own instructions to pick one and add it to the processor itself.
from learn-fpga.
Hi @tcal-x, @mithro, @Mecrisp,
It is a complicated desgin decision, but I think we will not do that (because I fully agree with @mescrisp). Here are some explanations for that:
We tried different designs for FemtoRV, and we think that a compact single-file/simple/non-generic design is a big plus (initially the first FemtoRV had multiple modules, then @Mecrisp redesigned it, and it gained a lot, both in terms of legibility and efficiency / LUT usage). Then we have a RV32I core that fits in (approx.) 100 lines of VERILOG code, and it's good for the students who read it: they can have a quick overview of it without having to browse multiple files. When you dive into somebody else's design, the "mental cost" of having multiple files / multiple modules is important (of course, it is necessary if the design is super complicated, but I do not think that the size of the different FemtoRV cores reach the "need for modularization" threshold.
In the end, I find it better to have several single-file versions of the whole design (quark, electron, intermissum, gracilis...) rather than assembling them from individual components, because with the second option, the proportion of interface/glue code/administration dominates over the code that implements the functionalities. Another aspect is that multiple modules sometimes constrain the design too much, for instance when you need to draw a wire between two different functional units: I think it is not very clear where the limits of the functional units should be, and whenever a decision is taken for that, there is always a good reason to change that decision a few weeks after (at least it is my own experience !)
I made an exception for the FPU though, because it is a really a big functional unit (even bigger than a complete RV32IMCZcsr core), but even for that part it is still unclear to me, for instance, should the FPU registers go in the FPU (sounds logical) or in a single bank shared with the integer code (will facilitate implementing ZFinx)? Should the FPU control register be in the FPU (sounds logical) or with the other CSRs (much more convenient to implement the CSR manipulation instructions)? With a single-file / single-module design, you do not have to bother with these questions and it is good: the functional units go in the always() blocks where it is easier to manipulate them (but well, my FPU is in a separate module for now... we'll see whether it will be re-merged with the version of the CPU that uses it or kept separate...)
Maybe what we can do is writing a tutorial that explains how to extend a femtorv32 core, what do you think ?
from learn-fpga.
Related Issues (20)
- From Blinky to RiscV - porting to other HDLs
- Interrupt handling, double triggering HOT 2
- Rv32i quark Block diagram HOT 4
- Out of memory while generating hex for blinky in step 20, IceStick HOT 3
- Icebreaker FPGA UART communication garbage out HOT 4
- Issue connecting iCEstick Evaluation Kit
- Building radiona_ulx3s_ex fails but the original LiteX python script works (ULX3s-12F) HOT 1
- comment/code mismatch
- broken link HOT 1
- FROM_BLINKER_TO_RISCV step 14 multiply simulates but doesn't run on IceStick
- comment/code mismatch FROM_BLINKER_TO_RISCV step 4 (?) HOT 1
- ice-sugar-nano: PLL avaliable but unused
- Step 7 Yields No Output HOT 15
- FROM_BLINKER_TO_RISCV: step 19: verilator command does not work. HOT 2
- FROM_BLINKER_TO_RISCV: no terminal output for step22.v on iCEstick HOT 14
- Which linker script should I be using with the ULX3S? HOT 2
- How to fit larger programs on the Icestick ULXS3 or Arty HOT 1
- Error when running make ARTY HOT 7
- Why does make hello.prog use iceprog after running make ARTY.firmware_config? HOT 1
- Struggling to make LiteOS HOT 31
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from learn-fpga.