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.

C6678 SRIO problem



Hi,

I have two setups as follows:

- Development setup consisting of an EVM6678L dev board connecting to an FPGA dev board via SRIO.

- First spin of a production board which is essentially the two dev boards combined.

- Software is identical between the two (our SRIO test code and FPGA image).

The problem is that the SRIO works well on the development setup but not on the PCB we have. The symptoms vary from lack of PORT_OK at initialisation time to seemingly working tx or rx (but not at the same time).

Currently, we are consistently failing to perform an initialise. The fail manifests itself as a timeout waiting for the PORT_OK flag to be set.

I've checked the setup of the driver as far as I can and have done register comparisons between the good&bad setups. The most relevant clue to the issue appears to be in the LANE_STAT0 registers (we have a single lane) and the STS_SRIO register.

The documentation on quite a few of the registers relevant to this discussion seems to either non-existent or wrong (bad bit-counts, wrong table numbers, etc)

After a bit of a detective job figuring out the register definitions, the relevant differences at the point we have the failure (PORT_OK not set) are as follows:

STS_SRIO (0x02620154): LANE0 EQ_UNDER and LANE0 EQ_OVER are clear when it fails and set when it passes.

RIO_LANE_STAT0 (0x0290E010): CHG_SYNC is clear when it fails. ERR_CNT is 15 when it fails, 3 when it passes. RX_RDY is clear when it fails. RX_SYNC is clear when it fails.

So, from this I'm deducing that:

- The error count is very large (maxed-out at 15), but wont necessarily be 0 when it works correctly.

- Sync has not been acheived.

- Training has completed Ok (RX_TRN is set in both cases).

- Lack-of-sync is preventing the lane becoming ready, hence lack of PORT_OK.

- The equalisation is set to "Fully Adaptive", and has not set the EQ_OVER&EQ_UNDER flags in the bad case. The meaning of these flags is seemingly un-documented. These flags are only mentioned due to the differences, without any knowledge of the equalisation algorithm, I cant infer anything from these.

Other relevant information:

- The SRIO tracks are a small number of cm's long. its not expected that there will be any issue at all with that given that we are only running at the 2.5Gb/s rate.

- At times, we have had PORT_OK, but failed later on with either receive or transmit, so we have at least some basic connectivity

- We have confirmed out ip_clk is 312.5MHz and jitter is comparable to the working setup.

- PLL multiplier is set to 8x, RATE is a quarter, PLL is enabled.

Any advice or help on either the badly-documented registers/ equalisation algorithm or hints as to what direction to head in would be appreciated.

Cheers,

SteveT

  • Hello Steve,

    I am not able to precisely help with your problem, but I have had a lot of SRIO posts that have some good information about the registers.  If you search my name and SRIO, I think you might find some good discussions.  If you haven't seen this post already it might be a good place to start as it has links to some other informative posts.

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/170264.aspx

    While the documentation might be great, the TI was very good about helping us with our SRIO problems, so I am sure they will be able to solve yours!

    I'll watch the post too, just in case there is something I can think of to help.  When we were having connectivity problems (no PORTOK) on our custom board is was becuase the clock wasn't measuring precisely 312.5MHz.  Our scope led us to beleive it was correct, but when we got a better scope to double check, we realized it was off by 0.5MHz.

    Once the clock was right, the PORTOK was always available and it became an issue of setting up routing, ACKIDs and SERDES settings.

    Do you have a switch?  Are you using the Xilinx SRIO core on the FPGA or is it some other product and core?  If its Xilinx, I can at least tell you there is hope becuase our DSP talks to the Xilinx core through a switch successfully so it can be done! 

    Brandy