Hello,
I am doing research with an Ultra-Embedded Implementation of a RISC-V Processor in gem5. My team is using an Oracle Virtual Machine to run testbenches and benchmarks for our research motivation. As part of our research, I have been tasked with looking into expansion of the AXI4 Bus (maybe increase bandwidth from what has been defined or data rate?). Because it is simulation based, we are not directly working with hardware. So the RISC-V Processor is defined in Verilog and .v files are what I am attempting to modify for this purpose.
I have begun to modify various core definition modules by increasing some I/O definitions to 64-bits from 32-bits. My question is: is what I am doing realistically increasing bandwidth? And if so, how might I best modify the files to achieve this? Currently, I am working to resolve the errors that appear as I modify variables, definitions, etc. to see if I can build the new implementation and receive simulation time metrics.
Here is the RISC-V Core I am working with:
https://github.com/ultraembedded/riscv
For those interested and willing, the virtual machine I am using to implement the hardware modelling and simulation:
https://www.virtualbox.org/wiki/Downloads
Your insight is appreciated!
Will
Hi Will,
I think if all you are doing is increasing the width of the data bus, but are not getting the processor to then issue wider transactions requests, you will not be increasing the bandwidth used. The AXI4 master will need to be able to use all of the increased width data bus at the same time before you could see any bandwidth improvement.
So your modifications would need to me more complex, forcing the processor logic to issue 64-bit transactions rather than the current 32-bit maximum, and this is very unlikely to be a simple verilog file change (I can't say for sure as I have never looked at RISC-V code).
Unless either there is a simple parameter change to convert the core to implement 64-bit data support, you would need to look at quite a complex structure, perhaps clocking the 32-bit core at twice the main bus speed and then implement a 64-bit write buffer to write that data out to the memory system (the write buffer handling the 32-64 bit conversion and the 2:1 clock ratio to result in 1 bufferable 64-bit write transfer per bus clock cycle), or perhaps a cache to load and store data from (a 32-bit cache and a 1:1 clock ratio would also usually still improve bandwidth as the processor won't see wait states from the system for any cache hits).
Sorry, no simple options that I can think of.
Colin,
Thank you for your response. Yes I had started to implement the 64-bit transaction change but it is difficult to resolve all the dependencies on the current 32-bit implementation when modifying it. I worked backwards to get to a working 32-bit implementation to at least have a running simulation again. As far as this bandwidth increase goes, worst case it is something that my research team could outline as a future work or enhancement to this RISC-V processor definition.
Regards,