sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
fengling has joined #m-labs
rohitksingh_work has joined #m-labs
fengling has quit [Quit: WeeChat 1.4]
rohitksingh_work has quit [Ping timeout: 260 seconds]
rohitksingh_work has joined #m-labs
cr1901_modern1 is now known as cr1901_modern
fengling has joined #m-labs
fengling has quit [Quit: WeeChat 1.4]
fengling has joined #m-labs
hozer has quit [Ping timeout: 260 seconds]
hozer has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
fengling has joined #m-labs
sb0 has quit [Ping timeout: 240 seconds]
early` has quit [Ping timeout: 240 seconds]
attie_ has quit [Ping timeout: 240 seconds]
_whitelogger has joined #m-labs
rohitksingh_work has quit [*.net *.split]
kuldeep has quit [*.net *.split]
bb-m-labs has quit [*.net *.split]
cyrozap has quit [*.net *.split]
jaeckel has quit [*.net *.split]
hobbes_ has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
gric has quit [*.net *.split]
kmehall_ has quit [*.net *.split]
[florian] has quit [*.net *.split]
stekern has quit [*.net *.split]
Neuron1k has quit [*.net *.split]
acathla has quit [*.net *.split]
balrog has quit [*.net *.split]
cr1901_modern has quit [*.net *.split]
siruf has quit [*.net *.split]
rjo has quit [*.net *.split]
larsc has quit [*.net *.split]
hozer has quit [*.net *.split]
MiW has quit [*.net *.split]
ohama has quit [*.net *.split]
mithro has quit [*.net *.split]
sandeepkr has quit [*.net *.split]
FabM has quit [*.net *.split]
felix_ has quit [*.net *.split]
tmbinc__ has quit [*.net *.split]
ysionneau has quit [*.net *.split]
kyak has quit [*.net *.split]
whitequark has quit [*.net *.split]
bentley` has quit [*.net *.split]
fengling has quit [*.net *.split]
ChanServ has quit [*.net *.split]
early has joined #m-labs
[florian] has joined #m-labs
larsc has joined #m-labs
acathla has joined #m-labs
fengling has joined #m-labs
<_florent_>
larsc, rjo: there is something I don't understand: as rjo said the right dacclk for 4lanes / 4converters / 1x interpolation / 5Gbps linerate is 250MHz
<_florent_>
by following the ad9154 datasheet I should then set in AD9154_CDR_OPERATING_MODE_REG_0:
<_florent_>
AD9154_CDR_OVERSAMP_SET(0)
<_florent_>
AD9154_ENHALFRATE_SET(0)
<_florent_>
and in AD9154_REF_CLK_DIVIDER_LDO:
<_florent_>
AD9154_SPI_CDR_OVERSAMP_SET(1)
<_florent_>
AD9154_SPI_LDO_BYPASS_FILT_SET(1)
<_florent_>
by doing that and with a 250MHz clock input I should be able to have the SERDES PLL to lock. But I have toprovide a 500MHz clock to get the SERDES PLL to lock...
<_florent_>
as if there were 4 lanes but 2 DAC channels enabled instead of 4.
<_florent_>
larsc: do you know what exact register control the divider before the SERDES PLL for the number of DAC enabled?
<_florent_>
larsc: or do you have a valid configuration for the ad9154 without using the dac pll? (just to understand)
<_florent_>
bbl
fengling has quit [Quit: WeeChat 1.4]
<sb0>
whitequark, any idea how bad the output clock of a Si5324 that has never seen an input clock is?
<whitequark>
sb0: I vaguely recall from my testing that it looked approximately right but I never did look at it in depth
<sb0>
do I have any chance of getting away with a single transceiver clock input? use the Si5324 in free running or digital hold mode to provide a reference clock for RX, then switch the Si5324 to the CDR clock and use it for both TX and RX
<sb0>
_florent_, larsc any experience doing that?
<sb0>
the main advantage is I can just use one CPLL instead of having to mess with the QPLL
sandeepkr has joined #m-labs
kuldeep has joined #m-labs
<larsc>
sb0: I'm not quite sure I follow what you want to do
<sb0>
the end goal is to get the TX syntonized to the RX (after CDR)
<sb0>
RX requires a reference clock to get anything started; what I want to do is use a single Si5324 to provide one reference clock to both RX and TX
<sb0>
initially, it will provide a reference clock based on its crystal alone, and then, after RX is locked, syntonize to the CDR clock
<sb0>
and then there will be a loop CDR -> Si5324 -> CDR, I don't know if that can work well or not
<larsc>
that would be more or less equal to just turning the reference off, no?
<sb0>
and will the "hitless" switching be hitless enough not to unlock the CDR?
<sb0>
no, the Si5324 is a lot more stable than the xilinx crap
<sb0>
and the xilinx cdr design continously uses its reference, you can't turn it off
<larsc>
In that case I'd expect that the reference needs to be phase coherent to itself
<sb0>
what does that mean?
<larsc>
phase does not change over time
<sb0>
it will always change, the question is how much change is a problem
<larsc>
and if you connect it the CDR I would expect the phase to move in response to the CDR
<sb0>
the Si5324 has very low loop bandwidth - 4 Hz
<sb0>
the CDR is supposed to be tuned by the incoming serial stream, too
<larsc>
it is still a open loop
<larsc>
I mean you can try
<larsc>
but I would expect issues
<sb0>
the low loop bandwidth would make phase changes very slow
<sb0>
so yes, it's unclear whether that works or not, and there isn't really enough information in the datasheets to answer that
<sb0>
especially in the Xilinx one which has very few CDR characteristics, "just use the magic numbers from our wizard"
<_florent_>
"You only need to use the Si5324 in free run mode with the 114.285 MHz crystal to generate the initial 155.52 MHz for the GTHs to operate, lock and generate a recovered clock from the received data. See page 73, section 6.5 of the Si53xxReferenceManual for more information on the free run mode. Once you have the GTH locked to the incoming data stream, the
<_florent_>
RXRECCLK can then be driven from the FPGA to the Si5324 using the REC_CLOCK_C_P|N pins and it will switch over and locked to the clock providing a 0 PPM offset."
<sb0>
oh, ok
<sb0>
so apparently this just works
<sb0>
nice
<larsc>
_florent_: and your divfactor is 2?
<_florent_>
larsc: just back from lunch, looking at that...
<larsc>
sorry, the factor should be 4, numerical value 2
<_florent_>
larsc: ok I think i know what is going on: it's just that 4lanes / 4converters / 1x interpolation / 5Gbps linerate is not possible with the AD9154 due to the mysterious /4 divider and black boxes:
<_florent_>
250/4=62Mhz and with a divFactor of 2 (for 5Gbps) = 31Mhz
<_florent_>
which is below the minimum 35Mhz for the SERDES PLL
<_florent_>
by settings 300Mhz at the input (37MHz at the input od the SERDES PLL) I now have the lock...
<rjo>
_florent_: but it's marginal. table 4: svdd=1.2V, f_lane_max = 4.8 or 4.9 GHz.
<sb0>
the si5324 will also switch on its own between the free-run mode and the clock input, whenever the clock input looks correct. neat.
<sb0>
after fighting xilinx plls for years, this is luxury
<_florent_>
rjo: I don't know how the black box is working, I'm just trying to guess
<_florent_>
rjo: from the behaviour I see here, for the same config but 6Gbps, I get the SERDES PLL lock for both 300MHz dacclk and 600Mhz dacclk
<_florent_>
rjo: 300Mhz dacclk is the one supposed to be correct, but I only get valid ILAS with 600MHz...
<rjo>
_florent_: which black box?
<rjo>
_florent_: the serdes pll and associated circuitry doesn't seem to be that much of a blackbox.
<rjo>
_florent_: the difference between 300 MHz and 600 MHz dacclock being 1x and 2x interpolation?
<rjo>
*the _only_ difference
<rjo>
... and the actual divider for the dacclock in the ad9516
sandeepkr has quit [Quit: Leaving]
<rjo>
how do you make 600 MHz? still fpga pll?
<_florent_>
rjo: the black box is: clk+- of the chip --> black box (divide clock according to registers settings) --> fref of SERDES PLL
<_florent_>
for the 300MHz/600MHz I'm always using 1x interpolatio
<_florent_>
ion
<_florent_>
yes I'm generating the 600Mhz from the fpga pll
sandeepkr has joined #m-labs
<rjo>
_florent_: ok. but to me fref (=pclock) is not much of a blackbox. since its definition is line_rate/40, and the only clock input is dacclock, the bacl box depends on the jesd registers and interpolation.
<_florent_>
rjo: yes that's not really a black box, but at least for now it's not doing what I'm expecting. I'm going to check all registers that can be related.
<rjo>
_florent_: you do agree with me that 600 MHz dacclock, 1x interp, 4 lanes, 4 converters, 6 GBps should not work, right? i don't think you can conclude much from the fact that it does work.
<rjo>
_florent_: you can conclude something from the fact that 300 MHz dacclock does _not_ work however.
<_florent_>
rjo: yes agree with you for 600MHz clock, that's why I'm looking to have the setup working with the expected clocks.
<_florent_>
rjo: yes for the 300MHz clock, I'm going to check all related registers...
<rjo>
_florent_: ack. just checking that we are on the same page.
<_florent_>
rjo: yes we are :)
<rjo>
_florent_: maybe the qpll is just ticking too fast. does vivado infer the line rate/fabric clock etc automatically from the qpll params?
<_florent_>
rjo: I've checked the linerate with an oscilloscope
<sb0>
btw is my 8b10b core passing timing at 10Gbps?
<rjo>
sb0: at 250 Mhz i am pretty sure it is just fine. but i haven't tested it yet.
<rjo>
sb0: _florent_ has though.
<_florent_>
sb0: I did one test, IIRC it was fine.
<rjo>
_florent_: for 6 GBps you have to enable half rate.
<rjo>
_florent_: and disable AD9154_SPI_CDR_OVERSAMP
<_florent_>
rjo: found my error....
<rjo>
_florent_: i think there are two. but cross-check.
<rjo>
_florent_: AD9154_ENHALFRATE and AD9154_SPI_CDR_OVERSAMP
<_florent_>
rjo: that was a typo on AD9154_ILS_S.
<rjo>
_florent_: i am pretty sure that AD9154_CDR_OVERSAMP and AD9154_SPI_CDR_OVERSAMP need to match. even though the working ranges are not that consistent.
<rjo>
_florent_: ah nice.
<_florent_>
rjo: now it's fine, but I'm going to test in halfrate mode
<_florent_>
rjo: here I have SYNC_TRIP and SYNC_LOCK set to 0
<_florent_>
sorry to 1
<rjo>
_florent_: strictly speaking, 5 GBps is impossible for the FMC-EBZ (table 4).
<_florent_>
rjo: because we have SVDD12 = 1.2 V?
<rjo>
_florent_: but let's say 1.2 \sim 1.3 and then we'd do CDR full rate, table 29: Halfrate=0, OvSamp=0, PLLDiv=1 (div-by-two afaict), table 37: DivFactor=2, SPI_CDR_OVERSAMP=1, table 38: HALFRATE=0, CDR_OVERSAMP=0,
<rjo>
_florent_: yes
<_florent_>
ok
<rjo>
_florent_: then i think your settings are correct (apart from 5 GBps being illegal).
<_florent_>
rjo: ok thanks.
<rjo>
ah. SPI_CDR_OVERSAMP is the same as PLLDiv (indexed). it says so.
<rjo>
that one is precisely the 1/2/4 divider, and also the same as DivFactor AFAICT.