Let’s face it, MyHDL is in crisis.
The last commit/merge of a PR has been in April 2017.
There are open PRs dating from April 2015 …
As a result most of us have a local MyHDL branch, and some (most?) no longer care to submit a PR.
I sent a private email to our BDFL two weeks ago, but didn’t get a reply (yet).
What is your opinion?
Regards,
Josy
Josy,
I agree with you.
I wrote about this 3 weeks ago (Issues and PRs are piling up).
I had no answer.
With so many PRs pending, it is useless to submit new ones which will be quite impossible to merge.
The silence of MyHDL team is really disturbing me.
Best regards,
Nicolas
Yes, it is strange. I can feel that this year’s GSoC was more silent than last year’s.
I’m more of a MyHDL user than a developer who submits PRs, but I’ve also noticed a downturn in MyHDL. I just did a Google comparison of search hits for MyHDL compared to migen and it was 125K to 600K (not in our favor). This is admittedly a crude measure, but it is still a benchmark.
While checking-in PRs is important for fixing/enhancing the core language, that may not be enough to save MyHDL. The PRs address issues that mainly concern experienced users. For new users, MyHDL is pretty good as it stands. Still, they aren’t taking the bait. If they did and the population of users grew, it might revitalize this project and the core developers might have more motivation to work on it.
Nobody would say migen is more expressive or beautiful than MyHDL, but it does have the misoc project that allows users to quickly build a processor system with the surrounding infrastructure and get it running on an FPGA. MyHDL seems to be missing that sort of marquee project that draws people in. (If I’m wrong, please point me to it as I haven’t found it.) Most of what I can find is some cores by Chris Felton in addition to the PyFDA filter synthesis tools (which don’t generate Verilog or VHDL). I also found an article by Chris from 2012 with a list of links to MyHDL projects, most of which haven’t been updated in years as well as a few 404 pages. And if you look at this forum, there have been <100 posts in 1-1/2 years, and only three of them are in the Projects category.
So while the quiet of the core developers is a concern, the real problem is that we as a community are failing to tell the story of how useful MyHDL is. We aren’t showcasing our designs for potential converts to see the tangible results of using MyHDL. The result is our base of users is not growing and other HDLs have more momentum.
I really find MyHDL useful and I don’t want to see it die. To help prevent that, over the past few months, I’ve been working on some MyHDL add ons:
myhdlpeek allows you to add Peeker objects to MyHDL code to store waveforms for a set of signals. These signals can be displayed as wave traces or tables in a Jupyter notebook.
pygmyhdl is a thin wrapper around MyHDL that attempts to smooth-out some of the rough spots in the syntax. It’s mainly “training wheels” for new users and I expect they’ll abandon it and move on to straight MyHDL once they gain experience.
I’ve got a sequence of Jupyter notebooks that use pygmyhdl, myhdlpeek and yosys/arachne/icestorm to do complete (but elementary) designs for the Lattice iCEstick in MyHDL. A new user can design, simulate, synthesize, place-and-route, and download to the FPGA without leaving the notebook using either Windows or Linux (or even an RPi).
None of these projects, alone or in combination, can save MyHDL. One person can’t do that, not even Chris. But if enough people put enough projects out there, maybe we can build the critical mass that will attract more people to MyHDL. And maybe that will reawaken the core developers or even bring in new ones.
If anyone is willing to showcase their projects, I can build a “MyHDL Projects” page similar to this one I built for KiCad add-on tools. Adding your project would be as simple as modifying the project list page and submitting a pull request as explained here.
Dave,
You make an excellent case for the MyHDL Projects page as it definitely is missing. But it will need worthy contributions.
My lament is about our BDFL who rightfully claims to be the sole decider, but fails to decide …
This puts off the core developers, @cfelton, @hgomersall, @DrPi, me (@josyb), and newer apprentices. The long list of open PRs (and Issues) doesn’t inspire confidence to newcomers either I’d say.
Actually there are no true core developers; only the BDFL @jandecaluwe and his lieutenant @jck have PR-merging rights. It looks to me that both are pursuing other interests.
Regards,
Josy
Yes, worthy (or even unworthy) projects are needed. I’ll wait a few days and see if anybody puts forth some candidates.
As for the core of MyHDL, why can’t we create a fork with the new improvements? I’m now reading that migen has soft-forked to LiteX. Is that a possibility for us?
Dave,
forking the project is a possibility. I have thought about this for some time. This is perhaps a useful blog:: https://jamesdixon.wordpress.com/forking-protocol-why-when-and-how-to-fork-an-open-source-project/
It would need a solid team to undertake this. And beware: it will be more work than we think.
Regards,
Josy
Hi,
On my side, when I choose a new project to work with, I first look at its maturity and its “health” (after functionalities of course). For this, I directly go to the repository and have a look at commits, issues and PRs. Second is the community.
First time I had a look at MyHDL was years ago and it was too early for me to go with it.
The second time was about a year. I decided to use it and I don’t regret my choice.
If I had a look at MyHDL today, I would certainly not go with it.
The main page of the WEB site is more than 2 years old (the news section). The repository has not been committed for 7 months. Issues and PR’s are accumulating. Some recent PRs overlap with older ones.
On discourse, Josy is the only user/developer answering questions.
With hardcore developers not working any more on the project, the future is not brilliant. Working on MyHDL is hard work, at least for me.
Before developing big projects, we need a real community.
Best regards,
Nicolas
That’s another way of looking at it.
For me, I would look for an existing project that I can use as a starting point when choosing a language. (I think this is the case with misoc funneling new converts into migen.) Looking at the number of PRs might indicate a vibrant community, or it might indicate a project that is hopelessly iterating and fiddling. It depends upon your viewpoint.
I don’t think we need a “big” project. misoc isn’t really that big. I’m hoping we already have some good projects lying around that just need some polish and some exposure. If we have to wait for a community before doing significant projects, then the game might already be over. IMO, communities don’t form spontaneously and then choose something to work on; they form when a common goal or project brings people together.
@devbisme There’s no need for a big community for a project to live. 8 months ago, there was a very active community. A small one but very active. As Josy said, 2 developers have commit rights on github and only one takes decisions. Both are currently completely inactive on the project stalling it’s development.
As a community and project we are definitely going through a slow patch and transition. It is not as simple as @jandecaluwe being incommunicado - @jck stated how the core developers should proceed to get the PRs merge and I agree with the approach. Best of my knowledge, we (@jck, @cfelton, @josyb, @hgomersall and others) have failed to review and comment on the PRs to get them merged.
If we get multiple reviews the PRs will get merged and yes it is more of a chore now since they have piled up. I want to see this project continue, I will try and get some methodical attack on reviewing the PRs. I am traveling quite a bit the month of Nov., we will have to see …
The activity for this project has always been bursty, the core developers and users all seem to be professionals - i.e. they all have other demanding responsibilities. There have been other long periods of low activity in the past.
This project will continue, this project will survive this transition, and this project will continue to be relevant. It might not (probably not) be as popular as some people would like.
Sorry, I don’t have any other words of wisdom to incite enthusiasm but if we do the work (sigh I pointing at myself) the project will continue to be supported piddle along.
In addition to reviewing the PRs we can add projects and examples to the myhdl website, I can update the status on the website as well. A simple task, could be to port relevant/interesting old examples for the wiki days to the current, which consists of porting the wiki pages to markdown.
@cfelton OK let’s start. I approved PR #54. As soon as this #54 is closed we can proceed to the next one.
Let’s start with low hanging fruit first 
@cfelton Thank you for reminding us of our duties — I completely forgot of the review mechanism.
Can we appoint you Chief Whip? 
@all Thanks for the impetus on this. How are the dependencies between PRs looking? Perhaps we need to triage so we have an attack plan.
Have the core developers ever considered doing a monthly or quarterly dev call? GNU Radio has one (https://wiki.gnuradio.org/index.php/) and it has been good for organizing tasks and keeping the community updated on progress.
@jpendlum that is not a bad idea, we have been trying to organize a meetup, we are spread out all over the place it will take some time.
We will see if we can organize a dev call, thanks for the link as an example.
@devbisme A reference project is a good point but it has drawbacks :
I think we need a “how to” section with basic examples and more complex ones.
I started such a PDF document. But maybe an on-line version is be better ? If so, where can we publish it ?
Nicolas