| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:a870:7807:f9b0:ad06> has quit IRC (Read error: Connection reset by peer) | 02:02 | |
| *** Degi_ <[email protected]> has joined #litex | 02:25 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 02:27 | |
| *** Degi_ is now known as Degi | 02:27 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:681d:764d:8b4d:e996> has joined #litex | 03:51 | |
| *** indy <[email protected]> has quit IRC (Read error: Connection reset by peer) | 04:14 | |
| *** indy <[email protected]> has joined #litex | 04:17 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has quit IRC (*.net *.split) | 05:00 | |
| *** CarlFK <CarlFK!~carlfk@2001:470:69fc:105::5d8> has quit IRC (*.net *.split) | 05:00 | |
| *** novenary <[email protected]> has quit IRC (*.net *.split) | 05:00 | |
| *** zyp <[email protected]> has quit IRC (*.net *.split) | 05:00 | |
| *** zyp <[email protected]> has joined #litex | 05:00 | |
| *** novenary <[email protected]> has joined #litex | 05:01 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has joined #litex | 05:03 | |
| *** CarlFK <CarlFK!~carlfk@2001:470:69fc:105::5d8> has joined #litex | 05:09 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 05:21 | |
| *** TMM_ <[email protected]> has joined #litex | 05:21 | |
| *** _franck_ <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 07:21 | |
| *** _franck_ <[email protected]> has joined #litex | 07:21 | |
| leons | _florent_: I've looked into the Packetizer/Depacketizer situation a bit and realize that my fixes cause some unexpected behavior for when no data qualifier is being used. | 08:41 |
|---|---|---|
| leons | At the same time, with your revert-commit applied on top -- even when no last_be data qualifier is present -- my tests break because one edge case causes the Packetizer to break pretty badly: when the first bus word is also the last, it'll reach a state where it won't ever get out of and just produce the same packet in a loop | 08:43 |
| *** Coldberg <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 08:54 | |
| leons | But honestly speaking, I can't even wrap my head around what a useful implementation for a Packetizer or Depacketizer without a data qualifier should look like. | 09:05 |
| leons | Let's assume a 5 byte header and 6 bytes data. That'll generate a 32-bit data stream of HHHH HDDD DDDX | 09:06 |
| leons | When we have 8 bytes of data it'll look like HHHH HDDD DDDD DXXX | 09:06 |
| leons | A depacketizer to avoid dropping bytes would recover the first data as DDDD DDXX, all fine | 09:06 |
| leons | The second data would also fit into two bus words, but because the depacketizer doesn't know that it would recover DDDD DDDD XXXX | 09:06 |
| leons | So the last word does not contain any useful data. | 09:06 |
| *** AndrewD_ <[email protected]> has joined #litex | 09:09 | |
| AndrewD_ | Was is the recommended way to read the clock domain for a sync? | 09:10 |
| AndrewD_ | I want to detect if a clockdomainsrenamer has been applied | 09:11 |
| leons | _florent_: What I can propose to do is to integrate your "revert" commit for the last/ready logic into the proper last_be handling code. Then it'll continue to work with the test_packet.py and I'm happy too given that it'll work correctly with last_be. But it won't work with the non-last_be cases in test_packet2.py because they test cases which cause the infinite loop problem which currently also exists upstream | 09:15 |
| leons | So it's really not an issue with the tests but indeed broken 🙂 I'd just comment out the respective tests | 09:16 |
| *** AndrewD_ <[email protected]> has quit IRC (Quit: Client closed) | 09:37 | |
| _florent_ | leons: Sorry I just saw your messages here | 09:49 |
| leons | _florent_: I just saw your commit moving it to liteeth 😀 | 09:50 |
| _florent_ | I in fact created a local copy of Packetizer/Depacketizer in LiteEth directly (that now also use them) to ease the development | 09:50 |
| leons | Yeah, it broke my hacky fix PR but that's okay 🙂 | 09:50 |
| _florent_ | This way your tests are still passing (and mine is also passing in LiteX for the other cores). | 09:51 |
| leons | Thanks, I think that makes things easier. My point is still valid for the bugs in the LiteX packetizer though :). It has some bugs which my test infrastructure did uncover (even without the last_be signal) so it might be worth looking into those in the future. | 09:52 |
| _florent_ | Yes sure, I want to work on that in the next days and try to switch LitePCIe to Packetizer/Depacketizer | 09:55 |
| leons | Thank you! Looking forward to seeing the changes required to the Packetizer/Depacketizer. | 09:57 |
| _florent_ | leons: I think we can agree that the current last_be data qualifier both give us headaches and that there is clearly something to do :) | 09:59 |
| leons | Absolutely. This is easily one of the most complex things I have worked on for some time now. But it's great to recover from the PTSD for now and have a "works for me" version in LiteEth 🙂 | 10:00 |
| _florent_ | leons: While I'm looking at this, if you have time, would you make sure we have good tests or designs exercising last_be in LiteEth that we could use to switch to the simpler data qualifier? | 10:01 |
| leons | Happy to collaborate on trying to come up with something that's less painful | 10:01 |
| leons | Well, I think the rewritten test_stream.py and test_packet.py excercise all known edge-cases of last_be (that's why they take so long), and the infrastructure is pretty flexible in switching it out for a different one, so I think we're covered there | 10:03 |
| _florent_ | leons: I'll also prepare some hardware to be able to test it. I'm not sure to remember your test setup, can you describe it to me again? | 10:03 |
| leons | Oh, and if it helps, this is a screenshot the failure case I've seen with upstream Packetizer/Depacketizer: | 10:03 |
| * leons uploaded an image: (114KiB) < https://libera.ems.host/_matrix/media/r0/download/is.currently.online/lSSjOYABryCRerFjpTnkYOFU/image.png > | 10:03 | |
| _florent_ | Thanks | 10:05 |
| acathla | Doc about CSRStorage says: "Size of the CSR register in bits. Can be bigger than the CSR bus width." But it does not say what's the size limit. It seems to use uint64_t in csr.h when CSR is less than 64bits and stop generating the code if >64 | 12:12 |
| acathla | I would like to make a module that controls 5 neopixels only, just send a color value, no complex effects. I already have the logic for one or two pixels using CSRStorage. I would like to use some BRAM or something else a little more optimized than many CSR. | 13:26 |
| acathla | I started with that code : https://www.hacknology.de/projekt/2020/neopixelar/ but it seems strange to store address and values in CSR to access a memory... | 13:27 |
| tpb | Title: Neopixelar oder 'Wie geht FPGA?' · hacKNology (at www.hacknology.de) | 13:27 |
| *** Coldberg <[email protected]> has joined #litex | 13:34 | |
| *** AndrewD <[email protected]> has quit IRC (Quit: Client closed) | 13:56 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 18:34 | |
| *** TMM_ <[email protected]> has joined #litex | 18:34 | |
| zyp | acathla, how many colors do you need? | 19:05 |
| zyp | I've also got a chain of 5 for indicators, and I've just set them up with 1-bit colors | 19:06 |
| *** _franck_0 <[email protected]> has joined #litex | 20:20 | |
| *** _franck_ <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 20:22 | |
| *** _franck_0 is now known as _franck_ | 20:22 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:681d:764d:8b4d:e996> has quit IRC (Read error: Connection reset by peer) | 23:36 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:c14c:ce51:723f:8f50> has joined #litex | 23:44 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
