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

Language standards from IEEE open choices

Posted: 01 Feb 2006 ?? ?Print Version ?Bookmark and Share

Keywords:richard goering? cadence design system? accellera? systemc? systemverilog?

Once seen as potentially competitive, SystemC and SystemVerilog languages appear to be settling into largely complementary niches.

SystemVerilog became the ieee 1800 standard in November, while SystemC became IEEE 1666 in December. Before submission to the IEEE, SystemVerilog was extensively developed by the Accellera standards organization, just as SystemC was nurtured by Open SystemC International (osci). SystemC already enjoys widespread tool support, while SystemVerilog tool support is just emerging.

Observers say IEEE standardization will overcome remaining customer resistance to both languages, spur tool development and generally accelerate adoption. But users should be aware that IEEE 1800 is not identical to Accellera's SystemVerilog 3.1a specification, nor is IEEE 1666 the same as the OSCI's SystemC 2.1 spec.

"There's a lot of value in having a formal standard from the IEEE," said Victor Berman, chair of the IEEE 1666 working group and group director of language standards at Cadence Design Systems Inc. The IEEE, he said, brings stability, makes sure the standardization process is open, and allows a specification to be widely reviewed.

OSCI chairman Alain Clouard said some companies that have been hesitant to adopt SystemC will do so now with the assurance of a "robust, stable standard" from the IEEE. Going forward, the final reference for SystemC will be the IEEE 1666 Standard Language Reference Manual (LRM), not the OSCI SystemC simulator, he noted.

The LRM is important to SystemC users such as Greg Tumbush, digital design engineer at the Starkey Colorado IC Design Center. "IEEE standardization will ensure that all tools interpret SystemC in the same way," he said. "The LRM will help make this a reality."

Furthermore, said Jack Donovan, chair of the North American SystemC User's Group, IEEE standardization of SystemC will help engineering teams get the blessing of the corporate entities they work for.

The IEEE standardization process for SystemC took only eight months and involved few changes from the OSCI 2.1 specification, Berman said. Still, he noted that some design automation vendors that support SystemC 2.1 "might have some work to do" to fully comply with IEEE 1666. For one thing, he said, semantic rules were strengthened, so error conditions can be more carefully defined.

But Berman, who also serves as Cadence's representative on the IEEE 1800 SystemVerilog working group, said that IEEE 1800 is actually "quite a bit different" from Accellera's SystemVerilog 3.1a. There were changes involving the integration of the testbench, assertions and rtl portions of the language, he said, along with the addition of intellectual-property (IP) encryption to IEEE 1364 Verilog, which is contained within SystemVerilog.

Accellera co-chair Dennis Brophy said that the changes made to SystemVerilog 3.1a do not reflect "substantial" additions, but he acknowledged that EDA vendors will have some work to do to fully comply with IEEE 1800. For one thing, they will need to comply with the new IEEE 1364-2005 version of the base Verilog language, which includes IP encryption.

IEEE standardization does not, of course, tell the user which language to use. But advocates of both SystemC and SystemVerilog now say the languages are complementary, with SystemC used primarily for high-level modeling and fast simulation, and SystemVerilog for RTL verification and design.

It wasn't always that way. When SystemC was first proposed, some backers saw it as a design implementation language that would ultimately replace VHDL and Verilog, moving designers from RTL to ESL design. Things didn't happen that way. There was, in fact, a strong backlash from RTL designers, who filled forums such as the E-Mail Synopsys Users Group (ESNUG) with diatribes against C-language design.

Things are calmer now. In a recent ESNUG "trip report" that surveyed attendees of the Design and Verification Conference, 42 percent of respondents said they expect to use SystemC in the coming months. Asked what for, 70 percent said high-level modeling, 62 percent said verification and only 7 percent said design.

In the same report, 19 percent of respondents said they plan to use SystemVerilog. Seventy percent of the SystemVerilog users said they will use it for verification, 5 percent for design and 26 percent for both. This survey, it should be noted, largely involved verification engineers.

"In the past, customers asked whether they should use SystemC or SystemVerilog, but a lot of them are adopting both," said Rindert Schutten, director of system-level solutions at Synopsys Inc. "SystemC is more focused on architectural modeling and early software integration, while SystemVerilog comes in when customers move to RTL design."

OSCI's Clouard said the primary uses for SystemC today are transaction-level modeling (TLM) and embedded-software testing, with architectural modeling less frequently deployed. "What I saw in production first was the functional-verification teams, who were quick to use algorithmic models as reference models in the testbench," he said.

But Cadence's Berman said that SystemC is now mostly used for architectural modeling and he sees a shift away from verification. "Initially, that verification was a strong point, but I see that being de-emphasized, now that we have good solutions with 'e' and SystemVerilog for that space." This, Berman said, is one reason the IEEE didn't standardize the SystemC Verification Library, which brings a testbench capability to SystemC.

There is, in fact, some overlap in verification. Both languages can be used for TLM, but SystemC is generally regarded as more advanced, with a TLM 1.0 specification now available from OSCI. Based on the familiar Verilog language, SystemVerilog brings in support for assertions and constrained-random stimulus generation.

An increasing number of simulation environments, such as Mentor Graphics Corp.'s Questa tool, support both SystemC and SystemVerilog.

The point of connection is the SystemVerilog Direct Programming Interface (DPI), which can bring in C-language or SystemC models. In fact, said Brophy, work at OSCI helped shape Accellera's development of the DPI. "We understood SystemC objects would need to work in concert with SystemVerilog objects," he said.

What's really needed now, said Berman, is a "bridge" between SystemC and SystemVerilog through TLM models. These, he said, could provide a standard way to transition from architectural to RTL models. "People are doing this now, but not in a standard way," he said.

- Richard Goering
EE Times

Article Comments - Language standards from IEEE open ch...
*? 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