About C6678 SRIO read during BootLoading.

Kwanchung Chan 说：

I have an situation about the SRIO read: I am doing some data download to L2 memory through SRIO, and then read back (through SRIO) by FPGA for verification. We find that a specific region of L2 in core 0 will cause the SRIO read fail (The FPGA gets an invalid data packet). The address is around “0x10869de4” and “0x10869e00”. The SRIO link is set up through I2C booting (the SRIO setup code is converted from .out to .bin format, which is stored inside the eeprom). During booting, the SRIO setup code is loaded and configures the lane, then enters a loop that monitors the BOOT MAGIC ADDRESS of each core. That is what the core 0 does.

Then, I send my main program code to every core through FPGA using SRIO write, then read back for verification before kick start that core. I find that core 1 to core 7 are behaving normally. However for core 0, it fail to read for address 0x10869d40 with length of 0xC4 byte.

I perform some test and find that there are some region around the address 0x10869d40 which will cause the SRIO read fail. Is there any constraint to SRIO/memory read during the boot process?

Below is the status register of the SRIO.

Base: 0x02900000

Offset:

B140h   SP0_LM_REQ Port 0                     Link Maintenance Request CSR                           0x00000004

B144h   SP0_LM_RESP Port 0                   Link Maintenance Response CSR                         0x00000010

B148h   SP0_ACKID_STAT Port 0               Local AckID Status CSR                                     0x00000101

B154h   SP0_CTL2 Port 0                         Control 2 CSR                                                   0x22EA0000

B158h   SP0_ERR_STAT Port 0                 Error and Status CSR                                         0x00000002

B15Ch   SP0_CTL Port 0                          Control CSR                                                     0xD0600001

According to your register info, I didn't see any error on SRIO in a physical link level

Coudl you do below steps to narrow down the root cause?

1) Provide the wrong read back value and the expected read value

2) Only download image to one core(core0), then read back to check whether the issue still exists or not

3) After your boot, connect CCS to check this memory in CCS memory view, then we can know the issue is caused by write or read

4) Check FPGA SRIO code, does your FPGA SRIO using soft core ip and hardware core ip? Probably the error is caused by application level  

Hi Thomas, Thanks for your reply,

For the test I performed:

1. There is no actual value (data) return, instead it returns a "invalid packet" reply with no desired data.

2. It still behaves same error and same location for only image downloaded to core 0

3. I connect with CCS and see that data are correctly downloaded to L2, I think it should be caused by SRIO read.

4. It is a soft core IP.

Hi

1）According to Rapid IO protocol, we can define packet type from FType and TType in packet header, here, you mentioned"invalid packet", do you mean that the read packet type is not in the range defination in tabel 2-2 in TI srio userguide? If yes, could you connect Logic analyzer in the bus to check the packet type?Because there is a possibility that FPGA SRIO IP have an abnormal process after it gets a correct response packet from DSP

2)  Before FPGA download image to DSP, I suggest you do a full memory write-read test for rapidIO link after power up .especially on the wrong memory range.

3) Based on your info, there is only 12 bytes read abnormally, do you see any difference on the read operation(size,address property) between this address and other successful address both from FPGA side and DSP side?

Hi Thomas,

1) We use NREAD (FType2, TType0100) for the access of DSP from FPGA. However the DSP side returns invalid packet - The situation is like (according to my FPGA teammate) sending a NREAD command with read address 0x0 which try to read some protected region.

I also read the "ERR_DET" register (table 3-90), it has bit 6 set when I send the NREAD packet with the mentioned address (start from 0x10869d40 of length 0xc4 bytes), which means RX I/O DMA Access Error. Is there any special condition triggers this error?

We configure using 4x lanes port each of 2.5Gbps and unfortunately we don't have a powerful enough equipment to extract the SRIO transmitted data. Do you have any advices or supports if we have to know the transmitted data?

2) I also tried different start address with different length (near the problem region). Some can successfully read but some encounter the same problem above. So I think this is not only region causes the read fail.

3) Amount the test, one of the fail case is start address: 0x10869d40, length 0xc4 bytes, but there is a success case when start address: 0x10869d40, length 0xc0 bytes. There are some more test cases. I can send you if necessary.

Thanks.

Hi

1) Why NREAD command with read address 0x0, this address should be invalid address in DSP, it may explain why your ERR_DET report DMA access erro

You can try to low lane tranfer freq and use logic analyzer to investigate the signal,if you have some difficulty, you also can check FPGA output value on its port

2) Do you see there are some common part/attribute on these failed address

3) So, only last 4bytes have problems, could you just double test 0x10869E00 address read and pay attention to the output command of FPGA?

Hi Thomas,

1) The read address is 0x10869d40, and it has reported ERR_DET. The above address 0x0 NREAD is just an example showing that the FPGA will see the "invalid packet" when NREAD, while its the same when NREAD address 0x10869d40. I checked that 0x10869d40 is a non-special L2 memory (no access right set, not remapped, ) so it is weird to see there is DMA error.

For the equipment, we don't have 4 probes... And the lower of lane speed need DSP, FPGA code, and hardware change that we cannot guarantee to repeat the issue. Do you have any equipment that available for support?

2,3 ) I have some test report, which describes some NREAD region tested as well as the fail regions. From my view I cannot draw conclusion from the fail pattern.. And I will also send you a screen shot about the DMA error report by ERR_DET (through CCS) and it will contain more info.

Due to some policy, I will send to the FAE and forward to you.

Thanks.