Forum Discussion

rshal2's avatar
rshal2
Icon for Occasional Contributor rankOccasional Contributor
7 years ago

How to disable MAC-PHY communication ?

Hello,

I am not sure why do we get "TSEMAC SW reset bit never cleared!" :

We are connecting the FPGA to network switch, (unmanaged switch), so we removed all communication with phy , by disabling MDIO option in TSE in platform designer (appears as: "Include MDIO module").

This is the log when running nios application:

$ nios2-terminal.exe -i 0
nios2-terminal: connected to hardware target using JTAG UART on cable
nios2-terminal: "USB-Blaster [USB-0]", device 1, instance 0
nios2-terminal: (Use the IDE stop button or Ctrl-C to terminate)
 
Created "Inet main" task (Prio: 2)
Created "clock tick" task (Prio: 3)
InterNiche Portable TCP/IP, v3.1
 
Copyright 1996-2008 by InterNiche Technologies. All rights reserved.
prep_tse_mac 0
prepped 1 interface, initializing...
[tse_mac_init]
TSEMAC SW reset bit never cleared!
OK, x=10002, CMD_CONFIG=0x00002000
 
MAC post-initialization: CMD_CONFIG=0x04000200
[tse_sgdma_read_init] RX descriptor chain desc (1 depth) created
mctest init called
IP address of et1 : 10.2.0.150
System is running....

Is it that MAC reset fails because TSE controller still tries to communicate with phy ? Why ?

Thank you for any idea,

ranran

8 Replies

  • FawazJ_Altera's avatar
    FawazJ_Altera
    Icon for Frequent Contributor rankFrequent Contributor
    7 years ago

    Hello,

    I will investigate more about your problem. In the mean time, would you please confirm the clock connections that are going to TSE, including the ones that are coming from the PHY?

    thank you

    • rshal2's avatar
      rshal2
      Icon for Occasional Contributor rankOccasional Contributor
      7 years ago

      Thank you very much, It's very much appreciated.

      As to the clocks, the FPGA internal clocks seems to be OK.

      Is there a specific clock that we should check ?

      nios_eth_tse_pcs_mac_tx_clock_clk => emac_tx_clk,
   nios_eth_tse_pcs_mac_rx_clock_clk => rgmii_rx_clk,

      I've validated with signal tap that emac_tx_clk is correct (25M clock for 100M ethernet)

      as to rgmii_rx_clk, I see no clock, does it explain the mac reset issue ? not sure

      Thank you

  • FawazJ_Altera's avatar
    FawazJ_Altera
    Icon for Frequent Contributor rankFrequent Contributor
    7 years ago

    Hello,

    Yes, this might be the reason.

    Kindly take a look at this document:

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

    The software reset is 1 when the clocks are not available, either cable disconnected, or PHY disconnected. In your case, since there is no PHY, the soft reset is kept high.

    The Nichestack application requires a phy to run. If you have the phy already in your system, I recommend to enable the MDIO and connect the phy to it. Then run the Nichestack application and see if you can pass the reset issue.

    If you want to run the system without phy, then Nichestack will not help you. You need to develop your own application to run the loopback test.

    Hope this might help.

    Thank you.

    • rshal2's avatar
      rshal2
      Icon for Occasional Contributor rankOccasional Contributor
      7 years ago

      Hi,

      Not sure I understand....

      The reset mac is not related to Nichestack . It is done in low level ( TSE registers).

      The issue is it not a limitation of Nichestack as you said, but of intel's TSE, Right ?

      When working with unmanaged switch (no cpu mode), there is no need to communiate with phy. We want it to run phyless.

      Therefore, the question is why TSE reset should fail without phy.

      Is there a way to overcome this limitation in TSE core ?

      Thanks

  • FawazJ_Altera's avatar
    FawazJ_Altera
    Icon for Frequent Contributor rankFrequent Contributor
    7 years ago

    Hello,

    The software terminal output shown in your description is coming from a nitchestack application right? My point here is, you cannot run Nitchestack without phy.

    The TSE expects a clock to come from the phy. without this clock, you will not get rid of this reset issue.

    May I know what is the intention of having phy-less system?

    Are you going to send data through ethernet cable?

    Thank you.

    • rshal2's avatar
      rshal2
      Icon for Occasional Contributor rankOccasional Contributor
      7 years ago

      Hi,

      I am using Marvell switch.

      This switch has un-managed mode, i.e. mode in which the switch starts operating without any need for configuration.

      I think this is not an issue of nitchestack limitation , I've commented out all it's trials to communicate with phy.

      The limitation seems to be purely related to TSE.

      Thanks

  • FawazJ_Altera's avatar
    FawazJ_Altera
    Icon for Frequent Contributor rankFrequent Contributor
    7 years ago

    Hello,

    TSE wise, there should be no issue. However, your interface would define your system. For example, if you use RGMII, this means you need to get a PHY since it will proved the rx clock to MAC.

    If you are using MII, then, all the signals should come from MAC to PHY. This might help you to get rid of the phy, or "phy-less" mode as you mentioned.

    Please let me know if MII didnt help you.

    thanks

  • rshal2's avatar
    rshal2
    Icon for Occasional Contributor rankOccasional Contributor
    7 years ago

    Hello,

    This is what we I did to solve this issue:

    1. In software: seems that internich can output network even if it

    detects any phy , yet we forced in getPhySpeed routine to configure

    the TSE controller to 1000 (the default in interniche code is 100, so

    we had to change it)

    2. switch is used in "unmanaged mode", i.e. it is enabled and

    configured "automatically" with default configuration (marvell

    default) on power.

    Yet, The actual problem was with RGMII delay (clock need to be phased

    shift from data, this could be solved by adding delay in fpga or in

    switch. We solved it by configuring the marvell switch rx delay bit

    (it is called"rx" in switch but it is actually the tx from fpga -

    through switch - to the output network).

    Now everything works !

    Thank you very much ,

    Ran