Vintage multi-core and “so long”

• Software Development
• System Design

Today is my birthday [I am 68 - how did that happen?] and I have designated it The Last Day of my Embedded Software Career. I started my first job on 28 August 1979; I finished from my last employment on 30 March 2021 - 4 years ago. That was my retirement and, in the meantime I have dabbled with a few assignments, when something came along that interested me. Having planned for my retirement, I was not seeking to top up my income really, but the odd bit of pocket money was always welcome.

I decided that I would “get out while I’m winning” and I do not plan to take on any more embedded software related work. I accept that I will increasingly get behind with my knowledge of the technology, but I am happy to let the next generation have all the fun now. Although, I guess, if something came along that was really irresistible …

In setting out on my working life, I had two ambitions: one specific and one broad. The specific one was to get published; over the years, I had countless articles published and my first book appears in 1986 - probably the first book on embedded software. My broad ambition was to never end up working in a job that I hated; I never did.

So, for my last blog post, I thought I’d tell a story from early in my career …

Sometimes I think that there is nothing truly new in the world. With technology, it is often a question of the time being right. It occurred to me that the current enthusiasm for multi-core designs is really nothing new. I browsed some of the literature and titles like “Multi-core is here now” have been appearing for at least 10 years.

But it goes back further still. I was working on a multi-core system in 1980 …

It was my first job out of college and I worked for a company that made materials testing instruments – large machines and systems that stressed and broke things under controlled conditions. The use of computer or microprocessor control was very new. Hitherto, the machines had been controlled by racks of analog electronics, with meters and chart recorders providing results. I worked in the division that provided the computer control. Initially, the approach was to simply link a mini-computer to a traditional console. The next – and, at the time, very brave – step was to replace the entire console with a microprocessor where a keypad enabled input of parameters and selection of settings on a screen.

The project, to which I was assigned, was to facilitate the “user programmability” of the new microprocessor controlled machines – the “User Programmability Option” or “UPO”. It was decided that the best way to provide this capability would be to add an additional computer instead of potentially compromising the real-time behavior of the controlling microprocessor.

The advanced console was built around a Texas Instruments ~9900~ microprocessor, which was one of the first true 16-bit, single chip devices on the market. It had quite an advanced architecture, with some interesting pros and cons: it could intrinsically support multi-threading in a very simple way, with context saving accommodated in hardware; but its registers were mostly RAM based, which, at the time, was a significant performance limiter. This part of the system was programmed in Forth. I have no idea why this design decision was made, but I found the language intriguing , so was happy to learn the language.

The UPO computer was an SBC-11. The “11″ came from the internal processor, which was essentially a DEC ~PDP-11~; a mini-computer which was very familiar to us at the time. “SBC” was short for “shoe box computer”, because that is what it looked like. We implemented user-programmability using a variant of the BASIC language, with some extensions to access capabilities of the testing machine.

The two computers were linked together by a shared memory interface, which proved an interesting challenge to get right. More on this later…

After many months of work, the project was completed and the system marketed. I made numerous customer demonstrations and I think we actually sold a few. I measured the success in terms of the technical achievement: it worked!

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~, for example, is to use one core for real time functionality [running an RTOS perhaps] and another for non-real-time activity [maybe running 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, but we needed to make it up as we went along. It was fun in those days. 🙂

So that’s it - my last blog completed. All that remains is for me to offer thanks to you for reading and to all the people that enabled me to get to this point with help and support in numerous ways. Adieu! 

Sign in