I've read a couple of posts about the SGDMA on this forum, but can't see an answer to the specific problem I'm having.Our design has a streaming source that runs continuously. We need to capture a chunk of data from this stream into memory. The stream is running quite fast (64bits of data valid every 4 clock cycles), and uses burst writes to move this into memory via a 64 bit bus. The problem I've come up against is how do I control the flow data into the SGDMA? Even when the SGDMA isn't busy it looks like the FIFO in the SGDMA is filled up. The first samples in my captured data are clearly from some old data. Also because the system is starting with a full FIFO it can't ever run it down to a point where it doesn't overflow again. The only solution I can see at the moment is to put some logic in so that the Nios can disable the valid from the source to the SGDMA. The Nios would then setup and start the SGDMA before enabling the valid. This problem here is that I'd still end up with data left in the SGDMA FIFO when the capture to memory is completed, as I wouldn't be able to switch off the valid at the instant the SGDMA is finished. I can't see any way to flush this unwanted data out of the SGDMA. Is there any way that my streaming source can detect that the SGDMA is busy? The 'ready' signal doesn't give me this information as it is asserted when there is space in the SGDMAs FIFO. Any ideas would be appreciated.
Unfortunately, I think you're stuck with that behavior if you use SGDMA.My suggestion would be to switch to the Modular SGDMA which has editable source and modify your local copy if it doesn't already have the desired behavior (e.g. deassert 'ready' when the mSGDMA is idle).
It seems to me that all you need to do is modify your IP to have an enable bit so that you can make sure the DMA is ready before you enable the core that is streaming the data. While your core is disabled it's valid bit should be driven low (that's the point of the valid signal, to control the transfer of streaming data). Then you just need to make sure you keep the DMA engine filled with descriptors so that it can keep up with the rate of data entering it (which is probably much easier to achieve using the mSGDMA).If you switch to the mSGDMA there is a bit inside the dispatcher called "busy" which you could pull out but I think trying to coordinate to IP cores like this will be rather painful. I would just use the flow control built into the ST spec and just coordinate starting both IPs instead.
BadOmen, Ted,Thanks for the replies, I wasn't aware of the mSGDMA. As we're only trying to capture a block of data coming from our streaming source I can't see that we can just enable/disable the source. It will work at the start of a capture, but unless I update the source IP with a counter it will always stream extra data into the SGDMA at the end of capture before the CPU responds and switches it off. My 'fix' for now is just to live with the SGDMA as is by increasing the size of the capture by enough samples to flush out the old data, and then discarding these extra samples from the front of the capture.
It sounds like when the source of the data is disabled you should just have it throw out samples holding the valid signal low, then when the CPU enables the flow of data you stop throwing it out and assert the valid signal. What I'm saying is that I don't think you need another IP to do this, just make the source of the data do this under software control.