I’ll be posting my weekly updates for this Project here.
Additional information and resources can be found with the proposal.
This is a Pre-GSOC coding period update. I have a draft setup for blog website, it will be ready to be released soon. I have completed video intro presentation and had it reviewed from respective mentors, will be making the necessary changes and will be starting with a draft video this week.
Except this I haven’t really worked much with the coding part due to ongoing exams.
The exams will continue till next week, but ill try my best to catch up as soon as exam finishes.
Week 1 Update:
- Intro Video Presentation Completed, Video will be uploaded shortly.
- Completed LED blink tutorial on BeagleV-Fire.
- Blog site to keep track of updates and resources, link.
Whatsapp Call based Informal meet with @KumarAbhishek and @Vedant_Paranjape on 1-Jun-2024.
Points discussed: -
- Proposal needs to be revised, as some important points are to be mentioned/ updated/ sharpened and weekly schedule to be updated to meet proper requirements.
- Discussed possible locations for program memory of PRU so that it can be accessed by PRU and written in run-time by the main CPU.
- In-general approach towards the project.
Blockers: -
Currently I haven’t started with coding part yet. But looking ahead I feel that a small blocker ahead would be reading and understanding PicoRV processor.
Next week goals: -
- Updating proposal as required.
- Researching on PicoRV core processes and other soft cores to detemine best way to interface I/O with the processor .
- Testing PicoRV on BeagleV-Fire for observation on its single-cycle processing capabilities.
Hello Atharva,
Sounds like some progress. Could you also share your update proposal?
Regards,
Vedant
Hii @Vedant_Paranjape,
As per instruction given by you and @KumarAbhishek I have revised my proposal, please review.
I have made changes to project goals and milestones.
@jkridner you review on this version of the proposal will be valuable.
I’ll be continuing with focus on I/O interfacing first followed by capability of PicoRV to handle single cycle execution for all instructions.
Can you document here and in your proposal what are the benefits of PicoRV?
Week 2 Update:
- Introduction video uploaded.
- Based upon weekly meeting with mentors, two approaches for I/O interfacing were discussed, memory mapped and register mapped I/O.
– I have decide to first try out memory mapped I/O.
– I have used a Risc-V CPU and I/O controller to try out memory mapped I/O but haven’t been successful yet.
Blockers:
- I am not able to use proper compiler flags for exact instruction generation, Generating hex file can be found here .
Next Goals:
- Complete memory mapped I/O and try register mapped I/O.
Links to commit:
Mem-mapped-IO
I have started to document about this but I think it would only be valid if I atleast compare it with other core to state why exactly PicoRV is better.
I’ll share the link to this document asap.
Week 3 Update:
- Tested Memory mapped I/O through simulations and by accessing on-board LEDs through a test CPU core. Here are few observations:
– The RISC-V ISA has no direct instruction to load 32-bit memory address so it takes multiple cycles to load the particular address.
– Memory slippage can be a serious issue. - I have started looking into MiV (microchips riscV softcore to understand how it implement I/O operations.
Next Goals:-
- Working out a way to implement Register mapping I/O.
- Setting up riscv compiler into gitlab CI for BeagleV-Fire gateware to compile the c code which will run on the PRU.
Links to commits:
Simple test Program
1 Like
Week 4 Update:
- Completed setting up CI workflow for gateware to compile the C code using riscv-gnu-toolchain
- Started with writing a wrapper for BeagleV-Fire to interface picoRV and memory devices onboard.
- Started to work with Registers mapped IO in parallel.
Blockers: Having some issues interfacing picoRV with BeagleV-Fire.
Next Goals:
- Researching if generating new instruction set would help.
- Completing Register mapped IO and note differences w.r.t other implementations.
- Setting up verilator in gitlab CI flow for generating simulation files.
Week 5 Update:
- Competed Register mapped IO and verified the latency through simulation
- Decided on using Register mapped IO to be interfaced with PicoRV32 as the final CPU.
- Competed basic instantiation of PicoRV in a wrapper for BeagleV-Fire along with IO_controller and a register file, now only left with memory interfacing.
Blocker:
Currently facing some issues with compiler arguments to be used to minimize the number of instructions as well as satisfy all the necessary conditions.
Next Goals:
- Complete PicoRV instantiation and deploy the CPU on BeagleV-Fire for testing.
- Note down the latency between IO operations when using PicoRV through simulations.
Week 6 Update:
- Added PicoRV based softcore as CAPE option to gateware.
- Added LSRAM component to represent Program Memory.
- Started with a makefile that would help to simpilify local build process for gateware
Blockers:
- No blockers this week
Next Goals:
- Adding the PRU-core as a separate component instead of a CAPE option.
- Setting up communication between Linux and PRU-core. Most possible ways are using AXI or APB protocol for this, haven’t confirmed yet.
Week 7 Updates:
- Added PicoRV Softcore as a component to the gateware which will work parallel without touching CAPE options.
- Added AXI4 Interconnected LSRAM as program memory. This IP allows Linux on BVF_RISCV_SUBSYSTEM to read/write data to this RAM using AXI protocol.
- Tested the working of AXI4 LSRAM by reading and writing data to it through Linux.
Blockers:
I am trying to figure out a way to halt the processor while the program memory is being flashed through Linux.
Next Goals:
- Testing the native interface of the LSRAM to ensure it can be accessed from both sides.
- Trying out RV32E and try to map IO to the internal registers within the core.
One way could be putting a register on the APB (cheap)
and control the processor reset that way.
I am doing something similar to what you are,
but like above, I access the LSRAM through APB,
which is a lot lighter on the LE count than doing AXI.
I second that motion! 
Very PRU like…
Hii @lranders,
I also had this in mind, but I am planning to keep it as a backup option.
Since I am already using AXI for Ram, I though It might be better to use some initial AXI addresses as CSRs and it would be easy to add a offset to the processor for the same.
It should work, but I am not familiar if there could be some other issues that might occur. Won’t know until I try 
.
That is interesting, can you share your repository link? I would love to go through your design. 
Sure, it’s right here.
Mind you, it’s in a very early draft state.
Week 8 Updates:
- Cross tested the AXI based communication between Linux and FPGA by write data through FPGA and reading through Linux, ensuring good transfer of data.
- Add a top Control module to add bit controlled reset for PRU softcore (this will pause the PRU while its being programmed).
- Added a GPIO register bit through which GPIO access can be switched between Linux system and PRU softcore.
- Started to brainstorm IO controller changes to map IO to in-built CPU registers, using rv32e.
Next Goals:
- Complete the rv32e implementation with register mapped IO.
- Test the complete PRU setup through Linux.
Remember, we’re not allowed to call it a PRU any longer…
Yes, I am aware of that, we are trying to find some suitable name for it. For now we have “Low-Latency Softcore”
Week 9 Updates:
- I completed the AXI setup for Program Memory for softcore.
- Since writing within the Program memory by adding offset for CSRs won’t allow immediate software resets, I had to opt to a different method for accessing the CSR.
- Added APB register (control-status) access for software reset and start/stop for the Softcore.
This register will also divert GPIO access within Linux and softcore. - Added RV32-supported register file to access GPIO through registers.
This feature has not been added completely yet.
Blockers:
While I only tested the AXI setup and it worked perfectly well, the Addition of APB has created some problems while transferring data. This issue needs to be debugged.
Next Goals:
- Solve the issue with APB registers on an immediate basis.
- Test the softcore setup.