Helpless about 1588V2

[mark_lee]

I run the project "LL10G_1G_10G_LINESIDE_1588v2" on the demo board "Arria 10 SOC Development Kit"

1588V2 thranceive an receive are OK ;  I made project run on my board(10AS066H3F34I2SG) , it is cannot receive anything . 

can  the chip "10AS066H3F34I2SG" surport the 1588v2  ?

% TEST_1588 0 1 10G
CONFIGURE CHANNEL 0 as master
configure_to_10G
setting up mac with a basic working config
setting 0xC5C4 into rxmac primary address Reg-1
setting 0xC3C2C1C0 into rxmac primary address Reg-0
enabling: pad and crc stripping in rx mac
testing Configure Period and Adjustment RX XGMII TSU
Configure Period and Adjustment TX XGMII TSU
clearing mac stats registers
testing Configure Period and Adjustment RX XGMII TSU
Configure Period and Adjustment TX XGMII TSU
Configure TOD Master
Configure TOD 10G
Disabling serial PMA Loopback (local)
Read back Serial PMA loopback register = 0x00000000
CONFIGURE CHANNEL 1 as slave
configure_to_10G
setting up mac with a basic working config
setting 0xC5C4 into rxmac primary address Reg-1
setting 0xC3C2C1C0 into rxmac primary address Reg-0
enabling: pad and crc stripping in rx mac
testing Configure Period and Adjustment RX XGMII TSU
Configure Period and Adjustment TX XGMII TSU
clearing mac stats registers
testing Configure Period and Adjustment RX XGMII TSU
Configure Period and Adjustment TX XGMII TSU
Configure TOD Master
Configure TOD 10G
Disabling serial PMA Loopback (local)
Read back Serial PMA loopback register = 0x00000000
Select 1588 traffic controller
Start TOD synchronization
Master 1588 start 1 step operation
TRAFFIC_CONTROLLER_BASE_ADDR: 0x100000
Waiting capturing offset delay ...
-- Break
Start capturing offset delay ...
Reset Master 1588 start 1 step operation
Reset Start TOD synchronization
delay ns = 0x00000000
delay fns = 0x00000000
offset ns = 0x00000000
offset fns = 0x00000000
===================================================================
| MAC TX STATS REGISTER CHECK
===================================================================
|# FRAMES_RECEIVED_WITH_ERROR = 0
|# UNICAST_FRAMES_WITH_ERROR = 0
|# MULTICAST_FRAMES_RECEIVED_WITH_ERROR = 0
|# BRDCAST_FRAMES_WITH_ERROR = 0
|# FRAMES_RECEIVED_WITH_ONLY_CRCERROR = 0
|# VALID_LENGTH_FRAMES_WITH_CRC_ERROR = 0
|# JABBER_FRAMES = 0
|# FRAGMENTED_FRAMES = 0
|# INVALID_FRAMES_RECEIVED = 0
|# FRAMES_RECEIVED_GOOD = 0
|# PAUSE_FRAMES_RECEIVED = 0
|# UNICAST_CONTROL_FRAMES = 0
|# MULTICAST_CONTROL_FRAMES = 0
|# UNICAST_FRAMES_RECEIVED_GOOD = 0
|# MULTICAST_FRAMES_RECEIVED_GOOD = 0
|# BRDCAST_FRAMES_GOOD = 0
|# DATA_AND_PADDING_OCTETS_RECEIVED_GOOD= 0
|# COMPREHENSICE_OCTETS_RECEIVED = 0
|# FRAMES_WITH_SIZE_64_BYTES = 0
|# FRAMES_BETWEEN_SIZE_64AND127_BYTES = 0
|# FRAMES_BETWEEN_SIZE_128AND255_BYTES = 0
|# FRAMES_BETWEEN_SIZE_256AND511_BYTES = 0
|# FRAMES_BETWEEN_SIZE_512AND1K_BYTES = 0
|# FRAMES_BETWEEN_SIZE_1KND1518_BYTES = 0
======================================================================
| MAC RX STATS REGISTER CHECK
======================================================================
|# FRAMES_RECEIVED_WITH_ERROR = 0
|# UNICAST_FRAMES_WITH_ERROR = 0
|# MULTICAST_FRAMES_RECEIVED_WITH_ERROR = 0
|# BRDCAST_FRAMES_WITH_ERROR = 0
|# FRAMES_RECEIVED_WITH_ONLY_CRCERROR = 0
|# VALID_LENGTH_FRAMES_WITH_CRC_ERROR = 0
|# JABBER_FRAMES = 0
|# FRAGMENTED_FRAMES = 0
|# INVALID_FRAMES_RECEIVED = 0
|# FRAMES_RECEIVED_GOOD = 0
|# PAUSE_FRAMES_RECEIVED = 0
|# UNICAST_CONTROL_FRAMES = 0
|# MULTICAST_CONTROL_FRAMES = 0
|# UNICAST_FRAMES_RECEIVED_GOOD = 0
|# MULTICAST_FRAMES_RECEIVED_GOOD = 0
|# BRDCAST_FRAMES_GOOD = 0
|# DATA_AND_PADDING_OCTETS_RECEIVED_GOOD= 0
|# COMPREHENSICE_OCTETS_RECEIVED = 0
|# FRAMES_WITH_SIZE_64_BYTES = 0
|# FRAMES_BETWEEN_SIZE_64AND127_BYTES = 0
|# FRAMES_BETWEEN_SIZE_128AND255_BYTES = 0
|# FRAMES_BETWEEN_SIZE_256AND511_BYTES = 0
|# FRAMES_BETWEEN_SIZE_512AND1K_BYTES = 0
|# FRAMES_BETWEEN_SIZE_1KND1518_BYTES = 0
|# FRAMES_BETWEEN_SIZE_ABOVE1519_BYTES = 0
===================================================================
| MAC TX STATS REGISTER CHECK
===================================================================
|# FRAMES_RECEIVED_WITH_ERROR = 0
|# UNICAST_FRAMES_WITH_ERROR = 0
|# MULTICAST_FRAMES_RECEIVED_WITH_ERROR = 0
|# BRDCAST_FRAMES_WITH_ERROR = 0
|# FRAMES_RECEIVED_WITH_ONLY_CRCERROR = 0
|# VALID_LENGTH_FRAMES_WITH_CRC_ERROR = 0
|# JABBER_FRAMES = 0
|# FRAGMENTED_FRAMES = 0
|# INVALID_FRAMES_RECEIVED = 0
|# FRAMES_RECEIVED_GOOD = 0
|# PAUSE_FRAMES_RECEIVED = 0
|# UNICAST_CONTROL_FRAMES = 0
|# MULTICAST_CONTROL_FRAMES = 0
|# UNICAST_FRAMES_RECEIVED_GOOD = 0
|# MULTICAST_FRAMES_RECEIVED_GOOD = 0
|# BRDCAST_FRAMES_GOOD = 0
|# DATA_AND_PADDING_OCTETS_RECEIVED_GOOD= 0
|# COMPREHENSICE_OCTETS_RECEIVED = 0
|# FRAMES_WITH_SIZE_64_BYTES = 0
|# FRAMES_BETWEEN_SIZE_64AND127_BYTES = 0
|# FRAMES_BETWEEN_SIZE_128AND255_BYTES = 0
|# FRAMES_BETWEEN_SIZE_256AND511_BYTES = 0
|# FRAMES_BETWEEN_SIZE_512AND1K_BYTES = 0
|# FRAMES_BETWEEN_SIZE_1KND1518_BYTES = 0
======================================================================
| MAC RX STATS REGISTER CHECK
======================================================================
|# FRAMES_RECEIVED_WITH_ERROR = 0
|# UNICAST_FRAMES_WITH_ERROR = 0
|# MULTICAST_FRAMES_RECEIVED_WITH_ERROR = 0
|# BRDCAST_FRAMES_WITH_ERROR = 0
|# FRAMES_RECEIVED_WITH_ONLY_CRCERROR = 0
|# VALID_LENGTH_FRAMES_WITH_CRC_ERROR = 0
|# JABBER_FRAMES = 0
|# FRAGMENTED_FRAMES = 0
|# INVALID_FRAMES_RECEIVED = 0
|# FRAMES_RECEIVED_GOOD = 0
|# PAUSE_FRAMES_RECEIVED = 0
|# UNICAST_CONTROL_FRAMES = 0
|# MULTICAST_CONTROL_FRAMES = 0
|# UNICAST_FRAMES_RECEIVED_GOOD = 0
|# MULTICAST_FRAMES_RECEIVED_GOOD = 0
|# BRDCAST_FRAMES_GOOD = 0
|# DATA_AND_PADDING_OCTETS_RECEIVED_GOOD= 0
|# COMPREHENSICE_OCTETS_RECEIVED = 0
|# FRAMES_WITH_SIZE_64_BYTES = 0
|# FRAMES_BETWEEN_SIZE_64AND127_BYTES = 0
|# FRAMES_BETWEEN_SIZE_128AND255_BYTES = 0
|# FRAMES_BETWEEN_SIZE_256AND511_BYTES = 0
|# FRAMES_BETWEEN_SIZE_512AND1K_BYTES = 0
|# FRAMES_BETWEEN_SIZE_1KND1518_BYTES = 0
|# FRAMES_BETWEEN_SIZE_ABOVE1519_BYTES = 0

[mark_lee]

1. I had run the 1588 test project on my board with Optical fiber between 0 port and 1 port , when I run Signal Tap to get 0 port phy interface signal , I get an abnormal signal , the phy is being calibrated：

  Under these circumstances，running  1588_TEST  ,  Fail 

2.   Every time after running ”TEST_PHYSERIAL_LOOPBACK 1 10G 5000“ , The  Signal Tap  get an normal signal about 0 port phy interface : 

  Under these circumstances，running  1588_TEST  ,  succes 

[Deshi_Intel]

Hi,

Thanks. These are good debug sharing but I am a bit confused on your signal_tap debug result.

• You mentioned you performed PHY_serial_loopback on port 1 but it somehow affect the transceiver status on port 0 ?
• Or you need to perform PHY_serial_loopback on both port 0 and port 1 before you can get 1588 test run working ?

My suspect is your port 0 or port 1 Rx channel is still stuck in reset, causing 1588 test to fail.

• Performed loopback test asserted CDR lock (rx_is_lockedtodata), then released Rx channel from reset and asserted (rx_ready). Rx channel is now ready to run 1588 test

I am not sure channel stuck in reset is due to

• MAC is operating in bidirectional mode. (unidirectional mode option is turned off in MAC IP)
• Or somehow transceiver PHY reset controller IP is holding Rx channel in reset
• Or this could be due to the example design tcl script functional write up where it expect user to perform internal loopback test before proceed to external test

To isolate whether this is related to "example design tcl script coding style issue" or "loopback issue"

• You can try to use external hardware equipment to send some data to port 0 and 1 Rx channel to ensure "rx_is_lockedtodata" and "rx_ready" signal asserted high for one time before running 1588 test
• If 1588 test passed, then we know somehow this is related to transceiver reset sequence requirement
• If 1588 test still failed, then we know it's related to loopback test requirement. User must performed one time loopback test before running actual Ethernet test

Thanks.

Regards,

dlim

[mark_lee]

HI  Deshi and team

1. You mentioned you performed PHY_serial_loopback on port 1 but it somehow affect the transceiver status on port 0 ？  

    YES , 

   PHY_serial_loopback on port 1 but  it somehow affect the transceiver status on port 0; 

   PHY_serial_loopback on port 0 but  it somehow affect the transceiver status on port 1;.

2. Or you need to perform PHY_serial_loopback on both port 0 and port 1 before you can get 1588 test run working ?

    Before I can get 1588 test run working success , I need to perform "PHY_serial_loopback " “the Slave port”，and it is the only method to make 1588 test success 。Perform "PHY_serial_loopback " “the master  port”  without effect。

[mark_lee]

Hi Deshi and team

   " Or somehow transceiver PHY reset controller IP is holding Rx channel in reset"

The Rx channel in reset , it is cause by the "rx_cal_busy=1", When the phy phy is being calibrated "rx_cal_busy=1" 。I  so confused  what  is the matter cause the phy being calibarated 

[Deshi_Intel]

Hi,

Go it. Meaning you need to perform PHY_serial_loopback on "slave" port before you can run 1588 test.

I don't think slave port RX channel will forever stuck in calibration. Reason being transceiver channel calibration only happen in below scenario

• during FPGA power up - it will auto perform transceiver channel calibration . Once calibration completed then cal_busy signal will de-assert
• user manually write to transceiver channel reg to trigger channel re-calibration

Either way, calibration process should complete after sometime

• Just to confirm whether do you see slave port RX channel cal_busy signal always stuck high, never de-assert ? Only de-assert after performing loopback test ?
• Or just happen your signal_tap capture during the middle of calibration process. That's why cal_busy still stay high for a while

Anyhow, would you be able to try out below experiment as suggested by me earlier.

To isolate whether this is related to "example design tcl script coding style issue" or "loopback issue"

• You can try to use external hardware equipment to send some data to port 0 and 1 Rx channel to ensure "rx_is_lockedtodata" and "rx_ready" signal asserted high for one time before running 1588 test
• If 1588 test passed, then we know somehow this is related to transceiver reset sequence requirement
• If 1588 test still failed, then we know it's related to loopback test requirement. User must performed one time loopback test before running actual Ethernet test

Also, just wonder do you see similar behaviour test result in A10 dev kit board ?

• This will also help us to isolate whether is it Quartus design issue or board design issue

Thanks.

Regards,

dlim

[mark_lee]

Hi Deshi and team

1. It is the master port phy being calibration ,  and the process is：
   “being calibration(re_cal_busy=1)----> calibration finish (re_cal_busy=0)----->being        calibration(re_cal_busy=1)----->calibration finish (re_cal_busy=0)----->............

        Repeat  the process untill perform PHY_serial_loopback on "slave" , The maste port stop calibration ,and "re_cal_busy=0 " and the other signals is correct。

（ I take an video for "Autorun analysis" in the appendix，plese check out )

2. This test resul never appear in A10 dev kit board;

 By the way , can you read in Chinese?

[mark_lee]

Hi Deshi and team 

      I have use external hardware equipment to send some data to the master port ,and Rx channel to ensure "rx_is_lockedtodata" and "rx_ready" signal asserted high for one time before running 1588 test.

    Then  when I perform "TEST_1588 0 1 10G "  , it is fail ,  and  the master port (0 port)  phy is being calibarated  repeat.

   But I don't think it is  related to loopback test requirement, My project running on the A10 dev kit board,it is never being calibarated.

[mark_lee]

Hi Deshi and team

1 I measurement the signal "phy_rx_recovered_clk "  when the phy is being calibrated , the "phy_rx_recovered_clk[0] and phy_rx_recovered_clk[1] ” is too bad ,  like this pictrue:

2. perform Physerial_loopback (0 port or 1 port ),  the ”“phy_rx_recovered_clk[0] and phy_rx_recovered_clk[1] ” is good  ,  like this pictrue:

[Deshi_Intel]

Hi,

Sorry, I can't read chinese. Understood that you are chinese customer but I still your help to continue to explain in English.

Your scope clk measurement make sense. If transceiver channel is not properly calibrated then the output clock is expected to be bad.

Assuming you didn't change much and connect everything correctly in the example design and the design did work in A10 dev kit board. we can then conclude that

• Quartus Ethernet example design (ok)
• Loopback test run is not a bring up requirement as it's not required on A10 dev kit board
• The failure should be related to either your board design or your overall hardware system bring up issue

From your signal_tap result, looks like the transceiver calibration process keeps on being interrupted and then restart again. This process repeat forever until your performed loopback testing.

• I think I mentioned this before - there are 2 things that may affect transceiver calibration
• clk_usr - this transceiver calibration clock is not stable or free running during FPGA power up period or somehow the clock is interrupted during transceiver calibration process
  • Can you review your board setup and cross check to monitor this clock on your scope ?
• A system reset is being performed during transceiver calibration process
  • This one you need to review your system reset control. Can you add delay to your system reset to ensure you only release it after transceiver calibration is completed
  • Another debug option is modify example design to connect transceiver reset controller IP reset input to Quartus "In and source and Probe" (ISSNP) IP to isolate transceiver reset from your board system reset

Worst come to worst if we still can't find the issue on your board setup then maybe you need to implement additional steps to perform "serial loopback" action once before you can start Ethernet operation on your board

Thanks.

Regards,

dlim

[Deshi_Intel]

HI,

I have not hear back from you for sometime.

Hopefully you are making progress in your debug plan or move on to implement the loopback workaround.

For now, I am setting this case to closure. Feel free to post new forum thread if you still like to continue the debug discussion further.

Thanks.

Regards,

dlim

[mark_lee]

Hi  Deshi and Team

    Thanks for you help and time.