Introduction

The Celtic Engineer is a weekly newsletter produced by Celtic Engineering Solutions.  We hope you enjoy it.  If you have any suggestions for topics, would like to give feedback or want your email added to the distribution list please send an email to [email protected].

The Joys of the Harvard Architecture

What should a computer architecture look like? What should computers do?  During the computer’s early development in the 1940’s and 50’s (Dyson, 2012), program and data storage was an overriding issue (Gruenberger, 1968). Many storage devices were tried, discarded, reimagined, and reengineered. A throwback to this era is the Harvard Architecture where the program was stored on relatively stable media (such as paper tape) and, data on expensive registers made from relays, vacuum tubes, mercury delay lines and Williams storage tubes. The Harvard Mark I, II, and II of the late 1940’s used loops of wide paper tapes as a program storage media (hence our program loops), table look up also on paper tape, with only a few registers for data storage (Engineering Research Associates, 1950). This Harvard Architecture is still found in many small micro-controllers: The 8051, the early Microchip 16 series, and others where program and data are on separate busses with program in flash (Flash, EEPROM or UV erasable) and data in static RAM of various sorts.

What do you gain from the Harvard Architecture?

Program storage is low power – storing programs in RAM is good for systems with an operating system but the program has to come from somewhere. What better than to have it where it’s supposed to be when you turn the processor on? If your application has a thousand processors this is a significant consideration. Flash memory uses about a tenth the power of the equivalent amount of RAM. Though there are limits to Flash’s speed, small applications with little available power can readily benefit.

What you lose is the reasonable ability for a program to modify itself. For example, some early Fortran versions of the FFT would build the code and constants into a Fortran array and then execute the array. Another example is a linker/loader that builds an executable image from your code and a library and then executes the code. For a Harvard architecture, you must do these things on a different processor and store the code in Flash with some programming device such as JTAG. How often are you going to write a compiler? A linker/loader? Some truly efficient filter code on the fly? Do these need to run on a 1.5mm² micro-processor?

What can you do to exploit these devices and make them more general purpose?

An easy answer is to treat them as micro-code machines. Many modern processors are based on this concept where the machine instructions are decoded and executed by a lower level machine with even more primitive instructions. Higher level versions of this concept include FORTH (FORTH-83 Standard, 1983), BASIC and many others. The interpreter is hard coded in flash and the program to execute stored in RAM. The interpreter examines the RAM program and performs the actions it dictates.

The advantages:

• You can execute very complex programs on small devices,
• You can have many such programs on small devices,
• The programs are easier to write than the interpreter,
• The resulting device is much more capable at a lower starting price.

The disadvantages:

• The programs aren’t as fast, they take more electrical power to complete their task,
• You have to design a language and write an interpreter or use somebody else’s design and write an interpreter,
• You may need to write a compiler/linker for a minimal interpreter,
• You need a file system to store programs,
• You might need a dynamic storage allocator for limited RAM.

Do you know your machine?

Are you comfortable with its architecture and programming tools? If so, then an interpreter may be just the thing. Very simple Basic interpreters have been written for minimal devices such as the Silicon Laboratories C8051F310 that has 16k bytes flash and 1k bytes RAM. Nearly complete Basic’s with floating-point, arrays, strings, graphics, and rudimentary file operations have been written for somewhat larger devices – 65k flash, and 8k RAM. These were capable of driving touch screen displays with high speed text and graphical primitives.

I’ve long been fascinated with the ability of small, simple machines to perform complex tasks. As modern computing gets more remote from the fundamental machine, the efficiency of computation – the energy cost per task – has decreased. If one is willing to take the time and energy, these devices can perform truly amazing tasks.

References

• Dyson, G. (2012). Turing’s Cathedral. New York: Vintage Books.
• Engineering Research Associates. (1950). High-Speed Computing Devices (First ed.). (J. W. W. Stifler, Ed.) New York: McGraw-Hill Book Company, Inc.
• FORTH-83 Standard. (1983). Retrieved from http://forth.sourceforge.net/standard/fst83/
• Gruenberger, F. J. (1968). The History of the Johnniac. Santa Monica: RAND Corporation.

Dr. Jed Marti has been computing, not since the dawn of digital computing, but at least some time after breakfast. He was one of the early developers of the Time Warps concurrent simulation system, the algorithms behind the Iron Curtain active protection system, sea sickness prevention, human monitoring of all sorts, and has served on standards and government committees. He has published 3 books and authorship of 3 patents.

Final thoughts

Gruenberger, F. J. (1968). The History of the Johnniac. Santa Monica: RAND Corporation.

Celtic Engineering Solutions puts together strong teams to meet our customers needs.  Contact us today to see how we can help you succeed.

This newsletter is sponsored by Celtic Engineering Solutions LLC, a design engineering firm based out of West Jordan and Murray, Utah, which can be found on the web at: www.celticengineeringsolutions.com.  We are also on Facebook, Instagram and Twitter.  If we can ever help you with your engineering needs please contact us.  You can find the newsletter on the company blog, LinkedIn or in your inbox by subscribing.  Send your emails to The Celtic Engineer at:  [email protected], with the subject line SUBSCRIBE. 

Do you know someone who would enjoy the newsletter?  Forward them a copy or let them know where to find it.