#apertus IRC Channel Logs

Hey Nira! How's it going?

evening Bertl :)

hi

okay, let's start and see who shows up later ...

yeah :)

1- for the encoding techniques : I have found that article comparing a lot of technique

nice

it is nice that it also mentions scrambling

okay, good find, what else have you got for us?

It's name : On Multiple AER Handshaking Channels Over High-Speed Bit-Serial Bidirectional LVDS Links With Flow-Control and Clock-Correction on Commercial FPGAs for Scalable Neuromorphic Systems

that I think it has a project that I work on

Davelister: evening, want to join our high-speed serial chat?

anything regarding link training and word/bit alignment?

no I didn't search for dynamic delay adjustments :/

okay, no problem, then let's start with some background on that

even if the data is perfectly aligned with a clock, the jitter and changes in temperature, voltage or clock will likely produce a very bad/weak link

depending on the available hardware, there are several approaches which can be taken to adjust those delays

i.e. the receiver knows in advance what data to expect and if the data is repeated several times, the receiver can adjust the delays to capture the transmitted pattern as good as possible

assuming you have a sample at time T0 and you get another sample at time T0 + d

then by adjusting the 'd', which should be smaller than half the clock period of the data

you can check how much 'wiggle room' you have while still receiving the same data

when you get too close to the 'unstable' region, you simply adjust the sample point accordingly

any questions?

jittered*

yes, basically you 'explore' the range where the signal is 'stable' and where it begins to become 'unstable'

and the unstable will be the transition

(I can make some diagrams here if you want)

Guest33620: if you have some at hand, please share

https://www.xilinx.com/support/documentation/application_notes/xapp1315-lvds-source-synch-serdes-clock-multiplication.pdf

https://www.xilinx.com/support/documentation/application_notes/xapp1064.pdf

:-)

!-------!_______!-------!_______

in this example, samples are taken on the clock rising edge

on each clock edge (DDR)

except the nature of the FPGA routing, and electronics as Bertl said, can make D1 delayed against the clock edge

for low frequency serial bus, we generally use a PLL working 8x to 16x faster than the bus clock

yes, the data may change just before the next edge due to the delays

you want to sample the data in the middle of its period

in general, there is a 'setup time' and a 'hold time' for any data/clock input element

and you want to make sure that the signal is stable for the 'setup time' before it is sampled and also for the 'hold time' after the 'theoretical' sampling point

if we take a closer look at the clock + data signals:

=<setup|hold--->

oh great :-)

yes, if the data signal is to late, we try to deport it to the next clock edge)

too late*

dual sample : the first sample is on the generated clock and the second is +d ?

\---------/ \---------/

T0 T1 T2 T3 T4

with adjusting the 'd', you can also sample T0, T2, T3 and T4 (only one of them at a time of course)

while T3 will result in wrong values every now and then

if you 'figure' out that T0 and T2 is fine (most of the time) then you can assume that you are sampling at the optimal point

if T0 would give wrong results, and T3 would be fine

(simplified)

yes :)

but at some point, you have the data aligned at the bit level and want to align it on the word boundary as well

let's say your data words are 8 bit in size, then you could for example use an alternating pattern like this

if you receive alternating values like 00000011 and 11111100

and you can adjust this by dropping a bunch of bits during reception (bit slip)

i.e. take the 11 from the first received word and combine it with the 111111 from the second word

and continue with that sequence all the run time with knowing what offset I should save for the next iteration ?

both methods are very similar and give equivalent results

e.g. 0101010110101010

also note that this is just one example how such a training pattern can look like

with a pattern like 0000000011111111 you could still be missaligned by two whole words and not "notice" it, are there any tricks for that, other than a longer patterns?

i am talking about the alignment of words, not the bits, i don't see how a larger d would help there...

your pattern needs to be long enough to match the word size

ah maybe i should have mentioned that i am talking about multiple data lanes

multiple data lanes should be trained independantly if possible

ok lets assume we are transfering 32 bit words striped in 8 bit words across 4 data lanes, how do you make sure each of the 8 bit words from the data lane is for the same 32 bit word, when training the lanes independantly?

vup: there are sync words

then, we generally set a FIFO for a clock domain crossing

(like a round robin)

Guest33620: ok, but if the transmitter offers lets say a decently long PRBS test pattern, why not do it already in the word alignment step?

danieel: if the designer is not too bad, that's the case :-)

your data is sampled (for each lane) with a ±1 bit

vup: yes it may

and each datalane is on the same I/O bank and are neighbors

and it looks like we cannot do anything :/

Bertl: a data word D1<0:31> gets striped across the lanes as D1<0:7>, D1<8:15>, D1<16:23>, D1<24:31>

Guest33620: i don't get what you mean by >because of the delays

the 2-4 is still within the chunks of 8 bits in parallel domain

let's consider you get 4 data lanes, each with IDELAY components

hence, each your word divided on the different data lane might be sampled with a ±1 bit delay

(I mean, Vivado does not evaluate the sampling time of all data lanes at the same time, just for one)

the IDELAY can make a datalane data sampled at the second next clock edge (because the data is too late for example)

1) adjust a delay element (for clock or data)

OK

if possible, also investigate bitslip and word recombination

Bertl: ok, that's basically what i was talking about

OK

that's fine, apurvanandan[m] has to catch up anyways

i.e. the delays are typically in the range of a bit or less, maybe a few bits at most

because when you change the 32bit pattern, you actually get a 64bit synchronization point

Bertl: well at the moment i only see about 2-4 bits, this was more of a theoretical question, basically just wondering why one doesn't use e.g. a PRBS for word alignment

because in contrary to a fixed pattern, a PRBS requires a synchronized 'start point'

if you know the period of the PRBS you could just xor it over that period with the "reference" PRBS and bitslip until you no longer get any one's

that takes an awfully long and complicated logic to achieve the same as with a fixed pattern

but I'm sure it makes sense to use this for fine tuning equalizers and other stuff

Nira|away: please ping me tomorrow when you have some time ...

off for now ... bbl

huh, i had the serial link talk in my calendar for yesterday and wondered why it wasn't happening. tuesdays 19:00 cest doesn't work for me

for testing the latter or doing latency measurements, i find it easiest to send a value that is incereased by 1 every word sent; the difference at the reciever is the difference in word alignment and should be constant within one run. that has to be dine after each lane is trained and the data bits within one lane are aligned

btw any explicit training would need a oob signal, eg TRAIN/LOCKn, as in Vx1 protocol