Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

SystemVerilog won't kill 'e' language

Posted: 02 Jan 2006 ?? ?Print Version ?Bookmark and Share

Keywords:richard goering? e? systemverilog? verification language? ieee p1647?

Some EDA vendors and many users think SystemVerilog will kill specialized verification languages. But backers of Cadence Design Systems Inc.'s "e" language, which is nearing IEEE standardization, say that rumors of the language's death are exaggerated.

The "e" language moved a step closer to standardization when an internal round of balloting overwhelmingly approved IEEE P1647. Full standardization is expected in March, opening the door, advocates say, for the kind of widespread support among tool vendors that Verilog now enjoys.

But the new SystemVerilog language has verification constructs, assertions and testbench automation features, causing many to see a bleak future for languages like "e" and Synopsys' Vera. In a "trip report" that surveyed 338 engineers following the last Design and Verification Conference (DVCon), published recently by industry critic John Cooley, 78 percent of the respondents said that specialized functional verification languages will be dead within five years.

It's a battle of numbers on both sides. Karen Bartleson, director of interoperability for Synopsys, noted that more than 75 products and services supporting SystemVerilog have already been announced. There is scant EDA vendor support for "e" outside of Cadence, which, early last year, bought Verisity, originator of the "e" language and associated Specman testbench automation tools.

But Verisity veteran Steve Glaser, now VP of marketing for Cadence's verification division, disagrees, citing 15,000 Specman licenses, more than 300 corporate customers, an estimated 50 million lines of "e" code and over 500 verification intellectual-property (VIP) components. "We fully expect large EDA vendors to support 'e' sometime in the future," Glaser said. "We expect, because there's real business demand, that many 'e'-based tools will emerge from this IEEE standard."

Differing views
It doesn't appear that Mentor Graphics Corp. will be one of the supporters. "SystemVerilog is the industry-standard verification language," said Robert Hum, VP for design, verification and test at Mentor. "We share the opinion of John Cooley's verification survey, which indicated that there isn't a future for 'e' or Vera."

Synopsys' Bartleson said, "Broad industry support is lagging for a language that offers a subset of SystemVerilog capabilities. It is not clear that standardization of 'e' will have any positive market impact." But Synopsys will continue to support Vera, she said, even though many of its capabilities have been integrated into SystemVerilog.

The point that's being missed, said Gary Smith, chief EDA analyst at Gartner Dataquest, is that "e" and SystemVerilog are different languages working at different levels. While SystemVerilog is an RTL language, he said, "e" is an ESL verification language whose only real competition is the SystemC verification class library initiated by Cadence.

"Verisity's competitors pretty much stopped their SystemC effort in favor of SystemVerilog," Smith said. "Instead of listening to their power-user customers, they bought into the SystemVerilog hype and now they're a day late and a dollar short."

Still, said Specman user Darren Galpin, senior verification engineer at Infineon Technologies AG, it's not an either/or situation. "What is easier to do in SystemVerilog will be done in SystemVerilog, and what is easier to do in 'e' will be done in 'e,'" he said. Galpin noted that SystemVerilog requires more code to achieve the same functions that "e" does and that it doesn't have aspect orientation, a feature of "e" that makes reuse easier.

Cadence is in the interesting position of supporting both "e" and SystemVerilog. Last October, in fact, the company rolled out its SystemVerilog-based Incisive Design Team family. But "e" and SystemVerilog are different languages with different heritages, addressing different groups of users, Glaser said.

The "e" language, which Verisity brought before the IEEE in 2003, was initially used for specification-driven verification for both software and hardware, Glaser noted. It thus allows users to describe system requirements, create a variety of "system scenarios," run verification and compile metrics along the way. Users can generate hierarchical groups of transactions called "sequences" in a very natural way, he said.

Some customers use "e" for combined hardware and software verification, Glaser said. But they also use it at the RTL "for unit, cluster or IP verification when it's required to be in a system and spec-driven context." Yes, there's some overlap with SystemVerilog, he said, but that's not a bad thing. "Overlap is healthy because it allows different parts of the flow and methodology to come together nicely," he said.

For people doing RTL verification who need more automation, SystemVerilog is a "perfect answer," Glaser said. Cadence's Incisive strategy is to target different groups with different languages. The SystemVerilog-based Design Team family targets RTL designers, while the Enterprise family, which supports "e" and other languages, targets verification teams and multispecialist, SoC design teams.

So why the pessimism in the DVCon trip report? It's because most respondents were RTL designers, not project teams tackling the most complex SoCs, Glaser said. "It's a typical profile of the masses being polled," he said. "It's a skewed picture. If you look at where the biggest projects and the most risk are, you'd get a skewed picture toward 'e' being critical forever."

Outside support
For "e" to become a true industry standard, it needs support from vendors other than Cadence. But "e" language tools and third-party IP are just beginning to emerge.

Amiq Consulting in Romania offers EParser, an "e" language parser that EDA vendors or in-house design groups can use to build "e" language tools. Cristian Amitroaie, Amiq Consulting's founder, noted that IEEE standardization will make the language open, prove it to be mature and increase customer confidence in what is no longer a "proprietary" language.

"As consultants for verification projects, we've seen it ['e'] working," Amitroaie said. "It solves real problems. It is a mature language."

Globetech Solutions in Greece offers "e"-based verification IP, including peripheral, storage and design-for-test components. "We are seeing a lot of companies that, prior to the standardization process, were hesitant about adopting 'e'-based solutions due to their proprietary nature, but are now beginning to reformulate their strategies," said Stylianos Diamantidis, managing director.

Diamantidis added, however, that "we expect that, in the short term, SystemVerilog will slow down 'e' somewhat, as people digest its merits."

It's hard to tell exactly who is behind the IEEE standardization effort, given that the P1647 committee consists of individuals voting on their own, as opposed to the "one company, one vote" policy used by working groups that adhere to the IEEE's corporate-standards process. But Glaser insisted that the working group represents a diverse crew, including academics and many users of the "e" language.

- Richard Goering
EE Times

Article Comments - SystemVerilog won't kill 'e' languag...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top