redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #glasgow
Eli2| has joined #glasgow
Eli2_ has quit [Ping timeout: 255 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
theorbtwo[m] has quit [Quit: Idle timeout reached: 172800s]
galibert[m] has joined #glasgow
<galibert[m]>
I'm looking for advice. I have an signal (audio serial) on two lines, one toggles at very close to 44100 2 Hz and gives sync and left/right, the other has the 0/1 bits of the data at a nominal 2.8224 MHz (441002*32) but needs to be phase-aligned with the first signal. How should I do to get the data with a fpga, eventually a glasgow? A 45.1584Mhz clock (*16) with a 16-bits counter for the phase? Something better?
<whitequark[cis]>
is that I2S?
<galibert[m]>
Doesn't i2s have a third line for a sync clock?
<whitequark[cis]>
oh i see
<galibert[m]>
it's what the saleae I borrowed tells me yamaha used for its plg expander plugin cards
<whitequark[cis]>
45.1584? why?
<galibert[m]>
16 times the nominal serial clock
<whitequark[cis]>
why 16
<galibert[m]>
because that what most serial chips seem to do, no other reason
<whitequark[cis]>
hm
<whitequark[cis]>
you probably cant get that clock with the ice40 pll anywau
<whitequark[cis]>
s/anywau/anyway/
<galibert[m]>
Oh, didn't know that. I'm more used to the cyclone v clock ranges
<galibert[m]>
8 is probably enough I'd guess
<whitequark[cis]>
feed it into icepll
<whitequark[cis]>
the issue is the precision not the range
<galibert[m]>
* I'm looking for advice. I have an signal (audio serial) on two lines, one toggles at very close to 44100*2 Hz and gives sync and left/right, the other has the 0/1 bits of the data at a nominal 2.8224 MHz (44100*2*32) but needs to be phase-aligned with the first signal. How should I do to get the data with a fpga, eventually a glasgow? A 45.1584Mhz clock (*16) with a 16-bits counter for the phase? Something better?
<joshua_>
you are trying to sample this, not generate this?
<galibert[m]>
yeah, do a bit-exact recording of an expander that does not have a binary output
<galibert[m]>
Through the expansion connector
<joshua_>
x16 oversampling is not a bad idea, and if you are oversampling that much, you could conceivably use a clock asynchronous to the input, and use edges to realign yourself
<joshua_>
the problem is long runs of 0s or 1s, so you would presumably have to come up with a fractional counter into the bit time, but that is not the end of the world
<galibert[m]>
max run length before an edge on the other line is 32
<whitequark[cis]>
you can probably just use 48M then
<galibert[m]>
they toggle the first line roughly 15% into the window fwiw according to the traces
<galibert[m]>
windows of a 1/(44100 232)s aligned with the second line edge
<galibert[m]>
s/ /\*/, s//\*/
<joshua_>
48MHz divide by 17 gets you 2823529.4 Hz, which is ~0.04% away from your target; 32 clocks would be 1.3% away from your target, so that seems safe
<galibert[m]>
Ohhhh nice, didn't think of dividing by 17
<galibert[m]>
(so now I need a glasgow :-) )
<joshua_>
the other option is to PLL up from the sync signal, assuming a PLL is available and clock routing resources are available for this, and then cross clock domains
<whitequark[cis]>
ice40 wont lock to anything below 16M
<joshua_>
rekt
<whitequark[cis]>
galibert[m]: that sounds oddly like i2s... but first i gotta check something
<joshua_>
88200Hz input is awfully low for even a good PLL, I suppose
theorbtwo[m] has joined #glasgow
<theorbtwo[m]>
Can you make a pll in gateware for that, instead of using the hard IP pll?
<galibert[m]>
what it is is not documented, yamaha may very much have used i2s
<whitequark[cis]>
that is just oversampling with extra steps
<theorbtwo[m]>
Ah.
<joshua_>
yeah, if you are going to do a NCO, just do a NCO
<whitequark[cis]>
since you have no vco ip
<joshua_>
I,I 'sparkling oversampling'
<joshua_>
(I thought I2S has a bit clock?)
<galibert[m]>
Note that it may be i2s but I didn't manage to switch the sck line on
<galibert[m]>
It's very weird though, data and side are connected to the sound chip, but what would be sck is connected to the main cpu, which is on a different xtal
<galibert[m]>
So clock reconstruction feels more reliable in any case
<whitequark[cis]>
> The word select clock changes one bit clock period before the MSB is transmitted.
<whitequark[cis]>
oh, i misremembered the offset for i2s
<whitequark[cis]>
so it's not i2s i guess
Saksham_Baba has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
ikarus[m] has quit [Quit: Idle timeout reached: 172800s]
Saksham_Baba has quit [Quit: Leaving.]
meklort_ has joined #glasgow
meklort has quit [Ping timeout: 246 seconds]
meklort_ is now known as meklort
<_whitenotifier-9>
[glasgow] whitequark opened pull request #611: Upgrade Python 3.11 and earlier readline history files to Python 3.12 and later when loaded - https://github.com/GlasgowEmbedded/glasgow/pull/611
<whitequark[cis]>
today in "complete waste of time":
<whitequark[cis]>
W: g.support.arepl: this Python distribution uses libedit instead of GNU readline, and their history file formats are not compatible
<whitequark[cis]>
W: g.support.arepl: REPL history file has been converted from the GNU readline format to the libedit format; backup saved to /home/whitequark/.glasgow-history.gnu
<whitequark[cis]>
the patch is a joy to witness too, i can recommend it if you want your day to get worse
<ari>
> assert "libedit" in readline.__doc__ # (AAAAAAAA)
<ari>
i can feel the pain of having to write that line of code ,_,
<whitequark[cis]>
this is the actual legitimate recommended by cpython devs approach
<whitequark[cis]>
i did not come up with this myself
<whitequark[cis]>
i copied it from the cpython bug tracker
<whitequark[cis]>
the patch is wrong also
<ari>
also, is the difference just the header, and separators?
<whitequark[cis]>
i think so
<ari>
this really should've been done by the python library
<whitequark[cis]>
or libedit
<_whitenotifier-9>
[glasgow] whitequark synchronize pull request #611: Upgrade Python 3.11 and earlier readline history files to Python 3.12 and later when loaded - https://github.com/GlasgowEmbedded/glasgow/pull/611
<whitequark[cis]>
check out the new diff
<whitequark[cis]>
it's worse!
<ari>
ono
<_whitenotifier-9>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-611-a599e3caa64c2e445358894fd050e16917f2ee42 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-9>
[glasgow] whitequark closed pull request #611: Upgrade Python 3.11 and earlier readline history files to Python 3.12 and later when loaded - https://github.com/GlasgowEmbedded/glasgow/pull/611
<whitequark[cis]>
update: for whatever bad reason, readline writes files in a different fucking format than it reads them??
<whitequark[cis]>
how fucking hard can it be to save a file with a list of lines
<galibert[m]>
that's.... wow
<whitequark[cis]>
incredible degree of incompetence
<galibert[m]>
indeed
<galibert[m]>
escaping issues?
<whitequark[cis]>
yes
<galibert[m]>
text is hell
<whitequark[cis]>
like... what happens is that it seems to truncate the history v2 marker while writing it
<galibert[m]>
ok, that's special
<galibert[m]>
so, I decoded the samples from the saleae export, for some reason they're shifted by three bits w.r.t the l/r edge, but heh, I get the exact same values than the contents of the sample rom, so that's cool
bvernoux has quit [Quit: Leaving]
Wanda[cis] has joined #glasgow
<Wanda[cis]>
HiStOrY_V2 what kind of fucking joke is this
<gruetzkopf>
the mentioned audio format sounds like stereo PCM from the alignment. did you see any signal toggling once per frame
<galibert[m]>
it's 32-bits per sample, 44100Hz stereo yes
<galibert[m]>
with one line with the data and the other alternating to indicate left or right
<gruetzkopf>
some codecs call this alignment (shifted one bit relative to standard I2S) PCM mode because PCM backplanes (like in H.110 ISDN backplanes in big PBXes) also use this format
<galibert[m]>
the shift between the data edges and the left/right signal edges is 3 bits in my case
<whitequark[cis]>
i'm reading 4 MB of data from the QSPI flash and counting how many bytes were wrong (actually i should probably count bits or nibbles but i don't think it'll change much)
<whitequark[cis]>
i[0] is sampling at the posedge (offset by the SB_IO capture window), i[1] is sampling at the negedge (offset by the SB_IO capture window)
<whitequark[cis]>
this has some really interesting results, like a local maximum of bit errors around 66 MHz
<whitequark[cis]>
(the incredibly janky setup with the standard glasgow flywire harness that i have seems to have a resonance peak of some kind around 66 MHz for the SCK wire)
<whitequark[cis]>
s/wire/transmission line/
<galibert[m]>
it's wrong because the transmission is out of spec or it's the flash itself that's not following?
<whitequark[cis]>
the flash is specced to >100 MHz
<whitequark[cis]>
this is entirely because the sampling happens at the wrong offset, i think
<whitequark[cis]>
the core is written assuming that the SB_IO i[0] sample has setup/hold times of 0 ns
<whitequark[cis]>
i'm not actually sure what are its setup/hold times but they're definitely not 0
<galibert[m]>
huhu
<whitequark[cis]>
after collecting this data i realized that what i've made is the world's worst eye diagram built with offset sampling
<whitequark[cis]>
i think i[1] starts to be wrong because by that time the flash sets the next bit, hence the very sharp bit
<whitequark[cis]>
and i think i[0] starts to be wrong because the input window is slowly encroaching onto the data out transition
<whitequark[cis]>
actually that doesn't make sense
<whitequark[cis]>
i guess maybe the SB_IO input is more sensitive to setup timings violation than to hold timings violation?
<galibert[m]>
I honestly have no idea :-)
<whitequark[cis]>
i think the proper way to fix this is to delay the input capture clock (or data) by the input window offset from the theoretical ideal
<whitequark[cis]>
time to shove a LUT-based IODELAY somewhere and see if it changes anything
gsuberland has quit [Remote host closed the connection]
gsuberland has joined #glasgow
<whitequark[cis]>
you know, i could conceivably implement configurable IODELAY as a native nextpnr primitive
<whitequark[cis]>
also inserting a probe completely breaks this circuit. lol
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
twix has joined #glasgow
tec has quit [Quit: bye!]
tec has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[cis]>
Attie: we could install a separate `glasgow-shebang` script that parses the rest of the command line using our argument parser and executes stuff as necessary...
<whitequark[cis]>
as i've been working more with designs that require examining timing reports, i've added a lot of quality of life stuff around viewing bitstream logs, see https://github.com/GlasgowEmbedded/glasgow/pull/614