09-02-2019 04:12 AM
Hi,
I am working on AXI peripheral which has 4 registers (32 bit each) and the memory block occupies 4KB. The base address is 0x43C00000 and i am using Vivado 2017.4. After exporting my hardware successfully, when i try to write to AXI peripheral's register (0x43C00000) it gets written successfully. However, along with this all other registers in the address space at offsets of 16 bytes get written to as well. I have tried doing this using AXI Interconnect and AXI Smartconnect but the result is same.
Why the other registers get written as well? Is this the expected result? Please find the attached image & code for information.
Any help regarding the issue will be appreciated.
#include <stdio.h> #include "platform.h" #include "xil_printf.h" #include "xparameters.h" #include "xil_io.h" int main() { init_platform(); print("Hello World\n\r"); int* axi_addr = 0x43C00000; int data = 198; xil_printf("AXI address = %d\n\r", axi_addr); Xil_Out32(axi_addr, data); // trying to write to a single register at address 0x43C00000 int save = Xil_In32(axi_addr); xil_printf("Data Read = %d\n\r", save); print("End of main\n\r"); cleanup_platform(); return 0; }
09-02-2019 05:01 AM
Is this an issue?
One common approach to address decoding is known as "partial address decoding". With partial address decoding, you don't check all of the bits of an address when determining which peripheral is at that address--you only check the minimum number. My guess is that the interconnect is checking fewer than the top 12 bits--it's certainly how I'd build the interconnect if I were doing so. The result is that your core lives at multiple addresses within the interconnect. Assuming your core is 16 32-bit registers in size, then adding 64 to your cores address should also access your core.
Why is this a good thing? Because it spares you the LUTs necessary to do full address decoding so that you can use them for other purposes within your design.
It's not usually an issue though, rather just a fun fact about how the whole thing is put together. If you restrict yourself to reading and writing only the defined peripheral address values you shouldn't notice a problem.
Dan
09-02-2019 04:40 AM
Is the AXI Peripheral a custom IP or module?
Is the working of this peripheral verified for proper working using RTL simulation?
I suspect some problem with the address decoding.
------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem
09-02-2019 04:46 AM
- I am using a custom IP in my project
- RTL simulation has not been done
How can i solve this address decoding issue?
09-02-2019 05:00 AM - edited 09-02-2019 05:02 AM
Before verifying in hardware, you should make sure your AXI IP is working properly using functional verification through RTL simulation.
So you can either use a Bus Functional Model and use it for verifying your AXI IP. Else if you have a pre-verified AXI master than you can also connect your slave to it and follow the bus transactions.
Check how you are handling the address decoding at the slave side.
------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem
09-02-2019 05:01 AM
Is this an issue?
One common approach to address decoding is known as "partial address decoding". With partial address decoding, you don't check all of the bits of an address when determining which peripheral is at that address--you only check the minimum number. My guess is that the interconnect is checking fewer than the top 12 bits--it's certainly how I'd build the interconnect if I were doing so. The result is that your core lives at multiple addresses within the interconnect. Assuming your core is 16 32-bit registers in size, then adding 64 to your cores address should also access your core.
Why is this a good thing? Because it spares you the LUTs necessary to do full address decoding so that you can use them for other purposes within your design.
It's not usually an issue though, rather just a fun fact about how the whole thing is put together. If you restrict yourself to reading and writing only the defined peripheral address values you shouldn't notice a problem.
Dan
09-02-2019 05:33 AM
Thank you for your response.
It is not a problem actually as i could read and write to my 4 registers successfully. However, i was keen to know the reason behind this behaviour and hence this post. I think you have answered my query quite well. Moreover, is there anyway to know how many bits are being considered in this partial address decoding?
10-01-2020 10:22 AM
Hi!
I have a design implementation similar to yours.
PCIE(endpoint) -- AXI Peripheral Register.
There are about 100 of such registers so I created a AXI4 peripheral with Interface Type - Lite, data width 32 and number of registers 100.
What is not clear to me is how to access these registers internal to FPGA logic.
Unlike AXI_GPIO which makes and external port. the AXI4 peripheral does not create external port.
Can you please elaborate on how I can access these 100 registers internal to FPGA fabric. The bits on these registers are used to run internal logic (state machine) and the internal logic will write to these registers so the Host Computer can read back these registers.
I guess my question is I understand the link from host computer to AXI4 pheripheral (100 registers) via the PCIe. However, I am not clear on how to read/write to these 100 registers from the FPGA (user logic)
10-05-2020 07:20 AM
This should better be posted as a new item, but here goes...
You should open up the generated sources and modify them as per your requirement.