Receiving SWITE, NWRITE SRIO transactions with MSC8156 processor

[Kir]

Hello!

I have a problem with receiving SWRITE, NWRITE  RapidIO transactions from remote srio controller(Xilinx FPGA SRIO IP controller). We've already achieved correct transmition SWRITE, NWRITE packets to FPGA, but when we transfer the same types of packets back to DSP, DSP shows no action. Be more precise, I could not see any data coming from FPGA. Could it be that DSP SRIO controller should only send NREAD transaction, and after that FPGA's controller could response with requested data and FPGA controller could not initiate write operation(if FPGA want to send something it should wait NREAD and only after that send)?

Thank you!

[AndrewinApps]

Both directions should work.

Have you tried NREADs from the MSC815x yet?

External SRIO hosts are able to initiate all SRIO transactions (SWRITE, NWRITE, NWRITE_R, NREAD) to the MSC815x devices, so it would seem there may be some other underlying issue.

[warlord]

The thing is, MSC8156 SRIO port configured with one outbound and one inbound window. DMA channel is used to transfer data from 8156 to external SRIO host. But when an external SRIO host  issues a NWRITE transaction the data inside MSC8156 goes directly from port via ATMU to internal memory(No DMA transferes charged). How user application can detect that transfer is complete and the data in memory is valid?? I expect some sort of interrupt or callback upon external NWRITE  transaction completeness. Maybe there is another way to do it??

[Jim95]

In this the case the FPGA can send you a DOORBELL  when the transfert is complete

[AndrewinApps]

Hi Jim95,

You just suggested something a little tricky actually.
As doorbells are sent via the RMU in the MSC8156, and NWRITEs via the OCNDMA, the path is not the same - meaning the doorbell may move ahead of your last transaction if you happen to be doing many NWRITEs in a row.

There are 2 ways around this:

1.Instead of using an doorbell, you can use a final NWRITE (after sending your data), that writes to one of the virtual interrupt registers. This way you are using the same path as your normal data and know everything is in order.

2. You can still use a doorbell to indicate data is completed, but best to send this after using an NWRITE_R instead of an NWRITE, and then having the FPGA wait for the response, etc.

[warlord]

All, you guys, suggest is a throughput decrease. I send 256-byte packets. First of all I received evidence that whole packet is put into DSP's memory atomicaly, i.e. CPU cannot got broken data. Then I've made a circular buffer with element equals one packet and FPGA fills this buffer accordingly.

[AndrewinApps]

Data is sent 1 packet at a time, yes at the high level. It isn't written into memory 256 bytes at a time though. The bus isn't that wide. 

I think something isn't clear here, so let me try to clarify:
If we are sending multiple packets, we need a way to know the last packet was officially received (ie - a way to inform the core that all data is there when a buffer has been filled). We also need a way to ensure the very last byte is in memory.

Without a signal / interrupt, the core has to simply poll the buffer for something - which isn't very efficient.

Using the interrupt generation via VIRQ write does not decrease throughput of your transaction..

It is Freescale's suggestions for doing multiple NWRITEs and wanting absolute evidence of completion of a set of transactions.

NWRITE_R does decrease throughput, but just informing of all available options.

[warlord]

I took rio_dma demo, removed SRIO_PORT1 and turned SRIO_PORT0 to DIGITAL_LB mode. I send a transaction of 4096 bytes to M3 memory using OSNDMA. The next step I configured a VIRQ registers to assert an interrupt. Finally I look for a way to send a 32-bit SRIO transaction to VIGR (0xFFF27000) to assert an interrupt. Currently I have one outbound window:

    {        1,                  // Window number         0,                  // Device ID towards which to direct the flow         0x100000000ULL,     // 36 bit Ocean address.         0x0C0000000ULL,      // 34 bit RapidIO address - destined to reach M3         SRIO_ATMU_OUT_WIN_1M,  // Window size         MEDIUM_FLOW_LEVEL,  // Priority level         NWRITE              // Access type on RapidIO     },

 Could you possibly point me what configuration (SRIO, OSNDMA) should I add to be able to carry out this type of transaction??

[warlord]

Task is solved:

    {        1,                  // Window number         0,                  // Device ID towards which to direct the flow         RIO0_ATMU_BASE,     // 36 bit Ocean address.         0xFFF00000ULL,      // 34 bit RapidIO address - destined to reach CCSR address space         SRIO_ATMU_OUT_WIN_1M,  // Window size         MEDIUM_FLOW_LEVEL,  // Priority level         NWRITE              // Access type on RapidIO     },

  and the transfer:

  static uint32_t virq_code_num;   ...  ocn_dma_transfer_config.source.stride_enable       = FALSE;  ocn_dma_transfer_config.destination.stride_enable  = FALSE;  ocn_dma_transfer_config.size                       = 4;  ocn_dma_transfer_config.interrupt                  = FALSE;  ocn_dma_transfer_config.response                   = TRGT_RESPONSE;  *(uint32_t*)data_buffers_m3 = virq_code_num;  ocn_dma_transfer_config.source.addr.high_addr      = 0;  ocn_dma_transfer_config.source.addr.low_addr       = (uint32_t)data_buffers_m3;  ocn_dma_transfer_config.destination.ocn_buff_addr  = (uint64_t)(RIO0_ATMU_BASE + ((uint64_t)(&g_msc815x_ccsr->gic.vigr)&0xFFFFF));    status = ocnDmaTransfer(ocn_dma[TRANSACTION_DMA], &ocn_dma_transfer_config, 0);

The one thing I do not still understand is the dma failes to transfer (transfers four zeroes) from local M2 memory, that is why I firstly copy 4 bytes from M2 to M3 and then start DMA.

[yangjie]

you must  make the 36 bit transform address align to the window size or it will result transfer fail and can,t receive the data.