I finally got my first edits to a gateware build up at https://openbeagle.org/jkridner/gateware. …and, I didn’t even change the Verilog, just worked on updating the device-tree overlay loaded with the gateware.
Usefully, I built the gateware from scratch and was able to install it using a Debian package and the change_gateware.sh script.
Check it out. Just blinks one of the on-board LEDs.
Also, found a Youtube video I haven’t yet watched. This developer went a bit further and used some custom Verilog for a fun LED effect. Note: I’ve also seen people building the SERV core using the OpenBeagle CI, so that might be a useful fork to explore.
Hi @silver2row,
I had been using just Verilog for BVFire, but your post inspired me to give VHDL a try… and it works great! It’s just a VHDL version of blinky (not nearly as sweet as snakey), instantiated into CAPE.v, but there were no issues. So your VHDL tutorial link is very applicable. I wish we had a page for links to golden nuggets like yours and @platima’s. Best Regards.
Hello. I’m very interested in contributing to the project, however, I have a few clarifying questions: Are we expected to implement peripheral functionalities (like UART, INTC, IEP, etc.) similar to those in PRU-ICSS around the RISC-V core, or is the primary goal to build and verify the RISC-V itself? Additionally, how closely should the new CPU adhere to the existing PRU specifications? Is the objective to create a system nearly identical to PRU but based on RISC-V architecture, or are we looking for something that offers similar functionalities but may differ in I/O configurations, registers, and other specifics?
I think the purpose of this project is to ask us to modify the CPU, like VexRiscv, NeoRV32, SweRV, to implement a PRU. What we should do is modify the instruction set, increase parallelism and add pipelines, etc. Meanwhile, this requires us to implement some of the peripheral functions.
Hello @jkridner@Vauban,
Sorry for late update, I was busy with mid semester exams last week.
As per your previous instructions I forked the Gateware repository and tried tweaking around with the code, successfully compiled blinky tutorial. I have also familiarised myself with OpenBeagle CI and its working. I have completed setup of Libero SoC suite and SoftConsole on my locale machine.
Thanks to @platima 's video I learnt a new debugging technique using CI generated log files.
Currently, I am exploring some open source RISC V cores while having the PRU design in mind. I am referring to this for the PRU design. Also I am trying to tweak around more with the Gateware code in order to understand the code structure.
I have started working on my project proposal, will be posting in a couple of days for review.
P.S-Can you share some resources that I should refer to for more clarity with the project, thank you.
Hello @jkridner@Vauban,
Sorry for being late, I have created a merge request for my proposal for this project. Your Feedback on the proposal will be highly appreciated. Also, suggest changes if any.
You can find rendered version of my proposal here.
No, just the RISC-V core, the ability to load code and start/stop execution and the low-latency I/O connection to the pins.
There’s no need to strictly match the PRU subsystem specifications. Just looking to implement something that gets the low-latency I/O part examined.
Eventually, it would be nice if this was a prototype for something akin to a PRU subsystem, but I think the bigger priority is just getting an educational RISC-V CPU that can show people how to prototype a CPU on BeagleV-Fire. Understanding how processors can be utilized for handling low-latency I/O as a simplified/cost-reduced process compared to something like an FPGA.
Ease of debug and clarity should be the priorities.
You can start with PRU documentation. Also refer to previous post for more reference.
Also @jkridner,
I was looking through this documentation for remote-proc framework. I feel it is quite complicated to implement and will require more time to establish a communication protocol similar to this one.
What is your take on this?
Hello @jkridner,
Updates:- I am going through documentations for picoRV and VexRiscv processors currently to understand its various extensions and controls, I am also trying to flash the CPU core that I previously designed on Beaglewire through Beaglebone black that I obtained from a senior, to test for its compatibility with higher frequency clocks. I further plan to flash picoRV and VexRiscv processors on Beagle wire as well to monitor their performance and usability. I will standardize this by generating a fibonacci sequence in each case using a riscv cross compiler to compile a C code.
If you get shared memory and interrupts working, this should not be overly complex. You just need CPUs with shared memory and interrupts and the rest is software that is already debugged.
Rather than create your own 2-ported memory, you can do something a bit lower performance initially and just use your access to the DDR through the bus provided within the subsystem. You’ll likely want to do this anyway. Then, that bus and cache will be responsible for making the memory coherent and you’ll have less to worry about.
Otherwise, internal 2-ported memory isn’t excessively complex, but it might take a lot of area. I’m not sure how much RAM is in this fabric.
