Hello,
I've developed an application on a Terasic DE10-Lite board which has a MAX10 and an SDRAM chip onboard, using Quartus 18.1 for this. In my design I have used a nios II/f core (w/o cache), the altera_msgdma IP and have developed a small driver to use it. Testing it it I've discovered that sometimes the device would never clear the busy bit, making it appear stuck and the written data is corrupted. I've provided a patch that solves it, .sof, .elf and .qsys and .stp files, below are all the details.
The altera_msgdma is configured with mode MM-to-MM and transfer_type set to unaligned access, no burst.
I'll use the pdf UG-01085 | 2018.09.24 as reference for everything: https://www.intel.com/content/www/us/en/docs/programmable/683130/18-1/introduction.html
Test application: make an array of bytes (uint8_t) on an on-chip memory (altera_avalon_onchip_memory2), fill it with increasing values (starting from 0). Transfer 500 times using the DMA device (meaning that the same descriptor is placed 500 times in the descriptor FIFO) a number of bytes to SDRAM (altera_avalon_new_sdram_controller). Wait for the DMA to end the transfers (polling the status register), check if the copied data matches, then increase the number of bytes to transfer and repeat. The number of bytes starts from 1 and goes up to the array size.
To make it clearer: src array has values (uint8_t) 0, 1, 2, ..., 255, 0, 1, 2, ..., dma copies 1 byte from src to dest 500 times, then dma copies 2 bytes from src to dest 500 times, and so on. The test never ends, waiting for the DMA to assert the Descriptor Buffer Empty bit (table 298 p. 330) when the number of bytes to transfer is 25. This is repeatable, but I think specific to my setup.
I run this test under GDB without breakpoints and, after more than enough time, pause it, the dma has (table 297 on page 329 and table 298 p. 330) the status register set to 1, and it stays like that until the end of times. This is what I can see from GDB when I stop it:
52 while (dma_jolly.csr_port.status.get().descriptor_empty != 1) {
1: /x dest = {_M_elems = {0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0xba <repeats 975 times>}}
(gdb) p /x src
$6 = {_M_elems = {0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e,
0x1f, 0x20...}}
As you can see, dest does not have the same values as src, it should start with 0x0, the DMA has "changed" the order of the written data.
After many trials I've tried to use Signal Tap Logic Analyzer in Quartus: there is a hardware bug that "hangs" the device, it exists only if the IP is configured with TRANSFER_TYPE set to unaligned access (in platform designer).
In the screenshot you can see the last node [...]read_master:read_mstr_internal|scfifo:the_master_to_st_fifo|usedw[4..0] as a bar chart, this is a FIFO in the read_master of the altera_sgdma that overflows. The issue is in the read_master module, its task is reading from the MM Avalon bus and forwarding data to the write_master, it uses a FIFO and has to stop requesting data from the bus early "enough" to not overflow that FIFO. When the module is configured to allow unaligned access it creates the signal (line 751 of read_master.v)
assign too_many_pending_reads = (({fifo_full,fifo_used} + pending_reads_counter) > (FIFO_DEPTH - (maximum_burst_count * 3)));It assumes a pipeline depth of 3, but it really is 4 deep, because of a barrel shifter in module MM_to_ST_Adapter.v, lines 289-300, that needs an extra cycle to empty itself, after all the reads from the Avalon bus are already done.
The .stp file shows the first time the overflow happens at sample -2472.
src is at addess 0x3e90, dest is at 0x4000000
I have no issue uploading every source file, but it requires an upstream copy of gcc 13.2 to compile, I'm attaching only my main .cpp file to show how the test works.
Link Copied
