Last week I wrote a post about the Mentor OVM/VMM compatibility layer, and subsequently posted a response to that post from Tom Fitzpatrick. Now, it’s my turn to respond. Tom made several points that I want to address.
I'd like to share with everyone a response to my last blog post on the Mentor OVM/VMM interoperability solution from Tom Fitzpatrick over at Mentor. By the way, there are some good comments on the original post as well, as well as a pointer to the documentation which I somehow couldn't find earlier in the week. Tom has made some excellent points below that I will address in a subsequent post. For now, enjoy!
Update 1/16/2009: Found the Mentor docs for the interop solution (thanks to Tom Fitzpatrick from Mentor) - fixed appropriate comments below.
Last month Mentor and Cadence each released separate versions of compatibility layers to allow VMM code to interoperate with OVM code on their respective simulators. I’ve spent some time over the last couple of days reviewing the Mentor solution and wanted to share my initial thoughts.
The Mentor solution uses a customized version of VMM 1.0.1. Unfortunately for Mentor and Cadence, Synopsys released a new version of the VMM, 1.1, a couple of weeks later which contains changes in stimulus generation capabilities (among other things) that might impact the way the compatibility solution is architected. I will be interested to see how Mentor modifies their solution to take the changes into account.
In addition to a modified version of the VMM, Mentor uses a library of compatibility widgets to deal with the following aspects of OVM/VMM interoperability (with examples of associated new classes):
Happy new year all! I thought I'd pass along a link to an excellent post written by John Ford over at DFTdigest about techniques for "repairing" embedded memories. Enjoy!