Re: [myhdl-list] MEP 107 need for portmap
Brought to you by:
jandecaluwe
Menu
▾
▴
Re: [myhdl-list] MEP 107 need for portmap
|
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
>
|
