Read speed: dcache width impact 32bit vs 64bit about vexriscv

[Dolu1990]

Hi,

Ahhh that's weird that the performance drop.
I would say, the only way to figure that one out would be to run it in simulation to see what is happening exactly.

Seems to me that Read speed: 61.0MiB/s is the outliner XD, as VexRiscv normaly get a higher write speed.

[pottendo]

hmm,
too long since I've done something with the simulator... You've helped to track down some FPU / multi-threaded issue on Zephyr/Linux, if you remember.
Can you point me to the right resources, where I can study, how to run this particular bitstream on an emulator? or whatever piece of it...
Or do I need to extract the memtest to a standalone (e.g. Zephyr) program?
bye, pottendo

[pottendo]

hi,
I've run naively:

64bit:

$ litex_sim --sim-debug --cpu-type vexriscv_smp --dcache-width=64 --with-sdram
[...]
--=============== SoC ==================--
CPU:		VexRiscv SMP-LINUX @ 1MHz
BUS:		WISHBONE 32-bit @ 4GiB
CSR:		32-bit data
ROM:		128.0KiB
SRAM:		8.0KiB
L2:		8.0KiB
SDRAM:		64.0MiB 32-bit @ 1MT/s (CL-2 CWL-2)
MAIN-RAM:	64.0MiB

--========== Initialization ============--
Initializing SDRAM @0x40000000...
Switching SDRAM to software control.
Switching SDRAM to hardware control.
Memtest at 0x40000000 (8.0KiB)...
  Write: 0x40000000-0x40002000 8.0KiB   
   Read: 0x40000000-0x40002000 8.0KiB   
Memtest OK
Memspeed at 0x40000000 (Sequential, 8.0KiB)...
  Write speed: 1.6MiB/s
   Read speed: 871.5KiB/s

--============== Boot ==================--

litex> mem_speed 0x40000000 102400
Memspeed at 0x40000000 (Sequential, 100.0KiB)...
  Write speed: 1.6MiB/s
   Read speed: 878.7KiB/s

and here the 32bit:

$ litex_sim --sim-debug --cpu-type vexriscv_smp --dcache-width=32 --with-sdram
--=============== SoC ==================--
CPU:		VexRiscv SMP-LINUX @ 1MHz
BUS:		WISHBONE 32-bit @ 4GiB
CSR:		32-bit data
ROM:		128.0KiB
SRAM:		8.0KiB
L2:		8.0KiB
SDRAM:		64.0MiB 32-bit @ 1MT/s (CL-2 CWL-2)
MAIN-RAM:	64.0MiB

--========== Initialization ============--
Initializing SDRAM @0x40000000...
Switching SDRAM to software control.
Switching SDRAM to hardware control.
Memtest at 0x40000000 (8.0KiB)...
  Write: 0x40000000-0x40002000 8.0KiB   
   Read: 0x40000000-0x40002000 8.0KiB   
Memtest OK
Memspeed at 0x40000000 (Sequential, 8.0KiB)...
  Write speed: 1.6MiB/s
   Read speed: 874.6KiB/s
[...]
--============= Console ================--

litex> mem_speed 0x40000000 102400
Memspeed at 0x40000000 (Sequential, 100.0KiB)...
  Write speed: 1.6MiB/s
   Read speed: 878.8KiB/s

No difference, 64bit vs. 32bit dcache-width, and confirmed that the write speed is faster.

Not sure if this experiment can even be representative for my observation on the real hardware.
What I can confirm is, that the performance on the real FPGA HW is substantially different. I've done a testcase where the one with --dcache-width=64 takes ~625s and with --dcache-width=32 its around 125s and even fast with --cpu-type=vexriscv (32bit dcache default) it's around 114s.

bye, pottendo

[Dolu1990]

Hi ^^

What memory system do you use on hardware ? (DDR, ... ) ?

Regards
Charles

[pottendo]

Well, don't know more than it's 'Hyperram'.
The partlist is here: https://github.com/zeldin/OrangeCart
My project is a fork of the RVCop64 project.

Can't open kicad files, so I can't tell you more, Sorry.

Bye, pottendo

[Dolu1990]

Ahhh then, one possibility, is that the hyperram controller successfuly reconize 32 bits based burst, but fail at reconizing the 64 bits based ones ?

[pottendo]

...must be something like this, I suppose.
Here some more information: https://github.com/zeldin/litehyperram/tree/22123da560144fdc7113a1d72f1bda8e4beea5da
At least some information about bursts: - Arbitrary burst length ...

[pottendo]

oops, mistakenly closed -> however, this is probably off-topic here, so @Dolu1990, it's ok to be closed.
Thanks for the feedback so far - maybe there's a solution; need to check with @zeldin.

[pottendo]

@zeldin has fixed the issue - thanks @Dolu1990 and @zeldin!
as always, you guys rock!

[Dolu1990]

<3