Jump to content
  • 0

Genesys2 Ethernet PHY trace length


stcrana

Question

Hello,

I am trying to use the Ethernet PHY on the Genesys2 card and I need to write the timing constraints for the Xilinx FPGA (the ones provided in the XDC file of the Ethernet IP do not match the PHY timing constraints)

The design configures the PHY in hardware (via strapping resistors) to add 2ns delay to the TXC line (4.7k pull up resistor on PHY pin RXD1) so that the FPGA sends out both clock and data at the same time (+/-0.5ns tolerance). The PHY will then add the 2ns delay to meet setup/hold.

On the receiver side (i.e. PHY out, FPGA In) the PHY is configured for no delay (4.7k pull down resistor on PHY pin LED2). Is the ETH_RX_CLK trace length longer than the RXD/RXCTL traces as suggested in the PHY datasheet (i.e. "This implies that PC board design will require clocks to be routed such that an additional trace delay of greater than 1.5ns and less than 2.0ns will be added to the associated clock signal.") or are these traces matched?

PHY datasheet: https://www.semiconductorstore.com/pages/asp/DownloadDirect.asp?sid=1614664716277

See page 65 for mentioned quote.

Thank you

Link to comment
Share on other sites

10 answers to this question

Recommended Posts

Your question is a very good one and it would be nice if Digilent addressed this for all of their boards with Ethernet PHY interfaces. Unfortunately, they have never presented a good demo using the Ethernet PHY that wasn't MicroBlaze based.

I have been using the Genesys2 and Nexys Video Ethernet PHYs for a few years and they do work.

Link to comment
Share on other sites

Hi @stcrana,

I have asked for the specific trace lengths from our layout engineer.

I do agree that the documentation is inconsistent with the reference manual saying that the there is no delay for TXD and RXD relative to TXC and RXC for data latching, but comparing the Genesys 2 schematic to Table 12 and Table 13 of the datasheet, it looks like there is a 2ns delay for the RX delay (via LED 2) with a 4.7 kOhm resistor to 3.3 V, but the TX Delay / RXD1 has a no load 4.7 kOhm resistor to a 1.5 V line, so I'm hoping to get some accurate information about these details as well.

Thanks,
JColvin

Link to comment
Share on other sites

While looking at this I found an issue in our Genesys 2 reference manual which was not detailing the PHY-internal delays in accordance with the schematic. I hope the revised section makes it clear now: https://reference.digilentinc.com/reference/programmable-logic/genesys-2/reference-manual#ethernet_phy.

You have the RXDLY and TXDLY configuration straps wrong. Also double-check what delays does the MAC in your design introduce. The traces are matched to +-10ps. Package delays would need to be added, but considering a total +-50ps mismatch is conservative enough and will not be hard for the tools to meet.

Link to comment
Share on other sites

48 minutes ago, elodg said:

While looking at this I found an issue in our Genesys 2 reference manual

While you are looking at things to fix with Genesys2 documentation mosey around to the official master xdc constraints file because it has never been correct. FOr JA and JB the differential PMODs the _n and _p pin locations are swapped in the constraints file relative to the schematic. At least the schematic has always been a safe reference. I just got snagged with this recently because I used the current constraints file from Digilent instead of referring to one from one of my old projects that I corrected. Relying on the official constraints will certainly cause some head scratching and heartburn.

Link to comment
Share on other sites

Hi @zygot,

The pin assignments themselves seem to be correct; JA1_P is set to both U27 in the schematic and the .xdc, JA1_N set to U28, etc.

I do agree that the ordering arrangement in the .xdc is confusing with the _N flavors of a pin being listed to the _P version is confusing; is this what you are specifically asking to be addressed (i.e. have them placed in a consistent order in the .xdc, _P before _N)?

Thanks,
JColvin

Link to comment
Share on other sites

@JColvin,

Here is an excerpt form the current Genesys-2-Master.xdc:

## PMOD Header JA

#set_property -dict { PACKAGE_PIN U28 IOSTANDARD LVCMOS33 } [get_ports { ja[0] }]; #IO_L13N_T2_MRCC_14 Sch=ja_n[1]

#set_property -dict { PACKAGE_PIN U27 IOSTANDARD LVCMOS33 } [get_ports { ja[1] }]; #IO_L13P_T2_MRCC_14 Sch=ja_p[1]

#set_property -dict { PACKAGE_PIN T27 IOSTANDARD LVCMOS33 } [get_ports { ja[2] }]; #IO_L12N_T1_MRCC_14 Sch=ja_n[2]

#set_property -dict { PACKAGE_PIN T26 IOSTANDARD LVCMOS33 } [get_ports { ja[3] }]; #IO_L12P_T1_MRCC_14 Sch=ja_p[2]

#set_property -dict { PACKAGE_PIN T23 IOSTANDARD LVCMOS33 } [get_ports { ja[4] }]; #IO_L5N_T0_D07_14 Sch=ja_n[3]

#set_property -dict { PACKAGE_PIN T22 IOSTANDARD LVCMOS33 } [get_ports { ja[5] }]; #IO_L5P_T0_D06_14 Sch=ja_p[3]a

#set_property -dict { PACKAGE_PIN T21 IOSTANDARD LVCMOS33 } [get_ports { ja[6] }]; #IO_L4N_T0_D05_14 Sch=ja_n[4]

#set_property -dict { PACKAGE_PIN T20 IOSTANDARD LVCMOS33 } [get_ports { ja[7] }]; #IO_L4P_T0_D04_14 Sch=ja_p[4]

These location assignments and their order only imply one connection to actual pins Ja[1,2,3,4,7,8,9,10].. When you connect external hardware to the PMOD connector pins it really does matter which ones are ja_n[1] or ja_p[1]. If you have a VHDL port "ja  : inout std_logic_vector(7 downto 0);" in your toplevel design file that match the master constraints ja pin location assignments then you are expecting ja[0] to be on ja pin 1, ja[1] to be on ja pin 2... For the Genesys 2 board that is NOT how they are connected. According to the schematic ja pin 1 is connected to ja_p[1] (ja[0]), ja pin2 is connected to ja_n[1] (ja[1]), ... etc.

So, no the assignments are wrong despite the constraints commentary that does get the schematic names correctly associated with the device pins. Unfortunately, the constraints commentary doesn't do anything except point out the problem. Master constraints files should be as reliable as the schematics. I understand that if you assign the task of creating constraints files to interns who have never done FPGA development could get this confused but in that case their work should be checked. It's a bit frightening to know that a vendor could get something like this wrong because they don't have a testing protocol that actually checks the constraints with a working project and this means testing on actual hardware. This might be the problem as some vendors don't want to take product out of the sales channel. But testing documentation on actual hardware, and testing documentation and demo projects on hardware is a necessary and vital expense if you care for your customers.

Link to comment
Share on other sites

Thanks, since I try to keep my projects updated with the current official support files this would prevent having to run into the same problem over and over. I don't always use the same hardware connectors so I don't always remember to check assignments, especially when I know that I've used the connector for previous projects. Both differential PMODs on the Genesys2 have the same problem. The Genesys2 isn't a board where I'd be wanting to have multiple drivers battling each other on straight wires into the FPGA device risking damage to an expensive ( for me at least ) development platform.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...