<tmbinc>
but it appears to work correctly after ~1 minute of scoping
lf_ has joined #litex
lf has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #litex
hansfbaier has joined #litex
TMM has quit [Remote host closed the connection]
TMM has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
Bertl_oO is now known as Bertl_zZ
hansfbaier has quit [Ping timeout: 264 seconds]
yqszxx has joined #litex
yqszxx has quit [Client Quit]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
<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?
<nickoe>
tmbinc: Is that the siglent scope?
<zyp>
nickoe, is that a litedram question, or are you thinking RAM in general?
<zyp>
the general question is bus interconnects that arbitrates access from multiple masters
<zyp>
general answer*
<zyp>
this can be wishbone or AXI or whatever
<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.
<zyp>
litedram has an internal crossbar interconnect so that you can attach multiple masters directly
<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.
<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.
<nickoe>
After that I would need to add some DSP in gateware (in verilog) to generate those IQ samples.
<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
<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
<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.
<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?
<nickoe>
maybe there exist some other SDR implemented with litex that I can look at?
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 246 seconds]
hansfbaier has joined #litex
FFY00 has quit [Ping timeout: 268 seconds]
hansfbaier has left #litex [#litex]
<_florent_>
tmbinc: nice you've been able to reuse and integrate your previous offsetdac code!
<_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
<_florent_>
tmbinc: we could maybe continue developing the scope part in the 360nosc0pe organization? (and have offsetdac code + test code + others custom peripherals there)
<_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)
<_florent_>
nickoe: this is convenient for CPU accesses but the main bus can be a bottleneck
<shorne>
somlo: thanks, I will look at these issues too then. This is blocking me using the mmc card as swap to run the glibc test. It works but way too slow and the linux start killing things
<acathla>
_florent_, your patch : moving the ibus out of main wishbone bus to an Arbiter (or interconnectShared) to ROM (and RAM) worked well. But adding an icache to the vexriscv give me almost the same results for a bit less LC
<_florent_>
acathla: ah ok, the issue was indeed that access on dbus were preventing instructions to be fetched, the instructions are now in your icache so yes the bypass will be less useful, but I thought it was not possible in your case to add the icache (using too much resources)
<_florent_>
acathla: even if no longer useful in your case, the things we experimented will probably be useful later
<_florent_>
acathla: so now you are able to saturate your link with the CPU?
<acathla>
I did the math again, this time the icache (1024) costs 47LC and 4 RAM
<acathla>
_florent_, yes, I also passed everything in 32 bits, so 4 times faster to write to the FIFO (but it costs some LC)
<acathla>
I think there is something overkill with the actual UART, taking too much LC for the iCE40 (but you don't care on bigger FPGAs)
<acathla>
as I said on #tomu : 317 LC for a simple UART, 511LC if it's a master on wishbone
<_florent_>
acathla: have you tried reducing the FIFO's depth?
<_florent_>
this should reduce resource usage, is significant we could add a parameter to disable dynamic baudrate
<acathla>
I'll re-do that and measure
<_florent_>
ok thanks
<acathla>
_florent_, 114 LC ! For only one UART
<_florent_>
acathla: instead of 317?
<acathla>
114 LC less without the register than with it
<acathla>
203 instead of 317 if you prefere
<_florent_>
ah ok, so that could be worth adding a parameter! (and even disable dynamic baudrate by default since I'm not sure anyone use it)
<acathla>
That's a good idea. I'm not using USB anymore so I can now fit icache + 1cycle mult + 1cycle shift and the rest of my design (4 Infrared transceivers)
<acathla>
1 cycle shift takes 126 LC
<acathla>
Hum, that's not linear...
Bertl_zZ is now known as Bertl
<nickoe>
_florent_: What does that "BIST" stuff mean or refer to? I mean I see it mentione in the files, but I don't really understand what it is about.
<nickoe>
Ahh, I see """Built In Self Test (BIST) modules for testing LiteDRAM functionality."""
<nickoe>
Is that what is used to do the memtests?
<nickoe>
in the bios?
FFY00 has joined #litex
lambda has quit [Remote host closed the connection]
hansfbaier1 has joined #litex
hansfbaier1 has left #litex [#litex]
<_florent_>
nickoe: the memtest from the CPU is a good diagnostic but not stressing that much the memory. The BIST is using hardware generator/checker to write/read at the maximum speed and with optional random data/addressing.
rj has joined #litex
<nickoe>
_florent_: Is there an example on how to use that to verify ddr ram settings for the platform comoletely?
<tmbinc>
_florent_: Makes sense. I'll put that under 360nosc0pe repo and make sure I'll rebase on top of yours. Is there a similar setup for other boards/
<tmbinc>
Would be great if thereÃ's a standard way to handle this
<_florent_>
It's a specialized bench for LiteSDCard based on the Arty platform/target from LiteX-Boards
<_florent_>
so you reuse all from BaseSoC in LiteX-Boards and then add your own peripherals
<_florent_>
but will depends from cases, sometimes it's also more convenient to only use the platform from LiteX-Boards and duplicate part of the target in the project
<_florent_>
since need specific clocking/peripherals
<_florent_>
maybe in 360nosc0pe you can have a copy of the platform/target from LiteX-Boards that we will customize and as progress are made we could integrate changes in LiteX-Boards if this is useful
<tmbinc>
ok that sounds reasonable. Let me continue in 360nosc0pe then (and we can still figure out the details later).
<tmbinc>
What about the memory IOSTANDARD? the chips (K4B2G1646FBYMA) seem to be DDR3 not DDR3L so they should use SSTL_1.5 not 1.35
<tmbinc>
which matches the LVCMOS15 VCCQ that is used for the other ios
<tmbinc>
(which are on the same bank as some of the DDR IOs)
<_florent_>
tmbinc: indeed, that's probably a copy/paste error on my side while copying ddram pins definition from another platform, I can do the changes, test and update LiteX-Boards
<tmbinc>
_florent_: Ok. Shoudl we still add the SPI bus and pin definitions for the other peripherals (even if there's no user then) to regular litex-boards?
<_florent_>
ah sorry, just saw this was already fixed in your branch...
<acathla>
Ok, I need help : VexRiscV without icache : 4336 LC, VexRiscV with iCacheSize 1024 : 4243 LC. How is it possible to have a negative cost to add a nice feature?
<tmbinc>
_florent_: thanks! (I'm sorry - I should have split my up the PR)
<mithro>
_florent_: Does the pythondata-misc-opentitan repository look okay?
rj has quit [Ping timeout: 268 seconds]
rj has joined #litex
<_florent_>
mithro: yes thanks, thanks for noticing that ibex was already in opentitan repo
<mithro>
We could make the pythondata-cpu-ibex just be a dummy package which depends on pythondata-misc-opentitan ?
<_florent_>
mithro: yes, don't know pythondata-cpu-ibex is worth now that we know it's already in opentitan?
<mithro>
It's not like we have to "do" anything to maintain it however...
<_florent_>
but it's still one package that has for now no utility if we use the code from opentitan :)
<_florent_>
but if we can have a package called pythondata-cpu-ibex that has both ibex and the fex opentitan prim libs that are used, I can use just this one
<mithro>
_florent_: The less we do changes / modify the upstream repository the less likely it will break in the future
<_florent_>
I meant: if pythondata-cpu-ibex is just a copy of pythondata-misc-opentitan, that also fine for me
<nickoe>
_florent_: What optoins should I use for sdram_bist? sdram_bist <burst_length> <random>
<_florent_>
you can try sdram_bist 128 0 (no random) and sdram_bist 128 1
<_florent_>
ok, so with this you are using the default values (that are also the default values of the BIOS) and you can now change --rtt_nom --rtt_wr --ron and see if it improves things or not. If not, this could be a timing an issue in the DDR3 module definition
<nickoe>
_florent_: The settings that they use in the mig project, are thsye for 800 timings? It appears so for me. Anyway, with 1.5V AND 800 timings from my current litedram timings config, it seems to work STABLE! :D
FFY00 has quit [Ping timeout: 268 seconds]
FFY00 has joined #litex
<shorne_>
somlo: I think I reproduced the timeout issue setting max_blk_count to the default of 8 I got a kernel lockup in sdcard_wait_done() in send_cmd
rj has quit [Quit: rj]
Bertl_oO is now known as Bertl
<somlo>
shorne_: thanks for confirming! I'm staring at the FSMs in LiteSDCard -- I could have really used the whiteboard I have at the office :)