Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
739 Views

Wrong address during burst transfer of mSGDMA

Hi, 

 

I'm using the Cyclone V GT development board in combination with Quartus 16.0. A finite state machine writes two or three descriptors to the mSGDMA, which transfers the data into the memory of my host computer by using the PCIe hard ip block. 

 

mSGDMA configuration: 

- MM --> MM 

- data width: 128 bit 

- burst count: 32 

- max. transfer length: 4kB 

- data path fifo depth: 256 

- descriptor fifo depth: 8 

- full word accesses only 

- extended feature support 

 

In some cases, the mSGDMA writes one data word (128 bit) more than requested. The purpose of the application is a ring buffer structure. The first descriptor transfers a write counter and pointer, which is read from a static address inside the fpga and will be written into a static address of the host memory (address: 0xC800_0010). The second descriptor writes the data from a fifo into the ring buffer (0xC800_0020 ... 0xC800_0FFF). the wrapping is solved by the third descriptor, which is used in case of an overflow of the ring buffer. Sometimes the mSGDMA violates the memory border and writes inside the next ring buffer. 

 

I have already checked the address calculation and the finite state machine of my design by simulation. Furthermore, I could see, that the finite state machine never writes invalid descriptors (proved by signaltap). In addition, I recognized, that the mSGDMA starts a burst transfer (address: 0xC800_0E10) with an invalid burst counter (burst counter: 0x20), which results in a memory violation (0xC800_1000). The violation is shown in the attachment. The next ring buffer starts at 0xC800_1000, which is violated.  

On top of that, the whole mSGDMA transfer sums up to 255 x 128 bit, but the possible maximum of my application is 254 x 128 bit. 

 

The problem occurs after 100,000 to 1,000,000 data words. There is no pattern behind it, so that i would expect some timing issues. According to the TimeQuest report the design fits the requirement (f = 125 MHz).
0 Kudos
0 Replies