using i2c core

Hello CMOS, Sadly, I've spent the last fortnight following your advice.

Trouble is, my eyesight has been badly affected. Could you post in a bigger font? That would.... omigod, what's s/he going to do with THAT? Cheers, Syms. p.s. So, normally from an FPGA clock is an output, try searching for OBUF in the libraries guide. Data is bi-directional (like a large percentage of the folks on those sites you recommended) so look for OBUFT and IBUF. ;-)

here we go again...showing off stupidity....

Well he has been your only reply, so perhaps you should just humor him some and leave his comments be.

Other than that, he wasn't far off. I2C is a shared interface, usually using open drain/collector pull-down connections. So it will require the use of a tri-state output buffer. You will simply set the output value to always be a low value (ie always pulling low) and the only signal that will be controlled for the pin is the output enable. Both pins should be bi-directional, to be capable of operating in either master/slave mode, and to tolerate clock stretching.

So as long as you assign the output signals from your I2C module to tri-statable pins everything should be ok.

Is that what you're after?

CMOS ( snipped-for-privacy@millenniumit.com) wrote: : here we go again...showing off stupidity....

Yay veriily, showing off with an understanding of capitalisation no less, and even providing an on topic response to someone who's heading for my usenet killfile...

i've done that already. im using IOBUF at the port. but at the traslation stage it gives an error "ERROR:924" which says the port is connectod to an non-buffered input. in detail this is what i have. i got six port signals comming out from the i2c interface to generate that open drain "scl" and "sda" outputs. namely, sda_pad_o - this is internaly connected to ground as you said. (port type -out) scl_pad_o - this too is internaly connected to ground as you said.(port type -out) sda_pad_oen - this is the buffer enable/disable output for sda.(port type -out) scl_pad_oen - this is the buffer enable/disable output for scl.(port type -out) sda_pad_i - this is the buffer enable/disable output for sda.(port type - in) scl_pad_i - this is the buffer enable/disable output for scl.(port type - in)

what im doing in the top level design is to connect those signals to two IOBUF's, where bidirectional pin of those two IOBUF's are used as the final sda and scl. im sure the connections are correct. when i do so, in the traslation phase it gives the error "ERROR:924".

Please help me on this.

p.s: Im new to vhdl and FPGA and i got lot of questions, some of which are very silly. But symon knew VHDL since his birth and im proud of him. let me know a better forum if im too in-experienced here.

or serch for "clk clock coffee cocoa" in this forum.

Thank you. CMOS

"im sure the connections are correct"

Is the IOBUF's input hooked up to the output from the core (which you found is always ground) and is the I/O buf's output hooked up the the input to your core? I've mentally stumbled on the .O feeding my inputs and not being what I drive and vice-versa on the other side.

The .I is the input *to* the IOBUF and the .O is the output *from* the IOBUF.

It's a shot.

- John_H

CMOS wrote:

hi, the IOBUF im using has 4 pins. it is made of one TRISTATE output buffer and input buffer. the inputbuffer's input and tri_state output buffers output is connected together and function as the IO port for the entity. the input of the tristate output buffer is connected to the output from the core, which is always grounded. its enable/disable pin is also controlled by the core. the output of the input buffer is connected to an input of the core.

CMOS

Does the output from the core not just have two pins for SCL and another two for SDA?

I'd have just thought that you'd have: OE for SCL connected to SCL output from core I for SCL connected to SCL input from core OE for SDA connected to SDA output from core I for SDA connected to SDA input from core

Which signals are available from this I2C core?

Never mind I've seen the spec myself now... If you're using VHDL, then what's wrong with simply following the guide laid out in the specs doc? Or are these errors found when doing that?

scl

this is exactly what i did initialy. when i do that, i cant see any ports corresponding to the outputs ( i.e scl and sda ) when i try to assign those to chip scope pro logic analyzer core using chipscope pro core inserter. im not sure whther the mentioned error comes for that configuration too ( ERROR:924). When i changed the design to the one i explained, Core inserter shows those outports so that i can assign them to trigger ports, but that error comes in the translation stage.

CMOS

"the inputbuffer's input and tri_state output buffers output is connected together"

and

"the input of the tristate output buffer is connected to the output from the core"

seems to suggest an extra connection.

sda_pad_o to IOBUF.I sda_pad_oen to IOBUF.T sda_pad_i to IOBUF.O pad to IOBUF.IO

similar for clock.

CMOS wrote:

if i do that there will be an output ( out put of the input Buffer ) without any connections. ( the IO buffer im talking about is made up of one OBUF and one IBUF.). is there a way to post images in this forum, so that i can post the diagram? CMOS

Then you've found the problem. If you're using one pad for a bidirectional signal, don't use two primitives. Use the *one* IOBUF primitive which has four ports: .I, .O, .T, and .IO. That's what the tools are designed to do.

If you wanted to use a primitive to instantiate a flip-flop, you wouldn't get the same results if you instantiated a master latch and a slave latch because (even though a register is a combination of those two) the tool understands the FF as a single element.

The tool understands a bidirectional pad as a single element.

thats what im using. I just explained the structure of it.

You explained that you were using an IBUF and an OBUF and that the number of connections I listed - the .I, .O, .T, and .IO - fell one showrt for your parts. Parts plural.

Are you 1) using an IBUF primitive with .I and .O ports and an OBUFT primitive with a .I, .O, and .T port or are you 2) using a single IOBUF primitive with the _oen connected to the .T, the _o connected to the .I, the _i connected to the .o and the pad connected to the .IO.

YOU NEED ONE PRIMITIVE - the IOBUF If you use the IBUF and the OBUFT primitivers, it will be like trying to convince the tools that two latch primitives make up a flop.

From before: sda_pad_o to IOBUF.I sda_pad_oen to IOBUF.T sda_pad_i to IOBUF.O pad to IOBUF.IO

And also from before: if i do that there will be an output ( out put of the input Buffer ) without any connections. ( the IO buffer im talking about is made up of one OBUF and one IBUF.).

You cannot make your own IOBUF from the OBUF and IBUF primitives. Use the IOBUF primitive as declared at:

Here the primitive has two buffers but it DOES NOT have an IBUF and an OBUF primitive. It is a single primitive itself.

Dogspeed.

hi, sure, that is exactly what im doing ( using the IOBUF) . i just explained the structure of IOBUF, as it looks like one OBUF and one IBUF connected together.

the problem with the IOBUF is translation error "ERROR:924". ( which made me to try various other combinations. ) . i dont even understand that error and there are no xilinx answers associated with it.

CMOS

So I asked if you were sure you had your output hooked up to the .i and the input hooked up to the .o for the IOBUF and I believe that was where you started talking about "not enough signals."

It's easy to get confused and hook the .o to the output and the .i to the input which would result in complaints from the tools.

no, i've connected them according to what you've mentioned. But translation error is still there. CMOS