00:52 <d1b2> <Attie> current I2S status - the first few hundred samples are good, but then it goes wonky...

00:52 <d1b2> <Attie> https://cdn.discordapp.com/attachments/613461005392936961/762114820761452574/unknown.png

10:12 <whitequark> attie: there is no way to reset the whole FPGA; there isn't a reset line

10:13 <whitequark> electronic_eel is correct that resetting individual applets is the way to go, and you can already do that

10:13 <whitequark> (every applet gets a reset register)

10:13 <whitequark> however, each time you run an applet, it already gets reset first

11:49 <d1b2> <Attie> @whitequark interesting, thanks... in this situation the applet doesn't appear to get reset - e.g: each time i run glasgow run audio-i2s-capture, the first states of the FSM appear to be "already done"

11:49 <d1b2> <Attie> (I was toying with autodetect for sample size and rate, but have put that to one side for now)

11:49 <d1b2> <Attie> my current issue seems to be keeping up with the FIFO, and not loosing data (see above)

11:51 <d1b2> <Attie> even in a very tight white True: await iface.read() loop, there are a couple of hiccups, where in_fifo.w_rdy isn't set for a period

11:51 <d1b2> <Attie> even in a very tight white True: await iface.read() loop, there are a couple of hiccups, where in_fifo.w_rdy isn't set for a period

11:52 <d1b2> <Attie> it's only 44.1kHz, 16-bit, stereo at the moment (~172.3 kiB/s)

12:20 <_whitenotifier-f> [glasgow] brainstorm commented on issue #151: False positive results in selftest - https://git.io/JU5xM

18:40 <_whitenotifier-f> [glasgow] whitequark commented on issue #151: False positive results in selftest - https://git.io/JUdaA

18:40 <whitequark> attie: it is unlikely that the applet doesn't get reset, it is more likely that there is a coding error in your implementation

20:18 <d1b2> <Attie> @whitequark hm, okay... FSM should be reset too? I'll do some more poking at it to see if I can get a feel for what's going on

20:19 <d1b2> <Attie> but from what I've seen so far, when it builds and loads the bitstream, i see the initial states used

20:19 <d1b2> <Attie> but then subsequently (when the bitstream doesn't need to be rebuilt), those states are "missed" - my hypothesis being that there wasn't a reset occuring

20:22 <whitequark> yes FSMs should be reset

20:41 <d1b2> <Attie> ok, thanks

21:30 <whitequark> if they weren't, nearly every applet in the tree today would be broken

21:31 <whitequark> this was actually something I had to fix early on, it wasn't trivial, and it's absolutely foundational to the whole applet system

21:36 <d1b2> <Attie> yeah - i had expected it to be taken care of for exactly this sort of reason

21:37 <whitequark> can you show your code? i have a few minutes i can use to look at it

21:37 <d1b2> <Attie> oh that would be kind, thanks

21:38 <d1b2> <Attie> https://github.com/attie/glasgow/commit/f4cc32f9d9ed4ee4f54d0cc577168791d573b798

21:39 <d1b2> <Attie> it's a bit grubby, because I'm figuring a lot out

21:40 <d1b2> <Attie> actually... that's without the extra / init states i was having problems with above, but the style stands

21:43 <whitequark> lemme see

21:43 <whitequark> ah

21:43 <whitequark> yeah, i see the problem immediately

21:44 <d1b2> <Attie> i suspected you might

21:44 <whitequark> you need to do `iface.add_subtarget(BlahSubtarget(...))`, since that is the function that actually adds the reset logic

21:44 <d1b2> <Attie> ahh, okay

21:46 <d1b2> <Attie> like this?

21:46 <d1b2> <Attie> https://gist.github.com/attie/3241b0ca5f14177559411298283c3899

21:47 <d1b2> <Attie> it builds and seems to do stuff, so that's a good start 🙂

22:01 <whitequark> yeah

22:02 <d1b2> <Attie> great, thanks

22:02 <d1b2> <Attie> now I need to figure out the FIFO side of things...

22:03 <d1b2> <Attie> I can't quite figure out if the system will bring as much data into the host as possible (assuming i'm a friendly asyncio worker and yield occasionally), or if i should be looking to do that in the I2S applet

22:03 <d1b2> <Attie> i also feel like I want a non-blocking in_fifo.read(), but I'm happy to be steered otherwise

22:05 <d1b2> <Attie> I'm currently working with this - https://gist.github.com/attie/3241b0ca5f14177559411298283c3899#file-non_block_fifo_read-py

22:05 <d1b2> <Attie> but it uses lots of internals, and feels very wrong

22:06 <d1b2> <Attie> (overheads in the memory copy being a small part)

22:20 <d1b2> <Attie> ... thinking about it, a separate asyncio task would make a lot more sense

23:56 <d1b2> <Attie> I2S audio captured with glasgow... when it misses samples, it misses a chunk (89Hz and 137Hz)

23:56 <d1b2> <Attie> https://cdn.discordapp.com/attachments/613461005392936961/762463251853869066/unknown.png

23:58 <ebb> Second trace looks like BPSK :P

23:59 <d1b2> <Attie> that's a stereo capture, so the traces are related in time - primes frequencies to help identify the missing timespan