When the topic of design languages comes up, most industry veterans think back to the "language wars" of the late 1980s and early 1990s. Back then, VHDL and Verilog vied for dominance, with numerous other proprietary hardware description languages (HDLs) nipping at their heels.
Verilog, created by Phil Moorby at Gateway Design Automation in the mid-1980s, saw its growth spurred by the availability of Gateway's simulator and by Synopsys' 1988 introduction of logic synthesis as embodied in Design Compiler.
But after Cadence acquired Gateway in late 1989, Cadence found its dominance in logic simulation threatened by VHDL. Verilog was proprietary, while VHDL was open source, and competitors began pushing VHDL for IEEE standardization to break Cadence's stranglehold on logic simulation. The company responded by founding Open Verilog International (OVI) in 1991, to which it donated the Verilog language reference manual. OVI, in turn, guided Verilog through IEEE standardization (IEEE-1364) in 1995. The war was over, Verilog had won, and it remains the dominant HDL to this day.
When Cadence opened up Verilog to short-circuit widespread adoption of VHDL, design sizes were on the order of 10,000 to 20,000 gates. Today, of course, 20,000 gates aren't even blinked at in the context of a 20-million-gate SoC behemoth.
With the SoC revolution of the late 1990s, the question of moving up in abstraction from RTL became more pressing. To a large degree, complexity drives the evolution of design languages. SoCs brought a new emphasis on platform-based design. While the software that runs on those SoCs is written in C/C++, that language is a poor choice for hardware design due to its native inability to express timing and parallelism. But the addition of class libraries to C/C++ to express hardware constructs and parallelism made for variants that stretched C/C++ into service as an electronic system-level (ESL) language.
Out of the notion of marrying hardware and software design in a single language, SystemC was born. In the interim, Verilog itself has sprouted a new branch called SystemVerilog. Initially, the pair spawned concerns of new language wars. But these fears faded as System C, SystemVerilog, and standalone verification languages like Verisity's (now Cadence's) e and Synopsys' Vera (since incorporated into SystemVerilog) began to settle into their respective roles in the design and verification processes.
"Where there once were 'language wars,' languages aren't really the focal point today," says Robert Hum, vice president and general manager of Mentor Graphics' Design Verification and Test Division. "The battle is over how to get the fewest functional errors at the end of the process. Languages alone won't solve it. Methodology enhancements are the answer."
The key lesson learned by the EDA industry from the language wars was that adoption of languages is driven by standards. Designers want and need interoperability and design flows that work with them and not against them. To that end, the user community, EDA vendors, standards organizations such as Accellera, and the IEEE have worked together to create a set of language standards that meets the demands of designers today and into the future.
In the platform-based SoC design age, software now plays a greater role in system design than ever before. It's become essential that design flows support early development of software, from drivers and diagnostics to application code. Further, there must be integration with existing C/C++ software code and facilitation of hardware/software co-design. Finally, today's design flows and languages must support system-level IP delivery and integration.
After Verilog and VHDL traversed the IEEE's standardization process, the organizations that had nurtured them—Open Verilog International and VHDL International—merged to form Accellera. Accellera has been a driving force behind Verilog's development and the rise of SystemVerilog. SystemVerilog, itself in the midst of the IEEE standardization process, is the subject of the IEEE's P1800 working group. By the time this article is published, that working group should have announced the release of the first valid version of the SystemVerilog Language Reference Manual. It'll also be out for balloting by then. "That's a big milestone on the way to standardization," says Victor Berman, director of language standards at Cadence.
SystemVerilog is built on the foundation of the 1995 and 2001 versions of Verilog (Fig. 1). A big push toward development of the language came when Co-Design Automation (since acquired by Synopsys) developed the Superlog language, which it donated to Accellera for incorporation into Verilog.
Superlog brought some features to Verilog that were important for IP communications, namely its Communications Interfaces constructs. These features lend themselves to functional simulation at a higher level of abstraction than RTL.
"As we at Co-Design came up with the Superlog idea, SystemC was being rolled out," says Dave Kelf, formerly of Co-Design Automation and now director of marketing at Novas Software. "Those behind SystemC saw that the world was shifting to much more use of embedded processors. Software is written in C, so we thought that if we could create a C-based language, then the software could be written with it but we could also build in the constructs for hardware design. That was the idea behind Superlog, to add the class library so that you can do hardware but link it up with the software in the same language."
The Superlog-enhanced Verilog 2001 was dubbed SystemVerilog 3.0. A further revision, 3.1a, added some verification features that make it a true next-generation design language. Thanks to Synopsys' donation of the object-oriented OpenVera testbench-automation language, SystemVerilog 3.1a sports full-featured testbench capabilities for improved test-vector-driven verification.
SystemVerilog also includes a comprehensive set of assertions. Assertion-based verification is becoming increasingly important in the verification engineer's bag of tricks. SystemVerilog Assertions (SVAs) are restricted to conditions that can be easily stated within the temporal simulation semantics of Verilog. Meanwhile, a more general class of assertions, which lend themselves to formal verification, can be stated in languages such as the Accellera-standard Property Specification Language (PSL).
SystemVerilog represents a particular approach to enhanced design and verification. It builds up from Verilog and an RTL/gate base. Most users of SystemVerilog tend to be more hardware-centric in their orientation. However, another view of the world comes from a top-down, software-oriented perspective, and that's where SystemC comes in.
ENTER SYSTEMC SystemC, derived from C/C++, is an object-oriented software paradigm (Fig. 2). It was once touted as a do-it-all replacement for RTL that would dramatically shift the hardware design process to the behavioral level. Until very recently, though, tools to support a SystemC-to-implementation design flow hadn't appeared.With tools and flows now emerging, SystemC has great appeal to design teams taking a top-down, system-level approach. For the system-level architect, transaction-level modeling (TLM) in SystemC permits much higher simulation speeds than possible with signal-oriented languages like Verilog or SystemVerilog. "The adoption of TLM by system houses, and of SystemC as their standard methodology, is a big step toward standardization of how people do verification of systems," says Cadence's Berman.
Software-oriented system-level engineers prefer SystemC because they're already well-versed in C/C++. It offers an extensive infrastructure that can be reused, and it's simple to integrate SystemC code with C/C++ code.
VHDL, Verilog's old nemesis, is still very much with us. Many of SystemVerilog's system-level constructs are derivative of concepts in VHDL. VHDL took hold years ago in Europe, where designers have a system-level bent and a preference for open language standards. The language is also popular in its military/aerospace world of origin. Meanwhile, most high-end chip design in the U.S., Japan, and Asia is done in Verilog or, increasingly, SystemVerilog. Also, many FPGA designs are created in VHDL.
The IEEE's VHDL Working Group, P1076, is carefully tracking SystemVerilog and plans to adopt some of its features. An updated version of VHDL is in the works. It should include direct usage of PSL assertions. "Overall, the two languages (VHDL and SystemVerilog) are drawing closer together," says Cadence's Berman. In Berman's estimation, VHDL will retain a 20% to 25% market share for at least the next five years.
Verific, a developer of language parsers for the front end of EDA tools, makes parsers for VHDL, Verilog, and SystemVerilog. "We haven't seen any licensees yet say they're not going to support VHDL," says Michiel Ligthart, Verific's chief operating officer. "But it's becoming an afterthought for some."
VERIFICATION PATHS So it appears that the two languages on most designers' radar screens are SystemC and SystemVerilog. Now, who uses which, and why? Also, can SystemC and SystemVerilog coexist in the same flow?The unfolding consensus is that the languages are indeed complementary. "Where it's evolved to today is that SystemVerilog is a great means to extend Verilog to provide what designers really need," says Novas' Dave Kelf. "It's done in a simple fashion but in the HDL world. So they're using it for extending design and adding simple verification structures, and I think that's its sweetspot. SystemC, on the other hand, is very much focused on systems and software."
A design paradigm is evolving in which system-level designers use SystemC to specify high-level models for early software checks. Meanwhile, the hardware teams will use those SystemC models as a "golden" reference model against which subsequent implementations are compared for functional accuracy.
"We're seeing adoption of the SystemC methodology in a lot of companies with a top-down methodology," says Chris Lennard, technical marketing manager at ARM. "If people are using a top-down methodology, they'll want to use the SystemC golden reference and push down. People who are using system-level models to get faster simulation will want to be able to use the RT-based simulation suites they have and push that up."
SystemC handles generalized modeling for communication and synchronization between IP blocks through its Channels, Interfaces, and Events constructs. Its system-level extensions support TLMs, communication refinement, executable specification modeling, and hardware/software co-design.
Meanwhile, SystemVerilog offers a direct programming interface (DPI) to SystemC, which means that SystemVerilog code can directly call functions written in C, C++, or SystemC without resorting to the Verilog Programming Language Interface (PLI). The PLI imposes a heavy toll on simulators in terms of runtime, while the DPI does not.
"The good news is that there are methodologies for taking SystemC TLMs and cosimulating those, or integrating them with lower-level RTL models," says Cadence's Berman. "So it's very feasible at this point to have a methodology where you do your system checkout, including software, using TLMs, and can verify piecewise going down to the RTL."
But some see the very features of SystemC that make it so useful for TLMs also creating a difficult path to implementation. "There's considerable bifurcation between modeling environments and implementation environments," says George Harper, director of marketing at Bluespec.
"The challenge," says Harper, "is that the modeling can't be used effectively to assess either the feasibility of implementation, the implications of tradeoffs, or the bulk of microarchitectural considerations. None of those things are informed by the models themselves, and the models can't be used to assess those things, because there's no tie-in to the hardware. So the hardware has to be redesigned at RTL."
Bluespec's approach is a proprietary variant of SystemVerilog it calls Bluespec Verilog (Fig. 3). The language uses "rules" and "methods," or programming constructs. They enable the language to provide a better understanding of the physical implementation of the models' functionality. In this way, Harper believes, Bluespec is reconnecting designers and their work to how it will be implemented.
"We're seeing an increasing need to direct implementation to achieve power and performance goals," says John Goodenough, director of design technology at ARM. "In some cases, our own processor designers are moving back to almost hand-placed gates."
To some extent, Bluespec's approach gives Verilog users a subtle way to move into behavioral synthesis. "It incrementally improves the HDL they know, whereas SystemC is a wholesale change. If there's one area in this whole industry where there's a lot of inertia, it's the synthesis flow. They just won't change that. There's so much knowledge required to get a good netlist out of synthesis," says Kelf.
Meanwhile, tools that perform behavioral synthesis from C to RTL are popping up. Forte Design's Cynthesizer, Mentor Graphics' Catapult C, and Synfora's Pico Application Engine synthesis technology are among those tools reaching from C to synthesis-ready RTL.
Another high-level language that bears mentioning is the MathWorks' Matlab. "Matlab was designed to facilitate algorithm development and numerical computation tests that engineers and scientists run into," says Ken Karnofsky, marketing manager at the MathWorks.
Users typically start by developing a floating-point algorithm, which then can be converted to a fixed-point representation. Then, the MathWorks' Simulink tool can be used to model the algorithm and full system-level simulations, including analog and digital portions, as well as the real-world environment in which they operate. In addition, Synopsys' SystemStudio tool directly reads Matlab code for cosimulation with SystemC and HDL models. Most of Matlab's success can be seen with mathematically intensive applications implemented on FPGAs.
TESTBENCH LANGUAGES Whether or not you start from SystemC or another C-based language, verification remains the sticking point for getting designs out the door. "We're not in the era of language wars, but rather in the era of verification or design platform wars," says ARM's Goodenough.A number of standalone verification languages arose in recent years. Most prominent among them are Verisity's e language and Synopsys' OpenVera. OpenVera was donated some time ago to Accellera, and most of its attributes are now incorporated into SystemVerilog 3.1a. With the recent acquisition of Verisity by Cadence (still pending as of this writing), the future of e is murky. But both Cadence and Verisity have pledged support of the e language and of Verisity's tools and methodology.
There's a good deal of both e and Vera legacy code that many designers still turn to when evaluating IP for integration. Verisity's senior vice president of marketing, Steve Glaser, emphasizes what he terms the "vertical role" of e in the verification process.
"Our methodology spans the block, chip, system, and project levels," says Glaser. "Languages play a role in verification, but it's one of half a dozen things you need to actually automate the process. The various specialists—project verification manager, verification specialist, systems designer, and logic designer as well as the embedded software engineer—each need a certain view into the verification process. They will in turn find different languages optimal for their particular tasks. The key is to link the views together. So it becomes a mixed-language world."
GETTING INTO THE FLOW Today's integrated IC implementation flows from Cadence, Magma, and Synopsys all have broad support for mixed-language design. And, Mentor Graphics' ModelSim 6.0 supports some, but not all, of SystemVerilog."Languages, to a large extent, have evolved to being competent in terms of specifying the functionality," says Yatin Trivedi, director of product marketing at Magma Design Automation. "But the rest of the design environment must be considered in terms of the implications of design-specific information."
Magma approaches the issue of language by pretty much ignoring it and focusing instead on methodology (Fig. 4). "Languages are a necessary starting point," says Trivedi. "We have to supplement the language, or functional specification, with the timing, DFT, and power specifications. We have attempted to unify all other aspects of implementation details through our flow."
www.accellera.org
ARM
www.arm.com
Bluespec
www.bluespec.com
Cadence
www.cadence.com
Forte Design Systems
www.fortedesignsystems.com
Magma Design Automation
www.magma-da.com
The MathWorks
www.mathworks.com
Mentor Graphics
www.mentor.com
Novas Software
www.novas.com
Synfora
www.synfora.com
Synopsys
www.synopsys.com
Verific
www.verific.com
Verisity
www.verisity.com
