SystemVerilog 3.1, which includes several constructs to enable verification, offers many of the advantages that a traditional HVL is able to offer verification teams. Verification teams are at crossroads again. Teams will need to give serious consideration to the pros and cons of migrating their verification infrastructure to SystemVerilog, and make an informed decision.

Important factors to consider are the adequacy of SystemVerilog 3.1 verification constructs for internal projects, ability to reuse legacy modules, potential cost savings and simulator/tool support. Decisions should be made objectively by making use of tools that can correctly estimate transition costs. For example, a tool programmed to understand the differences in Vera and SystemVerilog can closely estimate the "translatability" of existing Vera code.

If a corporation has made a decision to migrate to SystemVerilog, the next step is to put the tools in place to ensure a smooth migration. It is important to understand the feasibility of such a migration. Is it possible to take Vera files and attempt to create an equivalent SystemVerilog verification environment?

The answer is a resounding yes. SystemVerilog verification constructs are derived from Synopsys's contribution of certain Vera constructs to Accellera. Not surprisingly, an overwhelming majority of these constructs made it to SystemVerilog.

Given the similarities in these languages, an obvious migration methodology is translation. Translation is a tried and tested technique that works well for languages with similar semantics. This is a major benefit for current Vera users. They are assured of being able to develop verification code similar to Vera in an industry-standard language. Of course, as any language expert will hasten to add, no source-to-source translation is problem-free, however close the languages are in their syntax and semantics. The simpler discrepancies deal with keyword clashes, unsupported constructs and user comments.

Translation is easy to comprehend. However, a standalone, source-to-source translator's requirements are somewhat stringent. It is limited by the output language and is required to produce semantically equivalent constructs — all while keeping intact the input hierarchy and design modularity. Ironically, a good translator is one that deals well with the non-translatable constructs!

Translators do not work line-by-line. In fact, Vera to SystemVerilog translation will involve technology that will create an in-memory model of the input Vera modules, a transformation engine that will transform unsupported constructs to legal SystemVerilog constructs, and a SystemVerilog writer to write the output. Definitely not a weekend task for the in-house Perl expert!

There are other challenges in transitioning to a SystemVerilog-based verification environment. While the emergence of SystemVerilog 3.1-compliant simulators is a sure thing, most of the 3.1-compliant simulators are in the beta phase. However, the current "tool vacuum" does not mean that Vera users can sit tight, waiting for simulators to take the lead.

There are several steps companies with long-term migration strategies can take today. In addition to remaining abreast of all developments in SystemVerilog, verification teams will need to restrict the development of current Vera modules to conform to SystemVerilog language constructs, and require that Vera code be SystemVerilog-compatible.

Enforcing SystemVerilog-compliant development guidelines for Vera-based teams is a compelling, inexpensive and feasible strategy. In addition, it is essentially risk-free — in the worst case, you are left with well-written, maintainable Vera code, and at best you will be able to reuse all your Vera code in a SystemVerilog environment. This task is easy to conceptualize but hard to implement.

It is extremely challenging to design and enforce a coding policy in a typical multiple-site and multiple-team development environment. Companies with centralized CAD organizations are better equipped to deal with this task. With the right mix of tools, policies and people this goal can be successfully achieved. You will be well rewarded for your efforts in the form of increased verification productivity and a phenomenal reuse model.

There is overwhelming support for SystemVerilog; initiatives such as the SystemVerilog Catalyst Program are testament to the fact that vendors are allocating significant resources to upgrade their current tools to support SystemVerilog 3.1. It is widely accepted that SystemVerilog will be the language of choice for design and verification in the years to come.

Methodology decisions have long-term impact on a company's fortunes. Making the right decision is what we all want. However, in a situation where there is no crystal ball for right or wrong decisions, making an informed decision is the next best thing to do.

Sashi Obilisetty is president and CEO of VeriEZ Solutions, Inc.