<sb0>
larsc, sure. i already expressed what I think of the PCS.
<sb0>
larsc, the comma-align I'm doing is probabilistic only because the xilinx garbage does not let me shift the parallel clock divider in a deterministic way. all I can do is reset it and get another random phase.
<sb0>
and I need to touch the clock divider because I want precisely fixed latency. if you don't care too much about latency, you can comma-align with a barrel shifter, deterministically and without hacks
<sb0>
that comma aligner will also tell you by how much the transceiver clock needs to be shifted to achieve a given latency. but doing it isn't easy.
<cr1901_modern>
Huh... wonder why the SPI core is refusing to send the last few bits...
<whitequark>
is the SPI bug still not fixed?
<cr1901_modern>
It's a new one it seems
<cr1901_modern>
I'd have to see the code used, but if the same input works < 2MHz xfer but fails > 2 MHz xfer, I don't think simulation is going to help me
<sb0>
whitequark, different one, see the new issue
<sb0>
but we need to confirm first that this is indeed a spi core issue.
<sb0>
rjo, we don't actually need two loop timings on RTM. we can use RTM_MASTER_AUX_CLK_N for the DRTIO link.
<sb0>
this is driven by the HMC clock chip. it is unfortunately not connected to a transceiver clock input, so it'll have to go through the fabric and GTGREFCLK
<sb0>
so even if we get RXSLIDEMODE=PMA to work, the xilinx garbage will still produce an uncertainty of one UI
<sb0>
"Their experimental results indicate that the internal alignment circuit of the GTX/GTP transceiver can perform only the even-UI phase-shifts of RX_CLK."
<sb0>
"For the odd-UI phase differences between TX_CLK and RX_CLK, their solution was to reset the transceiver"
<sb0>
_florent_, so we shouldn't look into RXSLIDEMODE=PMA I think. the slow link startup time is OK.
<sb0>
_florent_, partial transceiver resets may help if link startup time becomes a problem
<sb0>
"The excessive jitter of RX_CLK may cause the DCM and PLL to lose lock," xilinx shit is always so poorly designed. can't make PLLs that would work with their transceiver's recovered clock, no. they prefer spending their time on irrelevant stuff like the PCS
<sb0>
or stupid transceiver wizard GUIs
<_florent_>
sb0: ok, I'm going to read the paper
<whitequark>
sb0: unfortunately I have to worry.
<whitequark>
in my laptop the keyboard is inseparable from the topcase
<whitequark>
and it's the part that has broken, at this point, four times already...
<GitHub>
[artiq] cjbe commented on issue #671: I don't know how large is too large, but several colleagues of mine have hit the ~400k double limit doing things that do not seem like an abuse of the broadcasting system. For example broadcasting a long scope trace or a vector of photon time-stamps.... https://github.com/m-labs/artiq/issues/671#issuecomment-280606113
<larsc>
the paper seems to use a virtex5, so not all restrictions must apply to series7 as well
<sb0>
larsc, the 7-series datasheet also mention something about even/odd UIs for rxslide, so it's probably the same horseshit