PL only clock (pin H16) in PYNQ-Z1 (or ARTY Z7) from ethernet PHY not stable ?

[Prabhat.kumar]

Hi,

I am trying to do PL only designs first on my PYNQ Z1 board. This board is functionally equivalent to boards like ARTY Z7 or ZYBO(only pin change here). I see there is a clock coming from ethernet PHY (CLK125) and being fed to the clock input of the PL side. I have seen at some places that this clock is not stable and resets around every 2s in absence of a valid ethernet connection. I wish to see this for myself, is there any way I can probe somewhere and see that this signal is being lost? If we just blink the LEDs, then there is chance that the clock recovers during the LED off period and that I will not be able to view the resetting behavior of this clock. I can't probe the 125MHZ signal, since I don't have a scope with that much bandwidth. I just wanted to ask a method in which I can see this misbehavior.

Now, coming to second part, how do I fix this issue ? I want to stay away from PS section for now. I saw one post (can't locate it now) where we just use PL fabric clocks generated from the PS and then use some tcl scripts to initilaize the PS, so that we don't need to deal with the SDK everytime we make changes to the code. Can someone please guide me on this issue and help me achieving my purpose with the lowest amount of hassle of dealing with the PS.

Thank you

Edited March 6 by Prabhat.kumar

[zygot]

Even though the Ethernet PHY is connected to the MIO pins, and not PL pins, these boards to connect the PHY CLKOUT pin to a PL pin.

Some Ethernet PHYs do have energy conservation designs that shutdown portions of the PHY when there is no activity on the receiver. Depending one the PHY, This behavior might be altered by changing certain registers in the PHY using the serial interface.

So, can one detect a condition where the PHY CLKOUT signal is not toggling using PL resources on one of these boards? I can't think of a reason why not. The solution just might be a bit more complicated than you envision.

There are ways to use a ZYNQ based FPGA board without any PS connectivity so that you can implement a logic design. One could make the case that having a minimal connection to the PS might be useful; for getting additional clocks into the PL for instance. Edited March 5 by zygot

[Prabhat.kumar]

13 hours ago, zygot said:

Even though the Ethernet PHY is connected to the MIO pins, and not PL pins, these boards to connect the PHY CLKOUT pin to a PL pin.

Some Ethernet PHYs do have energy conservation designs that shutdown portions of the PHY when there is no activity on the receiver. Depending one the PHY, This behavior might be altered by changing certain registers in the PHY using the serial interface.

So, can one detect a condition where the PHY CLKOUT signal is not toggling using PL resources on one of these boards? I can't think of a reason why not. The solution just might be a bit more complicated than you envision.

There are ways to use a ZYNQ based FPGA board without any PS connectivity so that you can implement a logic design. One could make the case that having a minimal connection to the PS might be useful; for getting additional clocks into the PL for instance.

Hi, thanks for the reply. So I did find a way to check the resetting behavior of the clock. I initialised a MMCM and generated a another clock, and in the clocking wizard, I selected 'locked' and 'input_clk_stopped' and mapped these to some pins on the board and probed them with a scope. If there is to be a input clock(ethernet PHY) failure, then, 'input_clk_stopped' would have gone high and 'locked' would have gone low. However, I was not able to catch such scenario even in single shot events on scope.

I believe this proves that the clock is continous. Please leave your valuable suggestions and also point out any errors in my testing.

Thank you

[zygot]

Perhaps I'm reading too much into your use of the words "failure", "resetting", "proves", "valid Ethernet connection", etc..

- Don't assume that all Ethernet PHYs behave the same.
- Clocks can assume a quiescent state for a variety of reasons. That doesn't necessarily imply a reset or failure of some kind. Sclk in an SPI interface is and example of a clock that is only active during periods of data transmission. In Series7 FPGA devices internal clock signal can be driven with a clock buffer having an enable in order to put sections of logic into a quiescent state and save power dissipation.
- the behavior of the PHY on your board might change depending on what kind of PHY it's connected to.
- All PHY interfaces provide transmit and receiver error signals, though none are as simple to extract as the GMII interface.
- The method that you chose to detect an absence of the PHY CLKOUT signal might be sufficient. Don't be too anxious to declare victory and move on. You might want to devise a second, more complex logic design to detect an absence of CLKOUT transitions.

It wouldn't hurt to read the datasheet for the PHYs that you are working with. Not all Ethernet PHY vendors provide this documentation without an NDA. But one can get insight by reading OS driver code or other available information.

All in all this is a good exercise and potential learning experience.