Unifying HW/SW Co-Design Teams

Electronic News, Jan 17, 2000 by Mark Miller

What end products will we see on the other side of the millennium? A toy store of high-complexity, high-value, low-cost electronic systems, each built on a dauntingly complex, semiconductor-based design that would be useless without an RTOS, embedded software application, or firmware. Each represents the integration of subprojects that individually would previously have been considered major accomplishments.

Managing this integration process can be a nightmare of cross-disciplinary interdependencies -- but it doesn't have to be. Let's consider the process. Design teams are now challenged to build products in less time than ever before. With the global shortage of engineering talent, a project will likely span multiple sites and/or outside design consulting resources. If you are the project manager for a telecommunications or networking design team, you will probably have to integrate not only many locations but also four distinct design activities. Let's consider the process:

Integrating and qualifying digital signal processor (DSP) and RISC cores.

Your design might contain an externally supplied RISC core and an internally developed reusable DSP core. The RISC core may arrive as a single target file that, once expanded, will consist of a 20,000- to 50,000-gate design delivered as approximately 250 files, in a variety of file types. These will have to be unpacked, checked for completeness, verified for reproducibility, and set up for internal use and distribution. Each requested modification will likely require a repeat of the process. Assume that integrating the DSP core will be similarly complex.

Developing project-specific hardware.

This might consist of 500,000 to 1,000,000 gates, including memory, represented as around 10,000 files that define over 400Mbytes of design data. Blocks may include digital logic, RF, analog, and mixed signal content, managed through the design flow using 25 to 50 electronic design automation tools that span over 25 iterations from RTL through tape-out in GDSII.

Developing the firmware, RTOS, or embedded software application.

This can necessitate a development environment from an external supplier, which will be used to create up to one million lines of code, including base libraries for the RTOS, drivers, and stacks. Typically 50 percent to 60 percent of this code will have to be created or modified.

Implementing an integration platform/co-simulation environment.

The goal is to support software development, prior to the availability of the final hardware, through cross-domain co-simulation and test of the software components, when run on the architecture of the yet-to-be-implemented hardware. This can consist of an evaluation board from your RISC/DSP core provider used as part of a "reference platform" upon which the application or RTOS code is compiled and tested.

As the project manager, you can simplify the process and expose critical issues while you still have time to deal with them.

Enable cross-team collaboration.

A single, Web-accessible, secure configuration- and release-management system that allows all teams to see the revision level, state, level of completion, and outstanding issues related to each subproject could eliminate working at cross-purposes. For example, it's imperative that the internal hardware development team not waste cycles simulating its design against a RISC/DSP core release that is known to contain bugs. Sounds obvious, but it happens all the time.

If this system supported user access rights, your team members could access the design data they needed, but not inadvertently change things they shouldn't.

It would be ideal to expand this infrastructure to include the delivery of cores -- the more the supplier looked to your internal design teams like a branch of your development organization, the better.

Adopt a secure, Web-based tracking system that supported triggers and subscription to state changes, to facilitate early visibility of critical bugs, ECOs, release availability, and applications notes for cross-discipline dependencies.

The trigger and subscription features would be key. If you knew that the regression test for your block had to simulate with the cache controller block which, at that moment, contained a "killer" bug, you wouldn't waste your time simulating against it -- until you were automatically notified that the bug was fixed.

Implement a Web-based mechanism that let all members see the state of each subproject, supporting effective management decisions and resource allocation.

If your teams successfully implemented the first two strategies, the manager's decision-support information portal would now be within reach. In the past, you depended on information collected from team leaders. Now you could develop your own profile of the state of the whole project.

Mark Miller is vice president of marketing and business development at Synchronicity in Marlboro, Mass. He was recently named chairman of RAPID (Reusable Application-Specific Intellectual Property Developers), an association of third-party suppliers of IP.