SystemC standard adds verification features

Until now, the SystemC system-level design language has been aimed at high-level modeling, but not verification. "We're really moving SystemC into the standard verification space," said Stan Krolikoski, OSCI chairman and vice president at Cadence.

"In order to have a language suitable for doing design, you need to be able to model, verify and implement," he said. "SystemC is in use for modeling and in some cases implementation, and some people are already using it for verification, but we thought we should be standardizing on methodology. Just because you can do it in C/C++ doesn't mean everybody does it the same way."

"There was a significant user community that wanted to do the whole enchilada," said Kevin Kranen, OSCI president and director of strategic programs at Synopsys Inc. "If you're going to model in SystemC, you can start doing the validation of the system earlier if you can capture the whole environment in SystemC."

Gary Smith, chief EDA analyst at Gartner Dataquest, has indicated the need for a verification library for some time. "It looks like SystemC will be the ESL [electronic system-level] design language of the future," he said of the SCV standard announcement. "The only open question is how well the test class library works with the other SystemC class libraries."

Poten tial competition

Smith said that the SCV standard will compete with Synopsys' Vera language and Verisity's "e" language. That potentially puts Synopsys, which developed SystemC along with CoWare Inc., in an awkward position.

But Synopsys' Kranen said competition will not be an issue.

OSCI's Krolikoski said that SCV is a hardware verification language like Vera and "e," but is targeted at the "pre-implementation" level. "Certainly it can be used at RTL, but we're really talking about transaction modeling," he said.

Instead of working at the pin or bit level, transactions represent a broad collection of data moving through a system, Kranen said. They also may represent events that occur at different times.

Krolikoski noted that SCV allows users to write randomized tests with a lot of flexibility. For instance, tests can be weighted to certain values that are likely to happen more often, or can be subject to constraints, so that users don't have to randomly test addresses that make no sense.

SCV also provides the ability to record transactions, and then bring them into an HDL simulator or testbench, he said. It lets users test the RTL implementation against the golden reference model written in SystemC, and specifies interfaces into HDL simulators.

The result, said Krolikoski, is a savings in time and an increase in flexibility. Further, since there's now a standard, testbench reuse is much more likely, he said.

"C/C++ is a benefit and a curse in some ways," Krolikoski said. "It can be a difficult language to learn. But once people learn — and I've never found anybody who couldn't learn — you can express exactly what you want to say in a very flexible manner."

Meanwhile, Cadence continues to offer the TestBuilder — currently version 1.3 — to customers, and also offers a product called TestBuilder SystemC. The latter has "a few more bells and whistles" than the new SCV standard, such as synchronization expressions , Krolikoski said.

"We're really looking to SystemC as the basis of our system-level offering," he said.

Any commercial tool that supports SystemC 2.0 should support SCV, Krolikoski said. Cadence announced in May that its simulation tools support SystemC. Synopsys' CoCentric family of offerings supports SystemC.