Forum Discussion

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

Helpless about 1588V2

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 can...
Deshi_Intel's avatar
Deshi_Intel
Icon for Regular Contributor rankRegular Contributor
5 years ago

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's avatar
    mark_lee
    Icon for Occasional Contributor rankOccasional Contributor
    5 years ago

    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's avatar
      mark_lee
      Icon for Occasional Contributor rankOccasional Contributor
      5 years ago

      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's avatar
        mark_lee
        Icon for Occasional Contributor rankOccasional Contributor
        5 years ago

        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: