<_florent_>
shenki: can you check if the simulation is working (requires installing the GHDL-synth plugin)?
<leons>
Does LiteX have a module for collecting/buffering a stream transaction with a size limit, such that it's guaranteed to be readable with valid == 1 over the whole transaction?
<leons>
Specifically, I'm upconverting a 32-bit stream to 64 bit for XGMII Ethernet and the stream through the Ethernet pipeline must never have valid == 0 in a transaction. So my naive solution, because I know that this stream is only a few bytes in size, is to collect a transaction entirely and then allow the consumer to read it in one go
<leons>
Ah, the moment you ask... PacketFIFO looks promising
<_florent_>
leons: yes I was going to suggest you this, that's the purpose of PacketFIFO
<leons>
_florent_: by the way, is there any progress in the Packetizer/Depacketizer side? Would it be possible to get the fixed version in first and then eventually rework the data qualifier? I've been using this version quite successfully without any issues for some time now, so it seems strictly better than the upstream version.
ewen has joined #litex
<_florent_>
leons: Sorry, too much things ongoing currently, I would be ok to merge the changes in litex/soc/interconnect/packet.py but not the test. Could you do a PR with just the logic changes? I'll be able to merge it. We could discuss changing the approach for the test during the data qualifier rework.
<leons>
Okay, though is there any specific reason why you wouldn't want the tests to be merged?
<_florent_>
Because 1) Without spending the time to fully understand it (which I don't have now) I lose the ability to maintain it 2) I'd also like to keep the previous test 3) We could maybe try to allow the new packet simulation classes to be used more widely but also need to discuss a bit.
<leons>
Okay, that makes sense.
<_florent_>
But if you keep the previous test and rename yours to test_packet2, I'm OK to merge it now and eventually merge both tests together in the future.
<leons>
I was asking whether there's some specific aspect I didn't cover (because I'm happy to further work on that) but it sounds like the concepts are good in general, just need to spend more time on it
<leons>
I'm fine with splitting it out - no worries. I was just asking because developing the Packetizer/Depacketizer without tests is, at least in my experience, pretty insane 😀
<_florent_>
So if you update the PR, keeping the previous test_packet and renaming yours to test_packet2, I'll merge it.
AndrewD has joined #litex
<AndrewD>
I've switched my Nick from mc6808 to match my GitHub pull requests
<AndrewD>
_florent_: thanks for getting litespi and everything else together so xyloni builds with uartbone
<AndrewD>
I tried uartbone briefly today with no success. Did you get anywhere?
<AndrewD>
I wonder if we need to drop the clock a bit.
<AndrewD>
I started experimenting to support the v1 pll on T8 the other day but didn't get it completed
<_florent_>
AndrewD: python3 -m litex_boards.targets.efinix_xyloni_dev_kit --build --flash should now produce a working bitstream
<trabucayre>
this mode allows to have something similar to xilinx, intel, ...
<trabucayre>
it's avoid to have two interfaces :)
AndrewD has joined #litex
<AndrewD>
trabucayre: can jtag access spi flash on T8? There are some limitations on the v1 trion devices
<AndrewD>
But I don't remember all the details from what I read early this week
<AndrewD>
I thought this was the reason they have direct spi connection on the T8 Dev board
<trabucayre>
to have access to jtag, you need to reset device with cs low...
<AndrewD>
But I don't think T20 and higher required this
<trabucayre>
I need to check. But T20/T120 are to expensive...
ewen has quit [Ping timeout: 258 seconds]
<AndrewD>
The T20 in CSP package is not too bad, but still twice the cost of T8
<AndrewD>
Roughly
<trabucayre>
boards are expensive :)
<AndrewD>
I would definitely like to use T8 of we can though to keep cost under control
<AndrewD>
The dev boards?
<AndrewD>
We are going to do a simple T20 csp Dev board
<trabucayre>
ok. Good to know
<AndrewD>
Just for internal use, but I might be able to build a few more
<trabucayre>
I have xyloni & fireant but nothing higher
<AndrewD>
Basically xyloni but with T20 is what I had in mind
<trabucayre>
looks good
<AndrewD>
Will be useful in development so we can avoid premature optimisation
<trabucayre>
yep
AndrewD has quit [Ping timeout: 256 seconds]
cr1901 has joined #litex
<somlo>
_florent_: thanks for the link! It provides or1k-buildroot-* and or1k-linux-*, but apparently litex insists on or1k-elf-* (and throws an error when all I have is the openrisc--musl toolchain you linked me to: https://pastebin.com/kcAvdTHS
<somlo>
_florent_: and if I comment that out, it starts to compile the bios, then errors out with a whole bunch of picolibc syntax errors: https://pastebin.com/qAVJP8pF
<somlo>
so assuming we're both using the latest git master of everything, I wonder what else is different between your setup (which I assume worked for you) and mine (which crashes and burns, spectacularly, as shown in the paste) :)
FabM has quit [Quit: Leaving]
<cr1901>
_florent_: I took a brief look at trying to migrate litex to meson. I think it's possible, but it would require some rearchitecting and not really appropriate for now.
<cr1901>
Specifically, I think Builder() shouldn't directly generate any files except a meson cross file, and meson calls back into Builder() to generate the linker script, headers, etc.
<cr1901>
Would you be receptive to a rearchitecting like this in the medium term?
<cr1901>
The short version is that "meson wants to find everything in either your source or build dir", and litex violates this a lot :P.
<_florent_>
Thanks cr1901, sorry I would also need to have a closer look at meson to see the pros/cons to be able to answer. I will try to take a bit of time in the next weeks to look at it and be able to answer.
futarisIRCcloud has joined #litex
<nickoe>
_florent_: OK (Re. the flashing of the flash)
_franck_3 has joined #litex
_franck_ has quit [Ping timeout: 258 seconds]
_franck_3 is now known as _franck_
<cr1901>
_florent_: I can still do a proof-of-concept/WIP PR if you want
<cr1901>
If you don't like it/decide it's not a direction worth going, you can close it :).
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_florent_>
cr1901: I'm not very confortable knowing you'll spend time on something without knowing it's the direction to go
<_florent_>
cr1901: so if you do it, just do a very quick proof-of-concept and don't spend too much time on it
<cr1901>
_florent_: Ack
<cr1901>
I'm gonna hold off then b/c I don't think it can be done quickly. The system we have works fine now. I just feel bad we need all of meson, make, and ninja lol