After many years of hype, multicore and multiple-CPU embedded systems are now becoming mainstream. There are numerous articles about multicore design that address different hardware architectures (homogeneous and heterogeneous multicore) and software architectures (AMP: asymmetrical multi-processing and SMP: symmetrical multi-processing). In this article the development of an AMP system is outlined, highlighting various challenges that were addressed. What is unusual is that the design was completed in 1981!
It often appears that there is nothing truly new in the world. With technology, it is often a question of the time being right. The programming languages that we use nowadays are mostly developments of 30-40 year old technology. The current enthusiasm for multicore designs is really nothing new either. Browsing the literature turns up titles like “Multi-core is Here Now” that have been appearing for at least 5 years.
But multicore goes back further still. I was working on a multi-core system in 1980 …
How it all started
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 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 simply to link a mini-computer to a traditional console. The next – and, at the time, brave – step was to replace the entire console with a microprocessor where a keypad enabled input of parameters and selection of settings from menus on a screen. Of course, a mouse or touch screen might have been better, but that technology would not appear for some years.
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. This is exactly how I might advise a customer today who is designing a multicore system with real-time and non-real-time components.
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 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. The instruction set and addressing modes bore some similarity to the 68000. I recall that the documentation was confusing, as the bits were numbered backwards, with the most significant bit being #0. This part of the system was programmed in Forth code (see code below). I have no idea why this design decision was made, but I found the language intriguing and my interest persists.
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 familiar to us at the time. “SBC” was apparently short for “shoe box computer”, because that is what it looked like. I have a suspicion that this was a joke and it actually stood for “single board computer”, as it does today. We implemented user programmability using a variant of the BASIC language, with some extensions to access capabilities of the testing machine.