azonenberg changed the topic of ##openfpga to: Open source tools for FPGAs, CPLDs, etc. Silicon RE, bitfile RE, synthesis, place-and-route, and JTAG are all on topic. Channel logs: https://libera.irclog.whitequark.org/~h~openfpga
sgstair_ is now known as sgstair
<agg>
also, what do we want to measure? I don't think the specan is meaningfully measuring pll jitter or phase noise
<Degi>
Hmm, the width of the peak in the middle, maximum height of sidebands and maximum height of noise floor (not sure how to do the last)
Degi has quit [Ping timeout: 256 seconds]
Degi has joined ##openfpga
<Degi>
Whoops internet was gone
<Degi>
Hmm, we could also measure something with the SERDES
<Degi>
Hmm nice. I might add some improvements later, for example we could do a scan with +- 10 kHz around the center frequency and use scipy fitting to do a gaussian fit of the peak
<Degi>
(or directly measure the FWHM)
<Degi>
(I think np.sum(spectrum > np.max(spectrum) / 2) * x_unit should do that if the spectrum is in a linear scale)
specing has quit [Ping timeout: 256 seconds]
specing has joined ##openfpga
<agg>
the peak doesn't really have a width beyond the rbw of the specan
<Degi>
Hmm
<Degi>
I can measure jitter later today with my oscilloscope
<Degi>
(By measuring phase noise at some time away from the trigger zero position, like record some waveforms at 1 ms delay and 100 MHz, then a 1 ns shift equals 1 ppm frequency shift if I did my calculation correctly. Then record multiple waveforms and measure the sigma of the shift distribution or something like that)
<agg>
I'm not sure what exactly that would tell you, the cycle to cycle jitter won't be magnified by the delay (since it's zero mean), but I guess you'll see slower variation in output frequency... so long as it's not mostly measuring your scope's frequency accuracy and stability instead
<agg>
I wonder if at 100MHz I can just measure the periods directly? I have some scripts for doing that too
<agg>
since the ecp5 datasheet gives numbers for output clock period jitter and cycle-to-cycle jitter as ps pk-pk >=100MHz...
<agg>
I'll give that a try later tonight and see how the numbers compare to the datasheet, I think normally it's pretty tough with a high quality oscillator but maybe the PLL will be bad enough to measure, I have 20ps time resolution and it specs 100/200ps max peak-peak
<agg>
ideally you'd supress the carrier and measure the power spectrum at offsets to get phase noise spectrum, or even better use an actual phase noise analyser, then compute the pp jitter statistics from the phase noise spectrum
<agg>
but the close-in phase noise is below the phase noise of my specan it looks like
tokomak has quit [Ping timeout: 240 seconds]
<agg>
hm, it looks like the spectrum analyser should be something like 23ps rms phase, 40ps rms period, 70ps rms cycle-to-cycle jitter, vs 200, 100, 200 ps peak-peak on the PLL, so maybe it can at least see if it's below the max spec and make some comparisions between settings
Abhishek_ has quit [Quit: Connection closed for inactivity]
<Degi>
Hmm right, maybe I could just measure instantaneous frequency. The thing I proposed was basically the integral of that
<agg>
Scope probably not enough frequency resolution for this, unless it's wicked high sample rate, but maybe it can do a good job interpolating between samples to work out timing?
<agg>
Maybe glscopeclient has some tooling for this
<Degi>
Hmm I just wanted to least squares fit a sinewave
<Degi>
Lets see
<Degi>
Hmm, if I use the oscilloscopes function generator at 10 MHz sine, then my program gets me 9999824±24 Hz
<Degi>
Well, with 16 samples, so that deviation has a deviation
<Peanut>
*waves* good evening everyone
<Peanut>
*w00t* I've got RGMII working with DDR clocks, I'm seeing actual packets.
<Peanut>
Now I'm wondering why the 125 MHz clock is good enough for RGMII, but not good enough for the SERDES/DCU.
emeb_mac has joined ##openfpga
<Degi>
Cool
<Degi>
Yeah the DCU needs a goood clock apparently
egg|cell|egg has joined ##openfpga
<agg>
Peanut: nice! Did you use the pll to generate the phase shift in the end then?
<agg>
How are you handling the rxclk?
<Degi>
Peanut: Can you post your SERDES configuration?
<Peanut>
Yes, I'm using the PLL to generate the DDR clock and its quadrature version.
<Peanut>
Regarding the SERDES config - happy to share it, but it needs a bit of cleaning up.
<Peanut>
agg: frankly, I'm not hanlding the rxclock at all yet (for the RGMII), it's just sending out 10 packets per second.
<agg>
Hehe, that's definitely the easiest way to handle it
<Peanut>
Actually my first Ethernet interface I did make RX first - because that way you can actually see the checksums etc. as they are on the wire. That was on a Spartan-3 board, and I made it display the packets in hex on its VGA port.
<Peanut>
Especially the documentation about the CRC32 and how its bits go into an Ethernet packet is a bit obtuse, so it's great to have an actual example.
<Degi>
Huh, least squares fitting works surprisingly bad if you have many cycles and search start frequency is more than twice apart from the atual frequency
<Degi>
*actual
<Degi>
Hmm, when I feed it through the PLL the uhh about 10 cycle jitter becomes about 5 times worse, from 3.5 kHz to 24 kHz at 100 MHz clock, PLl compared to sync clock
<Degi>
Hmh, I'm measuring about 2.4 ps jitter currently, maybe I should only sample one wave though