Rocket's DMA slave interface (and/or internal routing) currently
appears unable to route DMA writes from LiteSDCard at frequencies
above 25MHz (as tested on nexys4ddr, with Rocket, at 75MHz main
system clock frequency).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Assuming we currently support a 32-bit (4GB) physical address space,
ensure that the dma_bus slave covers the entire range, covering any
possible layout of the LiteX SoC memory map (e.g., rocket has MMIO
in a wide range of registers located below 2GB, and DRAM starting at
the 2GB mark, needing DMA accesses to be routed appropriately for the
entire 4GB physical address range).
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
This is needed to support memory regions up to 4GB in size (currently
limited to 2GB, or 0x8000_0000).
FIXME: CI complains about assertions re. axi_lite.address_width in
relationship to len(wishbone.adr) and wishbone_adr_shift, which
seems to be a problem on the 32bit (vexriscv?) CPU used for CI,
but seems to work fine on Rocket.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
foo
Useful for current tests with LiteSDCard using DMA and that requires the DMA to be connnected to
the DMA bus of Rocket when the direct memory bus is used.
The UART backend writes [read identifier, num_reads, addr] for
every read request.
Etherbone packets are able to include multiple read requests.
Therefore, it is beneficial to merge sequential read requests to reduce writes
(and possible latency overhead).
Benchmark:
A typical litescope fetch script with the following
signals [ddrphy.dfi,cpu.ibus.cyc,cpu.ibus.stb] results in 1 read for the
data_valid register and 24 sequential reads for the scope data per timestamp.
Fetching data for a capture length of 512 over a 921600 baud UART (arty board)
took:
205s (current master branch)
18s (with this merge function)
The proposed merger only merges read requests from one etherbone packet
at a time and doesn't change the read order.
This is the logical continuation of the recent change to avoid specific SoC classes.
A Zynq FPGA can be used with or without the PS7. When used without the PS7, a softcore CPU
can be used as with others FPGAs. When using the PS7, the softcore is replaced with the PS7
and connected to the SoC through one of the AXI GP interface.
An example is available on litex-boards.
When provided, the modules doing DMA shall connect the DMA to the dma_bus to allow the CPU(s) to manage cache coherency
and avoid the manual cache flushes.
This has been tested with VexRiscv SMP and LiteSDCard doing DMA while loading Linux binaries.
Gabriel Somlo
Florent Kermarrec
Pepijn de Vos
Jędrzej Boczar
Dolu1990
Christian Klarhorst
Sean Cross