Interconnections and interrupts between nios processors

[Altera_Forum]

Hi, 

 Now I am working on multi-core systms. Based on altera platform, more than two processors are using in a system and shard memory (message buffe) with Avalon-MM Pipeline Bridge is selected to connect nios processors.    Two questions involved in this issue: 1. Besides the shared memory, what interconnect or bus else can be used to connect nios processors? 2. If a message is transfered from Nios A to Nios B, how can I implement a corresponding interrup signal from Nios A to Nios B, aming at notifying Nios B there is a message coming.   Thank you very much for anwsers.

[Altera_Forum]

You could use a multiple of ways. For example, SPI. Just have one SPI master on Nios A and a SPI slave on Nios B. This will come with interrupts etc so it should be easy to do. Then just have another set in the opposite direction.  

 You could also wrap the dual port memory in some code and generate interrupts for when you write to a certain address. This would give you the ability to tell the other processor when a message has been written. I have done this in the past and it works really well.   /Boris

[Altera_Forum]

To Boris, 

Thank you very much for your reply! Using SPI is not suitable for my case because communication between nios processors in our design needs high speed. I don't understand your second way exactly since I am a fresh to use Nios and Qsys. Would you like to tell me in details?   Additionally, the interconnection between nios processors should be scalable, any suggestions?

[Altera_Forum]

You would have to make a custom component containing a dual port memory. One side would be for Nios A and the other for Nios B. You map all the addresses from Nios A to the dual port memory straight through except for writing to one address. Writing to this address will cause an interrupt to Nios B. You need the same on the other side of the memory as well. This way you can write a message on the dual port memory and last write to the interrupt address and then the other Nios will know that there are a message to be picked up. For making QSYS components check out http://www.altera.com/literature/hb/qts/qsys_components.pdf

[Altera_Forum]

Maybe just a custom interrupt controller and a dual port memory would be all you'd need

[Altera_Forum]

To lethenstrom, 

 Thank you very much! A custom interrupt controller would be a nice option for me. If a multi-core system includes more than two processors, how it would work by using dual port memory? Or more dual port memory blocks are involved(this is the reason I want to use pipeline bridge, but I don't know how to transfer interrupt signals between processors in Qsys)?

[Altera_Forum]

It all depends on the performance you are after on how you would implement this. You could use one single memory for all your processors and the arbiter handle who has access when. This would of course be a lower performance solution. The other is the you have a dedicated dual port memory between each of the processor that needs to communicate. This will cost more in resources, but have much higher performance since your have no data contention.  

 Also, a factor in this is the packet size that you desire. If it is large you might have to go more on the first method. If it is smaller packets you can easier do the dual port way. You can also do a hybrid method.   On the interrupt controller you would need one interrupt for each processor and a slave port that processor A can write to to cause an interrupt for another processor.

[Altera_Forum]

Are your Nios cpu on the same fpga - I assume so but someone mentioned SPI... 

 I'm not sure why you mentioned a pipelined bridge either. For speed you can dual port an internal memory block as 'tightly coupled data memory' to both cpu. Or maybe make it an Avalon slave to one and tightly coupled to the other.  If you need interrupts a small slave device that asserts an IRQ when 'set' will do. It can be worth having two locations and doing write-to-set and write-to-clear. Also worth supporting multiple bits and or'ing them onto the actual hw interrupt, maybe an enable mask as well! Oh - and you might as well hook up the nios soft reset lines to one of the bits....  Depending on the 'OS' (or lack of it!) you are using, interrupts may not be needed. If your code has an idle loop (probably calling a few functions) just check for 'work do to' in that loop. Saves the cost of the register saves in the ISR, and all the interrupt masking and deferring work to a non-interrupt context that is usually needed with ISRs.