DMA reading multiple PIOs

You could use a scatter-gather DMA controller and program the descriptors to continuously read each PIO in a round-robin fashion. If you have a little HDL knowledge, you could write your own block to do this for you and ditch the PIOs altogether.

Jake

Yes I agree with Jake, You most likely want to to write your own custom io.

At the very least you can insure your ADC sampling is consistent. By the number of ADC's you're talking about, you could probably do some of your number crunching and pass the date to nios when it really needs it.

Pete

anakha and jakobjones,

Thank you both for your comments. I have still been trying to use the basic Altera DMA core, but when I ask questions about using it with a series of PIOs, I tend to get a bunch of references to literature that does not answer my questions.

I do not have much (if any) experience using HDL, so creating my own code is not likely, and I decided to continue trying to use the Altera DMA core for a little while longer before I switch over to the SG_DMA core.

I have a couple of questions on the basic DMA core and its usage with the PIO cores. In order to try and use the DMA to read the PIOs, my software is arranged as follows;

0) Assign Handles

1) I first set up the data size by calling alt_dma_rxchan_ioctl with the ALT_DMA_SET_MODE_16 parameter

2) I also set it us for Rx Only by calling alt_dma_rxchan_ioctl with the ALT_DMA_RX_ONLY_ON parameter

3) In preparing the DMA to receive data, would I assign the BASE address of the first PIO in memory to the DMA?

4) The PIOs have been setup as 16 bit, so my 'size' value that I pass to the

alt_dma_rxchan_prepare routine would be 44 (i.e. 2 bytes per each of the 22 PIOs)

While the DMA is doing its thing, I have a flag set to prevent me from placing another call to the DMA until it has finished.

Does this look valid? Thanks

Fred

Well it's been a while for me since I used Altera DMA core. I assume you've read this:

http://www.altera.com/literature/hb/nios2/n2cpu_nii51006.pdf

and the “Using DMA Devices” on page 6–24 of this:

http://www.altera.com/literature/hb/nios2/n2sw_nii52004.pdf

When I used the core, I chose to access it's registers directly rather than use the higher level software functions. However what you have looks good to me except:

in step 3, you're going to want to give the address of the data register of the PIO. It does so happen that this is located at the base address of the PIO peripheral. If it weren't however, you would obtain it using the following macro found in "altera_avalon_pio_regs.h":

IOADDR_ALTERA_AVALON_PIO_DATA(base).

Now what you want to do is have the DMA controller perform a read from the base address of each PIO in turn. This means that you need to have it set up with a list of addresses to read from and reading two bytes from each address. You can't have it read from consecutive addresses because the base addresses of your PIOs are not consecutive. So you can't give it the base address of the first PIO, tell it to do 22 consecutive address reads, and expect to get the data. Does that make sense? That's why I think you need to use the SGDMA core for what you are trying to accomplish. The SGDMA core gives you the ability to specify a list of addresses to read from.

I should add too that in your case it would be faster to just read the values directly from the NIOS and not use DMA. There is a certain amount of overhead associated with DMA. DMA is only efficient when you are moving large chunks of data. So if you are just going to read each PIO once, do some processing in the NIOS, then repeat, drop the DMA as it's not going to buy you anything. You'll spend way more time setting up the DMA, servicing the IRQ, and waiting for the DMA core to cycle through descriptors than you would have just reading the PIO ports directly.

Jake

Jake,

Yes, that is what I suspicioned all along, i.e. that you cannot just pass the base address for the first PIO in and expect it to read the other PIOs. When I saw the address range for each PIO, I did not think the approach I presented would work, but I just wanted someone to verify it was for the reason I suspected.

The reason for trying to use the DMA in the first place is to speed up the reading cycle, but from what you have indicated, this will not get me there…

I have also been thinking about increasing my system/memory clock frequency (being generated by the Altera PLL). I have actually tried to do just this, but my system will not accept the program from the debugger…

My input clock is running at 50 MHz, and I am using the PLL to run at 85MHz. Everything works fine. I am using a Cyclone II EP2C70F896C6 FPGA, and the Cypress CY7C1380D SRAM which will go up to 167 MHz, so unless I have some layout problems on my board, I should be able to increase the frequency out of the PLL, but so far, I have had no luck. My current settings are;

Freq In – 50 MHz

PLL multiplier = 17

PLL divisor = 10

Phase Shift = -4.80 ns

I believe that I should be able to go up to 141.667Mhz using;

Freq In – 50 MHz

PLL multiplier = 17

PLL divisor = 6

Phase Shift = -?.?? ns

After talking with the Altera My Support folks, I have tried several phase shift values. Altera said that is should be the 90 degree value depending on the frequency you are trying to generate (e.g. at 141.666667 MHz, => (1/141.66667MHz) * (0.25) ~= -1.76ns) but this did not work. Any suggestions on either another phase shift value, or another area to look at. Thanks much for your help.

Fred

Are you adjusting your timing constraints accordingly with the changes you're making? Are you using timequest?

Jake

Jake,

No, I have never used this tool. It has amazed me that I have this system working with knowing so little. It is not until you start tweeking that you get into the tools you should have used up front. Thanks for pointing me in this direction.

Fred

Unfortunately, FPGA design is a lot more involved than uController design. You gain a wealth of flexibility and power but with the cost of added design investment.

Jake

I have given up on the DMA reading for it looks like it will indeed have too much overhead. I also believe that reading the PIO ports using the

IORD_ALTERA_AVALON_PIO_DATA command is too slow. Is there another way to rtead the PIO data? Thanks and have a great weekend!!

Fred

It seems like it's typically only about 3 clock cycles to do an IOWR or IORD. So for your 22 PIOs that's 66 clock cycles. Is that too slow? My calculation indicates that will take 0.7uS at your current clock speed. That is cutting it close. What are you going to do with the data after you get it? Are you going to have enough time to do whatever processing it is your going to do?

Maybe I'll write a little HDL module that will read them all for you and store them into memory.

If you could do one read per clock cycle, that would get your total sample time down to 0.260uS.

In reality, you could do two reads per clock cycle in HDL and get it down to 0.130uS.

Jake