Myhdl 0.10 release


#1

In the coming weeks, I finally have some time to get the 0.10 release out.

I have already worked through the PRs and merged in the ones I felt sure about. I have also resolved the issues tagged in the 0.10 milestone. As far as I know, the manual should be good enough for a release.

The remaining thing to do that I know of: switch 1.0dev -> 0.10. This may surprize some people but I agree with the number update.

So - are there still issues that definitively need to be addressed before a release? Several people have already helped with this, thanks, that makes it a lot easier. So if you have time to go over things again and make sure nothing essential is missed, thanks again. The easiest for me is to use GitHub for feedback - e.g. commenting/reviewing PRs or labeling issues with the 0.10 milestone (but only when really sure ;-)).

Clearly, this is not a call for new features, but to get us a stable release so that we can move forward.

I will have to finish this somewhere in the second half of March (or earlier), afterwards I may get stuck in tape-out craze again :wink:


#2

Hi Jan,

Yes, I get other fixes on my side. I didn’t made any PR for them since the github master branch was much too far from my version.
I’ll try to make PRs for them as soon as possible.

Nicolas


#3

@jandecaluwe I believe most issues are resolved. I am not aware of @DrPi changes (or at least I don’t recall, I believe he listed them in a separate post) but some of them might fall under “new feature”, we will have to look at those as they are posted.

There is a conversion bug that should be resolved before the release.

Regards,
Chris


#4

My pseudo on github is NicoPy.

PR#252 is not a new feature. It re-enables a feature lost when @block has been added
PR#251 is needed when working with signed intbv signals.
PR#250 is critical for my usage (I use signed intbv signals a lot). I know have to provide a use case but I am too busy for now. I hope I have time in a short delay.


#5

Is that WIP #256 that you refer to?

If I go ahead and change the version number to 0.10, is that OK now?


#6

Yes, I don’t foresee an issue changing the revision to 0.10 (I can merge/update).

I am missing the VHDL test case in #256, somehow broke my ghdl install. If we don’t want to delay, we can merge it as is - it doesn’t break any other tests.


#7

I have created a new PR to enhance unsigned() method of class intbv().

Please note that unsigned() is not convertible.


#8

I have other patches :

  • Make Unsigned() convertible
  • A NotUsed() function useful to remove warnings on signals that are not used.
  • A Attribute() function to add signal attributes à la VHDL.
  • Sort signals, variables, process sensitivity list in converted design. This is useful when comparing converted designs. I have not tested yet but it might not be useful with Python3.6+ (dicts keep the insertion order).

All this patches are compatible with VHDL conversion only.


#9

Just created PR #259.
Should be part of 0.10, I think.


#10

Hi all,

Some issues with docs/examples:

  • What’s new in 0.10 simply points to mep-114
  • mep-114 is not merged into the manual, e.g. @block decorator can’t be found in the reference, neither is the new simulation API
  • most examples still uses the old simulation API.

#11

I am thinking we should remove the examples embedded in the package, we have examples on the website - no reason to have duplications and dual maintenance.

It is ok (maybe not preferred), that some of the examples/documentation isn’t updated in the 0.10 release, both forms (@block and not block) are supported in 0.10. For the 1.0 release all the examples and documentation need to be converted to the @block form, the @block will be required in 1.0 (assuming no unforeseen issues).

Yes, the “What’s new” should be updated to list the @block, initial values support and ??? (@josyb, @hgomersall, @jck what else was added in this release?).

Regards,
Chris


#12

Lots and lots of fixes! (though perhaps mostly fixes to the new features :wink: )


#13

@cfelton: compare the 0.9 maintenance with the master branch? And weed through the commits :slight_smile:


#14

I have created the 0.10 release (the mechanism has completely changed in the mean time, so I waited a little with the announcement to see whether it worked fine).

I have also created a 0.10-maintenance branch for bug fixes on this release. PRs with bug fixes for 0.10 should go there, I will merge them into master of course.