Red Hat Bugzilla – Bug 474980
Review Request: ovm - Open Verification Methodology : IEEE 1800 SystemVerilog standard
Last modified: 2010-10-05 14:39:32 EDT
Spec URL: http://chitlesh.fedorapeople.org/RPMS/ovm.spec
SRPM URL: http://chitlesh.fedorapeople.org/RPMS/ovm-2.0-1.fc10.src.rpm
The OVM is based on the IEEE 1800 SystemVerilog standard and supports design
and verification engineers developing advanced verification environments that
offer higher levels of integration and portability of Verification IP. The
methodology is non-vendor specific and is interoperable with multiple languages
and simulators. The OVM is fully open, and includes a robust class library and
source code that is available for download.
Current, ovm can only be used with proprietary software. I am still searching a way to find an opensource systemverilog simulator that supports ovm.
One short note:
Cadence and Mentor Graphics, the whole EDA leaders have developed and released this ovm under the apache 2 license.
So, my only concern is whether fedora allows its inclusion or not.
Including into fedora will help upstream of iverilog and verilog to support ovm in their future releases.
I just "happened" to have the tar.gz downloaded (and in use since Sept..) so I guess a quick review cannot hurt. So:
fast forward review for release 1.fc11:
* RPM name is OK
* This is the latest version
* sha1sum is OK
ovm-2.0.tar.gz from spec: db292f605d77b14d09ddb0f461942493be18d148
* Builds fine in mock
* rpmlint looks OK
* File list looks OK
* works OK (in use since Sept, as I have said) at least with Questa
From my point of view, it's OK. Eventually it could go to RPMFusion if legal says "no go" here.
So, just to be clear... this is content that is only useful with proprietary applications, right?
There is no relevant guideline to match this. Our emulator policy is the inverse (you can include the FOSS emulator, if there are FOSS ROMS). I think this needs to go to FESCo for review (http://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content):
"All content is subject to review by FESCo, who has the final say on whether or not it can be included."
I'll put this on FESCo's radar. For what it is worth, I support including this FOSS licensed content, as it "enhances the OS user experience" has "an open source compatible license", and is not "legally questionable", the main three barriers for content inclusion.
Will be discussed in the next FESCo meeting (1/16 - noon EST, 17:00UTC)
I just want to remind FESCo, that ovm is used in high end commercial simulators and its apache 2.0 license and its inclusion in fedora will help in the creation of tools around ovm by the community. Other opensource upstream projects can update their simulators accordingly. Someone has to make the first step.
Currently there are some tools (in alpha version) which are available online, however too early for normal usage.
If ovm is approved by fedora, I'll also bring in vvm which is in the exact situation as ovm.
FESCo believes that this is of value. However, we'd like to see iverilog or other similar tools for dealing with this content in at the same time, realizing that those tools might not be useful right now, however.
Given FESCo's approval of this item, I'm lifting FE-Legal.
* Naming is okay,
* Licencing is ok,
* Paths are ok,
* Chmods are ok,
* Install scripts are ok.
rpmlint doesn't find errors or warnings.
Package Change Request
Package Name: ovm
Short Description: Open Verification Methodology : IEEE 1800 SystemVerilog standard
Branches: F-9 F-10 EL-5
Given that fesco wanted tools at the same time, would you like to hold off on cvs until one of those is ready also?
well, it won't happen before 6 months.
the intention of pushing it into fedora was to encourage EDA developers develop tools around it.
Right, the intent was to get iverilog (there's some code I can download from their webpage) into Fedora, realizing that it might not be usable with this particular content for 6 months.
Yes, this is the current status.
--- Forget "software" for a moment :
For any hardware designer, the basic design methodology is :
design <-> home made customized scripts <-> EDA tools
this combination gives
=> developing hardware
(with at least 12 different EDA tools to sign off a project)
This somehow differs from the popular "software" methodology: code, compile and run.
The questions you might be asking are :
- why complain when companies have opensourced their libraries ? (forget the opensource community, the later will _never_ give you such verification methodology before the next 20 years, because it costs millions of euros to develop it)
- can these libraries(text files) be incorporated directly into the user's HDL design?
You may have heard "open hardware" and opensource community are proud of it.
If you look closer (opensparcT2 for example) at the code, this open hardware was designed under proprietary eda tools, same applies to opencores designs.
I believe building an opensource design and simulation platform -FEL- (providing software), with inclusion of ovm and vmm, will encourage digital designers extend their "open" hardware desire to "design open hardware with open source software".
This is a problem and a lack in the current opensource software and hardware communities. The only way to solve it is "someone has to step in first and take the lead".
With our FEL we have already taken this leadership to promote open source _content_ and ovm is an open source _content_.
Maybe from mailing posts with respect to OVM :
will clarify any of your doubts.
Well, you are welcome to bring it up again to FESCo, but the decision made last time was that something that could at least potentially use the content should be added at the same time as this content package.
Unfortunately I cannot attend FESCo's IRC meetings due to overlapping with personal matters, but I must stand on Chitlesh's side here (ref #14 )) and support him.
I for one would have loved to use a rpm for OVM at the time that I deployed the software in the company I work for (see #3). And no, except for a few minor tools, the game around real EDA has no open-source players, all big boys use products from one of the three major players in the market. Stalling even the few available open source packages because in this moment there is no free tool to use them is just an administrative block and with no support in any of the guidelines I know of.
Note that this is the exact opposite case of games with free engines but encumbered game data (which was downloaded at install time from links outside our repos): this time we have free content but no free engine to use it with. Pushing the content _might_ speed up the engine and harm no one; on the contrary we would once again be the leader of the movement. No content at all will definitely not help anyone. It's like saying "Look, we have free oranges ! Take as many as you want !" but you reply "No, I will not eat your oranges unless someone provides a free knife for peeling them, too !" Or in a geeky speak, "Here, have some free beer !" "No, thank you, I cannot accept it, I have no free bottle opener!"
And for what it's worth: 10 days ago I had the opportunity to attend a meeting with a manager working for one of the top 3 EDA tools manufacturers mentioned above. It just happened that his next meeting scheduled during that week was with the other players of the OVM game, in view of releasing OVM 2.1. In other words, there is a real incentive over this project.
"If the content enhances the OS user experience, then the content is OK to be packaged in Fedora." that is why we said that we would like to have iverilog or some other tool for using the content in at the same time. understanding that the tools still have a way to go and are far from feature complete.
I see no relation between "If the content enhances the OS user experience, then the content is OK to be packaged in Fedora" and "the user experience must be provided only by free tools".
Would iverilog be nice to have? Definitely yes. Should its presence at the same time with OVM be mandatory ? Absolutely not. Users might be using EDA software from other sources. Actually I bet that 99% percent of them are using commercial tools and I also bet that in an enterprise environment they always will.
<small rant on>
In the company I work for we use several commercial EDA tools. Since July 2008 the number of engineers interacting with OVM increased from 2 to 25 and their number will increase in the future [, depending on the projects that end / new projects that start]. How would not the presence of OVM in a repository enhance these users' experience ? As sysadmin I would definitely have preferred to do "yum install ovm.el4" instead of "tar xzf ovm-2.0.tar.gz"
For what it's worth and completely unrelated, we have a very small team of courageous people who use gtkwave from EPEL when the number of licenses for the commercial tool is insufficient.
"the user experience must be provided only by free tools". goes with https://fedoraproject.org/wiki/Overview "Fedora is all about freedom and rapid innovation." it goes against fedoras goals of "Fedora will always be free for anybody, anywhere, to use, modify and distribute."
not having iverilog in means that ovm is only available to a subset of people who have access to the closed proprietary tools. We want you to get this in, all we are asking is to provide a way for everyone to use the content. even if for now its limited in functionality.
Our intention is not at all to keep this out.
Re. comment #19,
> As sysadmin I would definitely have preferred to do
> "yum install ovm.el4" instead of "tar xzf ovm-2.0.tar.gz"
Until that time, you could make a local yum repo and publish the RPM there.
FESCo has voted to continue to block this content, on the basis that it does not "enhance the OS user experience". Imagine this:
I'm Joe User, who wants to use ovm. I type 'yum install ovm iverilog' and expect to be able to do whatever ovm does (and I'll have to admit ignorance as to exactly what this is - I'm not a hardware guy). I find that I can't do that, and instead have to buy some expensive proprietary tool in order to make use of this free content.
We're fine with the concept of ovm being in Fedora, but we also want something that is able to use this content, even if it's at a very primitive level that no one actually *would* use it in a production environment. The link that Chitlesh posted earlier to upstream iverilog forums seemed to indicate that they had other priorities other than making this work.
(In reply to comment #20)
> not having iverilog in means that ovm is only available to a subset of people
> who have access to the closed proprietary tools. We want you to get this in,
> all we are asking is to provide a way for everyone to use the content. even if
> for now its limited in functionality.
iverilog is under the fedora umbrella since one or two years. perl-Verilog has incorporated early perl support of SystemVerilog
I'm closing this bug:
Reason : No simulator currently available under fedora
If the situation changes, I will still be interested to push OVM into fedora repositories.
Following Veripool's announcement,
This version adds support for 99% of the SystemVerilog 2009
standard, and also fixes a number of preprocessor bugs and
I'm reopening this review request since no item is blocking it's inclusion into Fedora repos.
In the meantime, perl-Verilog-Perl 3.300 is being tested through our testsuite, before releasing it into our fedora repositories
Spec URL: http://chitlesh.fedorapeople.org/RPMS/ovm.spec
SRPM URL: http://chitlesh.fedorapeople.org/RPMS/ovm-2.1.1-1.fc12.src.rpm
Package Change Request
Package Name: ovm
Short Description: Open Verification Methodology : IEEE 1800 SystemVerilog
Branches: F-12 F-13 EL-5 EL-6
Great news Chitlish. :)
I don't see any reason why we can't include this now.
This is a Package Add request, not a change request. :)
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.
More information and reason for this action is here: