Re: [myhdl-list] MEP 107 need for portmap
Brought to you by:
jandecaluwe
Menu
▾
▴
Re: [myhdl-list] MEP 107 need for portmap
|
From: Christopher F. <chr...@gm...> - 2014-02-20 17:02:32
|
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
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience. Start now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
|
