DM648 PCI Master Write Fifo Problem

1. When transmitting, is the DM648-PCI in slave mode(uses internal PCI DMA) or in master mode(uses EDMA) ?

2. Is it 40 bytes or hex 0x40 bytes ? Can you share more details, about this PCI transfer.

Regards
Varada

1. The safest way to do this is to perform a read, via PCI, of the last word you wrote. This will invoke RAW ordering rules and the completion of the read should also necessarily ensure completion of the write. If for some reason, your target does not adhere to RAW ordering, you can poll for write completion.

2. I have not heard of this kind of problem on this generation of PCI peripheral. Can you please provide more information?

1.We use DM648-PCI in master mode, and use EDMA to move data to host-map-window.

2.It is dec 40 bytes ,

  Description:

  when this problem happens, I write one DWORD to the host-map-window. but I can not get the correct data in the expected address.

  And I continue writing data to the host-map-window, When I write the 10th data, the 1st data I wrote appears in the address I last wrote to.

  Example:

  I write data (range from 0x00000000 to 0x00000014) to addr (range from 0x00000000 to 0x00000050)

  target memory content:

  Before write: 

   0x00000000:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000010:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000020:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000030:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000040:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF

 After write 1 dword:

   0x00000000:        0x123323AB 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000010:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000020:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000030:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000040:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF

 After write 2 dwords:

   0x00000000:        0x123323AB 0xEF234248 0xFFFFFFFF 0xFFFFFFFF 
   0x00000010:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000020:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000030:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000040:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF

....................................................

 After write 10 dwords:

   0x00000000:        0x123323AB 0xEF234248 0x2341243 0x59365418 
   0x00000010:        0xAC234529 0x43564667 0xAF324AC 0xBE009123 
   0x00000020:        0x14334ACF 0x7894BCF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000030:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 
   0x00000040:        0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF

 After write 20 dwords:

   0x00000000:        0x123323AB 0xEF234248 0x2341243 0x59365418 
   0x00000010:        0xAC234529 0x43564667 0xAF324AC 0xBE009123 
   0x00000020:        0x14334ACF 0x7894BCF 0x00000000 0x00000001 
   0x00000030:        0x00000002 0x00000003 0x00000004 0x00000005 
   0x00000040:        0x00000006 0x00000007 0x00000008 0x00000009

 Thanks!

Thanks for the details. As Todd mentioned this error is something out of the ordinary. I have not seen this before. The address to which data gets written - is incorrect, as seen with offset of 40 bytes. I have some more Questions ?

Does this error happen in beginning or in the middle of some big trasfer ? Do you get this error always ? As with the initial 40 bytes of inconsistent data, is it always these values ? And have you tried using a different PCIADDSUB_0..31 register ? Is is possible to share the EDMA PaRAM.

 1.Does this error happen in beginning or in the middle of some big trasfer ?

   It is maybe in beginning of the transfer, And difficult to catch the error point.

 2.Do you get this error always ?

   No, I repeatly start and close my application(this will cause repeatly rest DSP modules(except PCI) and code download),

   Some times later, it happens.

    Additional Information:

    Our appication case is a PC-based DVR, This error happens when we use inter-DSP DMA transfer, And only the master has this problem,The target is ok.

     If this happens, I have to restart pc or reset DM648 PCI module to come back to the right state.

 3.As with the initial 40 bytes of inconsistent data, is it always these values ?

    No,It is variable, It seems like data in the FIFO.

 4.And have you tried using a different PCIADDSUB_0..31 register ?

    I did not do this try, We think it is identical.

Also - Have you tried what Todd Hiers suggested, in this thread.

Quoting " The safest way to do this is to perform a read, via PCI, of the last word you wrote. This will invoke RAW ordering rules and the completion of the read should also necessarily ensure completion of the write. If for some reason, your target does not adhere to RAW ordering, you can poll for write completion."

Regards

Varada

My PCI bus clock is 33M.

I have found out the reason.

This maybe is a bug.

If I reset the C64x+ CPU during the DMA transfer, The data remained in the PCI FIFO will not be stransfered to the target.

Next time, before new data transfer the data in the PCI FIFO will be transfered first, And the offset happens.

This is the problem!

Thanks!

Thanks for the update. Good to know that you have figured out the reason. It may not be a bug. It is just an advisory to ensure the DMA is complete before the CPU C64x+ is reset, especially when PCI module is not reset. If this is not possible to do, then other workarounds are also possible.

Regards

Varada

Yes, DMA must be complete before CPU C64x+ is reset,

But I think it is better to empty the PCI FIFO before new data transfer after the C64x+ startup.

Best Regards!

Can you please tell which reset were you using on this device ?

Regards

Varada

We use PSC to reset C64x+ CPU and some other modules(except PCI module).

Best Regards!

Hey Todd, you pointed out this solution to us when we were using DM642. Please confirm that we need to take the same precaution on the DM648. Thanks

Geoff,

 There's nothing really device-specific about the advice. "Read back the last thing you wrote" is a good way to force write commits on hardware that enforces RAW ordering rules. Because the device won't let the read complete until the previous writes are complete, you can be sure the writes are complete when the read completes.

This is most useful for avoiding race conditions. Writing data to a buffer and then signaling an interrupt is the classic case. If the write data and interrupt do not use exactly the same data path, there is a potential race condition where the interrupt could be received before all the data lands in the buffer. Reading back the last data before signaling the interrupt prevents this race condition.

Though DM648 uses a different PCI architecture than DM642, it still has the potential for a race condition on incoming interrupts.

So this solution will work on DM642, DM648, and anywhere else you're worried about data race conditions.