New Contributor
New ContributorHello Wincent,
Thank you for the clarification.
I have a few follow-up questions to make sure we correctly implement the reset sequence based on Figure 49.
1. TX data and txdatavalid behavior during the Figure 49 reset sequence
My understanding is that the reset sequence is performed at Gen1 speed.
If we follow Figure 49 exactly, should we keep both txdatavalid_0 and txdatavalid_1 asserted to 1, and drive TS1 Ordered Sets on txdata[9:0] during the reset release sequence?
Or, even during the reset sequence, should txdatavalid_0 / txdatavalid_1 follow the Gen1 valid-data pattern described in the PIPE Direct TX Datapath Figure 48? I am still confused.
As far as I know, after the reset sequence is completed successfully, link training should start from Detect and then proceed toward L0 according to the LTSSM(described in the figure above), where TS1/TS2 Ordered Sets are transmitted. I am not clear at which exact point or condition we should transition from the Figure 49 reset-sequence behavior to the normal PIPE Direct TX Datapath behavior described in Figure 48 / PIPE datapath figures.
Could you clarify the expected transition timing or condition?
2. Relationship between TX data transmission and cdrlockstatus assertion
In Figure 49, it looks like there is a timing relationship between points a through h/i/j/k, where tx_clkout becomes available, powerdown changes to P0 2'b00, and TX data can be driven, and points l/m/n, where cdrlockstatus is asserted and then reset_status_n_o becomes 1.
From the timing diagram, it appears that cdrlockstatus becomes 1 after TX data transmission has already started.
However, when I observe the current behavior using SignalTap, cdrlockstatus is already asserted to 1 on all lanes before TX data starts being transmitted. (I'm afraid the screenshot i have added might now be as clear, but you can probably see that cdrlockstatus for lane 0~8 are 1's and meanwhile there are txelecidle is 0xF for all lanes & no tx valid, tx data sent since phystatus_o pulse has not been seen for all active lanes(0~8 lanes, x8 config).
Is this an abnormal condition? Or is it expected behavior, and the Figure 49 timing diagram is only showing a conceptual relationship rather than a strict timing dependency?
3. Validation request to check whether this is board-specific
Lastly, I would like to understand whether this behavior could be related to our board environment.
If I provide the .sof file, the .stp file, and a simple guide mentioning a set of sticky/debug signals that make the behavior easy to observe, would it be possible for you to run the same validation on your board and check whether the same issue is reproduced?
The main purpose is simply to confirm whether pin_perst_n_o also briefly goes low and then returns high during the reset sequence on your side, or whether this behavior is only observed on our board.
This would help us determine whether the issue is related to the IP/reset sequence itself or something specific to our board/system environment.
Best regards,
Jayden
Regular ContributorHi Jayden ,
should we keep both txdatavalid_0 and txdatavalid_1 asserted to 1, and drive TS1 Ordered Sets on txdata[9:0] during the reset release sequence?
>> Do not hold txdatavalid_0/txdatavalid_1 high and do not drive TS1/TS2 during the reset‑release sequence.
>> While txelecidle_i is asserted, the PHY remains in Electrical Idle and ignores txdata/txdatavalid. TS1/TS2 placed on txdata would not be transmitted. reset‑release timing (Figure 49) shows Electrical Idle held and labels TX data as “NA” until reset is complete and the lane is in P0/Gen1.
>> During reset‑release if refer to the figure, it keep the transmitter in Electrical Idle (txelecidle_i asserted for all active lanes, e.g., 0xF for x4) and treat txdatavalid_0/txdatavalid_1 as deasserted/don’t‑care. The PHY ignores TX data while in Electrical Idle.
>> Switch to the normal PIPE Direct TX datapath behavior (your Figure 48) only after the PIPE Direct reset sequence is complete and the lane is in P0 at Gen1 and ready. At that point, exit Electrical Idle and begin link training; when you start sending TS1/TS2, drive txdata[9:0] with the ordered sets and strobe txdatavalid_0/txdatavalid_1 per the Gen1 valid‑data pattern shown in the TX datapath figure.
Is this an abnormal condition? Or is it expected behavior, and the Figure 49 timing diagram is only showing a conceptual relationship rather than a strict timing dependency?
>> The table is something we tested internally and proven 99.9 % of the function is working well in such situation.
>> Hence, I would suggest you to follow it, except there is a special requirement on your project (who blocking you from following it).
>> from your waveform, the cdrlock2data start to be high before the phystatus is asserted. do you do the transition of powerdown from P1 to P0 ? or all the way it is P0 ?
If I provide the .sof file, the .stp file, and a simple guide mentioning a set of sticky/debug signals that make the behavior easy to observe, would it be possible for you to run the same validation on your board and check whether the same issue is reproduced?
>> I would suggest you to check directly with the Distributor's FAE on this request.
Regards,
Wincent_Altera
