FPGARelated.com
Forums
   Forums    More Forums    comp.arch.fpga  

using i2c core

Started by CMOS ●October 17, 2005
Summary A developer is seeking assistance with configuring the SDA and SCL ports for an open-source I2C core within a Xilinx FPGA design.

A developer is seeking assistance with configuring the SDA and SCL ports for an open-source I2C core within a Xilinx FPGA design. The discussion focuses on resolving a 'Translation Error 924' encountered when implementing bidirectional signals using IO buffers.

Community members advise on the correct use of the IOBUF primitive and the necessity of an open-drain configuration where the output is tied to ground and controlled via the tri-state enable pin.

  • I2C signals require an open-drain configuration, typically achieved by grounding the buffer input and toggling the tri-state enable.
  • The Xilinx IOBUF primitive should be used as a single element rather than trying to manually combine separate IBUF and OBUFT primitives.
  • Proper signal mapping for the IOBUF involves connecting the core's output enable to .T, the grounded output to .I, and the core's input to .O.
  • Translation Error 924 often indicates a mismatch between port directions or illegal connections to unbuffered inputs.
VHDLI2CFPGA DesignXilinx
hi,
im trying to use i2c open source core available from opensorces.org and
having problems with cofiguring the "scl" and "sda" from the top level
design with the use of IO buffers. if anyone got experience on how to
correctly configure these two ports from a top level hierachy, pls let
me know.

thank you.
CMOS
Reply by Symon ●October 17, 20052005-10-17
Hello CMOS,
Sadly, I've spent the last fortnight following your advice.
http://tinyurl.com/76ovq
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. ;-)


"CMOS" <manusha@millenniumit.com> wrote in message 
news:1129562457.464856.260830@g43g2000cwa.googlegroups.com...

> hi,
> im trying to use i2c open source core available from opensorces.org and
> having problems with cofiguring the "scl" and "sda" from the top level
> design with the use of IO buffers. if anyone got experience on how to
> correctly configure these two ports from a top level hierachy, pls let
> me know.
>
> thank you.
> CMOS
>
Reply by CMOS ●October 18, 20052005-10-18
here we go again...showing off stupidity....
Reply by Bevan Weiss ●October 18, 20052005-10-18
CMOS wrote:

> 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?
Reply by c d saunter ●October 18, 20052005-10-18
CMOS (manusha@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...

---
Reply by CMOS ●October 19, 20052005-10-19
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.

http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/7bf06cf65c8e6a76/d33a8d735c04af66?q=clk+clock+coffee&rnum=1&hl=en#d33a8d735c04af66
or serch for "clk clock coffee cocoa" in this forum.

Thank you.
CMOS
Reply by John_H ●October 19, 20052005-10-19
"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:

> 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.
> 
> http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/7bf06cf65c8e6a76/d33a8d735c04af66?q=clk+clock+coffee&rnum=1&hl=en#d33a8d735c04af66
> or serch for "clk clock coffee cocoa" in this forum.
> 
> Thank you.
> CMOS
Reply by CMOS ●October 19, 20052005-10-19
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
Reply by Bevan Weiss ●October 19, 20052005-10-19
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?
Reply by Bevan Weiss ●October 19, 20052005-10-19
Bevan Weiss wrote:

> 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 <= scl_pad_o when (scl_padoen_oe = &#4294967295;0&#4294967295;) else &#4294967295;Z&#4294967295;;
sda <= sda_pad_o when (sda_padoen_oe = &#4294967295;0&#4294967295;) else &#4294967295;Z&#4294967295;;
scl_pad_i <= scl;
scl_pad_i <= sda;

This code (as copied from specs doc for opencores I2C core) should infer 
a tri-state buffer into the mix.

Alternatively, you could create instances of an IOBUF, however this 
shouldn't be needed.