Please write down your items what this project should comprise, so we can create a project goals / mission page or statement.

• Create a core library “CoreLib” for

  • Often used data structures with a unified interface
  • Useful helper function
  • Synthesizable RTL gates described as one-liners
  • Generalized logging (to console/screen and log file)
• Decrease code duplication, reinvention and incompatible package mixing

  • Up stream existing code to CoreLib
  • Avoid mapping function between incompatible packages
  • Use CoreLib as a replacement
• Shorten release cycles compared to IEEE P1076
• Collect interface descriptions, which will be introduced with VHDL-2017 (“Interfaces”)
• Create and maintain a list of existing VHDL related open source projects

  • Present a project abstract
  • Link to sources
  • Link to documentation
• Create and maintain a list of VHDL related resources (inherited from old vhdl.net page)

  • Books
  • Blogs

• Create a common frame work for verification that competes with UVM

  • Ideal, but can we merge UVVM, VUNIT and OSVVM Plus?
  • Fall back, create models that interoperate
  • Adopt a methodology that transitions well to VHDL-2017 interfaces?

• Merge transcripting control - ie: output of test results - one file vs having different files

  • Ideal
  • Fall back?

• Merge logging packages

  • Ideal, but can it be done?
  • Fall back, create a methodology for the different logging packages to interoperate

    • Ideally they would have a means to automatically detect each other and report a summary via any one mechanism

• Develop shared packages using an agreed upon logging and transcripting mechanism

Some goals for CoreLib

• CoreLib should add significant value for everyone working with VHDL verification regardless of complexity.
• CoreLib should be a responsive project

A bit vague so let me elaborate

• Open source projects are always short of resources so we need to be focused. That's why my first goal is about verification and significant value. It may be tempting to add something “nice to have” and then forget about the maintenance and support costs coming later.
• With everyone I mean that CoreLib should be usable regardless if you're a design engineer verifying your own code or if you're a dedicated verification engineer, regardless if you use ModelSim PE or some super version. With UVM I see verification experts sitting in separate teams using high-end tools and that's a major disadvantage. Verification must start with the RTL designer to be effective.
• With regardless of complexity I mean that we should support advanced testing but that must not imply that simple testing becomes complex. UVM promoters often talk about the major initial effort like something that is required to be able to do advanced testing later on. I don't see why it has to be like that. It also means that UVM is not for everyone in every situation which is another disadvantage.
• With responsive I mean we should be setup to continuously deliver new functionality so that bugs are quickly fixed or new features are quickly integrated. Having a good test automation setup so that we can make quick bug fixes and immediately release them with confidence is one thing. When it comes to feature development it's also a question of mindset. I rather evolve in small steps than aim for the end goals directly. That also gives us the chance to figure out how the end goals should be achieved. UVM is a standard and that limits their responsiveness. Another disadvantage.
• The bullet above means that I think we should have interoperability between existing libraries before trying to merge them. I've already discussed these issues with some of you and it's not a quick fix. On the other hand, there's been work done to increase interoperability, at least between the VUnit, GHDL, OSVVM, and UVVM projects. There's more work to be done here. If we do that first it will be much easier to take the next step
• Note that I didn't say that CoreLib must be pure VHDL. If there is a value to be added (in line with our goals) that VHDL cannot provide we shouldn't wait for the next VHDL standard (may not even be a suitable addition to the standard) but try to solve it in other ways (be responsive). We should be careful though not to walk too far from VHDL or we may end up in the special-people-with-special-skills-and-tools-trap

Finally, goals are somewhat personal. Most people don't get involved in open source for the greater good but because they see added values for themselves. That's the reason why we don't see many open source EDA solutions. The people with the SW skills needed to develop those are not the same people using the tools. What people consider a value may vary and we need to be aware of this. It can be a tricky thing to meet people's personal goals such that they get involved while keeping the project focused. Some people are in it for the fun of problem solving, some are seeking reputation, most people are probably users, some people run a business, provide training and so on.

As a user of verification tools in general and a VUnit maintainer I primarily see added values in things I do not have with the tools I'm using today and values in reducing VUnit maintenance work. Today VUnit doesn't depend on other open-source projects (OSVVM is an add-on) so sharing the basic building blocks like complex datatypes would reduce maintenance.

• Provide a good methodology and supporting libraries for the VHDL community

  • Must be very simple to use for simple verification challenges
  • Should be easy to get started by e.g. just using one simple function/procedure from a library - with no preparations needed
  • Should be as simple as possible for more advanced verification challenges
  • Complexity should be avoided unless really needed

• Should target VHDL designers with no academic interest in languages

  • Not make a system that is great and flexible - at the cost of complexity
  • Target designers who wants to get the job done, but have no interest for language details

• Make the development of VHDL methodology and libraries more efficient - and achieve better progress

  • If at all possible - avoid N groups working on the same challenges with different solutions
  • If at all possible - make different solutions work together as one