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

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

On Wed, Jul 14, 2010 at 5:44 PM, Christopher Felton <cf...@uc...>wrote:

>
> On Wed, Jul 14, 2010 at 10:22 AM, Angel Ezquerra <ang...@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.
>
>

That is awesome! I did not know that! Thank you for this tip! It basically
removes one of my may complaints about MyHDL! :-D

I think that I have not seen this used in the examples that I've studied,
although perhaps I missed it. It is certainly not used in many of the
examples. Since this is a very convenient way to work I think that this
should be used in the examples so that it becomes the default way to return
the instances defined in a block.


> - 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.
>

Ideally you should be able to set default types (including sizes) for the
ports but you should also be able to tell myhdl whether you want it to
generate an exception when a user uses a different type (or Signal width)
for those parameters. Perhaps that could be done by using parameters (with
default values) but I don't really know how could that be done withing the
confines of python syntax. Any ideas?

Angel