After today's heated discussion I wanted to throw in my 2 cents:
I don't think we're at the point where we can realistically think about replacing BigEDA tools with open source. At the same time, I don't think this should necessarily be the goal. I'm pretty sure software companies use a mixture of commercial, open-source and home-grown tools. Sure, open-source may have "won" in the software world, but we're nowhere close that point. I'd much rather concentrate on providing stuff that I can't get from the Big3 or maybe small stuff that I think I can do better. If it's not something I'm going to ultimately use, I won't have any interest in developing it.
I can give you an example: I do a lot of posts about the UVM register model and I thought that I could build a little tool that can read an IP-XACT XML and spit out SV code. I use Olof's
ipyxact to quickly hack something together (the result is
here, by the way, I wanted to do a post about it sometime soon). I'm pretty sure Olof uses ipyxact for hist stuff and that's why he's interested in maintaining it. The other open-source libraries I used are also used by a lot of other people that are interested in maintaining them, because they want to make their jobs easier. Someone can take my code and modify it to suit his/her needs or could say "hey, you're onto something there, you wanna develop it further?". This is, to me, an essential part of open-source. Finding stuff, developing parts that aren't there and gluing it together to get software that does what I need.
Other good examples of people who eat their own dog food:
- Puneet with
Vlang who was fed up with the inflexibility of SV
- Aliaksey with
WaveDrom, which is a great example of a very nice tool that's ridiculously useful, but the Big3 never cared in providing anything
Other times, someone might want to develop a free alternative to already existing software, because he/she (and a great deal of others) can't get access to commercial tools, because of their ridiculous price tags.
Yosys is an example of this that pretty much enabled a lot of people to become hobbyists.
And sometimes, I might just want to start doing something just to explore and learn. As an example here: I was talking to Olof about his idea of generating a lot of his code for ipyxact. The question popped up: can't we generate it out Accellera/IEEE's XML Schemas for IP-XACT? I tinkered with the idea while I was killing some time, partly because of interest, partly because I wanted to learn more about XML, partly because it was a puzzle I just HAD to solve. The result is
here, but I never really used it. Once I got to a point where I thought I was done, I kind of lost interest. Regardless, the code is there for someone (or even for me) to discover and use in a future project.
What I think we should be talking about are ideas about tools we might have or what we think is missing in our (professional) lives. I could name a few things off the top of my head I've thought about. Maybe eventually after some discussions there's some overlap and we can get something going:
- tool that can draw the topology of a UVM environment
* another thing I wanted to do a post about (on the extremely long backlog)
* I think only Aldec offers anything here
* pretty sure a lot of people would be interested in this
- tool that can take SystemVerilog assertions and generate procedural code
* describe a protocol with assertions
* generate code for monitors/drivers out of it
* only have to modify assertions when something changes
* needs SV/SVA parser
- SystemRDL to IP-XACT
* again useful for all of my UVM REG posts, because it should be easier to write RDL code than IP-XACT
- tool for handling UVC packages and dependencies
* not really fully thought through
* similar idea to
FuseSoCThe question is: what are you missing now? I'm pretty sure for most of you working in verification like me it's not a new mixed-language simulator.
(post not proofread)