01:31 <_whitenotifier> [nmigen] RobertBaruch commented on issue #245: Unused signal seems not to change - https://git.io/JeWTk

06:34 <sb0> whitequark: with the glasgow applet you wrote for the HP laser, when I set bit 0 to 1, the result is 0x05 instead of the expected 0x11

06:34 <sb0> with 0x04 and 0x01 at the transitions

06:34 <sb0> so this suggests that the bit shift between samples in a byte is 3 instead of 4

06:35 <sb0> *2

08:20 <sb0> whitequark: and there is also random data corruption ...

08:22 <sb0> I'm feeding it a 2MHz waveform, and sometimes there are glitches, but the signal looks ok on the scope

08:42 <sb0> whitequark: tried another source of 2MHz, exactly the same problem

08:59 <sb0> whitequark: connect 2MHz source, then run "glasgow run logic -V 3.3 --pins-d 0,1", then measure the time in samples between transitions. it's usually 24 as it should be, but sometimes and rarely you get 8 or 31

08:59 <sb0> or other values

09:00 <Dar1us> tried another 2 pins just in case it is a hardware problem?

09:43 <sb0> yes, same

11:28 <whitequark> sb0: interesting

11:28 <whitequark> can you give me the source again?

11:34 <sb0> whitequark: https://git.m-labs.hk/sb10q/noptica-rs

11:35 <sb0> whitequark: https://git.m-labs.hk/sb10q/noptica-rs/src/branch/master/glasgow-applet.diff

11:36 <whitequark> sb0: try adding depth=8192 to get_in_fifo

11:37 <whitequark> the random data corruption is likely buffer overruns, which are not detected in that code, of course

11:38 <sb0> yes, the failure rate seems to vary with the computer's CPU load

11:38 <whitequark> i think the maximum fifo depth you can get is 30*512

11:38 <sb0> it's still buggy with in_fifo=iface.get_in_fifo(auto_flush=False, depth=8192),

11:38 <whitequark> that's strange

11:39 <whitequark> would need to set up something here and test

11:41 <_whitenotifier> [nmigen] whitequark closed issue #245: Unused signal seems not to change - https://git.io/JeClk

11:41 <_whitenotifier> [nmigen] whitequark commented on issue #245: Unused signal seems not to change - https://git.io/JeW3V

11:44 <whitequark> sb0: actually, there's a missing FFSynchronizer on the input, at least

11:45 <sb0> I don't get this "latch" signal

11:46 <sb0> is that for packing the two nibbles in the byte?

11:48 <whitequark> yeah

11:49 <whitequark> you could just feed input to the FIFO at the cost of halving the bandwidth

11:50 <whitequark> ohhh

11:50 <whitequark> re: bit shift

11:50 <whitequark> this happens because pads.d_t.i[:4] has length 2 in your case

11:51 <whitequark> so try something like

11:51 <whitequark> in_fifo.din[0:4].eq(pads.d_t.i[0:4]),

11:51 <whitequark> in_fifo.din[4:8].eq(latch[0:4]),

12:00 <whitequark> sb0: https://paste.debian.net/1105351/

12:06 <sb0> whitequark: that fixes it, thanks

12:07 <whitequark> both issues?

12:07 <sb0> yes

12:15 <mtrbot-ml_> [mattermost] <jan.kiethe> jan.kiethe joined the team.

12:50 <sb0> whitequark: but it freezes after a while now

12:50 <sb0> freezes are more frequent with CPU usage, and increasing the FIFO size makes them more infrequent

12:50 <sb0> but no FIFO that would fit in the FPGA is large enough to stop them

12:50 <sb0> whitequark: and it still fails after halving the sample rate by adding wait states in the FSM

13:01 <whitequark> sb0: right. let's see

13:02 <whitequark> that's a host side problem now

13:03 <whitequark> what if you remove sys.stdout.buffer.write part?

13:04 <whitequark> and just print dots or something

22:37 <whitequark> electronic_eel: i didn't forget about the PCA review. just couldn't get much done meanwhile.

23:01 <mtrbot-ml_> [mattermost] <harryho> whitequark: I'm sorry I actually repeated the same question regarding submodules in nMigen... my fault.

23:04 <whitequark> harryho: sorry, which questions? I must have missed them

23:33 <mtrbot-ml_> [mattermost] <harryho> Just asking about why `_get_submodule()` isn't found when using `dir(module.elaborate())`, but I forgot about how nmigen handles submodules differently. So, please don't worry.

23:34 <whitequark> ah. yeah.

23:34 <whitequark> harryho: FYI, about nmigen-soc, I plan to finish nmigen 0.1 this week and immediately get working on nmigen-soc.

23:42 <mtrbot-ml_> [mattermost] <harryho> Ok thanks

23:55 <_whitenotifier> [smoltcp] whitequark closed pull request #311: raw socket truncated packets - https://git.io/JeCSO

23:55 <_whitenotifier> [m-labs/smoltcp] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeWEf

23:55 <_whitenotifier> [m-labs/smoltcp] MabezDev 0fedb1d - raw_socket: gracefully handle packet truncation errors