This the issue I wanted to stress: because of lack of interest from our BDFL we all have diverged MyHDL libraries …
For those who are interested, I have updated my github repo : https://github.com/NicoPy/myhdl/commits/master
The differences with official repo are :
- Fixes by hgomersall (enhance namespace management)
- Fix an issue when converting to VHDL (signed casted to unsigned while it should not)
- Improved simulation configuration (progress callback, optional backup of simulation file, timescale, output directory…)
- Added an Unsigned() method to intbv (to allow casting a signed to unsigned)
- Added NotUsed() to remove warnings when converting to VHDL
- Sort signals, process sensitivity list and other when converting to VHDL (this allows to always generate the same VHDL output when converting a MyHDL source file)
- Added the possibility to attach attributes to signals. These attributes do nothing in simulation but are converted to VHDL. They allow to define pin location, pin pull-up, pin drive strength, RAM inference style…
These modifications are working with my designs. I don’t guarantee they are free of bugs.
See, that doesn’t work. If we all publish our ‘diverged’ code we are nowhere nearer to a unified and improved MyHDL library. I also have some fixes, with a different approach. @hgomersall has a few more, as does @cfelton, as does …
It is possible, just requires more work from us in the near-term.
Sorry for the delay, but I’ve not been well, and the dog ate my homework.
I have a project which is overdue for release which should attract wide interest and further controversy from users and fixers of floating point arithmetic.
There are two release goals:
A tiny processor in which the sole supported data type is an unconstrained integer. This would interest a small group of programmers, and release would prove the ability to handle variable-sized data items efficiently. Most code is written and slightly tested. A more flexible and simplified test harness is in progress. Expected size: ~3k LUT4s.
A similar processor where the single data type is Unum type 1. This data type is a superset of integer and float, both unconstrained. From planning details the added complexity over release 1) is estimated at 50%. Details of the advantages of Unum type 1 are below , but note that my binary number format differs significantly.
 Unums type 1.
RichReport Gustafson interview 2015-03-01:
An interesting subject. However it would be better if you started a new thread for this subject. The
ShowCase category seem appropriate, I’d say.
Thanks for the suggestion. I’m happy to start a new thread for this divergent topic. Is it possible to move the posting? Or does it need copying and maybe deleting? If anyone can do this easily then please go ahead.
Otherwise I’ll copy and repost tonight, and refine it if possible.
I’m just a mere user …
So I guess you have to go through the copy/paste/edit/delete motions.
I agree with you.
My intent is to share the modifications I made to MyHDL.This can be of interest to other users.
Showcase is for work completed, but neither of my release goals have yet been reached, so maybe that category is not suitable, but hopefully will be soon.
Since I would like a sleeping partner, or whipping boy, or something like that, anyone interested could email me directly rather than post here if this helps keep the topic cleaner:
jan4myhdl at murray-microft dot co dot uk
BTW, the 3k LUT4s [+Flops + block RAMs] is system size, so the project really is tiny.
If the BDFL and everyone else who have merging rights are missing for an unknown amount of time, I suggest you use DrPi’s repository either until they get back or until you decide to fork the project. The longer you wait, the messier its gonna be to get back on track.
I’m just a (somewhat inexperienced) MyHDL user who’d hate to see this project die, so I thought I’d add my opinions to the discussion.
It would be such a shame if the project dies just because two people become inactive, especially when there clearly is a community willing to submit pull requests and take the project forward.
IMHO, 7 months of no communication at all is a very long time. Had I been in your position, I think it would be a good time to consider making a fork.
I’m not trying to whip you guys into working more by the way. Just adding my two cents in the form of some opinions.
ok so this is one of the critical down-sides to github, which i’ve been mentioning for many many years but of course it really does not help because, having ridden in on the “social media craze” github is extremely popular.
personal github pages are personal. they do NOT work as TEAM pages. RepRapFirmware and Marlin Firmware are both total chaos as a result. if you do not understand this clearly, try to find the TEAM that is responsible for maintaining either of these projects. try to even find a TEAM web-site. what you will find instead is dozens of forks.
please for goodness sake everyone, please understand that if you want to develop a TEAM project please use sourceforge, savannah.nongnu.org, or set up your own fusionforge (it’s not that hard). these and alioth.debian.org are all based on the same codebase: a free software project that was originally project 1 on sourceforge, which was SPECIFICALLY designed around TEAM collaboration. it includes GROUP permissions. there are MULTIPLE ssh keys uploaded for git repository commit access. the project is organised around the PROJECT name NOT the PERSONAL USER GIT REPOSITORY.
consequently if any one person decides to stop working on the project and for whatever reason even goes to the extreme of no longer responding, even if all the other admins do not respond, sourceforge provides a mechanism to allow you to request to become a new admin. it takes a long time (deliberately) but it is possible.
in direct contrast you CANNOT request to take control of another person’s PERSONAL github page. because it is PERSONAL.
with fusionforge and derivatives you can always continue to do git pushes and pulls to github and/or personal github repositories: you can even use “git remote update” and you can even use a little-known feature of git to add two or more repository lines to the same entry in the config file.
so i’ve been around software libre for over two decadees, now. sourceforge, savannah, alioth, bitbucket, gitorious - all the quotes unpopular quotes software libre project management sites - are all based around team management. they all allow multiple people’s ssh keys to be added, all with the same commit rights, to the same repository. github does not permit this.
personally, when managing free software projects, i install gitolite3 and then, as people approach me, i add their ssh key to the repository so that they become a member of the group. it means that people need to properly coordinate… but it also means that you now have a single place for people to go to which is no longer critically dependent on a single person.
I know this is an old thread but it seems to be a very important one for a new user such as myself to understand the direction of myhdl.
As a new user of myhdl and add-ons myhdlpeek & pygmyhld from @devbisme I’m really excited about writing HDL in python with all it’s benefits. In particular writing tests is so much easier (at least for me where I have 10X the experience in python over verilog).
However, reading this thread I’m worried if I should invest my time here or just suck it up and write in Verilog? Myhdl seems to be very capable with lots of great examples from several contributors but there are bound to be bugs/enhancements that will continually be needed.
Perhaps there are work arounds that those more experienced have figured out. In fact, @josyb and @DrPi helped me with an issue I was having yesterday. This actually gave me a lot of encouragement that there is an active community willing to help newbies like myself. Thank you very much!
My basic question is whether myhdl will continue mostly “as-is” with workarounds suggested by the community or if there is a plan to continue active development (possibly via a fork)? The latter of course is a huge responsibility and undertaking and one that folks just may not have time for.
So should I stay or should I go?
I look forward to your inputs about the present & future of myhdl
Surely the question to ask is what benefits would come from not using MyHDL? Specifically, what exactly are you worried about? Even if the community evaporates tomorrow, you’ll still have what you’ve written and it will still convert just fine.
The migration path from myhdl->Verilog is not hard (MyHDL writes the verilog for you!), though you might want to refactor things a little.
So, the question in my mind would be, do the myriad benefits of using MyHDL over Verilog now exceed the potential cost of having to migrate at some point in the future? To me the answer is a resounding yes, but obviously you might reach a different conclusion.
Moreover, the MyHDL code base is pretty easy and accessible to hack on. We take the view we’ll just maintain it ourselves if we have to (and in practice, we do). The cost of maintenance is much less than the cost of writing in Verilog .
@hgomersall you make several valid points and I tend to agree that MyHDL as-is is still probably better than verilog. But I think your last point is the one that is both good & bad. It’s unfortunate that many of the enhancements individuals have made can’t be integrated into the main code base so all could benefit and not have to re-invent the wheel.
To be clear, all our changes have been merged into the MyHDL master. My point was that we don’t hesitate to make changes. There are lots of things that people are working on and for whatever reason haven’t been raised as pull requests, but these are invariably features well over and above what Verilog or VHDL can offer.
OK that’s very encouraging! Based on comments such as these earlier in this thread I was (wrongly?) under the impression that PR’s weren’t being merged. This thread is pretty old so something has changed in the past year or so?
And this in response to publishing individual hacked/enhanced code:
Things have considerably improved since I wrote my original lament.
@cfelton was given commit rights and we cleared out the backlog.
About viability: there a numerous people using MyHDL as is; it basically works and once you get the more subtle points you will be breezing along … at warp speed (compared to Verilog).
Of course together we can and will improve MyHDL to become even better.
I see that now and thank you all for re-assuring me and for keeping MyHDL alive. I’m in!