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,
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 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
Yes, this might be the reason.
Kindly take a look at this document:
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.
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 ?
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?
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.
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.
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 ,