Re: [myhdl-list] MEP 107 need for portmap

[Christopher F. <chr...@gm...>]

On 2/23/2014 6:03 PM, Keerthan jai.c wrote:
> Are you proposing that toV* can now be called in two ways, the usual way
> which is overriden if a function has  a portmap attribute?
>

Yes,

     # no portmap (current usage)
     toV*(m_top_level, <explicit list of ports>)

     # using portmat
     m_top_level.portmap = portmap
     toV*(m_top_level)

Both cases, after the call to toV* vportmap will
be filled in.

     pprint(m_top_level.vportmap)

Regards,
Chris

>
> On Thu, Feb 20, 2014 at 12:02 PM, Christopher Felton <chr...@gm...
>> wrote:
>
>> On 2/15/2014 3:43 PM, Keerthan jai.c wrote:
>>> I'm not sure which approach is more pythonic in this scenario. However,
>>> currently the only interface to the conversion functions are through toV*
>>> attributes. I think it is more 'consistent' to use toVerilog.portmap,
>>> unless we make the other parameters(such as toVerilog.name) exposed
>> through
>>> top level function attributes too.
>>>
>>
>> I appreciate that the /portmap/ tied to the toV*
>> functions matches (closer) to the current approach
>> to configure the conversions process.
>>
>> But given some of the other conversations I think
>> having a /portmap/ and /vportmap/ tied to the module
>> (top-level function) is useful and worth discussion.
>>
>> If we tie it to the top-level function it gives us
>> two ways - not two ways to do the same thing but two
>> ways to solve different problems.
>>
>> Per the other discussion - if you want conversion
>> time top-level port modifications that are parameterizable
>> for the system you are building.  The ability to do the
>> following, could be useful:
>>
>>       portmap = dict(<list of ports>)
>>       dut = m_top(**portmap)
>>       m_top.portmap = portmap
>>       toV*(m_top)
>>       #  the function portmap attribut is used to
>>       #  define the top-level ports and what they are
>>       #  instead of the compile time args to the func
>>       #  and the passed signals.
>>
>> I think the above is a use case worth considering.
>>
>> I also like the /portmap/ on the top-level function
>> because as designer I can create a default portmap,
>> often a top-level is for a specific hardware, as
>> the module designer I can define the default portmap
>> (shortcut for any user).  I like this because if I
>> have multiple tests, conversion scripts, etc I don't
>> have to recreate the port definitions in each or
>> define the port signals somewhere else (detached).
>>
>> Regards,
>> Chris
>>
>>
>>>
>>> On Fri, Feb 14, 2014 at 8:50 AM, Christopher Felton
>>> <chr...@gm...>wrote:
>>>
>>>> Previously, we had a short discussion that the MEP107
>>>> interface conversion for top-levels (e.g modules being
>>>> converted) introduced a need for a generated /portmap/ [1].
>>>>
>>>> The main uses case, given a module:
>>>>
>>>>        def m_some_mod(ifc1, ifc2):
>>>>            # ...
>>>>
>>>> If I am verifying the above module via co-simulation,
>>>> without a /portmap/ I would need to manually write a
>>>> wrapper or manually breakout all the interface /Signals/
>>>> when building the /Cosimulation/, example:
>>>>
>>>>        Cosimualation(simcmd, ifc1_di=ifc1.di, ifc1_do=ifc1.do ...
>>>>
>>>> In this case it defeats the purpose of the interfaces.
>>>> To address this complication Keerthan proposed a /portmap/
>>>> be generated in the conversion functions, the above would
>>>> then become:
>>>>
>>>>        Cosimulation(simcmd, **portmap)
>>>>
>>>> Ahhh, much better :)
>>>>
>>>> The /toV*/ functions already return a list generators in
>>>> the module.  The /portmap/ can't be returned from the
>>>> /toV*/ functions without breaking backwards compatibility.
>>>>
>>>> The current proposal is to attach a function attribute to the
>>>> /toV*/ functions, e.g:
>>>>
>>>>        toVerilog.portmap
>>>>
>>>> The /toV*.portmap/ would be the dictionary of the converted
>>>> portmap (interface expanded names).
>>>>
>>>> I would like to propose and discuss attaching the /portmap/
>>>> attribute to the function being converted and not the
>>>> conversion functions.  To me this is a more natural (I don't
>>>> know if this is generally pythonic (accepted) to have other
>>>> functions modify and/or add attributes to other functions).
>>>>
>>>> In addition, I would propose that generated portmap saved
>>>> in the /vportmap/ attribute and the /portmap/ attribute
>>>> to be used as a user defined default port definition.
>>>>
>>>> Keerthan has done an amazing job implementing MEP-107, many
>>>> thanks!  He has also created a pull-request for the
>>>> /toVerilog.portmap/, I wanted to have a short discussion
>>>> and make sure this is the most flexible path moving forward.
>>>> Once we finalize the portmap I can update the MEP.
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>> [1] http://thread.gmane.org/gmane.comp.python.myhdl/3223/focus=3318
>>>>
>>>>