What is/are the right SOPC compenent(s) for my project?

That's pretty much how I would do it. The only component you are missing is the ADC. You can probably make a component comprised of the dcfifo megafunction which is clocked at whatever your sample rate is offchip and your system speed on the other side. You would export the sampling side using a conduit and map the other side to a streaming source port that you would connect to the SGDMA in ST-->MM mode.

To do the flow control on the ST side of the FIFO you can drive the ST valid signal using 'fifo not empty'. The ST ready coming into the interface you would logically AND with 'fifo not empty' and use that to drive the readack signal of the FIFO. Make sure to put the FIFO into lookahead mode so that you can keep the ST ready latency down to 0.

Here is the Avalon spec for more details: http://www.altera.com/literature/manual/mnl_avalon_spec.pdf

The SGDMA can trigger the interrupt at the end of each descriptor chain. Each descriptor in the chain can describe up to 64kB in payload size. If you want to send more data than that then just chain a bunch of descriptors together. Alternatively you can use this which has a simpler programming model: http://www.altera.com/support/examples/nios2/exm-modular-scatter-gather-dma.html?gsa_pos=1&wt.oss_r=1&wt.oss=modular

Hi BadOmen,

thanks for your reply. The dcfifo hint is great and will be implemented. I just only don't find the proper ST component which I can use for my ADC component so that I will implement the Avalon-ST interface myself and will import that as user component in my SOPC system.

The SGDMA example you pointed me to looks very interesting. It seems as if this isn't using the standard SGDMA which I find in my SOPC library (I don't have this "Modular SGDMA Dispatcher" module).

I found nothing on the website or in the downloaded documentation that I'm not allowed to use these components. What do you think? Is it okay to use them in commercial projects?

Maik

Okay, next thing I'm thinking about is that my Nios runs with =<50Mhz and the ADC/SGDMA/SRAM part of the system runs with a different clock speed (here 80Mhz).

I think I need a clock crossing component in my SOPC design.

Where do I have to connect this? Between the SRAM component and the CPU or between the Tristate Bridge and the CPU? I havn't found any according SRAM examples on the net . . .

Maik

Since ADCs have many different interfaces it is not included as a standard component in SOPC Builder. Creating a new one is pretty easy though since it's just a FIFO for the most part.

The modular SGDMA can be used and modified in any project. It's offered as a design example so that users have an alternative to the SGDMA that's shipped with SOPC Builder. Since it's modular you can implement variant DMAs easily by re-using the master logic and just replacing the controller (dispatcher). The master blocks are the difficult ones to implement due to all the features and the tuning that's involved so usually the customization is left in the controller portion of the DMA. If you copy the IP directory from the design example into your own project then the cores will appear the next time you open SOPC Builder in the category "Modular SGDMA".

The SRAM component must be on the same clock domain as the tri-state bridge so if you want to operate the Nios II core on a different clock domain then the clock crossing bridge would need to be between the tri-state bridge and CPU (at a minimum). One question, does the CPU need to access the sampled data in memory? I ask because any time you introduce clock crossing you increase the memory read latency by around 12 clock cycles so if you are looking to process the samples you would probably be better off keeping the CPU on the same domain. Examples will be hard to find since cranking up the memory latency is normally bad for embedded systems.

Thanks again for the helpful conversation!

Well, yes, I would like that sampled data in memory be processed by the CPU. I agree that at 80Mhz the CPU can go that pace and it would be possible to run the whole system at one speed.

But what if I go a step further with my ADC/SGDMA/SRAM clock and run it at say 125MHz? I can imagine that the Nios CPU won't take that high speed at some point (in a Cyclone III device).

I know that I can't process the ADC data continiously with the CPU when the CPU is slower but I can make a fast shot of a couple of thousand samples and after that I can process the data at a slower pace with the CPU (maybe a FFT implemented in software in order to save LEs that I would need for a hardware FFT module).

I have relative fast signals to process but the results of the processing have not to be faster than say 10Hz. So a combination of a fast sample shot and a relativ slow processing of the data after that would be what I need. I'm right now trying to test the possibilities if this works as I imagine it.

Please, feel free to give me advises if I , in your opinion, am not thinking in the right directions.

Regards,

Maik

125MHz is doable on Cyclone III, especially with a fast speed grade device (I've hit around 180MHz using a -6 speed grade). Since your samples come it at 80MHz, that's the maximum fill rate to the memory. So bumping up the ADC and everything else isn't really going to speed up how fast you can fill the memory since the ADC won't be able to keep up. Since you plan on doing FFT in software you'll need all the performance you can get as it's really slow that way.

So if you keep the CPU and SRAM on the same domain and clocked it as high as possible that will give you the most software computational throughput. Things like streaming data, DMAs, etc... usually are not affected by latency so if you did your clock crossing there then you will be able to keep the CPU clocked fast and with low latency access to SRAM as well as isolating the other logic to some other clock domain. If you have a lot of stuff mastering SRAM you may find the fanin-out reduces the Fmax and that's where inserting pipeline bridges may be needed. Here is a doc you can take a look at for more details: http://www.altera.com/literature/hb/nios2/edh_ed5v1_03.pdf

Hi,

okay, the show goes on . . .

Today I implemented the SOPC system shown in the attachment. I designed my own ADC streaming component (ads62_avalon_st) and connected it with the SGDMA components provided in the example that BadOmen gave to me.

I use the following code to try to start the SGDMA:

# include <io.h>
# include <stdio.h>
# include <stdlib.h>
# include "sys/alt_dma.h"
# include "system.h"
# include <unistd.h>
# include "sys/alt_irq.h"
# include "altera_avalon_spi.h"
# include "altera_avalon_spi_regs.h"
# include "altera_avalon_pio_regs.h"
# include "i2c_defs.h"
# include "e_adc_0100_firmware_defs.h"
# include "descriptor_regs.h"
# include "csr_regs.h"
# include "response_regs.h"
# include "sgdma_dispatcher.h"
static volatile int rx_done = 0;
char* OK = "-> OK!\n";
char* FAILED = "-> FAILED!\n";
// flag used to determine when all the transfers have completed
volatile int sgdma_interrupt_fired = 0;
static void sgdma_complete_isr(void *context, alt_u32 id)
{
	sgdma_interrupt_fired = 1;
	clear_irq(SGDMA_DISPATCHER_CSR_BASE);
}
int main()
{
	int total_error_counter = 0;
	int current_error_counter = 0;
	int testNumber = 0;
	unsigned int potValue = 0;
	unsigned int pioIn = 0;
	unsigned int pioOut = 0;
	char c = 0x00;
	int i = 0;
	
	sgdma_standard_descriptor a_descriptor;
	sgdma_standard_descriptor * a_descriptor_ptr = &a_descriptor; // using this instead of 'a_descriptor' throughout the code
	unsigned long control_bits = DESCRIPTOR_CONTROL_TRANSFER_COMPLETE_IRQ_MASK;
	alt_irq_register(SGDMA_DISPATCHER_CSR_IRQ, NULL, sgdma_complete_isr); // register the ISR
	enable_global_interrupt_mask(SGDMA_DISPATCHER_CSR_BASE); // turn on the global interrupt mask in the SGDMA
	construct_standard_st_to_mm_descriptor(a_descriptor_ptr, (alt_u32 *)SRAM_BASE, 0xff, control_bits);
	while (1)
	{
		c = getchar();
		if (c == START_SGDMA_TRANSFER)
		{
			if (write_standard_descriptor(SGDMA_DISPATCHER_CSR_BASE, SGDMA_DISPATCHER_DESCRIPTOR_SLAVE_BASE, a_descriptor_ptr) != 0)
			{
				printf("Failed to write descriptor to the descriptor SGDMA port.");
			}
		}
		if (sgdma_interrupt_fired == 1)
		{
			for (i = 0; i < 0xff; i++) {
				printf("%x\n", IORD_32DIRECT(SRAM_BASE, i));
			}
			sgdma_interrupt_fired = 0;
		}
		if (c == OUTPUT_RAMP_PATTERN)
		{
			printf("ADS62 outputs digital ramp.\n");
			IOWR_ALTERA_AVALON_SPI_CONTROL(ADS62_SPI_BASE, ALTERA_AVALON_SPI_CONTROL_SSO_MSK);
			IOWR_ALTERA_AVALON_SPI_TXDATA(ADS62_SPI_BASE, 0x0002);
			IOWR_ALTERA_AVALON_SPI_CONTROL(ADS62_SPI_BASE, 0x0);
			usleep(10);
			IOWR_ALTERA_AVALON_SPI_CONTROL(ADS62_SPI_BASE, ALTERA_AVALON_SPI_CONTROL_SSO_MSK);
			IOWR_ALTERA_AVALON_SPI_TXDATA(ADS62_SPI_BASE, 0x1614);
			IOWR_ALTERA_AVALON_SPI_CONTROL(ADS62_SPI_BASE, 0x0);
			usleep(10);
		}
		if (c == SRAM_TEST)
		{
			// Test SRAM.
			printf("\n\nTesting SRAM with Counter 0x0 -> 0xFFFF.\n");
			// Write testpattern into memory.
			for (testNumber = 0; testNumber < 0xffff; testNumber++)
			{
				IOWR_32DIRECT(SRAM_BASE, testNumber, testNumber);
			}
			// Read test pattern from memory.
			for (testNumber = 0; testNumber < 0xffff; testNumber++)
			{
				if (IORD_32DIRECT(SRAM_BASE, testNumber) != testNumber)
				{
					current_error_counter++;
					total_error_counter++;
					printf("SRAM Read Error at Address: %x\n", testNumber);
				}
			}
			if (current_error_counter == 0)
			{
				printf("Counter Pattern %s\n\n", OK);
			} else
			{
				printf("Counter Pattern with %d Errors %s\n\n", current_error_counter, FAILED);
			}
		}
		c = 0x00;
	}
}

Unfortunately this is not working, yet (it seems that the interrupt after the SGDMA transfer is not triggered). However, the SRAM test is working as expected.

I will continue tomorrow but maybe, in the meantime, somebody has an idea that will help me to get this running.

Thanks,

Maik

Unless you need to readback the error/channel numbers then you probably don't need the response port enabled on the dispatcher block. It contains a FIFO so if it fills up and you don't empty it the DMA will become blocking.

It looks like you are working with 32-bit data. If you setup the write master for "Full word access only" mode and passed in a transfer length of 255 bytes I could see that being problematic. That mode requires that you pass in a transfer length that is a multiple of the word size (I'm assuming 4 bytes per word in your case so 256 would be the closed valid length) Some of your code looks like you are using 0xFF as if the transfer length is in terms of words, it's actually bytes so if you wanted 0xFF transfers and the data is 32-bit use 0x3FC instead.

Hi,

I think I'm on a good way to finally get what I need.

The tip to turn the response port "off" solved the problem that nothing happened. But now, when I read the SRAM memory content triggered by the interrupt of the SGDMA, I can verify that the ADC data is written to the SRAM but with a "stride" of 4.

So the ADC content (32 bit wide) is written to address 0x00, 0x04, 0x08, . . . .

In between, the memory is untouched. On addres 0x01 - 0x03, 0x05 - 0x07, ... I still can read the contents that my SRAM test routine has written to the memory.

I played a little bit with the parameters of the SOPC blocks, but I had no success in solving this issue. In the attachments you can see the settings of each block.

Maik.

The part where you are reading back the data you are using IORD_32DIRECT which means you have to pass in byte offsets (and they must be a multiple of 4 since Nios II does not support unaligned accesses). i.e. use this instead:

if (IORD_32DIRECT(SRAM_BASE, 4*testNumber) != testNumber)

I saw some other spots where you were using IOWR_32DIRECT, you probably will have to do the same 4* there too.

For example if I wanted to read back words from 'SSRAM_BASE' I would do this:

IORD_32DIRECT(SSRAM_BASE, 0)

IORD_32DIRECT(SSRAM_BASE, 4)

IORD_32DIRECT(SSRAM_BASE, 8)

etc...