Thread: [myhdl-list] MEP 107 Initial support
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Keerthan jai.c <jck...@gm...> - 2013-07-04 02:44:54
|
Hi, I've added inital support for conversion of attribute references. So far, it does not support inferring port names at the top level. However, it does support attribute referencing in lower levels of the hierarchy. I have not yet tested it extensively, but I did confirm it does not break any older tests. You can find it in the MEP107 branch here: https://bitbucket.org/jck2/myhdl -- have a nice day -jck |
|
From: Keerthan jai.c <jck...@gm...> - 2013-07-05 02:38:13
|
I have also added support for inferring portnames from objects. There is no depth restriction, You can safely use something like instance.attr1.attr2.next = something. Feel free to try it out and let me know if you experience any errors. On Wed, Jul 3, 2013 at 10:44 PM, Keerthan jai.c <jck...@gm...>wrote: > Hi, > > I've added inital support for conversion of attribute references. So far, > it does not support inferring port names at the top level. However, it does > support attribute referencing in lower levels of the hierarchy. I have not > yet tested it extensively, but I did confirm it does not break any older > tests. > > You can find it in the MEP107 branch here: > https://bitbucket.org/jck2/myhdl > > -- > have a nice day > -jck > -- have a nice day -jck |
|
From: Christopher F. <chr...@gm...> - 2013-07-05 15:12:11
|
On 7/3/13 9:44 PM, Keerthan jai.c wrote: > Hi, > > I've added inital support for conversion of attribute references. So > far, it does not support inferring port names at the top level. However, > it does support attribute referencing in lower levels of the hierarchy. > I have not yet tested it extensively, but I did confirm it does not > break any older tests. > > You can find it in the MEP107 branch here: https://bitbucket.org/jck2/myhdl > > -- > have a nice day > -jck Thanks for the contribution! I am unavailable for the next couple days (holiday in the states) but when I return I will "pull request" my tests for MEP107 and give the changes a look. One logistical nit. You made the changes to the default branch. We have been doing all our development on a branch (so that bug fixes can be made on the default branch). This enhancement implementation should be on a 0.9-dev branch. I don't know if anyone can create the branch or if Jan needs to create it? If we decide this implementation is desired, the current bundle (commit, pull request, etc) could not be accepted because it is on the default branch. Regards, Chris Felton |
|
From: Christopher F. <chr...@gm...> - 2013-07-05 15:25:43
|
On 7/5/13 10:11 AM, Christopher Felton wrote: > On 7/3/13 9:44 PM, Keerthan jai.c wrote: >> Hi, >> >> I've added inital support for conversion of attribute references. So >> far, it does not support inferring port names at the top level. However, >> it does support attribute referencing in lower levels of the hierarchy. >> I have not yet tested it extensively, but I did confirm it does not >> break any older tests. >> >> You can find it in the MEP107 branch here: https://bitbucket.org/jck2/myhdl >> >> -- >> have a nice day >> -jck > > > One logistical nit. You made the changes to the default > branch. We have been doing all our development on a branch > (so that bug fixes can be made on the default branch). This > enhancement implementation should be on a 0.9-dev branch. > I don't know if anyone can create the branch or if Jan needs > to create it? > My bad, I see you created a mep107 branch. This should work fine. > Regards, > Chris Felton > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > |
|
From: Keerthan jai.c <jck...@gm...> - 2013-07-06 21:58:43
|
Thanks! Don't forget to sync your fork with mine before running your tests.. On Fri, Jul 5, 2013 at 11:25 AM, Christopher Felton <chr...@gm...>wrote: > On 7/5/13 10:11 AM, Christopher Felton wrote: > > On 7/3/13 9:44 PM, Keerthan jai.c wrote: > >> Hi, > >> > >> I've added inital support for conversion of attribute references. So > >> far, it does not support inferring port names at the top level. However, > >> it does support attribute referencing in lower levels of the hierarchy. > >> I have not yet tested it extensively, but I did confirm it does not > >> break any older tests. > >> > >> You can find it in the MEP107 branch here: > https://bitbucket.org/jck2/myhdl > >> > >> -- > >> have a nice day > >> -jck > > > > > > One logistical nit. You made the changes to the default > > branch. We have been doing all our development on a branch > > (so that bug fixes can be made on the default branch). This > > enhancement implementation should be on a 0.9-dev branch. > > I don't know if anyone can create the branch or if Jan needs > > to create it? > > > > My bad, I see you created a mep107 branch. This should > work fine. > > > Regards, > > Chris Felton > > > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- have a nice day -jck |
|
From: Christopher F. <chr...@gm...> - 2013-07-11 14:12:39
|
On 7/6/2013 4:58 PM, Keerthan jai.c wrote: > Thanks! > > Don't forget to sync your fork with mine before running your tests.. > > I was unable to find the tests I thought I had created in the past (more than likely never existed). I will provide some feedback ASAP. Regards, Chris |
|
From: Christopher F. <chr...@gm...> - 2013-07-14 04:00:40
|
On 7/4/13 9:37 PM, Keerthan jai.c wrote: > I have also added support for inferring portnames from objects. > There is no depth restriction, You can safely use something like > instance.attr1.attr2.next = something. > > Feel free to try it out and let me know if you experience any errors. > > > On Wed, Jul 3, 2013 at 10:44 PM, Keerthan jai.c <jck...@gm... > <mailto:jck...@gm...>> wrote: > > Hi, > > I've added inital support for conversion of attribute references. So > far, it does not support inferring port names at the top level. > However, it does support attribute referencing in lower levels of > the hierarchy. I have not yet tested it extensively, but I did > confirm it does not break any older tests. > > You can find it in the MEP107 branch here: > https://bitbucket.org/jck2/myhdl > > -- > have a nice day > -jck > > I have not had time to review the changes line-by-line but I have added a couple unit tests [1] and tested on a project [2][3]. jck has added the unit tests to the repository mentioned above [4]. See jck's repo for the latest implementation. Functionally this implementation looks complete and has tested well. Thanks for the implementation jck! This is really exciting. All the tests in conversion/general appear to pass, need to run the other tests when we have a chance. Regards, Chris Felton [1] https://bitbucket.org/cfelton/myhdl_interfaces_09dev [2] https://github.com/cfelton/minnesota/tree/myhdl_09 https://github.com/cfelton/minnesota/blob/myhdl_09/mn/cores/usb_ext/fpgalink/_fpgalink_fx2.py [3] https://groups.google.com/forum/#!topic/fpgalink-users/P8q7texZqIQ [4] https://bitbucket.org/jck2/myhdl |
|
From: Keerthan jai.c <jck...@gm...> - 2013-07-29 22:24:11
|
Thanks a lot Chris! Jan, Did you get a chance to take a look at the implementation? I would love to hear some feedback on whether you think this implementation can be merged into myhdl. On Sun, Jul 14, 2013 at 12:00 AM, Christopher Felton <chr...@gm... > wrote: > On 7/4/13 9:37 PM, Keerthan jai.c wrote: > > I have also added support for inferring portnames from objects. > > There is no depth restriction, You can safely use something like > > instance.attr1.attr2.next = something. > > > > Feel free to try it out and let me know if you experience any errors. > > > > > > On Wed, Jul 3, 2013 at 10:44 PM, Keerthan jai.c <jck...@gm... > > <mailto:jck...@gm...>> wrote: > > > > Hi, > > > > I've added inital support for conversion of attribute references. So > > far, it does not support inferring port names at the top level. > > However, it does support attribute referencing in lower levels of > > the hierarchy. I have not yet tested it extensively, but I did > > confirm it does not break any older tests. > > > > You can find it in the MEP107 branch here: > > https://bitbucket.org/jck2/myhdl > > > > -- > > have a nice day > > -jck > > > > > > I have not had time to review the changes line-by-line > but I have added a couple unit tests [1] and tested on > a project [2][3]. > > jck has added the unit tests to the repository mentioned > above [4]. See jck's repo for the latest implementation. > > Functionally this implementation looks complete and has > tested well. Thanks for the implementation jck! This > is really exciting. All the tests in conversion/general > appear to pass, need to run the other tests when we have > a chance. > > Regards, > Chris Felton > > [1] https://bitbucket.org/cfelton/myhdl_interfaces_09dev > [2] https://github.com/cfelton/minnesota/tree/myhdl_09 > > > https://github.com/cfelton/minnesota/blob/myhdl_09/mn/cores/usb_ext/fpgalink/_fpgalink_fx2.py > [3] https://groups.google.com/forum/#!topic/fpgalink-users/P8q7texZqIQ > [4] https://bitbucket.org/jck2/myhdl > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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...> - 2013-08-06 02:11:23
|
On 7/29/13 5:23 PM, Keerthan jai.c wrote: > Thanks a lot Chris! > > Jan, > Did you get a chance to take a look at the implementation? I would love > to hear some feedback on whether you think this implementation can be > merged into myhdl. > > @jck, I just submitted a pull-request with some mods to the tests and a start on some documentation. At this point I would suggest we create a 0.9-dev branch, merge the mep-107 to the 0.9-dev, and create a pull-request to Jan's repo. It will be easier to comment on the changes etc. in the pull-request. Regards, Chris |
|
From: Keerthan jai.c <jck...@gm...> - 2013-08-07 21:31:25
|
I just pushed better support for dealing with signal attributes.
This enables us to do cool things such as subclassing Signal to define a
bitfield.
Among other things, I beleive this feature will be helpful to describe
things like instruction opcodes, which are actually a single signal(in
memory), rather than a collection of discrete signals.
For example:
class Operand(Signal):
def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]):
val = concat(fielda, fieldb)
super(Operand, self).__init__(val)
self.opcode = self(20, 16)
self.a = self(16, 8)
self.b = self(8, 0)
def decoder(operand, ...):
@always_comb
def logic():
if operand.opcode == ...
...
and in the generated HDL, operand.opcode would refer to bits 20:16.
On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton
<chr...@gm...>wrote:
> On 7/29/13 5:23 PM, Keerthan jai.c wrote:
> > Thanks a lot Chris!
> >
> > Jan,
> > Did you get a chance to take a look at the implementation? I would love
> > to hear some feedback on whether you think this implementation can be
> > merged into myhdl.
> >
> >
>
> @jck,
>
> I just submitted a pull-request with some mods to
> the tests and a start on some documentation. At
> this point I would suggest we create a 0.9-dev branch,
> merge the mep-107 to the 0.9-dev, and create a
> pull-request to Jan's repo.
>
> It will be easier to comment on the changes etc. in
> the pull-request.
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
--
have a nice day
-jck
|
|
From: Keerthan jai.c <jck...@gm...> - 2013-08-07 21:33:57
|
Oops, the first line in __init__ of Operand should be: concat(opcode, a, b) On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm...> wrote: > I just pushed better support for dealing with signal attributes. > > This enables us to do cool things such as subclassing Signal to define a > bitfield. > Among other things, I beleive this feature will be helpful to describe > things like instruction opcodes, which are actually a single signal(in > memory), rather than a collection of discrete signals. > For example: > > class Operand(Signal): > def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]): > val = concat(fielda, fieldb) > super(Operand, self).__init__(val) > self.opcode = self(20, 16) > self.a = self(16, 8) > self.b = self(8, 0) > > def decoder(operand, ...): > @always_comb > def logic(): > if operand.opcode == ... > ... > > and in the generated HDL, operand.opcode would refer to bits 20:16. > > > > On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton < > chr...@gm...> wrote: > >> On 7/29/13 5:23 PM, Keerthan jai.c wrote: >> > Thanks a lot Chris! >> > >> > Jan, >> > Did you get a chance to take a look at the implementation? I would love >> > to hear some feedback on whether you think this implementation can be >> > merged into myhdl. >> > >> > >> >> @jck, >> >> I just submitted a pull-request with some mods to >> the tests and a start on some documentation. At >> this point I would suggest we create a 0.9-dev branch, >> merge the mep-107 to the 0.9-dev, and create a >> pull-request to Jan's repo. >> >> It will be easier to comment on the changes etc. in >> the pull-request. >> >> Regards, >> Chris >> >> >> >> >> ------------------------------------------------------------------------------ >> Get your SQL database under version control now! >> Version control is standard for application code, but databases havent >> caught up. So what steps can you take to put your SQL databases under >> version control? Why should you start doing it? Read more to find out. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list >> > > > > -- > have a nice day > -jck > -- have a nice day -jck |
|
From: Keerthan jai.c <jck...@gm...> - 2013-08-07 22:00:01
|
I just created a 0.9-dev branch, merged the mep107 branch into it and sent a pull request to jandecaluwe/myhdl. If you would like to improve upon this implementation, you can fork the mep107 branch at https://bitbucket.org/jck2/myhdl/* *and send me a pull request. The full changeset can be viewed here: https://bitbucket.org/jandecaluwe/myhdl/pull-request/3/ On Wed, Aug 7, 2013 at 5:33 PM, Keerthan jai.c <jck...@gm...> wrote: > Oops, the first line in __init__ of Operand should be: > concat(opcode, a, b) > > > On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm...>wrote: > >> I just pushed better support for dealing with signal attributes. >> >> This enables us to do cool things such as subclassing Signal to define a >> bitfield. >> Among other things, I beleive this feature will be helpful to describe >> things like instruction opcodes, which are actually a single signal(in >> memory), rather than a collection of discrete signals. >> For example: >> >> class Operand(Signal): >> def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]): >> val = concat(fielda, fieldb) >> super(Operand, self).__init__(val) >> self.opcode = self(20, 16) >> self.a = self(16, 8) >> self.b = self(8, 0) >> >> def decoder(operand, ...): >> @always_comb >> def logic(): >> if operand.opcode == ... >> ... >> >> and in the generated HDL, operand.opcode would refer to bits 20:16. >> >> >> >> On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton < >> chr...@gm...> wrote: >> >>> On 7/29/13 5:23 PM, Keerthan jai.c wrote: >>> > Thanks a lot Chris! >>> > >>> > Jan, >>> > Did you get a chance to take a look at the implementation? I would love >>> > to hear some feedback on whether you think this implementation can be >>> > merged into myhdl. >>> > >>> > >>> >>> @jck, >>> >>> I just submitted a pull-request with some mods to >>> the tests and a start on some documentation. At >>> this point I would suggest we create a 0.9-dev branch, >>> merge the mep-107 to the 0.9-dev, and create a >>> pull-request to Jan's repo. >>> >>> It will be easier to comment on the changes etc. in >>> the pull-request. >>> >>> Regards, >>> Chris >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Get your SQL database under version control now! >>> Version control is standard for application code, but databases havent >>> caught up. So what steps can you take to put your SQL databases under >>> version control? Why should you start doing it? Read more to find out. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> myhdl-list mailing list >>> myh...@li... >>> https://lists.sourceforge.net/lists/listinfo/myhdl-list >>> >> >> >> >> -- >> have a nice day >> -jck >> > > > > -- > have a nice day > -jck > -- have a nice day -jck |
|
From: Jan D. <ja...@ja...> - 2013-09-11 19:47:21
|
Hi Keerthan, Thanks for the efforts, I think this is going to be a great enhancement. Before proceeding, I have posted some comments/questions to the pull request. (I propose to keep the detail discussion there, right with the pull request.) Jan On 08/07/2013 11:59 PM, Keerthan jai.c wrote: > I just created a 0.9-dev branch, merged the mep107 branch into it and > sent a pull request to jandecaluwe/myhdl. > > > If you would like to improve upon this implementation, you can fork > the mep107 branch at https://bitbucket.org/jck2/myhdl/**and send me a > pull request. > > The full changeset can be viewed here: > https://bitbucket.org/jandecaluwe/myhdl/pull-request/3/ > > > On Wed, Aug 7, 2013 at 5:33 PM, Keerthan jai.c <jck...@gm... > <mailto:jck...@gm...>> wrote: > > Oops, the first line in __init__ of Operand should be: concat(opcode, > a, b) > > > On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm... > <mailto:jck...@gm...>> wrote: > > I just pushed better support for dealing with signal attributes. > > This enables us to do cool things such as subclassing Signal to > define a bitfield. Among other things, I beleive this feature will be > helpful to describe things like instruction opcodes, which are > actually a single signal(in memory), rather than a collection of > discrete signals. For example: > > class Operand(Signal): def __init__(opcode=intbv(0)[4:], > a=intbv(0)[8:], b=intbv(0)[8:]): val = concat(fielda, fieldb) > super(Operand, self).__init__(val) self.opcode = self(20, 16) self.a > = self(16, 8) self.b = self(8, 0) > > def decoder(operand, ...): @always_comb def logic(): if > operand.opcode == ... ... > > and in the generated HDL, operand.opcode would refer to bits 20:16. > > > > On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton > <chr...@gm... <mailto:chr...@gm...>> wrote: > > On 7/29/13 5:23 PM, Keerthan jai.c wrote: >> Thanks a lot Chris! >> >> Jan, Did you get a chance to take a look at the implementation? I >> would love to hear some feedback on whether you think this >> implementation can be merged into myhdl. >> >> > > @jck, > > I just submitted a pull-request with some mods to the tests and a > start on some documentation. At this point I would suggest we create > a 0.9-dev branch, merge the mep-107 to the 0.9-dev, and create a > pull-request to Jan's repo. > > It will be easier to comment on the changes etc. in the > pull-request. > > Regards, Chris > > > > ------------------------------------------------------------------------------ > > Get your SQL database under version control now! > Version control is standard for application code, but databases > havent caught up. So what steps can you take to put your SQL > databases under version control? Why should you start doing it? Read > more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > _______________________________________________ > myhdl-list mailing list myh...@li... > <mailto:myh...@li...> > https://lists.sourceforge.net/lists/listinfo/myhdl-list > > > > > -- have a nice day -jck > > > > > -- have a nice day -jck > > > > > -- have a nice day -jck > > > ------------------------------------------------------------------------------ > > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. Get down to > code-level detail for bottlenecks, with <2% overhead. Download for > free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > > > > _______________________________________________ myhdl-list mailing > list myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Jan D. <ja...@ja...> - 2013-09-13 21:37:47
|
I have merged this in now on bitbucket. Development is now on branch 0.9-dev, bug fixes for 0.8 on branch default. The merged-in new functionality is major - I encourage all to test further. If it all works as advertised, this is exciting because it is a fantastic example of how we can support advanced features (interfaces) in conversion even when the target languages don't support them. Let's test this thoroughly, and then create a lot of buzz about it :-) NOTE: There are 2 known issues to be resolved, one with list of Signals naming (discovered by jck), another with dynamically set attributes (discovered by me, see failing unit test in conversion/toVerilog and conversion/toVHDL. I also propose that MEP 107 is adapted to the current implementation if necessary - (iff there are features not yet supported I suggest to factor them out for a future MEP). Thanks Chris for already starting with the documentation. Jan On 09/11/2013 09:47 PM, Jan Decaluwe wrote: > Hi Keerthan, > > Thanks for the efforts, I think this is going to be a great enhancement. > > Before proceeding, I have posted some comments/questions to the > pull request. (I propose to keep the detail discussion there, right > with the pull request.) > > Jan > > > On 08/07/2013 11:59 PM, Keerthan jai.c wrote: >> I just created a 0.9-dev branch, merged the mep107 branch into it and >> sent a pull request to jandecaluwe/myhdl. >> >> >> If you would like to improve upon this implementation, you can fork >> the mep107 branch at https://bitbucket.org/jck2/myhdl/**and send me a >> pull request. >> >> The full changeset can be viewed here: >> https://bitbucket.org/jandecaluwe/myhdl/pull-request/3/ >> >> >> On Wed, Aug 7, 2013 at 5:33 PM, Keerthan jai.c <jck...@gm... >> <mailto:jck...@gm...>> wrote: >> >> Oops, the first line in __init__ of Operand should be: concat(opcode, >> a, b) >> >> >> On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm... >> <mailto:jck...@gm...>> wrote: >> >> I just pushed better support for dealing with signal attributes. >> >> This enables us to do cool things such as subclassing Signal to >> define a bitfield. Among other things, I beleive this feature will be >> helpful to describe things like instruction opcodes, which are >> actually a single signal(in memory), rather than a collection of >> discrete signals. For example: >> >> class Operand(Signal): def __init__(opcode=intbv(0)[4:], >> a=intbv(0)[8:], b=intbv(0)[8:]): val = concat(fielda, fieldb) >> super(Operand, self).__init__(val) self.opcode = self(20, 16) self.a >> = self(16, 8) self.b = self(8, 0) >> >> def decoder(operand, ...): @always_comb def logic(): if >> operand.opcode == ... ... >> >> and in the generated HDL, operand.opcode would refer to bits 20:16. >> >> >> >> On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton >> <chr...@gm... <mailto:chr...@gm...>> wrote: >> >> On 7/29/13 5:23 PM, Keerthan jai.c wrote: >>> Thanks a lot Chris! >>> >>> Jan, Did you get a chance to take a look at the implementation? I >>> would love to hear some feedback on whether you think this >>> implementation can be merged into myhdl. >>> >>> >> >> @jck, >> >> I just submitted a pull-request with some mods to the tests and a >> start on some documentation. At this point I would suggest we create >> a 0.9-dev branch, merge the mep-107 to the 0.9-dev, and create a >> pull-request to Jan's repo. >> >> It will be easier to comment on the changes etc. in the >> pull-request. >> >> Regards, Chris >> >> >> >> ------------------------------------------------------------------------------ >> >> > Get your SQL database under version control now! >> Version control is standard for application code, but databases >> havent caught up. So what steps can you take to put your SQL >> databases under version control? Why should you start doing it? Read >> more to find out. >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> >> > _______________________________________________ >> myhdl-list mailing list myh...@li... >> <mailto:myh...@li...> >> https://lists.sourceforge.net/lists/listinfo/myhdl-list >> >> >> >> >> -- have a nice day -jck >> >> >> >> >> -- have a nice day -jck >> >> >> >> >> -- have a nice day -jck >> >> >> ------------------------------------------------------------------------------ >> >> > Get 100% visibility into Java/.NET code with AppDynamics Lite! >> It's a free troubleshooting tool designed for production. Get down to >> code-level detail for bottlenecks, with <2% overhead. Download for >> free and get started troubleshooting in minutes. >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> >> >> >> >> _______________________________________________ myhdl-list mailing >> list myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list >> > > -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Keerthan jai.c <jck...@gm...> - 2013-09-14 10:08:46
|
Jan, could you elaborate on the dynamically set attributes case? None of the tests in conversion/toVerilog seem to be failing for me. On Fri, Sep 13, 2013 at 5:37 PM, Jan Decaluwe <ja...@ja...> wrote: > I have merged this in now on bitbucket. > > Development is now on branch 0.9-dev, bug fixes for 0.8 on > branch default. > > The merged-in new functionality is major - I encourage all to > test further. If it all works as advertised, this is exciting > because it is a fantastic example of how we can support advanced > features (interfaces) in conversion even when the target languages > don't support them. Let's test this thoroughly, and then create > a lot of buzz about it :-) > > NOTE: There are 2 known issues to be resolved, one with list of Signals > naming (discovered by jck), another with dynamically set > attributes (discovered by me, see failing unit test in > conversion/toVerilog and conversion/toVHDL. > > I also propose that MEP 107 is adapted to the current > implementation if necessary - (iff there are features not yet supported > I suggest to factor them out for a future MEP). > > Thanks Chris for already starting with the documentation. > > Jan > > > On 09/11/2013 09:47 PM, Jan Decaluwe wrote: > > Hi Keerthan, > > > > Thanks for the efforts, I think this is going to be a great enhancement. > > > > Before proceeding, I have posted some comments/questions to the > > pull request. (I propose to keep the detail discussion there, right > > with the pull request.) > > > > Jan > > > > > > On 08/07/2013 11:59 PM, Keerthan jai.c wrote: > >> I just created a 0.9-dev branch, merged the mep107 branch into it and > >> sent a pull request to jandecaluwe/myhdl. > >> > >> > >> If you would like to improve upon this implementation, you can fork > >> the mep107 branch at https://bitbucket.org/jck2/myhdl/**and send me a > >> pull request. > >> > >> The full changeset can be viewed here: > >> https://bitbucket.org/jandecaluwe/myhdl/pull-request/3/ > >> > >> > >> On Wed, Aug 7, 2013 at 5:33 PM, Keerthan jai.c <jck...@gm... > >> <mailto:jck...@gm...>> wrote: > >> > >> Oops, the first line in __init__ of Operand should be: concat(opcode, > >> a, b) > >> > >> > >> On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm... > >> <mailto:jck...@gm...>> wrote: > >> > >> I just pushed better support for dealing with signal attributes. > >> > >> This enables us to do cool things such as subclassing Signal to > >> define a bitfield. Among other things, I beleive this feature will be > >> helpful to describe things like instruction opcodes, which are > >> actually a single signal(in memory), rather than a collection of > >> discrete signals. For example: > >> > >> class Operand(Signal): def __init__(opcode=intbv(0)[4:], > >> a=intbv(0)[8:], b=intbv(0)[8:]): val = concat(fielda, fieldb) > >> super(Operand, self).__init__(val) self.opcode = self(20, 16) self.a > >> = self(16, 8) self.b = self(8, 0) > >> > >> def decoder(operand, ...): @always_comb def logic(): if > >> operand.opcode == ... ... > >> > >> and in the generated HDL, operand.opcode would refer to bits 20:16. > >> > >> > >> > >> On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton > >> <chr...@gm... <mailto:chr...@gm...>> wrote: > >> > >> On 7/29/13 5:23 PM, Keerthan jai.c wrote: > >>> Thanks a lot Chris! > >>> > >>> Jan, Did you get a chance to take a look at the implementation? I > >>> would love to hear some feedback on whether you think this > >>> implementation can be merged into myhdl. > >>> > >>> > >> > >> @jck, > >> > >> I just submitted a pull-request with some mods to the tests and a > >> start on some documentation. At this point I would suggest we create > >> a 0.9-dev branch, merge the mep-107 to the 0.9-dev, and create a > >> pull-request to Jan's repo. > >> > >> It will be easier to comment on the changes etc. in the > >> pull-request. > >> > >> Regards, Chris > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> > > Get your SQL database under version control now! > >> Version control is standard for application code, but databases > >> havent caught up. So what steps can you take to put your SQL > >> databases under version control? Why should you start doing it? Read > >> more to find out. > >> > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > >> > >> > > _______________________________________________ > >> myhdl-list mailing list myh...@li... > >> <mailto:myh...@li...> > >> https://lists.sourceforge.net/lists/listinfo/myhdl-list > >> > >> > >> > >> > >> -- have a nice day -jck > >> > >> > >> > >> > >> -- have a nice day -jck > >> > >> > >> > >> > >> -- have a nice day -jck > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> > > Get 100% visibility into Java/.NET code with AppDynamics Lite! > >> It's a free troubleshooting tool designed for production. Get down to > >> code-level detail for bottlenecks, with <2% overhead. Download for > >> free and get started troubleshooting in minutes. > >> > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > >> > >> > >> > >> > >> _______________________________________________ myhdl-list mailing > >> list myh...@li... > >> https://lists.sourceforge.net/lists/listinfo/myhdl-list > >> > > > > > > > -- > Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com > Python as a HDL: http://www.myhdl.org > VHDL development, the modern way: http://www.sigasi.com > World-class digital design: http://www.easics.com > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- have a nice day -jck |
|
From: Jan D. <ja...@ja...> - 2013-09-14 10:58:46
|
On 09/14/2013 12:08 PM, Keerthan jai.c wrote: > Jan, could you elaborate on the dynamically set attributes case? > None of the tests in conversion/toVerilog seem to be failing for me. jand@gamay:~/dev/myhdl/myhdl/test/conversion/toVerilog$ py.test test_newcustom.py ========================================================================== test session starts ========================================================================== platform linux2 -- Python 2.6.5 -- pytest-2.0.1 collected 7 items test_newcustom.py .F..... -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Keerthan jai.c <jck...@gm...> - 2013-09-16 19:26:22
|
I've pushed a fix for the list of signals naming issue. However, I think the dynamic attribute issue is a part of a bigger design flaw. I'll look over it sometime next week. On Sat, Sep 14, 2013 at 6:58 AM, Jan Decaluwe <ja...@ja...> wrote: > On 09/14/2013 12:08 PM, Keerthan jai.c wrote: > > Jan, could you elaborate on the dynamically set attributes case? > > None of the tests in conversion/toVerilog seem to be failing for me. > > jand@gamay:~/dev/myhdl/myhdl/test/conversion/toVerilog$ py.test > test_newcustom.py > ========================================================================== > test session starts > ========================================================================== > platform linux2 -- Python 2.6.5 -- pytest-2.0.1 > collected 7 items > > test_newcustom.py .F..... > > > -- > Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com > Python as a HDL: http://www.myhdl.org > VHDL development, the modern way: http://www.sigasi.com > World-class digital design: http://www.easics.com > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. > http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- have a nice day -jck |
|
From: Keerthan jai.c <jck...@gm...> - 2013-10-01 23:13:02
|
Conversion of interfaces in the top level makes the arguments for cosimulation tricky. I think one option to simplify this is to store intf as an attribute in the toVerilog and toVHDL objects. You can then pass **toVerilog.intf as the second argument to Cosimulation. On Sat, Sep 14, 2013 at 6:58 AM, Jan Decaluwe <ja...@ja...> wrote: > On 09/14/2013 12:08 PM, Keerthan jai.c wrote: > > Jan, could you elaborate on the dynamically set attributes case? > > None of the tests in conversion/toVerilog seem to be failing for me. > > jand@gamay:~/dev/myhdl/myhdl/test/conversion/toVerilog$ py.test > test_newcustom.py > ========================================================================== > test session starts > ========================================================================== > platform linux2 -- Python 2.6.5 -- pytest-2.0.1 > collected 7 items > > test_newcustom.py .F..... > > > -- > Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com > Python as a HDL: http://www.myhdl.org > VHDL development, the modern way: http://www.sigasi.com > World-class digital design: http://www.easics.com > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. > http://pubads.g.doubleclick.net/gampad/clk?id=64545871&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...> - 2013-10-02 16:36:00
|
On 10/1/2013 6:12 PM, Keerthan jai.c wrote: > Conversion of interfaces in the top level makes the arguments for > cosimulation tricky. > I think one option to simplify this is to store intf as an attribute in the > toVerilog and toVHDL objects. > You can then pass **toVerilog.intf as the second argument to Cosimulation. > > I never thought top-level interface conversion was reasonable. From my perspective it makes things difficult because, now as a user you have to know the conversion details (e.g. how the names are expanded). My opinion, is that top-level interfaces conversion should not be supported. I guess, it would be nice to flag and throw a nice error message? Regards, Chris |
|
From: Keerthan jai.c <jck...@gm...> - 2013-10-02 18:16:48
|
Name conversion is pretty straight forward (obj.attr -> obj_attr, unless
obj_attr already exists as a port). Users who don't like this can simply
not use the feature. I don't think this feature should be disabled. I don't
think its unreasonable to expect users of advanced features to be aware of
some of the implementation details.
Making the intf dict available to users as an attribute in the conversion
object will greatly simplify cosimulations, without resorting to hacks to
prevent unnecessary repetition.
Consider writing a test bench for the Mux example in the manual:
def test_mux(cosim=False):
a, b, z = [Signal(intbv(0)[8:]) for i in range(3)]
sel = Signal(intbv(0)[1:])
if cosim:
toVerilog(mux, z, a, b, sel)
os.system('iverilog -o mux.o mux.v tb_mux.v')
dut = Cosimulation('vvp -m ./myhdl.vpi mux.o', z=z, a=a, b=b,
sel=sel)
#proposed method
#dut = Cosimulation('vvp -m ./myhdl.vpi mux.o', **toVerilog.intf)
else:
dut = mux(z, a, b, sel)
@instance
def stim():
for i in range(8):
a.next, b.next, sel.next = [randrange(i) for i in (8, 8, 2)]
yield delay(10)
if sel == 1:
expected = a
else:
expected = b
assert z == expected
Simulation(dut, stim).run()
On Wed, Oct 2, 2013 at 12:35 PM, Christopher Felton
<chr...@gm...>wrote:
> On 10/1/2013 6:12 PM, Keerthan jai.c wrote:
> > Conversion of interfaces in the top level makes the arguments for
> > cosimulation tricky.
> > I think one option to simplify this is to store intf as an attribute in
> the
> > toVerilog and toVHDL objects.
> > You can then pass **toVerilog.intf as the second argument to
> Cosimulation.
> >
> >
>
> I never thought top-level interface conversion was reasonable.
> From my perspective it makes things difficult because, now as
> a user you have to know the conversion details (e.g. how the
> names are expanded).
>
> My opinion, is that top-level interfaces conversion should
> not be supported. I guess, it would be nice to flag and throw
> a nice error message?
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&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...> - 2013-10-02 19:15:15
|
On 10/2/2013 1:16 PM, Keerthan jai.c wrote: > Name conversion is pretty straight forward (obj.attr -> obj_attr, unless > obj_attr already exists as a port). Users who don't like this can simply > not use the feature. I don't think this feature should be disabled. I don't > think its unreasonable to expect users of advanced features to be aware of > some of the implementation details. > > Making the intf dict available to users as an attribute in the conversion > object will greatly simplify cosimulations, without resorting to hacks to > prevent unnecessary repetition. > I do agree for cosimulation this would be a needed feature. You don't want to force a user to write a wrapper for each module they might want to test individually. In my mind, the main use case is testing embedded modules in a larger design and not as much for the top-level simplification (where the user needs to know the expansion rules and exceptions). I was stuck on the second and not considering the first :( This seems like a reasonable approach, with a port definition list. But should it be an attribute or a return of the toV* functions? If it is an attribute I would suggest a different / more verbose name, like /portmap/ or /interfaces/. Actually, in general this might be a nice feature to simplify simulations setup. You do not need to type out the port mapping twice :) Regards, Chris |
|
From: David H. <da...@ad...> - 2013-12-03 03:59:27
|
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.
On Dec 2, 2013 6:12 PM, "Christopher Felton" <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...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
|
|
From: Keerthan jai.c <jck...@gm...> - 2013-10-02 19:46:24
|
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. On Wed, Oct 2, 2013 at 3:33 PM, Christopher Felton <chr...@gm...>wrote: > <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 > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&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...> - 2013-08-08 03:23:08
|
On 8/7/13 4:30 PM, Keerthan jai.c wrote: > I just pushed better support for dealing with signal attributes. jck, We want to be a little careful and not add too many features to a single enhancement. This addition might warrant some conversation. You might want to explain what this additional support does? I am not sure if I follow based on the example. I think it takes and attribute that is a SignalSlice and does the name expansion, etc? Personally, I think I would like to see a separate MEP for this and a separate commit for the additional feature. The MEP are great for explaining the uses cases etc. We want to be very careful and not have "feature" bloat. Regards, Chris > > This enables us to do cool things such as subclassing Signal to define a > bitfield. > Among other things, I beleive this feature will be helpful to describe > things like instruction opcodes, which are actually a single signal(in > memory), rather than a collection of discrete signals. > For example: > > class Operand(Signal): > def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]): > val = concat(fielda, fieldb) > super(Operand, self).__init__(val) > self.opcode = self(20, 16) > self.a = self(16, 8) > self.b = self(8, 0) > > def decoder(operand, ...): > @always_comb > def logic(): > if operand.opcode == ... > ... > > and in the generated HDL, operand.opcode would refer to bits 20:16. > > > |
|
From: Keerthan jai.c <jck...@gm...> - 2013-08-08 15:40:59
|
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.
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.
In my example, a class 'Operand' is defined as a subclass as Signal, and in
its __init__, attributes 'opcode', 'a' and 'b' are added as shadow signals
on particular ranges.
There are no changes to the conversion mechanism. So these attributes get
converted how normal shadow signals get converted.
On Wed, Aug 7, 2013 at 11:22 PM, Christopher Felton
<chr...@gm...>wrote:
> On 8/7/13 4:30 PM, Keerthan jai.c wrote:
> > I just pushed better support for dealing with signal attributes.
>
> jck,
>
> We want to be a little careful and not add too many
> features to a single enhancement. This addition
> might warrant some conversation.
>
> You might want to explain what this additional support
> does? I am not sure if I follow based on the example.
>
> I think it takes and attribute that is a SignalSlice
> and does the name expansion, etc? Personally, I think
> I would like to see a separate MEP for this and a separate
> commit for the additional feature. The MEP are great for
> explaining the uses cases etc. We want to be very careful
> and not have "feature" bloat.
>
> Regards,
> Chris
>
> >
> > This enables us to do cool things such as subclassing Signal to define a
> > bitfield.
> > Among other things, I beleive this feature will be helpful to describe
> > things like instruction opcodes, which are actually a single signal(in
> > memory), rather than a collection of discrete signals.
> > For example:
> >
> > class Operand(Signal):
> > def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]):
> > val = concat(fielda, fieldb)
> > super(Operand, self).__init__(val)
> > self.opcode = self(20, 16)
> > self.a = self(16, 8)
> > self.b = self(8, 0)
> >
> > def decoder(operand, ...):
> > @always_comb
> > def logic():
> > if operand.opcode == ...
> > ...
> >
> > and in the generated HDL, operand.opcode would refer to bits 20:16.
> >
> >
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
--
have a nice day
-jck
|
×
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