FPGA(with SRIO IP core) and DSP (C6455 DSK board) connection issues

Hi

My suggestion for ur problem is, instead of checking the FPGA - DSP interface, first i would suggest to check the DSP-FPGA interface. Mean do data trsnsfer form DSP to FPGA, & check whether FPGA is receiving the data properly.

I suggest this because, DSP side has more debugging options than FPGA. [:)]

Have you been successful transferring other packets (different sizes and/or types)?  It's not obvious from your description that you have any packet settings incorrect, but it is possible that something is configured incorrectly either in the packet or the initialization of the peripheral.

It is possible for two link partners to initialize (port_ok bit is set) but still not be able to send data packets back and forth.  You should make sure the port_ok bit is set, and all error bits in the error_stat and error_detect registers are cleared before trying to send actual packets.  The port_error that you reference is a major error indicator from which hardware can not recover from automatically.  This is generally due to Ackid mis-alignment issues, which is probably due to the reset sequence between the link partners.  Logical layer errors won't cause this type of error and are recovered from automatically by hardware.  Clear the port_error bit manually, then in order to clear both input and output error stopped states, initiate the following step which will cause both link partners to exit the input/output error stopped states and align ackids automatically.  I suggest doing this step after initialization or any type of reset before exchanging packets.

Thank you for you suggestion, Travis.

I have not been able to successfully transfer NWRITE and STREAM_WRITE.

I did as you suggested. After initialziation, I Clear the port_error bit manually and then Write a value of 0x40FC8000 into the Port n Control Symbol Transmit register. However, there are no obvious changes.

Here is the ERR_DET value when I halt the DSP part  0x00000040 (DMA access to MAU was blocked. Write 0 to clear.)

I do not what else I can try to fix this problem. I really appreciate it if you have other suggestions.

Thank you,

It sounds like you are past the port_error now, which is good.  The fact that you are getting a logical/transport layer error means the packet has been received and passed from the physical layer to the appropriate protocol unit (MAU in this case) in the logical layer.  When you said NWRITE and SWRITE are not working, does that mean the exact same packet (same header fields) work with a NWRITE_R?  That should not be the case.  Some things to try:

1)  If you enable the logical/transport layer error capture registers with RIO_ERR_EN, then you can look at the capture header info of the packet and make sure it is matching what you think is being sent by the FPGA. Make sure you look at the logical/transport error capture registers not the port error capture registers.

2) Typically, this error means that there is something wrong with the address you are trying to read/write to in the DSP.  For example, the memory location is protected and not accessible by RapidIO.   I'm not sure how the FPGA constructs the packet header from the address you intend to access in the DSP, but remember, what is actually sent across the link is a 8B aligned address, the 2 least significant bits are not sent at all and assumed to be zero.  Make sure the FPGA is taking that into account for you, or determine if you have to manually account for that when you program the FPGA for the NWRITE/SWRITE.

3) Not sure what your board setup is like, but if you can perform a external loopback from DSP TX to DSP RX and get NWRITE/SWRITE working in this environment first that would be good.  Internal loopback on this device doesn't work, so don't waste your time.

I just did some modifications in the initialization as following:

-         CSL_SRIO_1X_MODE_PRIORITY -> CSL_SRIO_1X_MODE_PORT for periCntlSetup.bufferMode

-         SP_MODE is changed from 00 (1x/4x LP-Serial RapidIO Specification) to 01 (4 ports (1x mode each))

-         We used the SWRITE instead of NWRITE (trans, wrsize, srcTID, ext addr, wr ptr are not necessary in this mode)

This is what we got after making the above modifications

Logical/Transport Layer Error Detect CSR (ERR_DET)           0x02D02008

Initial                            00000000

Normal result                00000000

What we observed       00000040

RX_IO_DMA_ACCESS DMA access to MAU was blocked. Write 0 to clear.

RIO_SP0_ERR_DET  （Port 0 Error Detect CSR）                        0x02D02040

Initial                            00000000

Normal result                00000000

What we observed       00000000

RIO_SP0_ERR_STAT                                                            0x02D01158

Initial                            00000000

Normal result                00000002

What we observed       00000002

I have a feeling that since the port errors are gone, the packet can be forwarded to the logic/tran layer. Maybe it is because the address we are using is not correctly converted and that is why we have the MAU access error.

Do you have suggestions?

thank you

Ahhh,  you mentioned ext addr is not needed for SWRITE packets, when in fact, the two are totally unrelated.  What I mean by this is that ext address is a system level parameter.  Either you use ext address with all directIO packets (NWRITE, NWRITE_R, SWRITE, NREAD, etc) or you don't.  This is controlled by RIO_PE_LL_CTL (0x104C).  So if you didn't have this set correctly before, and were sending extended address with your packets, the physical layer to logical layer decode and handoff would have been wrong and could easily foul things up. 

As I mentioned in my last post, the RX I/O DMA access error (bit 6 of ERR_DET) is a logical layer error and indicates that you are still trying to access an address that you aren't allowed to.  Something is still wrong with the address.  You might want to ask for support from your FPGA vendor to ensure that the format you are sending is what you are expecting to send.

Regards,

Travis