It takes many heads to design a product

The number of complex designs that require more than one engineer for successful completion is growing every day. More than half of all designs-whether they result in pc boards, FPGAs, or ICs-need a number of engineers working together to meet the products' requirements and ever-shortening development schedules. When deciding to implement a new product, companies face technical, financial, and logistical challenges. The fierce competition in the electronics industry demands that a company must develop complex products in the most cost-effective manner. Frequently, this situation means using resources in different parts of the world, various skills, and different development methods.
Although designers often use the number of logic gates in a design as an indication of complexity, this method gives a clear measure only when the design is a purely digital logic design. Most designs today include both analog and digital blocks, and many have both hardware and software blocks. Frequently, the size of a digital design makes it is impossible for one engineer to complete it in the required time. When a design requires multiple disciplines, a team of designers is a necessity. Analog designers have different skills and use different EDA tools from those of digital designers. Software developers lack the knowledge to efficiently design hardware. Companies, therefore, must find a way to manage the development of complex systems. In some areas, it is becoming common for a number of companies to collaborate on a single design. For example, in FPGA or ASIC development, system houses, IP (intellectual-property) providers, foundries, library providers, and other consulting organizations must collaborate to ensure success. John Ford, vice president of marketing at Virtual Silicon (www.virtual-silicon.com), observes that the design flow is the most important asset of a system house. The system to support product development must span all of the phases: requirements definition, product architecture, development, debugging, integration, verification, manufacturing, and revision control.

The dimensions of complexity
The complexity of a development project manifests itself in a number of ways. The size of the design directly contributes to its complexity. The normal method for reducing complexity is to subdivide the design into a number of components, each with a unique functional characteristic. The advantage is that you can, using a recursive method, generate functional blocks that are small enough that one designer can efficiently implement them. If there are more blocks than there are available engineers, some, or maybe all, of the engineers will be responsible for more than one block. Given a block of manageable size, an engineer can meet both its requirements and the development schedule. The hidden danger in dividing the design is that, when you work on a block, you can lose track of the entire design, or as the proverb goes, you 'can't see the forest for the trees.' You concentrate so much on your task that you lose track of the big picture: the goal of the entire design. By overoptimizing your piece, you might complicate the design or even contribute to missing one of the design requirements. Each designer must be able to visualize the entire design, see the relationship of his or her work to the total product, evaluate the impact of design decisions on the functional blocks directly connected to his or her block, and adjust to design decisions by colleagues working on different blocks of the system.

People tend to resolve complexity by dividing problems into more manageable sizes. You could debate that this assertion also describes the state of our education system, which produces specialists on the theory that an individual who knows a lot about a little is better than one that knows a little about a lot. Analog designers learn different skills from logic designers, for example. An engineer skilled in DSP design can have difficulty fully understanding the issues that a wireless-communication-system engineer faces. Each engineer is concerned with a different set of problems, although both design hardware. Software developers follow a vastly different methodology from that of hardware design. They have different requirements when debugging their designs. Hardware engineers deal with physical characteristics and observe the design in terms of time or frequency. Software developers look at the state of the system and its functions. When a problem occurs, people with different backgrounds and views must be able to communicate to develop a solution. The team needs organization and an established communication protocol, or its members may end up like laborers on the Tower of Babel.

Another way to manage complexity is by reusing functional blocks. This practice has given rise to a new industry, providing reusable functional blocks either within a company or on the open market. As with all new industries that are based on rapid advancement, this industry lacks standards. A vital new market for virtual components or IP blocks, has attracted small companies that have the technical skill to produce the blocks but lack the marketing skills to sell them and the customer-service skills to support them. The result is that using an IP block often generates additional technical and communication problems. With the exception of few well-known and -supported IP blocks, integrating such a block in your system requires significant communication with the supplier, to the point that its engineers may end up as part of the development team, at least for a while. The team then must be able to communicate effectively while protecting proprietary information as much as possible. Companies such as VCX (www.thevcx.com) and organizations such as the VSI Alliance (www.vsi.org) are working to standardize this process and improve communication. But their work is far from done.

Requirements for team design
Development teams are like loosely coupled networks of application-specific processors. Such systems require data management, communication protocols, and the ability to recover after a failure. To function properly, each node must have a mechanism to understand its role in the entire system, and the resource manager must be able to reallocate resources throughout the system. Translating these requirements to human terms, a vendor must develop a product that allows you to obtain a description of the functions that your team needs to implement, using tools designed to support team-based design.

A team needs three types of data repository (Figure 1). Each member of the team must maintain a private area in which his or her ongoing work resides to avoid contaminating the common-data pool with rapidly changing work-in-progress files. It is also often necessary for several team members to collaborate without involving the entire team. The team needs a method whereby members can privately share information and files without necessarily revealing this information to the entire team. For example, a number of software developers working on code should be able to work together while shielding the hardware developers from the vagaries of their work, analog designers should be able to develop circuitry without worries that intermediate results will impact digital design, and developers must be able to work without impacting verification engineers with incomplete portions of the design. The communal database, on the other hand, is open to all members of the team and reflects the overall status of the project. However, it is available only to team members, not to the entire organization. The communal database is also the source of the final product release, as well as the release of reusable functional blocks that the team produces.


Improving the timeliness, accuracy, and quality of communication among team members enhances a team's efficiency. Although verbal communication is a powerful method for sharing ideas and status, it is often unreliable. And, when a team comprises members located half a world away, it is impractical. Written communication is likely to occur in the form of e-mail messages. Some of the messages contain documents that you must file at the proper time, to develop a complete documentation set for the project. But the text of each e-mail message may also be relevant, especially if you attempt forensic research on a project, to discover what improved its efficiency or caused a schedule slippage. Often, you can better gauge the efficiency of a team by judging the contents and quality of the informal communications among its members than you can with a formal document. Management must disclose at the beginning of a project that it will collect e-mail communications to preserve the privacy rights of the team members.

A project-documentation system must, at a minimum, be hierarchical. A flat system impairs members, because the existence of too many data items makes it difficult to find the set of documents relating to a specific design block. You can further increase efficiency by using a relational database in a hierarchical fashion. Carefully design the schema to allow engineers to link documents to the appropriate topics, but minimize the number of topics to avoid a rat's nest of links.

A good project-communication system supports real-time group communication using Internet-based visualization and markup techniques, as well as asynchronous messaging, such as e-mail and review of documents. Communication among team members must also be secure to prevent eavesdropping, sabotage, and intentional or accidental distribution of information to unauthorized persons.

Standards needed
Communication among team members is necessary, but communication among the EDA tools that the team uses is also important. For more than 20 years, EDA users have tried to formulate standards, sometimes in spite of EDA vendors, to enable data exchange independently of the tools generating and receiving the data. They have made much progress, and standards-making organizations have developed many standards; others have emerged as de facto industry standards. Yet, all of today's standards are serial. A tool must write a file, and then another tool must read the file. No standard exists, although after Synopsys acquired Avanti, Cadence announced the OpenAccess initiative, aimed at developing a standard API for its design database. Synopsys has recently reacted and proposed a similar initiative for the MilkyWay database it acquired with Avanti. Designs are now so complex that it is necessary for products from vendors to communicate dynamically and work in parallel to solve some of the most challenging physical problems in electronic design.

All projects, but especially team projects, benefit greatly from the ability to visualize the functional components and their relationships and interfaces. An engineer should always be able to check the relationship of the block he or she is working on with the rest of the system. Visualization of the relationships among the functional blocks of a design is important for interface-design and topology reasons. As products become smaller and operate at higher frequencies, the structures of interfaces increase in importance. Designers must choose the correct protocol to ensure that the design meets the required operating frequencies and that the wires that implement the interface are short enough to avoid RF and EMI problems. Finally, many electronic products now use multiple clocks. Visualizing the entire design helps designers define and observe clock boundaries, alerting them to the need for clock-synchronization circuitry and its impact on the design of functional blocks.

Organizations often overlook the needs for project management when they put together a project-information structure. This practice may seem strange, because the purposes of team-design structures are primarily to inform and to manage. But developers are often the focus of the architects developing a team design system, so the architects neglect the needs of managers. But no project comes together by itself: Projects need management. The larger and more disperse a team is, the greater the management effort it needs. The team-design system must provide managers with information to plan, schedule, and allocate. Before an organization approves a project, managers need to plan the development and forecast the schedule and the resources it requires, so that they can present a budget to the organization. An organization cannot and should not approve without a budget and a schedule. A project lacking these key elements will result in cost overruns and missed market windows-in either case, directly impacting the corporate bottom line.
Once the corporation approves a budget and a schedule, they should be available to team members, who will be responsible for meeting them. During the life of the project, managers must be able to review the status of the project against the schedule and budget, reallocate both human and capital resources, and change the schedule.

Tools you can use
Many tools can help you manage the supply chain and tools to manage code design and development (Reference 1). The most significant update in this area regards I-Logix. Last year, the company updated its Rhapsody Developer product to Version 4.0.1 and has added Rhapsody Architect, Rhapsody Designer, and Rhapsody Developer to the product family. Rhapsody Architect is available for C, C++, and J environments; Rhapsody Designer supports only C++; and Rhapsody Developer supports C, C++, J, and Ada.

Telelogic's products concentrate only on software-development support-an unfortunate decision, given that many of the change-control requirements are common to both software and hardware and that the number of integrated products requiring closer interaction between software and hardware engineers is rising significantly. Telelogic's CM Synergy DCM product provides distributed change-control management, ensuring that the work of a geographically dispersed team remains under the same change-control system. Another product in the Synergy family, ProjectSynergy, supports project management and works with the CM Synergy products. ProjectSynergy allows managers to retrieve the status of individual tasks and send notification of project changes to developers. The product provides a default set of mappings between Microsoft Project columns and Telelogic tasks to ensure synchronization between the two tools. Designers and managers can assign work, adjust work schedules, and track development activity in multiple databases from a single project schedule.

CoCreate Software provides the OneSpace Collaboration visualization product, which supports both 2- and 3-D drawing formats. Users download the client software on their systems and use the CoCreate server as the master process. The system allows any number of designers worldwide to view the design in real time. For managing your drawings, CoCreate's Project Data Manager works with the visualization software to file and organize the designs. CoCreate also offers 2- and 3-D modeling software that is compatible with the visualization product.

Oridus focuses on providing secure Web-based visualization software for the back end of IC design. SpaceCruiser supports multiple presenters, providing drawing-annotation tools and a white board to facilitate communications among attendees. GDS-SpaceCruiser is an interactive layout viewer. Silicon-SpaceCruiser allows users to view the place-and-route database, and Mebes-SpaceCruiser does the same for mask data. Finally, DWG-SpaceCruiser supports the viewing of IC-packaging design and CAD/CAM drawings.

Cimmetry Systems offers AutoVue and the more powerful AutoVue Professional, which, in addition to viewing, allows you to mark up a document and save the markups independently of the document, thus preserving layers of revisions. You can save markups in different files, and you can define multiple markup layers. You can also consolidate the individual markup files once the editing process is complete.

When Mentor Graphics purchased VeriBest, it acquired the company's Design View, which included DMS (design manangement system). From that product, it derived DMS (data-management system) and HDL Designer. The original product managed the development flow and the data associated with a design, and it supported team design. The current DMS, developed in the board-and-system-design division, now manages the parts-acquisition chain, taking advantage of a database engine obtained with the purchase of Descon. This product helps you find a part through an official link with PartMiner, manage parts by associating them with blocks in the design, generate a bill of materials, and interface with an external-components database. HDL Designer belongs to an area of the company focusing on HDL and FPGA design. It includes a number of modules. HDL Pilot is a common cockpit that provides a graphical user interface that allows you to manage design data and design activities. The HDL Author suite of tools allows engineers to develop a product using HDL code; graphics, such as state machines; and schematic diagrams. HDL Detective supports design reuse through analysis, visualization, documentation, and communication. HDL Designer supports project documentation. It lets you associate any file that is not part of the electrical description of the design-for example, specifications, test requirements, test results, and even software code-to any pertinent block, to make it part of the design database. HDL Designer manages revision control by interfacing with most of the popular version-control tools. The Mentor consulting group uses both DSM and HDL Designer and has relabeled HDL Designer as the QuickUse Development System. One of the most powerful features of HDL Designer is its knowledge of IBD (interface-based design). The system uses the external interface of a block to automatically maintain the hierarchy of the design.
A design team needs to process design data with a variety of tools that require significant design time. To start execution, the engineer needs to know that all required data is ready and that the computational resources are available. Once the run starts, the engineer must know whether it aborts because of error conditions or because a higher priority job pre-empted the license. Runtime Design Automation markets Flowtracer/EDA, a tool that understands the dependencies between the tool and its associated files. It automatically executes the tool; dispatches the job to an available machine in the network; and provides a graphical interface to aid in flow control, tool monitoring, and results debugging.

Synchronicity provides a suite of products that addresses all of the team-design requirements. ProjectSync helps manage projects by providing an event and trigger system to facilitate communications and process flow. You can also use it as a bug and issue tracker for the design, and you can define a development flow that uses the best practices developed within the organization. DesignSync manages the data associated with a project. The server-based application has a light client that supports parallel development, manages work spaces, and provides multisite version control and secure data access and transfer. Synchronicity bundles the two products into the Standard Developer Suite to provide the basic functions necessary for team design. The company has also created the HDL developer suite, which addresses front-end project management, including milestone planning and tracking, progress reporting, project and phase reviews, and electronic signoffs; the SOC Developer Suite, which supports design reuse, helping engineers to partition the design into blocks that they can then manage and track and creating a facility for capturing, tracking, resolving, and communicating design issues across the complete design hierarchy; and the Physical Developer Suite, a special version of the Standard Developer Suite that has been integrated with the Cadence Custom IC-tool user interface. Synchronicity's family of products provides the most complete coverage of team-design requirement.


Reference
1. Schweber, Bill, 'Project-coordination tools; Get your act together before you take it on the road, ' EDN, Nov 8, 2001, pg 75.


Acknowledgments
Thanks to Ed Rodrigues and Peter Bradshaw from BitBlitz and Steve Skiest from Molex for their contributions to this article.

You can contact Gabe Moretti at (1) 941-497-9880, Fax (1) 941-497-9887
E-mail gmoretti@edn.com