Re: [myhdl-list] reusable blocks with different interfaces

[Henry G. <he...@ca...>]

On 15/01/15 20:26, Christopher Felton wrote:
> On 1/15/2015 1:38 PM, Henry Gomersall wrote:
>> >On 15/01/15 19:25, Christopher Felton wrote:
>>> >>On 1/15/2015 1:15 PM, Henry Gomersall wrote:
>>>>> >>>>At risk of asking an XY problem (in which I describe a different problem
>>>>> >>>>to the more fundamental one), I would like to know if it is possible
>>>>> >>>>with MyHDL 0.9 to define a reusable convertible block that does
>>>>> >>>>something like the following:
>>>>> >>>>
>>>> >>>>from myhdl import *
>>>>> >>>>
>>>>> >>>>class Interface(object):
>>>>> >>>>        def __init__(self):
>>>>> >>>>            self.a = Signal(intbv(0)[5:])
>>>>> >>>>            self.b = Signal(intbv(0)[7:])
>>>>> >>>>
>>>>> >>>>def block_factory(input_interface, output_interface, clock, reset):
>>>>> >>>>
>>>>> >>>>        @always_seq(clock.posedge, reset)
>>>>> >>>>        def block():
>>>>> >>>>            output_interface.next = input_interface
>>>>> >>>>
>>>>> >>>>        return block
>>>>> >>>>
>>> >>No this is not supported.  I probably is possible
>>> >>but would need to follow the normal enhance (MEP)
>>> >>proposal.
>> >
>> >Okey dokey. I would like to initiate the discussion:)
>> >
>> >Does it seem like a crap idea, or something that might be useful?
>> >
>> >Shall I put together a tentative MEP?
>> >
>   From my perspective it seems reasonable.  The idea
> and uses cases are straight-forward but implementation
> might need some batting around.
>
> Example, should there be a factory function to copy,
> kinda like the previous example.  Or should the user
> have to defined a "next" method so that it can be a
> customizable copy ...

Another solution might be to support iterators more generally. Instead 
of the interface having a next property, it can implement the __iter__ 
method that returns the signals to iterate over.

This would have the nice property of also then supporting any iterables, 
not just interfaces.

I appreciate there isn't the equivalent in v*, but one approach that 
could work would be for the convertor to unroll the loop. A configurable 
parameter could set a maximum unroll length if that is desired.

I actually prefer this a solution - it's quite neat and powerful.

Henry