Forum Discussion

Abhi_Krishnan_R's avatar
Abhi_Krishnan_R
Icon for New Contributor rankNew Contributor
2 months ago

PCIe Hard IP - Can 'valid' De-assert Between SOP and EOP During DMA Read Completion?

Product / IP: Intel PCIe Hard IP (Avalon-ST Interface

Device Family: Cyclon 10 GX

Reference Manual: 

https://docs.altera.com/r/docs/683647/18.0/arria-10-and-cyclone-10-gx-avalon-streaming-interface-for-pci-express-user-guide/datasheet

I am an FPGA Design Engineer currently working on verifying the application layer logic interfacing with Intel's PCIe Hard IP over the Avalon Streaming (Avalon-ST) interface.

As part of the verification effort, I have developed an Avalon-ST Bus Functional Model (BFM) that mimics the RX-side behavior of the PCIe Hard IP — specifically, how it presents TLP data (DMA Read Completions) to the downstream application logic.

During simulation, my BFM generates scenarios where the 'valid' signal is de-asserted between 'startofpacket (SOP)' and 'endofpacket (EOP)' — i.e., mid-packet gaps or "bubbles" are introduced within a single TLP transfer. When this occurs, the application layer logic does not handle it correctly, causing functional failures.

Before proceeding with fixing the application logic to handle this case, I need to confirm from Intel whether this behavior is actually possible on the real PCIe Hard IP hardware

Question 1: On the RX Avalon-ST interface, when the PCIe Hard IP is acting as the SOURCE (driving TLP completion data toward user application logic), is it possible for the 'valid' signal to be de-asserted between SOP and EOP within the same TLP packet?

Question 2: If yes, under what conditions can this occur?

Question 3: Does the Intel PCIe Hard IP Reference Manual explicitly document this behavior anywhere? If so, could you point to the relevant section?

Pcie
Transceiver

8 Replies

  • Wincent_Altera's avatar
    Wincent_Altera
    Icon for Regular Contributor rankRegular Contributor
    1 month ago

    Hi Abhi_Krishnan_R ,

    For the behaviour of rx_st_eop/sop. I think you can refer below document as a reference
    https://docs.altera.com/r/docs/683059/25.1.1/p-tile-avalon-streaming-fpga-ip-for-pci-express-user-guide/avalon-st-rx-interface-rx_st_ready-behavior

    For C10 device, you may check under AVST interface section
    https://docs.altera.com/r/docs/683647/18.0/arria-10-and-cyclone-10-gx-avalon-streaming-interface-for-pci-express-user-guide/interfaces-and-signal-descriptions

    Regards,
    Wincent_Altera

    • Abhi_Krishnan_R's avatar
      Abhi_Krishnan_R
      Icon for New Contributor rankNew Contributor
      1 month ago

      Hi Wincent_Altera​ 

      Thanks for your response. I have gone through the references you provided.

      In the first link, the explanation mainly about application-side throttling when PCIe acts as the source. However, my concern is whether the PCIe IP itself can throttle the bus while transmitting data(Source), particularly during DMA operations.

      I also reviewed the interface section in the second reference. It similarly mentions only application-level throttling, and I could not find any details indicating whether the PCIe core independently throttles the bus, or under what conditions it might do so.

      Could you please clarify if the PCIe IP has any mechanism to throttle the bus during DMA transfers(when PCIe act as a source), or if throttling is entirely controlled by the application logic?

      • Wincent_Altera's avatar
        Wincent_Altera
        Icon for Regular Contributor rankRegular Contributor
        1 month ago

        Hi Abhi_Krishnan_R​ ,

        In normal operation of PCIe IP design example provided by Altera , the throttle/bubble is not a normal operation. Regarding throttling based on my experience and understanding on RX (PCIe → user), throttling is governed by your application through rx_st_ready. The PCIe HIP does not arbitrarily throttle mid‑packet while ready remains asserted; it responds to backpressure and streams at the interface clock rate otherwise.

        If you want to stress the design, I would suggest to de‑assert rx_st_ready for arbitrary spans within a TLP and verify proper resume to EOP. To be honest I do not have any exact answer as this is something customize and I never try before, Hope my suggestion able to help you to move a step forward.

        Regards,
        Wincent