{"id":834,"date":"2010-04-19T10:31:55","date_gmt":"2010-04-19T09:31:55","guid":{"rendered":"https:\/\/blogs.mentor.com\/colinwalls\/?p=834"},"modified":"2026-03-26T16:32:17","modified_gmt":"2026-03-26T20:32:17","slug":"vintage-multi-core-the-ipc","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/embedded-software\/2010\/04\/19\/vintage-multi-core-the-ipc\/","title":{"rendered":"Vintage multi-core – the IPC"},"content":{"rendered":"

Last week, I wrote<\/a> 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 we were developing all those years ago and modern ideas for multi-core design. A common approach, which I mentioned here<\/a>, for example, is to use one core for real time functionality [running an RTOS like Nucleus<\/a> perhaps] and another for non-real-time activity [maybe running Android or Linux<\/a>].<\/p>\n

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 …<\/p>\n

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<\/a> 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.<\/p>\n

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].<\/p>\n

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:<\/p>\n