« Return to Thread: I2C core questions (Avalon, SOPC)
Re: I2C core questions (Avalon, SOPC)
by Mark McDougall
::
Rate this Message:
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: +612-9599-3255 Fax: +612-9599-3266
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores
> 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: +612-9599-3255 Fax: +612-9599-3266
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores
« Return to Thread: I2C core questions (Avalon, SOPC)
| Free embeddable forum powered by Nabble | Forum Help |
