design tools

The New System-Level Design Language System-level design languages--their features, capabilities, and requirements--are the topic of the moment and what you should expect to see in the next few years. by Steven E. Schulz

It seems that system-level design is on everyone's mind these days. So it's not surprising that talk of a system-level design language (SLDL) has been making headlines. But what exactly is SLDL? What does it do? Where can one get it? If you've been wondering about all the industry hoopla surrounding SLDL, read on.

Fundamentally, SLDL is a language notation that embodies semantics for describing system requirements prior to partitioning. While no such language is available yet and none will be for several years, its capabilities and priorities are being determined now, and prototyping could start next year. The language itself should be available in 2000.

This article will explain why an SLDL is needed, who's driving it, what it promises to offer designers, and when you can expect it to be integrated into EDA tool flows. In addition, we will touch on some of the key concepts involved in describing heterogeneous systems.

Figure 1	The semantic requirements cube
Any set of notations considered for SLDL may be mapped onto the cube to analyze how they support SLDL needs (either Phase I or II). Classes of requirements (behavioral-, structural-, or constraint-based) and self-consistent semantic domains are used as primary dimensions of the full SLDL design space.

Larger designs
In simpler times, designers assumed that if they could write RTL code, they could handle the mundane challenges of getting function and timing right. Today, however, a rapidly growing proportion of designs include embedded software, making the description and analysis of system functionality and timing performance far more complex. There are also increasing demands to integrate analog and RF technologies on the same silicon with digital function. Add to this the integration of on-chip memories with multiple processors and interface protocols, and system-level design starts to take on new meaning. Because of greater time-to-market pressures, the risks to deliver all this integration within highly constrained market windows are increasing.

Of course, those changes provide similar motivation for the Virtual Socket Interface Alliance (VSIA). VSIA is working hard to establish common standards that will facilitate large-scale design reuse on silicon. SLDL and VSIA are highly complementary; whereas VSIA is attempting to provide better infrastructure for hardware implementation by leveraging existing technologies, SLDL is focusing on delivering an entirely new technology at the front end of the process. Arguably, SLDL hopes to facilitate reuse by allowing true hardware/software codesign and system constraint budgeting.

The solutions that currently exist are inadequate. HDLs were originally designed for implementation of hardware. Yet today, over 35 percent of new VLSI design starts include some form of embedded software, and that trend is accelerating. While several EDA tools have recently offered specific hardware/software coverification capabilities, hardware/software codesign remains an elusive Holy Grail for the industry.

Managing design constraints
Additionally, the problem of managing design constraints is growing exponentially. Larger designs, the integral use of software and analog/RF hardware, a wider variety of consumer applications, deep-submicron effects that affect system trade-offs, and packaging and thermal effects all impose new constraints. Until recently, designers have managed to juggle basic constraints in their heads, comparing them with waveform diagrams and textual reports from tools. Now, though, constraint management has more in common with trying to solve hundreds of simultaneous non-linear equations. Battery life, heat dissipation, density, and cost are typical "care-abouts" in addition to timing constraints.

System design requires a system view: If you can't describe it, you can't design it. At present, no interoperable format exists to capture that system view. Industry leaders believe that the lack of such a format is holding back an enormous potential market for highly integrated electronic products, as well as for new EDA tools.

Industry-driven origins
In October 1996, over 40 industry leaders in the field of system design convened in Dallas, for a two-day needs assessment workshop. Their challenge was to determine what role, if any, EDA standards must play in response to the EDA Industry Council's 1996 Standards Roadmap document. The roadmap cited serious and critical gaps in EDA flows for system-level design. The conclusion of that worldwide expert group was that current standards were insufficient to support system-on-a-chip capabilities and that some new notation would be necessary to achieve design objectives.

A new SLDL committee was established with David Barton (Intermetrics, Inc., Alexandria, Va.) elected chair. From that point, subcommittees were formed to focus on four interrelated areas: requirements and constraints, hardware/software codesign, system-to-component interfaces, and formal semantics (see "Requirements and Features Planned"). Since that initial workshop, numerous SLDL requirements workshops have been held in San Jose and Italy. The Air Force Research Labs recently awarded a three-year government contract to help accelerate the development and industrial adoption of SLDL. In addition, several hundred participants representing semiconductor and electronics system companies, EDA vendors, standards development bodies, and government agencies exchange views and make recommendations using the SLDL e-mail reflector.

Primary support is provided by the EDA Industry Council, with the Industry Council PTAB (Project Technical Advisory Board) serving as official sponsor. However, other consortia are also providing strong support. VHDL International is embracing SLDL as a natural complement to VHDL and is in fact planning on strong synergy with development of VHDL 200x. VHDL 200x requirements are derived from multiple sources that include SLDL requirements for integration purposes.

Key industry standards development organizations are also providing strong support. The Design Automation Steering Committee (DASC) of the IEEE tracks SLDL progress regularly and discusses synergistic opportunities. The European CAD Standardization Initiative (ECSI) hosted a three-day workshop in Italy last summer and is sponsoring a NATO Advanced Summer Institute in August, in which SLDL will be taught to attendees from over 40 countries. In Japan, EIA-J members have already included SLDL alongside VHDL and Verilog on their ASP-DAC survey of language usage trends. In addition, many of the top university researchers in the field have participated in discussions surrounding SLDL and how to incorporate into it the best of their research concepts.

Concepts behind SLDL
The scope of SLDL is motivated by today's system-on-a-chip business drivers; however, nothing prevents its use in large-scale electronics systems. The emphasis is on microelectronic designs with embedded software and tightly coupled interactions between digital, analog, and RF hardware. In addition, the scope includes mechanical and optical interfaces.

But what are system requirements? They fall under three categories: what the system should do, how the system is designed, and assumptions that constrain the design space. Those categories can also be labeled behavior, structure, and constraints (see Figure 1). The behavior category describes the functional goals and objectives of the design. The structure category, also known as architecture, defines relationships between various components that will be used to compose the system. Structural decisions often occur early in the design phase, when the architectural trade-offs are made and existing components or architectures are reused. The constraint category describes assumptions and assertions that must be satisfied by the implemented system.

It's important to understand how constraint specification and behavior specification are fundamentally different. Most engineers are used to describing functionality in terms of sequences of actions and reactions. That's known as an operational approach, which lends itself to simulation-based techniques. On the other hand, constraints are described by being stated as assertions, a declarative approach that lends itself to formal proof techniques. One of the problems with operational style specification is that it requires more complete specification for meaningful simulation. Declarative constraints cannot be simulated per se, but their consistency can be verified at any time. Thus declarative statements permit partial descriptions to be entered and analyzed with faster static, numerical, and formal analysis techniques. Since both VHDL and Verilog are operational notations (as are C++ and Java), declarative constraints are a highly complementary enhancement, even within today's HDL environment.

Figure 2	SLDL plug 'n' play architecture
Phase I of SLDL is currently targeting system-wide declarative specification constraints. Phase II will support behavior and architecture by "bridging" the semantics of several existing domain-specific system languages.

Specifying behavior at the system level is even more complex. The semantic meaning of statements can be fuzzier, and more inter-dependencies occur between them. For example, the semantics used to describe data flow versus control flow behavior are typically quite different. High-level data flow algorithms written in C are commonplace, but C algorithms cannot adequately describe the design objectives of a RISC microprocessor. It's not surprising, therefore, that existing system-level notations all assume a specific model of computation in their underlying semantics. And even though those computational models may use different semantic domains, all could very easily occur simultaneously within a single piece of silicon. Designers need SLDL to support those models of computation in a unified environment that preserves flexibility for repartitioning.

Figure 3	System design space
Language notations can overlap others within a semantic domain and can represent shared areas between these domains but can't support mutually exclusive regions of different semantic domains.

Since hardware is inherently concurrent, modeling the proper granularity of interacting behavior in hardware can be critical. For example, trading off high-level features of an on-chip communication bus may become too awkward if every detailed handshake must be modeled explicitly; yet refinement for timing budgeting purposes may require that detail. Timing should also be represented at multiple levels of abstraction. Designers shouldn't be forced into defining clock edges in absolute time before they know the required clock structures and clock rates. In such cases, it can be more natural to specify events using relative timing references or abstract synchronization points.

Dynamic requirements
All requirements are not created equal. Some are more important than others, and some are fixed while others are subject to change. Dynamic requirements are often derived from analysis of fixed requirements and designers' experience and evolve as more detail is learned about the system. One could even envision that trade-offs among competing requirements might imply arbitrary functions that could vary the relative priority weighting of a function based on how well other requirements are satisfied.

Though it would be convenient to assume all constraints are driven from the top down, in fact, bottom-up constraints are just as common. That's historically been because of lessons learned from similar designs, but the coming era of design reuse will also be driven by existing virtual components integrated into the solution. Since all implementation constraints must eventually be satisfied, it's most desirable to capture and work with known constraints as early in the design process as possible. Thus SLDL will support both specification and implementation constraints.

A multiphase approach
The SLDL committee is addressing those features in a multiphase approach. The first phase will focus on declarative features, primarily requirements and constraints. Since existing HDL's lack broad system constraint information, that initial deliverable can be integrated into EDA tools along with VHDL and Verilog to immediately enhance our design capability. The second phase will deal with the more complex problem of models of computation and supporting broader semantic richness for describing system-wide behavior.

Phase I support plans emphasize cross-domain constraint specifications, including timing (latency) and operational parameters, such as power consumption, noise, gain, and other measurable engineering parameters. It will support information flow between components, including constraints on that exchange. Temporal abstraction will include fixed-time, relative-time, and statistical timing relationships. Structural descriptions of component interaction will also be supported. It's likely that two classes of data types will emerge: those directly supporting tool analysis and those captured for designer reference. The committee plans to implement SLDL as an open ASCII format, suitable for either direct user input or for generation by EDA tools.

The overall architecture for both phases of SLDL will attempt to integrate several behavioral models of computation using a concept called "bridging semantics" (see Figure 2). Each notation supporting a given model of computation implements a consistent set of semantics that are contained within a semantic domain (see Figure 3). Because research has shown it may not be possible, let alone practical, to design a self-contained semantic supporting all computational models, it's planned instead to connect the "semantic islands" with "semantic bridges." Fundamentally, many anticipate that only two definitions must be mapped using the bridges: consistent abstractions of time and consistent semantics for information flow. Hopefully, that simpler approach will be both feasible for language design and more easily implemented into EDA tools. Rather than having an enormous language with ambiguous ways to describe the same thing, the approach should help in partitioning the language design into semantics in which each computational model is easier to write and easier for tools to process.

Status, schedules, and plans
Most of the key features of SLDL have emerged and solidified over the past 18 months. Over the last six months, a handful of industrial representative examples have been collected as reference points for testing the validity of SLDL requirements. The examples are expected to represent at least 80 to 85 percent of industry need, but additional examples for any remaining requirements are still welcomed by the committee (see "A Novel Approach to System Design").

The requirements for phase I are expected to be completed and approved no later than June '98. Simultaneously, language design will begin in earnest to start implementing those requirements. Early prototyping between several of the EDA suppliers and user companies is anticipated to occur throughout 1999 and 2000. After several prototyping iterations, the first industrial use is expected by the end of 2000. Recently, several companies have developed a pseudocode of SLDL features to aid in early analysis of the many language design options.

While phase II has yet to be scheduled, SLDL leadership expects it to start in the middle of '99, likely requiring three or four years to complete. Although that's an aggressive target, the expectation of leveraging much existing good work in behavioral semantics should help significantly (see "Building on Existing Work").

Just do it
There are numerous ways to get involved with the development of SLDL. First, you're invited to visit the SLDL Web sites, to review all work done to date for additional background, and to evaluate the relevance of SLDL objectives against your own company's needs. You're also encouraged to communicate information about SLDL within your company and to join the e-mail reflector to participate in open discussions as SLDL evolves. Companies not already represented in the initiative may request official participation on the SLDL committee. Contact information is available at the SLDL Web site: www.si2.org/sld.

The beginning of a large paradigm shift in design is coming and with it new capabilities for design expressiveness. While there's significant risk in this bold initiative, there appears to be even stronger business urgency and worldwide support. New supporting design methodologies will eventually emerge to take full advantage of SLDL's potential; however, significant benefits for system-on-a-chip designs should be possible within just a few years. Because SLDL is on a fast track for deployment in 2000, leading electronics designers and EDA suppliers alike will want to follow its progress closely.

Contributing Editor Steven E. Schulz is the founder and executive sponsor of SLDL in his role as the chairman of the EDA Industry Council PTAB, a technical advisory board for EDA standards directions and coordination. He's a senior member of the technical staff in Texas Instruments, Inc.'s worldwide ASIC group in Dallas, where he's responsible for defining the ASIC backplane roadmap for TI's system-level integration strategy. He also serves as president of the board of directors of VHDL International.

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

integrated system design  July 1998