Current Server Time: 19:31 (Central Europe)

#apertus IRC Channel Logs

2019/05/21

Timezone: UTC


00:25
johnathan
joined the channel
00:25
johnatha_
left the channel
00:28
Davelister
joined the channel
00:28
Davelister
changed nick to: Guest61027
00:32
Guest61027
left the channel
01:23
futarisIRCcloud
left the channel
01:29
Davelister
joined the channel
01:29
Davelister
changed nick to: Guest52451
01:33
Guest52451
left the channel
02:30
Davelister
joined the channel
02:30
Davelister
changed nick to: Guest58773
02:34
futarisIRCcloud
joined the channel
02:35
Guest58773
left the channel
02:54
johnathan
left the channel
04:27
BAndiT1983|away
changed nick to: BAndiT1983
04:27
BAndiT1983
changed nick to: BAndiT1983|away
05:47
Davelister
joined the channel
05:47
Davelister
changed nick to: Guest48002
05:52
Guest48002
left the channel
06:44
futarisIRCcloud
left the channel
07:25
futarisIRCcloud
joined the channel
07:45
Bertl_zZ
changed nick to: Bertl
07:45
Bertl
morning folks!
09:42
aombk
joined the channel
09:44
futarisIRCcloud
left the channel
11:10
futarisIRCcloud
joined the channel
11:42
BAndiT1983|away
changed nick to: BAndiT1983
12:15
illwieckz
left the channel
12:31
se6astian|away
changed nick to: se6astian
13:18
BAndiT1983
changed nick to: BAndiT1983|away
13:21
Nira|away
changed nick to: Nira
13:33
Bertl
Hey Nira! How's it going?
13:40
se6astian
changed nick to: se6astian|away
13:59
anuejn_
joined the channel
13:59
aSobhy
joined the channel
14:01
alexML_
joined the channel
14:01
Bertl_
joined the channel
14:01
lexano
left the channel
14:06
Bertl
left the channel
14:06
anuejn
left the channel
14:06
alexML
left the channel
14:06
aSobhy|away
left the channel
14:20
lexano
joined the channel
14:21
Bertl_
changed nick to: Bertl
15:02
lexano
left the channel
15:16
lexano
joined the channel
15:19
futarisIRCcloud
left the channel
15:57
aSobhy
changed nick to: aSobhy|away
15:57
aSobhy|away
changed nick to: aSobhy
15:58
johnathan
joined the channel
16:13
Nira
changed nick to: Nira|away
16:14
BAndiT1983|away
changed nick to: BAndiT1983
16:21
lexano
left the channel
16:37
lexano
joined the channel
16:59
Bertl
evening everybody!
17:00
aSobhy
evening Bertl :)
17:03
Bertl
felix_, _florent__, apurvanandan[m]: you around?
17:06
_florent__
hi
17:07
Bertl
great to have you here as well ...
17:07
Bertl
okay, let's start and see who shows up later ...
17:07
Bertl
aSobhy: did you find useful information online regarding the topics we want to discuss today?
17:08
aSobhy
yeah :)
17:08
Bertl
great, then please start with whatever you like
17:09
aSobhy
1- for the encoding techniques : I have found that article comparing a lot of technique
17:09
aSobhy
https://www.lightwaveonline.com/optical-tech/article/16647657/coding-techniques-for-highspeed-serial-interconnect
17:10
Bertl
nice
17:11
aSobhy
mostly it compares the 8b/10b with other techniques as 8b/10b has huge overhead 25%
17:12
Bertl
it is nice that it also mentions scrambling
17:12
aSobhy
didn't dig to the comma encoding (didn't find time to understand )
17:12
Bertl
okay, good find, what else have you got for us?
17:13
aSobhy
I found a paper Published in: IEEE Transactions on Biomedical Circuits and Systems
17:13
aSobhy
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
17:14
aSobhy
https://ieeexplore.ieee.org/document/8010303
17:14
Davelister
joined the channel
17:14
Davelister
good evening
17:14
aSobhy
that I think it has a project that I work on
17:14
Davelister
changed nick to: Guest33620
17:15
Bertl
Davelister: evening, want to join our high-speed serial chat?
17:16
Bertl
aSobhy: okay, have to dig through that first ...
17:16
Bertl
anything regarding link training and word/bit alignment?
17:16
aSobhy
(just scroll and see the modules they used)
17:17
aSobhy
no I didn't search for dynamic delay adjustments :/
17:17
aSobhy
sorry for that
17:17
Bertl
okay, no problem, then let's start with some background on that
17:19
Bertl
basically at speeds higher than a few hundred MHz, you cannot create a design with static delays (fixed timing) which works under all conditions
17:20
Bertl
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
17:21
Bertl
so you usually use some run-time configureable delay elements or PLLs with adjustable phase alignments to compensate for the 'current' situation
17:22
Bertl
depending on the available hardware, there are several approaches which can be taken to adjust those delays
17:23
Bertl
the simplest case is to have a 'known' pattern which is sent at a time also 'known' to the receiver
17:24
Bertl
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
17:26
Bertl
if the hardware supports a mechanism to sample the data twice with different logic elements, another approach can be taken
17:27
Bertl
assuming you have a sample at time T0 and you get another sample at time T0 + d
17:27
Guest33620
Bertl: that would have been with pleasure but I'm just back from work :-)
17:27
Bertl
then by adjusting the 'd', which should be smaller than half the clock period of the data
17:27
Guest33620
(and I have spent mostly my day on EDA)
17:28
Bertl
you can check how much 'wiggle room' you have while still receiving the same data
17:29
Bertl
if you do those adjustments in both directions, i.e. with positive and negative 'd' you can find the middle of the 'working' range which is likely to be the best place to sample the data
17:29
Bertl
when you get too close to the 'unstable' region, you simply adjust the sample point accordingly
17:30
Bertl
does that make sense?
17:31
Bertl
any questions?
17:31
aSobhy
new sample means to find the transition of the jjittered clock ?
17:31
aSobhy
jittered*
17:33
aSobhy
or to sample as if we dropped some bits
17:33
Bertl
yes, basically you 'explore' the range where the signal is 'stable' and where it begins to become 'unstable'
17:34
Guest33620
aSobhy: ideally, we consider the data signal aligned with half of the bit period
17:34
aSobhy
and the unstable will be the transition
17:34
Bertl
you know you want to stay in the 'stable' region, so you want to move as far as possible away from the 'unstable' data
17:35
Guest33620
(I can make some diagrams here if you want)
17:35
Bertl
checking both directions from the 'current' sampling point can give you an idea where you want to sample
17:35
Bertl
Guest33620: if you have some at hand, please share
17:35
Guest33620
yup
17:36
Guest33620
https://www.xilinx.com/support/documentation/application_notes/xapp1315-lvds-source-synch-serdes-clock-multiplication.pdf
17:37
Guest33620
(but not sure if it is the best one for this application)
17:37
Guest33620
https://www.xilinx.com/support/documentation/application_notes/xapp1064.pdf
17:37
Guest33620
better
17:37
Guest33620
:-)
17:38
Guest33620
Let's consider the following clock signal
17:39
Guest33620
!-------!_______!-------!_______
17:40
Guest33620
<D0-><D1----><D2---->
17:40
Guest33620
in this example, samples are taken on the clock rising edge
17:41
Guest33620
sorry
17:41
Guest33620
on each clock edge (DDR)
17:41
Guest33620
Theory makes you expect the data to change at half the bit period
17:42
Guest33620
except the nature of the FPGA routing, and electronics as Bertl said, can make D1 delayed against the clock edge
17:43
Guest33620
The idea with dynamic delay adjustements is to make one of the clock signal as late as the latest incoming signal (clock or data)
17:43
Guest33620
for low frequency serial bus, we generally use a PLL working 8x to 16x faster than the bus clock
17:43
aSobhy
aahhh the data changes to be saturated before the next edge
17:44
Guest33620
yes, the data may change just before the next edge due to the delays
17:44
Guest33620
hence, it is not a data considered as "setup" (because there is some transcient response)
17:45
Guest33620
you want to sample the data in the middle of its period
17:45
Guest33620
(where the emitter designer has specified the data would be "set" at this exact moment)
17:46
Bertl
in general, there is a 'setup time' and a 'hold time' for any data/clock input element
17:46
Guest33620
exact
17:46
Bertl
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
17:47
Bertl
in reality the entire time of 'setup' + 'hold' the signal needs to be stable to guarantee correct sampling
17:47
Guest33620
if we take a closer look at the clock + data signals:
17:48
Guest33620
-------!________
17:48
Guest33620
=<setup|hold--->
17:49
aSobhy
yeah I knew setup and hold time (exams effect)
17:50
Guest33620
oh great :-)
17:50
aSobhy
so If we are in unstable I set d to large value to skip those changes
17:50
Guest33620
yes, if the data signal is to late, we try to deport it to the next clock edge)
17:51
Bertl
in the case with dual sampling, when you are in the unstable region, you have to adjust
17:51
Guest33620
too late*
17:51
Bertl
but if you sample in the stable region, both samples will be identical and you know you're still good
17:53
aSobhy
dual sample : the first sample is on the generated clock and the second is +d ?
17:54
Bertl
____/---------\_____ /---------\_____
17:54
Bertl
\---------/ \---------/
17:54
Bertl
^ ^ ^ ^ ^
17:54
Bertl
T0 T1 T2 T3 T4
17:54
Bertl
let's say your 'normal' sampling point is T1
17:55
Bertl
with adjusting the 'd', you can also sample T0, T2, T3 and T4 (only one of them at a time of course)
17:56
Bertl
sampling at T0 or T2 will give you the same value as your T1 sample
17:56
Bertl
while T3 will result in wrong values every now and then
17:56
Bertl
and T4 will almost always give you a wrong result
17:57
Bertl
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
17:57
aSobhy
T1
17:58
Bertl
if T0 would give wrong results, and T3 would be fine
17:58
Bertl
then you know you want to move to sampling at T2 instead of T1
17:59
Bertl
(simplified)
17:59
illwieckz
joined the channel
17:59
aSobhy
yes :)
17:59
Bertl
so for example a good pattern to 'align' your data with your clock is an alternating pattern, like 0101010101
18:00
Bertl
but at some point, you have the data aligned at the bit level and want to align it on the word boundary as well
18:01
Bertl
this is the point where an alternating bit stream is a bad pattern to train with :)
18:01
Bertl
let's say your data words are 8 bit in size, then you could for example use an alternating pattern like this
18:02
Bertl
00000000111111110000000011111111
18:02
Bertl
if you receive alternating values like 00000011 and 11111100
18:03
Bertl
you know that your word alignment is off by two bits
18:03
Bertl
and you can adjust this by dropping a bunch of bits during reception (bit slip)
18:04
Bertl
alternatively you can keep older words around and combine two consecutive received words into one aligned word
18:05
Bertl
i.e. take the 11 from the first received word and combine it with the 111111 from the second word
18:06
Bertl
for the next word, the 00 from the second word will be combined with a 000000 from the third received word
18:06
aSobhy
and continue with that sequence all the run time with knowing what offset I should save for the next iteration ?
18:06
Bertl
yup, that is the 'word' alignment for this data stream
18:07
Bertl
both methods are very similar and give equivalent results
18:07
Bertl
you can also combine the two patterns to form one which can be used for bit and word alignment
18:08
Bertl
e.g. 0101010110101010
18:08
Bertl
note that at word boundaries you'll always get two 1 or two 0
18:08
Bertl
also note that this is just one example how such a training pattern can look like
18:09
Bertl
_florent__, felix_, Guest33620: any comments/input here?
18:09
vup
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?
18:13
aSobhy
sample at larger d ?
18:14
vup
i am talking about the alignment of words, not the bits, i don't see how a larger d would help there...
18:15
aSobhy
ah okay
18:15
Bertl
your pattern needs to be long enough to match the word size
18:16
Bertl
i.e. if your word is 8 bit, an 8 bit pattern is enough to align
18:16
vup
ah maybe i should have mentioned that i am talking about multiple data lanes
18:17
vup
there you need a pattern that is long enough to match the biggest expected discrepancy between the lanes (and atleast as long as the word size), no?
18:17
Bertl
multiple data lanes should be trained independantly if possible
18:18
Bertl
if not possible, you need to construct a pattern which consists of several smaller patterns
18:19
vup
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?
18:20
Bertl
how is the data composed/decomposed?
18:21
Guest33620
vup: there are sync words
18:22
Guest33620
and you keep each lane serialising independally
18:22
Guest33620
then, we generally set a FIFO for a clock domain crossing
18:23
Guest33620
the output clock is then in charge of reading each FIFO (one per lane) according to the protocol :-)
18:23
Guest33620
(like a round robin)
18:23
Guest33620
(sorry I forgot the main part)
18:23
vup
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?
18:24
danieel
vup: the max dispreparancy is given by the mismatch in trace length, which is usually under/around 1 bit at the assumed speeds and board designs
18:24
Guest33620
danieel: if the designer is not too bad, that's the case :-)
18:24
Guest33620
vup: because of the delays
18:25
Guest33620
your data is sampled (for each lane) with a ±1 bit
18:25
vup
danieel: thats not what i am getting, even with good trace length matching, i am getting around 2-4 bits dispreparancy, maybe thats an artifact of the zynq serdes?
18:25
Guest33620
vup: yes it may
18:26
Guest33620
I had some issues with that on a project I cannot introduce here
18:26
Guest33620
and each datalane is on the same I/O bank and are neighbors
18:26
Guest33620
this is due of the data signals route into the Zynq
18:26
Guest33620
and it looks like we cannot do anything :/
18:27
Guest33620
However it is repeatable
18:27
vup
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>
18:27
vup
Guest33620: yeah, that sounds similar to what i am observing
18:28
vup
Guest33620: i don't get what you mean by >because of the delays
18:28
Guest33620
oh I see
18:28
danieel
the 2-4 is still within the chunks of 8 bits in parallel domain
18:29
danieel
(or across two)
18:29
Guest33620
let's consider you get 4 data lanes, each with IDELAY components
18:29
Guest33620
the routing software from Vivado evaluates its timing against a clock edge
18:30
Guest33620
hence, each your word divided on the different data lane might be sampled with a ±1 bit delay
18:30
Bertl
vup: if the data can really be misaligned by eight bit or more (rather unlikely) you need a 64 bit pattern
18:31
Guest33620
(I mean, Vivado does not evaluate the sampling time of all data lanes at the same time, just for one)
18:31
Guest33620
(damn, I need a whiteboard)
18:32
Guest33620
the IDELAY can make a datalane data sampled at the second next clock edge (because the data is too late for example)
18:33
Guest33620
hence you will not get your data lane word serialized completely at the same time
18:34
Guest33620
changed nick to: Davelister
18:35
Davelister
left the channel
18:35
Davelister
joined the channel
18:36
Bertl
okay, to end a rather long meeting, there are basically two ways for dynamic adjustments (as I already mentioned earlier):
18:36
Bertl
1) adjust a delay element (for clock or data)
18:37
Bertl
2) adjust the phase alignment of a PLL
18:38
aSobhy
OK
18:38
Bertl
for next time, try to find examples for good training patterns and some documentation how the double sampling can be done in e.g. Xilinx 7Series
18:39
Bertl
if possible, also investigate bitslip and word recombination
18:39
Bertl
17:00 UTC next week is fine?
18:40
vup
Bertl: ok, that's basically what i was talking about
18:40
Bertl
i.e. Tuesday next week, same day, same time
18:40
aSobhy
OK
18:40
aSobhy
but I've started the exams so the effort will reduce
18:41
Bertl
that's fine, apurvanandan[m] has to catch up anyways
18:42
Bertl
vup: if you expect a lane to differ by a whole word (while it should be aligned) then you probably have a serious problem somewhere
18:42
Bertl
i.e. the delays are typically in the range of a bit or less, maybe a few bits at most
18:43
Bertl
but there is still a trick you can use to verify that if you are only able to set a 32bit pattern
18:44
Bertl
because when you change the 32bit pattern, you actually get a 64bit synchronization point
18:44
Bertl
and if you choose the two 32bit pattern carefully, you know exactly whether everything is aligned or 'off by a word'
18:47
vup
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
18:48
vup
yeah changing the 32bit pattern is a neat trick
18:49
Bertl
because in contrary to a fixed pattern, a PRBS requires a synchronized 'start point'
18:49
Bertl
same problem as with PRNGs :)
18:50
vup
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
18:51
vup
and find the start point that way
18:51
Bertl
that takes an awfully long and complicated logic to achieve the same as with a fixed pattern
18:52
vup
sure, it isn't the simplest or smallest solution ;)
18:52
Bertl
but I'm sure it makes sense to use this for fine tuning equalizers and other stuff
18:53
Bertl
so when your encoding gets more complex and you want to utilize a noisy channel as efficiently as possible, training with PRBSs is a viable approach
18:54
Bertl
Nira|away: please ping me tomorrow when you have some time ...
18:54
vup
Bertl: yeah, sounds resonable
19:12
Bertl
off for now ... bbl
19:12
Bertl
changed nick to: bertl_oO
19:12
bertl_oO
changed nick to: Bertl_oO
19:17
Y_G
joined the channel
19:20
illwieckz
left the channel
19:28
BAndiT1983
changed nick to: BAndiT1983|away
19:44
se6astian|away
changed nick to: se6astian
19:57
BAndiT1983|away
changed nick to: BAndiT1983
20:24
johnathan
left the channel
20:43
Nira|away
changed nick to: Nira
20:49
illwieckz
joined the channel
20:59
BAndiT1983
changed nick to: BAndiT1983|away
21:07
se6astian
changed nick to: se6astian|away
21:12
Davelister
left the channel
21:28
felix_
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
21:30
felix_
for high-speed applications it's usually best to train each lane independent from the other lanes. when the words in each lane are adjusted to be at the right bit positions, then i'd just use a small fifo in the data path of each lane to compensate the 0 to maybe 2 words offset
21:33
felix_
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
21:35
felix_
you could also send one value on all lanes for a certain time and then send another value and see at which time the values at the receivers change; i find the approach woth the conter a bit more intuitive and i can see if the link has some problems (when the differences aren't constant wiithin one run)
21:52
danieel
btw any explicit training would need a oob signal, eg TRAIN/LOCKn, as in Vx1 protocol
22:20
johnathan
joined the channel
22:25
johnatha_
joined the channel
22:25
johnathan
left the channel
22:28
johnathan
joined the channel
22:29
johnatha_
left the channel
22:37
Nira
changed nick to: Nira|away
23:10
Davelister
joined the channel
23:10
Davelister
changed nick to: Guest16056
23:14
Guest16056
left the channel
23:28
johnathan
left the channel
23:41
johnathan
joined the channel