Thread: [myhdl-list] MEP 107 need for portmap
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Christopher F. <chr...@gm...> - 2014-02-14 13:55:15
|
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
|
|
From: Keerthan jai.c <jck...@gm...> - 2014-02-15 21:44:16
|
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. 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 > -- have a nice day -jck |
|
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
>
|
|
From: Keerthan jai.c <jck...@gm...> - 2014-02-24 00:04:15
|
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? 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 > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> 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 > > > > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- have a nice day -jck |
|
From: Christopher F. <chr...@gm...> - 2014-03-04 19:26:07
|
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
>>>>
>>>>
|
|
From: Keerthan jai.c <jck...@gm...> - 2014-03-12 20:43:19
|
What do you think about leaving toV* to behave in their current way, storing the portmap in toV*.portmap; and creating new functions which wrap these functions and explicitly do what you proposed? On Mar 4, 2014 2:26 PM, "Christopher Felton" <chr...@gm...> wrote: > 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 > >>>> > >>>> > > > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and > the > freedom to use Git, Perforce or both. Make the move to Perforce. > > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
|
From: Christopher F. <chr...@gm...> - 2014-03-13 18:29:04
|
On 3/12/2014 3:43 PM, Keerthan jai.c wrote:
> What do you think about leaving toV* to behave in their current way,
> storing the portmap in toV*.portmap; and creating new functions which wrap
> these functions and explicitly do what you proposed?
I am not opposed to the wrapper method. To restate,
you are suggesting a wrapper, something like:
toVerilogWithPortmap(m_toplevel, portmap=portmap)
pprint(m_toplevel.portmap) # this will be all the
# converted ports.
This could be used for a dynamic portmap configuration.
Sounds fine to me.
Regards,
Chris
> On Mar 4, 2014 2:26 PM, "Christopher Felton" <chr...@gm...> wrote:
>
>> 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
>>>>>>
>>>>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries. Built-in WAN optimization and
>> the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
|
|
From: Keerthan jai.c <jck...@gm...> - 2014-03-16 13:20:41
|
What i meant was,
def toVerilogNewName(toplevel):
ret = toVerilog(toplevel, **toplevel.portmap)
toplevel.vportmap = toVerilog.portmap
return ret
On Mar 13, 2014 2:29 PM, "Christopher Felton" <chr...@gm...>
wrote:
> On 3/12/2014 3:43 PM, Keerthan jai.c wrote:
> > What do you think about leaving toV* to behave in their current way,
> > storing the portmap in toV*.portmap; and creating new functions which
> wrap
> > these functions and explicitly do what you proposed?
>
> I am not opposed to the wrapper method. To restate,
> you are suggesting a wrapper, something like:
>
> toVerilogWithPortmap(m_toplevel, portmap=portmap)
> pprint(m_toplevel.portmap) # this will be all the
> # converted ports.
>
> This could be used for a dynamic portmap configuration.
> Sounds fine to me.
>
> Regards,
> Chris
>
> > On Mar 4, 2014 2:26 PM, "Christopher Felton" <chr...@gm...>
> wrote:
> >
> >> 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
> >>>>>>
> >>>>>>
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Subversion Kills Productivity. Get off Subversion & Make the Move to
> >> Perforce.
> >> With Perforce, you get hassle-free workflows. Merge that actually works.
> >> Faster operations. Version large binaries. Built-in WAN optimization
> and
> >> the
> >> freedom to use Git, Perforce or both. Make the move to Perforce.
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> myhdl-list mailing list
> >> myh...@li...
> >> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> >
> >
> >
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X