08/11/04
pages 154 - 170
Chuck Holland was Alsing's main assistant. Alsing delegated most of the technical supervision of the Microteam to him. In fact, it seems that Alsing flirted with abandonment, as opposed to delegation, as a management strategy. Holland organized the structure of the microcode and divided up the writing process into tasks that he assigned to the various Microkids. He also wrote large chunks of the microcode himself. He kept the whole Eagle project from falling into chaos by overseeing and mediating the battles between the Microkids and the Hardy Boys about which machine functions would be built as hardware and which would be written in mircrocode.
Although Holland was basically happy in his work, he worried that Alsing and others might take credit for work that he had done.
One of Alsing's most important contributions to the eventual success of the Eagle project was his decision to develop a simulator for Eagle. A simulator is software that runs on one machine to make it act like another machine. In the present instance, Alsing wanted to develop software that would make a 16-bit Eclipse behave like a 32-bit Eagle. Specifically, the simulator would execute the Eagle microcode on an Eclipse. The main advantage was that the Eagle microcode could be tested before the Eagle hardware was completed.
Because the short time schedule for Eagle required that its microcode and hardware be developed in parallel, being able to check the microcode with a simulator was very attractive to Alsing. West, on the other hand, was skeptical. West was certain that the Eagle hardware would be debugged and ready before a simulator could be written. Despite his reservations, he let Alsing try to develop the simulator. Perhaps West had reached sufficient maturity as manager to know that you must trust the judgment of the people to whom you have delegated responsibility for tasks.
Whatever the reasons for his action, West's decision to let Alsing proceed with the simulator proved most fortunate. As it turned out, completion of the Eagle within anything like the desired time would simply have been impossible without the simulator. West simply was wrong.
What had West not foreseen? Two things.
First, West underestimated the complexity of both the hardware and the software for Eagle. In his own mind, he seemed to view the Eagle as an only slightly more complicated version of the Eclipse, a machine with which he was very familiar. West therefore expected the Eagle hardware to be ready long before it actually was.
Second, West (nor almost anyone else) would have believed that Alsing could develop a simulator as fast as he did. Well, of course, Alsing did not develop the simulator personally. He did develop a clever strategy that got the job done in record time, however.
Alsing had two programmers in the group whom he thought might be able to contribute to the development of the simulator. Dave Peck was an experienced programmer with a reputation for being almost unbelievably fast. Peck already had some ideas about what a simulator for Eagle might look like. Neal Firth, on the other hand, was a Microkid fresh out of school, with dual degrees in electrical engineering and computer science, who loved to program.
A straightforward approach would have been to ask Peck and Firth to work together as a team of two to build a simulator. Alsing took a different approach. First, he gave a simple tutorial on simulators to Neal Firth, when Firth first arrived, and asked him how long he thought it might take to write one. Firth knew nothing about simulator development and, in particular, that it normally took a year or so. Consequently, Firth estimated 6 weeks to 2 months for the time to completion. Alsing liked that. Then Alsing talked to Dave Peck. Peck, Alsing said, would lead the two-man effort to develop the simulator. While leading a two-person effort appears to be not much, this approach probably put Peck more in the mood to help Firth.
In addition to his leadership role, Peck was to be responsible for building a "quick and dirty" version of the simulator as quickly as possible while Firth was doing most of the work on the main simulator. Given the shortage of time, this use of Peck and Firth to develop two different simulators seems a little crazy. It worked, however, something like this. Peck sat down with Firth and gave him the benefit of his thoughts and experience for the development of the main simulator. Then Peck whipped out his quick and dirty simulator in the incredible time of only 6 weeks.
The importance of Peck's simulator was not its actual application, however - only a couple of people ever used it. Its importance was that it set the pace for Firth. Firth did not want Peck's quick and dirty simulator to be the main one that the Microkids used just because it was the first one available, so he hurried to complete his simulator, even as he included many additional features, including ones that made it especially easy to use, that Peck's did not. Firth had his simulator working only 10 weeks or so after Peck completed the quick and dirty one - an astounding feat, possible in all likelihood only because Firth did not know how long it was supposed to take to build one.
Firth's simulator soon became the center of the Microkid's lives. Even after the simulator was "completed", Firth worked long and hard to update his simulator to reflect the constant changes to the Eagle design. As a result of Firth's simulator, Microkids were able to begin debugging the microcode for Eagle long before the Eagle hardware had been debugged.
Alsing had been right.
In most technical areas, the availability of simulators has altered engineering practice in a fundamental way. Traditionally, the first step after a project had been designed was to build a model or prototype to see if it worked as expected. If (When) it did not work as expected, the design would be modified and the model or prototype modified to reflect the changes. Iterations of redesign and rebuilding of prototypes continued until the performance of the prototype was satisfactory. Such iterations usually were expensive and time-consuming.
With the availability of simulators, many design iterations can be accomplished quickly and cheaply with the simulators before the first prototype is built. The overall result is a speed-up of the production process and a decrease of the development cost.
In electrical engineering, simulator software was first widely used in the development of integrated circuit (IC) chips. In this particular case, the primary reason for the widespread use of simulators was not to speed up the design iteration process, however. Instead, it was to make the design iteration process possible.
The number of transistors on chips is so large (up to several million) that it is practically impossible to build a prototype circuit from ordinary circuit components that would come even close to mimicking the behavior of an integrated circuit. It is not only the large number of components that is a problem. Even if you went to the extreme trouble of building a prototype circuit, the much larger physical size of ordinary components would mean that the values of stray capacitance and inductance for the prototype circuit are so different from the proposed integrated circuit (IC) that the behavior of the prototype circuit would bear little resemblance to that of the proposed IC.
If building a prototype from discrete components is impractical, the first thought probably is to make a prototype IC. This approach proves impractical mainly because carrying out the process steps necessary to convert a design into a physical chip can take several weeks, much too long for efficient iteration of the design as modifications become necessary to satisfy design constraints. Besides, the manufacture of a prototype IC in this manner would be enormously expensive -- the semiconductor industry achieves low manufacturying cost mainly by making millions of identical ICs simultaneously so that the cost per unit is low.
Simulation software is therefore essential for the economical design and manufacture of integrated circuits. For ICs, therefore, it's this simple: no simulators, no chips.
The situation was not quite that drastic for the Eagle. The absence of the simulator would have entailed considerable delay, but probably would not have precluded the eventual production of the machine. The increase in complexity in moving from 16 bits to 32 bits made a simulator much more useful in the 32-bit environment than West had anticipated, however.
In 1998, Neal Firth provided some throughtful advice to students, as well as answers to questions, based on his career experiences. Today, Neal Firth is President and founder of SageRight, which provides specializes in providing solutions to software development organizations for the management and control of information from development through sales. According to an article entitled O, Engineers! in the December, 2000, issue of Wired, Dave Peck is a consultant in the systems engineering department at Fujitsu Nexion in Acton, Massachusetts, and Chuck Holland is a product evangelist for LiveVault, an Internet backup-services company in Marlborough, Massachusetts.