We also should point out what Freecellera is *not* and does *not* aim to be:
- the FSF
- Apache Foundation
- a "governance body" of any sort
Bryan
As I reach out to project leaders I feel like I need to give them a better explanation of what we (Freecellera) are doing here. Here's my rough draft Mission Statement (even though that phrase gives me the heebie jeebies a little):Reasoning behind this:
To promote the development and use of Free and Open Source software in the chip design industry[1].
Free and Open Source Software has revolutionized the software industry and economy, empowering people with the freedom to understand, use, and improve their software tools in any way they please. Somehow Free and Open Source software has yet to take hold in the realm of EDA. The software we use to design and verify chips is closed and proprietary. This ties the hands of the otherwise talented and creative engineers who use these tools which stifles our whole industry. We aim to fix that by giving us all access and ownership of the source code for our tools.Feedback?
Bryan
I like to think of accellera as the K street lobbyists of the EDA world so that would make us the "Bernie Sanders" people. The accellera business model is to charge rich companies for the right to create our languages and standards under the assumption that whats good for the big boys is good for the industry. Well whats good for the big boys is high priced tools that you must buy with high barriers to entry. The industry needs low cost tools that anyone can create.
The software world had the same problem 30 or 40 years ago and their solution was gnu. That is the model that we should emulate. You can design standards that are simple and easy to implement or you can make them so complex that only a company with a 200 engineer design team could handle it. Guess which ones we are getting?
Once you realize how many of their bugs they fixed because some smuck like you ran into one and had to spend copious amounts of your companies time to prove that it was their tool's bug then you wonder why you don't spend your time with a FOSS tool set where you are improving something that you can use for free.
We need to create to hardware equivalent of the gnu tool chain.
--
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...@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/CAPY2A7MUBMynJ%3DSv9iXka72d17PCYsHGtpaDw%2Ba67RdeFWEe2Q%40mail.gmail.com.
Given the expense of UVM-capable simulator licenses, and the complexity and difficulty of UVM, I suspect that any language that can do the verification job will be welcome.Because the vendors are spending a lot of money on tech-support on UVM, I bet. so if an open-source standard comes along, they'll back it.What about faster open-source VHDL/SV simulators that are for synthesizable code? (ie. don't need all the classes). that would seem pretty handy.
What major pieces of software do we need to design chips and is there a Free/Open Source options that is suitable? Here's a quick list that I just came up with:
--
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...@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/CAOP4iL2Zhies1Zsww3OarS6yr%2BerNYoZ3xpWX8zee%2BqyFi27rg%40mail.gmail.com.
I'd like to suggest that we take IP-XACT and add extensions to it, as a basis for almost everything.1) a lot of the truly big corporations already use it, so they'll be more likely to support it - or they may give us support so that they can use some of the tools.2) it already exists as a known standard. Is it perfect? no. But it does support extensions, so we can just add what we want.3) it captures a lot of the design info that any scripting environment is going to need: pins grouped as ports, identification of clocks, resets, address v. data lines, etc.4) it also allows capturing design flow: the synthesis scripts to use, library dependencies, etc.5) it supports configuration management6) it supports capturing design hierarchy with interfaces: so if you capture the design in IP-XACT, you can output all the top-level wiring and propagate timing constraints to lower-level modules if you want to build a testbench for a portion of your design.A good first step would be to build a simple browser/editor (nothing fancy), and an rtl2ipxact importer (again, nothing fancy - just need to load in the RTL, parse the port-names and directions on the entity/module statements; the user can do other clean up later.If someone has a FOSS tool that can read RTL and identify clock/reset inputs, one could add that into that importer script.
On Sun, Dec 27, 2015 at 8:02 PM, Bryan Murdock <bmur...@gmail.com> wrote:What major pieces of software do we need to design chips and is there a Free/Open Source options that is suitable? Here's a quick list that I just came up with:try this:Lets sort these into four groups:1) Platform Tools that are usable by any computer user and are widely available- workstation operating system (yes: linux, *bsd)- userspace os utilities (yes: GNU)- text editor (yes: emacs, vim, eclipse, etc., etc.)- revision control (yes: cvs, svn, hg, git, etc.)- c/c++ compiler (yes: gcc, clang)- environment management (yes: Modules, albion)- continuous integration/regression runner (mostly got it with tools like Jenkins)We probably would not create these tools but we would provide cookbook style instructions on how to install supported repos (Ubuntu, mint etc) and how to get these apps and setup the environment.
2) EDA Tools- multi-language ((system)verilog, vhdl, others?) simulator (don't have)- simulation waveform viewer (yes: gtkwave)- multi-language synthesis (don't have)- place and route (don't have)- timing analysis (don't have)- logical equivalence checker (don't have)- simulation code coverage reporting and analysis (don't have)We would form subgroups to create and maintain any tool that we wanted. For example there is code coverage tool out there that sort of works but has some bugs. I reported one to the owner and he indicated that he had moved on since he did that work and it was no longer actively supported. We could step in and take over any orphaned works.
3) ToolFlow scripts- scripts to drive simulation and back-end tools (maybe not necessary if tools are better?)- job queuing (such as LSF. we have Sun Grid Engine? any others?)- continuous integration/regression runner (mostly got it with tools like Jenkins)This will be our big contribution. IC design scripts are a real joke in this industry. Make files call perl scripts that call eda tools and then call sed scripts to fix the output files before calling the next eda tool. Then someone hacks the whole thing to run recursively . These scripts are a house of cards. No one wants to touch them for fear of breaking something. They are considered "scaffolding" and only have to last until netlist release. We need to design and test these scripts using proper engineering methodology.
4) IP This is the stuff we create.Along with tools we need a few reference designs to show designers what reusable IP actually looks like. A lot of them haven't a clue.
What am I missing?You are missing the big picture. Our industry in now beginning to undergo a huge transformation. Designs have grown to the point where we are now working in a "Big Data" environment. Small Data is very forgiving, You can make all the mistakes in the world and still manage to muddle through and succeed in the end. With Big Data the rules don't change but they are rigorously enforced. This is where we separate the real engineers from the hackers.
John EatonPS: I have been working on a FOSS IC design script suite called socgen. Its available under that name on opencores.org and sourceforge.net. You can download it and try it out. Please let me know how it works. It is as Brooks would say the first attempt that you throw away in order to learn how to design.
This will be our big contribution. IC design scripts are a real joke in this industry. Make files call perl scripts that call eda tools and then call sed scripts to fix the output files before calling the next eda tool. Then someone hacks the whole thing to run recursively . These scripts are a house of cards. No one wants to touch them for fear of breaking something. They are considered "scaffolding" and only have to last until netlist release. We need to design and test these scripts using proper engineering methodology.
So much agreement with your description of IC design scripts. It does seem like this is an area that is a) well within the skill level of just many of us (as opposed to, say, writing synthesis tools) and b) a major pain point just begging for improvement.
4) IP This is the stuff we create.Along with tools we need a few reference designs to show designers what reusable IP actually looks like. A lot of them haven't a clue.I don't think IP is within the scope of Freecellera. Opencores already exists. If they are not the right group to collaborate and drive open source IP then some other group should be formed. I would like to keep freecellera focused on tools.
What am I missing?You are missing the big picture. Our industry in now beginning to undergo a huge transformation. Designs have grown to the point where we are now working in a "Big Data" environment. Small Data is very forgiving, You can make all the mistakes in the world and still manage to muddle through and succeed in the end. With Big Data the rules don't change but they are rigorously enforced. This is where we separate the real engineers from the hackers.I'm going to need more explanation on this. What data are you referring to? What analysis is being done on this Big Data? I have some guesses as to what you are referring to, but I'd rather just let you explain yourself more.
At this point, it feels like we are not talking about the mission statement but delving down into more strategy (how to implmenet that mission), which is great. I have some general strategy guidelines and thoughts on that that I will post. I'm going to ask that we change the subject line and continue this discussion under a topic that will make it easier to find later, especially the very specific IP-Xact discussion that has sprung from this.As for the mission statement, if someone can put that on the website I would love that. I might even get to it myself here soon.Thanks,Bryan
--
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...@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/549755eb-07b7-411c-9513-efbd48b89202%40googlegroups.com.
I'd suggest sticking to Verification IP, for a few reasons:
a) OpenCores already existsb) the type of person who does Verification IP is different than someone who does Design IPc) Verification IP is a big enough problem - let's get success in one thing at a timeas far as SV is concerned: I was thinking of only the synthesizable part of SV (Interfaces and the alternate module ports) just to be able to provide a standardized interface to the class-based world.I've had quite a bit of success on standardizing those interfaces - it saves a lot of work, as well as simplifies it.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...@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/1b1a5699-2e58-432b-a33f-fb243b9578a3%40googlegroups.com.
For anyone in Silicon Valley I have a monthly dinner meeting -
https://groups.yahoo.com/neo/groups/foss-eda-sv/info
- I'd like to ditch Yahoo and do a global group on Meetup instead if anyone wants to assist.
Kev.
--
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...@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/0664601b-2107-4c92-8e2b-b1d1272504d7%40googlegroups.com.