Today I attended an OVM World seminar in Ottawa. There were three presentations. The first presentation was by Hans van der Schoot. Hans is a very interesting, brilliant and passionate engineer, which made this a fun presentation to watch. Shame on me for not having written down the names of the two other persons presenting after Hans: there was an engineer from Mentor and one from Doulos. All had presentations with lots of code examples in them, which to me is a plus.
Of database vs. object oriented code
A very common problem in ASIC verification is the modeling of configuration information. In typical object oriented code, you will build a nested structure of configuration objects, through which you access relevant information for different components of your environment, or for the DUT. For instance, when you access configuration, it may look like this:
// Object Oriented approach
Config config = new;
config.pci_transactor.bfm.en_err_injection = 1;
config.packet_scoreboard.tolerate_discards = 1;
In OVM, they propose an alternative to this form of nested strucure. It’s a database, indexed by strings:
// Database-like approach
You can also use wildcards in the argument strings. We are not far from using SQL syntax here! The main advantage of the database approach is that you do not need compile time binding of configuration objects. Say for instance you work on a block level environment where you do not have pci_transactors. Ideally, you do not even want pci_transactor configuration objects in your block level environment because they consume memory, create unnecessary dependencies, and extend you edit-recompile cycle. In Object Oriented code, it’s very hard to come up with the right structure to swap in and out those undesired members of the Config class. You can always do it with compiler #ifdef directives, but it’s hard. The database approach is more flexible. However, I would not be surprised if it cost more in terms of simulation speed.
A similar approach with the OVM Factory allows great flexibility when building an environment: instead of calling the constructor of your verification components directly, you can call a factory function, asking it for an object type with a simple string! The factory function returns an object of the specified type… or an overloaded version of your choice, which you specify in your testcase through another function. Let’s see this in code:
// Call a factory function, cast the returned
// object to a compatible instance
Now the interesting part is you can instruct the factory function to replace the returned object of every call requesting a normal_bfm, to return a error_injection_bfm instead, like this:
// in the testcase
Of course, all this requires registration of types and instances in a database, but it saves having to extend and overload instances in testcases. IMO it is always a big pain to overload existing instances at runtime because you must do it at the right time, between the build phase and the run phase, plus you have to redo the connections and the constructor (the new) arguments. It’s even a pain trying to explain it. I don’t know if SystemVerilog classes have static constructors, but I imagine this would be how their sole presence anywhere in a compilation unit resulted in their registration into a global database.
This concept can easily be extended to other aspects of verification environments, wherever deeply nested data structures are used.
OVM licensing questions
At the end of the seminar, there were many questions about the open source nature of the OVM. The answers in a nutshell: yes you can copy and redistribute it under the terms of the Apache 2.0 license (i.e. do not claim it’s yours, leave the copyright notice intact, etc. – read the license it’s all in there); no you do not have to make all your proprietary code publicly available just because you use an open source library if all you do is use the library internally for your own development.
Opening the OVM bug database
There was also insistance by some of the audience on the importance of making the OVM bug database open as well. Mentor and Cadence said they were tracking OVM bugs through their respective internal databases, but they were also trying to find a way to make these bugs public. One of the EDA vendor said they were going to publish known bugs using release notes at each OVM release, but that is not real time information about current bugs. But the nice thing is representatives from all three companies, Doulos, Mentor and Cadence all agreed that it was an important thing to do.
As far as reporting bugs through a public database, this is a delicate as anyone who has worked on project with a great number of users can attest: misunderstandings, duplicate bugs, and feature requests may eventually pollute the bug database. Not necessarily a big deal if users search through bugs before entering what they believe is a new bug, but most times users that hit the bug database have reach a high level of frustration, and they want their issue resolved now. Nevertheless, a public bug database is better than nothing at all. And the OVM user community is quite small compared say to a large open source project like gentoo, so I don’t think users will overwhelm the OVM developers with false/duplicate requests/bugs in the bug database.
Nothing stops anyone from opening a public bug database for the OVM and start using it… and same for creating a public repository for the source code as well. It is so simple now with the internet, I would chose savannah simply because it supports git, but any public server with a decent versioning tool would work.
Accepting contributions from the user community
There were two people asking on how they plan to accept contributions from the community. Their answer was that both Mentor and Cadence have people participating in the forums, and contributions made through the forums would be considered for inclusion in the OVM. The EDA representatives pointed out that contributions cannot be accepted as-is since they run tests on OVM before releasing it to insure its quality. I guess they could open source the OVM test suite as well. They could also use Linus’ philosophy: only grant write access to the source code database to trusted users with a proven track record of useful contributions or bug fixes.
ASIC register modeling
There were also talks about open sourcing the asic register modeling library, but no commitments were made. (I might have gotten the name wrong here since I am not a user of such library.)
There were questions about support for the OVM: the EDA user community is accustomed to email support with EDA vendors. But the EDA guys really seemed hesitant to commit to email support for helping users with the OVM… I mean they are giving out the OVM source code under and open source license, and people expect free support? I think the EDA vendors do not have to provide free support for the OVM. I have paid for support of open source tools in the past and it’s the normal way of compensating someone for their time. Companies use linux and they still pay their IT staff to support the “free” OS!
One of my favorite way to obtain support is through public IRC channels. I get support for gentoo and Tango in their respective IRC channels. Of course, one cannot go to an IRC channel, get help, and never give back, because it is simply not fair: you are expected to give when you want to be part of a community, it’s not just about taking for yourself. Nevertheless, this maybe a good way for EDA vendors to provide support for the OVM: users helping users on an IRC channel on freenode, with OVM developers on the channel from time to time. After a while, users might be able to support themselves.
All right, that’s what I have to say about the OVM. I congratulate Mentor and Cadence on releasing the OVM under an open source license, a first for an EDA company!