Gordon Bell, vice president, Engineering
by Richard Seltzer, from DECWORLD the company newspaper, July 1983
Looking ahead -- The excitement has just begun
"I used to consider myself to be a computer architect, working on individual systems. Now I believe I'm more like a city planner. I worry about how the nodes are connected and how information flows between them and how one can build from a collected set of nodes. I think about local area networks and how they are connected to form wide area networks, how technology such as cable TV is used, and how to get the necessary bandwidth and standards, since with distributed computing the need for communication grows exponentially with the number of computers. While we need to build larger, more reliable computer systems, it is becoming possible to it by interconnecting the emerging super-micros rather than continuing to make larger individual machines.
"Economy of scale is disappearing, and it's much cheaper to engineer and manufacture smaller computers to get the best cost-performance. But we need to understand how to use them together in all kinds of structures. For example, the beauty of Ethernet is that anyone can link the computers together, and segments can easily be connected to form a whole at a single site.
"Today we're building more complex systems, but they're built in an orderly way. Today's basic component is a processor -- a whole computer. We have to cover a lot more levels of integration now than we ever did -- from semiconductors to applications.
"As the company's second computer engineer, I didn't have a notion of architecture. When we defined something, it was in one person's head. One engineer designed the circuits, and somebody else designed the logic. There were a few diagnostics and systems programs. The user had to link together various subroutines to perform a unique system -- rather than having an operating system.
"Now today, with integrated circuits, we are at the point where there is more creativity for everybody including the circuit engineer, where the problem is laying out circuits on a chip. Architecture is refined so that a machine has a meaning over seral implementations as we've done in the VAX and PDP-11 families.
"I recently visited a user in Australia who built a totally homogeneous VAX computing environment: with large VAXs in Sydney running central computation centers and distributed 730s in various regional offices. They also had networked control computers doing real-time applications. That whole system ran as a single computing environment, along the lines I had hoped for with the VAX and a homogeneous architecture.
"What we're doing with networks and multiprocessors -- making it possible to run a single problem on many machines -- creates a new domain of architecture, which is more exciting than anything we've had in the past.
"Meanwhile, the exciting applications in areas such as Artificial Intelligence on parallel machines are still ahead of us, and probably won't really get going until the early 1990s, even though there are breakthroughs every day in specific knowledge- and expert-based systems.
"It continues to be clearer and clearer that we are only at the beginning of the computing era."
Lessons from history
Gordon has an ever-expanding set of notes, heuristics and lectures that will eventually become a book on the evolution of computing. He points out problems that could be avoided if engineers would pay closer attention to the lessons of history. "Often a product starts out simple, then becomes elegant (a design is 'elegant' when one part is used for two functions). Then it gets extended to be more general, and finally ends up so general that it's tricky. If it's too simple, it may be naive and useless.
"We also se that ideas tend to go in cycles. For instance, in a process known as the 'wheel of reincarnation,' you first add some simple hardware to a product to do a particular function such as displaying information. Then you put in more special hardware to do the function and to offload the original information processor. Gradually, you add more and more hardware so the function can be done better and without any help from the main processor. Ultimately, you end up with a general purpose processor which does the display function and you've totally unloaded the first processor. So you really end up with two separate computers, neither of which is doing very much, except communicating with the other one. This has happened in graphics, communications, computation and database processors.
"History also helps give us a sense of perspective -- of the importance and potential of the products and ideas we've grown accustomed to working with. Since we're so close to specific products, one of the hardest things to know is when we should stop evolving one and take a new approach. I think history provides good lessons on determining when a product is over-the-hill in terms of extensibility and hence lacks competitiveness. I strongly believe in product euthanasia."
Engineering around the world
In the last few years, Gordon has sponsored engineering groups on the West Coast, Colorado, the U.K. and Japan.
"The West Coast and Japan have significant groups of talented engineers. We want to be able to take advantage of the technology that's in the Silicon Valley and in Palo Alto around Stanford. Also, Japan has superb semiconductor, display, magnetic recording, printing and consumer electronics technology.
The Seattle location has a group of engineers who wanted to relocate from New England. They work together in a small, effective, tight-knit group. Colorado Springs started out the same way. In terms of productivity per person, they're both outstanding.
"In general, I have little faith in large design groups, and virtually no faith in large committees to solve problems," he explains. "Large groups tend to spend a lot of their time talking and politicking with each other rather than using interface specifications and the written word. In contract, one of the most complex interfaces we've developed is the mass storage control protocol that links mass storage devices with VAX systems. That was worked out very precisely between engineers in Colo9rado and VAX/VMS engineers in New England, totally through written specifications, and when it was plugged together it worked.
"The only engineering DEC has in places like Australia and France is done by Computer Special Systems (CSS). These small groups are tightly linked to customer needs. Central Engineering has not yet been able to take advantage of this worldwide engineering talent as CSS has done. I think that's something that I'd like to see us do int he next five years.
"For example, several Australian CSS engineers built a statistical communications multiplexer. We're shipping about 1000 of those per year. That's enough business for a respectable-sized small company, and the project cost less than it costs to write a business plan. That's another reason why we need smaller engineering groups."
using computers for design
The most important recent change in Engineering has been the new emphasis on the use of computers to help design better computers. "The use of computers in computer design really didn't become mandatory until the mid-70s," notes Gordon. "But now we can't do without them for VLSI and large systems design. We use computers to lay out circuits to simulate the operation of circuits, and, finally, to test the actual devices.
"Our increasing use of computers in engineering requires changes in training and changes in behavior. We call this approach the "Quality Design Methodology." It is being used in VLSI, large system development and some of the mid-range systems. Other areas are in the third generation or dark ages and must be retrained along the new lines.
"This discipline is one of the indirect benefits of 'silicon Mountain' (our Hudson, Mass., facility for designing and manufacturing large scale integration -- LSI -- semiconductor circuitry). They are working on vital technology which we're going to need for designing products. Within ten years, some systems we're going to build will be on a single chip, and we must master VLSI. This demanding work requires clear understanding of fundamentals, including materials. It has taught us a great deal about managing complexity (i.e., systems with lots of interconnected parts), and that's something that every engineering group must eventually understand.
"I expect every product breadboard to be so well designed and so well constructed that it will work the first time it is powered up. This means: having a clear organization; understanding the behavior of all supporting processes; specifying the design in more and more detail so that at each stage it has no errors; inspecting the design rigorously; simulating the design and verifying its timing using computer-aided design (CAD) tools; building it and getting ack a breadboard that is virtually perfect because Manufacturing uses a similar methodology; and then finally applying the power and observing that the actual device behaves exactly as the simulated version."
Looking back -- MIT, Australia and the start of a career in engineering
Gordon's first exposure to computers was as an undergraduate at MIT, where he learned programming on the Whirlwind, a computer that Ken Olsen and Dick Best had helped design.
After graduation, he received a Fulbright scholarship and went to the University of New South Wales in Australia. It was a new university with a new British computer called the DEUCE, that Turing helped design. During his year there, he wrote software and helped organize and tech their first graduate course on computer design.
"When I came back to the U.S. in late 1958," explains Gordon, "I had a choice of going to work for Philco on computer design or returning to MIT. I decided on MIT where I could do work that had a very high computing content as opposed to a circuits and logic design orientation.
:My thesis advise, Ken Stevens, who ran (and still runs) the Acoustics and Speech Research Lab at MIT, asked me to work on their new computer, the TX-0 given by Lincoln Laboratory. I interfaced speech input equipment to the TX-0 and wrote analysis and recognition programs (one of which, Analysis by Synthesis, is still a mainstay of recognition programs). We needed secondary memory; so I got a tape deck, interfaced it to the TX-0, and in the process discovered DEC, a new little company that was starting to sell system modules.
"these modules were compatible with the TX-0, because that computer was really the breadboard for the Lincoln Laboratory transistor circuits that Ken Olsen and Dick Best developed, and those circuits were really the breadboard for DEC's first modules. I went to Maynard to buy modules and met Ken, Dick, Harlan Anderson and Ben Gurley.
"Speech understanding and recognition is a classic hundred-year-old problem. It's deceptively simple because humans do it, and humans can also recognize speech represented in two-dimensional images called voice prints. I thought I could write a program to recognize speech. It took me a year to understand that this problem would take 20 years to solve, and I don't like to work on one problem that long. It was really computers that fascinated me.
"Besides, I didn't want to be a researcher; I wanted to be an engineer and build things. DEC looked like exactly the kind of place where I wanted to work. So in 1960 I gave up my doctoral program and came to DEC.
The PDP-6 development team in 1964. Left to right, standing: Peter Samson, programmer; Leo Gussell, diagnostics programmer; Gordon Bell, system architect; Alan Kotok, assistant architect and logic designer; Russ Doane, circuit engineer; Bill Kellicker, technician; Bob Reed, technician; George Vogelsang, draftsman. Seated: Lydia McKalip, secretary; Bill Colburn, technician; Ken Senior, Field Service technician; Ken Fitzgerald, mechanical engineer; Norman Hurst, technical writer; Harris Hyman, programmer.
Early days at DEC
"I was the second computer engineer in the company. Ben Gurley, who headed Computer Engineering, hired me, and Dick Best, who is still our Chief Engineer, was in charge of designing modules. I was hired to do programming, architecture and logic design.
"Tom Hastings was probably DEC's first software engineer. I hired him as a summer student in '61 to work on the PDP-1 program library. (Tom now works in Terminals in the Mill and has made important contributions int he architecture and standards of terminals. He also played a significant role int he PDP-10 and the VAX.)
"DEC got started in the computer business at a time when the industry was shifting form vacuum tube technology (what I call the first generation of computers0 to transistor-based technology (second generation). The PDP-1, introduced in 1960, was one of the first commercial applications of that technology.
"A total of 50 PDP-1s were built. We stopped making that product around 1965. One of the luckiest things that happened was that half of the machines were sold to ITT for message switching. It could handle up to 256 telegraph lines and switch them to other telegraph lines. Working on that project, I developed the device which we now call the UART (Universal Asynchronous Receiver Transmitter), a serial line encoder-decoder.
"We were very lucky in getting the ITT order because that made the PDP-1 a standard product. If that hadn't happened, I don't' think we would have survived int he computer business.
"Every other order for the PDP-1 used a wide variety of custom-designed and custom-built options. Those were the days when you first offered something for sale; and then if someone bought one, you designed it. That's a crude way to do market surveys.
"One of our earliest customers, Lawrence Livermore Radiation Lab, sued their PDP-1 as a converter between the IBM STRETCH and UNIVAC LARC. They ordered a system with virtually every option we could think of (but had not yet designed) including UNIVAC and IBM tapes, a UNIVAC card reader, an IBM card reader and an IBM card punch. They even ordered a five inch scope with 4096 x 4096 resolution that's still unrivaled today in its precision. We were lucky we didn't have more orders for such exotic equipment.
"DEC's goal from the very outset was to build a whole scale of computers -- from small to large. But our approach was rather haphazard -- a far cry from today's methods.
"The PDP-2 was a mythical machine number reserved in case we wanted a 24-bit computer. It was never defined on paper. The PDP-3, a 36-bit computer, was defined; and one of our customers built one using DEC modules. We almost got an order for a PDP-3 from the Air Force Cambridge Research Lab, but Harlan Anderson, DEC's first vice president, and I persuaded them to take two PDP-1s, in other words two 18-bit machines instead of one 36-bit machine.
"The PDP-4 started us in a new line of business for real-time control. It was designed for process control and ease of interfacing for a couple of Foxboro's customers. Because we didn't understand the cost or value of software, it turned out to be a business mistake. But, fortunately, it led to the PDP-5, which in turn led to the PDP-6 and the start of the minicomputer industry.
:One of the first few customers that bought the PDP-4 was the Canadian Atomic Energy commission at Chalk River. They wanted to control a nuclear reactor and needed a machine to do front end work for reactor monitoring. We visited them to consider the monitoring requirements. We were thinking of it as a special system. But in looking at it, we came upon the idea of the PDP-5 -- a computer designed to do process monitoring and recording and to work with the PDP-4.
"I think everybody who builds specialized digital systems discovers that the best digital controller is a computer. So no matter what we start out to build, we always end up with a computer. I continue to see engineers, companies and industries stumble onto this -- most recently in the form of microcomputers.
"Some people call the PDP-5 the first minicomputer, but I don't think of it that way, even though it was built to be embedded in a larger system.
"I believe the PDP-8 is the first real mini. It was half the cost of the nearest competitor. It was also a lot easier to interface, much faster and far smaller than the PDP-5. It took less than half a 19" rack, so you could embed it in any system. In other words, the computer was clearly a component.
"I like to think that minicomputer stands for 'minimal' computer -- that is the smallest computer you can make at a given time for the lowest price: something you use to substitute for other digital systems. I think that micros are really mini(mal) computers.
"The whole notion of personal computing is something that DEC pioneered. Personal computing to me means having a screen, very good interaction and a filing system so that the machine takes care of the bookkeeping of programs and data. It was a tradition that we all learned about at MIT. The TX-0 had interactive use that included a cathode ray tube (CRT) and typewriter. It turned out that other computers had typewriters, but they didn't have a CRT and usually didn't have a good file system. That's why I think that the first real personal computer was the LINC, designed by Wes Clark and Charlie Molnar at Lincoln Laboratory. It's no in the Computer Museum.
"Designed with DEC modules, the LINC had its own file system called "LINCTAPE." Ultimately Digital manufactured it. "When the designer of the file system, Tom Stockebrand, came to Digital from Lincoln Laboratory, LINCTAPE evolved into DECTAPE, and people were able to have personal filing systems, write and program directly on the CRT, compile and then execute them without having to go through a central data processing facility. Also it could be moved from lab to lab. No other system offered this capability until we started timesharing systems.
"Minis and micros are one kind of personal computer that we pioneered. Timesharing is another. By timeslicing a computer among many users,. we provided each user with what appeared to be his or her own large computer. This concept was implemented in three different places at the same time. Bolt Beranek and Newman (BBN), a management consulting firm in Cambridge, Mass., one of the earliest customers for the PDP=1, ordered two typewriters with their first system and did some of the first work on timesharing. Meanwhile, MIT was using several typewriters on a single computer, and Systems Development Corporation built a timesharing system on a large military computer.
"It was from these ideas that we created the PDP-6, the forerunner of the DECsystem-10 which was built from scratch to be timeshared so that everybody could have their own large computer for personal computing.
Gordon Bell (left) and Alan Kotok (right) working on the PDP-6, circa 1964.
Time off for research, then back to DEC
"In 1966 I went to teach, learn, write and do research at Carnegie-Mellon University, still staying in close touch with DEC as a consultant and a customer. While there, I consulted on development of what became the PDP-11 family of computers.
"The main reason that I went to Carnegie was to get time to think about computers. In retrospect, the leave was perfectly timed. I left a the beginning of the third generation of computing, when integrated circuits were coming in and every garage and store front was being converted into a minicomputer company building. At that time, the main issue at DEC was switching from discrete circuits designed and built in-house to circuits that semiconductor companies built. Aside from their smaller size, there wasn't much difference in working with these new circuits. The transition took about six years -- the time I was at Carnegie.
"In 1972, I was going to take a sabbatical and write another book, the 'ultimate' one on designing digital computers. But Ken Olsen asked me to come back and be vice president of Engineering.
"I returned to DEC for several reasons. Large scale integrated circuits had just become available, and the notion of a processor on a chip was beginning to appear. That was the start of the fourth generation of computers. I had done a lot of work at Carnegie based on the belief that processors and logic were going to become very cheap. All the multi-processor and multi-computer work at Carnegie was predicated on this. I came back to get DEC interested in LSI and ready to start projects based on it.
:I also wanted to work on what amounted to VAX. At that time it was clear the PDP-11 wasn't big enough. We had to do something else, and I was interested in that next step.
:?but probably the most important reason was that I had spent a lot of time trying to understand computing as a computer scientist, and I really wanted to be directly involved in building machines as an engineer.
"In 1972 there was no such ting as Central Engineering. There's always been a central core of engineering people. But back then, they were distributed in various groups called 'product lines,' that had both marketing and engineering functions and operated in a profit and lo9ss framework.
"In 1974, we brought most of engineering together as a single group. From the beginning, we said that Central Engineering would concentrate on basic rather than market-specific products. The product lines retained small engineering groups dedicated to tailoring these basic products to meet the needs of their particular markets.
:We soon got projects going in the LSI area, especially the LSI-11 with Western Digital. VAX-11 came later. That's the name I used beginning in April 1, 1975 in the task force to extend the addressing of the PD-11. It originally stood for 'Virtual Address Extension-11' a reminder that we were extending the 11, not starting over. That's a case where the name stuck throughout the project's life and has become one of our major trademarks. The press discovered it prior to announcement. So, when the time came to settle on a public name for it, we stayed with it, because we had already had more press exposure than if we had planned a campaign.
"Today, Engineering is more aligned with
Manufacturing and has the marketing functions for the basic
products it builds. Every product has a business plan which it is
measured against, and the engineer who plans or proposes a product
is responsible for doing it. The express 'he who proposes does'
reflects this notion that planners and proposers aren't distinct
from implementors. Today Engineering has more responsibility than
it has even had because it is solely the project team that I hold
responsible for a product."