Tuesday, 2021-09-28

*** tpb <[email protected]> has joined #litex00:00
*** willcode4[m] <willcode4[m]!~willcode4@2001:470:69fc:105::e1b3> has joined #litex00:00
*** vomoniyi[m] <vomoniyi[m]!~vomoniyig@2001:470:69fc:105::3023> has joined #litex00:00
*** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has joined #litex00:07
*** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has joined #litex00:08
*** Guest64 <[email protected]> has quit IRC (Quit: Client closed)00:41
*** Guest64 <[email protected]> has joined #litex00:46
*** Degi_ <[email protected]> has joined #litex03:20
*** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds)03:20
*** Degi_ is now known as Degi03:20
*** Wolf0 <Wolf0!~Wolf0@user/wolf0> has joined #litex04:15
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)05:27
*** TMM_ <[email protected]> has joined #litex05:27
*** FabM <[email protected]> has joined #litex07:11
_florent_somlo: thanks for the feedback, the breakage in Rocket seems related to atomics, switching the arch from rv64imac to rv64imc makes it work (at least in simulation)11:08
_florent_it's probably an issue with getchar in atomic mode, at least when adding traces, the IRQs/BIOS code are behaving correctly11:09
somlo_florent_: on a side note, my ability to run in simulation broke this mornign with "from vcd.gtkw import GTKWSave" -> ModuleNotFoundError: no module named 'vcd'11:28
somlotrying to figure out which python package I'm missing :)11:28
somloand how come it worked fine last night (reverting 782744ba doesn't help, so that wasn't it)11:29
_florent_somlo: ok thanks, that's probably pyvcd11:29
_florent_but I'll enable this only with --trace11:30
_florent_https://github.com/enjoy-digital/litex/commit/12c93ea8952d45d6ab273c52c8a10cb1cf5683b911:32
somlo_florent_: thanks (I'll save figuring out how to package pyvcd for Fedora another day -- I try hard to stay away from "sideloading" stuff other than what I'm actively working on behind the back of my distro package manager) :)11:35
somlo_florent_: you're right, setting "rv64imc" in GCC_FLAGS makes console input work, although I'm not sure whether I'm comfortable with this as a long-term workaround...11:41
somloalso, it's only on rocket (or 64-bit) that atomics are a problem -- vexriscv "linux" variant (rv32ima) seems to work fine11:44
_florent_somlo: yes we still have to understand, I'll try to have a closer look11:59
_florent_for now an acceptable workaround until we find what's going on could be to disable RISC-V atomics support for the BIOS with picolibc 12:00
*** Guest64 <[email protected]> has quit IRC (Quit: Ping timeout (120 seconds))12:02
somlo_florent_: I'm building a nexys4ddr bitstream with 'a' removed, to test if that also gets it to work there...12:19
_florent_somlo: https://github.com/enjoy-digital/litex/commit/a588c3b830d92c2d0525a0489c5e6b87ec25e883 fixes the issue (at least in simulation)12:53
somlo_florent_: thanks! I'm in the process of rebuilding the nexys4ddr bitstream, will report back in cca. 30 minutes when it's done13:01
*** pftbest <[email protected]> has quit IRC (Remote host closed the connection)13:03
*** pftbest <[email protected]> has joined #litex13:03
Wolf0_florent_: hey! I'm doing more with the Xilinx HBM parts, and... I think I was wrong about them using 1000Mhz binned parts. They.... might just be using 1200Mhz bin.13:47
somlo_florent_: unfortunately, while console input did start working for rocket in sim, on the fpga there's still no console activity at all (blinkie lights do start working when I push the bitstream)13:57
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #litex14:04
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 265 seconds)14:05
_florent_somlo: I got it working here on Arty with upstream LiteX. Are you sure picolibc was fully rebuilt on your side? (can you do a rm -rf build to be sure?)15:00
_florent_I can also test on a nexys4ddr15:01
somlo_florent_: I always rm -rf build/<board_name> before rebuilding15:02
somlotried it on both nexys4ddr and the ecpix5, and got nothing on the console...15:02
*** michalsieron <[email protected]> has joined #litex15:30
somlo_florent_: even more interesting, it works if I leave out "--with-ethernet" and "--with-sdcard"15:32
somloon the nexys4ddr, that is15:32
somloso it's got something to do with one or both of liteeth, litesdcard...15:32
_florent_somlo: I was just testing on hardware and was going to share the same conclusion :)15:33
_florent_on my side, it no longer works with only "--with-ethernet"15:34
somlothat's the one I'm building right now -- next was going to be only litesdcard :)15:34
_florent_somlo: In fact, it also seems to happen with the simulation when adding --with-ethernet15:35
_florent_so it will probablybe easier to investigate with it15:35
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 252 seconds)15:35
somlomakes sense -- I'll kill my current ethernet-only build and start a sdcard-only one, just to (hopefully) rule that out15:37
_florent_somlo: just adding --with-sdcard also seems to broke the simulation15:40
*** michalsieron <[email protected]> has quit IRC (Quit: michalsieron)15:45
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)16:27
*** TMM_ <[email protected]> has joined #litex16:27
somloyeah, here as well (just got back from running some errands while the build was going on)... 16:28
somlobut maybe figuring out why liteeth causes it will help with the overall issue, if we're lucky...16:29
DerekKozel[m]_florent_: Do you know if the litepcie DMA support handles non-full buffers? I see some lines handling alignment but wanted to check16:33
_florent_DerekKozel[m]: for the Host --> FPGA sense, the FPGA will have to flush the un-wanted data16:44
_florent_for the FPGA --> Host sense, it's possible to terminate the buffer early by asserting the last signal of stream16:45
DerekKozel[m]So for DMA_BUFFER_SIZE=8192, If I write 1000 bytes to the file descriptor what will arrive? Any indication of the empty space in the buffer?16:45
_florent_the capability also has to be enabled in the DMA descriptor16:45
DerekKozel[m]and on receive, read would return len=1000 correctly?16:46
DerekKozel[m]I'm just looking at the loopback at the moment, the student working on GNU Radio demo is almost complete except this case16:46
_florent_The current drivers is expecting full buffers16:48
_florent_the hardware can support non-full buffer, but the litepcie driver would need to be improved to support it16:48
DerekKozel[m]Ok, thanks. That's reasonable for GNU Radio to accomodate16:52
_florent_I've mostly been using the code to do continuous streaming in both directions, you could probably do the same in GNU radio16:54
_florent_in this case, that's the FPGA and RFIC that regulate the transfer speed, so the software just use the IRQs/DMA loop statuses to prepare the samples in advance (TX) or be able to accept them (RX) 16:56
_florent_somlo: Disabling LTO here (removing -flto) fixes the issue with "--with-ethernet" (at least in simulation)... but...16:58
_florent_somlo: breaks the case without "--with-ethernet"....16:59
somlo_florent_: I just tried `rm -rf build/sim; litex/litex/tools/litex_sim.py --threads 4 --opt-level Ofast --cpu-type rocket --with-ethernet` and got an error: https://imgur.com/a/XYY4d3b17:01
tpbTitle: Imgur: The magic of the Internet (at imgur.com)17:01
*** Guest6452 <[email protected]> has joined #litex17:02
_florent_ah yes, add --integrated-main-ram-size=0x1000017:02
somlook, makes sense, thanks17:02
*** peeps[zen] is now known as peepsalot17:33
DerekKozel[m]<_florent_> "I've mostly been using the..." <- Yes, it's just the possible final few hundred samples that we'll have to discard, or pad out18:30
_florent_DerekKozel[m]: I could have a look in the next days, happy to do some tests with you if needed19:22
DerekKozel[m]It'd be of low priority interest to be able to handle that.19:32
DerekKozel[m]Of much more interest would be an example of a liteaccelerator type setup for the CLE-215+ that does PCIe->Small DSP step like add 1 to  each int32 passing through->PCIe19:36
DerekKozel[m]My big block looking at this last time was trying to figure out how to configure, either statically at gateware build time or dynamically at runtime, how to create streams between the PCIe interfaces and some blob of HDL doing an operation.19:37
DerekKozel[m]Thank you for the offer of testing the PCIe transfer cases. It would be good to be able know what's possible and why/why-not19:38
_florent_DerekKozel[m]: ok, I indeed want to create a project that would provide such examples, I'll try to speed this a bit :)19:51
DerekKozel[m]The GNU Radio side got a big boost this semester with Victor working on it. Even the simplest example would be really helpful. 19:55
mm001_florent_ May I ask once again for your help, please? I have continued experimenting and managed to send data from fpga to computer via LiteEthUDPStreamer. I have implemented a counter which increments in self.sync. In self.sync, if the counter == 0 (once a second) and udp_streamer.sink.ready == 1, I set the udp_streamer.sink.valid.eq(1). Now here is my problem: Every packet seems to be sent twice or three times. As if the valid bit was high 20:02
mm001for too long. Any idea where this may come from? Does the streamer have another clock than the self.sync clock?20:02
*** Guest6452 <[email protected]> has quit IRC (Quit: Client closed)20:12
*** Guest6487 <[email protected]> has joined #litex20:27
keesjlo21:23

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!