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
:)

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

"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.

"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.

-Newman

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.

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

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.

From what I have seen, the problem is that platgen.exe (Part of EDK, not
XST) is auto generating wrappers for the IP blocks. The auto-generated
wrappers breaks out "inout" to *_I, *_O, *_T ports. It also generates a
top
level file where these signals are fed into instantiated IO blocks at the
top level. My guess is that the program that autogenerates these files
assumes that the user defined IP blocks conform to the _I, _O, _T
convention, and XST complains when it sees incompatible connections..

"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.

-Newman

TonyF,
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

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.

"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.

Regards
Falk

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.

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