[Cocotb] The future of Cocotb
luke.darnell at broadcom.com
Thu Sep 27 05:27:20 CEST 2018
I'm thinking along the same lines as Marek re splitting out the core cocotb.
cocotb core could be:
- gpi/vpi/vhpi/fli layer for simulator access
- cocotb handle, triggers, BinaryValue, coroutines, decorators, scheduler,
logging, regression, result, test
These provide the most basic functionality of doing digital simulation in
python against an rtl simulator.
And is analogous to the base Verilog/SystemVerilog language.
I think having an official framework that sat on top of the cocotb core
that provided the base classes for drivers, monitors, scoreboards,
sequences, etc... would be useful.
This would be analogous to the way UVM sits on top of SystemVerilog.
Maybe call this coco-vm ?
People would then implement verification IP that used the coco-vm (or
whatever it gets called).
This would make using other's work more straight forward and provide some
uniformity in usage/design of verification IP.
One piece of feedback I had from industry at Orconf was that there was no
cocotb equivalent of UVM, so no easy way of reusing different verification
Or even being able to purchase verification IP that would plug into cocotb.
Providing an "official" cocotb verification methodology would go a long way
to allaying those concerns.
One hopes in the future, as cocotb adoption continues to grow, that people
developing commercial cocotb verification IP will become a reality.
I for one would definitely be interested in commercially
available/supported cocotb verification IP, especially if it was built on a
common methodology that made reuse easy.
On Wed, Sep 26, 2018 at 10:43 PM Marek Ciepłucha <mciepluc at gmail.com> wrote:
> Hi Chris, and All,
> Thank you for the update.
> As we are using Cocotb as a verification tool in my current company, it
> will be manageable to arrange some time "officially" to contribute the
> Therefore we would love to contribute as well.
> We could take Python part (./cocotb), as it will be most extensively used
> in the team. Also we can prepare more detailed documentation of the
> existing features.
> Regarding external packages incl. coverage, I agree. However there is a
> discussion needed what should be the Cocotb "core" package. For example, if
> Scoreboard should belong to this package, as it also can be implemented
> different ways. Also there are some bus-specific BFMs in the package which
> may not be generic enough to fit everyone's requirements. I would recommend
> to also make them rather external.
> What do you think?
> śr., 26 wrz 2018 o 12:22 David Stanford <david.stanford at gmail.com>
>> I'd also be interested in helping out.
>> There's a lot you guys want to get done, so it'll be hard to coordinate
>> all of that in this email thread, but I agree with Luke that a key starting
>> place is working through outstanding issues on GitHub keeping this list of
>> goals in mind. Even without any permissions changes on GitHub, folks can
>> take initiative to comment review and talk about if changes seem
>> appropriate for mainline, experimental, or extensions integration branches.
>> On Tue, Sep 25, 2018, 22:13 Luke Darnell <luke.darnell at broadcom.com>
>>> This is great to hear Chris.
>>> I'd love to get involved.
>>> Stemming the continual flow of unresolved issues and open pull requests
>>> seems like a good place to start.
>>> As of today (26th September, 2018) we have 145 open issues and 36
>>> pending pull requests.
>>> Would be great to see this number starting to go down (or at least not
>>> going up).
>>> Seems like at a minimum people can start reviewing any pending pull
>>> requests on github.
>>> For issues, as we discussed at Orconf, github comments aren't the
>>> greatest place for a discussion.
>>> Can I suggest for any non-trivial issues, we start a thread on the
>>> mailing list?
>>> Perhaps we can do the same for pull requests that implement a major new
>>> feature or that might break backwards compatibility?
>>> I can start doing this and see how it works out.
>>> On Mon, Sep 24, 2018 at 8:06 PM Chris Higgs
>>> <chris.higgs at potential.ventures> wrote:
>>>> Greetings All,
>>>> TLDR; If you would like to get involved in maintaining and shaping the
>>>> future direction of Cocotb we are looking for volunteers to help run the
>>>> project - please reply on this thread if you would like to get involved!
>>>> There has been some discussion about the management of Cocotb and the
>>>> lack of input from Stu and myself over the last year or so. The upstream
>>>> repo has languished, PRs have been open for some time, there haven’t been
>>>> any tagged releases and generally the project has not kept up the momentum
>>>> despite accumulating an ever growing user base. Please accept our
>>>> apologies for this state of affairs - we want to fix this and find a way to
>>>> ensure that Cocotb can thrive without us getting in the way. We used the
>>>> recent 2018 ORConf conference to announce our intention to solve this, but
>>>> there are still a lot of details to be worked out to make it happen.
>>>> We need to figure out a way to hand control of the project over to the
>>>> community and put in place structures and guidelines to facilitate
>>>> colloboration. We need to appoint maintainers for different areas of the
>>>> project. The FOSSI foundation has helped tremendously by doing things like
>>>> setting up this mailing list and organising great conferences. However
>>>> while they may be able to provide some resources for helping out with
>>>> regression testing, if Cocotb is going to become a community driven project
>>>> then ultimately it is down to us as a community to work out how the project
>>>> should be structured and take it forward.
>>>> Here are some initial thoughts from my perspective of things we could
>>>> do to start working towards that goal.
>>>> 1. We need to figure out a process for contributing to the project and
>>>> document it.
>>>> 2. We need to make it possible for more developers to get involved in
>>>> reviewing and merging code onto the upstream repository. Ideally we could
>>>> appoint maintainers for various parts of the codebase who decide if
>>>> something is ready to be merged. If we cannot find maintainers, we could
>>>> try and achieve some degree of consensus via the review process. For
>>>> smaller bug fixes etc if the regressions all pass anybody with permissions
>>>> should feel confortable merging so we keep a reasonable turn-around time
>>>> for getting contributions into the upstream.
>>>> 3. We could create a branch on the upstream (experimental or unstable
>>>> or similar) where people felt more inclined to merge new stuff. Then things
>>>> can make it upstream and issues and wrinkles get ironed out, but there can
>>>> still be a wider discussion before a feature goes into master. That would
>>>> solve the situation we have currently where a lack of merging mean people
>>>> are often pointing at forks because upstream is moving too slowly. This
>>>> also ties into the fact that we’re not really versioning properly so most
>>>> people use a checkout and we don’t have stable releases, which means
>>>> merging to master can break things for people.
>>>> 4. We should figure out a way of for extensions to functionality to be
>>>> provided without necessarily needing to go in upstream, or permit multiple
>>>> implementations to exist side-by-side. For example with coverage, there are
>>>> a few ways of doing it so arguably they should all be available as
>>>> extensions and people could use whichever is most appropriate, rather than
>>>> mandating only one way in the “official” repo.
>>>> We need extensions to be easily discoverable and there are a few
>>>> options for this - for example we could maintain a list of extensions/BFMs
>>>> in the repository itself. It would be good to define some guidelines and
>>>> discoverability mechanisms for plugin authors that help make it very simple
>>>> to find and install plugins while avoiding some of the problems that can
>>>> arise such as namespace collisions. We could use LibreCores to aid
>>>> discoverability by finding extensions that exist in Github.
>>>> To me this path seems more scalable than continually adding stuff in
>>>> and means it can evolve much faster. In theory the “core” of cocotb that
>>>> abstracts VPI/VHPI into Python will be relatively stable.
>>>> I’m thinking something like:
>>>> pip install cocotb-coverage
>>>> Where coverage could live in an externally maintained repo... then
>>>> there’s no barrier to layering on features and multiple competing
>>>> implementations can coexist. There are plenty of examples of this style of
>>>> plugin/extensions so it’s not unusual to follow this model, we just need to
>>>> ensure we have thought through the implications of things like namespaces,
>>>> regression testing and versioning to avoid things getting broken.
>>>> 5. We need to find a solution to regression testing against proprietary
>>>> simulators. Again this is something where we might be able to enlist help
>>>> of the FOSSI foundation if there is infrastructure we need to do this in
>>>> addition to the Github/Travis services we are already using.
>>>> 6. We need to start doing versioned releases and pushing them to PyPI.
>>>> There was a lot of interest at ORConf from people wanting to get
>>>> involved in Cocotb, let’s try and continue momentum!
>>>> cocotb mailing list
>>>> cocotb at lists.librecores.org
>>> cocotb mailing list
>>> cocotb at lists.librecores.org
>> cocotb mailing list
>> cocotb at lists.librecores.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cocotb