Just like natural languages, non-standard verification
languages can fade away. Sure, ancient
Sumerian exists in the Code of
but all modern law is written in living languages. Similarly, verification environments and VIP
still exist in Vera, but a shrinking population understands and uses it. To preserve the investment, that code base need
to be both translated into a standard language like SystemVerilog (IEEE 1800) and/or e (IEEE
But how? One
obvious path is to hire a service provider.
A number of excellent choices are list on the OVM World website on the
partner pages. Of course, you could also just do it yourself. Regardless of who does the work, translation
tools can be a great help.
"But Mr. Sherilog, we all know translation tools are
incomplete." Right you are disembodied
voice of every engineer who's tried this.
True, but think of the workload.
If you could get a tool to do 95% of the grunt work, you could
concentrate on the remaining code and get the work done in a reasonable
time. Furthermore, it's only worth the
effort if the language is a dead end.
With a completely different set of keywords and semantics, Vera is
neither standard nor SystemVerilog so translation is worth the pain. Translation makes technical and business
One application we've seen our customers use is the
Vera2SV script posted at http://www.findthecat.com/vera2sv/. True, the script also targets VMM, but that
is to be expected as the methodology used with Vera was RVM, the predecessor to
VMM. Our customers have looked at
several translation paths and have had success with this one. The next step is to use the Accellera VIP TSC
best practices to encapsulate the translated code so that it can work with OVM
including the VIP portfolio from Cadence. You can find the code to enable the
interoperability on the OVMWorld site.
If you are interested in having the script target OVM directly, feel
free to post your comments here or directly to the authors on the script.
To all of our Vera users: "se udnamekam" or "live in the
The main reason to change would be the lower costs and higher productivity that comes from the larger ecosystem of EDA providers, VIP vendors, and system integrators. You get this with SystemVerilog (and SystemC and e) because it's a standard, while Vera is proprietary to a single provider.
With that said, I can't argue with the support you have received. I'm just suggesting you may want to consider how that decision unfolds one, two, or three down the line given the industry momentum.
I think if VERA is enough for my project, and the tool support is very good. Why should I change it into systemverilog?