Feed on

SystemVerilog Methodologies – It’s Getting Wild

Every day this week at DAC I’ve been involved in at least one discussion on VMM versus AVM. It’s getting really competitive now. There’s all this talk of standards, Open Source, maturity, and compliance. On top of that, things just don’t stay still long enough to form an opinion that lasts more than five minutes.

The VMM has been around for a while now. It was based on Vera RVM, and claims to still be on REV 1.0, which some would suggest is testament to its stability and maturity. I guess it is really, as most of the issues were ironed out in the RVM days. The VMM defines a set of base classes and some rules and recommendations for writing testbenches. There’s been some discussion at the conference as to whether the rules are complete enough to form a set of VMM compliance checks, and if so what compliance really means anyway. Does it guarantee any compliant component will be plug-and-play in a VMM environment?

On top of all that VMM has added a bunch of applications, including a register abstraction layer, portable environment allowing reuse from module to system level, memory allocation manager, and a hardware abstraction to assist connection to vendor generic hardware platform interfaces (e.g. SCEMI).

That’s all cool, but Mentor’s AVM is now on version 3.0, and is making very good progress. There’s been some exciting formal and informal discussions here at DAC as to what features the AVM might include in the future. The AVM developers have been collecting feedback all this week, and there will be a further opportunity to give input at the AVM Technical Advisory Meeting on Thursday.

The AVM has a very different feel to the VMM, but both have a lot in common from a conceptual point of view. There’s no explicit rules and recommendations in the AVM, which some people like and others don’t. The lack of rules make some wonder if it’s possible to have a concept of AVM compliance. The AVM has still got a bit of growing to do yet, but has the potential to accommodate changes quickly at this stage in its life. One thing is for sure, the fact that the AVM is Open Source has really appealed to the community, and there’s a good buzz going on.

There is another methodology for SystemVerilog: Cadence uRM. There seems to be less of a buzz about this, at least from a SystemVerilog point of view. Maybe that’s because Synopsys and Mentor have been pushing SystemVerilog harder? What is interesting to note however, is that neither the VMM, nor the AVM has come close to the achievements of the eRM (now absorbed into the uRM), from a reuse point of view. The eRM is the only commercial methodology that really seemed to enable plug-and-play verification environments that worked.

It’ll be interesting to see how the market handles VIP development now that there are at least 3 different SystemVerilog methodologies to support. I think one of the things that allowed so much third party and intra-company Specman VIP to be developed, was that there was only one methodology, and everyone was using it. It Just Worked!

We really need to get to that stage with SystemVerilog quickly, such that third parties have a chance of developing compliant VIP that will run on any simulator.

Comments are closed.

Work For Verilab