Thread: Re: [myhdl-list] MEP 107 Initial support (Page 2)
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Christopher F. <chr...@gm...> - 2013-08-08 15:46:27
|
On 8/8/2013 10:40 AM, Keerthan jai.c wrote:
> Originally, the implementation did not touch any of the 'reserved'
> attriubutes ('next' etc..) whose names were stored in a list.
> But now, rather than relying on a list of reserved attributes, it just
> ignores all attributes which myhdl._Signal._Signal has, based on hasattr.
Yes, that is a better approach.
>
> The side effect of this is that it is possible to inherit the Signal class
> and add custom attributes without affecting conversion. It is not a
> feature, per se.
>
Ok, I like that. You get a "nice side effect" for
cleanup and/or more general support.
Thanks,
Chris
|
|
From: Christopher F. <chr...@gm...> - 2013-10-02 19:33:30
|
<snip>
>
> This seems like a reasonable approach, with a port
> definition list. But should it be an attribute or a
> return of the toV* functions?
Nevermind, it looks like toV* already has a return
that I forgot/never new. I am not sure what/how the
return is used, it appears to return the top-level that
is passed. Maybe the return can be:
return h.top,portmap
I don't know if this breaks any existing code.
Regards,
Chris
|
|
From: Christopher F. <chr...@gm...> - 2013-12-02 23:12:44
|
On 10/2/2013 2:45 PM, Keerthan jai.c wrote:
> toVerilog returns whatever would be returned if you called the function
> directly, usually a tuple of generators. So, someone could hypothetically
> have been passing the return value of toVerilog to a myhdl.Simulation
> object. Returning the portmap alongside the previous return value would
> break their code.
>
> toVerilog.portmap seems reasonable.
>
>
How about the /portmap/ is tied to the module
(the function being passed) instead of the toV*?
Because of another request I was thinking - it
could be useful to define the "default" port
types in a /portmap/ function attribute.
Couple benefits:
1. Top-level modules often are specific, there
is only one mapping that makes sense
2. removes the need to re-declare the port
(simulation and conversion)
Example:
def m_adder(a,b,c):
@always_comb
def rtl():
c.next = a + b
return rtl
iot = intbv(0, min=-8, max=8)
m_adder.portmap = {"a":Signal(iot),
"b":Signal(iot),
"c":Signal(iot)}
A /vportmap/ (or something similar) function attribute
could be used to contain the expanded names. The port
definitions would be tied to the top-level function.
.chris
|
|
From: Christopher F. <chr...@gm...> - 2013-12-03 05:10:14
|
On 12/2/13 9:06 PM, David Holl wrote:
> If you go this route with the dict, I'd encourage the use of an
> OrderedDict, so that argument order may be preserved. Then the top
> level restriction that prevents **kwargs can be relaxed because the top
> function wouldn't need to be analyzed to get at the signal names.
Other than complexity, is there is downside
to analyzing the top function to get the signal
names?
Regards,
Chris
>
> On Dec 2, 2013 6:12 PM, "Christopher Felton" <chr...@gm...
> <mailto:chr...@gm...>> wrote:
>
> On 10/2/2013 2:45 PM, Keerthan jai.c wrote:
> > toVerilog returns whatever would be returned if you called the
> function
> > directly, usually a tuple of generators. So, someone could
> hypothetically
> > have been passing the return value of toVerilog to a myhdl.Simulation
> > object. Returning the portmap alongside the previous return value
> would
> > break their code.
> >
> > toVerilog.portmap seems reasonable.
> >
> >
>
> How about the /portmap/ is tied to the module
> (the function being passed) instead of the toV*?
>
> Because of another request I was thinking - it
> could be useful to define the "default" port
> types in a /portmap/ function attribute.
>
> Couple benefits:
>
> Â Â 1. Top-level modules often are specific, there
> Â Â Â Â is only one mapping that makes sense
>
> Â Â 2. removes the need to re-declare the port
> Â Â Â Â (simulation and conversion)
>
> Example:
>
> Â Â Â def m_adder(a,b,c):
> Â Â Â Â Â @always_comb
> Â Â Â Â Â def rtl():
> Â Â Â Â Â Â Â c.next = a + b
> Â Â Â Â Â return rtl
>
> Â Â Â iot = intbv(0, min=-8, max=8)
> Â Â Â m_adder.portmap = {"a":Signal(iot),
> Â Â Â Â Â Â Â Â Â Â Â Â "b":Signal(iot),
> Â Â Â Â Â Â Â Â Â Â Â Â "c":Signal(iot)}
>
> A /vportmap/ (or something similar) function attribute
> could be used to contain the expanded names. Â The port
> definitions would be tied to the top-level function.
>
> .chris
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility
> into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> <mailto:myh...@li...>
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
|
|
From: David H. <da...@ad...> - 2013-12-03 13:52:59
|
Yeah, the down-side is for some of my parameterizable IP (coded in MyHDL)
where **kwargs is a natural fit, I currently have to write out a silly
temporary .py file just for MyHDL to analyze to extract the top-level port
names.
So, being able to relax the restriction on **kwargs (in exchange for the
caller must .portmap prior to export), would hopefully eliminate this
ugliness.
(example IP blocks: an N-port arbiter for AXI4-S streams... Or a PCIe BAR
interface that auto-creates software input/output bits for hardware control
from an OS driver...)
On Tue, Dec 3, 2013 at 12:05 AM, Christopher Felton
<chr...@gm...>wrote:
> On 12/2/13 9:06 PM, David Holl wrote:
> > If you go this route with the dict, I'd encourage the use of an
> > OrderedDict, so that argument order may be preserved. Then the top
> > level restriction that prevents **kwargs can be relaxed because the top
> > function wouldn't need to be analyzed to get at the signal names.
>
> Other than complexity, is there is downside
> to analyzing the top function to get the signal
> names?
>
> Regards,
> Chris
>
> >
> > On Dec 2, 2013 6:12 PM, "Christopher Felton" <chr...@gm...
> > <mailto:chr...@gm...>> wrote:
> >
> > On 10/2/2013 2:45 PM, Keerthan jai.c wrote:
> > > toVerilog returns whatever would be returned if you called the
> > function
> > > directly, usually a tuple of generators. So, someone could
> > hypothetically
> > > have been passing the return value of toVerilog to a
> myhdl.Simulation
> > > object. Returning the portmap alongside the previous return value
> > would
> > > break their code.
> > >
> > > toVerilog.portmap seems reasonable.
> > >
> > >
> >
> > How about the /portmap/ is tied to the module
> > (the function being passed) instead of the toV*?
> >
> > Because of another request I was thinking - it
> > could be useful to define the "default" port
> > types in a /portmap/ function attribute.
> >
> > Couple benefits:
> >
> > Â Â 1. Top-level modules often are specific, there
> > Â Â Â Â is only one mapping that makes sense
> >
> > Â Â 2. removes the need to re-declare the port
> > Â Â Â Â (simulation and conversion)
> >
> > Example:
> >
> > Â Â Â def m_adder(a,b,c):
> > Â Â Â Â Â @always_comb
> > Â Â Â Â Â def rtl():
> > Â Â Â Â Â Â Â c.next = a + b
> > Â Â Â Â Â return rtl
> >
> > Â Â Â iot = intbv(0, min=-8, max=8)
> > Â Â Â m_adder.portmap = {"a":Signal(iot),
> > Â Â Â Â Â Â Â Â Â Â Â Â "b":Signal(iot),
> > Â Â Â Â Â Â Â Â Â Â Â Â "c":Signal(iot)}
> >
> > A /vportmap/ (or something similar) function attribute
> > could be used to contain the expanded names. Â The port
> > definitions would be tied to the top-level function.
> >
> > .chris
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most
> IT
> > organizations don't have a clear picture of how application
> performance
> > affects their revenue. With AppDynamics, you get 100% visibility
> > into your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> > AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > <mailto:myh...@li...>
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> 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