myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Github staging and works in progress

[Henry G. <he...@ca...>]

On 16/07/15 13:21, Jan Decaluwe wrote:
> On 07/16/2015 12:34 PM, Henry Gomersall wrote:
>> > On 16/07/15 08:54, Jan Decaluwe wrote:
>>> >> For every mediocre PR that I accept there will be 1 happy contributor
>>> >> and hunderds of users that hate me even more.
>> >
>> > Just on this point, you're rather drawing a false dichotomy. Of course
>> > you shouldn't accept bad PRs - I don't think anyone is suggesting you
>> > should. Rather, there needs to be a route by which bad PRs become good
>> > PRs, and that doesn't need to fall on you.
> Who are you, that you think you have anything to say about
> the way I choose to run my own open source project?
> 

Come on Jan, don't be so damn precious. I'm trying to help and your
response is distinctly confrontational. Of course you can run your
repository however you want, I'm just pointing out that perhaps there
are ways you could be more accommodating without compromising the quality.

> To those who are actually listening: the answer to the
> suggestion is (obviously) NO.
> 
> Of course many people have better Python skills than me,
> and I hope to see contributions from them. But I can
> hardly be an obstacle there: they don't need my guidance,
> and as can be seen from my track record I have little
> problems to judge the quality and incorporate them readily.

But this is the problem. Working on solutions in isolation is a very
*bad* way to do development. Nobody who is truly competent would try to
work like that unless they have to. Getting feedback through ongoing
code reviews is distinctly best practice. Currently this is very hard
with MyHDL.

> 
> For all other PR's, that are related to HDL-oriented
> decisions, I still have to meet the first person that
> I would trust to decide on them. For anybody who delves
> in the history of MyHDL, it will be obvious why.
> 
> I hope that is crystal clear.

Nobody is doubting your ability or authority when it comes to this
stuff, simply that if you're not keen to take a proactive role in the
refinement of PRs, other people can help with this. This isn't about
pushing crap into the repository, but about ironing out the problems in
pull requests before needing to bother you with them.

Please take my emails as what they are - a sincere and honest attempt to
refine the process of making MyHDL the best it can be.

Genuine best wishes,

Henry

Re: [myhdl-list] Github staging and works in progress

[Jan D. <ja...@ja...>]

On 07/16/2015 12:34 PM, Henry Gomersall wrote:
> On 16/07/15 08:54, Jan Decaluwe wrote:
>> For every mediocre PR that I accept there will be 1 happy contributor
>> and hunderds of users that hate me even more.
>
> Just on this point, you're rather drawing a false dichotomy. Of course
> you shouldn't accept bad PRs - I don't think anyone is suggesting you
> should. Rather, there needs to be a route by which bad PRs become good
> PRs, and that doesn't need to fall on you.

Who are you, that you think you have anything to say about
the way I choose to run my own open source project?

To those who are actually listening: the answer to the
suggestion is (obviously) NO.

Of course many people have better Python skills than me,
and I hope to see contributions from them. But I can
hardly be an obstacle there: they don't need my guidance,
and as can be seen from my track record I have little
problems to judge the quality and incorporate them readily.

For all other PR's, that are related to HDL-oriented
decisions, I still have to meet the first person that
I would trust to decide on them. For anybody who delves
in the history of MyHDL, it will be obvious why.

I hope that is crystal clear.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Github staging and works in progress

[Henry G. <he...@ca...>]

On 16/07/15 08:54, Jan Decaluwe wrote:
> For every mediocre PR that I accept there will be 1 happy contributor
> and hunderds of users that hate me even more.

Just on this point, you're rather drawing a false dichotomy. Of course 
you shouldn't accept bad PRs - I don't think anyone is suggesting you 
should. Rather, there needs to be a route by which bad PRs become good 
PRs, and that doesn't need to fall on you.

Cheers,

Henry

Re: [myhdl-list] Github staging and works in progress

[Jose M. G. C. <ch...@gm...>]

Dear Jan,

First of all, let me apologize for my yesterday wording, it was rude.

Second, I am sorry to say that what I said is still valid, now myhdl has new bugs.

Finally let me put it clear, I did not insult you, I just answered in the same way you answer to me, and sincerely, it hurts.

Best,

	Jose M.

> El 16/7/2015, a las 11:21, Henry Gomersall <he...@ca...> escribió:
> 
> On 16/07/15 08:54, Jan Decaluwe wrote:
>>> On a similar vein, I've sometimes failed to get useful feedback on
>>>> specific implementations that are distinctly a work in progress, but
>>>> need feedback to proceed. Specifically, issue #68 in which I have
>>>> half of a complete implementation for that particular problem. It's
>>>> distinctly not PR ready, but is a WIP. I'm somewhat disinclined to
>>>> sink any more time into it without some further constructive
>>>> feedback, which I attempted to garner without much success.
>> Interesting that you mention #68. That can hardly be seen as an
>> example where it's difficult to engage me in discussions. The
>> problem rather is, that several people seem unwilling to listen
>> and unwilling to look at the broader perspective beyond their
>> own pet feature.
> 
> The problem wasn't #68 per se, but rather there was no route to discuss 
> the specific implementation. Now, whether you agree or not the problem 
> is worth working on, there is clearly something that is irking people. 
> Personally, I don't have much interest in solving #68 - I worked on it 
> because I thought it was an interesting problem from a programming 
> perspective. I stopped because the one response was a snarky comment 
> from you about run time that I was fully aware of and disclosed and 
> wasn't really what I was garnering feedback on (the run time issue was 
> due to it being a wip and is easy to remove with a little effort).
> 
>>>> I feel there is quite a bit that could be done very easily to make
>>>> contributors feel more welcome. A mechanism for better and more
>>>> patient code collaboration for WIPs would go a long way to this end.
>>>> Perhaps if Jan doesn't wish to be involved with this, a second mirror
>>>> repository on github could take on that role.
>> If it's not clear: my goal is not to make contributors happy. It
>> is to have users hate me less. In fact that should be obvious and
>> the difference also.
>> 
>> For every mediocre PR that I accept there will be 1 happy contributor
>> and hunderds of users that hate me even more.
>> 
>> Moreover, I have had very bad experiences in the past with would-be
>> contributors whose self-confidence was much higher than their
>> technological skills. In addition to no interest, I simply have no time for
>> that anymore. That is a very important pratical limitation which
>> everyone should simply respect.
> 
> With respect Jan, you can't start out by assuming everyone is 
> incompetent, and certainly it is the case that areas of competence are 
> not always overlapping. E.g. being a python guru is useful even if the 
> person knows nothing about HDL, assuming the skills can be directed 
> appropriately - the other skills will be developed along the way.
> 
> Even the soft skills, like good management of contributors would be a 
> big plus to the project. This isn't Linux, with the huge commercial 
> resources backing it and a small army of full time developers to raise 
> the contributions bar.
> 
>> 
>> What MyHDL needs most in my opinion is not all kinds of new features.
>> It is full of features that are underutilized and the most important
>> contribution would be by users publishing about their work. No,
>> what it needs is a better and more robust implementation. Even though
>> jck has done a tremendous job in this in 0.9, I feel there is still
>> a lot that can be done. Such "mundane" hard work gets my first priority
>> and respect.
> I fully concur with the sentiment, but community building just doesn't 
> happen like that. People take an interest and are motivated by their 
> personal itch that needs scratching, and then they work on the bigger 
> problems as they get sucked in.
> 
> Perhaps you're not interested in building a community, but by your own 
> admission you're short of time.
> 
>> As it now has come to the point when a contributor found it appropriate
>> to insult me for not including his mediocre PR #101, I'd like to reconsider
>> the whole labeling thing. I fear it may turn the PR area into a dumping
>> ground on unfinished and dubious work. Like people that think they
>> solve a problem by sending an email. I prefer not to play a role in that.
>> 
>> I prefer the jck model of the past. Very hard work in the background, and
>> then I get a PR that is obviously brilliant. Look at those PRs. They are by
>> far the most complex contributions till now. Yet it didn't take me
>> much time to pull them in.
> 
> #101 is a good point to raise. I think jmgc should certainly have been 
> more polite in what he wrote, but it's not like you've been carefully 
> wordsmithing your criticism of him (or anyone else for that matter).
> 
> If you're not willing to take on the burden of interacting on the level 
> that is necessary, let others help you. Ruling with an iron fist is all 
> good and well, but it rather requires you to engage fully (lest people 
> fork or simply bugger off).
> 
> Cheers,
> 
> Henry
> 
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Github staging and works in progress

[Henry G. <he...@ca...>]

On 16/07/15 08:54, Jan Decaluwe wrote:
>> On a similar vein, I've sometimes failed to get useful feedback on
>> >specific implementations that are distinctly a work in progress, but
>> >need feedback to proceed. Specifically, issue #68 in which I have
>> >half of a complete implementation for that particular problem. It's
>> >distinctly not PR ready, but is a WIP. I'm somewhat disinclined to
>> >sink any more time into it without some further constructive
>> >feedback, which I attempted to garner without much success.
> Interesting that you mention #68. That can hardly be seen as an
> example where it's difficult to engage me in discussions. The
> problem rather is, that several people seem unwilling to listen
> and unwilling to look at the broader perspective beyond their
> own pet feature.

The problem wasn't #68 per se, but rather there was no route to discuss 
the specific implementation. Now, whether you agree or not the problem 
is worth working on, there is clearly something that is irking people. 
Personally, I don't have much interest in solving #68 - I worked on it 
because I thought it was an interesting problem from a programming 
perspective. I stopped because the one response was a snarky comment 
from you about run time that I was fully aware of and disclosed and 
wasn't really what I was garnering feedback on (the run time issue was 
due to it being a wip and is easy to remove with a little effort).

>> >I feel there is quite a bit that could be done very easily to make
>> >contributors feel more welcome. A mechanism for better and more
>> >patient code collaboration for WIPs would go a long way to this end.
>> >Perhaps if Jan doesn't wish to be involved with this, a second mirror
>> >repository on github could take on that role.
> If it's not clear: my goal is not to make contributors happy. It
> is to have users hate me less. In fact that should be obvious and
> the difference also.
>
> For every mediocre PR that I accept there will be 1 happy contributor
> and hunderds of users that hate me even more.
>
> Moreover, I have had very bad experiences in the past with would-be
> contributors whose self-confidence was much higher than their
> technological skills. In addition to no interest, I simply have no time for
> that anymore. That is a very important pratical limitation which
> everyone should simply respect.

With respect Jan, you can't start out by assuming everyone is 
incompetent, and certainly it is the case that areas of competence are 
not always overlapping. E.g. being a python guru is useful even if the 
person knows nothing about HDL, assuming the skills can be directed 
appropriately - the other skills will be developed along the way.

Even the soft skills, like good management of contributors would be a 
big plus to the project. This isn't Linux, with the huge commercial 
resources backing it and a small army of full time developers to raise 
the contributions bar.

>
> What MyHDL needs most in my opinion is not all kinds of new features.
> It is full of features that are underutilized and the most important
> contribution would be by users publishing about their work. No,
> what it needs is a better and more robust implementation. Even though
> jck has done a tremendous job in this in 0.9, I feel there is still
> a lot that can be done. Such "mundane" hard work gets my first priority
> and respect.
I fully concur with the sentiment, but community building just doesn't 
happen like that. People take an interest and are motivated by their 
personal itch that needs scratching, and then they work on the bigger 
problems as they get sucked in.

Perhaps you're not interested in building a community, but by your own 
admission you're short of time.

> As it now has come to the point when a contributor found it appropriate
> to insult me for not including his mediocre PR #101, I'd like to reconsider
> the whole labeling thing. I fear it may turn the PR area into a dumping
> ground on unfinished and dubious work. Like people that think they
> solve a problem by sending an email. I prefer not to play a role in that.
>
> I prefer the jck model of the past. Very hard work in the background, and
> then I get a PR that is obviously brilliant. Look at those PRs. They are by
> far the most complex contributions till now. Yet it didn't take me
> much time to pull them in.

#101 is a good point to raise. I think jmgc should certainly have been 
more polite in what he wrote, but it's not like you've been carefully 
wordsmithing your criticism of him (or anyone else for that matter).

If you're not willing to take on the burden of interacting on the level 
that is necessary, let others help you. Ruling with an iron fist is all 
good and well, but it rather requires you to engage fully (lest people 
fork or simply bugger off).

Cheers,

Henry

Re: [myhdl-list] Github staging and works in progress

[Jan D. <ja...@ja...>]

On 07/14/2015 08:10 PM, Henry Gomersall wrote:
> As was raised during PR #102 on github, Jan's preference so far has
> been to have PRs that are complete and ready.
>
> I posit that allowing discussion and updates on specific
> implementation is a great feature of github and we should have a
> convention to allow for this, such that a solution can evolve with
> input inside a PR.
>
> @jck's suggestion of doing what neovim do seems like a great idea to
> me:
>
> Prefixing the title with one of the following tags:
>
> |[WIP] - Work In Progress: the PR will change, so while there is no
> immediate need for review, the submitter still might appreciate it.
> [RFC] - Request For Comment: the PR needs reviewing and/or comments.
> [RDY] - Ready: the PR has been reviewed by at least one other person
> and has no outstanding issues. |
>
> Only when the tag is changed to [RDY] is it deemed to be ready for
> inclusion.
>
> It would be great if github had a collaborative staging area, but
> this seems like a good solution to me.
>
> On a similar vein, I've sometimes failed to get useful feedback on
> specific implementations that are distinctly a work in progress, but
> need feedback to proceed. Specifically, issue #68 in which I have
> half of a complete implementation for that particular problem. It's
> distinctly not PR ready, but is a WIP. I'm somewhat disinclined to
> sink any more time into it without some further constructive
> feedback, which I attempted to garner without much success.

Interesting that you mention #68. That can hardly be seen as an
example where it's difficult to engage me in discussions. The
problem rather is, that several people seem unwilling to listen
and unwilling to look at the broader perspective beyond their
own pet feature.

> I feel there is quite a bit that could be done very easily to make
> contributors feel more welcome. A mechanism for better and more
> patient code collaboration for WIPs would go a long way to this end.
> Perhaps if Jan doesn't wish to be involved with this, a second mirror
> repository on github could take on that role.

If it's not clear: my goal is not to make contributors happy. It
is to have users hate me less. In fact that should be obvious and
the difference also.

For every mediocre PR that I accept there will be 1 happy contributor
and hunderds of users that hate me even more.

Moreover, I have had very bad experiences in the past with would-be
contributors whose self-confidence was much higher than their
technological skills. In addition to no interest, I simply have no time for
that anymore. That is a very important pratical limitation which
everyone should simply respect.

What MyHDL needs most in my opinion is not all kinds of new features.
It is full of features that are underutilized and the most important
contribution would be by users publishing about their work. No,
what it needs is a better and more robust implementation. Even though
jck has done a tremendous job in this in 0.9, I feel there is still
a lot that can be done. Such "mundane" hard work gets my first priority
and respect.

As it now has come to the point when a contributor found it appropriate
to insult me for not including his mediocre PR #101, I'd like to reconsider
the whole labeling thing. I fear it may turn the PR area into a dumping
ground on unfinished and dubious work. Like people that think they
solve a problem by sending an email. I prefer not to play a role in that.

I prefer the jck model of the past. Very hard work in the background, and
then I get a PR that is obviously brilliant. Look at those PRs. They are by
far the most complex contributions till now. Yet it didn't take me
much time to pull them in.

Jan

>
> Cheers,
>
> Henry
>
>
> ------------------------------------------------------------------------------
>
>
Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support
> that you need to offload your IT needs and focus on growing your
> business. Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
>
>
>
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Interfaces in hierarchcal way

[Jos H. <jos...@gm...>]

David Holl <david <at> ad5ey.net> writes:

> Using MyHDL, I did create a full DMA controller for transferring radio
> data from our digital receivers to user applications.  The controller
> accepts data from our DDC's via AXI4-Stream signaling, ....

> ...  They were written around the time of MyHDL 0.7
> and 0.8-dev (before MyHDL's hierarchical signal ), so I did end-up
> implementing a number of work-arounds to avoid some MyHDL peculiarities
> at the time.

Hi David,

You're clearly much further than I am... I'm just starting to learn 
writing a linux device driver. So anything which can be shared would be 
helpful! For instance I could try a port to Altera-SoC.
The hierarchical AXI interface was just my initial step to get going.
So, I'm going into the same direction as you by first trying to create a 
fifo in hardware, which can be written and read from the CPU side.

Best regards,
Jos

Re: [myhdl-list] Github staging and works in progress

[Henry G. <he...@ca...>]

On 15/07/15 13:59, Christopher Felton wrote:
> On 7/14/2015 1:10 PM, Henry Gomersall wrote:
>> >As was raised during PR #102 on github, Jan's preference so far has
>> >been to have PRs that are complete and ready.
>> >
>> >I posit that allowing discussion and updates on specific
>> >implementation is a great feature of github and we should have a
>> >convention to allow for this, such that a solution can evolve with
>> >input inside a PR.
>> >
>> >@jck's suggestion of doing what neovim do seems like a great idea to
>> >me:
>> >
>> >Prefixing the title with one of the following tags:
>> >
>> >|[WIP] - Work In Progress: the PR will change, so while there is no
>> >immediate need for review, the submitter still might appreciate it.
>> >[RFC] - Request For Comment: the PR needs reviewing and/or comments.
>> >[RDY] - Ready: the PR has been reviewed by at least one other person
>> >and has no outstanding issues. |
>> >
>> >Only when the tag is changed to [RDY] is it deemed to be ready for
>> >inclusion.
> If we agree on this (it sounds reasonable) we need
> to update the development guide - stamp it official:)
>
> http://dev.myhdl.org/guide.html#creating-changes

Well, this gets my vote.

>
>> >
>> >It would be great if github had a collaborative staging area, but
>> >this seems like a good solution to me.
>> >
>> >On a similar vein, I've sometimes failed to get useful feedback on
>> >specific implementations that are distinctly a work in progress, but
>> >  need feedback to proceed. Specifically, issue #68 in which I have
>> >half of a complete implementation for that particular problem. It's
>> >distinctly not PR ready, but is a WIP. I'm somewhat disinclined to
>> >sink any more time into it without some further constructive
>> >feedback, which I attempted to garner without much success.
> In my opinion this is an effect of limited resources and
> distributed development.  An OP needs to be patient and
> persistent with issues.  For example, we had some off in
> the weeds conversations on IRC, so naturally this task
> faded into the background.

No doubt. The problem was more that there was nowhere that seemed to 
right to have the necessary conversation. My mild apathy to the problem 
meant that I'm not being particularly persistent (it was an issue that I 
thought was interesting and could see the purpose, but wasn't relevant 
to me - my approach was largely an academic exercise to see if it could 
be done without too much difficulty).

>> >
>> >I feel there is quite a bit that could be done very easily to make
>> >contributors feel more welcome. A mechanism for better and more
>> >patient code collaboration for WIPs would go a long way to this end.
>> >Perhaps if Jan doesn't wish to be involved with this, a second mirror
>> >repository on github could take on that role.
> A second mirror is not needed, when we first started
> discussing this issue fetching from each others forks
> worked fine and isn't too difficult.  I think the
> process outlined in the developer guide is reasonable
> first communicated (issues, IRC, gitter, mailing-list),
> and git provides reasonable collaboration.  Adding the
> tags could also be useful (I think it will also have
> some unforeseen downsides, e.g. staleness, who decides
> when a WIP is dead).

I agree that would be a bad outcome. It was really whether title tags 
are acceptable for the proposed kinds of PR in the main repository.

Cheers,

Henry

Re: [myhdl-list] Github staging and works in progress

[Christopher F. <chr...@gm...>]

On 7/14/2015 1:10 PM, Henry Gomersall wrote:
> As was raised during PR #102 on github, Jan's preference so far has
> been to have PRs that are complete and ready.
>
> I posit that allowing discussion and updates on specific
> implementation is a great feature of github and we should have a
> convention to allow for this, such that a solution can evolve with
> input inside a PR.
>
> @jck's suggestion of doing what neovim do seems like a great idea to
> me:
>
> Prefixing the title with one of the following tags:
>
> |[WIP] - Work In Progress: the PR will change, so while there is no
> immediate need for review, the submitter still might appreciate it.
> [RFC] - Request For Comment: the PR needs reviewing and/or comments.
> [RDY] - Ready: the PR has been reviewed by at least one other person
> and has no outstanding issues. |
>
> Only when the tag is changed to [RDY] is it deemed to be ready for
> inclusion.

If we agree on this (it sounds reasonable) we need
to update the development guide - stamp it official :)

http://dev.myhdl.org/guide.html#creating-changes

>
> It would be great if github had a collaborative staging area, but
> this seems like a good solution to me.
>
> On a similar vein, I've sometimes failed to get useful feedback on
> specific implementations that are distinctly a work in progress, but
>  need feedback to proceed. Specifically, issue #68 in which I have
> half of a complete implementation for that particular problem. It's
> distinctly not PR ready, but is a WIP. I'm somewhat disinclined to
> sink any more time into it without some further constructive
> feedback, which I attempted to garner without much success.

In my opinion this is an effect of limited resources and
distributed development.  An OP needs to be patient and
persistent with issues.  For example, we had some off in
the weeds conversations on IRC, so naturally this task
faded into the background.

>
> I feel there is quite a bit that could be done very easily to make
> contributors feel more welcome. A mechanism for better and more
> patient code collaboration for WIPs would go a long way to this end.
> Perhaps if Jan doesn't wish to be involved with this, a second mirror
> repository on github could take on that role.

A second mirror is not needed, when we first started
discussing this issue fetching from each others forks
worked fine and isn't too difficult.  I think the
process outlined in the developer guide is reasonable
first communicated (issues, IRC, gitter, mailing-list),
and git provides reasonable collaboration.  Adding the
tags could also be useful (I think it will also have
some unforeseen downsides, e.g. staleness, who decides
when a WIP is dead).

http://dev.myhdl.org/guide.html#first-step-communicate

Regards,
Chris

[myhdl-list] Github staging and works in progress

[Henry G. <he...@ca...>]

As was raised during PR #102 on github, Jan's preference so far has been 
to have PRs that are complete and ready.

I posit that allowing discussion and updates on specific implementation 
is a great feature of github and we should have a convention to allow 
for this, such that a solution can evolve with input inside a PR.

@jck's suggestion of doing what neovim do seems like a great idea to me:

Prefixing the title with one of the following tags:

|[WIP] - Work In Progress: the PR will change, so while there is no immediate need for review, the submitter still might appreciate it.
[RFC] - Request For Comment: the PR needs reviewing and/or comments.
[RDY] - Ready: the PR has been reviewed by at least one other person and has no outstanding issues.
|

Only when the tag is changed to [RDY] is it deemed to be ready for 
inclusion.

It would be great if github had a collaborative staging area, but this 
seems like a good solution to me.

On a similar vein, I've sometimes failed to get useful feedback on 
specific implementations that are distinctly a work in progress, but 
need feedback to proceed. Specifically, issue #68 in which I have half 
of a complete implementation for that particular problem. It's 
distinctly not PR ready, but is a WIP. I'm somewhat disinclined to sink 
any more time into it without some further constructive feedback, which 
I attempted to garner without much success.

I feel there is quite a bit that could be done very easily to make 
contributors feel more welcome. A mechanism for better and more patient 
code collaboration for WIPs would go a long way to this end. Perhaps if 
Jan doesn't wish to be involved with this, a second mirror repository on 
github could take on that role.

Cheers,

Henry

[myhdl-list] 0.9.0

[Jan D. <ja...@ja...>]

0.9.0 has been released.

http://docs.myhdl.org/en/stable/whatsnew/0.9.html

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Interfaces in hierarchcal way

[David H. <da...@ad...>]

Using MyHDL, I did create a full DMA controller for transferring radio
data from our digital receivers to user applications.  The controller
accepts data from our DDC's via AXI4-Stream signaling, and then it sends
the PCIe MWr TLP's (packets) to the Xilinx PCIe interface over
AXI4-Stream as well.  The Linux driver supports zero-copy I/O for direct
transfer into user application buffers, and MSI-X with message
ring-buffers for relaying status back to the driver.  There are no
kernel "bounce" buffers and thus no time wasted on memcpy.  This way,
customers may happily buy and plug more of our hardware into their
hosts, or they may use their hosts' available CPU and memory bandwidth
for more intensive signal processing.

I briefly looked at XillyBus, but opted to design my own low-latency scheme.

Leading up to and in support of this DMA controller, I did create a few
smaller AXI4-Stream building blocks in MyHDL such as synchronous FIFO's,
skid-buffers, and priority arbiters.  (yes, even though Xilinx offers
equivalent blocks...)  They were written around the time of MyHDL 0.7
and 0.8-dev (before MyHDL's hierarchical signal ), so I did end-up
implementing a number of work-arounds to avoid some MyHDL peculiarities
at the time.  In summary, these smaller [1] vendor-agnostic streaming
blocks would work just fine on Altera, but their code is pretty ugly
with the work-arounds.  Perhaps with MyHDL 0.9, a rewrite of these
blocks would make them less internally ugly and thus worthy of being shared.

Footnote:
1] For my larger DMA controller block, its PCIe output AXI4-S interface
is written to expect the signaling that the Xilinx IP core uses over the
"user" bits, so I'm not sure how cleanly this particular block would
port from Xilinx to Altera.


On 7/13/15 2:23 AM, Jos Huisken wrote:
> Josy Boelen <josyboelen <at> gmail.com> writes:
>
>> Jos Huisken <jos.huisken <at> gmail.com> writes:
>>
>>> I was trying to create an AXI subsystem for Altera Cyclone V 
> boards... 
>> Excuse me for barging in, but if you are using Altera components, 
> wouldn't 
>> it be easier to use Qsys to connect all those AXI (and other) 
> components? 
>> Or am I missing something?
>>
>> Regards,
>>
>> Josy
> Hi all,
>
> The idea is ultimately to create mainly streaming interfaces toward 
> hardware, i.e. AXI4S, the amount of streaming interfaces parameterized 
> and usable from a device driver in linux.
> You can maybe imagine that it becomes conveniently feasible to use 
> hardware accelerators and, for instance, use them from GNU-Radio.
> I haven't found that much, except maybe 'xillybus' which seems like a 
> solution.
> I'm using Qsys as well, but indeed as Chris mentioned, not easily 
> parameterized and missing the IP to go streaming.
>
> Maybe others have been looking into such architectural setup, I expect 
> at least that I'm not unique in realizing something like this.
>
> Regards,
> Jos
>
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Interfaces in hierarchcal way

[Jos H. <jos...@gm...>]

Josy Boelen <josyboelen <at> gmail.com> writes:

> We already talked about that, and yes you can't create parametrizable 
> systems with Qsys.
> But I'm not sure that bespoke AXI subsystems are that flexible either. 
> And connecting them all up in an hierarchical way can be tedious. I have 
> only used Avalon MM interfaces and am quite OK with wiring them in Qsys, 
> but then our Qsys projects are very 'fixed'. 

The idea is to use the lightweight AXI master for configuring both the 
streaming interfaces and the connected IP, and that the axi-master and 
axi-slave only serve as stream drivers and stream receivers respectively.
So configuration can be quite simple, I guess. But streaming interfaces 
are blocking so deadlock may occur: but that problem should be avoided by 
higher level mapping techniques.
This looks like a nice simple model to me, which can later be used easily 
toward silicon implementation. I prefer platform independence as much as 
reasonably possible, and think that this would also work out for Xilinx  
(although I haven't checked it yet)

Regards,
Jos

Re: [myhdl-list] Interfaces in hierarchcal way

[Jos H. <jos...@gm...>]

Josy Boelen <josyboelen <at> gmail.com> writes:

> 
> Jos Huisken <jos.huisken <at> gmail.com> writes:
> 
> > I was trying to create an AXI subsystem for Altera Cyclone V 
boards... 
> > 
> 
> Excuse me for barging in, but if you are using Altera components, 
wouldn't 
> it be easier to use Qsys to connect all those AXI (and other) 
components? 
> Or am I missing something?
> 
> Regards,
> 
> Josy

Hi all,

The idea is ultimately to create mainly streaming interfaces toward 
hardware, i.e. AXI4S, the amount of streaming interfaces parameterized 
and usable from a device driver in linux.
You can maybe imagine that it becomes conveniently feasible to use 
hardware accelerators and, for instance, use them from GNU-Radio.
I haven't found that much, except maybe 'xillybus' which seems like a 
solution.
I'm using Qsys as well, but indeed as Chris mentioned, not easily 
parameterized and missing the IP to go streaming.

Maybe others have been looking into such architectural setup, I expect 
at least that I'm not unique in realizing something like this.

Regards,
Jos

Re: [myhdl-list] Tristate top-level ports, (was Hello World)

[Josy B. <jos...@gm...>]

Jose M. Gomez Cama <chemoki <at> gmail.com> writes:

> 
> Dear both,
> 
> The problem with the ternary operator is not myhdl but the VHDL version. 
The conditional assignment is not
> available inside procedures before the version 2008. In version 93 the 
conditional assignment can only
> be concurrent (always_comb). There is also a comment in the 
test_ternary.py.
> 
> Best

Dear Jose,

it is definitely an issue of MyHDL interpreting the (python) ternary 
construct.

Regards,

Josy

Re: [myhdl-list] Tristate top-level ports, (was Hello World)

[Jose M. G. C. <ch...@gm...>]

Dear both,

The problem with the ternary operator is not myhdl but the VHDL version. The conditional assignment is not available inside procedures before the version 2008. In version 93 the conditional assignment can only be concurrent (always_comb). There is also a comment in the test_ternary.py.

Best

> El 10/07/2015, a las 22:11, Christopher Felton <chr...@gm...> escribió:
> 
>> On 7/10/15 2:21 AM, Josy Boelen wrote:
>> Christopher Felton <chris.felton <at> gmail.com> writes:
>> 
>>> Think I found it #74:
>>> https://github.com/jandecaluwe/myhdl/pull/74
>>> 
>>> For reasons unknown (thus far) this breaks code
>>> that previously converted:
>>> https://gist.github.com/cfelton/6119313
>> 
>> MyHDL doesn't always like the ternary construct:
>> 'sda_d.next = False if not sda_o else None'
>> 
>> The PR #74 has, IMHO, no influence on the conversion of that construct.
>> 
>> I have seen some of these ternary statements fail, and some not ...
>> 
>> Also see issue #86
> 
> Josy,
> 
> Makes sense, when I used git bisect it ended up at
> the version created after the #74 PR merge (unless
> I misinterpreted bisect results).
> https://github.com/jandecaluwe/myhdl/issues/98
> 
> Thanks!
> Chris
> 
> 
> 
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Tristate top-level ports, (was Hello World)

[Christopher F. <chr...@gm...>]

On 7/10/15 2:21 AM, Josy Boelen wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>> Think I found it #74:
>> https://github.com/jandecaluwe/myhdl/pull/74
>>
>> For reasons unknown (thus far) this breaks code
>> that previously converted:
>> https://gist.github.com/cfelton/6119313
>
> MyHDL doesn't always like the ternary construct:
> 'sda_d.next = False if not sda_o else None'
>
> The PR #74 has, IMHO, no influence on the conversion of that construct.
>
> I have seen some of these ternary statements fail, and some not ...
>
> Also see issue #86
>

Josy,

Makes sense, when I used git bisect it ended up at
the version created after the #74 PR merge (unless
I misinterpreted bisect results).
https://github.com/jandecaluwe/myhdl/issues/98

Thanks!
Chris

Re: [myhdl-list] Interfaces in hierarchcal way

[Josy B. <jos...@gm...>]

Martin Strubel <hackfin <at> section5.ch> writes:


> Having a deja vu here...
> I've found all the SOPC/Qsys and their Xilinx/Lattice counterparts not
> really friendly for maintenance, so I've ended up with an approach 
based
> on GNU make, kconfig (linux kernel config) and an XML device 
description
> (called DClib/devdesc). Like IP-XACT, but way less complex. Could be
> enhanced to spit out MyHDL (currently, it can only generate VHDL based
> Wishbone-capable SoCs). There's also a graphical tool called 
"kactus2",
> but I haven't looked at it in detail.
> The XML approach turned out to be quite robust and future compatible,
> unlike the known migration nightmares that make you freeze old 
software
> versions in a VM...
> 
> Once hierarchy can be maintained in MyHDL, this might become very
> interesting, due to a vast amount of powerful XML processing tools in
> the Python domain.
> 
> Greetings,
> 
> - Martin

Grüezi Martin,

IP-XACT and XML are total strangers to me ... I'll read up on it.
Thanks for the link on 'kactus2'. My colleague thinks it may be very 
usable, but we need some time to experiment and an electronic engineer 
never has enough time (at least 99% of them). Unfortunately 'kactus2' 
doesn't read Qsys xxx_hw.tcl files, but I'm confident I can rewrite my 
xxx_hw.tcl generator, when I find the time :)

Regards,

Josy

Re: [myhdl-list] Tristate top-level ports, (was Hello World)

[Josy B. <jos...@gm...>]

Christopher Felton <chris.felton <at> gmail.com> writes:

> Think I found it #74:
> https://github.com/jandecaluwe/myhdl/pull/74
> 
> For reasons unknown (thus far) this breaks code
> that previously converted:
> https://gist.github.com/cfelton/6119313

MyHDL doesn't always like the ternary construct:
'sda_d.next = False if not sda_o else None'

The PR #74 has, IMHO, no influence on the conversion of that construct.

I have seen some of these ternary statements fail, and some not ... 

Also see issue #86

Regards,

Josy

Re: [myhdl-list] to_VHDL() conversion error: 'intbv' object has no attribute '__name__'

[Christopher F. <chr...@gm...>]

On 7/9/2015 3:34 PM, David Stanford wrote:
> I'm working on some toy problems from projecteuler.org to get a
> better handle on myHDL and have run into a problem converting to
> VHDL.
>

Below this line is incorrect:
     even.next = True if mysum(0) == 0 else False

It needs to be:
     even.next = True if mysum[0] == 0 else False


[] brackets not () for bit-select.  The () are
for ShadowSignals and is elaboration only.

> As far as I can tell, it's something to do with mysum, fib_r1, or
> fib_r2, but I can't figure out what aspect is a problem.  Before the
> wall of text that is the code and the error code, I have 2 questions:
> 1) what's the specific problem I'm running into here? 2) If I wasn't
> emailing this list, where is the right place for me to look for
> solutions to this problem?

1. see above.

2. This mailing-list, #myhdl IRC on freenode, or
    stackoverflow with the myhdl tag.  In some cases
    an issue on github.

Typically creating the test like you did will help
resolve 95% of the issues.  Once in awhile, it might
simulate ok but not convert.

Regards,
Chris

Re: [myhdl-list] Tristate top-level ports, (was Hello World)

[Christopher F. <chr...@gm...>]

On 7/9/2015 1:50 PM, Christopher Felton wrote:
> <snip>
>>
>> I submitted a Pull Request to fix that bug.
>
> Josy,
>
> Do you know which PR this was?

Think I found it #74:
https://github.com/jandecaluwe/myhdl/pull/74

For reasons unknown (thus far) this breaks code
that previously converted:
https://gist.github.com/cfelton/6119313


Regards,
Chris

[myhdl-list] to_VHDL() conversion error: 'intbv' object has no attribute '__name__'

[David S. <dst...@kc...>]

I'm working on some toy problems from projecteuler.org to get a better handle on myHDL and have run into a problem converting to VHDL.

As far as I can tell, it's something to do with mysum, fib_r1, or fib_r2, but I can't figure out what aspect is a problem.  Before the wall of text that is the code and the error code, I have 2 questions: 1) what's the specific problem I'm running into here? 2) If I wasn't emailing this list, where is the right place for me to look for solutions to this problem?

Here's my code:

from myhdl import *

import unittest
from unittest import TestCase


def euler2(results, results_valid, n, clk, reset):
    """ implement a solution in hardware to https://projecteuler.net/problem=2 """

    even = Signal(bool())
    #mysum, fib_r1, fib_r2 = [Signal(intbv(1, 1, n*10)) for i in range(3)]
    mysum = Signal(intbv(1,1,40000000))
    fib_r1 = Signal(intbv(1,1,40000000))
    fib_r2 = Signal(intbv(1,1,40000000))
    results_int = Signal(intbv(0, 0, 5000000))

    @always_comb
    def a():
        even.next = True if mysum(0) == 0 else False
        results_valid.next = True if mysum >= n else False
     #   results_valid.next = results_int(0)
        results.next = results_int

    @always_comb
    def c():
        mysum.next = fib_r1 + fib_r2

    @always_seq(clk.posedge, reset)
    def b():
        fib_r1.next = mysum
        fib_r2.next = fib_r1
        if even:
            results_int.next = results_int + mysum
        #results_int.next = results_int + 1
    return a, b, c
    #return a, b

And here's the unit test:

class TestEuler2(TestCase):
    def setUp(self):
        self.reset = ResetSignal(0, active=1, async=True)
        self.results_valid, self.clk = [Signal(bool()) for i in range(2)]
        self.results = Signal(intbv(0, 0, 5000000))
        self.clk_inst = self.run_clk(self.clk)

    def run_clk(self, clk):
        half_period = delay(10)

        @always(half_period)
        def clkgen():
            clk.next = not clk

        return clkgen

    def euler2_py(self, n):
        f1 = 1
        f2 = 1
        mysum = 0
        print " "
        while (f1 + f2) < n:
            mysum = mysum + f1 + f2
            f1, f2 = f1 + (2 * f2), (2 * f1) + (3 * f2)
        return mysum

    def checkResult(self, i, results, results_valid, clk, reset):
        reset.next = 1
        yield clk.negedge
        reset.next = 0
        while 1:
            yield clk.negedge
            if results_valid:
                self.assertEqual(results, self.euler2_py(i),
                                 "does " + str(results) + " == " + str(self.euler2_py(i)) + " for i == " + str(i))
                raise StopSimulation

    def test100(self):
        i = 100
        dut = traceSignals(euler2, self.results, self.results_valid, i, self.clk, self.reset)
        check = self.checkResult(i, self.results, self.results_valid, self.clk, self.reset)
        Simulation(dut, check, self.clk_inst).run(300000)
        euler_inst = toVHDL(euler2, self.results, self.results_valid, i, self.clk, self.reset)

    def test10000(self):
        i = 10000
        dut = euler2(self.results, self.results_valid, i, self.clk, self.reset)
        check = self.checkResult(i, self.results, self.results_valid, self.clk, self.reset)
        Simulation(dut, check, self.clk_inst).run(300000)

    def test4000000(self):
        i = 4000000
        dut = euler2(self.results, self.results_valid, i, self.clk, self.reset)
        check = self.checkResult(i, self.results, self.results_valid, self.clk, self.reset)
        Simulation(dut, check, self.clk_inst).run(300000)
        #euler_inst = toVHDL(euler2, self.results, self.results_valid, 4000000, self.clk, self.reset)



unittest.main()

And here's the run:

$ python euler2.py


E

.

.
======================================================================
ERROR: test100 (__main__.TestEuler2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "euler2.py", line 81, in test100
    euler_inst = toVHDL(euler2, self.results, self.results_valid, 100, self.clk, self.reset)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVHDL.py", line 203, in __call__
    _convertGens(genlist, siglist, memlist, vfile)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVHDL.py", line 461, in _convertGens
    v.visit(tree)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVHDL.py", line 1224, in visit_Module
    self.visit(stmt)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVHDL.py", line 1631, in visit_FunctionDef
    self.visit_stmt(node.body)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVHDL.py", line 1432, in visit_stmt
    self.visit(stmt)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVHDL.py", line 872, in visit_Assign
    self.visit(rhs)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVHDL.py", line 1073, in visit_IfExp
    self.visit(node.test)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVHDL.py", line 1012, in visit_Compare
    self.visit(node.left)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVHDL.py", line 981, in visit_Call
    self.write(f.__name__)
  File "/usr/lib/python2.7/site-packages/myhdl/_Signal.py", line 494, in __getattr__
    return getattr(self._val, attr)
AttributeError: 'intbv' object has no attribute '__name__'

----------------------------------------------------------------------
Ran 3 tests in 0.282s

FAILED (errors=1)
This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature. For additional important disclaimers and disclosures regarding KCG’s products and services, please click on the following link:

http://www.kcg.com/legal/global-disclosures

[myhdl-list] Tristate top-level ports, (was Hello World)

[Christopher F. <chr...@gm...>]

<snip>
>
> I submitted a Pull Request to fix that bug.

Josy,

Do you know which PR this was?

Regards,
Chris

> One observation: in your code you are actually using a TriState pin to
> drive.read the I2C_SDAT. In reality the SDa pin in the I2C is an
> opendrain, with a pull-up in the circuit. So you can only drive it *low*
> and keep it tristated otherwise.
>
> Regards,
>
> Josy

Re: [myhdl-list] Interfaces in hierarchcal way

[Martin S. <ha...@se...>]

Hi guys,

> 
> We already talked about that, and yes you can't create parametrizable 
> systems with Qsys.
> ...
> I have been contemplating on abandoning Qsys, but then I need a good 
> alternative for connecting those master and slave interfaces together.
> 

Having a deja vu here...
I've found all the SOPC/Qsys and their Xilinx/Lattice counterparts not
really friendly for maintenance, so I've ended up with an approach based
on GNU make, kconfig (linux kernel config) and an XML device description
(called DClib/devdesc). Like IP-XACT, but way less complex. Could be
enhanced to spit out MyHDL (currently, it can only generate VHDL based
Wishbone-capable SoCs). There's also a graphical tool called "kactus2",
but I haven't looked at it in detail.
The XML approach turned out to be quite robust and future compatible,
unlike the known migration nightmares that make you freeze old software
versions in a VM...

Once hierarchy can be maintained in MyHDL, this might become very
interesting, due to a vast amount of powerful XML processing tools in
the Python domain.

Greetings,

- Martin

Re: [myhdl-list] Interfaces in hierarchcal way

[Josy B. <jos...@gm...>]

Christopher Felton <chris.felton <at> gmail.com> writes:


> I don't know, I really dislike Qsys and the whole
> approach.  It is impossible to create flexible and
> modular systems.
> 
> And yes you might be missing something (or I am :).
> I think in this case an AXI subsystem was created
> in myhdl and is being converted to Verilog and
> integrated with more Verilog presumably (?).
> 
> Regards,
> Chris
> 

We already talked about that, and yes you can't create parametrizable 
systems with Qsys.
But I'm not sure that bespoke AXI subsystems are that flexible either. 
And connecting them all up in an hierarchical way can be tedious. I have 
only used Avalon MM interfaces and am quite OK with wiring them in Qsys, 
but then our Qsys projects are very 'fixed'. 
I have been contemplating on abandoning Qsys, but then I need a good 
alternative for connecting those master and slave interfaces together.

I have been working on a Xilinx project (consulting for) and was 
impressed by the overhead of building such an AXI system manually.

Now I was just curious, and I had hoped that Jos Huysken enlightened me 
:)


Regards,

Josy