Designers cautiously try out C-language tools

Designers cautiously try out C-language tools
By Richard Goering, EE Times
March 9, 2001 (10:30 a.m. EST)
URL: http://www.eetimes.com/story/OEG20010308S0090

SAN JOSE, Calif. — While C-language system-on-chip (SoC) design has received considerable publicity during the past year, reports of actual silicon tapeouts have yet to come. Still, a few chip designers are testing the waters with new C-language tools, and are finding both compelling advantages and significant trade-offs.

Much of the recent publicity has centered on Open SystemC, a C++ class library initiative launched by Synopsys and CoWare that now claims dozens of industry backers. The Cynlib C++ class library from startup CynApps offers an alternative that has some loyal supporters. And vendors such as Synopsys, CynApps, C Level Design, Frontier and Celoxica offer various types of C-language design and synthesis tools.

Co-Design Automation, meanwhile, has gained some user support for its Superlog language, which takes Verilog and adds some C-language constructs. Get2Chip recently announced the first Superlog synthesis tool.

Designer s who have tried those new approaches are generally a long way from producing actual silicon. But their experiences offer a good preview of the promises, and perils, of moving from a Verilog or VHDL methodology to C or Superlog.

On the plus side, designers say, a C or Superlog approach makes it easier to model complex systems that involve hardware-software interactions. Higher-level modeling makes it possible to consider a range of architectural alternatives. And in addition to much faster simulation, C or Superlog can make it easy to construct tests that would be difficult or impossible with Verilog or VHDL.

The biggest stumbling block, according to many designers, is the lack of proven synthesis tools for those higher-level languages. The tools that exist often aren't mature, and automatic code translation yields HDL that's hard to read. And with the current lack of semantic checkers, users say, it's easy to write C/C++ code that compiles, but can't be simulated or synthesized.

A C-language too l set, by itself, is no panacea. Albrecht Mayer, a SystemC user and director of concept engineering at Infineon's Cores and Modules Division (Munich, Germany), makes that point in a book on hardware modeling that is currently available only in German.

In his book, Mayer notes that Moore's Law causes chips to become four times more complex every three years. If an SoC is two times larger, it requires twice as many functional patterns, which will run with half the simulation speed. So the effective complexity is growing at a minimum of 160 percent per year. Going from C to VHDL provides a five- to tenfold speedup in simulation, but it's only a one-time gain.

What happens after that one-time gain is used up? "The only way out of this dilemma," Mayer said, "is having an environment that makes it easy to go from very detailed modeling to a very abstract model." In other words, it's the overall methodology that's important, not the gains provided by any one tool.

Using SystemC

Judging from the technical papers available at the www.systemc.org Web site, the vast majority of SystemC activity is currently in Europe. Papers or presentations from Siemens ST Microelectronics, Infineon and the Italian CSELT laboratory discuss work done by those companies using SystemC. Most usage so far is based on SystemC version 1.0, which lacks the more advanced architectural modeling features, such as channels and events, available in the new 2.0 release.

At AMD's Advanced Development Labs in Austin, Texas, Joe Bailey, a member of the technical staff, is using SystemC 1.01 to model a complex system based on the Infiniband architecture. It's currently a research project, not an actual product. But through this effort, Bailey has discovered some of the advantages that SystemC has over Verilog.

"I'm developing a simulation model for the architecture," Bailey said. "My goal is to create an executable specification, so I've decided to approach this by writing real sof tware drivers and Infiniband management agents. And then I'm writing a SystemC model for the host channel adapter."

Bailey has done very little C-language modeling in the past. One attraction of SystemC, he said, is the ability to model hardware-software interactions. "When I compile the SystemC model, I get an executable, and I can build into it interprocess calls, or IPCs, that allow it to communicate directly with the software drivers and managers," he said.

With SystemC, Bailey noted, it's possible to create user-defined data types and pass those through SystemC ports to other blocks. This makes interblock communication easy, he noted, which is not a capability available in Verilog.

What Bailey questions is the ability to synthesize from SystemC. "I'm not sure just how well you can control the output of a synthesis engine with objectized C code," he said.

Bailey has run into some limitations with SystemC version 1.01. "It doesn't handle remote procedure calls, so the abstract port defini tions don't work," he noted. SystemC 1.2 adds those features but is just now becoming available on Windows NT platforms.

Bailey would also like to see a SystemC semantic checker. "There are a number of things you can do with SystemC that will compile just fine, but when you try to execute the model, won't work at all," he noted.

At Infineon, Mayer has started experimenting with SystemC for the design of intellectual-property (IP) blocks. But Mayer is no stranger to C-language design. He's been using Infineon's proprietary C++ class library since 1997, and this approach has been used to design several dozen IP blocks, representing many silicon tapeouts.

Mayer started talking to Synopsys about C-language design over two years ago. At that time, he found that Synopsys' Scenery class library was very similar to Infineon's CSIM. During a joint project with Synopsys, Infineon ported a GSM baseband chip description from CSIM to Scenery, which, Mayer said, is very similar to SystemC version 1.0.

Maye r is sold on the use of C for architectural modeling. "If you start on a level where you don't know what's hardware or software, it's better to have one language," he said. "If you have a C model running on a PC, all the tooling is dirt cheap, and speed is, of course, an issue."

For verification, Mayer said, C makes it easy to create "understandable" tests. "If you write functional tests at a higher level, basically you get a software driver for free," he noted. But, he acknowledged, Infineon still needs to deliver VHDL or Verilog models to its IP customers.

While SystemC 1.0 is functionally equivalent to CSIM, Mayer needs more. With SystemC 2.0, he noted, it becomes possible to model transaction-based buses, an important capability for Infineon.

Mayer has no current plans to use SystemC synthesis but will evaluate tools as they develop.

Walter Tibboel, hardware designer at Philips Center for Industrial Technology (Eindhoven, Netherlands), is doing more than just C-language modeling — h e's using the A/RT Designer C-language synthesis tool from Frontier Design. The tool is not yet compatible with SystemC, but Tibboel expects it soon will be, and he plans to conform to SystemC data types after that. Before turning to Frontier, he had done most of his work in VHDL.

C-language synthesis isn't for everybody. A/RT Designer is most useful, Tibboel said, for designs with multiple cycles per sample — designs that derive a lot of benefit from scheduling and resource sharing. Otherwise, he said, there will be some overhead. And for straight RTL design, Tibboel said, VHDL is better than C, because VHDL offers more support for parallelism.

To use A/RT Designer, Tibboel builds a bit-true model using Frontier's word-length types. "What you're building is an application-specific VLIW [very long-instruction word] processor, and you can instantiate as many operators as you like. Then you have to map your design source toward these operator instances," he said. Scheduling and resource allocation is done interactively, using labels and pragmas. One of the tool's outputs is synthesizable VHDL.

"After you do modifications, it's still high-level design source, and it's still readable by other people," Tibboel said. "That is certainly not the case if you write in RTL VHDL."

Tibboel doesn't plan to use A/RT Designer for all chip designs going forward. "It requires expertise to work with it, and I don't think everybody will get this expertise," he said.

The CynApps alternative

Not every C-language user is adopting SystemC. Milton Lie, director of engineering at networking startup Netrake (Plano, Texas), has opted for the competing Cynlib C++ class library from CynApps. Lie is using Cynlib on a production design, but due to the lack of high-level synthesis tools, he's staying at the register-transfer level (RTL).

Lie is using Cynlib to design a multichip processing engine for content-aware networking equipment. At the moment it's housed in three Xilinx Virtex 2600 devices, w ith a plan to migrate to ASICs. The FPGAs will be available in the first half of 2001.

"Our original intent was to do architectural modeling, and we felt C would be a better way to do it," Lie said. "We were going to write a Verilog model based on the architectural model." But plans changed, Lie said, when Netrake realized that high-level synthesis for Cynlib code wasn't available.

"The only way we have to go to synthesizable code, right now, is writing RTL," he said. "We don't want to have two models to maintain."

Even so, there are advantages, especially in verification. "There's no PLI [programming language interface] between your testbenches and the device under test, so it's easier to integrate with software modules," Lie said. He noted that Cynlib allows testbenches with C-language structures that aren't available in Verilog.

If he were only writing design descriptions, writing RTL Cynlib would probably be more work than writing RTL Verilog, Lie said. What makes Cynlib worth the effort, he said, is the huge amount of time that goes into verification.

Since Cynlib is aware of timing properties, Lie finds he can do anything he'd want to do in Verilog with C++. "Things like tasks are a little different," he noted. "And there are [Cynlib] function calls you can use, but you have to be careful what they mean in the synthesis process."

Lie uses CynApp's Cynthesizer product to translate the RTL Cynlib code into RTL Verilog. "It's not as readable as what you'd write by hand," he noted. "A lot of variable names are not readable." Also, he said, the use of CynApp's C++ simulation tool requires an understanding of timing wheels, a function that's hidden from the user in Verilog.

Lie decided not to use SystemC because "so many big companies with their own egos were involved that I thought it would be very hard to get off the ground." He also felt Cynlib was more mature.

"The language itself is pretty good," Lie said. "What I'd like to see is more robust error checking, and more meaning ful error messages when something goes wrong. I think in the future, high-level synthesis needs to be available for it to really work well."

The non-C approach

In spite of a publicity blitz by EDA vendors pushing C-language design, many chip designers remain skeptical. One alternative that's arisen is Co-Design Automation's Superlog language, which is drawing interest because it's a superset of Verilog.

Anders Nordstrom, ASIC design manager at Nortel Networks (Ottawa), is using Superlog to verify a two-million-gate, Ethernet-to-Sonet ASIC. But his team is only using Superlog for verification, while writing RTL Verilog code for synthesis.

Nordstrom explained that he decided not to use Superlog for architectural modeling because Superlog synthesis wasn't available at the time. "We didn't feel comfortable with an extra translation," he said.

But for verification, Superlog offers some compelling advantages. "We're passing frames through the ASIC, and we want to verify that the bits we send in are the same as the bits that come out. To do that in Verilog is quite complicated. To do that in Superlog, using a queue, is really simple," Nordstrom said.

Nordstrom said he decided against SystemC because he didn't want to move too far away from Verilog. "The advantage of Superlog is that it allows you to write Verilog, but you also have the headroom to move up in abstraction if you want to. Anything you can do in Verilog you can do in Superlog," he said.

Nordstrom is using Co-Design's Systemsim simulation tool, and his main complaint is that the Verilog simulation performance is still slower than Synopsys' VCS simulator. Superlog simulation, however, is significantly faster.

Co-Design has promised to make Superlog an open standard, and Nordstrom said that's essential. "I don't want to be caught in a proprietary language," he said.

Detailed interviews with Bailey, Lie and Nordstrom are available at the EDTN EEdesign Web site at www.EEdesign.c om.