Not Receiving Type-11 messages from Vertex 7 SRIO IP

Hi,

The default tput_benchmarking project example is configured for internal loopback mode. Have you referred the SRIO Benchmarking Example Code Guide document to modified the project for your testing(SRIO switch)? If no, refer section "9.5 Setting up B-S-B connection mode (board to board, with a SRIO switch)" to make sure your changes.

Doc Path: \pdk_C6678_1_1_2_6\packages\ti\drv\srio\test\tput_benchmarking\docs\SRIO_Benchmarking_Example_Code_Guide

The example support type 9 and type 11 SRIO transfers, type 11 transfer only not working or both type transfers are not working on your setup.

Thanks,

Thank you for responding.  

I have read through the SRIO Benchmarking Example Code Guide document. I had the env set to B-E-B (board to board, external interface) because there are no switches used between the FPGA and 6678 (their SRIO traces are a direct connect between the two devices).  If there are no switches in the path isn't this the correct setting.

I am only running with type-11 transfers because that is all our FPGA supports for SRIO ( I am using the ENV below).

The question was:

We noticed that for messages coming out the FPGA that the start of the message header is on lane 1 versus the messages coming out the DSP message header starts on lane 0. Could this cause alignment problem with SRIO decoder on the 6678?

#define SRIO_LANE_SPEED                   srio_lane_rate_5p000Gbps

#define SRIO_PORT_WIDTH                   srio_lanes_form_one_4x_port

#define TESTS_TO_RUN                   srio_type11_tests 

#define IS_BOARD_TO_BOARD                 TRUE

#define IS_OVER_EXTERNAL_SRIO_SWITCH      FALSE

#define USE_LOOPBACK_MODE                 FALSE

#define USE_SRIO_16_BIT_ID                TRUE

#define RUN_LATENCY_MEASUREMENT           FALSE

#define MESSAGE_INITIAL_DATA_SIZE         (256)

#define MESSAGE_MAX_DATA_SIZE             (256)

#define CONSUMER_CORE                 0x0
#define PRODUCER_CORE                  0x1

#define CORE_TO_INITIALIZE_SRIO        CONSUMER_CORE

#define PRODUCER_16BIT_DEVICE_ID        0x1234

#define CONSUMER_16BIT_DEVICE_ID       0x7ABC

#define CONSUMER_MBOX                 SRIO_TYPE11_RX_ACCEPT_ALL_MBOX_VALUE

#define CONSUMER_LTR                   0x1

Hi,

This test code is designed to use one core for the Consumer (Receive side) and one core for the Producer (Transmit side). The Consumer side is started first and then the Producer side is started. The Producer side is designed to transmit as fast as it can with the Consumer side monitoring and letting the Producer know when packets have been dropped. When packets are dropped the Producer will go into a pacing search mode to determine the minimum delay needed to transfer packets without losing any.

Have you implement the same procedure on FDGA side test code?

Thanks,

Jeff,

The odds are that if the DSP and FPGA are sending their message headers on different lanes, then either 1) it does not matter which lane is used or 2) the DSP is right by definition that it is not possible to be changed and the RapidIO spec would be the governing document. I do not have that spec, but your FPGA IP suppliers should be able to tell you what the answer to that is.

Can you try running in x1 mode to take this out of the equation and see if you are able to communicate correctly?

Do you have access to the FPGA IP to tell it to use Lane 0 instead?

Regards,
RandyP

Hello Randy,

Today we are trying with one lane. However I am seeing differences in the transmitted data from FPGA to DSP between 4 lanes and 1 lane.

I wanted to attach screen snapshot or paint file, but could not do so here. I can email them to you. If you can take a look at it and see what could be causing the problem, that will be very helpful.

Regards,

Ram

Ram,

Attachments or inserted pictures are not as obvious to me on the forum as they used to be. Please continue trying to do it here. This discussion needs to remain on the open forum. I am not the expert to look at anything.

If you are seeing differences in the transmitted data from FPGA to DSP, then there is not going to be anything we can help with. You will need to contact the FPGA module vendor for support.

Your experiment has done well to help establish a point of problem.

Regards,
RandyP

Hello,

Here is the data output from the FPGA for 4 lanes:

Cycle 1:

  gttx_data[31:0]     :  0x1c_bc_7c_01         gttx_charisk: 0x4

  gttx_data[63:32]   :  0x80_bc_80_1b         gttx_charisk: 0x4

  gttx_data[95:64]   :  0xff_bc_f8_12            gttx_charisk: 0x4

  gttx_data[127:96] :  0x0f_bc_1f_34           gttx_charisk: 0xE

Cycle 2:

  gttx_data[31:0]     :  0x78_00_00_00         gttx_charisk: 0x0

  gttx_data[63:32]   :  0xbc_00_00_00         gttx_charisk: 0x0

  gttx_data[95:64]   :  0x0e_00_00_00         gttx_charisk: 0x0

  gttx_data[127:96] :  0x60_00_00_00         gttx_charisk: 0x0

As can be seen in Cycle 1, the packet starts with Packet Delimiter 0x7C. Below is the packet format transmitted from the FPGA.

The user data begins after 0x60 in cycle 2.

The TI DSP is the destination and the Destination ID is 0x1234. The FPGA Source ID is 0x78BC. The Transaction Type is 0xB (Message Format).  Is this the format of Message type packet data that TI DSP is expecting. If not, what should it be?

 

Ram, Jeff,

Have you had any success with the 1x test?

It is not possible for me to decipher how the internal FPGA register contents map to serial data being transmitted or how that should be received by the DSP. It is not obvious how the 16 bytes shown in each group map to serial first-bit-out or map to which lane. This is all part of the FPGA design and not something we can support you with.

Do you have a contact with the module design vendor who can tell you what the data should be doing?

Do you have access to the RapidIO.org specs to be able to determine what should be in there? I do not have this.

Have you successfully sent a message from the DSP to the FPGA and captured similar byte maps?

Regards,
RandyP

Hello Randy,

The data that I posted above is what is going out on the SRIO lanes. It is not the FPGA register contents map. It is the actual data on the SRIO bus. The two groups that I have highlighted above are the SRIO headers like Start-of-Packet, type of packet, Destination ID, Source ID etc. We have checked in detail on the contents of this data and to the best of our understanding it follows the SRIO standards. Yes, we have the SRIO spec. and have studied it quite a bit. If you want me to, I can explain in detail each byte in the header.

Since the data sent to TI DSP is following the SRIO spec. and it is not seeing the packet data, we would like to know why the DSP is not seeing the data. Are there any flags the DSP sets when it drops a packet? Any other settings to look for?

The FPGA is able to receive a packet sent from DSP. We analyzed the packet header data and the format is the same as sent by the FPGA.

We are in touch with Xilinx about the 1-lane vs. 4-lane difference. We believe that the 4-lane configuration of the FPGA is transmitting data as per RapidIO spec.

We would like to get support from someone who is knowledgeable about SRIO and configurations needed in TI DSP to support it.

Regards,

Ram

Ram,

For my understanding, Your SRIO PLL value set as 0x229, it means the PLL multiplier(MPY) is 5x and SRIO reference clock is 250MHz. Is it correct? Share SRIO line rate (5Gbps or 3.125Gbps).
The SRIO Rx/Tx configuration rate bit field values are selected by Based on SRIO frequency range versus MPY value. For your configuration you need to select full rate (00h). Eg: rxConfig = 0x00440485; and txConfig = 0x00180785;

In your earlier reply you mentioned hard-coded the example project rx/txConfig values to 0x00440485. I think it for rxConfig value, share your txConfig value. Also Please share your DSP test code, i will try to run your test code on my setup(DSP <----> DSP).

Thanks,