Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12590 Discussions

Multiprosessor Nios systems

Altera_Forum
Honored Contributor II
1,463 Views

Where can I find examples about communicating multiprosessor systems? I need information howto create fifos and howto use shared memory at the Nios system. What would be the best (easiest) way to transfer data between prosessors?

0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
482 Views

I've done it two ways. 

 

Easiest is to just connect both processors to the same memory using the SOPC Builder patch panel. (in my case sdram) 

 

The other way that works faster/better in my system is I added a small onchip sram block and made it dual ported and connected each of two processors to a different port. Then I just developed my own little protocol for them to send commands and data to each other through this "mailbox" ram. 

 

Hope this helps. 

 

Ken
0 Kudos
Altera_Forum
Honored Contributor II
482 Views

Are you on Nios I or Nios II?

0 Kudos
Altera_Forum
Honored Contributor II
482 Views

I'm using Nios I at this time. Ken's mailbox idea sounds interesting. I'm just wondering if there is a ready solution for this mailbox/fifo thing by Altera or Microtronics. I've tried 16bit pio between prosessors, but I think some kind of memory based system is much more better.

0 Kudos
Altera_Forum
Honored Contributor II
482 Views

What you may need, in addition to the dual-port RAM, is a mailbox-interrupt peripheral. It would look like a 16- or 32-bit PIO register, but writing to it on the producer side would generate an interrupt to the consumer side, and reading from the consumer side (or something like that) would clear the interrupt. 

 

If you don't want to write a custom peripheral, there is a way to do it with PIOs. Create one PIO with 8 or 16 outputs for the producer. Create a PIO with the same number of inputs and outputs (not bidirectional pins) and a level-detecting IRQ for the consumer. Connect the external I/Os with a subtracter: consumer input = producer output - consumer output. 

 

The producer needs to have a shadow variable with the last value written to its PIO. When it wants to wake up the consumer, it increments this shadow variable and writes the result to the PIO. 

 

The consumer also has a shadow variable with the contents of its PIO. It initializes the edge detection to interrupt whenever the input is not all 0's. The IRQ handler reads the PIO to determine the number of events since the last time it was handled. It can then do one of two things:[list][*]Add this number to its shadow variable and write the result back to its PIO, or 

[*]Loop, incrementing the shadow variable each time and writing it back, until the value read back is 0. 

[/list]Note that the number of PIO bits used determines the maximum number of pending events; size it appropriately. I think this design is race-proof; if not, someone please show me what will break it. 

 

Note to Altera: it would be nice to have a peripheral that does this; one peripheral with two slave ports. The HAL driver would be a character driver; you write characters to the producer device (one character increments the counter by 1; the actual character is ignored) and read characters from the consumer device. I don't remember if there is a select()-like call in HAL, though.
0 Kudos
Altera_Forum
Honored Contributor II
482 Views

Mike, 

 

Great protocol. Almost exactly what we do on our dual Coldfire board, but we use a physical DPR that generates the interrupts and provides the mailbox. 

 

I didn't want to use IRQ's in this design because I need the second processors ISR latency for its most important task to be as jitter free as possible. I've found with the LA that IRQ activity increases jitter even for the highest priority ISR's. 

 

In my case the second processor can check for new messages whenever its convenient because command response latency of several ms is fine.  

 

hassu3, 

 

Mike's IRQ approach would really just tell the processor it was time to check his mail. You still may need the mailbox or something like it to transfer commands and data.  

 

Ken
0 Kudos
Altera_Forum
Honored Contributor II
482 Views

My two cents... 

 

I have implemented a multi-processor system using UARTs to pass data from one CPU to another. This interface is rather slow; but quite effective. I suspect SPI would be a whole lot better, but have not tried it... 

 

Cheers, 

tjd
0 Kudos
Reply