<sb0>
hmm, getting openocd to use a kc705 board on a particular board doesn't play nice with the shipped scripts
<sb0>
*particular port
<sb0>
the hacky way to solve the problem is to hardcode the main kc705 location into /usr/local/share/openocd/scripts/interface/ftdi/digilent-hs1.cfg and write another script to use the other kc705
<sb0>
okay I'm going to create interface/ftdi/digilent-hs1-bbmain.cfg, board/kc705-bbmain.cfg, interface/ftdi/digilent-hs1-bbaux.cfg and board/kc705-bbaux.cfg
<sb0>
well, of course, the ftdi_serial command doesn't work
<sb0>
you put any sort of garbage in there and it'll connect to the first ftdi chip it finds
<sb0>
ftdi_location doesn't work either because this is debian and of course libusb is outdated
<sb0>
okay, you need to give it the serial *and* the VID/PID, otherwise it ignores everything
<sb0>
there's no way to tell if the CDR has locked, it seems?
<sb0>
they have this "RXCDRLOCK" signal, but it's marked "reserved"
<sb0>
sounds like they tried, encountered silicon bugs, and made them their customer's problem.
<_florent_>
yes, they say that you cannot trust "RXCDRLOCK" and need to have a way to detect if datas are valid or not...
<_florent_>
seems like a silicon bug indeed
<sb0>
_florent_, in litesata, is it correct that you are setting both the TX and RX clocks at 1/20 the raw serial rate?
<_florent_>
yes, 1/20 when transceiver input/output in 16bits mode (8b/10b inserted in the transceiver), 1/40 in 32bits mode
<sb0>
I really don't get how the tranceiver can so blatantly ignore the input signal and just generate 101010101 at its output
<sb0>
even if the phase alignment, clocking, or something else was wrong, it shouldn't output a stable pattern
<sb0>
xilinx wizards move in mysterious ways
<sb0>
hmm
<sb0>
_florent_, how are the clock output frequencies computed exactly?
<sb0>
I have somehow managed to get the TX into a situation where the TX line rate is 1250, user clock 125 and it takes 20-bit data. something isn't right
<_florent_>
it should simply be: line rate = N bits (20 or 40 depending how the GTX is configured) * TX user frequency
<_florent_>
sorry going out for lunch, bbl
<sb0>
yes, which it isn't
fengling has quit [Ping timeout: 240 seconds]
<sb0>
_florent_, well litesata and my design have txoutclksel=011 (TXPLLREFCLK_DIV1)
<sb0>
shouldn't it be TXPLLREFCLK_DIV1 (010) when bypassing the TX buffer?
<sb0>
ah, no
<sb0>
I meant TXOUTCLKPMA, but for some reason, it does want refclk that has gone through all the muxes when the tx buffer is disabled
<sb0>
this makes no sense though
<sb0>
let's say you have GigE; the doc recommends 20-bit and 125MHz refclk, how is that supposed to work if you bypass the TX buffer?
<sb0>
_florent_, do you know?
<sb0>
are you supposed to divide refclk to 62.5 and then readjust the cpll?
<sb0>
well considering it does the right thing when I do that, I guess the answer is yes
<sb0>
xilinx really ought to trash 90% of their transceiver cruft and properly document the remaining 10%
Gurty has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<sb0>
okay, got rx to respond to inputs. the reason it didn't before is my SFP transceivers aren't working for some reason...
sb0 has quit [Quit: Leaving]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
sb0 has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
<GitHub73>
[artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/vKrSm