• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 390 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SRIO back pressure question on c6472

SNBANIK
Intellectual 645 points

I have a situation where the DSP (c6472) sends 2D frames out to the Back End (BE) DDR memory. I have setup the SRIO for peak data transfer rate of 2.5 Gbps (3.125 Gbps with 10/8). That leads to a data transfer BW of 300MBytes per second plus. The DDR in the BE could sometimes be in a state where it can only sustain a rate much lower than 300 MBytes per second because of other activities happening in the BE. Even in many other cases, it may be difficult for BE to sustain 300plus MBytes per second access rate (for the output from DSP).

We will be sending our output from DSP DDR.

My question is what happens in that case? Does the SRIO end point IP automatically take care of back pressure leading to overall rate dropping lower than peak? Or do we need to build a pacing mechanism using a GPIO?

In the case of former (that is automatic pacing) - does it lead to multiple retransmissions? is there any cost associated with that mechanism that we need to be aware of? Example does the automatic back pressure mechansim cause the switched central resource or any other resource within the DSP to slow down?

What would be a good document to study for such questions?

Somnath Banik 

  • 0
    TI__Mastermind 23525 points

    Somnath,

    The SRIO peripheral is somewhat self throttling for RX and TX data.   If packets can not proceed in either direction across the link, due to lack of buffer resources, then the protocol dictates that physical layer RETRYs are used on the link.  Packets in this case are resent by SRIO hardware, so no software is needed.  No if forward progress is stalled too long, then you can definitely see outbound credit completion codes, and perhaps timeouts in extreme cases (and depending on the traffic types).  Your software should be able to handle these cases, and if so, I wouldn't expect any issues.  The SRIO peripheral itself has a limited number of VBUS requests that it can have outstanding at any given instant to the internal VBUS fabric (SCRs), so there is no concern with affecting the device data flow or locking up the fabric resources.

     

    Regards,

    Travis