Other Parts Discussed in Thread: DS280DF810
Tool/software:
Hi team,
We are using DS250DF410 retimer in one of our designs, where the retimer is kept between two AMD Zynq Ultrascale+ SoCs. The connection is as shown below:
MPSoC1 GTY_TXn >> PCB trace section 1 >> DS250DF410 >> PCB trace section 2 >> MPSoC2 GTYx_RXn.
We have multiple links similar to what that is shown above and we are using Aurora protocol between the MPSoCs with a datarate of 24.33024Gbps. During bootup, the MPSoC1 boots up initially, then configures the retimer, and boots the MPSoC 2.
We are noticing an issue with some of the links where there are errors in the frames received at the receiving side MPSoC(both MPSoCs randomly). Please see our observations below:
- We are observing that the errors(soft error in Aurora) keep on incrementing in the affected links, while the others work fine.
- The issue is not observed all the time, but the probability of it happening is approximately 1 out of 5 boot ups.
- We have tried to reconfigure the retimer(which also re-establishes the Aurora link), which stopped the errors from incrementing.
- Similarly, we changed the sequence by configuring the retimer after MPSoC2 also booted up, which also worked fine, and link was up without any errors.
- After the above step(no error), we have rebooted both the MPSoCs, keeping the retimer in configured state. This however caused the errors to increment as before.
- We have resetted the Aurora IP in both the SoCs after the boot, which also stopped the error from incrementing.
From the above observations, it is evident that re-establishing the link seems to be resolving the issue. But, as we are only observing this issue in just few of our boards, while the links in other board(and the other links in same board) works just fine, we are in doubt whether there are any underlying signal integrity or component or timing issues with these boards. Due to this, we are analysing to find out the root cause. We have ran Vivado IBERT tests on these links, and the results are good, and similar to other links.
Could you please share your thoughts on any debugging which we can do from the retimer side?
- Could you please help on how to capture the eye, using just the I2C interface which we have access throught the MPSoC Processor subsection(petalinux)?
- Would there be any channel related adjustments (like equalisation) that is being done by the retimer which could contribute to this? Could you please share your thoughts?
- We shall try the raw mode option once. Does the raw mode completely bypasses the retimer?
- Could you please review the retimer configuration
Please see the relevant sections of retimer configuration script, that we run in Petalinux(OSC: 25MHz):
i2cset -y -m 0x01 -r 1 $SLAVE_ADDR 0xff 0x01
i2cset -y -m 0xFF -r 1 $SLAVE_ADDR 0xfc 0x01
i2cset -y -m 0x03 -r 1 $SLAVE_ADDR 0xff 0x03
i2cset -y -m 0x04 -r 1 $SLAVE_ADDR 0x00 0x04
i2cset -y -m 0x0c -r 1 $SLAVE_ADDR 0x0a 0x0c
i2cset -y -m 0xFF -r 1 $SLAVE_ADDR 0x60 0xD3
i2cset -y -m 0xFF -r 1 $SLAVE_ADDR 0x61 0xBC
i2cset -y -m 0xFF -r 1 $SLAVE_ADDR 0x62 0xD3
i2cset -y -m 0xFF -r 1 $SLAVE_ADDR 0x63 0xBC
i2cset -y -m 0xFF -r 1 $SLAVE_ADDR 0x64 0xFF
i2cset -y -m 0x04 -r 1 $SLAVE_ADDR 0x09 0x04
i2cset -y -m 0x70 -r 1 $SLAVE_ADDR 0x18 0x00
i2cset -y -m 0x0C -r 1 $SLAVE_ADDR 0x0A 0x0C
i2cset -y -m 0x0C -r 1 $SLAVE_ADDR 0x0A 0x00
i2cset -y -m 0x60 -r 1 $SLAVE_ADDR 0x31 0x20
i2cset -y -m 0x08 -r 1 $SLAVE_ADDR 0x1e 0x08
i2cset -y -m 0x80 -r 1 $SLAVE_ADDR 0x3d 0x80
i2cset -y -m 0x40 -r 1 $SLAVE_ADDR 0x3d 0x00
i2cset -y -m 0x40 -r 1 $SLAVE_ADDR 0x3f 0x40
i2cset -y -m 0x40 -r 1 $SLAVE_ADDR 0x3e 0x40
i2cset -y -m 0x1F -r 1 $SLAVE_ADDR 0x3d 0x0f
i2cset -y -m 0x0F -r 1 $SLAVE_ADDR 0x3f 0x00
i2cset -y -m 0x0F -r 1 $SLAVE_ADDR 0x3e 0x03
i2cset -y -m 0x0C -r 1 $SLAVE_ADDR 0x0a 0x00