Arty A7 25MHz device for Ethernet

[dbkincaid]

I would like to utilize an external clock for Ethernet.  The 25MHz clock chip has an existing footprint on the board. 

What is a suitable device to order for this purpose?  

Edited June 9, 2023 by dbkincaid
tags

[asmi]

2 hours ago, zygot said:

BTW, it's not clear as to what you are referring to in your reference to "The 25MHz clock chip has an existing footprint on the board. ".

I suspect he means exactly what it sounds like. There is a footprint for 25 MHz crystal (not clock chip) X1, as well as two load caps (C114 and C115), which are not actually placed, and a zero Ohm resistor R201 which will need to be disconnected if crystal is to be installed. So if you install X1, C114 and C115 and remove R201, you can make PHY work off that crystal without having FPGA to provide clock. Not sure why one would want to do that, but it is possible.

[zygot]

It makes a big difference if you are talking about the Arty A7-35T or the 100-T versions.

Is there a reason why you'd want an external clock for a low speed Ethernet PHY?

Fortunately, the Arty A7 seems to have a number of clock-capable pins connected to PMOD headers.

BTW, it's not clear as to what you are referring to in your reference to "The 25MHz clock chip has an existing footprint on the board. ".

[dbkincaid]

On 6/9/2023 at 3:54 PM, asmi said:

I suspect he means exactly what it sounds like. There is a footprint for 25 MHz crystal (not clock chip) X1, as well as two load caps (C114 and C115), which are not actually placed, and a zero Ohm resistor R201 which will need to be disconnected if crystal is to be installed. So if you install X1, C114 and C115 and remove R201, you can make PHY work off that crystal without having FPGA to provide clock. Not sure why one would want to do that, but it is possible.

Yes this is what I want to do.  The reason to use external 25MHz clock is to decouple the PS/Fabric clock subsystem from the (precise) 25MHz needed for the Ethernet device.  

[dbkincaid]

On 6/9/2023 at 1:18 PM, zygot said:

It makes a big difference if you are talking about the Arty A7-35T or the 100-T versions.

Is there a reason why you'd want an external clock for a low speed Ethernet PHY?

I am asking about Arty A7-100T

Yes, I want to decouple the clock subsystem from the precise 25MHz needed for Ethernet PHY.  As it is designed, the entire clock tree has to be constrained to multipliers that can source a precise 25MHz as an output.  It also burns a clock route, and adds constraints I'd rather not fuss with in fabric.

Make sense?

[zygot]

52 minutes ago, dbkincaid said:

As it is designed, the entire clock tree has to be constrained to multipliers that can source a precise 25MHz as an output.  It also burns a clock route, and adds constraints I'd rather not fuss with in fabric.

I do a lot of designs using Ethernet connectivity.

Yes there are situations where the MMCM/PLL design runs into issues with competing clocking requirements. One such case is when you have a lot of clock domain requirements for external interfaces, such as video and MIG/DDR3 and USB in a design. Fortunately, the overall clocking resources in a device like the Artix A100T allow you to overcome such obstacles. For instance, you can use clock4 out of one MMCM as a source for a secondary MMCM. If you choose your MMCM setup carefully, you can pretty much work out a way to resolve these issues. Sometimes an interface requires an odd clock frequency that you can't achieve from a standard 100 Mhz external clock source; but generally the solution is a second external clock source. One thing lacking in Digilent's FPGA boards is a programmable external clock module. For some platforms is this an annoyance. For other platforms this is an unforgivable board design flaw. What you are doing is opting for a low quality oscillator as an external clock source instead of a higher quality external clock source. You are free to do that if you want to but it's not an optimal way to do things.

As for constraints, I'd suggest getting proficient at adding these into your designs. As Vivado wants to control constraint management the tool is a impediment to this. If  you are doing  the HDL design flow, then you can control this vital part of the design process. The more control you have as opposed to letting the tool manage aspects of a design project the happier you will be for complicated project that need to survive years of life span. It's more work to assume responsibility but the alternative eventually just doesn't work.

Edited June 19, 2023 by zygot

[asmi]

1 hour ago, dbkincaid said:

Yes, I want to decouple the clock subsystem from the precise 25MHz needed for Ethernet PHY.  As it is designed, the entire clock tree has to be constrained to multipliers that can source a precise 25MHz as an output.  It also burns a clock route, and adds constraints I'd rather not fuss with in fabric.

Make sense?

Not really because as per specification MII's RX_CLK can be recovered clock or reference clock, and PHY can switch between them during runtime - see IEEE 802.3, clause 22.2.2.2. So you can not presume that RX_CLK is going to be the same as TX_CLK - you still need to have separate clock domains for transmission and receiving, unless you want to go with oversampling route.

Edited June 19, 2023 by asmi

[zygot]

2 hours ago, asmi said:

So you can not presume that RX_CLK is going to be the same as TX_CLK

Absolutely. Ethernet interfaces have 2 separate clock domains. I'm not sure that this is what you are attempting to simplify, but if it is, you can't.

Even for a 10/100 Mb/s Ethernet PHY interface you need to provide proper timing constraints if you want a reliable interface. Actually, it's good practice to supply proper constraints for all IO, even if it doesn't seem necessary. For trivial learning endeavors you can pretend that this isn't a necessary step in the design process, but as your designs get more complex and use a high percentage of the FPGA resources the illusion that what's running on hardware is representative of simulations disappears.

More importantly, you cannot treat the Ethernet PHY Rx and Tx clock domains as related clocks.

Edited June 19, 2023 by zygot

[asmi]

12 minutes ago, zygot said:

Absolutely. Ethernet interfaces have 2 separate clock domains. I'm not sure that this is what you are attempting to simplify, but if it is, you can't.

I'm not an OP. And I'm also not sure why would someone want to do what he intends to.

13 minutes ago, zygot said:

Even for a 10/100 Mb/s Ethernet PHY interface you need to provide proper timing constraints if you want a reliable interface. Actually, it's good practice to supply proper constraints for all IO, even if it doesn't seem necessary. For trivial learning endeavors you can pretend that this isn't a necessary step in the design process, but as your designs get more complex and use a high percentage of the FPGA resources the illusion that what's running on hardware is representative of simulations disappears.

For 25 MHz you can use 4x oversampling to find a good sampling point dynamically - you take 4 samples of a clock line at 100 MHz, find clock transitions (where sample goes from 0 to 1 and back) and determine which of those four is the best sampling point for data lines. This way you don't need any IO constraints assuming your data lines and clock are somewhat evenly matched (and for 25 MHz even centimeters of difference in length is accepted).

[zygot]

1 hour ago, asmi said:

For 25 MHz you can use 4x oversampling to find a good sampling point dynamically - you take 4 samples of a clock line at 100 MHz, find clock transitions (where sample goes from 0 to 1 and back) and determine which of those four is the best sampling point for data lines. This way you don't need any IO constraints assuming your data lines and clock are somewhat evenly matched (and for 25 MHz even centimeters of difference in length is accepted).

Asynchronous design is often a fine approach up to a point. For 10 Mbps SDR serial data this might even be preferred as suggested by the quote above. If you can control timing by design, rather than by constraints it's usually a good way to go, though you may run into portability issues using a wide range of programmable devices. For RGMII interfaces the asynchronous approach is going to become problematic, especially for 100/1000 Mbps. In general, I'd want to stick with the synchronous design approach for Ethernet interfaces. It's one way to conceptually maintain a common design approach to an interface that has a lot of variation in the PHY logic interface. For something like SPI, with a limited variation of the PHY level interface I take it on a case by case basis depending on the SCLK frequency.

If you are clever you can take whatever design approach you want; as long as you don't violate or ignore fundamental digital design concepts, especially when dealing clock domain crossing logic, or fail to understand how the external hardware that you want to connect to your design works.

Edited June 19, 2023 by zygot

[asmi]

Asyncronous designs have advantages - no need for separate clock domains, they can be made very toletant to lousy PCB routing as it's possible to implement per-line deskew, and in some cases it's the only way - like with high-speed (400+ Mbps) LVDS receivers, because it's impossible to do a static capture at such high speeds, also since they don't rely on IO constraints, they tend to be somewhat easier to port to other vendors' devices (because constraints syntax is different for each vendors).

As for RGMII - I think it should be possible to do an oversampling design using ISERDES primitives, but I haven't tried that personally, so I don't know for sure. One potential problem I see is that receive clock is not monotonous, so you would have to "re-learn" sampling point on each receive transaction, which, again, is possible, but I'm not sure if it's worth the trouble. I personally prefer doing it "by the book" whenever possible, and only invent "clever" ways when standard ones don't work for one reason or another.

[zygot]

4 hours ago, asmi said:

Asyncronous designs have advantages - no need for separate clock domains, they can be made very toletant to lousy PCB routing as it's possible to implement per-line deskew, and in some cases it's the only way

I completely agree with that argument. There's a price to pay of course; some of your logic needs to be clocked at at 4x - 8x the maximum toggle rate of the signals that you are sampling. This isn't usually a big deal, especially if you can leverage something like ISERDES. How much over sampling you need depends on a number of factors. Some FPGA devices, notably the Cyclone devices from Intel have artificially limited clock network frequencies to push customers toward more expensive devices and annual tool subscription expenses.

If the transmission line between the source and receiver is of poor quality a simplistic implementation of oversampling might not work out well. This shouldn't be the case with components on a fabricated PCB. If your source goes through a PMOD, then that's another story. Overshoot/undershoot does bad things to digital logic.

For compensation of line length mismatch there's always IDELAY. It's a shame that Series 7 devices don't have output delay compensation. Earlier devices had both.

All of this discussion might be a bit much for someone thinking about operating an entire design from an Ethernet reference clock, if that was your intent. But at least you have some ideas to work with. We've come a far ways from answering your original question, but I suspect that it's all the better to get answers that are off-topic but more germane to getting your project implemented correctly.

 

Edited June 19, 2023 by zygot

[asmi]

13 hours ago, zygot said:

I completely agree with that argument. There's a price to pay of course; some of your logic needs to be clocked at at 4x - 8x the maximum toggle rate of the signals that you are sampling. This isn't usually a big deal, especially if you can leverage something like ISERDES

That's not neccesarily the case. Take a look at XAPP523 - it shows how to do 4x oversampling using 4 phases of the clock which is the same as a bit clock. It's a pretty neat trick I gotta say, unfortunately it seems that this is not possible on later generations of their FPGAs.