Hi all I re-found once again my own "Rules of Life" what I first published 21 aug 2001 1 No Promises. 2 Keep Promises. 3 Give away what you do not need. 4 Do what you want to do. 5 Be Happy. In order to comply with Rules [5], [4] and specially [3] from the above list, I am giving a promise (those braking rule #1) that I will make all projects of my past live available as public domain. That includs all I can publish (ie all that IP that belongs to me and is not covered by 3rd party agreements), with the exception of maybe a few selected projects I am actually working on at the moment. In order to comply with [2] first project is made public today at: http://gforge.openchip.org there is OPB I2C IP-Core that uses the OpenCores I2C Core by implementing a OPB 2 Wishbone adapter. There seems to be still ongoing interest in OPB Wishbone wrappers so that sounded like a good thing to start! Antti PS as per rule #2 there is no fixed timeline how fast I will upload the projects, I started the process and will keep it going but it may take time :)
Antti Lukats: all my past live projects to be published...
Started by ●February 19, 2005
Reply by ●February 19, 20052005-02-19
Thanks Antti! You are a very generous person. There is a philosophy that you reap what you sow. It will be interesting how this comes back to you. -Newman "Antti Lukats" <antti@openchip.org> wrote in message news:cv7qqk$7le$02$1@news.t-online.com...> Hi all > > I re-found once again my own "Rules of Life" what I first published 21 aug > 2001 > > 1 No Promises. > 2 Keep Promises. > 3 Give away what you do not need. > 4 Do what you want to do. > 5 Be Happy. > > In order to comply with Rules [5], [4] and specially [3] from the above > list, I am giving a promise (those braking rule #1) that I will make all > projects of my past live available as public domain. That includs all I > can > publish (ie all that IP that belongs to me and is not covered by 3rd party > agreements), with the exception of maybe a few selected projects I am > actually working on at the moment. > > In order to comply with [2] first project is made public today at: > http://gforge.openchip.org > > there is OPB I2C IP-Core that uses the OpenCores I2C Core by implementing > a > OPB 2 Wishbone adapter. > > There seems to be still ongoing interest in OPB Wishbone wrappers so that > sounded like a good thing to start! > > Antti > > PS as per rule #2 there is no fixed timeline how fast I will upload the > projects, I started the process and will keep it going but it may take > time > :) > >
Reply by ●February 20, 20052005-02-20
Antti Lukats wrote:> Hi all > > I re-found once again my own "Rules of Life" what I first published 21 aug > 2001 > > 1 No Promises. > 2 Keep Promises. > 3 Give away what you do not need. > 4 Do what you want to do. > 5 Be Happy. > > In order to comply with Rules [5], [4] and specially [3] from the above > list, I am giving a promise (those braking rule #1) that I will make all > projects of my past live available as public domain. That includs all I can > publish (ie all that IP that belongs to me and is not covered by 3rd party > agreements), with the exception of maybe a few selected projects I am > actually working on at the moment. > > In order to comply with [2] first project is made public today at: > http://gforge.openchip.org > > there is OPB I2C IP-Core that uses the OpenCores I2C Core by implementing a > OPB 2 Wishbone adapter.Just noticed that in your VHDL code you don't use inout ports, resulting in 200% bloating of a normal inout port declaration. I presume this is because XST is too lazy to parse inouts so that we have to do some kind of backend annotation alongside HDL programming, resulting in a not very elegant code. This is probably the price to pay for such a cheap tool, so I should not really complain. Synplify will allow you to use inouts in sub modules, but it costs much more than XST. TonyF
Reply by ●February 20, 20052005-02-20
"TonyF" <not@valid.address> schrieb im Newsbeitrag news:Wp%Rd.1219$%F6.1075@newsfe4-gui.ntli.net...> Just noticed that in your VHDL code you don't use inout ports, resulting > in 200% bloating of a normal inout port declaration. I presume this is > because XST is too lazy to parse inouts so that we have to do some kindNonsense. XST can handle inouts quite good. Regards Falk
Reply by ●February 20, 20052005-02-20
There is a school of thought that all off chip IO should be inferred/instantiated at the top level, and not in sub-modules. "TonyF" <not@valid.address> wrote in message news:Wp%Rd.1219$%F6.1075@newsfe4-gui.ntli.net...> Antti Lukats wrote: > >> Hi all >> >> I re-found once again my own "Rules of Life" what I first published 21 >> aug >> 2001 >> >> 1 No Promises. >> 2 Keep Promises. >> 3 Give away what you do not need. >> 4 Do what you want to do. >> 5 Be Happy. >> >> In order to comply with Rules [5], [4] and specially [3] from the above >> list, I am giving a promise (those braking rule #1) that I will make all >> projects of my past live available as public domain. That includs all I >> can >> publish (ie all that IP that belongs to me and is not covered by 3rd >> party >> agreements), with the exception of maybe a few selected projects I am >> actually working on at the moment. >> >> In order to comply with [2] first project is made public today at: >> http://gforge.openchip.org >> >> there is OPB I2C IP-Core that uses the OpenCores I2C Core by implementing >> a >> OPB 2 Wishbone adapter. > > Just noticed that in your VHDL code you don't use inout ports, resulting > in 200% bloating of a normal inout port declaration. I presume this is > because XST is too lazy to parse inouts so that we have to do some kind of > backend annotation alongside HDL programming, resulting in a not very > elegant code. > > This is probably the price to pay for such a cheap tool, so I should not > really complain. Synplify will allow you to use inouts in sub modules, but > it costs much more than XST. > > TonyF >There is a school of thought that all off chip IO should be inferred/instantiated at the top level, and not in sub-modules. -Newman
Reply by ●February 20, 20052005-02-20
Falk Brunner wrote:> "TonyF" <not@valid.address> schrieb im Newsbeitrag > news:Wp%Rd.1219$%F6.1075@newsfe4-gui.ntli.net... > > >>Just noticed that in your VHDL code you don't use inout ports, resulting >>in 200% bloating of a normal inout port declaration. I presume this is >>because XST is too lazy to parse inouts so that we have to do some kind > > > Nonsense. XST can handle inouts quite good.Only if they are at the top level. If they are in a sub-module, XST will complain about not finding the *_I, *_O and *_T ports in your sub-module (see my other post). TonyF
Reply by ●February 20, 20052005-02-20
newman5382 wrote:> There is a school of thought that all off chip IO should be > inferred/instantiated at the top level, and not in sub-modules. >In the end, everything is flattened and becomes top-level, but in your HDL code it is useful to have sub-modules for clarity, code maintenance and reusability. It should be obvious or possible to tell to a synthesis tool that your inout port in your sub-module really is an external port. TonyF
Reply by ●February 20, 20052005-02-20
"TonyF" <not@valid.address> wrote in message news:rl1Sd.1774$%F6.772@newsfe4-gui.ntli.net...> newman5382 wrote: > >> There is a school of thought that all off chip IO should be >> inferred/instantiated at the top level, and not in sub-modules. >> > > In the end, everything is flattened and becomes top-level, but in your HDL > code it is useful to have sub-modules for clarity, code maintenance and > reusability. It should be obvious or possible to tell to a synthesis tool > that your inout port in your sub-module really is an external port. > > TonyFIt is not my HDL code. Lots of things are judgement calls, and different people will choose differently. If I look at regular HDL (non-EDK) targeted code, if I see that all the primary I/O are defined in the top level, and not buried at some unknown level of the hierarchy, it gives me a warm fuzzy that the other person made some effort for other people to understand the flow of the design. As far as your complaint about the XST synthesys tool, since I own a bunch of Synplicity stock, I think it would be best for me to not address that issue. -Newman
Reply by ●February 20, 20052005-02-20
newman5382 wrote:> It is not my HDL code. > > Lots of things are judgement calls, and different people will choose > differently. If I look at regular HDL (non-EDK) targeted code, if I see > that all the primary I/O are defined in the top level, and not buried at > some unknown level of the hierarchy, it gives me a warm fuzzy that the other > person made some effort for other people to understand the flow of the > design.The designer's HDL code should not target such low level. An inout is just that, an inout, not much to understand. In Xilinx FPGAs this will be inferred as an IOBUF that will provide the *_I, *_O and *_T ports. With other vendors or ASIC it might be inferred as something else (though equivalent). > As far as your complaint about the XST synthesys tool, since I own a bunch> of Synplicity stock, I think it would be best for me to not address that > issue.I did try my code with Synplify (outside EDK) and I didn't have this problem. Nevertheless I still think EDK/ISE is a nice tool for project management/implementation and great value for money. TonyF
Reply by ●February 20, 20052005-02-20
"newman5382" <newman5382@yahoo.com> wrote in message news:GP1Sd.96890$qB6.89122@tornado.tampabay.rr.com...> > "TonyF" <not@valid.address> wrote in message > news:rl1Sd.1774$%F6.772@newsfe4-gui.ntli.net... >> newman5382 wrote: >> >>> There is a school of thought that all off chip IO should be >>> inferred/instantiated at the top level, and not in sub-modules. >>> >> >> In the end, everything is flattened and becomes top-level, but in your >> HDL code it is useful to have sub-modules for clarity, code maintenance >> and reusability. It should be obvious or possible to tell to a synthesis >> tool that your inout port in your sub-module really is an external port. >> >> TonyF > > > It is not my HDL code. > > Lots of things are judgement calls, and different people will choose > differently. If I look at regular HDL (non-EDK) targeted code, if I see > that all the primary I/O are defined in the top level, and not buried at > some unknown level of the hierarchy, it gives me a warm fuzzy that the > other person made some effort for other people to understand the flow of > the design. > > As far as your complaint about the XST synthesys tool, since I own a bunch > of Synplicity stock, I think it would be best for me to not address that > issue. > > -NewmanTonyF, I looked at the code section in question. It appeared to be two IO lines SDA, SCL that were broken out into input, output, and tristate control. I did an I2C design a while back, and I found it convenient to break out the signals in a similar manner. -Newman
