Altera Avalon MM DMA controller issues in burst mode

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

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.

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.

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.

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.

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 }