Honored Contributor
Honored ContributorThanks for the well considered and detailed reply
--- Quote Start --- The regular DMA uses memory mapped interfaces, which are designed to be connected to memory components, or at least components with an area mapped as a memory. Of course you can choose to emulate a memory component by ignoring the address and connect some signals as you are trying to do, but there are several problems: [list][*]as a general design rule, you shouldn't use a generated signal as a clock in an FPGA. You can have glitches on that signal, that can cause unwanted clock cycles at unpredictable times (and usually not when you want them ;) ) and timing problems **That's correct, and I was unclear. I'm connecting the read_n signal from the dma read master port to the 'rdreq' port on the DCFIFO megafunction. My understanding is that this is a synchronous fifo and the that input functions as a read clock enable. [*]if the DMA wants to read on several cycles in a row it will just keep the read_n signal low. So if you use it as a clock it won't work. Instead, use the same clock the DMA is using as the fifo read clock, and use an inverted version of read_n for the read request. ** Again, I was unclear: This is a fully synchronous system: DMA and read side of fifo have the same clock. And the inverted read_n goes to the 'rdreq' port. [*]by keeping the wait request always low you won't prevent the DMA from trying to read your fifo when it is empty. You should probably use this signal to stop the DMA when the FIFO is empty instead. ** My state machine does that, but since I was only getting a single 'read_n' from the dma (or at least only one followed by at least 80us of inactivity according to both signaltap and oscilloscope probing) despite a length register programmed to 128, I was trying to eliminate that as a cause. So I hold it inactive as a test. [*]keeping the data valid signal high violates the specification (http://www.altera.com/literature/manual/mnl_avalon_spec.pdf) which says "A slave with readdatavalid must assert this signal for one cycle for each read access it has received. There must be at least one cycle of latency between acceptance of the read and assertion of readdatavalid." It may or may not work with the DMA controller (I don't know its internals) and even if it does there is no guarantee it will work with future versions. It is better to stick to the specification and use for example a delayed version of the read request. **Good quote (Avalon spec table 3-1, page 3-4.) I will try the explicit de-assertion. This could be better written, but I agree that it implies de-assertion during the 'latency'. Looking at the dma controller code, this input doesn't seem to lead into any synchronous circuitry. [*]as you don't decode the address you have no way of knowing where the controller is in its transaction. Depending on the type of data you need to transfer it may not be a problem, but in some cases it can be interesting to signal the beginning and the end of a transaction, for example because you are sending packets with a specific format, or you need to keep track of timing. You could read the address to detect when you are at the beginning of a transaction, but you have no way to tell the DMA controller that the transaction is finished.[/list] ** I'm programming the dma length register to equal the fifo depth and using fifo full to start the transfer and fifo empty to end it (using wait request to hold the next transfer until the fifo is filled again). Simple, I thought, but not simple enough, apparently. The Avalon Stream interface is more adapted to those kind of transfers IMHO, and it very easy to use. --- Quote End --- ** Maybe so, but the Qsys flow doesn't support a streaming interface to the pcie. It seems like a lot of work to put the pci express block outside of qsys and take care of flow control (credit processing must be done by hand) just to do dma, especially when my transactions are always the same length.
