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

[Jian L. <jia...@go...>]

I usually use assert to check ports before any instance declaration in the
function body,
and think that's good enough for me.

Cheers,

Jian


On Sat, Jul 17, 2010 at 5:01 PM, Angel Ezquerra <ang...@gm...>wrote:

>
> 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
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>