Forum Discussion

Occasional 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 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

31 Replies

Caguicla_Intel
New Contributor
5 years ago
Hello mark_lee,

Thank you for posting in Intel Ethernet Communities.

Your query will be best answered by our Intel Field Programmable Gate Array (FPGA) Support team, we will help you to move this post to the designated team for further assistance.

Please feel free to contact us if you need assistance from Intel Ethernet support team.

May you have a great day!

Best regards,
Crisselle C
Intel® Customer Support
- mark_lee
  Occasional Contributor
  5 years ago
  hi TEAM
  
  In addition: demo board "Arria 10 SOC Development Kit" use the chip"10AS066N3F40E2SG";
  
  my project use the chip "10AS066H3F34I2SG
Deshi_Intel
Regular Contributor
5 years ago
HI,

May I know which Ethernet ref design that you are referring here ?
Any download link or do explain to me how you generate the ref design ?

Typically 1588 feature follow Ethernet IP and has less dependency on FPGA device speedgrade. Since both A10 SOC dev kit and your board are using Arria 10 FPGA, it should work.

Which means the failure is either due to Quartus design issue, board setup issue or board design issue. The good news is you at least have a golden working ref design on A10 SOC dev kit board. You just need to compare and find out the difference that may caused the failure.

To rule out Quartus design issue
I presume you use back same ref design without changes to the RTL design ?
Does the design met Quartus timequest timing closure ?
Also pls verify the qsf setting particularly on pin location and IO standard setting to match with your own board
To rule out board setup issue
Pls double check on FPGA reset, power and clocking
Your log file shown zero Tx and Rx transaction where I suspect either your design is stuck in reset or clocking is not provided correctly
Or maybe some FPGA pin location or IO standard is set wrongly
To rule out board design issue
Can your board handle 10G data transfer without concern on signal integrity issue ?
Have you try to use transceiver toolkit to perform loopback testing on your board to verify 10G signal transfer is good on your board first ?

Thanks.

Regards,
dlim
- mark_lee
  Occasional Contributor
  5 years ago
  Hi Deshi ant team
  
  1. The Project "LL10G_1G_10G_LINESIDE_1588v2" is builded Reference the Intel Example "a10soc_322265325_Scalable_Eth1588_BUG2613_Quartus_16.1.0";
  
  2. My Project is working on the Quartus Prime pro 19.2;
  
  3.I have running my project on my board ，"TEST_SMA_LB 0 1 10G " is ok;
  
  4.I have running my project on my board ，"TEST_PHYSERIA_LOOPBACK " is ok;
  
  5.When finish TEST_PHYSERIAL_LOOPBACK , and running“TEST_1588 0 1 10G" right now，sometime frames received is good , "offset ns" and "delay ns" are good , but when runningTEST_1588 again it is receive annything 。
  - mark_lee
    Occasional Contributor
    5 years ago
    Hi Deshi ant team
    
    In addition:
    
    1. "TEST_SMA_LB 0 10 G 5000 " and "TEST_PHYSERIAL_LOOPBACK "1 10G 5000" are ok, message is :
    
    (1)
    
    % TEST_SMA_LB 0 10G 5000
    CONFIGURE CHANNEL 0
    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 std ethernet traffic controller
    Disable Avalon ST Loopback
    
    ====================================================================================
    B E G I N C O N F I G U R A T I O N
    ====================================================================================
    payload length = fixed ....
    payload bytes = fixed incremental bytes ....
    burst size = 5000 ....
    payload length = 100 ....
    frame source addres field = F0F1F2F3F4F5 ....
    frame destination addres field = C5C4C3C2C1C0 ....
    reseting monitor Packet Counters
    number of Packets Expected By Monitor = 0x1388
    burst being injected into device ....
    -- MONITOR processing frames received .....
    
    -- MONITOR Received Packet# 5000]
    
    -- DONE! - monitor received all expected sum of packets .....
    
    _________________________________________________________________________________________________________________________
    
    -- (MONITOR) GOOD PKTS RECEIVED = 5000
    -- (MONITOR) BAD PKTS RECEIVED = 0
    -- (MONITOR) BYTES RECEIVED = 479992
    -- (MONITOR) CYCLES USED = 75002
    -- (MONITOR) THROUGHPUT CALCULATED = 8.00 Gbps
    -- (MONITOR) RXBYTECNT_LO32 = 479992
    -- (MONITOR) RXBYTECNT_HI32 = 0
    -- (MONITOR) RXCYCLCNT_LO32 = 75002
    -- (MONITOR) RXCYCLCNT_HI32 = 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 = 5000
    |# PAUSE_FRAMES_RECEIVED = 0
    |# UNICAST_CONTROL_FRAMES = 0
    |# MULTICAST_CONTROL_FRAMES = 0
    |# UNICAST_FRAMES_RECEIVED_GOOD = 0
    |# MULTICAST_FRAMES_RECEIVED_GOOD = 5000
    |# BRDCAST_FRAMES_GOOD = 0
    |# DATA_AND_PADDING_OCTETS_RECEIVED_GOOD= 410000
    |# COMPREHENSICE_OCTETS_RECEIVED = 500000
    |# FRAMES_WITH_SIZE_64_BYTES = 0
    |# FRAMES_BETWEEN_SIZE_64AND127_BYTES = 5000
    |# 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 = 5000
    |# PAUSE_FRAMES_RECEIVED = 0
    |# UNICAST_CONTROL_FRAMES = 0
    |# MULTICAST_CONTROL_FRAMES = 0
    |# UNICAST_FRAMES_RECEIVED_GOOD = 0
    |# MULTICAST_FRAMES_RECEIVED_GOOD = 5000
    |# BRDCAST_FRAMES_GOOD = 0
    |# DATA_AND_PADDING_OCTETS_RECEIVED_GOOD= 410000
    |# COMPREHENSICE_OCTETS_RECEIVED = 500000
    |# FRAMES_WITH_SIZE_64_BYTES = 0
    |# FRAMES_BETWEEN_SIZE_64AND127_BYTES = 5000
    |# 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
    
    (2)
    
    % TEST_PHYSERIAL_LOOPBACK 1 10G 5000
    CONFIGURE CHANNEL 1
    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
    Enabling serial PMA Loopback (local)
    Read back Serial PMA loopback register = 0x00000001
    Select std ethernet traffic controller
    Disable Avalon ST Loopback
    
    ====================================================================================
    B E G I N C O N F I G U R A T I O N
    ====================================================================================
    payload length = fixed ....
    payload bytes = fixed incremental bytes ....
    burst size = 5000 ....
    payload length = 100 ....
    frame source addres field = F0F1F2F3F4F5 ....
    frame destination addres field = C5C4C3C2C1C0 ....
    reseting monitor Packet Counters
    number of Packets Expected By Monitor = 0x1388
    burst being injected into device ....
    -- MONITOR processing frames received .....
    
    -- MONITOR Received Packet# 5000]
    
    -- DONE! - monitor received all expected sum of packets .....
    
    _________________________________________________________________________________________________________________________
    
    -- (MONITOR) GOOD PKTS RECEIVED = 5000
    -- (MONITOR) BAD PKTS RECEIVED = 0
    -- (MONITOR) BYTES RECEIVED = 479992
    -- (MONITOR) CYCLES USED = 75002
    -- (MONITOR) THROUGHPUT CALCULATED = 8.00 Gbps
    -- (MONITOR) RXBYTECNT_LO32 = 479992
    -- (MONITOR) RXBYTECNT_HI32 = 0
    -- (MONITOR) RXCYCLCNT_LO32 = 75002
    -- (MONITOR) RXCYCLCNT_HI32 = 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 = 5000
    |# PAUSE_FRAMES_RECEIVED = 0
    |# UNICAST_CONTROL_FRAMES = 0
    |# MULTICAST_CONTROL_FRAMES = 0
    |# UNICAST_FRAMES_RECEIVED_GOOD = 0
    |# MULTICAST_FRAMES_RECEIVED_GOOD = 5000
    |# BRDCAST_FRAMES_GOOD = 0
    |# DATA_AND_PADDING_OCTETS_RECEIVED_GOOD= 410000
    |# COMPREHENSICE_OCTETS_RECEIVED = 500000
    |# FRAMES_WITH_SIZE_64_BYTES = 0
    |# FRAMES_BETWEEN_SIZE_64AND127_BYTES = 5000
    |# 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 = 5000
    |# PAUSE_FRAMES_RECEIVED = 0
    |# UNICAST_CONTROL_FRAMES = 0
    |# MULTICAST_CONTROL_FRAMES = 0
    |# UNICAST_FRAMES_RECEIVED_GOOD = 0
    |# MULTICAST_FRAMES_RECEIVED_GOOD = 5000
    |# BRDCAST_FRAMES_GOOD = 0
    |# DATA_AND_PADDING_OCTETS_RECEIVED_GOOD= 410000
    |# COMPREHENSICE_OCTETS_RECEIVED = 500000
    |# FRAMES_WITH_SIZE_64_BYTES = 0
    |# FRAMES_BETWEEN_SIZE_64AND127_BYTES = 5000
    |# 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
Deshi_Intel
Regular Contributor
5 years ago
Hi Mark,

I presume you are still using below ref design "unchanged" or you had modified the design ?
https://www.intel.com/content/dam/altera-www/global/en_US/uploads/2/26/Arria_10_Scalable_10G_Ethernet_MAC_NativePHY_IEEE1588v2_user_guide.pdf

Let's clarify your problem statement before we discuss about debug plan :
Your latest update mentioned 1588 hardware testing sometime pass, sometime failed, right ?
Does the failure occurs randomly or always after 2nd time of 1588 hardware testing ?
Does reset the system and retest 1588 makes it to pass again ?
When 1588 test failed, does the statistic log always show zero value ? This looks to me your design or system is stuck rather than receive wrong/bad data issue

For the debug plan, similar approach applied as I explained to you earlier on the other post
Does your board provide clean and stable clocking to ref design mm_clk (125MHz), ref_clk_10g (644.53MHz), ref_clk_1g (125MHz) ?
Does your board supply (100Mhz - 125MHz) clock to FPGA clkusr pin that's in charge to provide clocking to transceiver channel power up calibration ?
The ref design comes with stp1.stp debug signal_tap file. Can you trigger and capture the signal_tap debug signals for both passing and failing condition and share with me the signal_tap files ? We can then review the signal_tap files to see which status signal is failing and debug further from there

Thanks.

Regards,
dlim
- mark_lee
  Occasional Contributor
  5 years ago
  Hi Deshi and team
  
  1. I use the design is build by my workmate , he is reference to the example " Arria 10 Scalable 10G Ethernet MAC+ Native PHY with IEEE1588v2 Design “；
  
  2.My design is running 1588V2 test success on the demo board "Arria 10 SOC Development Kit" ;
  
  3. MY design running "TEST_SMA_LB" and " TEST_PHYSERIAL_LOOPBACK" test success on my board;
  
  4. Every time running ”TEST_PHYSERIAL_LOOPBACK“，and then running "TEST_1588" 。1588TEST is success 。 THis the only method to made 1588TEST success now 。IF didnot running "TEST_PHYSERIAL_LOOPBACK" before "TEST_1588" , 1588 test fail, and the statistic log always show zero value;
  
  5. Clock On my board is :
  
  (1) clock to FPGA clkusr (100Mhz );
  
  (2) ref_clk_10g (644.53MHz);
  
  (3) mm_clk (100MHz);
  
  (4) ref_clk_1g ( "no clock input " ),
  
  There have no clock 125Mhz for the "ref_clk_1g" on my board , In my design did not need 1g test.
  
  THANKS
  
  Regards,
  
  mark
  - mark_lee
    Occasional Contributor
    5 years ago
    Hi Deshi and team
    
    In addition :
    I set the "IOPLL" out2 is 125Mhz ,and use it as the "IOPLL2 ” ref_clk_input , IOPLL2 output the "tod sync" and "sampling clock".
Deshi_Intel
Regular Contributor
5 years ago
Hi Mark,

Pls use the original working ref design without design modification. Just change the FPGA OPN and pin location to match your board only.
Once getting the design to work then only feel free to modify the design

Let's debug your following statement first
When 1588 test failing I can't trigger and capture anything , as the ip core never running

Can you share with me the signal_tap screenshot/file when the 1588 test is failing ?
I want to know what's the exact signal condition that you see from signal_tap in test failed condition.

Let me explain. Which scenario that you are facing here ?
Scenario A :
Signal_tap is clocked by "xgmii_clk_312_5". Once the xgmii clock presented on your board, signal_tap should start capture something (be it good or bad signal status) if you set the signal_tap trigger condition to capture everything xx. Don't set trigger condition like trigger on rising edge or faling edge
The only reason signal_tap will stop working is there is no clock on xgmii_clk_312_5. Signal_tap will complain "waiting for clock". Are you seeing scenario A ?
No clock could be due to your board stop supplying input clock to FPGA or FPGA IOPLL loose lock or your design is stuck in reset. Then you can check further from here
Scenarion B :
Signal_tap detected "xgmii_clk_312_5" and start capturing data.
But you set signal_tap trigger condition on some signal and the signal didn't trigger causing nothing capture on your signal_tap because it's still waiting for signal trigger.
Pls set the signal_tap trigger condition to capture everything xx. Don't set trigger condition like trigger on rising edge or faling edge
Then we see what's signal status result on the signal_tap

Thanks.

Regards,
dlim
- mark_lee
  Occasional Contributor
  5 years ago
  Hi Deshi
  
  I facing “Scenarion B” ;
- mark_lee
  Occasional Contributor
  5 years ago
  Hi Deshi
  
  the STP is in the appendix，pls check up
  
  Thanks
  STP_file_for_Deshi.zip93 KB
  - Deshi_Intel
    Regular Contributor
    5 years ago
    
    SIgnal_Tap result comparison between ref design doc (page 14) vs customer 1588_test_passed result
Deshi_Intel
Regular Contributor
5 years ago
HI Mark,

May I know
stp_1588_TEST_success.stp = 1588 test passed result ?
stp_1588_TEST_fail.stp = 1588 test failed result ?

The reason I asked is due to I am seeing weird result when compared to golden reference signal_tap result from ref design doc (page 14). Attached is the result comparison that you can check it out yourself.

I suspect is either
(A) Something is still wrong with your board or system reset control on 1588 ref design "channel_reset_n" and "master_reset_n" ports
Or (B) your signal_tap result is capturing the system test run at the wrong time (like before the system is stable or after test run completed)

We now know that signal_tap is working on your board. You can then play with signal_tap trigger feature to try detect following expected signal behaviour
For instance, your signal_tap result shown transceiver channel is still stuck in reset and ready signal haven't asserted high
both ch0 and ch1 rx_islockedtodata signal doesn't assert high which means Rx channel CDR doesn't detect correct 10G data and lock yet
both ch0 and ch1 rx_enh_blk_lock signal doesn't assert high as well which highly due to CDR is still loose lock ?
ch0 link_fault status signal also asserted high which is bad

Pls try play around with trigger function and re-capture signal_tap result for both passing and failing cases then we can compared the result again.
You can do so yourself to compare with page 14 expected signal_tap result in parallel
Then we can exchange debug opinion to discuss further

Thanks.

Regards,
Deshi
- mark_lee
  Occasional Contributor
  5 years ago
  Hi Deshi
  
  stp_1588_TEST_success.stp = 1588 test passed result ? YES
  
  stp_1588_TEST_fail.stp = 1588 test failed result ? YES
  - mark_lee
    Occasional Contributor
    5 years ago
    Hi Deshi and team
    
    I have try to make 1588V2 channel 0 loopback to channel1 on the chip without Optical module。My code is:
    
    " assign rx_serial_data[0] = tx_serial_data[1] ;
    
    assign rx_serial_data[1] = tx_serial_data[0] ；”
    
    then compilation, I get error about this :
    
    Error(11654): Output port "VOP" of "HSSI_PMA_TX_BUF" cannot connect to HSSI port "RX_P_BIDIR_IN" of "HSSI_PMA_TX_BUF" for atom "altera_eth_multi_channel_1588_inst|CHANNEL[1].altera_eth_channel_1588_inst|phy|xcvr_10gkr_a10_0|CHANNEL|DATAPATH_10G.NATIVE_PHY_10G_1588_644_LS.native_10g_1588_644_ls_inst|native_10g_1588_644_ls_inst|native_10g_1588_644_ls_inst|g_xcvr_native_insts[0].twentynm_xcvr_native_inst|twentynm_xcvr_native_inst|inst_twentynm_pma|gen_twentynm_hssi_pma_tx_buf.inst_twentynm_hssi_pma_tx_buf".
    Error(11654): Output port "VOP" of "HSSI_PMA_TX_BUF" cannot connect to HSSI port "RXP" of "HSSI_PMA_RX_BUF" for atom "altera_eth_multi_channel_1588_inst|CHANNEL[1].altera_eth_channel_1588_inst|phy|xcvr_10gkr_a10_0|CHANNEL|DATAPATH_10G.NATIVE_PHY_10G_1588_644_LS.native_10g_1588_644_ls_inst|native_10g_1588_644_ls_inst|native_10g_1588_644_ls_inst|g_xcvr_native_insts[0].twentynm_xcvr_native_inst|twentynm_xcvr_native_inst|inst_twentynm_pma|gen_twentynm_hssi_pma_rx_buf.inst_twentynm_hssi_pma_rx_buf".
    Error(11654): Output port "VOP" of "HSSI_PMA_TX_BUF" cannot connect to HSSI port "RXP" of "HSSI_PMA_CDR_PLL" for atom "altera_eth_multi_channel_1588_inst|CHANNEL[1].altera_eth_channel_1588_inst|phy|xcvr_10gkr_a10_0|CHANNEL|DATAPATH_10G.NATIVE_PHY_10G_1588_644_LS.native_10g_1588_644_ls_inst|native_10g_1588_644_ls_inst|native_10g_1588_644_ls_inst|g_xcvr_native_insts[0].twentynm_xcvr_native_inst|twentynm_xcvr_native_inst|inst_twentynm_pma|gen_twentynm_hssi_pma_channel_pll.inst_twentynm_hssi_pma_channel_pll".
    Error(11654): Output port "VOP" of "HSSI_PMA_TX_BUF" cannot connect to HSSI port "RXP" of "HSSI_PMA_CDR_PLL" for atom "altera_eth_multi_channel_1588_inst|CHANNEL[0].altera_eth_channel_1588_inst|phy|xcvr_10gkr_a10_0|CHANNEL|DATAPATH_10G.NATIVE_PHY_10G_1588_644_LS.native_10g_1588_644_ls_inst|native_10g_1588_644_ls_inst|native_10g_1588_644_ls_inst|g_xcvr_native_insts[0].twentynm_xcvr_native_inst|twentynm_xcvr_native_inst|inst_twentynm_pma|gen_twentynm_hssi_pma_channel_pll.inst_twentynm_hssi_pma_channel_pll".
    Error(11654)
    
    HOW can I make channel 0 loopback to channel 1 on the chip?
    
    thanks a lot !
Deshi_Intel
Regular Contributor
5 years ago
Hi,

We don't support FPGA internal loopback from one transceiver channel to another transceiver channel. That's why you get design compilation error.
We only support FPGA internal loopback within the same transceiver channel from Tx channel back to Rx channel

Just would like to follow up with you - did you have a chance to play around with different signal_tap triggering setup to observe different signal_tap result between passing and failing case ?
Any latest debug update to share with me ?

Thanks.

Regards,
dlim
- mark_lee
  Occasional Contributor
  5 years ago
  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
Regular Contributor
5 years ago
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
  Occasional Contributor
  5 years ago
  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
    Occasional Contributor
    5 years ago
    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
Regular 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
  Occasional 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?
  phy_calibration.mp43.3 MB
  - mark_lee
    Occasional 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.
Deshi_Intel
Regular Contributor
5 years ago
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
Regular Contributor
5 years ago
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
  Occasional Contributor
  5 years ago
  Hi Deshi and Team
  
  Thanks for you help and time.