Forum Discussion
Deshi_Intel
Regular Contributor
6 years agoHI,
The reason I asked for simplified debug design is due to your system is quite complex with a lot of design blocks that interact with TSE IP on both software and hardware level.
- Unfortunately I am not familiar with the overall system level design but I do can try to help out on TSE IP debug. That's why I asked earlier whether can you duplicate this issue using simpler design that maybe just contains a RTL design logic driver that interact with TSE IP only.
Regarding the signal_tap issue on RGMII interface
- You can't probe RGMII interface due to it's hard design block inside FPGA. Signal_tap which is is soft logic design can't access and probe on the the hard block. Detail in KDB link below
- https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/solutions/rd03122014_936.html
- However, you do can probe on TSE MAC another side avalon ST port to ensure the data packet arrived TSE MAC successfully
As for the debug plan that you suspected TX data transfer maybe failed on TX RGMII output
- The reason I suggested for the MAC RGMII loopback test is basically to confirm on your finding where does the TX packet disappear exactly ? Is it insides FPGA or outside FPGA ?
- Alternate way will be to probe on the board txd[3:0] bus to observe is there any data transaction or not since you mentioned external PHY component didn't received the data packet.
- Also, have you double check to ensure your Quartus design is timing clean by studying the Quartus timequest report ?
Thanks.
Regards,
dlim