Last week I quoted Tom Fitzpatrick, Verification Technologist at Mentor Graphics as saying "SystemC and SystemVerilog are the only two growing verification standards", and that e and Vera were on the decline. Mike Stellfox from Cadence Design Systems disagreed, and provided an analysis of the situation from his perspective. I asked Tom if he had a rebuttal to Mike's response, and yesterday he provided one. Here's what Tom had to say:
Now that I'm home and sufficiently dug out from the piles of stuff that accumulated during DVCon, I'd like to reply to your post "Mentor Says e/Vera on Decline…Cadence Says, Not Yet!" on Feb. 22.
Yes, I did declare that "SystemC and SystemVerilog are the only two growing standards for verification," and I stand by that statement since I really can't consider e to be a standard until more than one simulator vendor supports it. I must confess to being unaware of the modest growth Mike mentioned because I was too busy working on the 230+ new Mentor SystemVerilog customers we've added in the last year and a half. Combined with the 150 SystemVerilog customers that Cadence announced in their 1/8/07 press release, and not even counting Synopsys, it's clear that SystemVerilog is growing much faster (by 10-20x) and may have already surpassed the 400 e logos that Mike mentioned (I'm guessing Synopsys has more than 21 SystemVerilog logos). It's also clear that even Cadence's own installed base is moving to SystemVerilog rather than e.
As we all know, the value of a standard is that it allows users to benchmark tools against each other without being locked into one vendor. It is only when e users have this ability that Cadence will be able to call 1647 a real standard with a straight face. Don't hold your breath. In contrast, Mentor Graphics, Synopsys and even Cadence have all committed publicly to fully supporting the SystemVerilog standard, and even a majority of Cadence's own panel at DVCon on Friday said that having a unified design and verification language is clearly superior to having two completely separate languages.
I'll also agree with Mike that the primary application for SystemC is for TLM for early architecture exploration or virtual prototyping. One of the key reasons we architected the AVM to use both SystemC and SystemVerilog is so that a single testbench environment could be assembled for use with these TLM models that could also be reused as the design is refined down to RTL. The question of whether to use SystemC or SystemVerilog is a choice to be made by the users based on their own talents, inclinations and tool flow. But I have to take exception to Mike's statement that "SystemVerilog is appealing to a lot of people who haven't really adopted constrained random coverage driven verification."
We've had success in bringing non-HVL users into the constrained-random coverage-driven fold by using the AVM to ease the transition for them to an OOP environment. Not coincidentally, many of these users hadn't made the switch previously because the idea of adopting a completely new language was simply too big of a hurdle. We've been able to get them past that and they are deriving huge benefits from these new (to them) capabilities. Of course, we also have many customers who have a great deal of experience with HVLs, constrained-random and coverage-driven methodologies who have switched to the AVM, including porting large amounts of e code, because they see the value that it provides in terms of reuse, particularly at multiple levels of abstraction.
One last comment: We deliberately chose to make the AVM open-source as a direct challenge to the other vendors to support a common methodology. The advanced verification features were added to SystemVerilog because real users requested them, and Mentor Graphics has taken the lead in providing these capabilities. By architecting the AVM to use these features, the overall use-model is much simpler for the user, and we've been getting nothing but positive feedback. We know that other vendors have downloaded the AVM and are probably using it in their regression suites, which is great. The sooner they step up to the plate and support the IEEE 1800 standard fully, the sooner our customers will be able to compare the different tools on a level playing field, which has always been the goal of standards. We at Mentor Graphics have always been comfortable competing in such an environment, and we're confident that users will find our tools to be the most valuable.
Thanks for the opportunity to reply,
I'd like to thank both Tom and Mike for taking the time to lay out their positions in more detail, and, as always, am interested to see if any third-party information exists that could shed additional light on this issue.