Actions
Forum Thread Details
  • State Not Answered
  • Replies 11 replies
  • Subscribers 339 subscribers
  • Views 1060 views
  • Users 0 members are here
Related

PicoZed / Carrier Ethernet PHY RXC Routing

chailatte

Hi folks,


Thinking I've encountered a concern regarding the routing of the Rx Clock on the Ethernet PHY on the PicoZed FMCC Carrier Card, and wanting to turn it over to some other eyes to confirm or refute.


I'm preparing to use the Carrier Card to prototype a gigabit ethernet connection driven by logic on the Zynq PL of a PicoZed card, instantiating the AXI Ethernet Block (R6.2).  (Need to support jumbo frames, which precludes using a MAC of the PS.)


From the schematics of PicoZed and FMCC carrier, I trace the RXC receive channel clock of the Marvell PHY on the carrier through JX2 pin 94 to pad V11 of the Zynq 7020.  But since V11 is not an MRCC or SRCC pin, Vivado (rightfully, I believe) complains vociferously at its inability to successfully route the design.


On further study of the schematics, I find the a nearby JX2 connector pin 74, which does route to an SRCC pin, in the same I/O bank 13 as the other signals of the PHY interface.  It is labeled IO_L14P_T2_SRCC_13 on the Zynq, bonded to pad Y9, and makes the implementation tools much much happier.


But before I turn the carrier card over to our tech folks for the minor surgery needed to reroute the PHY's RXC output through JX2.74, I thought I'd check with the group to see if anyone could confirm (or otherwise comment upon) both:
1) my reading of the documentation; and
2) its accuracy.


In case it matters, the carrier card I have is labeled MBCC-PZCC-PCB-C, 1450043.


Many thanks,


Joseph

  • 0

    We can confirm that what you have found is accurate. We did not catch this in our testing as we were using the 2nd Ethernet PS peripheral. Sorry for the inconvenience. We will look to change this on the next revision. Please let us know how your rework goes. Thank you for bringing this to our attention.

    Bryan

  • 0

    We are experiencing similar timing problems due to the RX clock pin assignment, when using the GMII to RGMII IP.

    In addition the latest PicoZed Carrier constraints file (Apr 2nd) sets Bank 13 to LVCMOS33. 3V3 is not a supported RGMII voltage signal level for Xilinx 7 series devices. See Table 4-1 on page 42 of the GMII to RGMII v3.0 (PG160) data sheet.

    http://www.xilinx.com/support/documentation/ip_documentation/gmii_to_rgmii/v3_0/pg160-gmii-to-rgmii.pdf

    Bryan: Is there an example available which successfully routes both PS Ethernet ports to the PicoZed carrier?

    Thanks,
    Chris

  • 0 in reply to Former Member

    The RGMII using a 3.3V bank is one of the things listed in the Errata that we just posted. You are correct that it is outside the specification provided by Xilinx. I am working on getting a better explanation from Xilinx as to why that requirement exists. In spite of this, we have tested this 2nd Ethernet port with sustained data rates of 800 Mbps.

    We are working on a dual Ethernet example, but we are still several weeks away from having that ready. You may be able to get some assistance from your local Avnet FAE.

    Bryan

  • 0 in reply to bhfletcher

    Looking over Bank 13, it looks like the choices to get access to a clock-capable pin are JX1.87 (ETH_TXD0), JX1.88 (ETH_MDC), JX3.73 (PL_LED1), or JX3.74 (PMOD1_D0_P). The least risky pins to try are JX3.73 or JX3.74. I think the above message had a typo in JX2.74 that was really meant to be JX3.74.

    I will also admit that I have not tried this myself.

    Bryan

  • 0 in reply to bhfletcher

    Thanks again, Bryan, and yes, typo acknowledged, I'd intended JX3.74.


    Joseph

  • 0

    Is there an example design available for either the external carrier PHY or both PHYs? I have not been able to create a working design using the carrier PHY.

  • 0 in reply to Former Member

    We have a dual Ethernet design that we did with Xilinx in 2014.4. You can request this through your FAE. It used the PS GEM1 through EMIO into PL and a PL shim, then out the PL IO. This passed timing and worked reliably. The only rework required was changing the PHYAD for the PHY on the Carrier to a '1'. The RX_CLK is not a problem with this design.

     

    Creating the 2nd Ethernet interface using a MAC in the PL causes problems. In this case, RX_CLK does need to come in on a clock-capable pin. The only way to accomplish this is by reworking the Carrier. Of course, adding an external wire for your clock is not ideal.

     

    So, if you can make use of PS GEM1, I think this will work. If you need a PL-based MAC, then unfortunately, I think the best advice may be to prototype with another board temporarily until we can get a new PicoZed Carrier to market. One option would be a MicroZed with MicroZed FMC Carrier along with the Opsero Quad GigE FMC Card (www.ethernetfmc.com).

     

    Bryan

  • 0 in reply to bhfletcher

    I am about to try a design using both Ethernet ports and would like to have a look at the above mentioned solution. However I have no idea of how to contact an Avnet FAE to get my hands on it.

  • 0

    I would suggest a cleaner approach would be to use the Ospero Quad GigE FMC Card ( http://ethernetfmc.com/ ) with either a ZedBoard, a MicroZed with the MicroZed FMC Carrier Card, or a PicoZed with the soon to be released PicoZed FMC Carrier Card V2. Either of these options would provide for a solution that does not require reworking a board and has the correct routing and signal assignments. In addition there is a supported reference design on the ethernetfmc.com site for the Zedboard that should be easy to move to one of the other platforms.

     

    -Gary

  • 0 in reply to Former Member

    Gary,

    I have a carrier card of my own design and I am in the process of designing another card however in this design the end user would like to have 2 ports. For the first design, which had 1 port, I simply routed the PHY outputs coming from the Picozed to magnetics on the board. The design works fine. For the rework I was planning on using the same setup that is currently on the V1 carrier card for the second port. The end user will have GME1 from the PS available so in theory if I duplicate the design of the carrier card and the PS TEMAC is used then there should be no problem. But, since I am redoing the board and can simply rout the RXclk to a compatible pin that is what I will do. Does this sound correct to you?

    My main concern is with the end user. He wants to have a reference design to start with and that is why I would like to have a copy of the working one.

    on a side note in reference to another query above, I believe that the main reason for the 2.5V as opposed to the 3.3V is related to output drive strength and edge timing.