In its plain-vanilla form, the Verilog hardware description language is purely a designer's language that contains all of the constructs one would need to assemble an IC netlist for synthesis to gate level. But for today's extremely complex IC designs, it's unable to make the leap into the verification world.
A couple of years ago, Accellera's SystemVerilog Working Group sought to build upon the foundation of Verilog and extend it with a rich set of verification capabilities. That effort bore fruit last December when the IEEE ratified the SystemVerilog P1800 standard.
Now that SystemVerilog is an honest-to-goodness IEEE standard, who's using it for verification, how are they using it, and why? How difficult—or easy—is it to begin using SystemVerilog in the verification realm? And what kind of infrastructure has been built so that it's useful to designers?
MARRIAGE OF CONVENIENCE Verilog's extension into what's now IEEE-P1800 SystemVerilog was borne from the need for a design language that truly unified design and verification. To that end, the Accellera SystemVerilog Working Group accepted technology donations from several companies and added them to the existing Verilog language as extensions.Indeed, designers have embraced SystemVerilog—it's by far the fastest growing design/verification language in the world today (Fig. 1). "The ability to do assertions is significantly improved in SystemVerilog, so you certainly can say that it is taking off as a verification language," says Gary Smith, chief EDA analyst at Gartner Dataquest.
SystemVerilog marries a number of verification concepts, primarily in the areas of design, assertions, and testbench creation, that were previously embodied in separate and sometimes proprietary languages. Although use of these capabilities with Verilog, doing so often requires separate tools that must with a simulator through a programming language interface (PLI) application programming interface (API). The result is undesirable and less than adequate performance.
For partitioning purposes, a discussion of SystemVerilog can be broken out into four key segments: design, assertions, testbench capabilities, and verification coverage analysis. SystemVerilog's rich set of verification capabilities contains many successful verification techniques. Using a mix of them likely will lead to first-silicon success (Fig. 2).
One of the beautiful things about SystemVerilog is that its verification capabilities can be adopted incrementally. One needn't swallow the entire language at once to make use of a given set of features. Rather, users can dip their toes into the SystemVerilog verification waters simply by adding its constructs to their existing RTL environment.
"Just by adding assertions, ordinary Verilog users become SystemVerilog users by learning only one extra construct," says Yatin Trivedi, director of product marketing at Magma Design Automation.
Thus, it seems that adoption of SystemVerilog is progressing at different rates for different kinds of design teams. Some are gravitating toward certain aspects of the language before others, largely due to the levels of risk entailed in disrupting an established verification methodology.
GETTING ASSERTIVE "We see the SystemVerilog market as two major segments," says Steve Glaser, corporate vice president of marketing for Cadence's verification division. "One is the selfcontained design team, which may be heavily responsible for verification of its own RTL. These teams typically do not include dedicated verification experts and require a low-risk path to adoption."The second major segment, says Glaser, is the large, multispecialist "enterprise" team that does include dedicated engineering specialists. Such groups tend to be very cautious about changes to their methodologies.
One of the most popular, and most readily adopted, SystemVerilog features is its assertions capabilities. Using assertions with the RTL is a quick and relatively easy way to make use of SystemVerilog to improve verification.
Use of the SystemVerilog Assertions subset is fairly non-disruptive-to the users' verification methodologies. Assertions can be liberally sprinkled throughout the design's RTL. When the RTL is run on a simulator and an assertion "fires," meaning that whatever the assertion statement "asserts" should happen logically fails to occur, the error is flagged.
What, if any, barriers to entry are there to would-be users of SystemVerilog Assertions? For one thing, assertion-based verification methodologies do require some training. According to Glaser, some users struggle to use assertions correctly.
How do you write assertions? Which constructs do you use? How many should you write? How do you debug the assertions themselves? And how do you leverage them into providing metrics regarding functional coverage?
Despite these questions, some designers prefer assertions because they require a smaller upfront investment. For instance, many design teams at STMicroelectronics are fans of assertions. However, Mike Benjamin, manager of ST's functional verification group, does wish that Accellera had included Property Specification Language (PSL) assertions within the P1800 standard as opposed to the SystemVerilog Assertions (SVA) subset, since ST's verification teams had widely deployed PSL. PSL is one of several standalone assertion languages in the market.
"To some extent, it's nice to have an assertion language that's not tied to SystemVerilog," says Benjamin. Yet he expects that all simulators will be equipped to support both PSL and SVA assertions. An important aspect of using assertions, and a question designers should ask, is how their use in RTL benefits downstream implementation flows.
"Traditional Verilog users are simply RTL coders working toward synthesis," says Magma's Trivedi. "They provide little or no guidance to the verification engineers."
Approaching RTL design without an eye toward verification can force verification engineers to debug the design blindly. Thus, they must check the design for many more possible bugs than may be necessary. But with assertions plugged into the design, the verification team gains some much-needed guidance in terms of what it should look for.
"SystemVerilog assertions can significantly improve the productivity of the verification engineer," says Trivedi. They'll serve to point the verification engineer in the direction of the aspects of the design that the designer is concerned about.
"You get a lot of bang for the buck with assertions," says Tom Moxon, founder of Moxon Design, a design consulting firm based in Beaverton, Ore. Moxon points out that for most of the standards-based interfaces, such as ARM's AMBA, the PCI bus, and the Open Core Protocol, a full body of assertions has already been written and debugged. "When you buy the (Cadence) Incisive verification platform, or (Synopsys') VCS simulator, these checkers come along with it," says Moxon. "In the same vein, Mentor Graphics is starting to fold the 0-In. checkers into its Questa simulator."
APPROACH THE TEST BENCH For the large, multispecialist design teams with in-house verification experts, such as those often found on the enterprise level, SystemVerilog adoption comes at a different rate than it does for smaller teams. This is exemplified primarily on the testbench side, where the larger teams, who typically develop larger SoCs, often have much more to lose than the smaller teams.Whereas the smaller, self-contained design teams are fairly adventurous with assertions, they're bound to want an incremental approach to tackling the testbench extensions to SystemVerilog. They're likely to need methodology guidance as they gingerly move beyond directed testing (in the form of assertions) to an automated-testbench methodology.
Meanwhile, the multispecialist teams, which are apt to include verification engineers who aren't shy about applying object-oriented programming techniques, face a bit of a conundrum. They're more likely to be enticed by SystemVerilog's potent coverage-driven, constrained, directed-random verification capabilities. But taking the deep plunge into directed-random testing means raising the bar much higher in terms of risk.
"These large groups are typically part of a corporate-wide implementation initiative," says Magma's Yatin Trivedi. "These groups need such an initiative. The problem is that for larger companies, once you start moving in that direction, it's very hard to backtrack if it isn't working out."
To some, the emergence of SystemVerilog on the testbenchautomation scene represents consolidation.
"What we saw when we first looked at this technology was primarily proprietary solutions in the market, both in terms of various flavors of assertion languages, and in terms of testbench automation," says John Goodenough, director of design technology at ARM. "We saw a fragmented market. So we viewed SystemVerilog favorably as a means of driving some convergence."
The barriers to entry for SystemVerilog's testbench capabilities are different from those on the assertions side. "The biggest issue is what do people do with their legacy code?" says Robert Hum, VP and general manager of Mentor Graphics' Design Verification and Test Division.
Many design teams have already begun using other testbench languages, such as SystemC, Cadence's (formerly Verisity's) e language, or Synopsys' Vera. "So on the testbench side," says Hum, "SystemVerilog will progress with people putting their new projects on it. It'll be a gentle ramp, not a step function, because of this legacy problem."
At STMicroelectronics, where heterogeneous design and verification environments have been the rule, a mixture of Verilog and VHDL is gradually yielding to SystemVerilog on the design side. According to Mike Benjamin, ST historically has been a user of the Verisity/Cadence Specman tool for testbench automation. Now, though, the company is beginning to look at SystemVerilog as a testbench language.
"I believe that SystemVerilog will end up doing as good a job or better than Specman," says Benjamin. "They're comparable. But we at ST have a lot of legacy verification IP in Specman e code, and we can't instantly swap that into SystemVerilog. We're also using more SystemC to model at a very abstract level. So we anticipate mixed environments."
According to Mentor's Robert Hum, the Specman e language to Accellera for inclusion in SystemVerilog in the form of OpenVera, are relatively similar. key aspect that makes them so is their directedrandom testing capability. "People who know how to directed-random test find switching to System-Verilog quite easy," says Hum. "Once you understand the paradigm of using directed-random test, all you need to do is shift syntax."
With the inclusion of the OpenVera constructs, System-Verilog offers full object-oriented programming capabilities, as well as full functional coverage. "The object orientation in SystemVerilog tends to make for a clean testbench," says ST's Benjamin. However, he points out, SystemVerilog is weak on aspect orientation, which is a particular strength of the Specman e language. "Verification engineers like to work in an aspect-oriented fashion, so there's a bit of a conflict there and not a clear win either way," he says.
For testbench creation, SystemVerilog still has an estimable competitor in SystemC. "I believe that testbenches will be developed at the electronic system level (ESL) as the designers move up to ESL design," says Gartner Dataquest's Gary Smith. "That means SystemC or e will be the preferred languages."
Design consultant Tom Moxon agrees with Smith's point. But as Moxon explains, "there's testbenches and then there's testbenches. For system-level approaches, I can see SystemC dominating, because there you're looking at hardware/ software interfaces and transaction-level models (TLMs). But for timing and chip-level interactions, you're in a lower-level environment where you may not have all the models plugged in. That's where SystemVerilog presents more of an advantage."
SystemVerilog's built-in direct programming interface (DPI) lets users directly call the software team's C-level models or algorithms. "That feature will foster a lot of code reuse," says Moxon. That same DPI also allows a C-language function to call a SystemVerilog task or function, which further facilitates hardware/software co-verification (Fig. 3).
For those verification teams looking to get the most out of SystemVerilog, particularly for testbench creation, the learning curve is steep. To aid in adoption, EDA vendors put together a number of methodology manuals.
The granddaddy is the Verification Methodology Manual (VMM) from Synopsys and ARM. Mentor Graphics has its Advanced Verification Methodology (AVM). Likewise, Cadence offers its Unified Verification Methodology (UVM).
All of these manuals serve the same general purpose: lending a helping hand to adopters of advanced verification methodologies. Each provides a structured method in "cookbook" form, from which users can piece together a solution.
But according to users, not all methodology manuals are created equal. "The Synopsys/ARM VMM did a good job of putting together the knowledge required to do a sophisticated testbench," says ST's Benjamin. "But you have to read 500 pages before you can write a really good testbench."
For Benjamin, Mentor's AVM is a less weighty take on a methodology. The AVM, which features an object-oriented coding style, is notable for its inclusion of source code for base class libraries, utilities, and implementation examples written in both SystemC and SystemVerilog. The AVM code and documentation is free under an Apache 2.0 open-source license.
Of course, manuals (and languages) alone do not a methodology make. For any of this to be useful to designers, verification environments must support SystemVerilog.
Cadence, Mentor, and Synopsys all offer fairly comprehensive SystemVerilog support. Cadence's Incisive verification platform is augmented by what Cadence terms its "Plan-to-Closure" methodology, which in turn is supported by a Webbased support system (see "Verification Methodology Spans Plan To Closure," ED Online 12147).
Version 6.2 of Mentor's Questa functional verification platform supports all of the key components of the AVM. These include the object-oriented and constrained-random capabilities of SystemVerilog and SystemC, the Open SystemC Initiative's TLM-standard functionality, and the functional coverage capabilities of SystemVerilog and PSL.
Questa supports the AVM's layered, modular architecture, which allows users to quickly assemble building blocks into reusable testbenches (Fig. 4). All of the architecture's intelligence resides in a test controller, which interfaces directly with the test stimuli, a coverage engine, and a scoreboard for delivering coverage metrics. The device under test (DUT), which is usually in RTL, interfaces with the testbench through an abstraction conversion layer.
"The other word for that is TLMs," says Mentor's Robert Hum. "At the edge of your DUT, you can have ones and zeroes, or pin wiggles, if you will. At the other end of the conversion layer, you can have arbitrary levels of abstraction."
So software engineers can see routine calls and other nontimed views, while hardware designers can see lower levels of abstraction with the timing information they need. Test stimuli are never sent to the DUT directly, but rather through a conversion-layer. This adds no overhead to the simulation. "We've seen testbenches run faster, because this methodology cleans up the testbench code," claims Hum.
Questa 6.2 ships in Q2. Pricing starts at $28,000.
Synopsys claims to offer complete design and verification support for SystemVerilog. A final, and crucial, piece of the infrastructure surrounding that support is the recent announcement of a SystemVerilog verification-IP library. Synopsys enhanced its VCS simulator to support testbenches created using IEEE-P1800 SystemVerilog.
"While you can use existing verification-IP components in a SystemVerilog environment, one of the biggest advantages is being able to work within the constrained-random stimulus methodology and also with functional coverage," says Synopsys' Steve Smith. "That required some enhancements to the VCS simulator to support the verification IP."
Thanks to the VCS and verification-IP enhancements, those using SystemVerilog for testbench creation will have access to a broad portfolio of Synopsys' DesignWare verification IP. Current DesignWare customers can obtain the SystemVerilog functionality for their IP at no added cost by requesting the SystemVerilog versions from the Synopsys Web site.
For a complete list of companies mentioned in this article, see Drill Deeper 12548.