System-level design garners more attention as the years roll by, due to the proposal of new languages, the development of design flows, and the formation of new standards committees. Yet, we ask questions about what system-level design really is. As we learn more about implementation technologies and product demands, our understanding of where system-level design should take us and what problems tools should solve is becoming clearer.
To understand system-level design, let's think about the main role of the systems engineer. In simplest terms, the systems engineer defines your problem and understands how your work integrates into the larger product development activity. System engineers certainly understand system function at a higher abstraction level, but they also grasp how performance constraints, such as cost, reliability, timing, and energy consumption, affect the final design. In other words, they understand the overall collection of heterogeneous information as a holistic representation of the emerging system.
As systems that rely on semiconductors increase in complexity and heterogeneity, they require the same system-level attention as, say, a large civil engineering project. Cost and power constraints, timing, and interface issues must all be managed in the context of providing correct function. Such issues play an ever-larger role in getting systems right.
To support system-level design with languages, tools, and design flows, we must address abstraction and heterogeneity. Abstraction allows the engineer to choose what details should be dealt with in a given model. Heterogeneity lets engineers select an appropriate representation for their models and integrate representations from multiple disciplines. Basically, any specification or programming language allows for abstraction and heterogeneity. There's a need for languages that actively support such concepts.
Abstraction is the process of excluding model details as appropriate for solving a problem. As new abstractions are sought for complex systems, simply raising the abstraction level of simulation languages isn't enough. We need declarative modeling abstractions that support incomplete specifications, nonexecutable performance requirements, and symbolic analysis techniques.
Heterogeneity is supported when a language, tool, or flow can represent information from multiple perspectives. By their nature, systems are heterogeneous. Different components and different models of the same component may have different underlying models of computation. When integrating components and models use varying computation models, we must understand how those underlying models interact. Whether you're modeling heterogeneous components communicating through a well-defined interface, or modeling interacting, heterogeneous models of the same component, information integration becomes critical.
Is developing tool and language support to move to the systems level revolutionary or evolutionary? The only logical answer is that it's both. Evolutionary languages like SystemVerilog and SystemC have successfully raised the abstraction level for system simulation. Both build on existing design and programming languages to provide necessary functionality. Revolutionary approaches like Rosetta, Ptolemy II, and Metropolis represent languages that attempt to deal with heterogeneity and abstraction issues by integrating different models of computation.
Accellera's Rosetta effort is developing a language that explicitly addresses system-level design issues. Rosetta gives systems engineers the ability to develop abstract systems models and integrate heterogeneous, domain-specific models. Engineers using Rosetta define system models, called facets, based on a collection of modeling domains. Each domain provides vocabulary and model-of-computation information that serves as the basis for describing domain-specific system facets. Collections of facets are composed to describe systems constructed of heterogeneous components and heterogeneous models of the same component. Interactions defined between domains allow analysis tools to determine how and when domain-specific models interact.
Thus, it's possible to describe performance parameters in one facet, functional requirements in another, and define interactions between them that support analysis of system-level effects of local changes. At DAC 2002, Accellera's Rosetta Committee demonstrated modeling of the interaction between energy consumption and functional requirements.
Rosetta standardization is an ongoing process under the Accellera Technical Committee umbrella. Although significant work remains, the promise of language support for system-level design is being realized. In combination with evolutionary approaches, Rosetta can provide a long-term solution for system-level design problems. Visit www.sldl.org.
Reprints
