Last time, I wrote about a “multi-core” project that I was working on 30 years ago. To be fair, it was actually “multi-CPU” rather than “multi-core”, but many of the challenges were similar, as was the initial design decision to take the approach of distributing the processing capacity. It is interesting to draw a comparison between the system that we were developing all those years ago and modern ideas for multi-core design. A common approach is to use one core for real time functionality (running an RTOS like Nucleus perhaps) and another for non-real-time activity (maybe running Android or Linux).

Using multiple CPUs (or cores) presents a variety of challenges. One is the division of labor, which was reasonably straightforward in this case. Another is communication between the processors …

In designing the UPO, we considered a number of means by which the two CPUs might be connected. As they were separate boxes, serial and parallel connections were considered. Nowadays, I am sure that USB would have been an option too. But we were very concerned about any possible compromise of the real-time performance of the console microprocessor. Also, we did not want the user to be faced with the UPO freezing while it waited for attention from the console. So, clearly a buffering mechanism was needed and shared memory seemed to be a good option.

A small memory board was designed. I have no idea of the hardware architecture, except that I seem to recall that the TI-9900 had priority over the SB-11, as it could not afford to be delayed by slow memory access. If I remember correctly, the board was 2K (words, probably).

It was down to us to define a protocol for communication, so we aimed to produce something that was simple and reliable. We divided the memory into two halves; one was a buffer for communication from the UPO to the console and the other for the opposite direction. The first word of each buffer was for a command/status code, which was simply a non-zero value. We did not use interrupts. The receiving CPU just polled the first word when appropriate, awaiting a non-zero value. When a command was found, any data could be copied and the command word cleared to zero indicating that the processing was complete. So, the UPO sending a command to the console might go through a sequence like this:

• Write data to the buffer (second word onwards).
• Write a command to the first word.
• Poll the word, waiting for it to become zero.

If it was expecting a response, it would then start monitoring the other buffer. Of course, there were other facilities to handle a situation where one CPU did not respond after a timeout period.

Nowadays, multi-core and multi-chip systems have a variety of interconnection technologies, but shared memory is still very common. A number of standardized protocols have been developed over the years, including derivatives of TCP/IP. In recent years, the Multicore Association produced MCAPI, which is rapidly gaining broad acceptance in multi-core embedded system designs.

Read more from Colin on SciTech Connect:

• Staying Inline
• Thanks for the Memory
• Software Product Quality: Belief or Proof?
• Embedded Optimization: Small or Fast?
• C, C++ and the Family Tree
• Agile Embedded

Colin’s most recent publication, Embedded Software: The Works is available now on the Elsevier Store. Save 30% on his book and other Newnes Press and embedded systems books. Use discount code “STC3014″ at checkout. 

About the Author

Colin Walls (@Colin_Walls) is an embedded software technologist at Mentor Graphics (@mentor_graphics), the leading EDA software company.

You can read more about Colin and his work on embedded systems at The Colin Walls Blog at Mentor Graphics here. Connect with Colin online here: