I2C core questions (Avalon, SOPC)

[Thomas Winkler-4]

Hello,

I'm currently working on connecting the opencores I2C master (VHDL version) to
the NIOS 2 processor via the Avalon bus. I intend to run the NIOS 2 on the
Altera DE2 board (based on a Cyclone 2 FPGA).

So far I've completed the following step:

1) Wrapper code that implements the tri-state buffers for SCL and SDA and
eliminates ARST_LVL and arst_i at the toplevel (I've tied ARST_LVL to '0' and
arst_i to '1').
I've uploaded the source to
http://www.wnk.at/tmp/i2c/i2c_master_top_avalon.vhd

BTW: In the I2C master document there seems to be a mistake regarding the
tri-state: I think the last line should be sda_pad_i <= sda;  instead of
scl_pad_i <= sda;"


2) I've create a SOPC component. The singals and itnerfaces of the SOPC
component can be found at
http://www.wnk.at/tmp/i2c/sopc_signals.png
and
http://www.wnk.at/tmp/i2c/sopc_interfaces.png

I tried to stick to the information from the OC I2C FAQ. But I'm by no means
an SOPC or Avalon expert - so I'd be glad if someone with more experience
could have a brief look at it to tell me if it looks ok.


3) I've attached the I2C component to a simple NIOS 2 processor using SOPC
builder (see http://www.wnk.at/tmp/i2c/sopc_nios.png). After generating the
system I did a pin assignment in the Quartus II software. I assigned SCL and
SDA to pins of the expansion header of the DE2 board.
What kind of surprised me was that SCL and SDA are recongized as pure output
pins by quartus although they are marked as bidirectional in SOPC builder.
The pin assignment can be seen at:
http://www.wnk.at/tmp/i2c/pin_assignment.png

After downloading the system to the DE2 board i measured the signal levels of
the SCL and SDA pins on the DE2 board. The SCL pin is at 0V and the SDA pin
is at 1.2V.
I'm not sure if this is the expected behavior. In the pin assignment editor
the pins are set to 3.3V (TTL).
What I also didn't fully understand yet are the pull-ups. Do I have to add
external pull-up resistors (connecting SCL and SDA to 3.3V) or is that
somehow done on the board / in the FPGA?

I'm anything but an digital design / FPGA expert but I have some basic
knowledge of VHDL and realted topics. Therefore I'd appreciate any help I can
get to make this work. In case of success I'd be happy to contribute to this
project by making the SOPC I2C component available for download.

Thank you very much,
--
Thomas Winkler
tc@...
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

[beachbum]

I can't advise you on your toolset and target FPGA questions since mine are different, however you will need to make the SDA pin bidirectional.  If the FPGA is the only master, you can get away with SCL as output only, but in general you should also make it bidirectional or at least tri-state to allow other I2C masters.  You generally have to do this in the FPGA vendor's P&R constraint file since specifying or inferring the pin types in the source doesn't always get properly forwarded by the synthesis tool for various reasons.

I recommend you download version 3.0 of the I2C spec from http://www.nxp.com/acrobat_download/usermanuals/UM10204_3.pdf, which contains recommendations for pullup resistor values as well as series resistors and slope control.  You can also search for I2C at the NXP site to find relevant app notes, forums, datasheets, and reference designs.  Note that the pullup resistor value depends both on the I2C bus mode (standard, fast, fast-plus) as well as the bus capacitance.  In general, you shouldn't have less than a 10k pullup for standard mode, with 4.7k or even 2.2k a better choice for fast mode or longer, loaded I2C buses.  Although the FPGA probably has pullups, these are generally weak with a value of 50k or more to minimize FPGA bank supply current requirements and heat dissipation.

The above are only suggestions and opinions, as my I2C experience has been with different hardware and toolsets.

Tom Taylor
ttaylor_at_nospam_ateng.com

Thomas Winkler-4 wrote:

Hello,

I'm currently working on connecting the opencores I2C master (VHDL version) to
the NIOS 2 processor via the Avalon bus. I intend to run the NIOS 2 on the
Altera DE2 board (based on a Cyclone 2 FPGA).

So far I've completed the following step:

1) Wrapper code that implements the tri-state buffers for SCL and SDA and
eliminates ARST_LVL and arst_i at the toplevel (I've tied ARST_LVL to '0' and
arst_i to '1').
I've uploaded the source to
http://www.wnk.at/tmp/i2c/i2c_master_top_avalon.vhd

BTW: In the I2C master document there seems to be a mistake regarding the
tri-state: I think the last line should be sda_pad_i <= sda;  instead of
scl_pad_i <= sda;"


2) I've create a SOPC component. The singals and itnerfaces of the SOPC
component can be found at
http://www.wnk.at/tmp/i2c/sopc_signals.png
and
http://www.wnk.at/tmp/i2c/sopc_interfaces.png

I tried to stick to the information from the OC I2C FAQ. But I'm by no means
an SOPC or Avalon expert - so I'd be glad if someone with more experience
could have a brief look at it to tell me if it looks ok.


3) I've attached the I2C component to a simple NIOS 2 processor using SOPC
builder (see http://www.wnk.at/tmp/i2c/sopc_nios.png). After generating the
system I did a pin assignment in the Quartus II software. I assigned SCL and
SDA to pins of the expansion header of the DE2 board.
What kind of surprised me was that SCL and SDA are recongized as pure output
pins by quartus although they are marked as bidirectional in SOPC builder.
The pin assignment can be seen at:
http://www.wnk.at/tmp/i2c/pin_assignment.png

After downloading the system to the DE2 board i measured the signal levels of
the SCL and SDA pins on the DE2 board. The SCL pin is at 0V and the SDA pin
is at 1.2V.
I'm not sure if this is the expected behavior. In the pin assignment editor
the pins are set to 3.3V (TTL).
What I also didn't fully understand yet are the pull-ups. Do I have to add
external pull-up resistors (connecting SCL and SDA to 3.3V) or is that
somehow done on the board / in the FPGA?

I'm anything but an digital design / FPGA expert but I have some basic
knowledge of VHDL and realted topics. Therefore I'd appreciate any help I can
get to make this work. In case of success I'd be happy to contribute to this
project by making the SOPC I2C component available for download.

Thank you very much,
--
Thomas Winkler
[e-mail]
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

[Mark McDougall]

Thomas Winkler wrote:

> 1) Wrapper code that implements the tri-state buffers for SCL and SDA
> and eliminates ARST_LVL and arst_i at the toplevel (I've tied ARST_LVL
> to '0' and arst_i to '1'). I've uploaded the source to
> http://www.wnk.at/tmp/i2c/i2c_master_top_avalon.vhd

Looks OK. I've done similar in the past without any problems.

It's generally good practice to _NOT_ have any bidir ports in your design
except for the topmost level. Technically, internal bidir ports can't be
synthesized anyway, and synthesis tools just make it look like you can.
The way this is done has changed in Quartus, for example, in the last few
versions and has caused problems with some older designs that I have
re-built recently.

It's also more flexible if you omit bidir ports. I had an implementation
of a CIA/VIA chip that was originally written to interface to off-chip
peripherals, which used bidir ports. I wanted to use it to (also)
interface to on-chip peripherals, and so had to change the interface.

> BTW: In the I2C master document there seems to be a mistake regarding
> the tri-state: I think the last line should be sda_pad_i <= sda;
> instead of scl_pad_i <= sda;"

You are correct.

> 2) I've create a SOPC component. The singals and itnerfaces of the SOPC
>  component can be found at http://www.wnk.at/tmp/i2c/sopc_signals.png 
> and http://www.wnk.at/tmp/i2c/sopc_interfaces.png

Looks OK.

> 3) I've attached the I2C component to a simple NIOS 2 processor using
> SOPC builder (see http://www.wnk.at/tmp/i2c/sopc_nios.png). After
> generating the system I did a pin assignment in the Quartus II
> software. I assigned SCL and SDA to pins of the expansion header of the
> DE2 board. What kind of surprised me was that SCL and SDA are
> recongized as pure output pins by quartus although they are marked as
> bidirectional in SOPC builder. The pin assignment can be seen at:
> http://www.wnk.at/tmp/i2c/pin_assignment.png

Maybe this is related to my comment above??? I'm assuming you have a
top-level wrapper around the SOPC-generated VHD - yes? What type of port
do you have specified for SCL/SDA there? If not, it's generally a good
idea to do so...

> What I also didn't fully understand yet are the pull-ups. Do I have to
> add external pull-up resistors (connecting SCL and SDA to 3.3V) or is
> that somehow done on the board / in the FPGA?

The cyclone parts have a weak internal pullup option which you need to
specify in the assignments editor - IIRC around 22K? Depending on your
external bus/peripheral that may or may not be sufficient.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: [phone] Fax: [phone]
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

[Thomas Winkler-4]

Hello,

> It's generally good practice to _NOT_ have any bidir ports in your design
> except for the topmost level. Technically, internal bidir ports can't be
> synthesized anyway, and synthesis tools just make it look like you can.
> The way this is done has changed in Quartus, for example, in the last few
> versions and has caused problems with some older designs that I have
> re-built recently.

Ok - that means that I should not have scl and sda as inout ports in my
i2c_master_top_avalon.vhd file? My idea was to add the tri-state logic to
this file and define the ports as "inout" since i do not intend to use SCL
and SDA internally anyway but bring them out to the board pins.

> [...] I wanted to use it to (also)
> interface to on-chip peripherals, and so had to change the interface.

Ok - that absolutely makes sense to me. But since I (for now) only intend to
interface off-chips peripherals my code should be ok, right?

> Maybe this is related to my comment above??? I'm assuming you have a
> top-level wrapper around the SOPC-generated VHD - yes? What type of port
> do you have specified for SCL/SDA there? If not, it's generally a good
> idea to do so...

Yes - but my toplevel wrapper is a schematic but not a VHDL file. But the
principle should be the same. In my previous version I hat a mistake
regarding the SCL and SDA ports in the schematic. Now the are bidi ports as
they should be. See: http://www.wnk.at/tmp/i2c/toplevel.png

> The cyclone parts have a weak internal pullup option which you need to
> specify in the assignments editor - IIRC around 22K? Depending on your
> external bus/peripheral that may or may not be sufficient.

Ok - I now found out how to set the pull-up in the pin assignment editor:
http://www.wnk.at/tmp/i2c/pin_assignment_2.png
I now measure ~3.1V on the idle SDA pin but get 0V on the SCL pin which
confuses me. I'm not sure whats wrong with this one.
Do you have any idea?

Thank you,
--
Thomas Winkler
tc@...
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

[tadorta]

Hello Thomas,

I'm using the i2c_master_top core in my project, and I can tell you
that it works properly.

The bug exists, is "sda_pad_i <= sda"

To use I2C bus you need to put external pull up resistors, to force
weak high level.

To control the i2c_master_top core you need a Wishbone master. I built
my own WB master in VHDL for this propose. I don´t know if you can
control it with NIOS via avalon, I suppose u have to build some kind
of interface between wishbone and avalon.

If you have some specific question about code tell me

Taho
tadorta@...

----- Original Message -----
From: Thomas Winkler<tc@t...>
To:
Date: Thu Feb  7 09:57:08 CET 2008
Subject: [oc] I2C core questions (Avalon, SOPC)

> Hello,
>
> I'm currently working on connecting the opencores I2C master (VHDL
> version) to
> the NIOS 2 processor via the Avalon bus. I intend to run the NIOS 2
> on the
> Altera DE2 board (based on a Cyclone 2 FPGA).
> So far I've completed the following step:
> 1) Wrapper code that implements the tri-state buffers for SCL and
> SDA and
> eliminates ARST_LVL and arst_i at the toplevel (I've tied ARST_LVL
> to '0' and
> arst_i to '1').
> I've uploaded the source to
> http://www.wnk.at/tmp/i2c/i2c_master_top_avalon.vhd 
> BTW: In the I2C master document there seems to be a mistake
> regarding the
> tri-state: I think the last line should be sda_pad_i <= sda;
> instead of
> scl_pad_i <= sda;"
> 2) I've create a SOPC component. The singals and itnerfaces of the
> SOPC
> component can be found at
> http://www.wnk.at/tmp/i2c/sopc_signals.png 
> and
> http://www.wnk.at/tmp/i2c/sopc_interfaces.png 
> I tried to stick to the information from the OC I2C FAQ. But I'm by
> no means
> an SOPC or Avalon expert - so I'd be glad if someone with more
> experience
> could have a brief look at it to tell me if it looks ok.
> 3) I've attached the I2C component to a simple NIOS 2 processor
> using SOPC
> builder (see http://www.wnk.at/tmp/i2c/sopc_nios.png). After
> generating the
> system I did a pin assignment in the Quartus II software. I
> assigned SCL and
> SDA to pins of the expansion header of the DE2 board.
> What kind of surprised me was that SCL and SDA are recongized as
> pure output
> pins by quartus although they are marked as bidirectional in SOPC
> builder.
> The pin assignment can be seen at:
> http://www.wnk.at/tmp/i2c/pin_assignment.png 
> After downloading the system to the DE2 board i measured the signal
> levels of
> the SCL and SDA pins on the DE2 board. The SCL pin is at 0V and the
> SDA pin
> is at 1.2V.
> I'm not sure if this is the expected behavior. In the pin
> assignment editor
> the pins are set to 3.3V (TTL).
> What I also didn't fully understand yet are the pull-ups. Do I have
> to add
> external pull-up resistors (connecting SCL and SDA to 3.3V) or is
> that
> somehow done on the board / in the FPGA?
> I'm anything but an digital design / FPGA expert but I have some
> basic
> knowledge of VHDL and realted topics. Therefore I'd appreciate any
> help I can
> get to make this work. In case of success I'd be happy to
> contribute to this
> project by making the SOPC I2C component available for download.
> Thank you very much,
> --
> Thomas Winkler
> tc at tomwinkler.net
>
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

[Richard Herveille]

Do a search on i2c and avalon in this forum.
You're not the first one solving this problem; I should probably make a
section on the i2c project page on how to do this.

And yes, the documentation bug has been reported before, and yes I have to
fix it :)

Richard



-----Original Message-----
From: cores-bounces@... [mailto:cores-bounces@...] On
Behalf Of tadorta@...
Sent: 08 February 2008 17:27
To: cores@...
Subject: Re: [oc] I2C core questions (Avalon, SOPC)

Hello Thomas,

I'm using the i2c_master_top core in my project, and I can tell you
that it works properly.

The bug exists, is "sda_pad_i <= sda"

To use I2C bus you need to put external pull up resistors, to force
weak high level.

To control the i2c_master_top core you need a Wishbone master. I built
my own WB master in VHDL for this propose. I don´t know if you can
control it with NIOS via avalon, I suppose u have to build some kind
of interface between wishbone and avalon.

If you have some specific question about code tell me

Taho
tadorta@...

----- Original Message -----
From: Thomas Winkler<tc@t...>
To:
Date: Thu Feb  7 09:57:08 CET 2008
Subject: [oc] I2C core questions (Avalon, SOPC)

> Hello,
>
> I'm currently working on connecting the opencores I2C master (VHDL
> version) to
> the NIOS 2 processor via the Avalon bus. I intend to run the NIOS 2
> on the
> Altera DE2 board (based on a Cyclone 2 FPGA).
> So far I've completed the following step:
> 1) Wrapper code that implements the tri-state buffers for SCL and
> SDA and
> eliminates ARST_LVL and arst_i at the toplevel (I've tied ARST_LVL
> to '0' and
> arst_i to '1').
> I've uploaded the source to
> http://www.wnk.at/tmp/i2c/i2c_master_top_avalon.vhd 
> BTW: In the I2C master document there seems to be a mistake
> regarding the
> tri-state: I think the last line should be sda_pad_i <= sda;
> instead of
> scl_pad_i <= sda;"
> 2) I've create a SOPC component. The singals and itnerfaces of the
> SOPC
> component can be found at
> http://www.wnk.at/tmp/i2c/sopc_signals.png 
> and
> http://www.wnk.at/tmp/i2c/sopc_interfaces.png 
> I tried to stick to the information from the OC I2C FAQ. But I'm by
> no means
> an SOPC or Avalon expert - so I'd be glad if someone with more
> experience
> could have a brief look at it to tell me if it looks ok.
> 3) I've attached the I2C component to a simple NIOS 2 processor
> using SOPC
> builder (see http://www.wnk.at/tmp/i2c/sopc_nios.png). After
> generating the
> system I did a pin assignment in the Quartus II software. I
> assigned SCL and
> SDA to pins of the expansion header of the DE2 board.
> What kind of surprised me was that SCL and SDA are recongized as
> pure output
> pins by quartus although they are marked as bidirectional in SOPC
> builder.
> The pin assignment can be seen at:
> http://www.wnk.at/tmp/i2c/pin_assignment.png 
> After downloading the system to the DE2 board i measured the signal
> levels of
> the SCL and SDA pins on the DE2 board. The SCL pin is at 0V and the
> SDA pin
> is at 1.2V.
> I'm not sure if this is the expected behavior. In the pin
> assignment editor
> the pins are set to 3.3V (TTL).
> What I also didn't fully understand yet are the pull-ups. Do I have
> to add
> external pull-up resistors (connecting SCL and SDA to 3.3V) or is
> that
> somehow done on the board / in the FPGA?
> I'm anything but an digital design / FPGA expert but I have some
> basic
> knowledge of VHDL and realted topics. Therefore I'd appreciate any
> help I can
> get to make this work. In case of success I'd be happy to
> contribute to this
> project by making the SOPC I2C component available for download.
> Thank you very much,
> --
> Thomas Winkler
> tc at tomwinkler.net
>
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

_______________________________________________
http://www.opencores.org/mailman/listinfo/cores