07:52 <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:54 <mm001> I also noticed some "glitches" with the RX example we discussed on 2021-09-22. Some packets seem not to arrive.

07:55 <mm001> Can this be a clock domain problem?

08:04 <zyp> no, you can provide data as soon as you have it, and should set valid=1 whenever you're presenting valid data

08:07 <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:08 <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:13 <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:14 <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:15 <zyp> a fifo will consume data every cycle both sink.valid and sink.ready is 1

08:17 <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:18 <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:19 <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:20 <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:21 <zyp> you generally always use self.sync and wrap the module in a ClockDomainsRenamer() to move the entire module to a different domain

08:23 <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:25 <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:27 <mm001> Thanks!

08:31 <mm001> Is there a doc somewhere where such things are described?

08:32 <zyp> https://github.com/enjoy-digital/litex/wiki/Streams

08:42 <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:43 <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:45 <zyp> IIRC the rules states that ready can combinatiorally depend on valid, but not the other way around

08:49 <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:53 <mm001> thanks!

09:04 <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:13 <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:30 <mm001> I get some duplicate packets, sometimes three times the same packet

09:31 <mm001> Then, sometimes, there are malformed packets...

09:32 <mm001> strange.

09:53 <mm001> then, often after duplicates, the counter2 is skipped a few values.

09:58 <mm001> with tx_fifo_depth=None, it doesn't work at all.

09:59 <leons> mm001: what data width is your stream?

10:00 <mm001> 8

10:01 <leons> You might be running into https://github.com/enjoy-digital/litex/pull/1008

10:01 <leons> Ah, for 8 it should work :)

10:02 <mm001> at least, I think so. I don't change it, so it should be the default dw=8

10:06 <mm001> with tx_fifo_depth=1, it does also not work...

10:17 <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:22 <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:23 <mm001> leons: yes, I'll try that

10:27 <mm001> so you don't see any obvious mistake in the pastebin?