System-level design merits a closer look

The difficulty of generating a design from a set of requirements increases as products become more complex. Translating a set of specifications written in a spoken language into a computer-parsable format presents a number of problems.

First, the specifications must be correctly interpreted and understood. This goal is difficult to achieve because the semantics of spoken languages are context-sensitive, leading to confusion. It is also possible to generate an incomplete specification. Designers may not find a problem until late in the design cycle, when the required reworking is costly. Many products contain both hardware and software components, and a sentence may mean different things to a software engineer and a hardware engineer. If you write the specification at a level of abstraction significantly higher than the implementation language supports, difficult-to-find translation errors can occur.

The definition of “system” is itself vague. You can call any object comprising two or more parts interacting with each other a system. You cannot even begin to devise a tool to help with system design without first precisely defining the problem, the scope of the solution, and the goal you’d like to achieve. For this reason Gartner Dataquest, a leading EDA-industry-analysis company, defined a new term, “electronic-system-level,” or ESL design. ESL design is the design of an electronic product at the conceptual level, including hardware/software codesigning, design partitioning, and specification writing. A more precise definition of what needs to be accomplished gives managers a clearer idea of the project scope, degree of difficulty, and costs. They can then use project-coordination tools, such as those that Reference 1 describes, to better manage projects.

Figure 1 The introduction of new tools and methods is necessary to keep development costs to a realistic level (courtesy Gartner Dataquest).

It would seem, therefore, that designers would be eager to purchase EDA tools that address ESL design and that the market would rapidly expand. However, this situation has not been the case. In fact, many EDA start-up companies targeting this segment of the market have been unsuccessful and have gone out of business or have been acquired, and their engineers have been redeployed to other projects. Gartner Dataquest estimates the size of the market for fiscal 2000 at around US$70 million and the size of the total tool market at US$2.5 billion. The rising cost of developing a complex IC requires designers to continually refine their methodology. Gary Smith, chief EDA analyst at Gartner Dataquest, observed that by 2005 design engineers must be able to use ESL tools to keep development costs at a commercially viable level (Figure 1). Work by universities, industry consortia, and the IEEE to develop standards that will help in addressing ESL design is ongoing (see sidebar “ESL design needs standards”).

Most development teams still begin their designs at the RTL (register-transfer level), because the teams have experience with the available EDA tools and cannot afford to invest time in exploring a new methodology. Two major obstacles are impeding a more rapid adoption of ESL design by engineers: the lack of languages and related EDA tools to describe the functions and requirements of the desired product and the lack of computer-aided links between ESL and RTL.

DO YOU SPEAK "SYSTEM ARCHITECTURE"?
As Verilog and VHDL settled into their respective market segments, controversy over which language is better subsided. The June 2000 Design Automation Conference in Los Angeles found a new topic for panelists to debate: “Which language is right for ESL design?” The beauty of the debate is that you need only a strong conviction in your own opinions—not factual technical knowledge—to passionately argue your side. Just like the good old days of VHDL versus Verilog, when many presenters discussed the languages in marketing terms clothed in technospeak, presenters often discuss ESL-language choices in terms that provide little technical information to designers. You can also describe the debate as “SystemC versus Superlog.”

Proper engineering methods require that you define the problem, establish a goal, and develop a solution that allows designers facing the problem to productively reach the goal. In this case, the problem is that Verilog and VHDL (in the EDA market) provide neither the syntax nor the semantics to describe a product at the system level. The goal is to describe the requirements and functions of the desired product in unambiguous terms, so that computer-aided methods can check adherence to specification during the development process.

Connectivity has replaced personal computing as the primary market driver for electronic systems. The architecture of communication products, whether wired or wireless, focuses largely on data-flow problems, and personal computing focuses on control flow. Engineers have for many years used C to develop and test digital-signal-processing algorithms that address communications. Marketing teams have confused algorithm design with system design and concluded that ESL design is already taking place and that C is the tool of choice.

This conclusion presents two problems. First, most engineers use C to validate the algorithms, not to describe the architecture of a system. Second, the entire system also contains control-flow blocks, which you cannot describe in C, because the language has neither a time domain nor the notion of concurrency, and it does not support parallelism. SystemC, championed by Synopsys, partially addresses the problems by moving to C++ and creating a number of classes that you can use to mimic hardware primitives and time-domain events. As any software engineer who has moved from C to C++ can tell you, the change is fraught with problems. C++ requires a totally new approach to programming. You move from a simple algorithmic language, such as C, to an object-oriented language that is much more difficult to use, such as C++. Engineers proficient in C are not necessarily good C++ programmers. Moving from C to C++ is like moving from Verilog to VHDL: You get more power, but the tool is more complex. Synopsys claims—based on the number of downloads of the specification from its Web site—that tens of thousands of engineers are using SystemC. Independent surveys find that engineers are a curious lot and that they have downloaded the specification so that they can study it, but few are using SystemC for product development.

Superlog is SystemC’s adversary in the language wars. The language, developed by Co-Design Automation, is an extension of Verilog. Co-Design extended Verilog by adding features that allow a more abstract description of an electronic system. Most of the semantics elements it added were borrowed from VHDL. Co-Design chose to extend Verilog, the most widely used language for RTL design, instead of championing a new implementation of VHDL, for good marketing reasons. This strategy, like Synopsys’ SystemC approach, seeks to build on an installed base to quicken market penetration. The major technical advantage of Superlog over VHDL is a clean and powerful interface to C that allows hardware/software co-design. Because it is built over Verilog, Superlog provides both event scheduling and concurrency in a natural way and does not require its users to become familiar with object-oriented programming.

As in every modern conflict, the battlefield is more complex. Around the two major combatants are other factions that receive less coverage but may be worth considering. Rosetta and Esterel are two ESL languages that have been used in actual product development, but other languages exist, and work on some ESL tools is showing promise. SystemC and Superlog address the design-verification problem, but requirement specification and design partitioning are also important issues.

The US Department of Defense funded the initial specification and development of Rosetta. The goal of the project was to produce executable and verifiable specifications for any type of system. The language covers more than electronic systems, but it has been used successfully in the design of electronic systems. Rosetta provides a good example of productive government funding of EDA research. TRW Systems has used VectorGen, a tool developed by EDAptive Computing, to develop specifications and test vectors for a satellite-communication preprocessor. VectorGen reads the description of the requirements written in Rosetta and generates the test vectors used to simulate the preprocessor in a VHDL environment. Rosetta allows designers to specify various views of the system, called facets. Designers can use a number of facets to specify power consumption and distribution, thermal operating conditions, frequency response, or arithmetic accuracy, for example. Given a complete set of facets, developers can generate system models and test vectors to verify the behavior of the design. Engineers can then develop an RTL description to proceed to hardware implementation.

The European Union started working on a system-design problem a few years before the start of Rosetta. It funded the development of Esterel, a formal language designers use to describe the structure and behavior of systems. Esterel Technologies markets Esterel Studio, which is a graphical system-definition and -development environment that supports formal component definition, interactive system simulation, formal properties verification, and test and documentation generation. Some European system companies are using Esterel in actual product-development projects, but US EDA vendors do not yet offer tools for the language, and Esterel Technologies introduced the language in the United States during last year’s Design Automation Conference.

THE MISSING LINK
Most companies do not do ESL design, because the tools to carry the design to an implementable RTL representation either do not exist or have limited usefulness. The EDA industry has labeled this step “behavioral synthesis.” Both this label and its current intent may turn out to be wrong. The phrase describes the transformation of the design from a behavioral level to an RTL. The problem is that the behavioral level is ill-defined. You cannot say whether an expression describing an algorithm, or a set of requirements, or even the graphical representation of two functional blocks and their interface constitute the behavioral description to be synthesized. EDA vendors have tried to develop products that transform algorithms into hardware circuits. Synthesis products that accept C as input and produce a gate-level netlist have been available for more than a decade. The transformations are generally difficult and result in nonoptimized circuits. Therefore, all behavioral synthesis products sold so far have succeeded in only narrow cases and have not been widely accepted.

Just as there is no one single language that you can use for every aspect of ESL design, there is no single tool that can synthesize such a design to a lower level of abstraction. The authors of Rosetta, for example, understood that system architects use a collection of “views” to describe the various aspects of the system. So they incorporated into the language the fundamental notion of a “facet,” to allow engineers to independently describe and process each view while maintaining the relationships among the facets required to make up the whole system. Following this example, the EDA industry should define and develop a toolbox that provides the appropriate tool for the many functions required to produce an RTL design from its ESL representation and to verify the equivalence of the two descriptions.

Realizing that the problem is too complex, a few EDA vendors have subdivided it into narrower, easier to solve, problems. You can find tools that perform “interface synthesis.” N2C from CoWare is an example of such a tool. It takes a graphical block representation of a design, identifies the connections between two blocks, and generates shell Verilog modules or VHDL entities that preserve the hierarchy and connectivity that the system architects established. N2C uses a library of common functions to help designers implement the functions of each RTL block.

Because every design is different, it is generally impossible for an EDA tool to generate the optimal hardware for a given function, or even to partition the architecture for optimum implementation. Engineers must be sure that the ESL design and the manually modified RTL design are equivalent. Therefore, vendors must extend formal verification tools, which you currently use to verify a gate-level design versus its RTL equivalent, to cover the transformation from ESL to RTL. Such verification tools will need to use both equivalence-checking and theorem-proving techniques to handle all types of methods that architects use.

Engineers must verify that the various levels of implementation adhere to design constraints and physical requirements. Currently, functional verification is the most expensive part of product development. A tool such as EDAptive’s VectorGen can diminish the cost of functional verification by automatically generating a set of vectors covering the requirements described in the Rosetta facets. When designers describe control logic at the architectural level, products such as Volare from Get2Chip generate the corresponding finite-state-machine hardware as well as the logic to handle scheduling. Although each of these tools provides a valuable function, designers need a data-centric integrated environment that allows design manipulation based on the nature of the inputs and desired outputs. A complete flow allows designers to make predictions based on requirements and visualize an implementation. Then, by analyzing the implementation, they can validate the requirements or identify necessary modification (Figure 2). This feedback loop is still missing. In addition, designers must use a subset of the ESL requirements for physical synthesis. Engineers must be sure that all the appropriate data is available and used during this step. The tools available today make ESL design possible but unnecessarily complex and expensive.

COPING WITH THE SHORT COMINGS
Despite the lack of an integrated ESL-design flow, some companies are developing products from specification to silicon using a computer-aided methodology. In addition, the electronics industry has in many cases found a way to minimize the complexity of system design, thus eliminating the need for most of the sophistication that traditional system design requires.

Figure 2 Complete feedback loops in design methods are necessary to enforce consistency among the various levels of abstraction that product development uses.

Focus Enhancements designs advanced, proprietary video-scan-conversion ASICs and digital-video-conversion and video-production equipment. The specifications for each product are still written in a human language, but the algorithms are prototyped first using The MathWorks’ Matlab and then C. Because the main computational engine in Focus Enhancements’ system is a DSP, C is a natural tool for algorithm verification. The engineering team manually enters the RTL design using Verilog, counting on its experience and knowledge to avoid mistakes. The designers then simulate the system and compare the results with the results of the C-language prototype. Focus has downloaded and studied the SystemC specification but has yet to use it in

any development work.The major drawback seems to be the lack of parallelism in the system and the need to convert to Verilog or VHDL to synthesize. The conversion process, even if done automatically, can be a source of errors that may be difficult to identify. The problems inherent in a multiple-language system are evident in Figure 2. Engineers must define the requirements and the algorithms using one language and describe the hardware implementation in another language—an error-prone method.

STMicroelectronics has a number of ongoing pilot programs for ESL design. Its automotive division is using Cadence Design Systems’ VCC. The tool helps STMicroelectronics identify elements of system functions and separate them from the implementation details. VCC also helps in exploring functional partitioning, both among hardware blocks and between hardware and software. One of the goals is to enable concurrent hardware and software development. STMicroelectronics also believes that design reuse will improve, through both the company’s and its customers’ efforts. By using an ESL design, the company can identify reusable functions and improve the documentation of its own products so that its customers can more frequently reuse them. STMicroelectronics sees the need to merge data- and control-flow models into one system or tool and to have the ability to predict the performance that the product will eventually achieve while still at the architectural-design stage. One of the major obstacles to a quick and widespread implementation of ESL methods has been the lack of architectural models for existing IP (intellectual-property) blocks and memory. Cadence has also found that the lack of IP models is an obstacle to wider acceptance of VCC and is working to fix the problem by developing models that define the properties of each IP block at the functional level.

Platform-based design is a methodology that provides a way to do ESL design by simplifying the requirements. Designers in an application area—wireless communications, for example—begin the design by assuming that a number of important hardware and software blocks are developed and functional. The firmware for the operating system, the DSP, and the microcontroller all come from third parties, in the form of IP. A platform is a collection of building blocks that has been verified to work together; it is like a computing system that you can tailor to your requirements with relatively minor modifications. DSP vendors, for example, provide platforms to their customers. FPGA vendors also offer application-specific platforms in a number of areas. Product developers add whatever hardware and software is necessary to customize the platform, but the job is significantly less complex than if you start from scratch. Some EDA vendors have developed tools that address platform-based design. Mentor Graphics offers Platform Express, a tool that lets engineers develop their own platforms from an inventory of supported IP. A designer, for example, chooses a microcontroller, and the tool provides a list of all peripheral-controller cores that have been verified to work with the chosen IP, together with the appropriate buses. He or she can then put together a platform that fits his or her application area using a verified subsystem as a start.

ESL-design tools have suffered from the lack of integration with tools addressing RTL and gate-level design, but the gap is slowly narrowing. Experience with the obstacles that engineers face will help vendors focus on the correct set of problems and develop solutions. With any luck, the industry will meet analyst Smith’s prediction of a practical ESL methodology by 2005.

ESL DESIGN NEEDS STANDARDS Standards facilitate tool integration and improve designers’ productivity. But standards are difficult to develop. They require a clear understanding of the problem to be solved, a group of interested and dedicated individuals willing to donate their time to work on the solution, and the opportunity to develop a consensus. Standards are expensive, and companies are generally unwilling to invest in standards development because they do not perceive that doing so will result in market superiority. Government funding of standards development can effectively stimulate productivity and generate tangible returns. Yet most EDA standards are not the result of government funding, and when funding has occurred, especially in the United States, it has generally been in small amounts and for short periods of time. In ESL (electronic-system-level) design, many types of standards-development activities are taking place: research centering on academic institutions, efforts funded by industry groups through a consortium, efforts initiated by one company in the form of an initiative, government-sponsored research and development, and activities by professional organizations that traditionally develop and promulgate national and international standards. The Gigascale Silicon Research Center is an organization that brings together 14 US universities to perform long-range research that addresses the challenges of chip design expected in the next eight to 12 years. The University of California-Berkeley leads the efforts, and ESL-design issues are one of the topics of the research. The work is principally funded through corporate contributions, although some government funding is also used. Accellera is one of the most active and successful organizations in the development of EDA standards in the last few years. Accellera is a consortium of companies, both EDA vendors and users, that resulted from the fusion of VHDL International and Open Verilog International. Its technical working group has ongoing activities in a number of ESL-design issues. Committees are working on C-based architectural languages, Rosetta, Verilog AMS (analog mixed signals), and the development of a semantic reference manual to improve communications in a field in which terms are often poorly defined. Accellera also believes that formal verification must play a significant role in ESL design and has started a working group to address this application area. The consortium is also working on a system Verilog language centering on the donation of a portion of Superlog by Co-Design. Member contributions, either financial or in-kind, fund most of Accellera’s work. In the spring of 2000, Synopsys launched the OSCI (Open SystemC Initiative) to develop an ESL-design language based on C++. The reason for starting its own initiative instead of sponsoring the work through a more traditional standards-making body was that those organizations took too long. Two years later and after much controversy, including the resignation of its executive director last year, OSCI can now distribute the first version of what seems to be a workable language nucleus for future standardization. Contrary to most standards-making bodies, OSCI is an exclusive club that charges US$50,000/year for corporate membership and US$2000/year for individual membership. DARPA (Defense Advanced Research Projects Administration) provides most government funds impacting EDA. VHDL is the most visible EDA standard resulting from DARPA funding. The Rosetta language development began under a DARPA grant. Now, most of the work goes on under Accellera sponsorship, although some federal funding is still available. The IEEE is the most influential US organization in the development of national and international electronics-engineering standards. The organization has developed and maintains a number of EDA standards through its DASC (Design Automation Standards Committee). Activities abound, although coordination among the various efforts can be improved, and funds remain scarce despite the obvious strategic impact that EDA makes to the economic well-being of the nation and the world.

REFERENCES
1. Schweber, Bill, “Project-coordination tools: Get your act together before you take it on the road,” EDN, Nov 8, 2001, pg 75.

You can contact Editor Graham Prohpet at
(44) 118-935-1650, Fax (44) 118-935-1670
E-mail grapham.prophet@cahnerseurope.com