This is just a list of unanswered questions I have, this mostly evolves about nice to have features or use cases that I don't know if they are supported and simply not documented in a way that lead me to discover them.
For reference, my working FPGA is the Mars AX3 from Enclustra featuring an Artix7.
It appears that it is posisble to combine renode with verilator simulations. See https://mithro-fomu-workshop.readthedocs.io/en/master/renode-verilator.html
Linux on LiteX VescRiscV appears to use a SimSoc. See https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/sim.py
Also the demo presented in https://antmicro.com/blog/2020/05/multicore-vex-in-litex/
I can run those, but what I am really intestered in is also having the co-simulation wit my own custom gateware.
Can I run a VescRiscV in LiteX with some of my own modules simulated in verilator such that I can poke registers from the "app" and make it do stuff in the verilator simulation? How do I go about integrating this in my target script?
For example if I have:
cat boot.json
{
"test_data.bin": "0x41000000",
"demo.bin": "0x40000000",
}
Then I would like the demo.bin app to be able to interacts with the data I stuffed in RAM. This appears to work on the target when putting that on the SD card and booting from that. Then the demo app can access that memory.
How do I access above data in gateware? I expect that care should be taken to not access it at the same time from the CPU. Can I do something to manage this properly?
[08:08:47] <nickoe> _florent_: How does one normally go about using the RAM memory space in gateware together witH the CPU having access to memory as well? Does the memory have an AXI interface that the CPU uses? Does this mean that gateware can just use AXI as well?
[08:12:53] <nickoe> tmbinc: Is that the siglent scope?
[08:18:23] <zyp> nickoe, is that a litedram question, or are you thinking RAM in general?
[08:19:33] <zyp> the general question is bus interconnects that arbitrates access from multiple masters
[08:19:39] <zyp> general answer*
[08:19:59] <zyp> this can be wishbone or AXI or whatever
[08:20:00] <nickoe> zyp: I am talking in general, but I want to implememt it specifically with litex, so I guess it is a litedram question in gemeral.
[08:20:48] <zyp> litedram has an internal crossbar interconnect so that you can attach multiple masters directly
[08:20:52] <nickoe> My current goal is to stuff some IQ samples in memory. I can do that with the boot.jsom and load it from the SD card.
[08:21:52] <nickoe> Ghen I want to stuff those samples to a DAC at a 100MHz rate if possible somehow. I am still trying to understamd how to arch this sanely.
[08:23:07] <nickoe> After that I would need to add some DSP in gateware (in verilog) to generate those IQ samples.
[08:24:01] <zyp> a typical litex system will have a main wishbone interconnect across the various slaves, including litedram, and then if you've got a high performance cpu it might also be plugged directly into the litedram so it can bypass the main interconnect when accessing the main ram
[08:25:13] <zyp> so if you wanna do some sort of DMA, you can either make something that plugs into the main interconnect and can access the whole system memory space, or something that plugs directly into litedram if it only needs access to the main ram
[08:26:29] <zyp> in the latter case, you might want to use one of these adapters: https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/dma.py
[08:30:53] <nickoe> Ok, I think that is what I want, but I have no previous resl experince i using AXI or Wishbone directly, so i am also trying to understand how it can be used.
[08:31:47] <zyp> https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/axi.py or https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/wishbone.py
[08:39:07] <nickoe> Mm, I guess I can somehow connect the data unbuffered to some registers that I map to the output pins of the FPGA that connecto the the DAC, but wouldn't that sufffer from read/access latencies?
[08:40:19] <nickoe> maybe there exist some other SDR implemented with litex that I can look at?
[08:49:42] --> kgugala (~Android@d110-162.icpnet.pl) has joined #litex
[08:53:27] <-- kgugala_ (~Android@public-gprs396738.centertel.pl) has quit (Ping timeout: 246 seconds)
[09:27:03] --> hansfbaier (~hansf@36.65.122.40) has joined #litex
[09:40:29] <-- FFY00 (~FFY00@archlinux/trusteduser/ffy00) has quit (Ping timeout: 268 seconds)
[09:54:49] <-- hansfbaier (~hansf@36.65.122.40) has left #litex
[10:21:40] <_florent_> tmbinc: nice you've been able to reuse and integrate your previous offsetdac code!
[10:22:40] <_florent_> tmbinc: in LiteX-Boards I generally try to only have the base support for hardware (Serial, Ethernet, DRAM, etc...), and add custom peripherals in application projects
[10:24:12] <_florent_> tmbinc: we could maybe continue developing the scope part in the 360nosc0pe organization? (and have offsetdac code + test code + others custom peripherals there)
[10:27:17] <_florent_> nickoe: the default LiteX SoC are using a single DRAM port that is mapped on the main bus of the SoC (Wishbone or AXI)
[10:27:41] <_florent_> nickoe: this is convenient for CPU accesses but the main bus can be a bottleneck
[10:28:57] <_florent_> nickoe: so it's also possible to create direct ports to the DRAM too, with get_port of the crossbar: https://github.com/enjoy-digital/litedram/blob/master/litedram/core/crossbar.py#L79
[10:29:38] <_florent_> nickoe: this will provide you a native LiteDRAM interface, that you can then convert to Wishbone/AXI if more convenient
[10:31:35] <_florent_> nickoe: the BIST module is for example creating two additional ports (one for write, one for read) and use them to stress the DRAM:
[10:31:37] <_florent_> https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/bist.py
[10:31:52] <_florent_> integrated with:
[10:31:52] <_florent_> https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1230-L1235
Some more
[23:02:18] <nickoe> Well, I do want to attempt to stream out data from the ram. I wanted to read it with LiteDRAMDMAReader and then push it in to an AXI Stream Interface.
[00:00:00] - {Day changed to Monday, 22 February 2021}
[04:33:25] <-> Degi_ is now known as Degi
[07:59:40] <_florent_> nickoe: LiteDRAMDMAReader has two endpoints: a sink to provide your read request and a source that will return the data
[08:00:20] <_florent_> so you can just set sink.valid.eq(1), sink.address.eq(the_address_you_want_to_read)
[08:00:31] <_florent_> then wait sink.ready to be 1
[08:00:57] <_florent_> and data will be returned on source.data when source.valid is 1
I followed the docs on https://github.com/enjoy-digital/litex/wiki/Use-Host-Bridge-to-control-debug-a-SoC#create-scripts-to-communicate-from-the-host-pc-with-the-bridge
This wishbone remote client stuff if pretty cool. I am not sure how it works, but it appears thta if I just do writes to a regiter in a forloop that I can run that with about 20Hz. It apperas as if the operations are buffered or offloaded to the server, as the test script has returned, but the registeres are still updated. That I can see with the logic analyzer on some pins.
I know this interface is not intended to be a streaming interface, but is it possible to make considerably faster?
Reading XAPP586 it appears that ISE/IMPACT flashes a custom bitstream to the FPGA to route through the SPI mode from the JTAG to sprogram it?
It does appear as if lxterm did support programming the flash, but it was removed in this commit: https://github.com/enjoy-digital/litex/commit/41964f945cee71337e8e0998d597086b2ef94f77 How does one go about to program the flash now?
Does the netv2 support it? https://github.com/enjoy-digital/netv2/blob/14905f90ffdefadc396f2a1df8675d59ee151516/netv2.py#L227-L229
I am slightly confused by this.
Other references: https://marc.info/?l=openocd-development&m=151002052505567&w=2
UPDATE 2021.12.23: This looks like it has implementation via withbone script and bios firmware for exactly this purpose. litex-hub/litespi#52
I also see my flash chip listed in https://github.com/litex-hub/litespi/blob/55926a6c035da37123fa467779a6b72cdd26d061/litespi/modules/generated_modules.py#L7256-L7275, maybe I should swith to using the litespi module instead of this?
Above was based on whatever was in the litex version used on litex-buildenv which appears to be dated around the summer of 2020.
Notes for when I want to try it again:
+from litex.soc.cores.spi_flash import S7SPIFlash
+from litex.soc.cores.icap import ICAP
Such that I can control that with a bit of code in the app?
For example:
I have these RAM parameters, https://github.com/enjoy-digital/litedram/compare/master...nickoe:mars_ax3
If I want those merged, can we do that without submitting the board? Then I won't have as many forked dependencies in my project. ... but what I really ask, is there a proper way to testnif those parameters work properly?
I am using them now, but often when I boot I get a couple of errors in memcheck but a subsequent sdram_init or sdram_test passes OK. I wonder if that is just the PLL that is not ready yet? Or maybe some timing constraits that are not fully matched in the vivado syth.
On a second thought, I guess I could just put that in my platform file as well, to keep it together for now. Is that a bette idea?
It appears that there is a BIST thing in litedram that is "Built In Self Test (BIST) modules for testing LiteDRAM functionality.", this can be enabled with the with_bist=True for the add_sdram(), see https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1187
The --trace optoin with start and stop appaears to be broken, but an option is to do it in the DHL with:
cycles_end = 2000
cycles = Signal(32)
self.sync += cycles.eq(cycles + 1)
self.sync += If(cycles == cycles_end, Finish())
Or even
self.sync += If(cycles == cycles_end,
Display("-"*80),
Display("Cycles: %d", cycles),
Display("-"*80),
Finish(),
)
SDRAM endianness difference between hardware and simulation