System-on-a-chip: Scott Eisenhart
Waging war in the Windy City

A full-blown system-on-a-chip (SOC) design-one that integrates a digital signal processor core with a processor with memory and custom logic-is an effort that perhaps can best be compared not with a mere battle, but a full-blown campaign.

Listening to Scott Eisenhart talk about an SOC design implemented by Texas Instruments Inc. and a major customer in the telecom-switch industry, a 10-month-long effort that he co-managed in Chicago, there is no mention of war or soldierly camaraderie. But the melding of individual egos into a group with a single objective-survival and closure-brings to mind the soldierly comparison. Little blood, perhaps, but plenty of sweat and tears.

Eisenhart came to the SOC project in Chicago after graduating from the school of DSP hard knocks in another middle-American industrial city, Detroit. After studying control theory during his undergraduate days at the University of Tennessee (his father, a Hewlett-Packard computer salesman, took Scott hopscotching around the world), Eisenhart figured out that the algorithms he had worked with during college fit nicely with the emerging field of DSPs.

TI hired Eisenhart, trained him in Houston in 1987 and sent him to Detroit for what turned out to be a five-and-a-half-year stint. General Motors was working on active suspension at its technical center in Warren, Mich., back in 1987. TI engineers worked with GM people to apply a 320C17 DSP to an active suspension, a shock absorber with a variable orifice, where the rate of change in the suspension would affect the fluid flow in the shock. The need for "hard" real-time control was a challenge for the DSP and MCU solutions that General Motors, Chrysler and others were attempting to apply to anti-lock brakes, active suspension and exotic technologies such as night-vision radar.

Eisenhart also went out to recruit engineers and evangelize DSP technology at engineering schools in the region, such as Oakland University (Rochester, Mich.), the General Motors Institute and the University of Michigan at Dearborn. That effort was during the infancy stage of TI's university program, which was then modeled in part on Intel Corp.'s successful effort at getting students to use Intel MCUs during their formative years.

That outreach effort continued after TI sent Eisenhart to Chicago, where Tellabs, Lucent Technologies and others were starting to use TI's most powerful DSPs in the central-office switches developed in the Windy City area. Moving from DSP-centered work, Eisenhart was put in charge of an ASIC design center where TI engineers were learning how to integrate DSPs into TI's ASIC library and process backplane.

His three years in Chicago culminated in a 10-month system-on-a-chip effort, during which Texas Instruments and a major customer (which Eisenhart was reluctant to identify) worked to bring together an ARM processor core, a DSP, a significant amount of SRAM memory and nine peripheral modules. Four of those modules were designed by the customer and five by TI engineers, some of whom worked in Dallas. A special package was also required.

Eisenhart was in charge of the TI portion of a joint engineering team-five ASIC engineers and two software engineers-that was charged with putting those modules together and making sure the hardware and software worked.

'Shared risk'
"I would say the risk was shared equally. In our case, this project took a significant portion of our local resources [in Chicago] for 10 months. At the peak, we brought in a number of other software application engineers. We relied on the customer, even though there were changes at the upper-level management structure of the customer during the project," Eisenhart pointed out.

Two major challenges-one technical in nature, involving a breakdown in the simulation of the design, the other a team-building challenge-stand out in Eisenhart's mind.

"Each person had different skills and plugged those skills into the project, stepping into their role and applying their unique expertise. ASIC engineers are more hardware guys and the first month was the most difficult period because the software guys and the hardware guys had very different ways of looking at the project.

"And then there were details about the project. People were looking at the customer and the customer was not sure exactly what levels of information [it] could share with us; there were details that the customer was not providing to us. There were issues about the data rates . . . some very fundamental design issues. So there was a lot of frustration at the beginning and we were not coming to a solution."

On TI's side, there was an experienced engineer, a veteran employee of TI, who took very different approaches to the problems than another engineer, relatively new to TI, who possessed a great deal of experience in system integration. Both were critical to the success of the project and Eisenhart said he had to work hard to make sure that the two engineers came to a meeting of the minds.

"There were a lot of issues, about trust, about how we spoke to each other, which in some cases required me to become a technical arbitrator. One engineer was an excellent leader who was struggling to find a new role. Both engineers were critical, absolutely essential, to the success of the project. We could not have succeeded if either of them had not participated and I honestly can say that they did learn to trust, that their strengths and weaknesses meshed together quite well."

At one point, Eisenhart went to the white board, wrote down five options that the TI team needed to decide upon and started the group on a week-long search for what TI would recommend to the customer. "We wanted to prove that our knowledge and expertise were such that we could show the customer what the tradeoffs were. At one point I just had to make some choices and say, 'Trust me, guys, this is going to work.' That week of preparation was probably the most stressful week of the project, but it taught me something, a lot, about working [with] other people."

Revision control
The project required a verification environment where the customer's encrypted RTL could run in conjunction with simulations of TI's modules, and vice versa. The simulation environment, test benches, the transacter and report tools, all were built from the ground up. An important aspect of the project, since two teams were working on a single design, was revision control. The group used a Cadence tool, Team Design Manager, and the Unix revision control utility, RCS.

"To make a long story short, when we would fix a bug, it would break something that the customer had done. We were not as disciplined about revision control as we needed to be. We totally crashed the top-level simulator and for an entire week neither team could do any top-level simulations. What we found was that we had merged two different versions of our test benches, which made the whole system unstable. It took a lot of time to find that one."

The group had established a common way to write scripts with the Cadence tool to control revisions, but those steps were not followed with the test benches. "We didn't manage that part as well as we did the creation of the RTL itself. It was just design-team management. A fix was made at the top level while one of our lead engineers was on vacation and we made a lot of progress finding the bug when he returned. But in between it was very frustrating for everybody. The pressure of losing a week in the schedule was intense."

The lesson learned: Have a backup person prepared so that there are no single points of failure.

After the Chicago project, Eisenhart was promoted, put in charge of a design-for-reuse initiative at TI.

Return to: TimesPeople 98