Design Languages Vie For System-Level Dominance

There's change in the wind for designers as IC geometries shrink and transistor counts rise. Design methodologies must move with the physical silicon. Clearly, hardware-description language-based methodologies increasingly are a hindrance to simulation and verification. It's time for designers, as they did a decade ago, to consider moving up a level of abstraction.

In the world of design languages, change is driven by rising design complexity. For example, by the late 1980s, ASIC designers had begun shifting from schematic-capture-based design methodologies to the emerging hardware-description languages (HDLs). This move to the higher level of abstraction, represented by the register-transfer level (RTL), helped designers regain control over the rapidly escalating complexity.

The early 1990s are remembered for the so-called "language wars," as Verilog, VHDL, and other HDLs competed for market share. The invention of synthesis technology by Synopsys propelled Verilog to prominence in 1988. It enabled the synthesis of Verilog hardware descriptions directly into gates. In 1991, Cadence made Verilog an open standard; it became an IEEE standard in 1995. Verilog became the veritable 800-lb gorilla in RTL design and has been ever since.

Today, a similar scenario is developing. A new "language war" is brewing in which a number of system-level design languages (SLDLs) are touted as the means to not only speed up simulation for these large ASIC/SoC designs, but also to address hardware/software partitioning and coverification in one fell swoop. Standards organizations such as Accellera are working to solidify these languages, while industry consortia like the Open SystemC Initiative work to rally support.

While most, if not all, large system OEMs already incorporate some form of system-level design exploration into their flow, this isn't the case with most smaller companies. There are good reasons to consider using high-level languages before starting the long, hard slog through simulation at the RTL. But know that it's still early in the game for SLDLs. Track records are spotty in terms of going all the way to implementation from a high-level design description. Tool flows are still coming together. Indications show that it can be done, but not painlessly.

Let's define exactly what's meant by "system-level design." To most EDA tool vendors, it means the exploration of SoC/ASIC architectural tradeoffs at a level ahead of partitioning the system's functionality into hardware and software. System-level design is certainly at a level above RTL. "It's pretty clear that if you're talking system-level design, you're talking more than just behavioral synthesis of hardware blocks," explains Stan Krolikoski, vice president of business operations for Cadence's Systems and Functional Verification Group.

"You're talking about the relationship of hardware and software, the relationship of hardware blocks to other blocks within your system, and about parts of your system that sometimes are ignored, namely the communication links, like buses, and what their effects are on the whole," he explains.

Others would maintain that system-level design implies a way to describe a system algorithmically. It should also include a mechanism for checking assertions about the design.

Foremost among the reasons for altering a design methodology to include a system-level layer is the simulation and verification issue. With SoCs and ASICs ballooning into the multimillion-gate range, simulation of a smidgen of runtime can take weeks. A design description at a higher level of abstraction can remove much, if not all, of the implementation details that bog simulators down while retaining the pure functional information. The result is much faster simulation and more time for what-ifs, tweaks, and other stabs at an optimal architecture.

Another major benefit is in hardware/software codesign and coverification. An increasingly large part of any system's functionality is implemented in software. Higher levels of abstraction can make it easier to observe the behavior of a system in total, as the system architect begins pondering the difficult issues related to partitioning.

Two predominant approaches to system-level design are currently being batted around in the marketplace. One is to reshape the C/C++ programming language to enable it to describe hardware concepts, something it can't do in its native form. The other is to extend the existing HDLs, and primarily Verilog, upwards in abstraction, so they can express system-level concepts.

System architects who tend to take a top-down approach to design will more likely be drawn to the C/C++ approach, represented by languages such as SystemC, SpecC, HandelC, CynLib, and the ANSI C/C++ coding methodology from C Level Design called CycleC. On the other hand, HDL-oriented designers seem hesitant to abandon or even alter the methodologies that have gotten them this far.

Many of those designers might find an incremental approach that adds system-level capabilities to HDLs to be more attractive. Co-Design Automation's Superlog language best exemplifies this approach. Thrown into the mix are some verification languages like e and OpenVera, which can ease the design of RTL test benches. Each approach has its strengths and weaknesses at various points along the path from high-level design description down to RTL (Fig. 1).

In one way or another, the C/C++ derivatives are all attempts to take a language that has traditionally been used for programming and extend its utility into the hardware realm. At the same time, C/C++ supporters say, the language maintains its support for the software side of the system equation, making this the best approach for full system-level work.

In their native forms, though, serial C and C++ languages don't offer constructs for algorithmic expression of hardware design concepts such as timing and concurrency, nor for data types like tristate logic. A superset of the C language, C++ offers the substantial benefit of being extensible by defining classes and building class libraries. These class libraries carry the constructs that enable the language to express hardware concepts.

Does endowing a sequential programming language with the ability to express hardware concepts, like parallelism, make it suitable for hardware design? Dave Kelf, vice president of marketing at Co-Design Automation, doesn't think so. "Our belief is that C++ doesn't give you an evolutionary route for hardware design, nor for system design and verification," he says. "Secondly, it's actually a very alien mechanism for many designers to use. It's very good for people like system architects who are used to programming in C++ and working with algorithmic models. But there are a lot of issues when you come to real device implementation."

The leading C/C++-based language, SystemC, was developed by Synopsys, CoWare, and Frontier Design (now Adelante Technologies). Driven by the Open SystemC Initiative, the language has gained the broadest support in the industry to date. It's a modeling platform consisting of C++ class libraries and a simulation kernel for design at the system-behavioral level and RTL.

Class libraries for SystemC, now freely available in Version 2.0 in beta form, include classes for time, concurrency, hardware data types, and others. Version 2.0 also includes capabilities for modeling of communication between blocks in a design (Fig. 2).

But this begs the question: Is one well served by coding in such low-level, or RTL-like, detail when working in a high-level language? After all, the point of working at higher levels of abstraction is speed.

"A distinction must be made between behavioral C and RTL C," says Herman Beke, chief executive officer of Adelante Technologies. In Beke's view, the former would facilitate a design description hewing to the notion that system-level design at high levels of abstraction implies a purely behavioral description of the system. In such a description, there's no notion of timing, nor any assumptions regarding implementation and partitioning. The idea is simply to describe the system's function algorithmically, feed that description's input with data, examine the output, and determine whether it's correct. If it is, then the algorithmic functional description is good, and the designer can move on to partitioning and implementation details. But if not, the designer has work to do.

Beke terms RTL C as what happens when hardware concepts are invoked. RTL code implies that there's at least cycle-level clocking involved. "If you use the class library principle, you're still using what looks like standard behavioral C," he says. "In reality, the customer might think he or she is writing ANSI C code at the behavioral level. But in practice, because of all the libraries, they're creating an RTL description. That's what they're really doing even though they might not think so."

What's so bad about that, you might ask? Beke maintains that such a meth-odology might make things easier for the designer, but such an approach hides and smoothes over the complexity of real RTL design.

There's an ulterior motive behind such an approach. Some advocates of system-level design see a path from a behavioral description straight through to implementation, which is the thinking behind technologies like behavioral synthesis. Those who have real experience with attempts to design hardware in C/C++ would advise caution in this respect.

Andy Meyer, chief technology officer and cofounder of the design services company Zaiq Technologies, has seen some projects through from C++ to implementation. He sees some benefits to using straight ANSI C++, a method advocated by C Level Design in its CycleC coding methodology. "The positive side of that kind of approach is that it's simpler to code and to execute. As a result, it goes a lot faster," he explains. C Level's approach doesn't involve class libraries, but a style of coding with pure ANSI C++ that supports clocks, resets, hierarchy, and concurrency. The primary benefit is extremely fast simulation, on the order of hundreds of times faster than equivalent RTL HDL designs.

Part of that speed stems from the absence of class libraries. Co-Design Automation's Dave Kelf points out that the use of class libraries to support timing forces the use of an event-scheduling queue, which can sap simulation speed. C Level's approach sidesteps that. According to Meyer, the downside is that you're stuck with straight C syntax and capabilities. "This means that if you want to do 72-bit arithmetic, you're in trouble. You will have to write the code to make it all work. But the class libraries don't care how many bits it is. Arbitrary is miserable for C and great for C++ class libraries," Meyer says.

Meyer points out, though, that using anything other than what he terms the "standard" design methodologies, i.e., HDLs, will potentially invite trouble. Even the staunchest defenders of C/C++ feel that it's a difficult language to learn and use well.

"C++ is a difficult language," Krolikoski says. "It's not trivial." Krolikoski, who once taught C programming at the University of Minnesota, found that only 20% of his students fully grasped the notion of object-oriented design. "They could all program in C++, but to really use it right is hard."

John Sanguinetti, chief technical officer and chairman of Forte Design Systems, echoes this sentiment. "A lot of the things I don't like about C++ are mostly due to its complicated nature." Forte offers a macro preprocessor called Cyn++ that eases the task of writing Cynlib-compatible C++ code by abstracting some of the more verbose features of C++ into a set of simple convenient macros. These macros have a strong Verilog flavor to them, making designs written in Cyn++ look extremely familiar to Verilog designers. "It just eases the job," Sanguinetti says. "If you're not a C++ programmer, it makes it a lot more approachable."

Making C++ approachable is a concern for users and vendors alike. This concern manifests itself both in terms of ease of use and methodology. With respect to methodology, it depends on whom a given language targets. For example, Celoxica's HandelC language, essentially a subset of ANSI C with extensions necessary for cleanly designing hardware, is aimed not at ASIC designers, but at FPGA designers. Celoxica's view is that the price/performance ratio for FPGAs has been pushed down to the point where they now represent a viable solution to coprocessor acceleration applications. Still, Celoxica is trying to move the software and hardware design worlds closer together and to apply software design concepts to a behavioral hardware design approach by taking advantage of the inherently sequential nature of C.

"By default, anything written in hardware languages is executed in parallel," says Kjell Torkelsson, director of technology strategy for Celoxica Ltd. "If you want to add sequential constructs, you have to add control logic, usually a finite state machine. This is a significant part of the designer's work, to build the finite state machines to achieve sequentiality. In HandelC, we've turned that around. The default is sequentiality and you add parallelism, which is much easier to do." In addition to a construct for parallelism, HandelC provides variable bit widths on integers.

The idea of approaching hardware design from a basis of sequentiality with the option of imposing parallelism may not sit well with hardware designers who lack a software mindset. In general, HDL junkies don't much care to change their way of life.

Hence, we find the drive in some quarters to take a different tack, to make Verilog more applicable in the system domain. Co-Design Automation's Superlog language is a step in this direction. Superlog is a superset of Verilog (and Verilog2K), with the addition of C programming, system, and verification capabilities.

According to Kelf, Superlog represents an evolutionary approach (see "A Prediction Of Design Language Evolution," p. 56). "Verilog users can adapt extremely easily, evolving up from where they are today," he says. "Getting the hardware engineers and, to a lesser extent, the verification engineers to use C++ means that they must learn a new language. And, of course, all their designs are written in Verilog today. So these guys have an issue with trying to learn a new language and incorporating models written in the old language."

Superlog offers certain capabilities that make it attractive on the system level. For one, Co-Design's Systemsim simulator features CBlend technology that allows the mixing of C, Verilog, and Superlog without the need for a programming language interface (PLI). For another, the language offers powerful design verification capabilities (Fig. 3). Gaining prevalence is a verification technique of blasting random numbers or data at a design in a manner that's constrained to those areas where problems are anticipated. Traditional test benches require writing test vectors that are intended to target specific problems.

This approach is somewhat chancy, as it requires the test bench writer to imbue the vector set with an almost clairvoyant anticipation of where the problems lie. The random methodology allows a general targeting of the vectors with a better chance of actually finding the problem. Superlog provides this capability, as well as a corresponding mechanism for checking functional coverage.

Moreover, Co-Design has been working with Verplex, a formal verification vendor, on incorporating Verplex's Open Verification Library (OVL) into Superlog. The OVL is a set of libraries of assertion-checking primitives that can be written into models, providing very powerful model-checking capabilities that can be closely tied to simulation. Like Superlog, the OVL is Verilog-based.

Both Superlog and the OVL have been donated to the Accellera standards organization. Within Accellera is an HDL+ working group with subcommittees on what's now called Verilog++ and Assertions. The Verilog++ group is working through the Superlog Extended Synthesizable Subset (ESS) manual with the hope that by the spring of 2002, an Accellera standard can be settled. This will be moved forward to the IEEE-1364 Verilog standard committee for ratification as the next revision of that standard. Meanwhile, the Assertions subcommittee is moving forward in similar fashion with the OVL.

Accellera also administers a C/C++ working group under the aegis of its SLDL technical committee. Last year, the C/C++ group was formed to look into the creation and standardization of a semantic model capable of supporting the C/C++ class libraries in today's commercial products. C Level Design has donated CycleC to this group in support of its efforts to come up with a reference manual for semantically defining hardware structures in C and C++.

Interestingly, few if any efforts have been made to extend VHDL as a system-level language. "There's probably some good reason for that," says Ac-cellera chairman Dennis Brophy. For one thing, much of what's proposed in the form of Superlog for the third generation of Verilog actually brings many of the detail capabilities already available in VHDL. For example, enumerated data types have been in the VHDL language for a long time, but they are just now being proposed for third-generation Verilog.

"There are customers out there asking for (VHDL), but it seems like the intellectual energy is going into either C languages, Superlog, or Verilog 2000, for that matter," says David Knapp, chief technical officer at Get2Chip.

Further developments regarding VHDL notwithstanding, it appears that SystemC and Superlog now are the heavyweight contenders in the system-level design space. "The interesting thing is that if you talk to architects, CAD people, or management, they obviously want SystemC to win," says Gary Smith, Gartner Dataquest's chief EDA analyst. "If you talk to engineers, especially Verilog engineers, they want to make as few changes to their life as possible. They're all very conservative. They know that once you get to the RTL, that's going to be Verilog."

Smith wonders if the design community will drive market acceptance of Superlog fast enough to block SystemC. Meanwhile, efforts to resolve the incongruities between existing C++ class libraries, such as the Accellera C++ working group's semantics standardization effort, could influence the outcome.

Regarding emerging system-level languages, watch for Rosetta and SpecC. Rosetta is another Accellera project under the SLDL umbrella (Fig. 4). It provides modeling support for different design domains, employing semantics and syntax appropriate for each. Rosetta provides a collection of interacting domain theories for describing systems facets. Each do-main theory provides a semantic and representational framework for one or more design domains.

"We wanted it to be able to bridge different domains," Brophy explains. "It will have the ability to express a facet of the design. Between facets, you'll have domain bridging capabilities that will allow tools that work in these different environments to actually work together." The language offers rich expressive capabilities in its own right that extend to system-level constraints and assertions. Work on Rosetta is ongoing.

Originally developed at the University of California, Irvine, with sponsorship from Toshiba, Hitachi, and other companies, the SpecC language is a system specification description language based on C. It permits use of the same semantics and syntax to represent specifications in a conceptual system, hardware, software, and, most importantly, intermediate specification and information during hardware/software codesign stages. While support for SpecC has grown, largely through efforts by the SpecC Technology Open Consortium, tool support for the language has lagged.

The key question is where the language spectrum will end up. Although the language purveyors and vendors of associated tools would like us to think we will all use one solution or another, a mix of languages and levels of abstraction will coexist for some time. No C/C++ language advocate is suggesting C/C++ will replace HDLs, or that it even could. Tool support for the high-level language isn't quite here yet, although it's growing. But the fact remains that much can be gained by moving up in abstraction to the system level.