• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 873 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.

TCI6638K2K: SRIO Benchmarking Example Code

P-F Wolfe
Prodigy 40 points
Part Number: TCI6638K2K
Other Parts Discussed in Thread: 66AK2H12,

Hello, here’s some background:

I am developing with a Keystone II EVM (XTCIEVMK2X Rev 1.1: http://www2.advantech.com/Support/TI-EVM/EVMK2HX.aspx) as a stand in for a custom board using a 66AK2H12.

Previously, a team member of mine was able to demonstrate data transfer from an FPGA to the 66AK2H12 on our custom board using all four SRIO lanes and receiving the data on the SoC with a program that relied on the SRIO driver in Processor SDK Linux version 03.03.00 (Linux was running on the ARM cores).

Since support for the SRIO driver was dropped from later Processor SDK Linux releases (see PLSDK-1421) but remains in TI-RTOS which we were always planning on using on the DSPs I have been trying to work towards replacing the former with the latter.

I decided to start off small, with some of the example programs provided with Processor SDK RTOS (I am using ti-processor-sdk-rtos-k2hk-evm-04.03.00.05). Specifically I was trying to work with the SRIO tput_benchmarking test project (C:\ti\pdk_k2hk_4_0_9\packages\ti\drv\srio\test\tput_benchmarking) since it appears to offer a number of different modes to test where I could build up my understanding of the configuration required. I generated the project (alongside some of the other examples) without problem

C:\ti\pdk_k2hk_4_0_9\packages>pdksetupenv.bat "C:\ti\pdk_k2hk_4_0_9\packages"
C:\ti\pdk_k2hk_4_0_9\packages>pdkProjectCreate.bat K2K all little srio all dsp "C:\ti\pdk_k2hk_4_0_9\packages"

And successfully built it in CCS and ran it in the default mode (C-I-C) on cores 0 and 1.

According to the documentation in section 9.2 of SRIO_Benchmarking_Example_Code_Guide.doc (found under C:\ti\pdk_k2hk_4_0_9\packages\ti\drv\srio\test\tput_benchmarking\docs) it should be possible to simply change the USE_LOOPBACK_MODE definition in benchmarking.h from TRUE to FALSE in order to run the tests in C-E-C mode. The main difference I see is that instead of calling CSL_SRIO_SetLoopbackMode for each lane, CSL_SRIO_SetNormalMode is called instead.

I have the AMC SMA Ultra 9000 breakout board from Silicon Turnkey Express and all four lanes for SRIO (8-11) connected in loopback Tx+->Rx+ etc (section 5.2 of the guide document). When I build and try to run this mode (I also have DISPLAY_RUN_PROGRESS_MESSAGES set to true in benchmarking.h) this is what I see:

[C66xx_1] ********************************

*********** PRODUCER ***********

********************************

WARNING: Please ensure that the CONSUMER is executing before running the PRODUCER!!

Debug(Core 1): Waiting for SRIO to be initialized.

[C66xx_0] ********************************

*********** CONSUMER ***********

********************************

WARNING: Please ensure that the CONSUMER is executing before running the PRODUCER!!

Debug: Queue Manager and CPPI are initialized.

Debug: Waiting for module reset...

Debug: Waiting for module local reset...

SRIO Serdes Common Init Complete

SRIO Serdes Lane 0 Init Complete

SRIO Serdes Lane 1 Init Complete

SRIO Serdes Lane 2 Init Complete

SRIO Serdes Lane 3 Init Complete

SRIO Serdes Init Complete

Debug: Waiting for SRIO ports to be operational...

Debug: SRIO port 0 is NOT operational.

 

*Note: I cropped the subsequent output since the port isn’t operational and the tests don’t run

**Also Note that despite what the output messages say, core 0 (consumer) was started first, the messages only print after both cores are running…

Digging into where the “SRIO port 0 is NOT operational” message is not generated I can see that that it is due to CSL_SRIO_IsPortOk never returning a good port status (the function call stack is: main -> SrioDevice_init -> waitAllSrioPortsOperational -> CSL_SRIO_IsPortOk). By default, there is a timeout of 5 seconds but even eliminating that and waiting forever, no progress is made. Taking a peek at the Port General Control CSR using the register view in CCS, I can see that as expected bit 30 (Port OK) is indeed unset and that bit 31 (Port uninitialized) is set. My understanding is that either the port as wired/configured is never getting an idle control symbol or is not establishing proper input sampling window timing alignment (Sam Fuller, RapidIO The Embedded System Interconnect, pg 127-128).

I am not quite sure why I am running into this issue and I have tried a number of other examples to see if I could Identify a difference in initialization and I have been able to make internal loopback function properly but not had luck with external loopback in those either with the same issue, that the port never gets properly initialized.

Does anyone have any ideas about what is incorrect with my configuration or what additional information I can provide that would help in determining the issue? I believe I have the breakout card and loopback cables properly connected. I am less sure about there being some issue related to the silicon revision of the board (I see several suspects in sprz401f.pdf, the TCI6638K2K Silicon Errata). I feel that I could easily have missed some additional configuration step when I was looking over the approach taken in the example.

Any insight is appreciated, thanks.

  • 0
    Prodigy 40 points

    Okay, I've continued trying to solve this issue by digging deeper into what specific CSL calls are made and registers touched (without any particular success to show for it).

    Starting off I wanted to make sure incorrect loopback settings weren’t being configured. I identified three registers of potential interest with several fields that I wanted to check:

    PLM_SP(n)_IMP_SPEC_CTL (pg 236, sprugw1b)

    DLB_EN (For digital loopback, since I’m trying to use the breakout board I don’t want this set)

    LLB_EN (For line loopback, I’m trying to transmit out on a port and receive on the same port, this allows data received to be automatically sent back out bypassing a processor, again, not relevant)

    PER_SET_CNTL1 (pg 164, sprugw1b)

    Loopback[3-0] I want Normal operation here because Loopback takes place before the SERDES block.

    Lane_000 (pg 79, spruho3a)

    NEW_LB_ENA_O (Near End Serial Loopback, I don’t want to loopback the SERDES internally so this field should remain unset).

    The other fields in this register are used for configuring a Far End Loopback (pg 153 spruho3a) which is also internal and not desired for my current tests.

    After considering these, it seems that setting USE_LOOPBACK_MODE False in benchmarking.h as instructed ensures that PER_SET_CNTL1->Loopback is in Normal mode and that all of the fields mentioned in the other two registers remain in their default states. This all seems correct but doesn’t solve my problem…

    So, taking another look at the TCI6638K2K errata (sprz401f) for version 1.1 of the silicon I see Advisory 13 and 16 relate to SRIO and Advisory 44 and Usage Note 28 to SERDES.

    Advisory 13 concerns SRIO line loopback and (as mentioned before) if I understand correctly, I don’t need and irrelevant to me.

    Advisory 16 concerns a bandwidth reduction and has no workaround so I can ignore it

    Advisory 44 seems like it might matter to me (I’m not quite sure) but regardless, I have yet to find CSL_SerdesAttBoostPatch() mentioned in the workaround section…It seems that others before me couldn’t find it either though they were using pdk_k2hk_4_0_2 while I am using pdk_k2hk_4_0_9: https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/624391

    Usage Note 28 also seems potentially relevant and hopefully more tractable. I will attempt to perform the BER test with PRBS sequence as suggested. Perhaps I will gain some more information from doing so. I'll update if this leads to anything fruitful.

    Finally, I have also started making a list of all of the registers modified by the SRIO driver from Processor SDK Linux and those modified in the TputBenchmarking test. If all else fails maybe I can glean something by comparing the differences in initialization/configuration…

    If anyone has any ideas, even if only where I should look next, please let me know.

    Thanks.

  • 0 in reply to P-F Wolfe
    Prodigy 40 points
    Short update: After probing some of the outputs on the AMC to SMA breakout board being used it became clear that there was no SRIO traffic on Lanes 8, 9, 10, or 11 as expected. Instead there is traffic on Lane 0. When Lane 0 is connected in external loopback (Tx <-> Rx on the breakout board), whether or not any of the the other lanes are still connected in loopback, the TputBenchmarking program reports that Srio port 0 is operational and goes on to run the tests (seemingly successfully). While I'm glad to see something different I don't understand why Lane 0 is being used. All of the documentation that I have read indicates that AMC Lane 0 is is connected to SGMII2 (and AMC Lane 1 to SGMII3).

    Are there any ideas why there is this seeming contradiction in expected behavior? Considering the SRIO registers are the ones being configured I don't see how SGMII or Lane 0 come into play.
  • 0 in reply to P-F Wolfe
    Prodigy 40 points
    Solved! Turns out it was an unfortunate oversight when connecting the EVM and breakout board. The Lane 0 connection lines up with Tx9 and Rx8 if the AMC connector is plugged in flipped in the wrong direction... That explains the mysterious SRIO signals on SGMII... With all four lanes looped as before and the breakout board properly connected the C-E-C test runs as expected. Hopefully anyone else in doubt checks their AMC orientation sooner than I did...