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 Latency time

Other Parts Discussed in Thread: TMS320C6678

Hi,

  I would like to know about the sRIO latency time to the data output of the sRIO after DSP kicking. It is connected with SRIO (4x mode) between a DSP (TMS320C6678) and FPGA. When the data has been sent to the FPGA from the DSP, I measure the time until the first data reach the FPGA from the start transmitting by DSP. At the result, I got 2 latency times about 810nsec and 430nsec. Either one latency time keeps until power off.

Quetsions:

1)    Why are there 2 types latency time?

2)    Are there how to shorten the latency time more?

Regards,

Kenshow

  • Hi Kenshow,

    Can you provide more information:

    1. Are you running the SRIO MCSDK example project? For the test project, what is the MCSDK/PDK release version and project name?

    2. Are you getting 2 different latency times for the same project?

    If configured the SRIO as 1x mode, it is possible to shorten the latency time more.

    Thanks, 

  • Hi,

     I reply your about questions as follows:

    > 1. Are you running the SRIO MCSDK example project?

    C:\ti\mcsdk_2_01_02_06\tools\boot_loader\examples\srio\srioboot_example\src\srioBootExample.c
    C:\ti\pdk_C6678_1_1_2_6\packages\ti\drv\srio\device_srio_loopback.c

    > 2. Are you getting 2 different latency times for the same project?

     Yes. 

     Is there a possibility that can get 2 different latency times in general system?

    Regards,

    Kenshow

  • Hi Kenshow,

    One possibility that you get two different latency is because of cache impact. If the data sent from DSP is already in L1/L2 cache, the latency would be lower. You may try to disable cacheability of the memory that contains testing data to verify it.
     
    Thanks,
  • Hello,

    I’m sorry for the delay reply.

    I don’t have time for this confirmation, now. I’ll reply if I can check it.

     

    Thanks,

    Kenshow

  • Hi,

     We checked the latency time as cache disable, but  we still get 2 different latency times. I think that this is not cache impact.

    Thanks,

    Kenshow

  • Hi Kenshow,

    My understanding it is related to cache impact. I will work with my team and get back to you.

    Thanks,

  • Hello Ganapathi,

     Can you get any information about them? Do you have any Latency information of sRIO as TI testing? 

    Regards,

    Kenshow

  • Hi Kenshow,

    What speed do you have SRIO configure for? Can you confirm you are using type 11 message passing in the TI SRIO loopback example?

    Can you also clarify what you mean when you say "Either one latency time keeps until power off"? Do you mean each time you transfer after the system is running there is a specific latency associated for the 1st packet to arrive? Or do you mean you observe this latency only for the very 1st packet after boot?

    The latency times you listed seem reasonable. These numbers will be dependent on your specific system configuration.

    Thanks,

    Clinton

  • Hi Clinton,

     Because I also thought that this issue depends on the specific system configuration, I gave up this investigation about difference of two latency times. My purpose of this question was how to shorten the latency time. I heard that sRIO latency is very slower than FPGA’s one. Our application periodic cycle time allows in 3 micro seconds. So, the system is occupied by sRIO latency time.

     

    I answer your question as follows:

     The speed was 3.125G. I hadn’t confirmed type 11.

    "Either one latency time keeps until power off" mean each time I transfer after the system is running there is a specific latency associated for the 1st packet to arrive.

     

    If you have any information how to shorten the latency time, please let me know.

     

    Best regards,

    Kenshow

  • How are you measuring the latency?  It can be a tough thing to do especially when going device to device.  With NWRITE.  If you are getting two very consistent numbers like that, I'd say something is probably not correct in the measurement method.  I'd suggest a couple of things to try...  first, put the DSP in loopback and make some measurements there by starting a timer, kicking off a TX transaction and polling on the RX memory location until the payload arrives.  If this is working and seems reasonable, you can move to device-to-device, using an NREAD with the exact same measurement technique (all measurement i.e. start and stop by the DSP).  Trying to measure NWRITE device-to-device will be tough to get accurate and will need a different technique, such as sending two packets (2 LSU programming) and measuring the time from the last byte of 1st packet received to the last byte of the 2nd packet on the RX side.  We don't measure latency, only throughput in our throughput report http://www.ti.com/lit/pdf/sprabk5 because in a packet based system it depends heavily on the traffic and priorities, etc.

    Regards,

    Travis

  • Hi Travis,

     

      Thanks for your advice.

      I also did loopback test with C6678 EVM for measuring of latency that is from LSU set to 1st data received on L2 memory. I used TSC register for measuring. This testing was only used sRIO transfer with no any other transfer. It takes 1.9 usec in this test.

     Best regards,

    kenshow