Re: [myhdl-list] MyHDL hierarchy extraction and conversion process is broken

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

On 1/28/2014 5:24 AM, Alexander Hungenberg wrote:
> Hey guys
>
> Sorry for the sensational subject. I do not really have the expertise
> to really throw out such a statement.

I believe you will receive a better reception if you
have a specific example (better yet a unit test)
that demonstrates the problem and a subject title asking
for assistance instead of declaring something not working
without much evidence to support the claim.

> But I programmed quite a bit in
> MyHDL now, and I _LOVE_ the approach. Using python as a HDL seems
> pretty natural and great to achieve more flexibility. Also writing of
> tests seems a lot more painless to me.
>

That is great to hear.

> However, as often as I was happy about the great features MyHDL
> offers, I am getting frustrated by completely misguiding error
> messages for an unknown reason, where the only possible way to fix
> them is spending many hours debugging through the MyHDL source code
> and finding the relevant part which generates the exception. But even
> when I got there, it is very difficult to find out how the MyHDL
> conversion process got to this point and which line in my sourcecode
> is relevant.

The best and most productive way to debug a module
is to have a test for the module.  I am not aware
of many (any?) cases when someone had a test and
proved the functionality, that conversion was much
of an issue.

>
> One example I recently tried to program was a flexible serial
> receiver/transmitter, which takes a variable amount of 16-bit
> arguments and transmits them on request using Xilinx's uart core. In
> python I declared this module as
>
> def communicator(rx, tx, ... , clk, *data)
>
> However, this didn't work. I digged through the MyHDL conversion
> process and let me say, even as a Python expert it is really painful
> :-D
>

Posting the error (or a chunk of it) or a sandbox
example of a similar error to this mailing-list,
you will get some useful help.

> MyHDL uses a large mix of profiling, static code inspection and
> runtime function inspection to determine the contained generators and
> used signals. Due to this the conversion process jumps around
> endlessly in the code, and precisely due to this mix (especially of
> static source code inspection and the dynamic one) it is impossible to
> use the great features which Python offers in terms of flexibility
> (dynamic numbers of arguments until the conversion process starts,
> code reuse by using classes, ...). Or at least it is not possible with
> my deepness of understanding of MyHDL.
>
> I know, this is some pretty blurry and not very constructive critics,
> but my intuition tells me that there should be a lot more consistent
> way of doing the conversion (ideally, only based on runtime
> inspection) which allows such ways of programming increasing the
> usefulness of MyHDL a lot. Even if it needs some additional function
> call in each module to register signals or generators to the
> converter.

The error messages are ever evolving and improving
but the converter is not a compiler and the information
from the converter might always be less than one
might hope.  As noted, if tested this usually is not
an issue.

Regards,
Chris