kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
jjeanthom has quit [Ping timeout: 256 seconds]
show1 has quit [Ping timeout: 260 seconds]
show1 has joined ##openfpga
mumptai has quit [Remote host closed the connection]
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
<mwk>
so... I'm looking at the Zynq QSPI controller in PS, and wondering htw it is supposed to work
<mwk>
am I missing something, or is the design really this comically insane
<mwk>
the strangest feature it has that I still don't understand is the "clock feedback" bit
<mwk>
so apparently it can do 40MHz without any extra steps, but you can use it up to 100MHz or so if you connect a "feedback clock"
<mwk>
which... is just a MIO pin that you have to pinky promise you won't connect to any driver or input buffer aside from maybe a pullup, and let it toggle freely
<mwk>
and apparently it indeed emits a copy of the clock signal on it while working
<mwk>
any ideas on what that is about? how does having an unconnected IO pin help with timing?
<sorear>
it sounds like they're using the pin as a capacitor? which still doesn't make sense because they have a clock distribution network that can do 100MHz easily
<mwk>
it kind of sounds like they're using it for a delay
<mwk>
which... honestly doesn't make a whole lot of sense either
<sorear>
having trouble downloading ug585 today
<whitequark>
verilog format specifiers are kinda batshit
<sorear>
so it seems to cut off after a random number of bytes, and sending accept-bytes doesn't push that forward
<whitequark>
like there's separate knobs for "fill in zeroes from the highest nonzero bit to width of argument" and "fill in spaces from whatever was the last character to the field width"
<implr>
which terrible vendor did they get that ip from
<mwk>
Cadence
<implr>
the ps uart easily does 100mhz clock (!= bitrate, obviously)
<implr>
it's the default even
<mwk>
except that they then sholveled lots of shit into it
<mwk>
including the feedback bit
<mwk>
oh, nah, they can actually do 100MHz on the pin
<implr>
otoh wait
<mwk>
I don't mean the ref clock
* implr
brb vivado
<implr>
ah yeah i'm dumb
<implr>
also looking at vivado made me aware of this thing supporting 'dual quad spi'
<implr>
marvelous
<whitequark>
uhhhhh
<mwk>
oh right, that
<mwk>
I mean, that one is actually kinda reasonable
<mwk>
widen your serial bus by stuffing moar chips in parallel
<mwk>
well for some value of "serial"
<mwk>
I mean, everything is serial if it has one transaction after another, right?
<mwk>
*points at AXI* it has bursts, this is a serial port
<sorear>
when you exist in a single timeline with events in a linearizable partial order
emeb_mac has quit [Quit: Leaving.]
lexano has quit [Ping timeout: 260 seconds]
lexano has joined ##openfpga
Bob_Dole has quit [Ping timeout: 264 seconds]
Bob_Dole has joined ##openfpga
jjeanthom has joined ##openfpga
<TD-Linux>
spi is just boneless parallel
mumptai has joined ##openfpga
<lain>
X3
jjeanthom has quit [Ping timeout: 240 seconds]
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
kristianpaul has quit [Ping timeout: 240 seconds]
kristianpaul has joined ##openfpga
jjeanthom has joined ##openfpga
jjeanthom has quit [Ping timeout: 264 seconds]
sorki has joined ##openfpga
sorki has quit [Remote host closed the connection]
sorki has joined ##openfpga
sorki has quit [Remote host closed the connection]
sorki has joined ##openfpga
<agg>
azonenberg: with jitter analysis in glscopeclient, am I right in assuming the noise floor is limited by the scope's frequency reference? so for a scope without a ref in and with a standard internal tcxo or whatever, you probably wouldn't be able to do any jitter analysis of a low-jitter source?
<agg>
(just watched your new video, very keen to gain some jitter analysis on my scope that otherwise can't do such a thing from the manufacturer)
<azonenberg>
agg: I'm still working on improving the capabilities. Most higher end scopes use OCXOs
<azonenberg>
and have ref inputs
<azonenberg>
if it's too low end to have a ref in, it's probably using a tcxo
<azonenberg>
I think i can definitely improve the noise floor of my jitter spectra by subtracting Rj somehow. My LeCroy scope can do that, but i don't quite understand how
<agg>
yea, this is a keysight msox3000 series, sadly no ref in
<agg>
annoying since the 4000 has a ref in and it seems like 3000 shouldn't be 'low end' but in this respect it is a bit limited
<azonenberg>
or sorry, separating the Rj + BUj
<azonenberg>
so you don't get the DDJ in the spectrum
<azonenberg>
I'm still learning about jitter decomposition. so far all of the plots i have are Tj only
<azonenberg>
And they're based on TIE only and assume an arbitrary non-repeating data pattern. there are some nicer jitter analysis techniques you can use if you have a signal with a repeating pattern like a PRBS-7
<agg>
any thoughts on adding jitter analysis for clocks, rather than data streams?
<azonenberg>
It should work the same way. lock a reference pll to it
<azonenberg>
then extract TIE
<azonenberg>
and do the other analysis off that
Degi has quit [Ping timeout: 240 seconds]
<azonenberg>
the bigger thing i need to fix is that my reference PLL itself is rather hacky
<azonenberg>
and i really need to implement a standard reference pll
<agg>
makes sense
<azonenberg>
I suspect the noise floor on my jitter spectrum would go down a fair bit if i had a better pll
<azonenberg>
i'm using a simple bang-bang control loop right now
<azonenberg>
which locks on well, but i suspect has less than ideal jitter
<agg>
yep. i have recently implemented a bad bang-bang cdr in fpga logic and i wanted to know how awful its jitter was :p
<azonenberg>
Lol. well mine is done in post and is fairly low, but i think i can get lower
<azonenberg>
the big thing is i don't have the control theory background to understand how to actually implement the reference PLLs in these standards
<agg>
how are they specified?
<azonenberg>
Good question. Finding the specs is not super easy
<azonenberg>
in the case of the fibre channel golden pll, which is good for fixed frequency (not spread spectrum) data
<azonenberg>
it's a "single pole LP FIR"with cutoff frequency at 1/1667 of the data rate
<azonenberg>
but that sounds like a lowpass filter spec
<azonenberg>
i dont see how this maps to a control loop
Degi has joined ##openfpga
_whitelogger has joined ##openfpga
sorki has quit [Remote host closed the connection]