[myhdl-list] Two slightly awkward things about the MyHDL syntax

[Angel E. <ezq...@gm...>]

Hi Jan,

I am little by little learning how to use MyHDL. In general I've found that
using python to model hardware is very nice and that the resulting code is
very clear and easy to understand. However there are two things in the way
that MyHDL works that feel a bit awkward to me. I'd like to give you the
perspective of a new user so that perhaps you can try to improve MyHDL in
this regard if you feel that these suggestion are valid :-)

- Having to return the list of declared generators is odd:

This is the first thing that tripped me when trying to create my first myhdl
design from scratch. I was expecting MyHDL to infer the list of generators
automatically. Instead you must manually return the list of generators that
you use on each block.

This is a bit annoying because it means that if you ever add new generators
to a block or if you change their names you must remember to modify the
function return statement to keep it synchronized with the generators that
you are using.

Note that I am not saying that the MyHDL documentation does not tell you
about this (because it does). I am just saying that it would be much nicer
if myhdl could track this automatically for you.

Perhaps the @instance, @always and @always_comb decorators could somehow add
a reference to the generator that is being declared into a list of local
instances. This "instance list" could have a known name that the user could
then return (e.g. the user could always do "return local_instances()" or
something of the sort). The nice thing of this approach is that it could be
100% backwards compatible, since the user could chose to manually create the
return list (as is done today).


- Declaring the list of interface signals (and their types) outside of the
block definition function is prone to errors:

In MyHDL, when you define a block you put the names of the interface signals
in the argument list of the corresponding function. However, when you call
the conversion functions you must first declare the corresponding signals
(and their types) and then pass that list to the conversion function.

I feel that this is awkward for two reasons:
   - It is weird that the port type specifications are done outside of the
block declaration.
   - If you change the block declaration you must also change the code that
calls the conversion function.

I imagine that the main reason for this second "awkward" syntax is that
Python is not a strongly typed language. Yet it seems that a more elegant
solution could be found. For example, perhaps a "port" decorator could be
added to the "hardware block functions" in which the list of port types
could be declared. This would put the port type declaration close to the
actual block definition and would let you call the pass the block
declaration function alone (without the list of port signals) to the convert
functions (e.g. you could call "toVHDL(myBlock)" rather than
"toVHDL(myBlock, myPort1, myPort2, myPort3)").

I think that this enhancement could also be done in a backward compatible
way, since the user could still pass the list of port signals to the convert
function.

An extra benefit of this approach is that this "port" annotation could be
used to ensure that the signals that are passed to the block function are of
the right type (and throw an exception if that were not the case).


Cheers,

Angel