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
<Degi>
The PLL is terrible, look at its output with an SDR or spectrum analyzer. If you have a second unused DCU maybe you could use that as a good PLL
<Degi>
(I think last I looked it had like 10 MHz bandwidth at a few 100 MHz. Otherwise set the trigger position of the oscilloscope far away, that also works to determine jitter / frequency deviation %)
<Peanut>
There's some settings still to explore in terms of PLL bandwidth and gain, perhaps that may help?
<Peanut>
Also: didn't know you could use the DCU as a PLL.
<Degi>
Well, it doesn't have as many ratios as the EHXPLLL but you can get quite a few ratios out of it between reference and TX clocks
<Degi>
Peanut: The SERDES also has some undocumented PLL settings, maybe they can be used to make it work with worse clocks
<Degi>
Huh, the LatticeSCM chips seem interesting, I wonder why they got discontinued.
<Degi>
Hmm, for the EHXPLLL there are 4 parameters which seem interesting in relation to output noise, maybe we could iterate through them with a spectrum analyzer and see which combination yields the lowest width
<Degi>
I think at the top it even shows which bits it sets
<Degi>
Hmm, I wonder if you can directly write to the FxBy parameters lol
<Degi>
I think the open source toolchain doesn't do such things (besides when routing wires and for textual parameters). Like lattice diamond has some soft blocks which you can replicate with some gateware in the open source toolchain
<agg>
Degi: 10MHz sounds _awful_! how were you measuring it?
<agg>
i'm trying to work out if any of my ecp5s have easy clock outputs but i think the closest is a 22r series terminated smb which would probably not enjoy driving a 50R input
<agg>
should be ok into a scope though, but dunno if my scope's clock is stable enough for meaningful phase noise measurements
<Degi>
Hmm, I think I stuck its output onto an SDR. Maybe I was misremembering it, but it was > 2 MHz. Other sources (I think the SERDES PLL) were a narrow line.
<Degi>
I mean impedance matching isn't really important here though, like you have a large signal and much phase noise, so even 90+ % reflected power is probably fine. I think I just connected the SDR to some pin of the ECP5
<Degi>
(Maybe put a 1 kOhm series resistor, or a DC blocking cap and 1.5 V VCCIO, then the current is only 15 mA AC)
<Degi>
Or limit the drive strength to 4 mA
<agg>
oh, yea, I have a series DC block actually, good call
<agg>
I had just finished setting up PCB SMB -> SMB coax -> SMB-SMA adapter -> SMA-BNC adapter -> BNC-scope-probe-tip adapter -> 1:10 probe -> BNC to SMA adapter -> SMA to N adapter -> spectrum analyser
<agg>
but your idea is much better
<Degi>
Which board is this?
<agg>
just some custom work thing I have lying around that happens to have an SMB hooked up to a gpio pin for debug
<Degi>
I'd just solder an SMA connector to a header and plug that into the board and maybe add a capacitor onto the header. And set IO drive strength to 4 mA, especially since SDRs usually are pretty sensitive.
<agg>
ecp5um 85f bg381, but the serdes isn't powered or connected
<Degi>
Hmm, and enable the attenuator if your spectrum analyzer has one
tokomak has quit [Ping timeout: 240 seconds]
emeb_mac has joined ##openfpga
Raito_Bezarius has quit [Ping timeout: 252 seconds]
<Peanut>
Definitely using an attenuator before connecting anything to my SDR, yes.
Raito_Bezarius has joined ##openfpga
<Peanut>
s/harcore/erg frustrerend/ :-)
<Peanut>
Ehh.. wrong window *lol*
<jn>
sounds dutch
<Peanut>
It is, with a typo in the English part even.
fibmod has quit [Remote host closed the connection]
specing has quit [Ping timeout: 240 seconds]
specing_ has joined ##openfpga
specing_ is now known as specing
<agg>
Degi: hmm, so ddr output clocked by sync, first with sync directly from 20MHz tcxo input, second with sync from 40MHz PLL (ICP current 12mA, LPF resistor 8, mfg_enable_filteropamp=1, mfg_gmcref_sel=2, clki_div=1, clkop_div=15, clkfb_div=2)
<agg>
so the close-in noise is pretty much identical but spurs on the pll out to about +-1MHz of centre
<Degi>
What is 1 unit of ICP current?
<Peanut>
I wonder what the little dip around the carrier is?
<agg>
not sure what the current is but maybe mA
<Degi>
Huh, that looks much better than what I got.
<Degi>
Do you have the open source toolchain? Can you try without any of the options which make it better?
<agg>
this is with yosys+nextpnr
<Degi>
I see, nice
<Peanut>
This is with the VCO at 600 MHz?
<agg>
yes
<agg>
since clkout divider is 15 and f_out is 40M
<Degi>
Btw you can get some of the PLLs in the 5G devices over 1 GHz (I think 1.5 or so)
<Peanut>
That's a lot, I try and keep them between 400-800 MHz (as per the datasheet).
<Degi>
Me too, but recently I needed a faster clock and didn't want to set up the other FPGAs SERDES (though with that you can clock the fabric at over 2 GHz, though only some pins work as inputs and it depends on a bit of luck whether it works)
<Degi>
(At least the hardware clock dividers work at that frequency if I remember correctly)
<Peanut>
agg: what is 'clocked by sync' ?
<Degi>
I assume ClockSignal("sync") so the default clock of the FPGA board
<Peanut>
That sounds like Migen/NMigen/Amaranth?
<agg>
sorry yes I forgot this isn't #amaranth
<Degi>
right
<agg>
I just mean the oclk of the ddr is driven by either the input tcxo clock or by the pll clock output
<Peanut>
Ok, with you again.
<agg>
the tcxo feeds a pll input pin, which isn't a pclk input
<Degi>
Hmm, why not directly put it onto a pin but use a DDR?
<agg>
but should be the best case for the pll
<agg>
hm
<agg>
no reason I guess, I'm just used to using ddr to output clocks for data
<Degi>
Hmm, can you try with 200 MHz PLL output?
<Degi>
(I wonder if an oscilloscope would be suitable for this too, it has low dynamic range but a large enough FFT might be able to extract some data)
<Peanut>
My oscilloscope has phosphor and vacuum.
<agg>
can capture on the scope and see, it's 5GS/s and hooks into glscopeclient for FFTs
<agg>
hard to say what will do better at phase noise measurement. I'm sure the noise floor we see on those traces is from the specan, not from the tcxo
<Degi>
I mean I don't have a spectrum analyzer besides an SDR (with extremely non-flat transmit path), but the oscilloscope has 200 MSamples heh
<agg>
what pll settings do you want for 200MHz?
<Degi>
I think clkop_div=3 and clkfb_div=2, maybe one at minimum and maximum ICP, not sure about LPF resistor, one at minimum and maximum resistance would be nice but I don't know where that resistor is or what the bits mean (whether its a bunch of parallel resistors to ground or something else)
<agg>
ugh, it's getting late and takes like a minute or two to capture each trace, this demands automation
<agg>
python script to generate bitstream with each parameter set, upload, trigger spacan, capture screenshot, tag with parameters
sgstair_ has joined ##openfpga
<agg>
then discover next morning it needed a 10MHz span or something
<Peanut>
And then for all combinations of resistor, charge pump current, capacitance etc.. ouch.
<agg>
yea but if i can leave that overnight by itself it can work it out
<agg>
I guess the question is what parts you leave fixed... the output freq?
<Peanut>
I would guess that the input frequency to the PLL matters - the VCO itself only covers an octave (if you keep to the datasheet).
sgstair has quit [Ping timeout: 240 seconds]
<agg>
the freq after the refclk divider?
<Peanut>
Yes, the frequency that goes into the phase detector. That's one of the frequencies that you want to supress in the output.
<agg>
the 10-400MHz f_PFD in the datasheet?
mewt has quit [Ping timeout: 240 seconds]
<Peanut>
*nods* that's a huge range - I think maybe better to wait with that until after we understand how the loop filter works, and then see how it supresses low input frequencies. The docs state that if you go below 10 MHz there, you'll get worse jitter.
mewt has joined ##openfpga
<agg>
yea
<agg>
i really want to write this little automation now, it seems fun
<agg>
I don't have any hardware where I can feed a variable clock in, anyway, though
<agg>
so the 20MHz TCXO is all I got, but at least it's a tcxo I guess
<Degi>
Nice! Otherwise I would've done that tomorrow (not much time today), theoretically I guess I can feed a variable clock generated by a SERDES of another ECP5 or from a dedicated PLL IC (though only to 300 or so MHz), but my spectrum analyzer is limited to SDR or MSO5000 (slow, at least for 200 MSamples it takes a few minutes, most of it for data transfer)
<Degi>
Which parameters do we want to iterate over anyways? ICP_CURRENT + KVCO + LPF_CAPACITOR + LPF_RESISTOR + MFG_ENABLE_FILTEROPAMP is 18 bits, so 262 k configuration space
<Degi>
(Maybe for faster iteration, instead of full compilation each time we could just alter the relevant bits in the bitstream)
<Degi>
(Otherwise we could iterate over each setting by itself to see how they change the signal)