Actions
Forum Thread Details
  • State Not Answered
  • Replies 6 replies
  • Subscribers 272 subscribers
  • Views 811 views
  • Users 0 members are here
Related

Picozed 7015 + Carrier Card + Gig SFP

Former Member

Hello All,

I'm attempting to use the Xilinx 1g/2.5g PCS/PMA to connect a Finisar SFP module in the SFP slot of the carrier card to the PS GEM1 on a Picozed 7015. My design is similar to that of xapp1082 but adapted to the picozed.

I'm using Vivado 2015.2, and a new picozed 7015 and carrier card.

The carrier card has been configured to output a 125Mhz clock (mgtrefclk1). The independent clock for the core is being provided by the PS oscillator (200MHz). Both clocks have been verified by externally connecting a scope.

I've been working on this for several weeks and am encountering a persistent issue where the transceiver GTP PLL0 fails to stay locked ONLY when the SFP is inserted in the slot.

I originally thought the core was sending a reset signal to the PLL so i implemented the PLL in the example design and removed the reset connection between the PCS/PMA and the PLL and tied it to gpio so that I could manually reset the PLL. In this configuration, I can reset the PLL and it is again stable until the SFP is inserted, at which point the PLL locked signal will begin to toggle.

I have 2 carrier cards and 2 picozeds, and this behavior is exhibited on both.

I've also got several SFP's. The finisar copper sfp's cause the pll to disconnect instantly upon being connected. (or the pll never maintains a lock if the sfp was in the slot when the board was powered on). The finisar fiber (850nm) sfp's can be inserted without disrupting the lock but will once an optical input is tied to the sfp rx port, then the lock will be lost. I have dozens of SFP's and I've connected several different ones and the behavior is the same with every one I've tried.

At this point, I'm wondering if anyone out there has managed to use the SFP port on the carrier card (I can't possibly be the first?!). I'm a computer programmer and relatively new to FPGA design and I therefore don't discount the possibility that there may be a flaw in my bitstream.

Any wisdom would be appreciated. 





Parents
  • 0

    Hi there Mark,

    First, thanks for being thorough.  It helps as I cannot be there with you to see everything.
    Second, I do not recommend connecting the SFP modules WHILE the system has power.  I personally have never done that.
    Third, it seems to me that the clock is probably not correct.  The MGTREFCLK0 will ALWAYS have a clock on it.  When the IDT 874003 has no input clock (your situation) it will still run and generate a CLOCK.  Depending on how SW8 is setup, you are probably generating 250MHz, which is the default factory configuration.  Since you followed my guide, I had you set everything up for 250MHz.  I find it strange that you are not getting 250MHz after matching the configuration that was recommended.  Can you double check the SW9/SW10 setup?  with the PCIe card edge nearest you, you should see CLOSE/OFF; CLOSE/OFF ; CLOSE/OFF; AWAY/ON; AWAY/ON; CLOSE;OFF.
    There is an image in section 2b on page 17 of the IBERT documentation.

    I am glad that you have ordered a SFP Loopback adapter, that will remove questions about the Verilog modifications.  Another way to remove this question, a few days ago, the IBERT reference designs were updated to REV 1.1.  This now includes a scripted method to configure the IBERT design.  You basically download the GIT repository, extract, open Vivado, run the appropriate command (see documentation) -  then the scripted environment does everything else, including file manipulation and JTAG.

    The reason I am circling back to the clock is looking over your procedures above...you claim to have loopback running without issue when using MGTREFCLK0 (which as I said should be defaulting to 250MHz).  Assuming you have the same IBERT image, just changing ONLY the clock input field (see #13 on page 11) there is no reason the IBERT would not run just as well for either.  Also, make certain that you are setting the System clock to using the Quad 112 clock, although if that were the issue, you would probably have a non-working IBERT using MGTREFCLK0 and 1.

    Can you tell me what the @3.111GHz number is from?  Is that from what Vivado is telling you it is seeing as a recovered clock?  What number do you see in the Status column?

    This statement also bothers me: "all xcvrs in near-end pma loopback, pll locked"  If the PLL is locked, with near-end PMA it should be working.  When in this situation, have you tried near-end PCS?  That is digital ONLY and will validate the image is working as expected (clocks, data shifters, as well as other logic).  When in this situation, have you tried to click the RX Reset button?  There are a few troublshooting tips in Video 103 near 3:45 or so.  Also some details about WHAT you can expect to see to KNOW that everything is running AOK.

    A quick note, I'm not sure if you have changed any of the bank voltages when using your PicoZed 7015 SOM, but remember that the PicoZed 7030 is a 1.8V device!  If you have CON2 set to anything but 1.8V or disconnected (no jumper) you will damage your ZC7030 based SOM!!

    --Dan

Reply
  • 0

    Hi there Mark,

    First, thanks for being thorough.  It helps as I cannot be there with you to see everything.
    Second, I do not recommend connecting the SFP modules WHILE the system has power.  I personally have never done that.
    Third, it seems to me that the clock is probably not correct.  The MGTREFCLK0 will ALWAYS have a clock on it.  When the IDT 874003 has no input clock (your situation) it will still run and generate a CLOCK.  Depending on how SW8 is setup, you are probably generating 250MHz, which is the default factory configuration.  Since you followed my guide, I had you set everything up for 250MHz.  I find it strange that you are not getting 250MHz after matching the configuration that was recommended.  Can you double check the SW9/SW10 setup?  with the PCIe card edge nearest you, you should see CLOSE/OFF; CLOSE/OFF ; CLOSE/OFF; AWAY/ON; AWAY/ON; CLOSE;OFF.
    There is an image in section 2b on page 17 of the IBERT documentation.

    I am glad that you have ordered a SFP Loopback adapter, that will remove questions about the Verilog modifications.  Another way to remove this question, a few days ago, the IBERT reference designs were updated to REV 1.1.  This now includes a scripted method to configure the IBERT design.  You basically download the GIT repository, extract, open Vivado, run the appropriate command (see documentation) -  then the scripted environment does everything else, including file manipulation and JTAG.

    The reason I am circling back to the clock is looking over your procedures above...you claim to have loopback running without issue when using MGTREFCLK0 (which as I said should be defaulting to 250MHz).  Assuming you have the same IBERT image, just changing ONLY the clock input field (see #13 on page 11) there is no reason the IBERT would not run just as well for either.  Also, make certain that you are setting the System clock to using the Quad 112 clock, although if that were the issue, you would probably have a non-working IBERT using MGTREFCLK0 and 1.

    Can you tell me what the @3.111GHz number is from?  Is that from what Vivado is telling you it is seeing as a recovered clock?  What number do you see in the Status column?

    This statement also bothers me: "all xcvrs in near-end pma loopback, pll locked"  If the PLL is locked, with near-end PMA it should be working.  When in this situation, have you tried near-end PCS?  That is digital ONLY and will validate the image is working as expected (clocks, data shifters, as well as other logic).  When in this situation, have you tried to click the RX Reset button?  There are a few troublshooting tips in Video 103 near 3:45 or so.  Also some details about WHAT you can expect to see to KNOW that everything is running AOK.

    A quick note, I'm not sure if you have changed any of the bank voltages when using your PicoZed 7015 SOM, but remember that the PicoZed 7030 is a 1.8V device!  If you have CON2 set to anything but 1.8V or disconnected (no jumper) you will damage your ZC7030 based SOM!!

    --Dan

Children
  • 0 in reply to drozwood90

    I made you a video:

    https://youtu.be/RpVUA37LX58

    I want to stress that I've obviously attempted doing the ibert test from a fresh bootup of the board and restart of Vivado without making changes to the pll. I've now followed your video through a few times and even tried loading the files (that was a while back). I'm confident that I've followed the instructions properly. jumpers are configured (with pcie edge connector facing downwards) SW8: all down(off)  SW9: all down(off) SW10 down, up, up, down -- but as you stated, the improper configuration of these jumpers would likely lead to a different clock speed but, you'd think, that it would still come up in an ibert loopback unless it created a rate that was completely out of range.

    I also tried near-end PCS. I wish I had also recorded that behavior on the video but it took my phone a while to upload it over wifi - in that mode, links come and go with the GTREFCLK1 clock source and errors are present on all ports - but unlike "near end pma", the links will actually connect.

    When I play with the pll0 properties while its on GTREFCLK0, its really robust and works as expected... i.e. changing the divider properties and resetting the tx/rx results in an expected change in rate and the connection re-establishes itself. On GTREFCLK1, it always works badly, but some settings yield better connectivity the others. A 7 bit pattern tends to stay connected more than a 31 bit etc...

    I went into the properties and removed the powerdown flag from pll1, reset it and attached it to gtrefclk1 then tried moving the rx+tx for a single channel to pll1 - pll1 worked the same way as pll0, stable on GTREFCLK0 and unreliable on GTREFCLK1.

    Also, thanks for the heads up on the 1.8v - had already decided to go to 1.8v in case we moved to the 7030.

    Warm Regards,
    Mark