Framing the debate over system-level languages is not as simple as staging a shoot-out between various high-profile contenders for the hearts and minds of designers today. It's true that C/C++, SystemC, SpecC, Handel-C, Superlog, and others are being touted as languages that will carry the day for the system designer, the hardware designer, and the verification guy, simultaneously. But the real question is whether it's feasible—or even desirable—to move to a one-language-fits-all kind of a world.

==Message from our Sponsor==

It's probably safe to say that users are driving the search for an effective system-level design language, and it's also safe to say vendors and universities who have developed and backed one language or another have both pride and potential profits hanging in the balance of the final decision. For the short term, there are too many factors—legacy attitudes and staff, non-interoperable or non-existent tools, and vagueness as to the advantages of one language over another—to declare or even predict a winner. However, the situation in mid-2002 is starting to move, albeit slowly and ponderously, toward something of a resolution, a compromise of sorts between smart, stream-lined system specification languages—that really could do it all given the chance—and the more traditional implementation languages.

David Sonnier has a unique perspective on the system-level language discussion; he comes to his current work in hardware design at Agere Systems (currently being spun off from Lucent Technologies) after an initial career in software development. As Director of Product Architecture for the Processing, Switching, and Aggregation Division, Sonnier sees a situation that's often frustrating and not likely to benefit from quick solutions for the foreseeable future.

Languages, Languages Everywhere
"When I look across all the languages that you could possibly imagine [for system specification], the biggest question is: Does the language meet our needs and does it limit our desire to go anywhere else? Most of the projects I'm responsible for are using C/C++/Java. When we use those languages, we have a huge set of available talents. [Using] any other tools immediately limits our job candidates. [Additionally], a number of our system-modeling tools actually end up in products that we ship to customers. Java or C provides an easy environment to put into these products, so another one of the advantages of using a generic language is that it can be used everywhere." In other words, there is a royalty-free situation with these generic languages that may not be the case in more vendor-specific languages.

But there's more to his decision on language selection than just staffing and familiarity issues. Sonnier says that having a single language for system and hardware design is not realistic today. "Can there be one code for compiling both software and hardware representations [of the system]? We haven't seen [anything] yet compelling enough to convince us to go that route. [In fact], when we write the C/C++ models for a system, we're actually extracting away the hardware models because we want a model that's dramatically smaller and faster in system simulation performance for customers. Even if the hardware was modeled in C [or a C-like language] and compiled, it would still run [too slowly]."

Figure 1:  Working across language environments is the reality today in hardware/software co-design. However, system-level languages can help merge design efforts early in the design process. (Figure courtesy of Celoxica)

Sonnier offers a concrete example: "Say I'm doing a processor instruction pipeline, for instance, needing seven clocks to run. For the architectural performance model, [it's enough to acknowledge] that seven clocks have occurred. But the hardware model has to describe all seven clocks in detail and what happens with each clock. And I'm going to get this same answer [and need to extract away the same hardware model] even if I'm writing in SystemC. If you could get to the point where hardware definition was not just to determine performance—you were not trying to push the hardware technology and how fast the gate runs through the model—then languages like C/C++ might actually be more productive [for hardware specification]. But I'm not convinced that it's good enough yet to remove [the need for separate hardware languages]."

He says that although it might be useful someday to use very high-level languages for hardware design, the challenge of running the design all the way down to the gates is still great. "When you're compiling in silicon, every extra gate ends up costing you dollars in the final product. There's always a drive to optimize hardware real estate and how fast the silicon runs. We're pretty much doing those things successfully in Verilog and a bit of VHDL today—not in C/C++."

With regard to the third leg of product development, verification, Sonnier says, "We're largely using verification languages like e and Vera, although we have written pieces of our verification suite in C++ and Java. One of our verification strategies, for instance, is to create a cycle-accurate Java model and essentially use it as a reference model for C, then type it in and use it with e. So an idea would be to take an e-framework and wrap it in with one piece of Java."

Sonnier says that verifying a processor is "a notoriously difficult thing to do. If you've got an architectural model—and, by the way, this model would prefer to be in Java because I'm shipping it to customers—you either write it in e or end up spending weeks gluing the thing together [if it is in Java]. So, we're stuck using e or Vera. The kind of tool continuity [that would be gained from doing it all in Java] has to come up to the point where the change to that technology gives you a compelling advantage over what you were doing before. By the way, writing in Verilog or VHDL for verification was awful! Vera and e are annoying and painful, but enough better than Verilog and VHDL that they've become adopted. [Similarly], SystemC and Superlog have not proven themselves to be enough better than the current alternatives to deal with the staffing and single-language issues [that they precipitate]."

By most accounts, Sonnier's story is an accurate reflection of today's reality. His teams are using C/C++, Java, Verilog, an odd bit of VHDL here and there, e and/or Vera to complete a design. And, more importantly, Sonnier has not yet seen a compelling argument as to why he should be moving beyond this somewhat kludgey language situation to a more streamlined, less poly-lingual process. He's not ready to use a high-level language specific to system-level design, let alone use that language all the way down to the gate level.

Brave New World
Technology hinges on nothing if not optimism and change. The David Sonnier's of the world may see themselves as the realists, but the evangelizers for the various system-level languages see themselves as the visionaries. It's their job to convince Sonnier and others like him that change will be beneficial in the long run. If and when they succeed, Sonnier may want to call Mike Baird, President of Willamette HDL. Baird is a design consultant and readily speaks across the language spectrum that Agere's Sonnier understands, from HDLs to C/C++. Along with his design work, Baird and his team also teach classes on Verilog, VHDL, SystemC, and Superlog.

Baird says he sees several things pushing his customers into a realization that a SystemC or Superlog-type language would be useful: "The trend is towards executable transaction-level models of a system, which are being used as software development platforms. If system designers have to wait until the hardware's actually developed, it's too late in the process [to meet time-to-market demands]. These models are being used to validate architectural decisions and resource allocations on-chip, particularly in SoC (system-on-chip) designs which are so [heavily dependent on] embedded software. We see wide usage of C++ and SystemC at this level. [In fact], a surprising number of projects today have a methodology that starts with a high-level description of the system."

He says, however, that this trend is not taking away from the usefulness or respect afforded to the HDLs—Verilog and VHDL. "We're not seeing a lot of SystemC versus Verilog, for instance. A project has the hardware guys working in Verilog, but at the same time the project has transaction-level [modeling] in SystemC. Verilog is not fast enough when the intent is for software development. So what's happening now is that the two languages co-exist. It's a transition time."

Baird says that a big part of the current situation revolves around the designer community. "Engineers are always conservative," he says. "It's a leap for them to move to a new language or methodology. There are quite a few C++ savvy people out there. It's not tough for them to do the system modeling. It's harder for the Verilog and VHDL guys. I've talked with several companies on this issue. With the older guys working in Verilog… there's no budging them. So, many companies have system developers using C [type languages] and are also going to great lengths to meet the demands of their HDL designers. The companies say, 'We're comfortable when all of our engineers are comfortable.' The whole thing reminds me of the mid-1980s when people began using the HDLs rather than schematic capture for design. It took a good six-to-eight years before the HDLs [gained wide acceptance]."

One thing companies can do, Baird says, is to encourage the HDL designers to work towards a systems viewpoint via Superlog, a language built from the bottom-up on top of Verilog. "From an RTL designer's point of view, looking up to system-level design, Superlog is very attractive. It does higher level modeling and verification comparable to e and Vera. So you get this appealing migration, an evolutionary path to [system-level] languages rather than a jump [or revolutionary] path."

Alternatively, Baird says there are companies such as Motorola who want to make the jump to SystemC, to take the more revolutionary path. He says, "Motorola is looking at it from an architect's point of view, system designers who are familiar with C/C++. For people coming from that direction who tend to use these languages, SystemC looks very attractive."

Baird says that the increasing use of IP (pre-designed blocks of silicon intellectual-property) is having an impact on the situation as well. "My personal experience with various customers indicates that when the project starts with a platform and the intention to use IP written in C++, SystemC can act as the infrastructure for module simulation. Meanwhile, there are more and more platform-type designs needing more and more verification—upwards of 70% of the effort is in verification. Vera and e exist because Verilog and VHDL can't cut it. Superlog is an attempt to grow [a system-level] language from that direction [and meet verification needs in the process]."

So, again the question—is there one language that can do it all? Baird say, "I think C/C++ comes closest because it's the only one that spans system level, verification, software, RTL design. But spanning across [applications] doesn't necessarily mean it's the best language [for each purpose]." He says, therefore, a set of languages will continue to be used for some time to come, not a single unifying language. "There's kind of an analogy to Verilog and VHDL in the early 1990s. It was hard to translate between VHDL and Verilog. When mixed-language simulators were introduced, it was no longer a problem to have mixed-language projects. So it wouldn't surprise me to continue to have lots of mixed-language projects and tools [in the current environment] using C/C++, SystemC, Verilog, VHDL, Superlog."

	For those attending DAC in New Orleans June 10-15, you'll have an opportunity to attend an all-day tutorial on Friday discussing the plethora of languages in use today. Mike Baird will be one of the presenters.

Throwing the problem back to the EDA vendors, Baird adds, "In a perfect world, you'd have a single language and all the tools you could want. The reality is you'll never have all the tools you need, even if you did have the single best language. Right now, HDL designers are entrenched and aren't going to move very much at all. Where it goes two to three years from now, it's hard to say. In 1985, most designs were done in schematic capture. Nobody saw synthesis coming, but synthesis enabled the HDLs to really take off. Whatever's going to show up [in the next few years] in technology may accelerate the acceptance of a particular language. Tools may end up being a big part of the story."

The Advocates Argue Their Cases
Will Golby and Kjell Torkelsson of Celoxica are avid proponents of Handel-C. Pete Hardee of CoWare, a company closely linked to the history of SystemC, and Dave Kelf of Co-Design Automation, a company similarly linked to the foundations of Superlog, are capable spokesmen for those two languages as well. All of these technologists believe they have the best interests of the designers in mind.

Golby, Vice President for Communications for Celoxica says, "There is confusion [today] about what system-level languages are trying to do. They're not trying to get rid of electrical engineers and make computer science into an engineering discipline. The hardware designers, however, perceive a threat. They see a lot of marketing hype about [these new] languages and [don't understand] that we're trying to help make hardware design a more efficient process."

Torkelsson, Vice President of Engineering at Celoxica says that, before he came to the company, he spent several decades at Ericsson: "I'm a hardware designer and I've been through many [methodology] changes in the past 30 years. Every time there's a significant change introduced, there's fear. Logic synthesis had a hostile audience, but then designers realized that HDLs offered as much detail as a drawing on a screen. Today there's a lot of skepticism about C-based solutions [to design]. Before I used Handel-C [at Ericsson], I was like many people in these HDL user groups. I thought it would cost a lot to use software and move down to hardware. But Handel-C is as efficient as Verilog and VHDL in most cases. You can easily see from the Handel-C code what the resulting hardware's going to be and, within a few weeks of learning, you're in good control of how you write the code. I don't see it as a threat to have a language do a design two to three times faster than my early designs. The old adage that hardware people can't design software discredits the advancements with the tools."

Hardee, Director of Product Marketing at CoWare, says: "Before SystemC was conceived, CoWare had it's own ANSI-C language and our customers had their successes with that. But Guido Arnout (now Chairman of CoWare) and I realized that proprietary languages weren't going to win this game. The fact was that semiconductor houses, IP providers, design houses, the whole design tool chain [in fact] needed more than a proprietary language. We took what we had done in CoWare C and, instead of adding extensions, we added the extensions with Synopsys to C. Interestingly, I've read some articles talking about SystemC that says everyone knows C++. It does have a big following today, but people have also found it syntactically awkward. What people know is C—it's used overwhelmingly today—and they need extensions to use C to deal with system-level design, particularly on the hardware side. You need different ideas of structure; you need to add the concept of time, and to add various data-set extensions that you don't have in ANSI-C."

Kelf, Vice President of Marketing at Co-Design, says: "Development on Superlog started five years ago and was announced at DAC in June 1999. When it was originally developed, [built on Phil Moorby's Verilog], it was seen as a way of linking the worlds of designers, system designers, and verification engineers. Since it was announced, it has been adopted by various EDA companies and end-users including Nortel, Ericsson, Fujitsu, Toshiba and lots of others."

Kelf enumerates what users are looking for in a system language: "Different users actually want different things. It comes down to what design method they're using. Most companies are looking at how to combine hardware and software design at a high level. They need to nail down a methodology whereby system users can do analysis and partitioning of the design, utilizing constraints created at a high level, and then allow for the hardware/software design."

Both Kelf and Hardee agree that having a system-level language, however, is not enough. Hardee says, "System-level design needs a full set of tools as well. That requires some investment [on the part the EDA vendors], which is why companies like Cadence, Synopsys, Mentor, and CoWare are cooperating on SystemC." Along with Kelf, others in EDA are siding with Superlog: "A number of EDA companies have endorsed Superlog, including Get2Chip, Co-Design, Real Intent, and Verplex."

Torkelsson says, "Within Europe the adoption of system tools has moved much faster than in the U.S. Maybe in America, there's a drive to produce product quicker, to move straight to the target. Europeans take more time at the outset to think things through. We are working in cooperation with Ericsson [for instance] to look at XML, C++, Verilog, as well as Handel-C."

For Golby, "The key is experimentation. You have a new type of target architecture in reprogrammable SoCs and FPGAs, for instance, where the embedded system closely links the interaction between the software and the hardware guy. We're providing an environment where that can happen. It's C-like, but the hardware guys can understand."

Combining emerging tools is a part of the experiment. Torkelsson says, "You can define system-level constructs in SystemC and in Handel-C. To evaluate how the algorithm works in your system, you could run part of that in C, part in SystemC, and part in Handel-C. Incremental design is very important."

Setting the Standard
Industry standards bodies are often involved in sorting out forks in the technical roadmap. Dennis Brophy is Chairman of Accellera, built several years ago on the merger of the VHDL International and Open Verilog International standards bodies. He is also Director of Strategic Business Development at Mentor Graphics' Model Technology. Brophy is calm and dispassionate in describing the process currently underway at Accellera for sorting out the current language debates. He's also attempting to keep an open mind about the many offerings currently on the table.

Brophy says, "There's always been a multitude of languages and there always will be. C has an important role in the expression of design and I don't think that's been either accelerated or facilitated by SystemC. Not has it slowed down our language work or work on other languages. Our work is directed at the hardware designers. There's a basic infrastructure in place to designate from concept of hardware to implementation in silicon and that's not going to be easily redone. At Accellera, we do discuss things with our software brethren. They are using C as well as UML, XML—languages that can be used to express design. There will continue to be a multitude of languages at the system level, so [it's difficult to] accept that the move to SystemC will result in one language. SystemC is becoming, in some ways, just another HDL. So now there are three. However, in reality, it doesn't matter what language gets invented. If you're able to deliver a significant advantage over today's technology, it will be used. If it's C or SystemC or Verilog, part of this is immaterial."

Co-Design's Kelf articulates recent efforts to encourage an industry standard based on Superlog: "One of the most significant developments [in the history of Superlog] is that we donated a large subset of the code to Accellera a year ago." At this year's HDL Con, Co-Design and Real Intent announced an additional donation to Accellera—the Superlog Design Assertions language Subset. Kelf says, "This subset is really useful for simulation and model checking and semi-formal verification. Verification tools need design-like properties for assertions checking." These types of donations of code are an important part of the process of converting languages that may be exist as a de facto standard into industry standard.

Meanwhile, to bolster acceptance of SystemC, the Open SystemC Initiative (OSCI) was established, an organization that has generated a lot of press in the last 18 months. Pete Hardee from CoWare serves on the board of OSCI and also as the organization's Secretary and Executive Director. After some highly publicized speed bumps between various founding companies related to how 'open' is 'open'—Hardee says OSCI has earned its stripes of late with the release of SystemC 2.0, a collaboration between member companies on the OSCI board: STMicroelectronics, Fujitsu, Motorola, Cadence, Synopsys, and CoWare. Hardee says, "All the major competitors are coming together to create a very fair and open initiative. The process requires a very good understanding of anti-trust laws and OSCI takes a keen interest in [assuring] that proprietary interests of member [are not compromised]. Our goal is to be declared an IEEE standard within two years and the reference manual is underway."

Additionally, OSCI announced at this year's DATE Conference in Paris a new Internet platform to provide "comprehensive support for the expanding SystemC user community at www.SystemC.org." The availability of this type of support, in combination with open access to the code and compiler is, according to some reports, allowing SystemC to make headway in user communities, particularly among academics and European system houses who are working to explore the design opportunities offered within SystemC.

Celoxica's Golby warns, however: "[We're] talking about productivity tools that drive an industry. It's not about consumerism. I would like to think that every company is acting in the interests of the users in driving standards. Because a language is easy to get hold of, does not mean that users will take the path of least resistance. At the end of the day, the customers are going to make the [right] decisions."

Academically Speaking
Academic venues can offer a different evolutionary path for system-level language development than those available in a for-profit commercial setting. Researchers at the University of California, Irvine, have been considering the challenges of system design since the late 1980s and introduced a system-level language layered on top of VHDL in 1989. When Toshiba offered UCI funding in the mid-90s to develop a whole new design technology, the team reconsidered their HDL-based language strategy and moved instead to a C-based language approach. The UCI SpecC language was introduced in 1995 with the intention of matching the growing demands that software development occur in conjunction with hardware design. Based on their extensive research into synthesis, verification, and other aspects of hardware development, the UCI team felt that their language provided a robust bridge across the two domains of software and hardware.

	Confused by all the system-level and other languages people use for developing their chips? You're not alone! Here's a handy table to help you deal with the design-language Tower of Babel.

Professor Daniel Gajski of the UCI faculty says that after several years of refining SpecC, "The whole thing was finished in 2000 and many companies, including Toshiba, decided that it was so good that they didn't want to pass up [the opportunity]. They created the SpecC Technology Open Consortium and [today] there are over 50 companies and universities trying to establish SpecC as the universal language for system design. Members of the consortium hope to streamline the design process from high-level specifications all the way down to manufacturing, using one common language."

Gajski says that SpecC is a highly promising candidate in a crowded field of system-level language contenders. He adds that one of the strengths of the language is the completely open nature of the code: "SpecC is open source under BSD license. You can use the source code and do anything you want. You can sell it, upgrade it, and you don't have to report [back to us]. The only thing you have to do is to acknowledge the copyright of UCI." Gajski says that the freedom to work with SpecC offers an advantage over the licensing restrictions that exist in the fine print of some of the commercially available languages.

On the technical side, he says SpecC is superior as well. He argues that SystemC, for instance, is riddled with too much of a good thing. "It was built on top of C++ by incorporating many different concepts into C++ classes, [but it became] too complicated for synthesis and verification. SpecC has a minimal set of orthogonal concepts. System specification, architecture, communication, RTL are all uniquely described with well-defined semantics, so it's easy to do synthesis and verification."

Today Gajski and the SpecC Consortium are faced with convincing commercial users of the worth of the language. "Young students at the universities want to do something and they realize that SpecC is superior. Unfortunately, no EDA vendors are behind it because they believe SystemC will solve their problems. They [the EDA vendors] do not fully understand embedded software requirements and the development process."

As such, Gajski believes the vendors do not appreciate the problems presented by the complexities within SystemC or the elegance offered by the SpecC language. Similarly, the tools offered by the EDA vendors restrict system designers. If tools do not emerge that work with SpecC, there will an uphill battle to achieve acceptance for the language.

Gajski acknowledges that Superlog is an intelligent option for hard-core HDL designers and that UML is a good concept at high levels of abstraction. However, he is adamant in his convictions that, in the long run, SpecC will meet the needs of the design process from the initial specification all the way down to the manufacturing phase.

Gajski would like to see the user community and the EDA vendors fund a public demonstration of the effectiveness of the system languages under consideration today—languages such as SpecC, SystemC, Handel-C, and Superlog. He says the challenge would be to do a real design and see how it works—to have a number of different teams, several in Japan, several in the U.S., and several in Europe as well, attack a well-defined problem with the different languages. He says that would go a long way towards eliminating the guesswork now required of the system houses in choosing which language to standardize on.

In the End
In the era of deep-submicron multi-million gate designs, smoothing the transition from system-level specifications to implementation and manufacture are real—as are the debates over the proper languages needed to address that integration. Alan Naumann, newly appointed President and CEO at CoWare, says: "The issue today is how to put complex systems on silicon and the SoC is the ultimate [challenge]. In my opinion, it seems like there are two main camps [with proposals on the table]—those that believe that fixing software and implementation is [critical] versus those who want to see incremental changes to the HDLs."

Brophy says, "From the EDA companies to the design companies, everybody would love to have their [own] stuff become the standard. It's almost a mine field that we have to walk through at times.[However], it's the end users who are guiding and running this [process] and who are keeping all of us on our toes."

Brophy adds, "We recognize that the architects of systems don't want one for hardware and one for software. Still, it's a little early to say that you'll reach Nirvana if you use one language which will automatically assign hardware/software and meet constraints optimally."

It looks like, for the next few years at least, it won't be "Shoot-out at the OK Corral" with only one language left standing in the end. It's more likely to be the final scene from Casablanca—languages like modified HDLs and C-like dialects walking off into the mist and contemplating "The start of a beautiful friendship." Now, if we could just get the software and hardware guys to take the hint.