<ablu[m]>
Is a file with the labels of the aluminium case available somewhere? Got some spare area on a UV DTF print I am sending off and would like to make a sticker of it.
<whitequark[cis]>
the case is not open source
<ablu[m]>
ACK. Thanks! I will build a crappy version of the labeling then :)
be65da6e451238ff has quit [Quit: Client closed]
be65da6e451238ff has joined #glasgow
<be65da6e451238ff>
I'm feeling a bit stumped here. I've been trying to make an applet that will essentially read some data in sync with an input clock signal and send it out. This code [ https://paste.debian.net/1365521/ ] _kinda_ works, but I see two bugs I don't really understand -- (1) sometimes the very first byte is wrong and (2) it seems to always be 2 bytes
<be65da6e451238ff>
short. Anyone have a sec to take a look?
<be65da6e451238ff>
Oh hm I think I understand why it's two bytes short
<be65da6e451238ff>
The flip flops in the FIFO probably oops
<whitequark[cis]>
I haven't read it closely but if you want to clock stuff into the FIFO from another domain you must do it using an AsyncFIFO
<whitequark[cis]>
there are some examples in the Ethernet applet, and I think there's code to instantiate an applet that lives entirely in a different clock domain
<whitequark[cis]>
good luck, this is one of the least well tested parts of the framework
<be65da6e451238ff>
If I do `iface.get_in_fifo(clock_domain=...)` that's going to give me an `AsyncFIFO` right?
<be65da6e451238ff>
I think so at least
<whitequark[cis]>
yeah it should
<whitequark[cis]>
back when we were still using Migen, one of Migen's deficiencies meant that resets don't work properly
<whitequark[cis]>
we have since migrated to Amaranth and tried to fix the resets, but they still don't work properly
<be65da6e451238ff>
I think I understand what I'm doing wrong for (2) there, not too sure about one still but I wonder if it's related
<whitequark[cis]>
(2) seems related, you probably just somehow assert the flag for effectively 2 cycles and not 1
<be65da6e451238ff>
I'm testing this with an SPI signal so the input clock turns on and off -- I guess when the input clock turns off there is no more clock driving the FIFO so it just hangs out in limbo until the clock starts again
<be65da6e451238ff>
which tracks with me finding those missing two bytes at the start of every message heh
<be65da6e451238ff>
I'm slightly out of my element with this code so I'm fumbling a bit, but a lot of the APIs seem pretty intuitive so that's nice
<be65da6e451238ff>
this is a cool device :D
<whitequark[cis]>
thank you :3
<whitequark[cis]>
yeah, I would just use oversampling
<be65da6e451238ff>
Sadly I need to read a 33MHz signal and don't think I can sample fast enough to get that
<whitequark[cis]>
oh I see
<whitequark[cis]>
yeah, this is actually a difficult problem
<whitequark[cis]>
one day I want to have a high quality QSPI snoop applet but we're not there yet... hold on
<whitequark[cis]>
33 MHz? is this eSPI by any chance?
<be65da6e451238ff>
LPC
<be65da6e451238ff>
oh
<be65da6e451238ff>
are those the same thing?
<whitequark[cis]>
fun fact
<whitequark[cis]>
I have a prototype LPC applet
<be65da6e451238ff>
oooh
<whitequark[cis]>
and it, specifically, was a major motivating factor in improving Amaranth to handle async FIFOs better
<whitequark[cis]>
... and I never finished it ;w;
<whitequark[cis]>
we did end up with a better language though
<be65da6e451238ff>
uh oh :)
<whitequark[cis]>
quite literally I added AsyncFIFO support to handle the LPC use case
<be65da6e451238ff>
haha
<whitequark[cis]>
(eSPI is the successor, I wasn't sure if they have the same frequency or not; LPC is old but 33 MHz is pretty specific so I assumed it might be something related)
<whitequark[cis]>
(eSPI is a lot better actually, it has nothing to do with SPI though)
<be65da6e451238ff>
Yea this is specifically to show that a TPM appears to be being used wrong, but I have nothing that can actually read the data than I'm pretty sure is there so I bought this hoping I could get it done in time
<be65da6e451238ff>
My logic analyzer was too slow :(
<whitequark[cis]>
yeah same
<be65da6e451238ff>
If I throw that signal at the applet I just made should I be expecting it to not work then? I just need to grab a fairly short transaction
<be65da6e451238ff>
currently works "well enough" for my 1MHz SPI testing.. but that's a bit slower
<be65da6e451238ff>
thanks for the help; I'm gonna run for the day
<whitequark[cis]>
I think this is doable and I might look into it but zero promises