<_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)
<_florent_>
it's probably an issue with getchar in atomic mode, at least when adding traces, the IRQs/BIOS code are behaving correctly
<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'
<somlo>
trying to figure out which python package I'm missing :)
<somlo>
and how come it worked fine last night (reverting 782744ba doesn't help, so that wasn't it)
<_florent_>
somlo: ok thanks, that's probably pyvcd
<_florent_>
but I'll enable this only with --trace
<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) :)
<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...
<somlo>
also, it's only on rocket (or 64-bit) that atomics are a problem -- vexriscv "linux" variant (rv32ima) seems to work fine
<_florent_>
somlo: yes we still have to understand, I'll try to have a closer look
<_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
Guest64 has quit [Quit: Ping timeout (120 seconds)]
<somlo>
_florent_: I'm building a nexys4ddr bitstream with 'a' removed, to test if that also gets it to work there...
<somlo>
_florent_: thanks! I'm in the process of rebuilding the nexys4ddr bitstream, will report back in cca. 30 minutes when it's done
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<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.
<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)
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 265 seconds]
<_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?)
<_florent_>
I can also test on a nexys4ddr
<somlo>
_florent_: I always rm -rf build/<board_name> before rebuilding
<somlo>
tried it on both nexys4ddr and the ecpix5, and got nothing on the console...
michalsieron has joined #litex
<somlo>
_florent_: even more interesting, it works if I leave out "--with-ethernet" and "--with-sdcard"
<somlo>
on the nexys4ddr, that is
<somlo>
so it's got something to do with one or both of liteeth, litesdcard...
<_florent_>
somlo: I was just testing on hardware and was going to share the same conclusion :)
<_florent_>
on my side, it no longer works with only "--with-ethernet"
<somlo>
that's the one I'm building right now -- next was going to be only litesdcard :)
<_florent_>
somlo: In fact, it also seems to happen with the simulation when adding --with-ethernet
<_florent_>
so it will probablybe easier to investigate with it
FabM has quit [Ping timeout: 252 seconds]
<somlo>
makes sense -- I'll kill my current ethernet-only build and start a sdcard-only one, just to (hopefully) rule that out
<_florent_>
somlo: just adding --with-sdcard also seems to broke the simulation
<somlo>
yeah, here as well (just got back from running some errands while the build was going on)...
<somlo>
but maybe figuring out why liteeth causes it will help with the overall issue, if we're lucky...
<DerekKozel[m]>
_florent_: Do you know if the litepcie DMA support handles non-full buffers? I see some lines handling alignment but wanted to check
<_florent_>
DerekKozel[m]: for the Host --> FPGA sense, the FPGA will have to flush the un-wanted data
<_florent_>
for the FPGA --> Host sense, it's possible to terminate the buffer early by asserting the last signal of stream
<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?
<_florent_>
the capability also has to be enabled in the DMA descriptor
<DerekKozel[m]>
and on receive, read would return len=1000 correctly?
<DerekKozel[m]>
I'm just looking at the loopback at the moment, the student working on GNU Radio demo is almost complete except this case
<_florent_>
The current drivers is expecting full buffers
<_florent_>
the hardware can support non-full buffer, but the litepcie driver would need to be improved to support it
<DerekKozel[m]>
Ok, thanks. That's reasonable for GNU Radio to accomodate
<_florent_>
I've mostly been using the code to do continuous streaming in both directions, you could probably do the same in GNU radio
<_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)
<_florent_>
somlo: Disabling LTO here (removing -flto) fixes the issue with "--with-ethernet" (at least in simulation)... but...
<_florent_>
somlo: breaks the case without "--with-ethernet"....
<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/XYY4d3b
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<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 out
<_florent_>
DerekKozel[m]: I could have a look in the next days, happy to do some tests with you if needed
<DerekKozel[m]>
It'd be of low priority interest to be able to handle that.
<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->PCIe
<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.
<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-not
<_florent_>
DerekKozel[m]: ok, I indeed want to create a project that would provide such examples, I'll try to speed this a bit :)
<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.
<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
<mm001>
for too long. Any idea where this may come from? Does the streamer have another clock than the self.sync clock?