#apertus IRC Channel Logs

should be available around 18:00 CEST

morning folks!

hey

and the logic behind the ISERDES is clocked by a PLL based on this clock return channel

but to answer your original question, the training works like this:

then we 'guess' the best setting for the clock delay and use it for detailed tuning of the channels

once all adjustments have been made, we do another check and report the 'working' channels

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

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

yes, but you need a word specific pattern for word alignment

word specific?

also presumably you cannot detect bit alignment with all 0s or all 1s

correct, and paterns like 000011110000 will be problematic at least for bit alignment ;)

so the only feedback you have from a channel is if the word matches the known pattern?

kind of, this is of course averaged over a number of samples

the gateware creates a '1' for a pattern match and a '0' for a miss

so the channel is only reported as 'being okay' when there is a number of consecutive pattern matches

no, that's done in the FPGA if I remember correctly

https://github.com/apertus-open-source-cinema/axiom-firmware/blob/main/peripherals/soc_main/par_match.vhd

see GEN_match there

yep, that's the current default

yep

thank you!

btw, it would be quite nice to check for patterns during idle an maybe even OH

yes, that was an extension i had in mind

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

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

so there are a bunch of nice options in case you want to improve things there ;)

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

this doesn't necessarily have to match the word size of the sensor data but it should at least partially match

so going for <= 8 bit on the conversion allows to use both SERDES somewhat independently

yes, this is likely a design flaw of the xilinx SERDES