| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** Coldberg <[email protected]> has quit IRC (Read error: Connection reset by peer) | 01:17 | |
| *** Coldberg <[email protected]> has joined #litex | 01:17 | |
| *** Guest6487 <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 01:29 | |
| *** Degi_ <[email protected]> has joined #litex | 03:17 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 03:18 | |
| *** Degi_ is now known as Degi | 03:18 | |
| *** Guest53 <[email protected]> has joined #litex | 04:16 | |
| *** FabM <[email protected]> has joined #litex | 06:17 | |
| *** Coldberg <[email protected]> has quit IRC (Read error: Connection reset by peer) | 07:05 | |
| *** C-Man <[email protected]> has joined #litex | 07:08 | |
| *** C-Man <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 07:22 | |
| mm001 | Am I understanding right that I have to wait for the ready of the udp_streamser.sink is 1, then I can put data on the udp_streamer.sink.data port and flip the sink.valid to 1 for one click cycle to add the data to the streamer fifo? | 07:52 |
|---|---|---|
| mm001 | *clock | 07:52 |
| mm001 | I also noticed some "glitches" with the RX example we discussed on 2021-09-22. Some packets seem not to arrive. | 07:54 |
| mm001 | Can this be a clock domain problem? | 07:55 |
| zyp | no, you can provide data as soon as you have it, and should set valid=1 whenever you're presenting valid data | 08:04 |
| mm001 | ok, but then, if valid is 1 for more than one clock cycle, the data will be put multiple times into the fifo? | 08:07 |
| zyp | data will be put into the fifo when both valid and ready is 1 in the same cycle | 08:08 |
| zyp | i.e. if you're providing valid=1 and you also see ready=1, you should consider the data sent, and if you don't have more you set valid=0 in the next cycle | 08:08 |
| mm001 | Ah, ok... so the procedure to send one byte to the fifo is: 1. put data on data port, set valid=1, 2. wait for ready == 1 and set valid=0 then. right? | 08:13 |
| zyp | yes | 08:13 |
| mm001 | but what happens if i don't set valid=0 soon enough? will the same data be put into the fifo once more? | 08:14 |
| zyp | yes | 08:14 |
| zyp | a fifo will consume data every cycle both sink.valid and sink.ready is 1 | 08:15 |
| mm001 | and the fifo clock is synced to the self.sync? So if valid is 1 for only one clk period, the data will never be put twice into the fifo, right? | 08:17 |
| mm001 | in this case, I should rather loose some packets and not have duplicates... | 08:18 |
| zyp | depends what sort of fifo you have and what clock domain it's in | 08:18 |
| zyp | which I can't answer for your particular case | 08:19 |
| zyp | but yes, to get sane behavior its write port need to be in the same clock domain as you're using | 08:19 |
| mm001 | I'm using the LiteEthUDPStreamer | 08:20 |
| zyp | I'm not sure what clock domain that defaults to | 08:20 |
| mm001 | As _florent_ uses self.sync in the bench/arty.py example, I guess that's the correct clock domain... | 08:20 |
| zyp | you generally always use self.sync and wrap the module in a ClockDomainsRenamer() to move the entire module to a different domain | 08:21 |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Las[m] <Las[m]!~lasmatrix@2001:470:69fc:105::74e> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** dcallagh <dcallagh!~dcallagh@2001:470:69fc:105::9c5> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** david-sawatzke[m <david-sawatzke[m!~david-saw@2001:470:69fc:105::1634> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** OmkarBhilare[m] <OmkarBhilare[m]!~ombhilare@2001:470:69fc:105::4e51> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** dmiller[m] <dmiller[m]!~dmillergn@2001:470:69fc:105::e9f6> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** DerekKozel[m] <DerekKozel[m]!~dkozelgnu@2001:470:69fc:105::2f14> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** leons <leons!~leons@2001:470:69fc:105::abc> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** hjimenez93[m] <hjimenez93[m]!~hjimenez9@2001:470:69fc:105::fe30> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** willcode4[m] <willcode4[m]!~willcode4@2001:470:69fc:105::e1b3> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** vomoniyi[m] <vomoniyi[m]!~vomoniyig@2001:470:69fc:105::3023> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** amstan <amstan!~amstan@2001:470:69fc:105::1e9> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** bluecmd <bluecmd!~bluecmd@2001:470:69fc:105::1d44> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| mm001 | ok, thanks a lot for your help! I'll try now to wait for ready to be 1 to set valid back to 0 | 08:23 |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has joined #litex | 08:24 | |
| mm001 | another question: if i want e.g. to send one byte at a time in a packet, i can hardwire the "last" signal to 1, right? | 08:25 |
| zyp | yes | 08:25 |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has joined #litex | 08:25 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #litex | 08:25 | |
| *** dcallagh <dcallagh!~dcallagh@2001:470:69fc:105::9c5> has joined #litex | 08:25 | |
| *** david-sawatzke[m <david-sawatzke[m!~david-saw@2001:470:69fc:105::1634> has joined #litex | 08:25 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has joined #litex | 08:25 | |
| *** DerekKozel[m] <DerekKozel[m]!~dkozelgnu@2001:470:69fc:105::2f14> has joined #litex | 08:26 | |
| *** vomoniyi[m] <vomoniyi[m]!~vomoniyig@2001:470:69fc:105::3023> has joined #litex | 08:26 | |
| *** leons <leons!~leons@2001:470:69fc:105::abc> has joined #litex | 08:26 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has joined #litex | 08:26 | |
| *** Las[m] <Las[m]!~lasmatrix@2001:470:69fc:105::74e> has joined #litex | 08:26 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #litex | 08:26 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has joined #litex | 08:26 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has joined #litex | 08:26 | |
| *** amstan <amstan!~amstan@2001:470:69fc:105::1e9> has joined #litex | 08:26 | |
| *** OmkarBhilare[m] <OmkarBhilare[m]!~ombhilare@2001:470:69fc:105::4e51> has joined #litex | 08:26 | |
| *** HumbertoJimenez[ <HumbertoJimenez[!~hjimenez9@2001:470:69fc:105::fe30> has joined #litex | 08:26 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has joined #litex | 08:26 | |
| *** willcode4[m] <willcode4[m]!~willcode4@2001:470:69fc:105::e1b3> has joined #litex | 08:26 | |
| *** dmiller[m] <dmiller[m]!~dmillergn@2001:470:69fc:105::e9f6> has joined #litex | 08:26 | |
| *** bluecmd <bluecmd!~bluecmd@2001:470:69fc:105::1d44> has joined #litex | 08:26 | |
| mm001 | Thanks! | 08:27 |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:ac7b:1555:3d5f:1f9f> has quit IRC (Ping timeout: 260 seconds) | 08:29 | |
| mm001 | Is there a doc somewhere where such things are described? | 08:31 |
| zyp | https://github.com/enjoy-digital/litex/wiki/Streams | 08:32 |
| mm001 | Ah, yes, I had seen that. That's why I was waiting for ready to be 1 before setting valid to 1: "When the sink becomes ready (ie the UART is ready to transmit another byte), the ready signal is asserted, and data can be written by setting up the payload data as above and asserting the valid signal. When the valid signal is asserted, the data is read by the module." | 08:42 |
| zyp | «While the UART example above may have been easy to get started with, it violates the Streams protocol: Actually when both valid and ready are asserted, then only may the data 'legally' handed on.» | 08:43 |
| mm001 | yes, just seen :-) | 08:43 |
| zyp | IIRC the rules states that ready can combinatiorally depend on valid, but not the other way around | 08:45 |
| tnt | https://developer.arm.com/documentation/ihi0022/c/Channel-Handshake/Dependencies-between-channel-handshake-signals | 08:49 |
| tpb | Title: Documentation – Arm Developer (at developer.arm.com) | 08:49 |
| mm001 | thanks! | 08:53 |
| mm001 | And maybe a stupid question, but it's ok for a 'counter = Signal(26)' to do in self.sync: counter.eq(counter + 1) and If(counter == 0, ...), right? | 09:04 |
| mm001 | I'm sorry but it seems to be something that should be so easy and I don't know what I am doing wrong. If anyone has a minute to have a look at pastebin.com/U2DebcdB and check if there is something obviously wrong, I would be very grateful | 09:13 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 09:28 | |
| *** TMM_ <[email protected]> has joined #litex | 09:29 | |
| mm001 | I get some duplicate packets, sometimes three times the same packet | 09:30 |
| mm001 | Then, sometimes, there are malformed packets... | 09:31 |
| mm001 | strange. | 09:32 |
| mm001 | then, often after duplicates, the counter2 is skipped a few values. | 09:53 |
| mm001 | with tx_fifo_depth=None, it doesn't work at all. | 09:58 |
| leons | mm001: what data width is your stream? | 09:59 |
| mm001 | 8 | 10:00 |
| leons | You might be running into https://github.com/enjoy-digital/litex/pull/1008 | 10:01 |
| leons | Ah, for 8 it should work :) | 10:01 |
| mm001 | at least, I think so. I don't change it, so it should be the default dw=8 | 10:02 |
| *** C-Man <[email protected]> has joined #litex | 10:04 | |
| mm001 | with tx_fifo_depth=1, it does also not work... | 10:06 |
| mm001 | with tx_fifo_depth=256 it sends data, but with the same problem as described (duplicates, malformed packets, skipped data) | 10:17 |
| mm001 | and at sometime it freezes. | 10:17 |
| leons | That does sound like symptoms I’ve experienced with the packetizer and depacketizer. Maybe it‘d be worth a shot to just apply the patches from my PR and test? Maybe it switches to 32bit dw somewhere in between | 10:22 |
| mm001 | Some packets have the data repeated multiple times | 10:22 |
| mm001 | leons: yes, I'll try that | 10:23 |
| mm001 | so you don't see any obvious mistake in the pastebin? | 10:27 |
| *** Las[m] <Las[m]!~lasmatrix@2001:470:69fc:105::74e> has quit IRC (Quit: Reconnecting) | 11:08 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:5120:3edd:7c22:3adb> has joined #litex | 11:19 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 12:33 | |
| *** shorne <[email protected]> has joined #litex | 12:41 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 12:49 | |
| *** shorne <[email protected]> has joined #litex | 12:51 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 12:57 | |
| *** TMM_ <[email protected]> has joined #litex | 12:57 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 14:55 | |
| *** awordnot <awordnot!~awordnot@user/awordnot> has quit IRC (Ping timeout: 250 seconds) | 16:23 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #litex | 17:04 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 265 seconds) | 17:06 | |
| *** Guest53 <[email protected]> has quit IRC (Quit: Client closed) | 17:23 | |
| *** Guest53 <[email protected]> has joined #litex | 17:26 | |
| *** indy <[email protected]> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 17:38 | |
| *** indy <[email protected]> has joined #litex | 17:39 | |
| *** ilia__s <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 19:07 | |
| *** ilia__s <[email protected]> has joined #litex | 19:08 | |
| *** Guest53 <[email protected]> has quit IRC (Quit: Client closed) | 19:23 | |
| *** Coldberg <[email protected]> has joined #litex | 19:48 | |
| *** C-Man <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 19:51 | |
| *** Guest53 <[email protected]> has joined #litex | 19:52 | |
| *** Xesxen <Xesxen!~cyber@hackalot/deelnemer/xesxen> has quit IRC (Remote host closed the connection) | 20:17 | |
| *** Xesxen <Xesxen!~cyber@hackalot/deelnemer/xesxen> has joined #litex | 20:19 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 20:38 | |
| *** shorne <[email protected]> has joined #litex | 20:40 | |
| *** peeps[zen] is now known as peepsalot | 20:47 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!