Last Thursday at DAC I participated in a panel discussion at the OVM World Summit. Unfortunately, I arrived a few minutes late as I went to the Marriott instead of the Sheraton (oops!). Luckily things had just gotten started and we had an interesting discussion about the benefits of OVM and whether the industry needs a single standard language and methodology for verification.
One comment that caught my attention came from John Aynsley of Doulos. John stated that he felt customers were looking for a single language and methodology and would prefer not to have to make a decision regarding which one to select. I understand where these customers are coming from. It is also true, though, that some problems lend themselves well to certain languages and methodologies and other problems may be better solved with alternate approaches. For example, I'm likely to need to use SystemC to model algorithms in a DSP core, and will certainly need to run an instruction set simulator written in any number of languages that uses assembly instructions as input if I'm verifying a CPU. Do we need to force everyone to use a single language and lose any competitive advantage that may come from using a more advanced flow than the average user?
After the panel was over there was a presentation discussing the upcoming features of OVM 2.0, to be released in August. I stepped out of the room just long enough to cause me to miss the talk but was able to get a quick overview of the material after the fact from Sharon Rosenberg of Cadence. According to Sharon, the following are some of the major features that will be present in OVM 2.0:
- Unified Sequence Methodology
- User's Guide (it's about time!)
- Reset Methodology for Sequences
- TLM Enhancements
- Improvements to the Configuration Mechanism
- Objection Mechanism
The sequence and objection mechanism additions/improvements will be most welcome additions to the library. The common user's guide is also key as it will hopefully resolve some of the lingering issues where Mentor and Cadence have been pushing different visions of how the OVM should be used.