freecellera mission statement

[Bryan Murdock]

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

To promote the development and use of Free and Open Source software in the chip design industry[1].

Reasoning behind this:

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

Footnotes

1.Not exactly sure what to call our industry.  EDA?  Chip Design?  #SemiEDA? (kidding, I think...)

[Bryan Murdock]

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

[Kevin Cameron]

A problem with Accellera and the IEEE, is that only vendors have been turning up. Users need to be encouraged to share the problems they need solved so that the OS developers know what to do - most OS EDA efforts are copies of dysfunctional (old) standards, rather than bleeding-edge development that is doing new things beyond what the commercial tools do.

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.

[Ouabache Designworks]

On Saturday, December 5, 2015 at 6:30:24 AM UTC-8, Bryan Murdock wrote:

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

To promote the development and use of Free and Open Source software in the chip design industry[1].

Reasoning behind this:

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.


John Eaton













 

[Bryan Murdock]

On Sat, Dec 26, 2015 at 9:58 AM, Ouabache Designworks <z3qm...@gmail.com> wrote:

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.

 Hey, John!  Good to hear from you (for those following along, we worked together years ago).  Yes, gnu is exactly what we need to emulate (but sorry, I'm not into politics enough to understand the lobbyist/Bernie Sanders analogy :-).  The GNU people sat down and made a list of all the software that needed a Free replacement and then got to writing code to create those.  Lucky for them one big piece, the OS kernel, was provided by another group (Linus Torvalds and friends).  We need to do the same.  Lucky for us a lot of what the GNU and Linux people have done fills many of our needs.

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:

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

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

Less prominent but pretty necessary pieces:

- environment management (yes: Modules, albion)

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

- simulation code coverage reporting and analysis (don't have)

- continuous integration/regression runner (mostly got it with tools like Jenkins)

What am I missing?

Bryan

[Erik Jessen]

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.

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/CAPY2A7MUBMynJ%3DSv9iXka72d17PCYsHGtpaDw%2Ba67RdeFWEe2Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Bryan Murdock]

On Sun, Dec 27, 2015 at 9:08 PM, Erik Jessen <nbje...@gmail.com> wrote:

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.

That is something I have thought about too.  I'm not sure how important to our success it would be to support *all* legacy code that everyone has (which would require supporting all of the SystemVerilog subset that UVM uses, at least).

On one extreme is not bothering to support any legacy code, rtl or verif.  Then we could all get behind some new better language (e.g., MyHDL,  ParC, something we invent?) and forget verilog and vhdl.  Who would be able to ditch all their legacy code and be brave enough to use such a tool?

The other extreme would be to try and support *all* legacy code so it would be as painless as possible for people to switch.  That sounds daunting.

In between those two is the hybrid approach.  The most important legacy code to support would be the synthesizable code.  If we write a multi-synthesizable-language simulator that also supported a nice new verif language (which really could be just about any existing high-level general purpose language, or preferably more than one of those) then people would only need to re-write their testbenches in order to adopt this new simulation tool.  And honestly, who doesn't re-write at least some of their testbenches for every new project, even if re-using design IP?

That hybrid approach is still not an easy task, but it seems the most doable to me at the moment.

Thoughts?

Bryan

[Ouabache Designworks]

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:

https://www.semiwiki.com/forum/showwiki.php?title=Semi+Wiki:EDA+Open+Source+Tools+Wiki

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 Eaton

PS: 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.

 

[Erik Jessen]

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 management

6) 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.

--
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.

[Ouabache Designworks]

On Mon, Dec 28, 2015 at 9:54 AM, Erik Jessen <nbje...@gmail.com> wrote:

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 management

6) 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.

I am using IP-Xact in my socgen project and am currently rewriting everything to conform to IEEE1685-2014. It is probably the closest thing we have to a good standard but it does have some problems.

One of the biggest ones is that it supports extensions. Back in the 90's the PCB world created a standard called EDIF to solve their problems with interchanging design files between different vendors systems.

It was a failure because each vendor created their own "flavor" of EDIF files that the other vendors couldn't use. Vendor extensions could easily produce the same schisms in IP-Xact and cause its failure. You

have to build that capability into the standard and that is hard.

I had been sitting in on accelleras IP-Xact technical team phone calls and had even help teach a tutorial at DAC a few years ago. But then they decided to terminate access for anyone who did not belong to a accellera member company. Not only do they not seek out input from the industry, they fight you when you try to help them.

John Eaton

 

 

[Erik Jessen]

John,

I'd like to work with you on your socgen with IP-XACT - I want to add extensions for UVM, and DPI.

I personally think UVM testbench creation is far too complex (yet also automatable).

My personal thought:

1) there are lots of C# programmers out there, who understand inter-process communication, etc.

    C# programmers are a LOT cheaper to hire, and there's a lot more of them, than there are ASIC designers who also know OOP programming AND have spent a few years learning UVM.

2) C# compilers are going to run faster executing the same functionality as SV compilers will run OOP-SV code, simply because there's a lot more value to vendors of C# compilers to improve the speed.

3) An RTL simulator with DPI and C# will therefor be a preferred route for all companies, vs. a UVM simulation.
    With regression scripts and large parallel suites - it'll be faster/cheaper to have 2x the hardware nodes each running a sim at 80% of speed, than 1x the hardware nodes running UVM at 100% of speed.
    And of course, if you can't find UVM-knowledgeable personnel to code those tests, it won't matter how fast your compute-grid is.

[Bryan Murdock]

On Mon, Dec 28, 2015 at 10:38 AM, Ouabache Designworks <z3qm...@gmail.com> wrote:

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:

https://www.semiwiki.com/forum/showwiki.php?title=Semi+Wiki:EDA+Open+Source+Tools+Wiki

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.

Agreed!
 

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.

Yes, and I think the subgroup idea works for any type of tool, not just the ones in this group.

I'd be interested in the name of the coverage tool.
 

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.

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.

John Eaton

PS: 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.

Very nice.  I think a big part of what we need to do is simply help make projects like this known.  It's that evil "m" word we all love: marketing.

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

[Tudor Timi]

One quick contribution from me before we start splitting this up into other topics.

Supporting SV might be a bit too daunting, seeing as how even the big EDA companies struggle with it. I'm also not fully sold on the "one language to rule design and verification" thing. I like the e/Specman approach a lot of connecting the verification tool to the HDL simulator via the programming interfaces made available (e.g. VPI for Verilog). Puneet is already doing something similar with his Vlang project and that's something I could see myself rallying around. HDL simulators already exist, like Verilator and Icarus, the latter already having been integrated with Specman (on EDAPlayground).

I also saw some formal tools out there (for example, Spear - http://www.domagoj-babic.com/index.php/ResearchProjects/Spear). These lack the user friendliness of commercial model checking tools, but could for sure be enhanced with nicer frontends to parse SVAs or PSL. I'm pretty sure I've seen Spear used as a solver in a commercial tool.

Also, you mentioned that IP isn't in the scope of Freecellera. By this I think you mean design IP, as UVM, which isn't a tool is under the stewardship of Accellera. Verification IP is treated a bit differently.

[Olof Kindgren]

Hi Bryan and others,

I'm really happy to see this effort. Open Source EDA is on the way, but still got a long way to go.

For this reason we launched the FOSSi Foundation earlier this year (http://fossi-foundation.org/). From what I can read here, we seem to have common interests.

The current board of directors are mostly people who have a background in the OpenRISC project, but we have moved to cover Open Source Silicon (this is what we call our industry, btw) in general. We see an increasing interest in Open Source Silicon, which is very clear from both the media coverage of projects like RISC-V and Project Icestorm, as well as the number of people who come to our yearly conference (http://orconf.org) where we had almost 100 participants this year. I would like to see some interaction between Freecellera and FOSSi Foundation.

I see that you have identified some key areas for innovation. We are working along these lines as well, and one particular area where we saw a lot of interest at orconf was for a common IR (Intermediate Representation) language. There have been an explosion of new HDL languages in the last year, such as Chisel, MyHDL, Migen, HardCaml and others. The drawback here is that they still have to be compiled to verilog to be useful, which is a bit awkward. What we hope to see instead is a new language that is better suited to be an IR, to make it easier to have interoperability between high-level languages and tools

Anyway. Good luck with Freecellera and hope to hear from you

//Olof Kindgren

[Ouabache Designworks]

On Monday, December 28, 2015 at 9:12:22 PM UTC-8, Bryan Murdock wrote:

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.

The IC design team that I was on @ HP spent way to much of our time creating and maintaining scripts. HP did have cross the board licensing with the four major EDA tool vendors so we could have found something that worked and adopted that but we didn't. The problem was that whoever championed a tool and brought it into the team then became the defacto support person. We had 61 engineers spread over 4 divisions and 2 continents. Imagine coming in and finding email from Bangalore telling you that your tool wasn't working. Now you have to try figure out how to fix it.

The big problem was that we kept running into new requirements. We did a chip with STM that had 4 usb ports on it. ST wanted us to use their dual usb pad with two adjacent usb ports. We used a pad muxing tool that only understood one pad per port. If that had been a commercial tool then we would have had to rely on the tool vendor to find a solution. But since it was an internal tool written in perl then I could go in and add new code to implement a complete new packaging system to solve the problem. Or I could add one new variable that disabled printing the pad into the output file and enter the correct code by hand somewhere else in the file.  I hacked it and we had the design working the same day.

The big problem with that is that you are testing your code on a live database. You are working without a net and always have to check the produced rtl for errors. A freecellera tool set can be developed at leisure with its own test suite. As users run into new requirements they can be added and tested before the next user needs it. You can get a lot of users testing it under a lot of different cases

 

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.

Its not. But it is important that we provide reference designs that the user can run "Out-of-the-Box"  to see exactly how our tools work.

I have been taking cores from opencores.org and making them reusable in my socgen toolset by adding IP-Xact files refactoring the code and including them with my code.

For example if I find an embedded design with a test suite then I usually find that they have about a dozen different programs that they can compile and run on a testbench. They will have a script that runs all of them in sequence.

The first thing that I do is to add support for multiple testbenches. A testbench for Icarus is written in verilog and can use non-synthesizable code, for verilator it is C++ and its code must be synthesizable. I can easily chose either one  on a sim by sim basis. Each sim must have its own test sequence. You could simply start the clock,give it a reset and then wait for it to finish and that would work for all sims, in fact that is how most of them do it. But if your code comes up and prints a welcome message then you need to make sure that it is the right message, and each program needs a different message so that we know that we loaded the right bits and each sim must have its own time out and clock period values.

Each sim must be able to specify what data is to be dumped. Dump_all only works on small short tests.

Each gtkwave session must save its setup file. It takes time to recreate them every time.

Each sim must have its own subdirectory to store all of these files.


I also use test fixtures along with the testbench. The component under test is an IP-Xact enabled design as are all the BusFunctionalModels(BFMs). So the test fixture is simply an IP-Xact component  and design file. It is trivial for a tool to read IP-Xact files and create a set that instantiates  the component with its default parameters and connects each pad to a wire with the same name.

The BFMs are all created in a IP-Xact design file and it can be reused for all the sims.

The testfixture is instantiated by the testbench and each sims parameters are passed down along with 4 signals

  1)  Clock
  2)  Reset
  3)  Fail ( if the testfixture finds a problem)
  4)  End ( if the testfixture reaches the end of the test)

If the time out expires before the End signal then the sim terminates with a timeout error. An error count is always provided at termination.

Each component must autogenerate its own test fixture for BFMs but you will also need board level simulation. There your fixture will be the board level product schematic. This means that IC and PCB designers must use the same design files.
 

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.

Its simply the case that as the number of things that you have to deal with increases then you have to change how you do things. I did product design back in the day when everything was through hole components. We would get in ten lap proto PCBs and we would fire up our soldering irons, raid labstock and start building and testing boards by hand. Later when you had to build 100 production protos, we used the wave solder machine.

If you receive one piece of IP for your chip then you can go in by hand and figure out how to incorporate it into your SOC. That won't work for large numbers but thats what many soc designers are still trying to do.  Most of my success in design for reuse has come from taking well know manufacturing techniques and applying them to SOC design. Designers need to understand that a lot of things that they have done over the years on small designs simply do not work when the designs gets bigger.

A good example of this is search paths. Search paths make it real easy to set up any EDA tool. Its like making a shopping list for costco and then in the store you follow a white line through every aisle and anytime you see something on the list you grab it and put it in the cart. When you have everything you head for the checkout.

Except now your not in costco, you are in that warehouse shown at the end of "Raiders of the Lost Ark". And `including your defines.v file stopped working because you added some new ip and they also have a defines.v file spelled the same the same way that you spelled yours. And theres a big fight because you use defines.v to configure your IP and you have two different designers each needing a different configuration.

Search paths don't work in Big Data.
 

 

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

Good Idea.


John Eaton

BTW: That coverage tool is called covered.

With ubuntu   sudo apt-get  install -y covered

[Ouabache Designworks]

On Saturday, December 5, 2015 at 6:30:24 AM UTC-8, Bryan Murdock wrote:

Ok So back to the original question.

I do like Olofs suggestion of "Open Source Silicon" for a name. Its broad enough to give us a lot of flexibility. The only problem is that while our tools are FOSS we are not limiting their use to free hardware designs. The Open Source is for our deliverables only.



I think that we need to call special attention to how Open Source Software only succeeded because they were able to establish industry standards for  designer deliverables. Here's how to write code that can be run under POSIX compatible OSes. Heres the format of an ELF file.  Heres how to pass your symbol table to a gnu debugger. Without that there is chaos. We are lacking that in the IC world and we have chaos.

How about:


To promote the development and use of Free and Open Source EDA software for the creation of reusable silicon ip.



John Eaton





 

[Erik Jessen]

I'd suggest sticking to Verification IP, for a few reasons:
a) OpenCores already exists

b) the type of person who does Verification IP is different than someone who does Design IP

c) Verification IP is a big enough problem - let's get success in one thing at a time

as 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/549755eb-07b7-411c-9513-efbd48b89202%40googlegroups.com.

[Ouabache Designworks]

On Tuesday, December 29, 2015 at 11:07:57 AM UTC-8, Erik Jessen wrote:

I'd suggest sticking to Verification IP, for a few reasons:
a) OpenCores already exists

b) the type of person who does Verification IP is different than someone who does Design IP

c) Verification IP is a big enough problem - let's get success in one thing at a time

as 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

Verification IP is useless unless you have something to verify. Back when HP made test equipment they had a hand help logic analyzer and it was shipped with this little butterfly pin with 2 flashing leds. So rather than having to rig up a test board you could turn this on and probe it with the analyzer. They were not in the flashy butterfly pin market but they used it to intro the product to their customers. That's called marketing and if you want this project to succeed then we better start doing it better. 

We aren't in the business to develop IP but we should provide some from other open source projects that have been configured to run under our tools.


John Eaton

 

[Erik Jessen]

Agreed - my thought was that we'd verify OpenCores and the Leon2 from IP-XACT Accellera.

Since other people presumably are familiar with those cores (and are using them), they'd quickly be able to take whatever Verification IP we've developed, and deploy to their existing designs.

We could also release Verification IP into the OpenCores (or referencing it).

Some useful examples would be: C code that would configure an OpenCore block into various modes.  This could be run via cosim, or executed on the real hardware.  Demonstrating vertical reuse is pretty important.

--

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.

[Ouabache Designworks]

On Sunday, December 6, 2015 at 11:58:07 AM UTC-8, Kevin Cameron wrote:

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.

 
 Kevin,

Daniel Payne from semiwiki does a monthly EDA tools lunch in Lake Oswego, Or. Its not exclusive to open source but there is a lot of overlap with your group. You may want to contact him to see if a meetup could work out for both.


John Eaton

 

[Erik Jessen]

I'm in LA...

--

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.