Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.

Multiprosessor Nios systems

Altera_Forum
Honored Contributor I
1,039 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 I
58 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
Altera_Forum
Honored Contributor I
58 Views

Are you on Nios I or Nios II?

Altera_Forum
Honored Contributor I
58 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.

Altera_Forum
Honored Contributor I
58 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.
Altera_Forum
Honored Contributor I
58 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
Altera_Forum
Honored Contributor I
58 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
Reply