Hi,
@list: See below for some nitty-gritty details of fixed-latency
transceiver implementation, if you are interested in that. It only
impacts the gateware and is of no relevance to the hardware.
@Peter: Thanks for your replies. I expected the elastic buffer to be
clocked at the frequency of the user data clock, and therefore the
magnitude of the jumps should be equal to its period, i.e. several
nanoseconds. Are you sure that you do not happen to hit a phase
relationship in your design that is away from a jump point and therefore
you get deterministic latency (by chance)? Or am I misunderstanding
something? Is the elastic buffer clocked faster than the user data clock?
And yes, we would like the highest accuracy we can reasonably get.
Sébastien
On Thursday, July 07, 2016 06:12 PM, Peter Jansweijer wrote:
Hi Sebastien,
For Virtex 6 devices where the TX latency (using elastic buffer) was not
fixed. In retrospective you bring up a good point about discrete jumps
in the elastic virtex6 buffer. All other FPGAs behaved deterministic.
Indeed, jitter causes small latency variations between startups. Have a
look at slide 16 of
http://www.ohwr.org/attachments/3552/141006_WR_Workshop_8_KM3NeT.pptx
Never mind the outliers since they were caused by endpoint bugs that
were solved in later releases. You can see a red (SPEC) and blue (KM3eT
CLB) band with a spread in time for different restarts. There are
multiple causes but the jitter you mention is one of the parameters.
Oscillator stability and the servo software are other parameters.
For a high accuracy WR implementation we should determine the amount of
jitter for each of the parameters, among others these PHY elastic buffer
restart latency uncertainty. For the past specification (< 1 ns) is was
just accepted as good enough.
Are you aiming for better precision than the 1 ns specification, and is
this why you are concerned about latency variations?
Cheers,
Peter
On 7-7-2016 10:24, Sébastien Bourdeauducq wrote:
Hi,
Yes. But how do you ensure that the phase relation between the two
domains isn't near a value that causes a discrete jump in the elastic
buffer latency (and then jitter can cause latency variation between
startups)?
Sébastien
On Thursday, July 07, 2016 03:55 PM, Peter Jansweijer wrote:
Hi Sebastien,
The situation is as you describe. However the phase relation between one
and the other domain is fixed (and thus deterministic).
For Rx you use the recovered clock at both sides of the fifo.
For Tx the recovered clock is used for write and the GTX ref clock
(derived from the recovered clock bij the VCXO) is used for reading the
Tx fifo.
So you can do without the fifo's but need to be careful that both
domains have proper setup and hold times. This can be automatically done
by using the phase align ports on the GTX or GTP (see for example
gtp_phase_align_virtex6). The phase is then fixed at a safe value (and
deterministic again). The latter involves an extra state machine which
can be avoided when using the elastic buffer. For Virtex6 the elastic
buffer didn't function well so there we needed to implement the phase
alignment.
Cheers,
Peter
On 6-7-2016 14:38, Sébastien Bourdeauducq wrote:
Hi Peter,
As I understand the situation, the TX/RX buffers are shallow FIFO
ringbuffers where the write pointer is incremented at each cycle of
the write clock, and the read pointer is incremented at each cycle of
the read clock. The initial difference between the write and read
pointers depends on the phase relationship between the write and read
clocks. For some phase relationships, the jitter causes an uncertainty
of one position for the write/read pointer difference, and therefore
the buffers cannot be used if one wants reliable deterministic latency.
Sébastien
On Monday, June 20, 2016 05:28 PM, Peter Jansweijer wrote:
Hi Sebastien,
Enabling TX/RX buffers avoids a phase alignment cycle. The buffers
take
care of proper PMA/PCS clock domain crossing. The latencies are fixed.
I didn't understand your later remark about using the RX CDR clock,
filter it, and use it for TX? The Rx recovered clock is used for the
receiving side of the PHY. In combination with gtp_bitslide this gives
you fixed latency as well on the Rx path.
Cheers,
Peter
On 20-6-2016 10:30, Tomasz Wlostowski wrote:
On 17.06.2016 17:26, Sébastien Bourdeauducq wrote:
Also, how can you take the RX CDR clock, filter it, and use it
for TX
without using the QPLL?
Or is this transceiver PHY not working according to the published WR
documentation?
Hi Sebastien,
I think the best person to answer your questions would be Peter. I
haven't used WR yet on a Kintex-7...
Cheers,
Tom
Sébastien
On Friday, June 17, 2016 11:18 PM, Sébastien Bourdeauducq wrote:
Hi,
I'm looking at the WR code right now and I'm surprised that the RX
and
TX buffers of the GTX transceivers for 7-series are enabled. Aren't
they
introducing unpredictable latency that is potentially different
for the
two directions of the link?
Sébastien
_______________________________________________
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
