hakzsam24 has quit [Remote host closed the connection]
futarisIRCcloud has joined #m-labs
mauz555 has quit [Ping timeout: 252 seconds]
up2late has joined #m-labs
up2late has quit [Remote host closed the connection]
drebs14 has joined #m-labs
drebs14 has quit [Remote host closed the connection]
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
mauz555 has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
mitch_23 has joined #m-labs
mitch_23 has quit [Remote host closed the connection]
hartytp has joined #m-labs
<hartytp>
sb0: I think there must be a dodgy connection on this board, because after putting it away and then getting it out again it seems to work fine
<hartytp>
no odd JESD errors or PLL lock ups
<hartytp>
sigh
<hartytp>
sb0: testing something out for changing the linerate. I want to run the FPGA reference clock at 300MHz and then divide by two in the IBUF, to still put the rtio clock at 150MHz
<sb0>
hartytp: yes, you did not change the linerate
<sb0>
hartytp: l.20 of that patch
<hartytp>
in that patch, I wasn't trying to.
<hartytp>
was just trying to use a 300MHz reference from the FPGA
<hartytp>
which is a prerequisite to changing the linerate
<sb0>
hartytp: but then it'll try to get back the original linerate with that refclk, which may or may not work
<hartytp>
why wouldn't it work?
<hartytp>
(hint: it doesn't)
<sb0>
because GTH transceivers only support certain ratios
<hartytp>
right
<hartytp>
but one nice thing about _florent_'s core is that it checks that
<hartytp>
I looked through his code and through the Xiling UGs and AFIACT his code does not allow the user to set any PLL ratios that aren't supported.
<hartytp>
although it's very possible that there is some extra constraint that he didn't enforce that I also missed
<sb0>
hartytp: in any cases, those things can only do 20x or 40x the fabric frequency on the line
<sb0>
hartytp: you can set other PLL settings and different clocks but then it'll not work
<hartytp>
okay
<hartytp>
do you have a reference for that?
<larsc>
if you use the ref clock for the fpga device clock and want det lat the only supported ratio is 40
<sb0>
larsc: why?
<larsc>
if you have a divider in the fpga you'll introduce uncertainty because you can't control the phase of the divider
<sb0>
you get a bigger divider with 40 than with 20
<larsc>
yes, put the phase ambiguity will be to other external signals that have a even larger divider like sysref
<larsc>
if all the dividers are in the clock chip you can make sure they are all aligned
<sb0>
also they can align the output of the divider
<sb0>
oh, you are talking about the external clock chip dividers
<sb0>
right
<sb0>
I thought you were talking about something intrinsic to the transceiver
<sb0>
but yes, that IBUFDS_GTE3 contains an unsynced divider
<larsc>
if you use it
<larsc>
which you do when you go to 300MHz refclk
<larsc>
btw. fyi I'm leaving ADI at the end of October, no more insider knowledge ;)
<hartytp>
sb0: right, I see what you're saying.
<hartytp>
but, going back to that patch, I'm not changing the line rate or the fabric frequency
<hartytp>
just the reference clock, and hence the pll settings
<sb0>
hartytp: what are you trying to do?
<hartytp>
go to a different line rate eventually, but that will requrie changing the GTH PLL settings and using the IBUF divider, so I want to check that I can get that to work without changing the linerate first
<sb0>
hartytp: what linerate? 12G?
<hartytp>
yes
<hartytp>
sorry, 10G
<hartytp>
1GBPS
<sb0>
hartytp: actually the GTH can do 80x
<hartytp>
yes, but the core currently hard codes 40x afaict
<sb0>
so you can keep everything the FPGA sees at 150MHz and "simply" change the GTH settings
<sb0>
hartytp: well you only have two options: clock the FPGA at 300MHz, which will fail timing, or implement 80x in the fabric (2x + 40x) or in the transceiver
<sb0>
hartytp: both options require changing that code
<hartytp>
sure
<sb0>
well, not the one you linked to, but in various parts of artiq
<hartytp>
but, first, i was surprised that using a 300MHz reference clock but keeping the line rate at 6GBPs and adding the divider didn't work
<hartytp>
that doesn't change either the fabric freq or the line rate, so should be a pretty simple change
<sb0>
also, you probably want to review every single GTH parameter when going to 12G. yes, there are 600 of them. this is one reason I hate those things so much.
<sb0>
hartytp: in addition to the nondeterminism that larsc pointed, iirc that only divides the fabric output, not the transceiver output
juvenal1 has joined #m-labs
<hartytp>
sb0: right but for now I'm not worried about the non-determinism
<hartytp>
and, I didn't want to change the transceiver output
<hartytp>
(that's the whole point)
<hartytp>
the PLL settings should give the correct TX clock for the given linerate even with the 300MHz ref clk, shouldn't they
<hartytp>
yes, _florent_ did a good job of documenting that and adding assertions to ensure that the code won't build with invalid PLL divider settings
<hartytp>
which is why I figured that the patch I posted above would work -- just change the refclk frequency as well as the FPGA dividers and it should work
<hartytp>
the fact that it doesn't shows that I don't understand how the various FPGA bits are clocked and shouldn't try to do anything more complex :(
<larsc>
what does it report for the dividers it computed etc?
rohitksingh_work has quit [Read error: Connection reset by peer]
mauz555 has quit [Ping timeout: 240 seconds]
<hartytp>
larsc: thanks again for the pointers.
<hartytp>
I'll put increasing the JESD linerate on hold for now and just crank the DAC interpolation up as a quicker way of getting the clock frequency up
<hartytp>
sb0: are there any docs for the DRTIO switching?
<sb0>
hartytp: no
<hartytp>
are you planning to write any?
<sb0>
artiq_route init, artiq_route set <destination> <hop1> <hop2> ... (on kasli: 0=local rtio, 1=sfp1, 2=sfp2; routes must end with 0), artiq_flash -f routing_table file, then 8 MSBs of RTIO channels are the destination
<sb0>
or artiq_coremgmt config routing_table
<sb0>
destinations are numbers 0-255 of your choosing
<hartytp>
okay, so all satellites are now repeaters with no special new configuration required
<hartytp>
sf0 is upstream, sfp1/2 are downstream
<hartytp>
all that is needed is to program the routing table in the master
<hartytp>
is that correct?
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
rohitksingh has quit [Client Quit]
rlindsgaard has joined #m-labs
xpoqp27 has joined #m-labs
xpoqp27 has quit [Remote host closed the connection]
<hartytp>
I would like to check synchronisation using DRTIO switching, as part of my acceptance testing
<GitHub61>
[smoltcp] whitequark commented on issue #256: > It seems when I write a straightforward case (do a bunch of `send!` calls with frames but one missing from the sequence), the `recv!` call at the end -- expecting an ACK with sACK in the TCP options -- gets `Ok(None)`, which causes an assert failure. And I cannot figure out why.... https://github.com/m-labs/smoltcp/issues/256#issuecomment-424011255
<sb0>
if no routing table is programmed, it takes a default that corresponds to a star (similar to when there was no switching)
<sb0>
as for #1155 either fix it or stop using the SERDES