Transferring data from a HDL to the Nios II processor

[Altera_Forum]

Hello, 

 I have a HDL module which is connected to the Avalon bus as a slave component. The component has a FIFO with a length of 4096 * 32 bits values which the processor should read out perdiodically. The processor should always read from the same address.  According to: http://www.altera.com/literature/tt/tt_nios2_tightly_coupled_memory_tutorial.pdf I should use the IORD macro to read out the data.  The following questions are bothering me:  1. I haven't quite understood why using a pointer to the device address (e.g. int32_t *module_data = MODULE_BASE) won't work. Why does it work for memory (like DDR RAM attached to the processor) but not for a memory mapped device attached to the Avalon bus?  2. Is it possible to use a DMA controller to do the data transfer (is generally possible, e.g. if I would change the module so that every word has its own address)? Transferring the data using only the IORD macro would probably eat a lot of CPU cycles.  Best regards Martin

[Altera_Forum]

Hi, 

A1. The IORD macro ensures that you bypass any cache the CPU might have.  Using a pointer might work correcly.. or not.  A2. Yes, you can use DMA. The SGDMA core supports several use cases. You don't need to modify your component. The SGDMA core can peform a DMA while repeatedly reading from the same address.  Another good option is to make your component have an Avalon-ST source interface and use the SGDMA core to copy data from the stream to memory.   See the Embedded Peripherals User Guide.

[Altera_Forum]

Hi, 

 thanks for your answers! I think I will try the SGDMA solution then as I don't have to modify my component then.  The Avalon-ST bus sounds interesting but I think I'll try the SGDMA solution first.

[Altera_Forum]

Avalon-ST is not a bus, it's a simple FIFO like interface for streaming data. 

 And SGDMA also supports Avalon-ST sources/sinks.

[Altera_Forum]

Ok that's interesting. I haven't read the documentation about the Avalon ST interface thoroughly. There are probably better ways to implement the data transfer than what I intend to do now but most importantly it has to be running pretty soon. 

 What I want to do is transfer some measurement data and status registers. The Nios II configures my component with which measurement data it wants and what status registers.  I chose to put the selected data into a FIFO in the correct order so that the Nios II simply has to read the data (the Nios II knows from the configuration how much data it has to read until the FIFO is empty). Another possibility I was thinking of was to put each measurement and register data at a memory address which the Nios II could directly access. This would have had the advantage that the Nios II would have known which data it was going to read. In the current implementation the processor has to look at the selected configuration to know how much data it has to read and what the meaning of each word is.  I'm open to other suggestions on how to best transfer a data stream of variable length to the Nios II.

[Altera_Forum]

It really depends on your case. 

 Ie, if I assume that your component always holds all the status and measurement data, then it may be simpler to simply expose that in the MM slave interface as separate addresses. This would avoid the need to copy the selected data into the FIFO.  It also depends on your performance needs. In an extreme case, you may want your component to be have a MM master interface and write data directly into RAM.

[Altera_Forum]

I haven't look at implementing a master but I think a master interface is probably more difficult to implement than the slave interface. I saw that Altera offers a few templates for implementing master interfaces which I'm going to look at for the next project. 

 The component internally stores the data in addressable registers and then puts the data into the FIFO. The reason for doing it this way was that new data comes into the component at a steady rate. The Nios II has then to send the data over ethernet. As we are not sure that the processor could fetch and send the data fast enough I chose to use the FIFO. Otherwise it could have happened that the processor read data from different sample times because while the processor would still read the old data, new sample data could be written to the registers.

[Altera_Forum]

Hello StMartin81, 

 Did you finish your project? I am also encountering this issue. I also want to transfer data from HDL to Nios II memory. If you experienced it, can you tell me what I should do to get data to Nios II system?

[Altera_Forum]

Yes I've finished my project but I'm using another solution now. I'm not reading from the same address now but have a memory which is attached to the processor. 

 So what I have now is the following: - I only need to read data - The data is stored in dual port RAM which is attached to the processor  So the signal flow looks like this: custom component -> RAM -> Avalon bus -> NIOS II  To read data from the RAM the processor cache has to be cleared first so that the processor doesn't use old cached data.  I've attached an example of the interface I'm using now. I've taken this from my project and copied the relevant code so you could use it as a starting point. So probably you have to clean up the code before it synthesizes.

[Altera_Forum]

Thank you for your help. 

 I will try. It helps me a lot, at least in my orientations.

[Altera_Forum]

Hi,StMartin81 

Have your problems solved?I have met the same problem with you.

[Altera_Forum]

Yes, but as explained in this previous post: http://www.alteraforum.com/forum/showthread.php?t=33460&p=167183#post167183 I've implemented another solution.

[Altera_Forum]

can you send your top file to me?how the dual port RAM worked,and the data from avalon bus to nios,the IORD is the only way?have something other ways to read the data from Avalon Bus with less CPU circuits?can you help me?