Forum Discussion

rt52's avatar
rt52
Icon for Occasional Contributor rankOccasional Contributor
5 years ago

TSE IP core on MAX10 not working

I have a custom board with a MAX10 and 2 TI DP83869 PHYs that are meant to transfer ethernet data from one PHY to the other through the MAX10. However, I cannot seem to get data to appear from the input PHY on the MAX10. I have a UART module that reads the MAC and PHY registers from the IP core and outputs them to the terminal and none of the counting registers update, even when sending UDP packets to the board.

It is based on the ethernet pass-through design on the MAX10 FPGA dev kit that uses tcl scripts to configure all of the MAC and PHY registers. I am not able to use tcl on my custom board, so all register configuration is done in verilog, in a state machine. These seem to work ok, as the UART output reads back all of the correct values, but no evidence of data coming is there.

I have the simulation working fine for this, and it worked on the dev kit hardware, but moving to my board with a different PHY seems to have broken something. I verified all external clocks and MDIO/MDC seems to be working as well.

I am at a loss to what is going on, so any help with properly interfacing with a different PHY than the dev kit or anything else that might seem wrong is appreciated.

If at all possible, would anyone have a direct translation to verilog of the tcl from the ethernet pass-through?

Thanks

12 Replies

  • SengKok_L_Intel's avatar
    SengKok_L_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi,


    1) Is the state machine that used to configure the MAC and PHY already validated by using Development kit before you port over to the new board?


    2) To ruled out if this is FPGA or PHY not configure properly, you can perform the MAC Loopback test. See section 4.1.9 in the following user guide.

    https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_ethernet.pdf


    3) Do you follow the TI PHY datasheet to configure it via the MDIO interface?


    Regards -SK


    • rt52's avatar
      rt52
      Icon for Occasional Contributor rankOccasional Contributor
      5 years ago

      1) Yes, I have successfully passed data using the dev board, although none of the statistics registers in UART updated, only when running stats_chk in the system console when running the tcl scripts.

      2) I set up local loopback by writing x803B to command config reg, but I still do not see any status registers changing.

      Also tested a form of PHY loopback test by directly connecting the RGMII rx signal to the RGMII tx signal in the MAX10 and using signal tap to verify that they were the same. So it looks like our PHY does

      3) I should have mentioned that the PHYs are programmed via hardware strapping for the correct modes, RGMII to copper and RGMII to 1000Base-X and most of the configuration is done by that. I am able to write to the PHY, for example to set the activity and data LED signals to the proper mode, but all other settings should be done via the strapping.

  • SengKok_L_Intel's avatar
    SengKok_L_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi,

    Thank you for the reply.

    1. Do you initial a pattern generator to transmit the data when perform the local loopback test (e.g Pattern Generator -> TX -> Local loopback -> RX)?
    2. Is the local loopback work well in dev kit, but not your custom board?
    3. When perform the local loopback test, did you check the TSE IP Avalon ST interface? Are there any activities (both TX and RX)?
    4. If you suspect this is external PHY issue, I would suggest you to contact the third party vendor to advice.

    Regards -SK


    • rt52's avatar
      rt52
      Icon for Occasional Contributor rankOccasional Contributor
      5 years ago

      1) I am not sure where to find the pattern generator. Would I have to make one myself or is there one I could use? I did not see anything in the datasheet regarding that.

      2) I will have to try that, but if the packet generator is an issue, I would guess not.

      3) So I interrupted the pipeline latch that connects one MAC to the other and viewed in signal tap and saw I had data coming out of of the first MAC, but I still did not see any status registers update from my UART module. Could you think of any reason why the status register would not update? I have them enabled in the platform designer instantiation.

      4) I am in contact with the PHY manufacturer trying to tackle this issue from both sides

      Thanks

  • SengKok_L_Intel's avatar
    SengKok_L_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi,


    You may refer to the following design example for MAX 10, it consist of the pattern generator for ethernet packet.

    https://fpgacloud.intel.com/devstore/platform/18.0.0/Standard/max-10-single-port-triple-speed-ethernet-and-on-board-phy-chip-design-example/


    It look like there is another problem in your system design with UART that unable to update the statistics register, but it work well in TCL scripts.

    The UART is not working in both dev kit and custom board, If this is only the statistics register not update correctly, but other registers are okay. I would suggest you to double check your code, to ensure the address are assigned correctly, and double check if you turn on the “include statistics counters” from the TSE IP.


    Regards -SK


    • rt52's avatar
      rt52
      Icon for Occasional Contributor rankOccasional Contributor
      5 years ago

      Looking at the example design, I see other components in the platform designer that I don't have in mine, like eth_gen and eth_mon. I will see about adding those back in to get loopback going, thanks.

      Yes, I can read/write the registers that are read/writable, but the read only statistics counters don't update.

      The register address for the statistics counter are correct and match the datasheet and the "include statistics counter" option is checked in platform designer.

  • SengKok_L_Intel's avatar
    SengKok_L_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi,

    Assuming the UART update is correct. If you don’t see the TX statistics counter is increasing, it look like there is no data sending out from the TX interface. I would suggest you to capture the signal tap to confirm if this is true, and you might also need double check your system to confirm there is a proper clock connection.

    Regards -SK


    • rt52's avatar
      rt52
      Icon for Occasional Contributor rankOccasional Contributor
      5 years ago

      I broke open the pipeline latches that connect the 2 MACs and did a signal tap read on the avalon bus coming from RGMII, but still nothing on the uart. If this is the case, I would at least expect the error counters to update.

      Yes, that was my next thing to check. I have multiple clocks feeding everything. The IP core and all of my logic (including mac register write, read and uart) are on 50Mhz, the FIFOs are running on 100Mhz, and the platform designer instantiations are running on a 125Mhz, with the RGMII tx on a shifted 125Mhz. Do you notice anything off with that?

  • SengKok_L_Intel's avatar
    SengKok_L_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi,

    If there is packet appear at the Avalon ST TX side, then you may perform a MAC loopback test, and determine if the packet can loopback to the Avalon ST RX side. If not, it could be something wrong in your design or clock system. Are you running at 1Gbps? What is the FIFO data width?

    Just to confirm, if using TCL script, the statistic counter is update correctly?

    Regards -SK


    • rt52's avatar
      rt52
      Icon for Occasional Contributor rankOccasional Contributor
      5 years ago

      Ok, I am working on getting the eth_gen and eth_mon modules in my project, I will try the loopback when I have finished.

      1 Gbps is the desired speed, and I am configuring the mac registers for this. The fifo data width is 32bits.

      Yes, when the design is on the dev board, and the stats_chk script is executed, I see the statistics counters incrementing when traffic is sent through, but nothing from my uart.

  • SengKok_L_Intel's avatar
    SengKok_L_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Thanks for the update. It sound like there is something wrong in the UART that you might need to debug further.


  • SengKok_L_Intel's avatar
    SengKok_L_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    If further support is needed in this thread, please post a response within 15 days. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.