The Open SystemC Initiative (OSCI) has hit a snag over some ambiguous wording in the SystemC licensing agreement. Hopefully, it can be quickly resolved so we can move on to the real questions about C-language design in general and SystemC in particular.
OSCI is supposed to be an "open" and independent standards effort, but Synopsys still has total control over the license agreement. One provision of that agreement implies that any licensee who sues any contributor over any software patent will lose its SystemC license. The way the agreement is worded now, if a licensee sues a contributor such as Synopsys or CoWare over a matter unrelated to SystemC, its SystemC license will be revoked.
If all major EDA vendors join OSCI, in theory, they won't be able to sue each other anymore-and companies don't like to sign away their legal rights. Thus, some companies, including Mentor Graphics and C Level Design, are refusing to license SystemC software.
A simple change in wording would make the license clause applicable only to SystemC-related patents. Then we can move on to more serious questions: Who will use SystemC, why, and how?
Will SystemC primarily be used by the small number of system designers already working in C/C++ or by the much larger number of RTL chip designers using VHDL or Verilog? The latter group has so far shown a lot of skepticism about C-language design and has warmed more to Superlog as a way of moving up in abstraction.
Why will system designers benefit? There are already pre-SystemC tools that help automate the transition from C to HDLs. The best argument, possibly, is that SystemC models of intellectual-property (IP) blocks can be exchanged with other companies, while proprietary C models generally can't.
Will SystemC be used mostly for architectural modeling or verification? Vendors seem to be opting for modeling, and Synopsys continues to push Vera as a verification language. But SystemC, Cynlib and Superlog seem to be using the approaches more for testbench generation. What's the advantage over Vera or Verisity's "e" language?
Dataquest's Gary Smith has asked whether we actually need three class libraries-for modeling, testbench development and synthesis. Can SystemC really span all three areas? Where are the high-level synthesis tools, and do we need a synthesis subset?
Finally, SystemC and Cynlib advocates both say they're ready to talk about combining the proposals. Will that claim result in any action? Stay tuned.