Current Server Time: 17:49 (Central Europe)

#apertus IRC Channel Logs

2021/06/30

Timezone: UTC


02:09
Bertl_oO
should be available around 18:00 CEST
02:09
Bertl_oO
off to bed now ... have a good one everyone!
02:09
Bertl_oO
changed nick to: Bertl_zZ
09:04
Bertl_zZ
changed nick to: Bertl
09:04
Bertl
morning folks!
09:57
Bertl
off for now ... bbl
09:57
Bertl
changed nick to: Bertl_oO
16:45
tpw_rules
Bertl_oO: hello! could you explain how the LVDS training works on the current beta gateware? like i said before, i am a bit confused because the delay made possible by the IDELAYE2 is only about half the bit period
16:57
Bertl_oO
hey
16:58
Bertl_oO
the trick here is that we use an IDELAY2 on each of the channels, including the clock channel (from the sensor)
16:59
Bertl_oO
and the logic behind the ISERDES is clocked by a PLL based on this clock return channel
17:01
Bertl_oO
bot note here, if we switch to higher clock rates (which we want to do anyway) then the problem goes away
17:02
Bertl_oO
but to answer your original question, the training works like this:
17:03
Bertl_oO
we first adjust the clock IDELAY and verify that all data channels and the control channel report at least a few matches with the pattern when being adjusted
17:04
Bertl_oO
then we 'guess' the best setting for the clock delay and use it for detailed tuning of the channels
17:05
Bertl_oO
the channel delay often is a guess as well, especially if we get correct pattern reception over the entire adjustment range
17:06
Bertl_oO
once all adjustments have been made, we do another check and report the 'working' channels
17:07
Bertl_oO
in case a channel fails, the process is repeated
17:07
tpw_rules
is the pattern match a binary thing? i found https://www.xilinx.com/support/documentation/application_notes/xapp855.pdf but it looks like they use a 010101010101 pattern or so and look specifically for the transition edges
17:07
Bertl_oO
note that we reset the PLL and ISERDES in this case, to make sure everything is in a good condition
17:10
tpw_rules
but i don't think you can get a pattern like that out of the control channel. i also notice the training program allows the user to specify an arbitrary pattern
17:10
Bertl_oO
yes, training with an even/odd pattern is certainly a good approach as well
17:11
Bertl_oO
yes, but you need a word specific pattern for word alignment
17:11
Bertl_oO
(not for the bit alignment)
17:11
tpw_rules
word specific?
17:12
Bertl_oO
well, 8/10/12 bit requires different pattern to detect the word alignment
17:12
tpw_rules
also presumably you cannot detect bit alignment with all 0s or all 1s
17:12
Bertl_oO
s/word specific/word size specific/
17:13
Bertl_oO
correct, and paterns like 000011110000 will be problematic at least for bit alignment ;)
17:14
Bertl_oO
this is mostly because the eye pattern changes dramatically when there are long runs of 0 or 1
17:15
tpw_rules
so the only feedback you have from a channel is if the word matches the known pattern?
17:15
tpw_rules
or doesn't?
17:15
Bertl_oO
kind of, this is of course averaged over a number of samples
17:16
tpw_rules
what do you mean?
17:16
Bertl_oO
the gateware creates a '1' for a pattern match and a '0' for a miss
17:17
Bertl_oO
this bit is then shifted in a register and the register is checked for the number of '1's
17:17
Bertl_oO
so the channel is only reported as 'being okay' when there is a number of consecutive pattern matches
17:17
tpw_rules
this register is in the C code, correct
17:18
Bertl_oO
no, that's done in the FPGA if I remember correctly
17:18
tpw_rules
hm ok
17:19
Bertl_oO
https://github.com/apertus-open-source-cinema/axiom-firmware/blob/main/peripherals/soc_main/par_match.vhd
17:19
tpw_rules
well i think that's the questions i had, thank you for the information
17:19
Bertl_oO
see GEN_match there
17:20
tpw_rules
ok, so MATCH is 1 if it matched for 8 consecutive words, and MISMATCH if it failed to match for 8 consecutive words?
17:20
Bertl_oO
yep, that's the current default
17:20
tpw_rules
i assume par12_a is the full 12 bit word type?
17:21
Bertl_oO
yep
17:21
tpw_rules
ok
17:21
tpw_rules
thank you!
17:21
Bertl_oO
you're welcome!
17:21
Bertl_oO
btw, it would be quite nice to check for patterns during idle an maybe even OH
17:22
Bertl_oO
those periods could also be used to carefully tune the delays during normal operation
17:22
tpw_rules
yes, that was an extension i had in mind
17:22
tpw_rules
i am not sure if there will be time; i am behind a couple weeks on my schedule. but we will see
17:25
vup
I think in theory you could also use the oversample mode of the iserdes + use two iserdes per channel to sample each bit at at 0, 90, 180 and 270 degrees phase and use that to either a) figure out the correct delay or b) just do data recovery directly
17:25
vup
but this is probably a lot more work than necessary
17:32
Bertl_oO
a good option IMHO would be to adjust the SERDES to half the bit length (i.e. 4/5/6) and use the second SERDES on the inverted signal for reference
17:32
Bertl_oO
this would allow to do adjustments on one of them while using the other for actual data
17:33
Bertl_oO
so there are a bunch of nice options in case you want to improve things there ;)
17:39
tpw_rules
do you mean word length?
17:39
tpw_rules
i guess i would need to see what the data looks like to more fully understand the problem and your suggestions. i don't have an intuitive feel for what is going on
20:27
Bertl_oO
the SERDES allows certain 'word length' to convert from serial to parallel (or vice versa)
20:28
Bertl_oO
this doesn't necessarily have to match the word size of the sensor data but it should at least partially match
20:29
Bertl_oO
there are also two SERDES blocks for each LVDS pair and if you need larger word sizes (>8) they can be combined in a master-slave setup
20:30
Bertl_oO
so going for <= 8 bit on the conversion allows to use both SERDES somewhat independently
20:53
vup
But for some reason cascading to 12 bit is impossible...
21:35
Bertl_oO
yes, this is likely a design flaw of the xilinx SERDES