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

[Christopher F. <cf...@uc...>]

On Wed, Jul 14, 2010 at 10:22 AM, Angel Ezquerra <ezq...@gm...> wrote:

> 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).
>
>
This is currently support use the function instances().  Example return
instances().  It will return all generators in the module.  Adding new
generators will not require updating the return list.


>
> - 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).
>
>
Would the port decorator be able to handle parameters?  The HDL modules need
to be modular, such that I can define bit widths etc when instantiating the
module.

.chris