01-29-2019 11:59 AM
Using the Xilinx example design as a starting point, I have a design using an AXI traffic generator in System Init mode that sets up the AXI IIC IP core.
What I want to do is a series of master transmit transactions:
START, DATA, DATA, DATA, STOP, START, DATA, DATA, DATA, STOP, START, ........
I have already read both pg125 and pg090 and can't seem to set up the IIC IP block to issue the correct sequence of commands. My coe files used to initialize the traffic generator are pasted.
addrress coe file:
data coe file:
memory_initialization_radix = 16;
01-31-2019 03:33 PM
What exactly are you seeing? Are you able to transmit data for at least one beat? What OS, board/part, and version of Vivado are you using? The more detail you can give will usually be better (as long as it isn't overwhelming or confusing).
Can you link the specific example you are starting from, and if you have changed anything, what your design looks like now?
Finally, can you provide a specific spot you are stuck at, or a specific question?
01-31-2019 04:11 PM
As shown in the .coe files in my original post, I am trying (for this go around) to issue three IIC master transmits. What I would like to see is
START, DATA, DATA, DATA, STOP, START, DATA, DATA, DATA, STOP. Instead what I am seeing is
START, DATA, DATA, DATA, START, DATA, DATA, DATA, STOP.
My OS is Windows 10 and the eval board is VCU108 but these are irrelevant since I'm still only running simulations. The version of
Vivado is 2018.2. For details I have attached the entire project but to simplify life I really think it's an issue of making the .coe file
which I pasted in the original post do the right thing. I might be misinterpreting the info in documents pg125 and pg090. Thanks!
02-01-2019 10:30 AM
When copying your .coe files directly into the example design, I am able to pass the example design's test and simulate properly. I am unsure what you are seeing that makes you think your data is not being sent over IIC.
I may be seeing a false positive, but I don't know what you are doing that is different than in my design. Two notes I have about your design. First, you provided the address and data .coe files, but did not give the atg_ctrl.coe or atg_mask.coe files which may have an impact on your design.
Secondly, in your addresses they all start at a base of 0x40000000 which I do not see in any of the design documents or files (Verilog or VHDL).
To cut down on size of files, and an easier way to send a Vivado design, is by exporting the design as a .tcl file. This can be done by using the command "write_project_tcl -force <file name>.tcl" in the Tcl Console. Make sure to change to the directory you want to export to (Vivado defaults to the top level folder of the project you are working on. Use the "source <file name>.tcl" command and Vivado will import the project back for you or others to work on.
The bullets are actionable items, if you could answer my questions and/or provide with the necessary files that would be much appreciated and would help with getting this issue solved.
02-04-2019 10:49 AM
- Please see attached screenshot. I can also send you whatever other files you think may be useful. If you look where the cursor is, that is the acknowledge bit. I would have expected the master to issue a STOP transaction immediately afterwards but it doesn't happen.
- The master is being configured as a system init block and as such there are no coe files for control and mask.
- The address space does indeed start at 0x40800000. Please see attached screenshot
-I have attched a tcl file for you as well.
02-04-2019 11:06 AM
Also, I don't see documentation which tells me how deep the transmit FIFO is?
02-05-2019 08:00 AM
If this is a simulation, can you also include what testbench you are running for this system? Do you have some Verilog or SystemVerilog to test the design?
02-05-2019 09:08 AM
02-05-2019 03:36 PM
So I looked at your design and it is more complex than the example AXI IIC design. Have you tried sending your three IIC packets in the AXI IIC example design? If you try that and it passes then you know your .coe files are not the problem.
After that, if the .coe files are fine, then I would check where your design is returning the ACK, and how that is being triggered.
You mention that your waveform is stopped where the ACK bit is set, but I do not see that (maybe I am missing something).
Can you try the example design and then respond back if that does/doesn't work? If it doesn't can you key us into where you are triggering the ACK part of the IIC transaction?
02-28-2019 01:35 PM
Please look at the design attached here. It only has the AXI traffic generator and the AXI IIC IP. The design was created using IPI only, no HDL. As youcan see from the simulation waveform,
the AXI IIC IP stops sending out anything after the first set of three bytes. My testbench correctly acknowledges each byte. Can you please use this project zip file to simulate and suggest
any edits to the .coe files?
02-28-2019 03:26 PM - edited 03-01-2019 09:52 AM
Looking at your design and the programming sequence in PG090 AXI IIC Product Guide (https://www.xilinx.com/support/documentation/ip_documentation/axi_iic/v2_0/pg090-axi-iic.pdf), it looks like you are sending the wrong data to some of the registers of the IIC IP core. For instance the Interrupt Enable Register should be set for the Interrupts necessary for a Master Transmit. In addition, the Global Interrupt Enable register does not have its most significant bit set, which means all interrupts would be disabled. Another big issue I see is that you are clearing the MSMS field of the Control Register which means that a STOP condition should be generated, but you only want that to occur at the end of your transmission. I think instead of 0x40800108 that should be 0x4080010D to say both transmit and keep on transmitting data without a stop until right before the last beat, and to enable the AXI IIC control register (the last bit of the control register is an enable bit).
Can you double check the registers you are writing to and the order, and alter as needed? Particularly I would follow the programming sequence on Page 33 of PG090. As well, In the example design they provide .coe examples that have all these bits set properly to tell the AXI IIC to transmit data (for instance, they set the second line of the data .coe to 0x80000000 which is necessary). If you look at those .coe files that would probably be very useful to you. You could even copy those .coe files, and then alter to send the data that you want to send if that might be easier.
Edit: Sorry I misread, but my point about the Control Register still stands. Before your second 0x40800108 there should be a call to 0x40800100 which is the control register and at minimum 0x0...0D should be sent to that address. A Repeated Start condition is how you will send multiple data points in a row. This is a fundamental component of I2C communication as it allows for multiple data beats without waiting to STOP and START again. This guide from TI talks about the repeated start on page 4: http://www.ti.com/lit/an/slva704/slva704.pdf . Please read the Repeated Start section there for a good overview of how IIC Repeated Start works. This is exactly what you are describing above when you say you want to transmit START, DATA, DATA, DATA, STOP, START...etc.
03-06-2019 04:22 PM
Sorry for a little delay in further response. Having looked at your problem a little more I realized a couple other things that might be causing your issue, or are unrelated but still problems all the same.
1. In your COE files I notice that you are writing to the TX FIFO with a value greater than 255 in decimal, or 0xFF, which I don't believe will be sent as IIC can only send 8 bits for each data beat/chunk.
2. Did you create the testbench you are using? Or if you are using someone elses testbench could you say where it came from? In the example AXI IIC design, the testbench is meant to be used in some very specific scenarios. I am wondering if your testbench may not be responding to your IIC transmits correctly which makes it look like the IIC transmit is failing when it is the response that is not working correctly.