wsong83
commented
7 years ago Yes, the dram.c is used to test the Dram interface by enforcing write-back from L2. Since I am not sure how much has been revised for porting to Zynq, I can only provide the following suggestions.
Replacing L2$ cache with a broadcasting coherence bus would speed up writing back as there is no L2 $. To do this, replace line 150 with line 149 in LowRISCChip.scala
Try to see problems in simulation. I believe you can replace the PS AXI interface with a behavioural memory model in simulation and test whether the AXI RW messages are correctly generated by Rocket.
You probably have gotten it right. Have you set the base address of the shared DRAM correctly?
Hello,
I ported the v3 implementation to a ZedBoard, using PMODs for UART and SD Card, and using memory through PS's (Processing System) HP (High Performance) AXI port. The idea is to setup a shared memory region between ARM and RISC-V, introduce the ARM part as a platform device to RISC-V, and go for emulating some peripheral functionalities over ARM to ease device device and driver development.
My port works for basic hello applications, but I cannot pass the dram test. As far as I understand, the "ram.c" test code sets big memory regions to force L1 and L2 caches be filled so that write back to DRAM will occur. So I think my ZedBoard port to use PS's memory has the problem.
As I see that you provide the DRAM code which specifically test the memory write back issue, I thought that you may have observed the same or similar problem before and come up with a test code to verify the solution. Therefore, I would like to kindly ask you if you have any suggestions for me to look at to solve this.
Kind Regards,
Furkan