HDMI and 10GbE

[auricm]

Hi all,

I'm working on a project on a custom board with a Zynq Ultrascale+ where I want to use the HDMI and the 10GbE IP from xilinx with petalinux (Vivado version 2019.1).
To start I used them separately, and they work fine as expected, now I put them together in the same design, obviously in different quads (225 for HDMI and 227 for 10GbE).
Now I see that the HDMI keeps working fine but the 10GbE is not generating the user clock for tx and rx user side, the block seems to be in reset or in a similar situation but I can't be sure of that as I don't know how to check it. The result is that I'm unable to send or receive through the ethernet connection.

As I remove the HDMI block from the design the 10GbE IP start working again, so I'm wondering if the HDMI block makes something wrong in the configuration of the transceiver of other quads.
Thank you for your support

Regards

[karnanl]

Hello @auricm 

Are you using Vivado with version earlier than 2019.2 ?
If yes, could you please check if GTPOWERGOOD is asserted in your failed design ?

If GTPOWERGOOD is not asserted after board power-up, please see AR#72746  for a work-around.

Thanks & regards
Leo

[auricm]

Hi @karnanl 

I'm using vivado 2019.1, the pin you highlighted after the power up is stable at high level.

I can also see the correct frequency 156.25MHz coming out from gt_reflck_out.

regards

[florentw]

Hi @auricm 

If the 2 IPs are on different quads then I do not think there is one controlling the logic the other is trying to use.

The main check I would start with is timing. Can you confirm your design meets timing?

Did you check that your design is following the UFDM guide? Refer to the following articles:

https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/Using-the-Methodology-Report-Part-One-Timing-is-Met-But-Getting/ba-p/1154790

https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/Using-the-Methodology-Report-Part-Two-Effect-of-Methodology/ba-p/1158046

https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/Using-the-Methodology-Report-Part-Three-Timing-is-met-but-there/ba-p/1160250 

[auricm]

Hi @florentw 

after synthesis and implementation, I don't see timing errors or warnings based on the Xilinx IP, 

Anyway, I expect to see a clock coming out of the IP block even if there are timing violations, that's why I asked if it's possible that another IP configures in some way another quad.

I will try read and try the articles you linked.

[auricm]

Hi @karnanl, @florentw 

After using the workaround AR#72746 the design started working but... as I added another block into my design the situation is again a stuck quad, no way to make it work.
Does this new situation address the problem on something else?
Thank you for your support

Regards

[karnanl]

Hello

>as I added another block into my design the situation is again a stuck quad, no way to make it work.

1. What is the IP you added in your design ?
2. What is the failure behavior you observed on your HW ?
3. Is the timing met ?
4. Also, is there any Critical warning in your implementation result ? ( Did you try to run report_methodology and report_drc in your design ?)

Thanks & regards
Leo

[auricm]

Hi @karnanl 

I added some fifos and a few hdl blocks, the behavior is always the same, no user clock output.
No timing issues with the ethernet IP.

At the moment the issue seems to be solved writing a small vhdl component that reset the 10G ethernet IP every 20ms if no clock is coming out.
Thank you for your support and hints.
Regards

[florentw]

HI @auricm 

When looking for timing issue we need to know about the full design no only the specific IP.

I would also make sure you are not over or under constraining your design. So make sure all the constraints of your design make sense

[auricm]

Hi @florentw 

After two weeks of testing, I consider the problem solved with the "repeated" reset, as far as I tested seems that only one reset is enough.

Now the reset sequence is the following:
1. Power up, reset is de-asserted
2. setup of the external clock source with reset de-asserted
3. as the clock source is stable assert the reset and de-assert.
4. if there's no clock coming out assert the reset periodically

There are some timing constraints that are not met but they are present between Xilinx IP, so I can't touch anything.

This transceiver behavior can be due to hardware power supply problems?

I'm using a third part board so I can't debug the hardware as I don't have schematics of the power section.

Regards

[florentw]

HI @auricm 

Yes this can be due to HW problem. For example if the power section is not able to handle the spike caused by a reset.

Are you reseting both IP at the same time? Maybe that would help to reset them one by one

[auricm]

Hi @florentw 

I reset only the 10GbE IP (both the tx and rx at the same time), not the HDMI.
I'm not able to access the decoupling capacitors of the transceiver or the power supply, I can't verify if there's something
Thank you

Regards