New Contributor
Regular ContributorHi,
Thanks for your update. You are right, the main purpose of us running the simulation here is to help isolating potential functional issue to further narrow down the issue. Glad to hear that there is no issue with the simulation.
Thanks for sharing that after changing the signaltap logic, the problem goes away. This is trending toward potential timing issue. Just would like to clarify with you on the following:
1. When you mentioned two EOPs for every SOP, I believe you are observing this in signaltap. Is my understanding correct?
2. When the issue occur in signaltap for a specific lane, do you observe failure in that SL lane as well? Just to further isolate out if it is signaltap only issue or SL lane issue. For example, potential timing issue which cause signaltap sampling error.
Please let me know if there is any concern. Thank you.
Best regards,
Chee Pin
New ContributorChee Pin,
Thanks for the reply. I will answer your question one by one.
1. Yes, but in the down stream device. Let's name the device that sources the traffic and we suspect causing the problem is FPGA1, the down stream device that receives all the packets on SerialLite is FPGA2. We put signaltap in FPGA2 at the Rx Atlantic interface out of the seriallite and saw the words are out of order in the packets and sop and eop do not match each other. We also put signaltap in FPGA 1 at Tx atlantic interface input right before seriallite and did not see any problem while problems were observed at signaltap in FPGA2. The reasons that we believe the problem is in FPGA 1 Tx is that problem goes away for every first run after we reset seriallite in FPGA 1, and FPGA 1 only. Problem comes and goes only when we recompile FPGA1, not FPGA 2. We recompiled FPGA 2 many times and nothing changes.
2. This is bonded 4 lane link. And overall link status signal "stat_rr_link" never goes down even when the problem shows up. We never put signaltap at the lane level since it is not going to be of too much use to us. Again, seriallite is encrypted and it is a black box to us. We pull signals out in signaltap but we don't know what we are looking at without source code. I would assume byte alignment, word alignment and lane bonding all work since words are out of order on 64 bit word boundary, not individual bit or byte. Plus, link never goes down. In signaltap of both FPGA, we basically use the clock at the atlantic interface to clock the data, they should be the signals for the right clock. There is no setup violation in the timing report. No unconstrained clock.
Thanks
New ContributorChee Pin,
If you would like, I can send you some signaltap waveforms. But not on this forum, because of IP and security concerns.
Thanks,
Regular ContributorHi,
Sorry for the delay. Thanks for your update. I understand that there are two FPGAs where you are suspecting that the issue is cause by the upstream FPGA1. When you recompile the FPGA1 design, the error might goes away. There are 4 bonded lanes in the design.
Before we further engage our timing team, would you mind to help test on the following:
1. With the failing build, can you perform loopback from the FPGA1's TX back to its own RX to see if issue occurs. This would be helpful to narrow down to FPGA1 only. If there is any issue at the SL IP in FPGA1 TX, its own RX should see similar error as FPGA2's RX.
2. You can try the loopback with both internal serial loopback and external loopback to see if there is any difference.
3. If there is no issue with internal and external loopback, you might want to look into if there is any potential trace length mismatch in the connection between FPGA1 and FPGA2 to narrow down connection issue.
Please let me know if there is any concern. Thank you.
