"In this Corner…"—The Battle for System-Level Language Supremacy - Embedded.com

“In this Corner…”—The Battle for System-Level Language Supremacy


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

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

David Sonnier has a unique perspective on the system-levellanguage discussion; he comes to his current work in hardwaredesign at Agere Systems (currently being spun off from LucentTechnologies) 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 oftenfrustrating and not likely to benefit from quick solutions for theforeseeable future.

Languages, Languages Everywhere
“When I look across all the languages that you could possiblyimagine [for system specification], the biggest question is: Doesthe language meet our needs and does it limit our desire to goanywhere else? Most of the projects I'm responsible for are usingC/C++/Java. When we use those languages, we have a huge set ofavailable talents. [Using] any other tools immediately limits ourjob candidates. [Additionally], a number of our system-modelingtools actually end up in products that we ship to customers. Javaor C provides an easy environment to put into these products, soanother one of the advantages of using a generic language is thatit can be used everywhere.” In other words, there is a royalty-freesituation with these generic languages that may not be the case inmore vendor-specific languages.

But there's more to his decision on language selection than juststaffing and familiarity issues. Sonnier says that having a singlelanguage for system and hardware design is not realistic today.”Can there be one code for compiling both software and hardwarerepresentations [of the system]? We haven't seen [anything] yetcompelling enough to convince us to go that route. [In fact], whenwe write the C/C++ models for a system, we're actually extractingaway the hardware models because we want a model that'sdramatically smaller and faster in system simulation performancefor customers. Even if the hardware was modeled in C [or a C-likelanguage] and compiled, it would still run [too slowly].”

Figure 1:  Working across language environments is the reality today inhardware/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 processorinstruction pipeline, for instance, needing seven clocks to run.For the architectural performance model, [it's enough toacknowledge] that seven clocks have occurred. But the hardwaremodel has to describe all seven clocks in detail and what happenswith each clock. And I'm going to get this same answer [and need toextract away the same hardware model] even if I'm writing inSystemC. If you could get to the point where hardware definitionwas not just to determine performance—you were not trying topush the hardware technology and how fast the gate runs through themodel—then languages like C/C++ might actually be moreproductive [for hardware specification]. But I'm not convinced thatit's good enough yet to remove [the need for separate hardwarelanguages].”

He says that although it might be useful someday to use veryhigh-level languages for hardware design, the challenge of runningthe design all the way down to the gates is still great. “Whenyou're compiling in silicon, every extra gate ends up costing youdollars in the final product. There's always a drive to optimizehardware real estate and how fast the silicon runs. We're prettymuch doing those things successfully in Verilog and a bit of VHDLtoday—not in C/C++.”

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

Sonnier says that verifying a processor is “a notoriouslydifficult thing to do. If you've got an architecturalmodel—and, by the way, this model would prefer to be in Javabecause I'm shipping it to customers—you either write it ine or end up spending weeks gluing the thing together [if itis in Java]. So, we're stuck using e or Vera. The kind oftool continuity [that would be gained from doing it all in Java]has to come up to the point where the change to that technologygives 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 thanVerilog and VHDL that they've become adopted. [Similarly], SystemCand Superlog have not proven themselves to be enough better thanthe current alternatives to deal with the staffing andsingle-language issues [that they precipitate].”

By most accounts, Sonnier's story is an accurate reflection oftoday's reality. His teams are using C/C++, Java, Verilog, an oddbit of VHDL here and there, e and/or Vera to complete adesign. And, more importantly, Sonnier has not yet seen acompelling argument as to why he should be moving beyond thissomewhat kludgey language situation to a more streamlined, lesspoly-lingual process. He's not ready to use a high-level languagespecific to system-level design, let alone use that language allthe way down to the gate level.

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

Baird says he sees several things pushing his customers into arealization that a SystemC or Superlog-type language would beuseful: “The trend is towards executable transaction-level modelsof a system, which are being used as software developmentplatforms. If system designers have to wait until the hardware'sactually developed, it's too late in the process [to meettime-to-market demands]. These models are being used to validatearchitectural decisions and resource allocations on-chip,particularly in SoC (system-on-chip) designs which are so [heavilydependent on] embedded software. We see wide usage of C++ andSystemC at this level. [In fact], a surprising number of projectstoday have a methodology that starts with a high-level descriptionof the system.”

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

Baird says that a big part of the current situation revolvesaround the designer community. “Engineers are always conservative,”he says. “It's a leap for them to move to a new language ormethodology. There are quite a few C++ savvy people out there. It'snot tough for them to do the system modeling. It's harder forthe Verilog and VHDL guys. I've talked with several companies onthis issue. With the older guys working in Verilog… there'sno budging them. So, many companies have system developers using C[type languages] and are also going to great lengths to meet thedemands of their HDL designers. The companies say, 'We'recomfortable when all of our engineers are comfortable.' The wholething reminds me of the mid-1980s when people began using the HDLsrather 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 HDLdesigners to work towards a systems viewpoint via Superlog, alanguage built from the bottom-up on top of Verilog. “From an RTLdesigner's point of view, looking up to system-level design,Superlog is very attractive. It does higher level modeling andverification comparable to e and Vera. So you get thisappealing migration, an evolutionary path to [system-level]languages rather than a jump [or revolutionary] path.”

Alternatively, Baird says there are companies such as Motorolawho want to make the jump to SystemC, to take the morerevolutionary path. He says, “Motorola is looking at it from anarchitect's point of view, system designers who are familiar withC/C++. For people coming from that direction who tend to use theselanguages, SystemC looks very attractive.”

Baird says that the increasing use of IP (pre-designed blocks ofsilicon intellectual-property) is having an impact on the situationas well. “My personal experience with various customers indicatesthat when the project starts with a platform and the intention touse IP written in C++, SystemC can act as the infrastructure formodule simulation. Meanwhile, there are more and more platform-typedesigns needing more and more verification—upwards of 70% ofthe effort is in verification. Vera and e exist becauseVerilog and VHDL can't cut it. Superlog is an attempt to grow [asystem-level] language from that direction [and meet verificationneeds in the process].”

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

For those attending DAC in New Orleans June10-15, you'll have an opportunity to attend an all-day tutorial onFriday discussing the plethora of languages in use today. MikeBaird will be one of the presenters.

Throwing the problem back to the EDA vendors, Baird adds, “In aperfect world, you'd have a single language and all the tools youcould want. The reality is you'll never have all the tools youneed, even if you did have the single best language. Right now, HDLdesigners 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. In1985, most designs were done in schematic capture. Nobody sawsynthesis coming, but synthesis enabled the HDLs to really takeoff. Whatever's going to show up [in the next few years] intechnology 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. PeteHardee of CoWare, a company closely linked to the history ofSystemC, and Dave Kelf of Co-Design Automation, a company similarly linkedto the foundations of Superlog, are capable spokesmen for those twolanguages as well. All of these technologists believe they have thebest interests of the designers in mind.

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

Torkelsson, Vice President of Engineering at Celoxica says that,before he came to the company, he spent several decades atEricsson: “I'm a hardware designer and I've been through many[methodology] changes in the past 30 years. Every time there's asignificant change introduced, there's fear. Logic synthesis had ahostile audience, but then designers realized that HDLs offered asmuch detail as a drawing on a screen. Today there's a lot ofskepticism about C-based solutions [to design]. Before I usedHandel-C [at Ericsson], I was like many people in these HDL usergroups. I thought it would cost a lot to use software and move downto hardware. But Handel-C is as efficient as Verilog and VHDL inmost cases. You can easily see from the Handel-C code what theresulting hardware's going to be and, within a few weeks oflearning, you're in good control of how you write the code. I don'tsee it as a threat to have a language do a design two to threetimes faster than my early designs. The old adage that hardwarepeople can't design software discredits the advancements with thetools.”

Hardee, Director of Product Marketing at CoWare, says: “BeforeSystemC was conceived, CoWare had it's own ANSI-C language and ourcustomers had their successes with that. But Guido Arnout (nowChairman of CoWare) and I realized that proprietary languagesweren't going to win this game. The fact was that semiconductorhouses, IP providers, design houses, the whole design tool chain[in fact] needed more than a proprietary language. We took what wehad done in CoWare C and, instead of adding extensions, we addedthe extensions with Synopsys to C. Interestingly, I've read somearticles talking about SystemC that says everyone knows C++. Itdoes have a big following today, but people have also found itsyntactically awkward. What people know is C—it's usedoverwhelmingly today—and they need extensions to use C to dealwith system-level design, particularly on the hardware side. Youneed different ideas of structure; you need to add the concept oftime, and to add various data-set extensions that you don't have inANSI-C.”

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

Kelf enumerates what users are looking for in a system language:”Different users actually want different things. It comes down towhat design method they're using. Most companies are looking at howto combine hardware and software design at a high level. They needto nail down a methodology whereby system users can do analysis andpartitioning of the design, utilizing constraints created at a highlevel, 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 afull set of tools as well. That requires some investment [on thepart the EDA vendors], which is why companies like Cadence,Synopsys, Mentor, and CoWare are cooperating on SystemC.” Alongwith Kelf, others in EDA are siding with Superlog: “A number of EDAcompanies have endorsed Superlog, including Get2Chip, Co-Design,Real Intent, and Verplex.”

Torkelsson says, “Within Europe the adoption of system tools hasmoved much faster than in the U.S. Maybe in America, there's adrive to produce product quicker, to move straight to the target.Europeans take more time at the outset to think things through. Weare working in cooperation with Ericsson [for instance] to look atXML, C++, Verilog, as well as Handel-C.”

For Golby, “The key is experimentation. You have a new type oftarget architecture in reprogrammable SoCs and FPGAs, for instance,where the embedded system closely links the interaction between thesoftware and the hardware guy. We're providing an environment wherethat can happen. It's C-like, but the hardware guys canunderstand.”

Combining emerging tools is a part of the experiment. Torkelssonsays, “You can define system-level constructs in SystemC and inHandel-C. To evaluate how the algorithm works in your system, youcould 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 forksin the technical roadmap. Dennis Brophy is Chairman of Accellera, built several years ago on the mergerof the VHDL International and Open Verilog International standardsbodies. He is also Director of Strategic Business Development at MentorGraphics' Model Technology. Brophy is calm and dispassionate indescribing the process currently underway at Accellera for sortingout the current language debates. He's also attempting to keep anopen mind about the many offerings currently on the table.

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

Co-Design's Kelf articulates recent efforts to encourage anindustry standard based on Superlog: “One of the most significantdevelopments [in the history of Superlog] is that we donated alarge subset of the code to Accellera a year ago.” At this year'sHDL Con, Co-Design and Real Intent announced an additional donationto Accellera—the Superlog Design Assertions language Subset.Kelf says, “This subset is really useful for simulation and modelchecking and semi-formal verification. Verification tools needdesign-like properties for assertions checking.” These types ofdonations of code are an important part of the process ofconverting languages that may be exist as a de facto standard intoindustry standard.

Meanwhile, to bolster acceptance of SystemC, the Open SystemCInitiative (OSCI) was established, an organization that hasgenerated a lot of press in the last 18 months. Pete Hardee fromCoWare serves on the board of OSCI and also as the organization'sSecretary and Executive Director. After some highly publicizedspeed bumps between various founding companies related to how'open' is 'open'—Hardee says OSCI has earned its stripes oflate with the release of SystemC 2.0, a collaboration betweenmember companies on the OSCI board: STMicroelectronics, Fujitsu,Motorola, Cadence, Synopsys, and CoWare. Hardee says, “All themajor competitors are coming together to create a very fair andopen initiative. The process requires a very good understanding ofanti-trust laws and OSCI takes a keen interest in [assuring] thatproprietary interests of member [are not compromised]. Our goal isto be declared an IEEE standard within two years and the referencemanual is underway.”

Additionally, OSCI announced at this year's DATE Conference inParis a new Internet platform to provide “comprehensive support forthe expanding SystemC user community at www.SystemC.org.”The availability of this type of support, in combination with openaccess to the code and compiler is, according to some reports,allowing SystemC to make headway in user communities, particularlyamong academics and European system houses who are working toexplore the design opportunities offered within SystemC.

Celoxica's Golby warns, however: “[We're] talking aboutproductivity tools that drive an industry. It's not aboutconsumerism. I would like to think that every company is acting inthe interests of the users in driving standards. Because a languageis easy to get hold of, does not mean that users will take the pathof least resistance. At the end of the day, the customers are goingto make the [right] decisions.”

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

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

Professor Daniel Gajski of the UCI faculty says that afterseveral years of refining SpecC, “The whole thing was finished in2000 and many companies, including Toshiba, decided that it was sogood that they didn't want to pass up [the opportunity]. Theycreated the SpecCTechnology Open Consortium and [today] there are over 50companies and universities trying to establish SpecC as theuniversal language for system design. Members of the consortiumhope to streamline the design process from high-levelspecifications all the way down to manufacturing, using one commonlanguage.”

Gajski says that SpecC is a highly promising candidate in acrowded field of system-level language contenders. He adds that oneof the strengths of the language is the completely open nature ofthe code: “SpecC is open source under BSD license. You can use thesource 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 haveto do is to acknowledge the copyright of UCI.” Gajski says that thefreedom to work with SpecC offers an advantage over the licensingrestrictions that exist in the fine print of some of thecommercially available languages.

On the technical side, he says SpecC is superior as well. Heargues that SystemC, for instance, is riddled with too much of agood thing. “It was built on top of C++ by incorporating manydifferent concepts into C++ classes, [but it became] toocomplicated for synthesis and verification. SpecC has a minimal setof orthogonal concepts. System specification, architecture,communication, RTL are all uniquely described with well-definedsemantics, so it's easy to do synthesis and verification.”

Today Gajski and the SpecC Consortium are faced with convincingcommercial users of the worth of the language. “Young students atthe universities want to do something and they realize that SpecCis superior. Unfortunately, no EDA vendors are behind it becausethey believe SystemC will solve their problems. They [the EDAvendors] do not fully understand embedded software requirements andthe development process.”

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

Gajski acknowledges that Superlog is an intelligent option forhard-core HDL designers and that UML is a good concept at highlevels of abstraction. However, he is adamant in his convictionsthat, in the long run, SpecC will meet the needs of the designprocess from the initial specification all the way down to themanufacturing phase.

Gajski would like to see the user community and the EDA vendorsfund a public demonstration of the effectiveness of the systemlanguages under consideration today—languages such as SpecC,SystemC, Handel-C, and Superlog. He says the challenge would be to do areal design and see how it works—to have a number of differentteams, several in Japan, several in the U.S., and several in Europeas well, attack a well-defined problem with the differentlanguages. He says that would go a long way towards eliminating theguesswork now required of the system houses in choosing whichlanguage to standardize on.

In the End
In the era of deep-submicron multi-million gate designs, smoothingthe transition from system-level specifications to implementationand manufacture are real—as are the debates over the properlanguages needed to address that integration. Alan Naumann, newlyappointed President and CEO at CoWare, says: “The issue today ishow 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 fixingsoftware and implementation is [critical] versus those who want tosee 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 attimes.[However], it's the end users who are guiding and runningthis [process] and who are keeping all of us on our toes.”

Brophy adds, “We recognize that the architects of systems don'twant one for hardware and one for software. Still, it's a littleearly to say that you'll reach Nirvana if you use one languagewhich will automatically assign hardware/software and meetconstraints 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 standingin the end. It's more likely to be the final scene fromCasablanca —languages like modified HDLs and C-likedialects walking off into the mist and contemplating “The start ofa beautiful friendship.” Now, if we could just get the software andhardware guys to take the hint.

About the Author
Peggy Aycinena is a freelance technologywriter based in Silicon Valley.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.