FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

Altera Avalon MM DMA controller issues in burst mode

Altera_Forum
Honored Contributor II
2,601 Views

I am having issues with the Altera Avalon MM DMA controller when burst mode is enabled. 

 

1. With small transfer lengths works running DMA host ( RC ) DDR -> DDR , but when I increase the transfer length above 0x2000 it hangs .. with the transfer 

length equal to 0x4000 it hangs with the length register equal to 0x3FFC which represents only 4 WORDS transferred ... I see a DDR read of 2 DWORDS then a DDR write of 2 DWORDS with the data from the read. .. then I see some garbage on the x1 PCIe link . 

 

I don't understand this behavior ... I have tried the same design on the Cyclone IV and Arria V cards with similar results. 

 

2. When transfering from SRAM -> host ( RC ) DDR, it always hangs independent of of lenght The SRAM is 2 bytes or 4 bytes I/F ..  

 

 

 

3. I am running the Cyclone design in Modelsim and just need to edit the test case to start a 0x4000 length transfer. 

 

Any ideas on this as the core is very mature . 

 

I can't see any rules being violated. 

 

Thanks in advance, Bob.
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
810 Views

Here is the answer ... Ftom the Altera Knowkedge base 

 

 

".................. 

 

Solution ID: rd05032006_770 

Last Modified: Sep 11, 2012 

Product Category: Embedded 

Product Area: SOPC Builder 

Product Sub-area: Components Editor 

 

When I enable burst for the SOPC Builder DMA component, why are some of my DMA transfers truncated or stalled? 

Description 

For the SOPC Builder DMA component when burst transfers are enabled, the maximum amount of data that can be transferred is limited to the maximum burst transfer length (The Burst Transactions “Maximum Burst Size” setting in the DMA parameters tab). For a width N of burstcount, the maximum burst length is 2(N-1). 

 

Any transfers larger than the maximum burst count length are truncated by the DMA component and may stall the DMA burst transfer operation. 

 

Workarounds: 

 

1) Increase the DMA component’s “Maximum Burst Size” words to be greater than the largest DMA transfer length that will be used in your system. The maximum burst size value must be a power of 2. 

 

2) Limit the DMA transfers to be no larger than the “Maximum Burst Size” setting in the DMA parameters tab. 

 

Note: This issue only affects the SOPC Builder DMA component when burst is enabled. This does not affect the DMA in non-burst mode. 

 

All versions of the DMA controller are affected by this burst issue. ..................." 

 

Now for the solution ... it should be easy ... I can employ 2) which is a constraint more than a solution ... I have the burst size set to 1024 ( words ) and someone I work with wants a DMA transfer length to be much larger . 

I believe I need to edit the QSYS component but have never been able to. 

 

Any ideas on how to increase the maximum burst length. ? 

 

Thanks BCD
0 Kudos
Altera_Forum
Honored Contributor II
810 Views

I went into altera_avalon_dma_hw.tcl under the sopc_builder_ip directory and edited the maxBurstSize section... adding 2048 4096 8192 

 

I then opened the QSYS project and the new values appeared ... for the Cyclone IV design ... using a larger number broke the fitter unless I reduced the IMEM size.  

... for the Arria V design, I was able to select 8192 ( words ) and I will see if a 32k byte transfer is supported. 

 

add_parameter maxBurstSize INTEGER 

set_parameter_property maxBurstSize DEFAULT_VALUE {128} 

set_parameter_property maxBurstSize DISPLAY_NAME {Maximum burst size (words)} 

set_parameter_property maxBurstSize ALLOWED_RANGES {1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 } 

set_parameter_property maxBurstSize AFFECTS_GENERATION {1} 

set_parameter_property maxBurstSize HDL_PARAMETER {0}  

 

Does anyone know where I can get the Cyclone IV PCIe performance application and source code to re-generate the published performance figures found in this document 

https://www.altera.com/en_us/pdfs/literature/an/an456.pdf

 

Thanks Bob.
0 Kudos
Altera_Forum
Honored Contributor II
810 Views

The scatter-gather dma controller might let you do the transfers you want (but beware of its default fifo sizes). 

But it is OTT if you just want to generate a few long TLPs. 

 

Quartos 14 seems to have a dma interface option on the PCIe interface, but for some reason (not at all obvious) it is restricted to x4 PCIe. 

 

I'm not sure, but the Avalon to PCIe bridge may require 64bit wide bursts. So you need something that will do multiple 32bit reads and then do a burst write (and v.v.). It really shouldn't be difficult to write, but I don't think the simple dma controller can actually do that.
0 Kudos
Altera_Forum
Honored Contributor II
810 Views

Thanks DSL. 

 

I believe I have representative performance achieved with the Avalon MM DMA controller where I source date from 64 bit IMEM and the destination is the 64 bit TXS slave. Measurements on my PCIe decoder running on a scope , indicates in burst mode I achieve reasonable performance. 

 

I am interested in why Quartus 14 would make any difference ... I guess I will read up on it since I have stayed with 13.1 for stability reasons. 

 

What is OTT ? 

 

My main interest now is reproducing the Altera example performance measurements using their sample application / GUI. I can do it for Stratix V I believe but the Cyclone IV is s special case indicated above and I believe I need to put the "add_parameter" statements in an altpci.ini file but it's not clear where this file resides. 

 

Anyone know ? 

 

Thanks, Bob.
0 Kudos
Altera_Forum
Honored Contributor II
810 Views

OTT == Over The Top 

 

I failed in a quick experiment to get PCIe master dma working on a card that we've only used as a PCIe slave. 

However I wasn't able use JTAG so debugging wasn't really possible. 

In my case the source was a 32bit wide M9K block.
0 Kudos
Altera_Forum
Honored Contributor II
810 Views

Ok DSL ... 

 

my only thought is the that I have been stuck there since the EP needs to be explicitly set up to perform Master ( DMA ) operations ... by setting the Master bit in the Command Register of the EP. 

 

I'm not familiar with the block you refer to but do know the Avalon MM DMA IP has qome Quirks ... namely ... doesn't like to start on non-supported alignments and ... in burst mode desn't support transfer lenghts > Max Burst Length . You may be able to search the Altera Knowledge Base for any issues with the DMA IP you are trying to use. 

 

M9k Block just seems to be a configurable IMEM ... the thing to be careful of here is if the data width and the DMA controller node ... in theory , I expect data width mismatches to be handled by the Avalon MM fabric, but I am not sure if the slave is 32 bits ( WORD ) and the DMA controller is set up to run in another mode like DWORD or HWORD.  

 

ie ... 

 

static void __pci_set_master(struct pci_dev *dev, bool enable) 

1807 { 

1808 u16 old_cmd, cmd; 

1809  

1810 pci_read_config_word(dev, PCI_COMMAND, &old_cmd); 

1811 if (enable) 

1812 cmd = old_cmd | PCI_COMMAND_MASTER; 

1813 else 

1814 cmd = old_cmd & ~PCI_COMMAND_MASTER; 

1815 if (cmd != old_cmd) { 

1816 dev_dbg(&dev->dev, "%s bus mastering\n", 

1817 enable ? "enabling" : "disabling"); 

1818 pci_write_config_word(dev, PCI_COMMAND, cmd); 

1819 } 

1820 dev->is_busmaster = enable; 

1821 }
0 Kudos
Altera_Forum
Honored Contributor II
810 Views

hello sorry for the intrusion but did someone managed to configure the almemphy ip ?

0 Kudos
Reply