Yet another thread about what we could be doing

[Tudor Timi]

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 FuseSoC

The 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)

[Bryan Murdock]

On Wed, Aug 17, 2016 at 3:50 PM, Tudor Timi <tudor...@gmail.com> wrote:
> 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.

Thanks, Tudor. Here is my vision that I posted a while back:

https://groups.google.com/d/msg/freecellera/hpRW3Va9Ckk/kewdbkwGCAAJ

It does state that we want to have Free Software for all the tools
needed to design chips, but you are right that we need to start with
something small and reasonable. Baby steps first. The rest of your
post gave some great examples. Note that GNU (which aimed to replace
UNIX with Free Software, and after many years and with some big help
from the Linux project did finally succeed) took a similar approach:
starting off by writing small and simple utilities.

Bryan

[Erik Jessen]

I would recommend SVEditor as a great base to work from.

1) it's Eclipse-based, so you have lots of addons and a well-known base.

2) he's got an extensive SV parser, so all you need to do is process data-structures that have already been checked.  There's a saying that 80% of writing software is input validation - SVEditor already did the work.

3) The author is EXTREMELY responsive - if you file a bug report, it's typically fixed within a couple of hours.  He's a professional software engineer - and brilliant from personal acquaintance.

Useful tools that are not available anywhere from BigEDA:

a) SV linter (unused variables inside of classes, having 'public' properties instead of 'private/protected' with getter/setter, etc.

    The great thing about a linter is that you just keep on adding rules, one at a time.  So with just a week's work you could have a couple of rules, and anybody can add new ones.

b) enhancing SVEditor to be able to do refactoring

      b.1) rename a class property to something else

      b.2) change a class property to be 'protected/private' and replace all uses of the public property with getter/setter.

Useful tools that are very expensive from BigEDA, but are all based on expired patents

c) A simple property-checker using BDD (Binary Decision Diagrams).  BDDs take up a lot of memory and are really slow, but for small FSMs today's PCs can easily run them.  Formal verification at the small FSM level is still very useful.

I'd also suggest taking existing open-source IP-XACT tools and hooking into SVEditor, so that one could extract IP-XACT structures from SV code that has been sucked into SVEditor, or create SV classes or module hierarchies from IP-XACT input.  And of course a check to verify that the IP-XACT and SV code are equivalent.

IP-XACT allows one to capture a lot of information - like register maps - and so with IP-XACT one can output UVM register packages.

Erik

--
You received this message because you are subscribed to the Google Groups "Freecellera" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freecellera+unsubscribe@googlegroups.com.
To post to this group, send email to freec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/freecellera/114cf7bf-584f-4b10-9eb3-8f6170a8db52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.