cover story

Codesigning a Complex System on a Chip with Behavioral Models Simultaneous development of hardware and software required cooperation among the system house's hardware and software engineers, the CAE vendors, and the foundry. by Bob Cassagnol, Sandra Weber, Dave Kloper, Sonjai Gupta, Brandon Bautz, and Effat J-Ahmadi

Like many developers of embedded systems, we at Hughes Network Systems faced tremendous challenges when we set out to develop our latest satellite broadcast system. DirecPC GenII, as it's called, was to be realized in a highly complex system on a chip with an embedded MIPS processor and specialized functions that don't lend themselves well to embedding (see Figure 1).

In our traditional methodology, software was developed after hardware prototypes had been created. That approach was inadequate here because the system firmware for the complex SOC had to be verified before the silicon could be finished. Exceedingly long run times meant that conventional HDL simulation wouldn't be practical. Furthermore, we knew that the system design would evolve over several generations, so we had to ensure that our methodology would easily provide for such a forward migration.

In fact, we needed a methodology permitting us to develop software and hardware concurrently. Early on, we determined that undertaking the bulk of our design work at the behavioral level would be one way to attain those objectives--despite the time and effort such a course would require. Codesign greatly helped our effort to debug and optimize the system. ASIC hardware and software engineers worked together throughout the process, providing immediate feedback, making real-time updates, and jointly generating sign-off vectors. Early software design information permitted our software engineers to suggest ways of optimizing the ASIC architecture and of adding new instructions for the internally developed controller.

Working out the kinks
Nonetheless, we faced many problems. The hardware behavioral models needed for our control-intensive, real-time application required accuracy at the register transfer level to model the interaction of hardware and software within the system, but no such model for our processor core existed. Furthermore, the technology for codesign and behavioral simulation was limited and unproved. Also, such a change in methodology would force us to develop much of our design infrastructure from scratch.

Surmounting those challenges required a collaborative effort from HNS and our key vendors. To generate and verify an RTL-accurate C model for the processor, EDA vendor CAE Plus, Inc. in Austin, Texas, collaborated with the design center of Toshiba America Electronic Components, Inc. in Boston and with Toshiba Corp.'s Semiconductor System Engineering Center, the foundry in Kawasaki, Japan, offering the MIPS processor of choice. Working with CAE Plus and Green Hills Software, Inc. in Santa Barbara, Calif., to create a concurrent design environment, we at HNS then stitched the model together with our system software and components. The project succeeded not only because hardware and software were developed in tandem but also because of the behavioral-level design environment; the speed and accuracy of behavioral simulation; and the multilateral collaboration among CAE Plus, Green Hills Software, HNS, and Toshiba.

Figure 1	DirecPC system on silicon
DirecPC, a complex system on a chip, contains a MIPS processor core, multiple buses and clocks, firmware, and specialized functions that have traditionally been hard to embed.

Our decision to adopt a new methodology wasn't taken lightly. The traditional hardware-based development flow, in which hardware prototypes designed with FPGAs or hardware emulators are used to develop software, is proved and accurate. Yet that approach presented a number of difficulties. FPGAs couldn't be used to implement all of our system functions. Moreover, if software is developed only after the hardware prototype becomes available, it takes too much time and money to respin the system and optimize the software and hardware implementation. The high cost of emulation seats also makes it impractical to involve the desired number of engineers and to use engineering talent in remote locations.

What's more, the hardware-based approach makes analysis and debugging suboptimal. An inherently dynamic emulation environment limits the developers' ability to freeze clocks and to use other analytical techniques that help validate and optimize the system's performance. Debugging hardware prototypes is also a challenge because it's difficult to access all signals. And the larger and more complex the design becomes, the more evident and serious are the failings of hardware-based techniques.

A hardware/software codesign methodology was the answer. System hardware and software are developed concurrently--thanks to the use of software models synthesized from behavioral-level input rather than prototype hardware. Presilicon verification permits the developers to make trade-offs between hardware and software and to optimize the system rapidly and cheaply.

The number of design errors falls because exhaustive debugging makes it possible to identify them earlier than would be possible with the old development process, for all signals can be accessed. Raising the design domain from the RT to the behavioral level makes model generation more productive. All designers can have a dedicated set of development tools. Finally, building the models in C and using cycle-based simulation significantly accelerates the simulation's execution. The primary drawback of the behavioral codesign methodology is its novelty and, to that extent, its riskiness.

Making the rubber meet the road
Having considered a variety of approaches and decided on a concurrent development methodology, we knew that behavioral models for our circuit components weren't available. Nor did any turnkey codesign environment meet our specific needs. A multilateral effort among HNS, our EDA providers, and our silicon vendor was required to make the rubber meet the road (see Figure 2).

After we selected a Toshiba MIPS processor for our system, that company set out to develop and verify an RTL-accurate C model of the processor. It provided specifications and manufacturing test vectors to our high-level modeling and verification vendor, CAE Plus, which used its automated model development tool, Archgen, to create the model. Toshiba then verified it by comparing the results of the Verilog RTL simulation with those of the RTL-accurate C behavioral model from CAE Plus. For the simulations, Toshiba used the actual manufacturing test vectors, encompassing some 500 test programs and hundreds of thousands of lines of code. Problems identified during simulation were then fed back to CAE Plus for correction. The result was a model that achieves a cycle accuracy of more than 98 percent.

The HNS team had to create and validate RTL-accurate C models of a specialized controller and other ASIC logic. We automatically generated the models--both RTL-accurate C behavioral models and Verilog RTL models for hardware implementation--internally in the CAE Plus Archgen model development environment. After creating exhaustive vectors to sign off on the RTL code, we used them to make sure that the behavioral model properly represented the desired function. When Toshiba delivered the processor model, we stitched together the models for all components into a complete system.

Our software-based development methodology required us to navigate between event- and cycle-based simulation domains. Because Archgen is a discrete event simulator, it employs a reactive simulation approach in which the simulator waits for events to occur and then responds appropriately. One of Archgen's outputs is a custom C, or RTL-accurate C, simulator: a scheduled version, defining exactly when resources will be used, of the design captured in Archgen. The cycle-based approach is proactive, for the same code is executed every clock cycle and the order in which C functions are called within each cycle is predetermined. The RTL-accurate C behavioral simulation was desirable because it runs significantly faster than does its Verilog RTL counterpart.

In the early stages of the project, we found that the way we modeled a particular function in Archgen affected the way it was translated into RTL-accurate C. In other words, we could have an Archgen model that behaved exactly as desired but then generated RTL-accurate C that behaved very differently. (That outcome wasn't unlike scenarios in which Verilog code that complies behaviorally is interpreted differently by synthesis tools, forcing the developer to go back and modify the RTL.) In the early stages, we dealt with the mismatch by wading through tool-generated C code and correlating it with a data-dependency graph in Archgen. CAE Plus was very responsive to our need to reduce or eliminate the debugging of RTL-accurate C code, so the transition from Archgen to RTL-accurate C became much smoother with each release of the simulator.

To ease the development effort for future product generations, we constructed our models with that evolution in mind. The architecture itself is highly decoupled, which will make it easy to replace specific blocks with improved versions down the road. We also plan to stay with the same family of processor cores for future generations, so we expended extra effort to get the model of the processor core right.

Figure 2	Trilateral system-on-a-chip development
The effort to develop the DirecPC system on a chip actively involved three key parties. Toshiba, the silicon vendor, verified the processor model. CAE Plus, the vendor of the behavioral-level design tool, provided modeling and codesign tools, as well as services to develop the processor model. HNS specified architectural and design requirements and stitched together the final system.

At that stage, HNS had to establish a codesign methodology--an environment that would both handle design at the behavioral level and support Multi, our software debugging tool from Green Hills Software. To achieve the task, we pulled Multi together with ASVP Lab, an embedded-system IC verification tool from CAE Plus. We also defined the application program interface needed to integrate Multi into the ASVP Lab verification environment. CAE Plus then did the work needed to realize the specialized interface with our software development environment.

With the desired interfaces and component models in place, we embarked upon a true codesign effort (see Figure 3), starting the development of the software and the definition of the system architecture concurrently. Much of the system software was developed directly on the model, giving us early, presilicon visibility into chip functionality and minimizing potential software-related problems or delays after final silicon arrived. As mentioned previously, to verify the Verilog code before its release to the ASIC vendor for manufacturing, we used the same test code and functional code that had been developed and run on the model. In fact, matching RTL and behavioral vectors made up part of the device's sign-off criteria.

Figure 3	Codesign environment
In the hardware/software codesign environment, engineers can concurrently observe all aspects of the system's behavior, such as the MIPS processor as it runs code, the status of external and internal memory, and the execution of code on an internal sequencer. A timing diagram displays cycle information.

Generating functionally complete models presented a challenge. Models within the Archgen environment are correct by construction. In contrast, the RTL-accurate C state machine that Archgen generates depends entirely on the input stimulus applied. Once we defined a design in Archgen and matched the behavior of the RTL-accurate C model to that of the Archgen model (based on the input stimulus defined as complete), we integrated the model into a larger model--of the entire chip--that interfaced with the Multi software.

Once the work was finished, new demands on the design's functionality, such as the requirements of the software engineers or interface issues between design modules, exposed the weaknesses of the complete input stimulus. An unknown state would occur in the model, making it useless. We then returned to the Archgen model development environment to come up with an input "vector" to cover the errant state. Good interface definitions were very important to reduce the number of the iterations.

Troubleshooting
Subcycle timing, which typically isn't a concern in writing and simulating RTL code, becomes important with RTL-accurate C behavioral models. At interfaces, the time slice when a source model presents an output during a clock cycle must come before the time slice when the destination model samples its inputs. Such scheduling at the interfaces of RTL-accurate C models can be a perpetual concern. As with the unknown states we encountered, we returned to the model development environment to work through a solution to interface scheduling conflicts.

Our choice of the behavioral-level design domain forced us to delineate hardware engineering responsibilities. Instead of undertaking nothing but behavioral or RTL model development, each or our three hardware engineers developed both behavioral and RTL models for a given functional set. Our objective was to eliminate inefficiencies that emerge when a number of engineers attempt to maintain consistent information between the two domains. As a secondary responsibility, each engineer had to serve as the team's resident specialist in such individual aspects of the design process as test or synthesis. That arrangement permitted us to ensure that we would have the expertise to undertake specific design tasks without placing too much of a burden on the engineers.

Model-based verification had major advantages. The static verification environment permitted us to use such analytical techniques as freezing clocks, which provided much more insight into the behavior and optimization of the circuit than would have been possible in a dynamic emulation environment. We could examine all states and other aspects of the device and check its behavior under varied conditions. In addition, we accessed any and all internal pins needed to debug the system--for a model-based flow, unlike a hardware-based one, doesn't constrain the number of signals that can be accessed.

We also achieved cycle accuracy between behavioral and RTL models and, perhaps most significant, observed a dramatic improvement in simulation run times using the behavioral models. Our RTL-accurate C behavioral simulation rates were on the order of thousands of instructions a second, as opposed to the tens of instructions a minute common for Verilog RTL simulations. That speed-up reduced the time needed to verify the system to less than a day, making it possible to iterate the design more often and to achieve a more optimized implementation.

Our use of behavioral development models also provided a benefit for our customers. In the past, those wishing to develop code before the hardware became available had to either make use of costly hardware emulation or cool their heels until the hardware arrived. But the DirecPC system contains firmware, so third-party developers have no difficulty adding application code to the system. As a result, we can now readily ship a model to our customers, and they can develop their own customer-specific code before the hardware arrives.

Finally, the multilateral cooperation among HNS and our silicon and tool vendors was a key element in our successful effort. We couldn't have developed the Toshiba processor model and the Multi verification system interface that were critical aspects of our design strategy by ourselves. As with most of today's SOC development efforts, the elements needed for the design came together because the vendors made a special effort. At the same time, however, we helped CAE Plus develop and define many aspects of its tools. Its flexibility, cooperative attitude, and responsiveness contributed significantly to the project's success.

Bumps in the road
Despite our overall success with the methodology and its vast superiority to the alternatives, our experience wasn't without problems. ASIC implementation tools and behavioral-level tools weren't tightly linked, so functional changes required us to change both the RTL-accurate C behavioral model and the RTL model manually. Because there were no direct links between the two parallel flows, we had to verify cycle accuracy by manually running exhaustive "golden" functional vectors on the model. As a result, we faced a time-consuming task when vectors didn't match. After the work was completed--and partly because of it--automated links have been incorporated into the behavioral-level tools, reducing the amount of manual intervention required.

Moreover, the development schedules and costs of the project exceeded our original expectations. Although our engineering management strategy was designed chiefly to promote efficiency, the dual responsibility for behavioral and RTL models caused delays in the schedule. Design at either the behavioral or the RT level requires tremendous concentration, and shifting from one domain to the other on demand was difficult. Furthermore, the cost and effort needed to generate and verify the behavioral models were higher than we had at first expected. Finally, adopting the new design methodology forced us to master some 15 different tools to design the ASIC and to develop the model.

We also encountered inefficiencies and inaccuracies stemming from the sign-off vectors (originally designed to validate the processor core in various ASIC applications) that the foundry provided for the processor core model. Since our project was the processor model's maiden voyage, a much more extensive vector set exploring all of the processor's functionality--that is, its ability to execute the MIPS instruction set correctly--would have been desirable.

Down the road
We had those problems mostly because behavioral modeling and codesign technology are still in the relatively early stages of their evolution. The technology used in the development effort will no doubt evolve. More validated behavioral models are being provided off the shelf by silicon and IP vendors, which in turn will reduce delays and costs to their customers. More direct links between behavioral- and RT-level design flows will eliminate time-consuming and error-prone manual translations. Design simulation will take less and less time, thanks to the use of checkpoint mode verification, in which simulations are executed to a point, all states are held and frozen, and subsequent simulations continue from that point.

We hope that our experience will help engender a new culture in the microelectronics industry. Development schedules of 9 to 12 months for design must eventually yield to 4- to 6-month schedules. One key requirement for shortening the development window is faster and more innovative design tools, such as the behavioral-level development ones we used on the project. The other requirement is IP in a form that would permit it to be deployed in SOC design and on silicon more rapidly and easily.

Off-the-shelf, fully verified processor models would have saved us a significant amount of development time. Nonetheless, our experience proves that hardware/software codesign and behavioral-level design are not only possible but also the source of substantial benefits.

The authors are part of Hughes Network Systems' Broadcast Products Division in Gaithersburg, Md.

Bob Cassagnol, principal engineer on the hardware technical staff, is a lead designer for satellite broadcast products; and Dave Kloper, principal engineer on the software technical staff, is a lead software engineer for such products.

Sandra Weber, formerly a member of the technical staff, is enrolled in the ECE master's degree program at Carnegie Mellon University, specializing in CAD.

Brandon Bautz, a member of the technical staff, is a hardware developer. He designed several peripheral circuits, performed test insertion and synthesis, and did several behavioral models using the CAE Plus tool for the DirecPC GenII ASIC.

Sonjai Gupta and Effat J-Ahmadi, also members of the technical staff, are software developers. Gupta is currently working on designing the DSS transport software for a new generation of DSS/DirecPC receivers. J-Ahmadi is participating in ongoing testing of the DirecPC GenII ASIC's secure kernel, executing functional and white-box test suites.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  November 1998