_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
chiefwigms has quit [Quit: Client closed]
Degi_ has joined #litex
Degi has quit [Ping timeout: 245 seconds]
Degi_ is now known as Degi
<tnt> Hi. I'm looking at linux.config in linux-on-litex-vexriscv and I see CONFIG_SMP is y ? Is that expected for a single cpu riscv setup ?
<shoragan> tnt, litex supports generating multicore vexriscv
C-Man has quit [Ping timeout: 258 seconds]
<Finde> SMP doesn't mean there necessarily are multiple cores, just that they're supported
<tnt> yeah, I just wasn't sure if the CSR (or alike) used to even detect multiple cores would be supported in a single core vex.
joseng has joined #litex
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
C-Man has joined #litex
<tnt> Somewhat related question : Anychance of running linux on rv32 without atomics ?
<gatecat> doing the emulation in M-mode would be cleaner
<tnt> gatecat: Oh nice, thanks !
<tnt> ATM I'm just trying to get things vaguely doing something ... but DCache is too large and AFAICT Vex doesn't support AMO without DCache.
<leons> I've been working on getting LiteX to work on some FPGA board, and unfortunately I'm again at the point where I have issues with DRAM and no clue really on how to diagnose these.
<leons> Weirdly enough, my DRAM memory seems to work but the memtest is still "KO"
<tnt> "best: m2, b04 delays: -" sounds bad to me
<tnt> looks like one of the group failed training
<leons> tnt: Ah, right, I see that now. I should probably check the constraints then, right? Is there any signal to watch out for specifically?
<tnt> DQS maybe.
<tnt> but really I think a wrong DQ would also cause it so .
<gatecat> yeah
<gatecat> DQS, DQ and DM
<gatecat> for m02, the third group
pftbest has quit [Read error: Connection reset by peer]
pftbest has joined #litex
<leons> Woah cool, the second DRAM module works perfectly! Will check the constraints of the first now.
<leons> It's really tedious so I've been whipping up a small python script to translate the MIG XML files to LiteX constraints :)
<leons> With at least one of my DRAM modules running, I'm reaching speeds of approx. 30MiB/s write and 26MiB/s read. The reference of my FPGA board claims that the DRAM can run at 800MHz and my board features a 233.3MHz clock signal to be used by the MIG. Does LiteDRAM support running the memory at higher speeds, through an external clock?
<_florent_> leons: The speed reported by the BIOS is the speed seen by the CPU (with the CPU/Wishbone being the bottleneck)
<leons> florent: Ah, right, I suspected that already
<_florent_> if you want to test with a hardware generator/check, you can enable the BIST module by setting with_bist=True in add_sdram
<_florent_> you'll then have a sdram_bist command available in the BIOS
<_florent_> the issue with your first DRAM could be related to a missing INTERNAL_VREF or DCI_CASCADE property
<_florent_> make sure to apply/user the ones you'll find in the MIG
<_florent_> apply/use
<leons> Ah, thanks. I can confirm that works, unfortunately getting a ton of errors which I suppose isn't expected :)
chiefwigms has joined #litex
<leons> _florent_: I'm afraid I think the MIG generates for both INTERNAL_VREF and DCI_CASCADE the value 0, which is not translated into a constraint
chiefwigms has quit [Quit: Client closed]
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
<Melkhior> leons: there were discussions about DRAM speed in Litex here: https://github.com/litex-hub/linux-on-litex-vexriscv/issues/229
<Melkhior> One Vexriscv can't saturate anywhere near DDR3 bandwidth, even using native interface (i.e. not going through Wishbone)
<Melkhior> I've seen 100+ MB/s with 4 cores using 1 (shared by 4 cores) or 2 (shared by 2 cores each) FPUs on the 'normal' STREAM benchmark (which is using FP64)
<Melkhior> And even 170+ MB/s using hand-tuned assembly in the critical loop
<Melkhior> That's with a 100 MHz sysclk and a 16-bits device (400 MHz DDR3)
geertu has quit [Quit: Changing server]
geertu has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
geertu has quit [Ping timeout: 252 seconds]
<leons> Melkhior: thanks for the pointer! I'm still pretty new to this stuff...
<leons> Eventually I'd like to access the memory in hardware anyways, but for now it's a good first milestone to get the memory working at all :)
<leons> With AXI lite I'm getting about 600MiB/s in both directions, which isn't too bad but nowhere near the theoretical limit
<leons> (That's in hardware of course, with `sdram_bist`)
<Melkhior> leons: that's already pretty impressive!
<leons> Melkhior: But with a 64-bit 800MHz DDR3
<Melkhior> leons: whoa that's a big memory for a FPGA
<leons> Yeah, the FPGA is pretty OP, 2x4GB and Virtex7 690T. Not mine, of course :)
<Melkhior> That's not-so-old laptop territory already...
<Melkhior> Hehe, yes I also have a 'big' one but it's for work only :-)
<Melkhior> Fun stuff can make do with an Artix-7
<leons> Absolutely.
<leons> _florent_: Is a basic SoC with UART, LEDs, Buttons and one of the SO-DIMMs sufficient for an initial upstream already or should I try to get both memories and the Ethernet working first?
<leons> I'm also thinking about trying to wire a MIG-generated memory up to the AXI lite bus, just to find out whether my hardware is borked or I'm doing something wrong with LiteDRAM (probably the latter)
geertu has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
analognoise has quit [Quit: Leaving]
pftbest has joined #litex
ewen has joined #litex
pftbest has quit [Quit: Leaving...]
ewen has quit [Ping timeout: 255 seconds]