Actions
Forum Thread Details
  • State Not Answered
  • +1 person also asked this people also asked this
  • Replies 14 replies
  • Subscribers 356 subscribers
  • Views 570 views
  • Users 0 members are here
Related

Custom AXI4 Lite I2C checking

MATRIX7878

Hello,

       I have been working on a custom AXI4 Lite I2C core for the ZuBoard 1CG on board temp sensor.  The best I can do is read back a value of 0x00 for the WHO_AM_I register.  It should be 0xA0.  Since Xilinx's AXI4 IP creator is broken, I have created a custom AXI4 protocol.  I need help understanding what the problem with my design is.  I do not know if it is with my VHDL, or my C.  Everything in my C executes, so it seems like the hardware I built does not have errors in it, it just does not work.  The VHDL is 2019 version: MATRIX7878/AXI4-I2C: A simple I2C for AXI4.  I have confirmed the sensor works by using the Avnet IIC temp sensor AXI4.

Thank you

Parents
  • 0

    This might not be anything to do with the problem you're having, but I'll throw it in anyway for good measure.

    I have no direct experience with the Xilinx design software, but a problem that has come up here before a couple of times is to do with implementing tristates on the IO pins (you're using the tristate capability of the IO pins to emulate the open drain that you need for the I2C clock and data).

    As I understood it, the top level in your 'design block' isn't the device pins, it's one layer down from the pins. It gets extended up to the pin level automatically when the system generates that intermediate layer for itself, on a one-to-one basis, but tristates need to be in a particular form, with signal(s) and enable, related together by naming. (If it wasn't done like that, the synthesis would mess things up by trying to give you the equivalent of an internal tristate bus between the layers and then optimising it out because it doesn't do anything.)

    It's possible that process may have changed in the time since those questions came up - as I say I don't use the design software, so wouldn't know - but it might be worth a quick look at how other people do this when writing for that platform.

Reply
  • 0

    This might not be anything to do with the problem you're having, but I'll throw it in anyway for good measure.

    I have no direct experience with the Xilinx design software, but a problem that has come up here before a couple of times is to do with implementing tristates on the IO pins (you're using the tristate capability of the IO pins to emulate the open drain that you need for the I2C clock and data).

    As I understood it, the top level in your 'design block' isn't the device pins, it's one layer down from the pins. It gets extended up to the pin level automatically when the system generates that intermediate layer for itself, on a one-to-one basis, but tristates need to be in a particular form, with signal(s) and enable, related together by naming. (If it wasn't done like that, the synthesis would mess things up by trying to give you the equivalent of an internal tristate bus between the layers and then optimising it out because it doesn't do anything.)

    It's possible that process may have changed in the time since those questions came up - as I say I don't use the design software, so wouldn't know - but it might be worth a quick look at how other people do this when writing for that platform.

Children