Current Server Time: 14:43 (Central Europe)

#apertus IRC Channel Logs

2019/05/21

Timezone: UTC


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