Forum Discussion
New ContributorSerialite II Issue
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,
- CheepinC_altera
Regular Contributor
Hi,
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.
- ChunyeHong
Again, let me answer your question one by one.
1. This is really hard to do. We first observed this problem in our system, with multiple boards in the chain in different cabinet. It is duplex link but we only use it for one direction, FPGA1 to FPGA2. The end product of this is the RF signal came out wrong then we realized there is a problem then we put in signaltap at each stage and suspect it is FPGA1. I could put a loop back at FPGA1 output but I can only test it by putting signal tap on FPGA1 Rx. Since we don't use this direction, that is quite a bit change and again every time we make changes to the design or even no change just recompile the problem goes away. Second, if we put FPGA1 loopback, FPGA2 won't detect a link the system software will not run and create packets. We have to change the software to make the test. That is quite some exercise.
2. Same reason as 1. And I really doubt it is the phy, transceivers or high speed serial link itself, since our system software monitors those error siganls like err_rr_8berrdet, err_rr_disp, err_rr_pol_rev_required, overflow, underflow etc signals all the time and has counter on those to count how many times they happens. the error counters stay error. i am convinced that it is not link layer but somewhere above.
3. Again, i doubt it is link layer and below problem. One more piece of information, at the beginning, we used streaming mode for seriallite and never saw this problem. about one year ago, we change this link to packet mode, this problem started to show up. that further indicates it is something in the seriallite core.
Thank you
