Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

PCIe HIP and Credits

I am using a SIV with the PCIe HIP. I have a functional application layer using DMA and things are running well. So why am I writing?

Recently, I re-wrote much of the TX path to increase bandwidth. During my iterations, I temporarily removed the credit checking mechanism I wrote and ran some tests with SignalTap. Based on my observations, I saw credits being consumed (only P_DATA). I was concerned that the core might lockup when credits ran out, but I noticed that the core would de-assert tx_ready when credits got low. To my surprise, I could DMA data ~3GBps (Gen2 x8) with credits consistently running out and throttling being handled by the ready flag from the core.

Does this mean that manual credit checking is unnecessary, as the core will handle cases when the credits go too low? Seems unlikely. Have others observed this? What approaches to credit checking have you implemented?

Thanks for the advice!

Jay

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Got my answer by opening a service ticket....

    "After further study, I found that it's optional to implement the credit checking mechanism. Sorry for the previous confusion.

    From reading the PCIe user guide, it has some statements in multiple locations.

    - bullet point# 1, pg77: " The IP core uses [...] tx_cred[35:0] for the hard IP implementation. The application layer may choose to ignore this information."

    - bullet point# 3, pg77: " The IP core verifies that sufficient flow control credits exist, and acknowledges or postpones the request"

    The PCIe core will always checks for sufficient credits before acknowledging a request.

    However, by checking available credits with this signal, the application can improve system performance by dividing a large transaction layer packet

    into smaller transaction layer packets based on available credits or arbitrating among different types of transaction layer packets.

    The only reason for application layer to implement credit checking is if user wants (optionally) to perform an additional layer of optimization.

    The Altera design example ignore credit checking because it doesn't perform this level of transmit optimization for application.

    I sincerely hope the responses in this service request have addressed the questions."