Forum Discussion

Jayden's avatar
Jayden
Icon for New Contributor rankNew Contributor
7 days ago

PIPE Direct Reset Release Sequence

Hello,

I am debugging R-Tile Avalon Streaming FPGA IP for PCI Express in PIPE Direct mode on an Agilex 7 device.
My goal is a custom PCIe/CXL soft controller. I was originally targeting x16, but I am currently reducing the setup to x1 for bring-up/debug.

I have questions about the PIPE Direct Reset Release Sequence (Figure 50).

 

  1. Clock domain for reset release control
    It is not clear to me when ln0_pipe_direct_pld_tx_clk_out_o becomes valid enough to be used for control sequencing.
    Should lnX_pipe_direct_pld_pcs_rst_n_i be released(Step 4 in Figure 50) by logic clocked with ln0_pipe_direct_pld_tx_clk_out_o after lnX_pipe_direct_tx_transfer_en_o (Step 3 in Figure 50)is observed, or is it acceptable to control this sequence from another stable FPGA system clock domain with synchronization?
  2. SignalTap trigger for reset release debugging
    I tried using ln0_pipe_direct_pld_tx_clk_out_o as the SignalTap clock and triggering on the first rising edge of lnX_pipe_direct_phystatus_o(Step b in Figure 50)during DETECT, but I cannot reliably capture that pulse. What is the recommended trigger/event to verify that the reset release sequence is operating correctly in hardware?
  3. Missing phystatus_o before cdrlockstatus_o in P0
    From Figure 50, I expected a phystatus_o pulse (Step g in Figure 50)in the P1 power state before cdrlockstatus_o asserts. In my test, that phystatus_o pulse does not appear, cdrlock2data_o never becomes 1(Step m in Figure 50), but reset_status_n_o still goes high (Step n in Figure 50), in conclusion the raw RX data from PIPE Direct IP appears corrupted/unstable.

Is there a known reason this can happen?

Also, I would like to verify this reset release sequence in RTL simulation, not only on hardware.
However, for PIPE Direct mode, there are no example design available, so at the moment I do not have a way to validate this behavior with RTL simulation.

If anyone has experience debugging Figure 50 on real hardware, I would appreciate guidance.

Thank you.

1 Reply

  • Wincent_Altera's avatar
    Wincent_Altera
    Icon for Regular Contributor rankRegular Contributor
    3 days ago

    Hi Jayden ,

    Question 1,
    I am recommended to release lnX_pipe_direct_pld_pcs_rst_n_i (Step 4) in the domain of ln0_pipe_direct_pld_tx_clk_out_o, or at least synchronously to it. This ensures the reset release and subsequent logic initialization are properly aligned with the TX clock domain, avoiding metastability and timing issues. While you can use another clock with CDC (clock domain crossing) synchronizers, doing so adds complexity and risk. If you must use a different clock, you must guarantee that the de-assertion is properly synchronized into the TX clock domain, typically with a multi-flop synchronizer.

    Question 2,
    Increase your SignalTap pre-trigger buffer to capture events before and after your trigger, so you can see the full sequence.

    Question 3,
    I have work with few other customer before, and they are able to bring up the phystatus and cdrlock2data.
    IF this happen, I would suggest you to check back your logic carefully. few of the common mistake will be make sure lnX_pipe_direct_powerdown_i follows the correct state transitions (P1 → P0 as per PIPE). Double-check reset release timing: Ensure lnX_pipe_direct_pld_pcs_rst_n_i is released after lnX_pipe_direct_tx_transfer_en_o and the TX clock is valid. It is quite hard to narrow down in one single reply, But I hope I am able to provide the best tips for you to narrow the issue quicky.

    This guide is helpful for your logic designing, perhaps you can refer
    https://www.intel.com/content/www/us/en/io/pci-express/phy-interface-pci-express-sata-usb30-architectures-3-1.html

    However, for PIPE Direct mode, there are no example design available, so at the moment I do not have a way to validate this behavior with RTL simulation.

    If anyone has experience debugging Figure 50 on real hardware, I would appreciate guidance.
    >> We do have technical Partner that is fully validate this in real HW design.
    >> IF you need a turnkey solution do consult your local Altera Distributor/sales to get the partner name.
    >> or else, me and the community contributor will continue to ensure your success via this forum platform.

    Regards,
    Wincent