DMA on a DE0

While your code is running the stack and heap could be in that range you tested so I wouldn't recommend testing this way. There is a smaller version of the memtest software that would fit into the on-chip memory if you boost the size a bit. The readme text for that software template should tell you how big the code footprint needs to be (it's either 4 or 8 kB.... I forget).

Yes, I saw the 'small' variant, but it doesn't do any DMA testing. I was trying to keep to the supplied code (to reduce the number of things I could have done wrong :) )

Ah you are correct, this whole time I thought the small memtest used the DMA. I think if you took the memtest code, and removed the flash testing stuff and switched the software over to using small printfs you could probably get it to fit in an 8k on-chip memory.

1. the MemDMATest is the last thing to allocate any RAM (for the DMA buffers) and they're well below the area I'm testing.

2. the stack ought to be nowhere near where I'm testing either. The Memory extends from 0x800000 to 0xFFFFFF, and I'm only testing from 0xA00000 to 0xB00000 at the moment.

Hmm - ok, looking around the forum, I found: http://www.alteraforum.com/forum/showthread.php?t=1269&page=2 which has some fairly clear docs on how to constrain the SDRAM using Timequest, so if I did:

• Max Clk-to-valid-output-delay = 5.4ns

• Min Output data-hold time = 2.5ns

• Min setup = 1.5ns

• Min hold = 1 ns

• I don't really see why DRAM_BA and DRAM_{L,U}DQM aren't part of the ports listed. I'm following the recommendations in the document, but would love to know :)

• I'm guessing that the DRAM_DQ data lines aren't specified because they'll be latched at some time during the waveform that the other signals comprise, so they're less important to get synchronised.

• DRAM_CKE isn't mentioned anywhere either. Ought I be putting this signal into the list of ports above ?

Typically I use the same clock for the controller as what I send off chip since the constraints will drive the fitter to move things around for you. If timing is still and issue mixing timing constraints with a phase shifted clock off-chip can sometimes solve that problem. In that case you are trading off either read or write timing for the other which is also what that -3.5ns phase shift that people blindly add to their designs does as well (but you have no idea if it really works without constraints).

Well, since this is such a simple design, I decided to try out Quartus2 v11, and see if that helped matters, especially since you say the DMA ought not hang...

Perhaps the DMA or bridge suffered from the same bug as the SGDMA used to as well and it was fixed in 11.0 (it's been a while so I forget). This bug would prevent the master from issuing a request until waitrequest is low so as you can imagine this could cause the master to get stuck. Masters shouldn't wait for waitrequest to de-assert so this was addressed in a few cores.

Ok, same topic but a different subject :)

static	alt_dma_txchan 	_txchan;
static unsigned char *	_vram = (unsigned char *)0xE00000;
static void nextFrameRequired(void* handle)
	{
	static int count = 0;
	int rc;
	if (count %60 == 0)
	    printf("x");
	count ++;
	// Re-schedule a DMA transfer, and call this callback again
	if ((rc = alt_dma_txchan_send(_txchan, _vram, 640*480, nextFrameRequired, NULL)) < 0)
	    {
	    printf ("Failed to repost transmit request, reason = %i\n", rc);
	    }
	}
int main(void)
    {
    int rc;					// Result code
    int failed = 0;
    printf("\n\nStarting up the VGA controller\n");
    // Start a transfer to the VGA controller
    if ((_txchan = alt_dma_txchan_open(DMA_NAME)) == NULL)
	{
	printf ("Failed to open DMA channel to VGA controller\n");
	failed = 1;
	}
    
    // We want to write to the VGA controller FIFO at VGA_BASE so
    // set the DMA transactions to be WRITE_ONLY
    if ((rc = alt_dma_txchan_ioctl(_txchan, ALT_DMA_TX_ONLY_ON, (void *)VGA_BASE)) < 0)
	{
	printf ("Failed to configure DMA, reason = %i\n", rc);
	failed = 1;
	}
    // We want bytes to be written to the fifo
    if ((rc = alt_dma_txchan_ioctl(_txchan,ALT_DMA_SET_MODE_8,0)) < 0)
	{
	printf("Failed to configure byte-writes\n");
	failed = 1;
	}
    // Schedule a DMA transfer, and enable a callback that will
    // reschedule a transfer when the current one is done. We transfer
    // from the top of memory
    if ((rc = alt_dma_txchan_send(_txchan, _vram, 640*480, nextFrameRequired, NULL)) < 0)
	{
	printf ("Failed to post transmit request, reason = %i\n", rc);
	failed= 1;
	}
    printf("DMA scheduler activated. Failed = %d, Looping\n", failed);
    // Loop forever
    while (1)
	{
	int i;
	int pixel = 0;
	unsigned char *vram = _vram;
	for (i=0; i<640*480; i++)
	    {
	    *vram ++  = pixel ++;
	    if (pixel == 21)
		pixel = 0;
	    }
	}
    }

• http://www.0x0000ff.com/src/fpga/q11.zip (http://www.0x0000ff.com/src/fpga/q11.zip) (zipped, 24MB )

• http://www.0x0000ff.com/src/fpga/q11.tar.bz2 (http://www.0x0000ff.com/src/fpga/q11.tar.bz2) (bz2-compressed tar file, 22MB )

Make sure you have lots of buffering in the video output otherwise the time between the frames might be so long that you end up with a buffer underflow. I would simulate your design to see whether or not the DMA is behaving as expected. Also your code fragment doesn't have any cache bypassing when it's writing to the frame buffer so if you have the data cache enabled I would address that too. The code as far as I can tell sets the DMA up correctly, but I haven't used that DMA for around 5 years so I could be overlooking something.