Actions
Forum Thread Details
  • State Not Answered
  • Replies 9 replies
  • Subscribers 350 subscribers
  • Views 91 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

  • 0

    Have you simulated your design ?

    If not, then simulate and get the simulation working.

    As a general rule, a design might not work in hardware even if the simulation works, but it will never work in hardware if the simulation fails.

    Once the sim is working, if the hardware doesn't work then add test features or use Viavado probing tools to find out where it goes wrong.

    Test the axi interface and get that working first - then get into the I2C stuff.

    Are you using VHDL or Verillog ?

    MK

  • 0

    I don't know what you mean by "AXI4 IP creator is broken".  I use it all the time in recent Vivado releases. The Xilinx I2C core is not perfect but I am using it right now without problem.  It will be much easier to use that core than invent your own.

  • 0

    Is there any example for AXI I2C ? I want to try that too. 

  • 0 in reply to embeddedguy

    All you have to do is add the AXI I2C to your block design in Vivado (mapped to the I2C interface that you are targeting). Import the design XSA into Vitis and create a new platform based on the XSA. Then navigate in Vitis to the drivers that get created based on your XSA within the BSP. Find the AXI I2C driver and look all the way to the right in the driver window. You will see an option to IMPORT EXAMPLE designs. Pick the example design with best fits your targeted application. Hope this helps.

  • 0 in reply to padudle

    With Vivado 2025.2, the AXI4 creator is bugged.  At least that is what I have been told and what I have seen when I tried it myself.  The thrill of building my own I2C (which I already have for pure FPGA logic) is higher than just using the standard AXI_IIC core for the temp sensor.  Is it working correctly?

  • 0 in reply to michaelkellett

    I normally do simulate, but I do not know how to simulate AXI with the PS.  I looked at the AXI VIP, but do not know SystemVerilog and cannot find a good tutorial for custom IP blocks.  I have tried an ILA before, but it never runs after I program the board in Vitis.  Is there a more thorough guide out there that I haven't found despite searching all over the internet?  I use VHDL as that is what I was trained in and prefer anyways to Verilog.

  • 0 in reply to iksevas

    I am using my I2C protocol so I can take advantage of the PL and PS combo and it is a great way (for me) to learn and see first-hand how the communication works.  I tested the IIC AXI for the onboard temp sensor and it works, but when I use my AXI4 I made, I see my lines are stuck low or just sending noise.  My variable in my C file is 0x00.  As it is I2C, I would expect a line of 0xFF if the bus failed.  I do not think I am communicating from the PL to the PS correctly.

  • 0

    Which version of the Vivado and Vitis are you using? Can you share the syn and impl logs ? 

  • 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.