New Contributor
Regular ContributorHi Jayden ,
Lane 9 appears to decode the TS2 sequence correctly. Lane 8 shows COM (K28.5) and PAD (K23.7) correctly, but the symbols after that are unstable / corrupted.
>> I see you are using x16, do you occupied all of the 16 lane ?
>> Is it only lane 9 and lane 8 got problem and other lane act as what you expected ?
>> Do you tested in gen2 ? or this issue only seeing in gen1 ?
What mode of the pipe direct you trying to perform ?
Reset sequence or speed change ?
IF I understand correctly from your case description , I assume you are using reset sequence.
IF Yes, please check the signal sequence example under
https://docs.altera.com/r/docs/683501/25.1.1/r-tile-avalon-streaming-ip-for-pci-express-user-guide/pipe-direct-reset-sequence
Please do ensure that those sequence are strictly been followed.
Based on my experience and understanding , once the system entering polling.configuration substate, the a transmitter will stop sending TS1s and start sending TS2s, still with PAD set for the Link and Lane numbers. The purpose of the change to sending TS2s instead of TS1s is to advertise to the link partner that this device is ready to proceed to the next state in the state machine. It is a handshake mechaȬ nism to ensure that both devices on the link proceed through the LTSSM together. Neither device can proceed to the next state until both devices are ready. The way they advertise they are ready is by sending TS2 orderedȬsets. So once a device is both sending AND receiving TS2s, it knows it can proceed to the next state because it is ready and its link partner is ready too.
BUT I not sure what happening with your system, perhaps checking back the reset sequence can be a good start for us.
Regards,
Wincent_Altera
New ContributorHello Wincent,
Thank you for the reply.
Yes, I am using the x16 configuration, and all 16 lanes are occupied. After the reset release sequence, the link proceeds to Polling.Active and Polling.Configuration on all 16 lanes. However, the problem is that the lanes that receive consecutive TS1/TS2 correctly are not stable. The set of “good” lanes changes every time I reboot the server with the FPGA card installed. In other words, the behavior looks very random.
So to answer your questions:
For the PIPE Direct configuration, I am using:
Regarding your question about reset sequence or speed change:
At the moment, I am focusing on the reset sequence path.
I already built an RTL simulation environment and connected my soft IP in the same way as in hardware. In RTL simulation, the reset sequence itself appears to complete normally without any issue.
However, in SignalTap, I sometimes see unrealistic behavior, for example pin_perst_n_o continuing to toggle, possibly due to setup timing violations around the TX clock domain. Because of that, it is difficult to trust SignalTap captures for validating the reset sequence directly.
Do you have any recommendation for how to debug or validate the reset sequence in this situation, when SignalTap itself may be showing unreliable behavior due to timing issues?
I also have one additional question.
In the waveform shown in the following link:
PIPE Direct Reset Sequence
this is a Gen1 reset sequence, but even in Gen1, both ln0_pipe_direct_txdatavalid0_i and ln0_pipe_direct_txdatavalid1_i appear to go high.
However, in Figure 48, the PIPE Direct TX Data Path for Gen1 seems to show a format where only txdatavalid0 toggles.
Because of this, I am not fully sure which behavior should be considered correct during the reset sequence for Gen1.
Could you please clarify which one should be followed during Gen1 reset sequence?
Should I treat the reset-sequence waveform as the expected behavior, or should I follow the interpretation shown in Figure 48 for Gen1 TX datapath formatting?
Thank you again for your help.
Best regards,
Jayden
Regular ContributorHi Jayden ,
If referring to the Figure 49,
The pin_perst should asserted high at the beginning of the reset sequence.
Can you please show your timing report ? just want to see if the violation is valid or not (A printscreen will do)
Regarding your question on the txdatavalid shall be toggling or continuous be high, let me double confirm this on my place, get back to you shortly.
Regards,
Wincent_Altera
Regular ContributorHi Jayden ,
Regarding question for Figure 48 vs Figure 49.
if user need to perform reset-sequence , they shall follow figure49.
While figure48 is common practice for reference purpose only.
The reset release sequence diagram is primarily intended for the reset release relationship between the various signals For the actual data handling, the user should refer to the PIPE Direct TX Datapath and PIPE Direct RX Datapath figures. On the TX side, the tx_clkout is always at 500MHz. Depending on which speed you are in, the valid data on the TX path varies between Gen1 to Gen5 and needs to toggle accordingly On the RX path, the rx_clkout varies as per gen, so every clock cycle there is valid data between _0 and _1 signals
Hope this clarified.
Regards,
Wincent
