标签: microprocessor

Recently, I finished reading Richard J. Aldrich's GCHQ: The uncensored story of Britain's most sensitive intelligence agency . The Government Communication Headquarters (GCHQ), Britain's equivalent of the NSA, is a direct descendant of Bletchley Park, where the British decoded German messages encoded by the Enigma machine and where the world's first programmable electronic digital computer, the Colossus, was built. It was the stomping ground of Alan Turing during the Second World War and -- according to Winston Churchill -- where the war was won. In my not-so-humble opinion, the greatest technical museum for any electrical engineer is Bletchley Park.   Back to the book, which is about how the British monitor telecommunications traffic from around the world and decode it to provide "intelligence" for military and political purposes. It is a fairly weighty tome, long on facts and short on anecdotes. It is also not a particularly easy read. However, on page 400, I was wading through the description of the Falklands War when I came across this sentence: "The Argentinean Air Force's traffic was the hardest to read, since it had recently invested in new encrypted communications made by a subsidiary of the British defence company Racal, based in South Africa."   "Just a minute," I said aloud to myself, "that was one of mine." Actually, this is a bit of an exaggeration. In fact, I had designed the first prototype -- the proof of concept -- for the microprocessor that controlled the digital tuning of a radio to operate as a frequency-hopping device. It was a very early application of a microprocessor. It synchronized the transmission and then controlled the calculation of the next frequency to which the transmission would hop.   The facts presented in the book are a little suspect, since by that time Racal had sold the organization to a South African company, Grinaker Electronics, but perhaps Racal still held some shares or was responsible for international marketing. The book makes the point that, when it comes to arms supplies, there are some very strange bedfellows, so the fact that this system had ended up in Argentina did not surprise me too much. What did surprise me was that this system should come back into my life 38 years later. It felt really surreal, almost like I was looking at the back of my own head. Maybe I have been around long enough to be on my second lap now.   All this reminded me of the British engineer Sir Robert Alexander Watson-Watt, was a significant contributor to the development of radar during the Second World War. He emigrated to Canada in the 1950s and -- later in life -- was caught in a radar speed trap in Ontario. He is reported to have said to the police officer, "Had I known what you were going to do with it, I would never have invented it." He even wrote a poem about it:   Pity Sir Robert Watson-Watt, strange target of this radar plot And thus, with others I can mention, the victim of his own invention. His magical all-seeing eye enabled cloud-bound planes to fly but now by some ironic twist it spots the speeding motorist and bites, no doubt with legal wit, the hand that once created it.   Does any of this strike a chord with you? Have you ever been blindsided by your own design? If so, it would be great if you would share your experiences in the comments below.   Aubrey Kagan Engineering Manager Emphatec

I recently read Richard J. Aldrich's GCHQ: The uncensored story of Britain's most sensitive intelligence agency . The Government Communication Headquarters (GCHQ), Britain's equivalent of the NSA, is a direct descendant of Bletchley Park, where the British decoded German messages encoded by the Enigma machine and where the world's first programmable electronic digital computer, the Colossus, was built. It was the stomping ground of Alan Turing during the Second World War and -- according to Winston Churchill -- where the war was won. In my not-so-humble opinion, the greatest technical museum for any electrical engineer is Bletchley Park.   Back to the book, which is about how the British monitor telecommunications traffic from around the world and decode it to provide "intelligence" for military and political purposes. It is a fairly weighty tome, long on facts and short on anecdotes. It is also not a particularly easy read. However, on page 400, I was wading through the description of the Falklands War when I came across this sentence: "The Argentinean Air Force's traffic was the hardest to read, since it had recently invested in new encrypted communications made by a subsidiary of the British defence company Racal, based in South Africa."   "Just a minute," I said aloud to myself, "that was one of mine." Actually, this is a bit of an exaggeration. In fact, I had designed the first prototype -- the proof of concept -- for the microprocessor that controlled the digital tuning of a radio to operate as a frequency-hopping device. It was a very early application of a microprocessor. It synchronized the transmission and then controlled the calculation of the next frequency to which the transmission would hop.   The facts presented in the book are a little suspect, since by that time Racal had sold the organization to a South African company, Grinaker Electronics, but perhaps Racal still held some shares or was responsible for international marketing. The book makes the point that, when it comes to arms supplies, there are some very strange bedfellows, so the fact that this system had ended up in Argentina did not surprise me too much. What did surprise me was that this system should come back into my life 38 years later. It felt really surreal, almost like I was looking at the back of my own head. Maybe I have been around long enough to be on my second lap now.   All this reminded me of the British engineer Sir Robert Alexander Watson-Watt, was a significant contributor to the development of radar during the Second World War. He emigrated to Canada in the 1950s and -- later in life -- was caught in a radar speed trap in Ontario. He is reported to have said to the police officer, "Had I known what you were going to do with it, I would never have invented it." He even wrote a poem about it:   Pity Sir Robert Watson-Watt, strange target of this radar plot And thus, with others I can mention, the victim of his own invention. His magical all-seeing eye enabled cloud-bound planes to fly but now by some ironic twist it spots the speeding motorist and bites, no doubt with legal wit, the hand that once created it.   Does any of this strike a chord with you? Have you ever been blindsided by your own design? If so, it would be great if you would share your experiences in the comments below.   Aubrey Kagan Engineering Manager Emphatec

In this blog, I thought we should consider things in the context of microprocessors. In almost every piece of electronic equipment we use today, there will be some kind of microprocessor (MPU) or microcontroller (MCU) controlling the operation. Following Moore's Law, microprocessors have doubled in size every second year. When Intel introduced the 4004 microprocessor in 1971, it had about 2,300 transistors. By comparison, the latest Intel 64bit microprocessors contain more than 2.5 billion transistors.   This retrospective blog describes how I became involved in testing microprocessors in 1976, and how microprocessors have influenced my professional work for many years. Testing microprocessors A visit to the Computer History Museum's website will help us get a feeling for the evolution of the microprocessor. After working for a few years maintaining the computer-controlled test equipment at Ericsson, I realised it would be much more fun to program these beasts. I applied for a job with the microcircuit group in Ericsson's component test department. I got the job, and the first thing I had to do was to write a test program for the Motorola 6801 microcomputer. The 6800 was an eight-bit microprocessor designed and manufactured by Motorola. The MC6800 microprocessor was part of the M6800 Microcomputer System, which also included serial and parallel interface ICs, RAM, ROM, and a variety of other support chips. A significant design feature was that the M6800 family of ICs required only a single five-volt power supply at a time when most other microprocessors required three voltages. The M6800 Microcomputer System was announced in March 1974 and was in full production by the end of that year.   The MC6801 was a single-chip microcomputer based on a 6800 CPU with 128B of RAM, a 2KB ROM, a 16bit timer, 31 programmable parallel I/O lines, and a serial port. It could also use the I/O lines as data and address buses to connect to standard M6800 peripherals. The 6801 would execute 6800 code, but it had 10 additional instructions, and the execution time of key instructions was reduced. The two eight-bit accumulators could act as a single 16bit accumulator for double-precision addition, subtraction, and multiplication. This device was initially designed for automotive use, with General Motors as the lead customer. The first application was a trip computer for the 1978 Cadillac Seville. This 35,000 transistor chip was too expensive for wide-scale adoption in automobiles, which resulted in the creation of a reduced-function MC6805 single-chip microcomputer. Writing test programs for the Tektronix S-3260 test system It was not easy to write a test program that would fully test the MC6801 microcomputer's functionality. Up to that time (1976), we had been writing test programs only for simple TTL devices in the 74 series. Our tester could store 1,024 test vectors, which was sufficient for testing simple counters and adders, but we knew that we would need much more memory for testing a microprocessor. Also, I had to come up with a completely new method for testing. The solution was to use the tester memory as program memory connected to the processor bus. We could then compile small assembly programs and let the processor execute these programs and send the results back to the tester. This method was successful, so I wrote a paper which I presented at a Tektronix users meeting in Germany in 1979. Moving to Switzerland Two of my favourite winter activities are skiing and skating. The mountains in Sweden cannot compare to the Alps, so I found myself traveling to Austria and Switzerland every winter for one week's skiing. That was all I could afford at the time, but I always dreamed about skiing a whole winter in the Alps. That's why I started thinking about moving to Switzerland. At the users meeting in Germany, I had met a guy working for a Swiss company (Landis Gyr) in Zug. It had the same kind of Tektronix test equipment, and it used Motorola microprocessors. The company needed someone that could help them write test programs and I was hired. In October 1979, I packed my things and moved to Switzerland.   The photo above was taken in Zermatt in 1981 and shows me in front of the famous Matterhorn. (You will note that, unlike in the pictures with my previous blogs, there are no bell bottom trousers to be seen.) Testing the Motorola MC68000 My first task at Landis Gyr was to write a test program for the 16bit Motorola MC68000 microprocessor. This was a huge device that was presented in a 64-pin dual-in-line package. This was before the introduction of surface mount devices (which would be used in later versions).   The 68000 grew out of the Motorola Advanced Computer System on Silicon (MACSS) project, which was begun in 1976 to develop an entirely new architecture without backward compatibility. This was to be a higher-power sibling complementing the eight-bit 6800 line, rather than a backward-compatible successor. In the end, the 68000 did retain a bus protocol compatibility mode for 6800 peripheral devices, and a version with an eight-bit data bus was produced. However, the designers mainly focused on the future, or forward compatibility, which gave the M68K platform a head start against later 32bit instruction set architectures. For instance, the CPU registers were 32 bits wide, though few self-contained structures in the processor itself operated on 32 bits at a time. The MACSS team drew heavily on the influence of minicomputer processor designs, such as the PDP-11 and VAX systems, which were similarly micro-coded. I used the same approach for writing the test program for the 68000 as I used for the 6801, and I came up with a similar test setup. This time I added an external memory in which I could store the program code executed by the microprocessor. To generate the test program ('programme' for plan), I had to write a cross assembler for the 68000. Yes, at that time you could still write your own cross assembler, but I don't think you would do this today. The test program development was described in a document I presented at a Tektronix users meeting in Philadelphia in 1984. Here's a hand-drawn block diagram showing the test setup.   Moving back to Sweden After a few years in Switzerland, I came to realise that skiing was not the only thing in life, and that I missed the long summer days in Sweden. I moved back to Sweden, returned to my old job at Ericsson, and continued to write test programs for more and more complex devices. In the mid-1980s, I came in contact with a new device called an application-specific integrated circuit (ASIC). The design department at Ericsson had just designed its first ASICs, and it was our job to test them.   I summarise my time as a component test engineer with the illustration above. After 15 years of testing components, it was time to move on to new challenges. Though I didn't know it at the time, I was soon to become an ASIC designer myself, and this will be the subject of a future retrospective. Sven Andersson is an independent ASIC/FPGA design consultant.  

According to the Phrase Finder , the concept of tickling pink is of enjoyment great enough to make the recipient glow with pleasure, which pretty much describes my current state of being. I just received the most amazing email... but before we go there, in order to set the scene, I need to explain that a couple of years ago my chum Alvin and I wrote a book called How Computers Do Math . (May I be so bold as to note that this little rascal, which has 4.9 stars out of 5.0 on Amazon, would make an ideal gift for anyone who wants to know more about how computers perform their magic.) Accompanying the book is a virtual 8bit microprocessor. The interface to this virtual machine is a calculator front panel as illustrated below (the reason some of the buttons are blank is that you can configure them to have whatever annotations you wish).   When you first power-up this little scamp, whose official name is the DIY Calculator (DIY stands for "Do-It-Yourself") nothing happens... The idea is that the book guides the reader via a suite of step-by-step labs to create a program in assembly language that makes our virtual microprocessor and calculator front panel function as a simple four-function calculator. But the possibilities are limitless – someone has already created a BASIC interpreter (in our assembly language, of course), and I have plans to create a simple C Compiler (again in our assembly language)... one day. OK, one more thing before we proceed to the reason for this column is that – as part of the DIY Calculator project – we also created something called The Official DIY Calculator Data Book (you can access both the DIY Calculator software and this Data Book for FREE from the Downloads page of our www.DIYCalculator.com website). This data book was modeled on the old microprocessor data books of the late 1970s. It basically tells you everything you need to know to build your own 8bit microprocessor from the ground up. All of which leads us to the following message, which I just received from John R. Wind: Hello Mr. Maxfield. If you don't mind, I thought I would tell you about a project of mine that implements your "DIY Calculator" in a digital logic simulation program called Logisim (Website – http://ozark.hendrix.edu/~burch/logisim/ ). I am an Electrical Engineer from Grand Rapids, Michigan, and I found Logisim on the internet one night. It is a nice little cross-platform program that I can carry about on a thumb drive and work on projects when I am bored. Now all I needed was a project. There are many digital devices built into Logisim, but one thing lacking was a CPU. After searching around for a premade CPU, I found that a lot of college-level computer classes ask students build a CPU in Logisim as classwork. So I thought that sounded like fun. In looking for information about CPU design, I came across your "DIY Calculator" website. The descriptions in the "Official DIY Calculator Data Book" were just what I needed to get started. Much of the design is a straight forward implementation of your descriptions. Coming up with the Instruction Decoding and Sequencing control logic myself was enough of a challenge to make it interesting. Logisim is very hierarchical and lets you define sub-circuits that you can assemble to make larger constructs. This feature was used to greatly help in organizing the design. Now that I have your virtual CPU built out of digital logic components, I can use it as a sub-circuit to build larger projects with. As an example, I have built a keypad and display that faithfully emulate your "DIY Calculator" and are connected to your virtual CPU along with some memory in the RAM and ROM configuration described in your book. This setup is serving as my "test bed" because it is 100% compatible with all of the programs from your book "How Computers Do Math". Currently, I am trying them out to see if any glaring bugs in my design pop up. Depending upon the computer running Logisim, the virtual CPU is no speed demon. The fun for me is in getting the assembly code to work, not in using the result.   The DIY Calculator running in Logisim   Logisim is very graphically oriented, and it is very educational to look into the design of the CPU and watch how the program is being executed as you step through it. When satisfied, I intend to make my design available to others on the Internet. I thought you might appreciate this because, in a sense, you have provided all of the documentation. If asked for information on the little CPU, I will just refer others to your book. :-) This was all just a warm up. Back when I was a high school student, I built a microcomputer out of a kit that used the RCA 1802 Cosmac Elf microprocessor. I think next that I may relive my youth by designing an 1802 CPU in Logisim and re-building (in a virtual fashion) the microcomputer I once had. There is something satisfying about going myself one better by having to build the CPU itself first. Cheers, John R. Wind PS Just FYI, the display in the image above is saying "Hello World" because it is running that program from your book :-) Wow! Color me impressed. I immediately emailed John back and we bounced a few messages back and forth. John very kindly provided a copy of the Logisim version of the DIY Calculator for anyone to play with if they want ( Click Here to download it in the form of a ZIP file – of course you will also need to download Logisim itself from the website noted in John's message). But wait, there's more, because John kindly said I could share his email ( jrwind@comcast.net ) so that anyone who does play with his Logisim version of the DIY Calculator can contact him with comments and suggestions. The end result is that, as I noted in the title of this column, I am "Tickled Pink". I cannot even begin to describe the countless hours I spent creating the diagrams and text in How Computers Do Math and in The Official DIY Calculator Data Book , so knowing that someone has used this work to the level that John has it very, very gratifying. I think I will have a warm glow for a long time to come...  

Debugging involved loading the tape of the object code and then using the monitor to run or step through the program. At least it allowed breakpoints and even a one line assembler. Some of the more sophisticated monitors allowed addressing by name rather than absolute address, but I can't recall how this one worked. Once again, corrections in the short term were implemented using patches so as to avoid having to re-assemble. The same techniques of GOTOs and leaving gaps between subroutines applied here. Once the development was over, the object code was loaded into a PROM programmer and then the EPROM was inserted in to the target hardware. Next was the eternal challenge – how do you know that the system is working or – more importantly – why it is not working? Some people wrote their own monitors to address this, but I quickly became a confirmed believer in In-Circuit Emulators. As you can imagine some of these tapes were quite long. It was possible to get the tape in fan-fold format, but I never manage to find a supplier. Organising the length of paper tape could be quite a challenge. They could form a roll 5" or 6" in diameter. Reading them would result in many feet of tape spewed out over the floor. Rewinding them was not only tedious but could also lead to damage of the tape. My solution (although not my original idea) was to wind them on to a plastic bobbin derived from a sewing cotton reel. My mom was a sewer and there were many "empties". I see they are still available. I would cut a slot and feed the tape into it. Then I had to find a method to wind it on. I acquired a manual grinding wheel (see photo below), removed the grindstone, and wound tape around the shaft to increase the diameter. I then wedged the bobbin onto the shaft and although it was a two handed operation, rolling the tape became a breeze.   My grinding wheel was very useful for winding paper tapes   Most of the CP/M computers at this time (around 1979) were designed to work with a teletype input, which quickly morphed into "glass teletypes" as dumb terminals were called. In the middle of our desktop computer development, Lear Siegler (one of the glass teletype manufacturers) brought out a desktop system that was a clone of the DEC (the largest minicomputer manufacturer of the day) PDP12. We figured there was no way we could compete and so I was left rudderless. It did not matter that DEC successfully sued Lear Siegler and their product never made it to market. I found my way into some industrial design and decided to revert to Intel, largely because of the quality of the support, both hardware and personnel, of their distributor in South Africa. I broke down and financed an Intel MDS236 development system with ICE for the 8085 and 8048 families. The equipment cost more than my house! The paper tape approach had been replaced by 3 8" floppy drives- 1 single density (720KB) and 2 double density drives (1.2KB). I also had a high level language: PL/M. It was now possible to develop software in modules and use libraries. Although the processes were similar (three-pass assembly), they were transparent to the user and there was mostly enough disc space to do this, although sometimes you had to shuffle floppies. It mainly supported Intel products, although there was a plug in ICE for a Z80 (see photo below).   I got a project designing a calorimeter and, for cost reasons, the customer opted for an 8080. I could produce my code on the development system since 8080 and 8085 code was identical, but I could not debug since I did not have (and couldn't afford) and new ICE. I managed to get a used Intel development tool called aµScope which was essentially a reduced feature emulator in an attaché case (see photo below). The user interface was a bit clumsy (especially as I never received a user manual), but still usable.   I also acquired an Osborne 1 for the express purpose of producing data manuals (using Wordstar ) so that I would look professional. I also ordered Supercalc , which was my first introduction to the world of spreadsheets. ( Supercalc was for CP/M-based computers; Visicalc was for Apple machines.) The Osborne 1 was a "luggable" computer and had a 5" screen that was like a magnifying glass view of your document. You could see about 24 characters (of an 80 character wide document) and 10 lines at a time. Storage was limited to two 360KB 5¼ inch floppy disks, one of which had the application you were running. Changing floppies was not a simple task of opening the drive latch, removing one, and inserting another disc. On CP/M machines there was some initialisation required every time disc was inserted, all of which further complicated mass storage. We've come a long way! The IBM PC finally became accepted as the industry standard about 1983 (in SA at least) and I started moving towards using it for documentation and PC layout. More than that though, Intel started accepting it as the development base for all their hardware and introduced the ICE5100 emulator for the 8051 hosted on a PC via an RS232 connection. Intel even created emulators to run all the existing software compilers, assemblers, editors under PC-DOS. By 1986 the development approach was not much different to what it is today, with the major exception of the user interface. Unlike the single chip microcomputers that we use today, back then the microprocessor had to connect to RAM, ROM and peripherals externally. That meant there were up to 8 data lines, 16 address lines, and 3 control signals (27 lines) snaking their way around a PCB. The probability for a manufacturing fault increased dramatically and Hewlett Packard believed they had a technique to aid debugging when a product failed test in manufacturing. They created an instrument called a Signature Analyzer (see photo below) to capitalise on the idea. It also provided much amusement when seen by the uninitiated who assumed it applied to one's John Hancock.   In circuits with repetitive waveforms, diagnostic manuals had pictures of the waveforms identified with nodes and the settings that produced these waveforms. Of course microprocessor busses are non-repetitive and it is quite an art to debug them. HP's idea was to provide some "waveform" at each node to prove that the system was working. The concept was to force the micro to run a set of instructions that would repeat a bit pattern through a particular node. This pattern is fed into a shift register (in the Signature Analyzer) with some feedback loops similar to CRC calculation to generate a 16 bit signature that is displayed as a 4-digit hexadecimal word on the instrument. That could only be done when the basic system was working. To start up there had to be some method of opening the data bus and forcing the micro to execute a single instruction over and over to allow the exercise of the address bus and ROM read signal. This was fairly easy in Intel processors because the NOP instruction was 00hex and so all that was needed was an 8 way DIP switch to open the bus and 8 diodes connected in a common cathode arrangement with a switch to ground. You could then establish a signature on each address line and EPROM data output, and slowly enable the memories etc. from there.