02-15-2018 10:49 PM
I have created an AXI-Master which writes data to the PS DDR4 memory. The only thin I want is to write certain data from the PL to the DRAM and then read it back and compare it. I don't want the PS to modify any of it. Is there any software for the PS necessary besides the FSBL to load the bitstream from QSPI? I would appreciate any help since I'm new to this.
02-16-2018 12:12 AM
02-16-2018 12:51 AM
The smartconnect was inserted automatically if I remember right. I"m not sure if this is needed to translate form the AXI4 Lite master.
02-16-2018 02:08 AM
I see. Let's still assume you would like to to performance tests: Just remember that the PS part is internally using an AXI v3 interconnect and we firmware developer tend to use the AXI v4. Hence whatever you are doing in your test RTL you have to restrict yourself in the firmware to the supported common transfers. Maybe the AXI interconnect you added will do this for you. In addition if you want to do performance tests then consider the axi performance monitors in the PS part... they show the read and write bandwidth, which is very handy for getting a better understanding on the interface and memory access performance in general.
02-16-2018 02:32 AM
Actually I really just want to do basic accesses from the PL. I'm not a firmware developer. I'm an ASIC designer who is now trying to solve a particular problem. I don't want the processor doing something. All the accesses are just done by the PL. What firmware is necessary to have?
02-16-2018 05:35 AM
I guess you have to have the processor part running as well, since the software called FSBL (first stage bool loader) initializes the PS part. Hence if you try to access the SDRAM controller (and other stuff as well) it has to be configured fist, before you are able to use it. However may be there is anther way by some PS default setup which is added to your firmware and which allows you to use this PL ONLY access... but I have no idea how this should work.
Sorry and cheers
02-18-2018 11:32 PM
I have the FSBL running, but still I'm not able to get the expected results. Do I have to specify a .elf file for the "destination_cpu"? Are there any restricted areas in the DRAM?
02-19-2018 01:09 AM
Check the memory content by means of the software debugger.... here is a memory view available in SDK which allows you to see what you were writing to the memory. The other thing you may do is to see if your AXI master does what it was intended to do by adding in firmware an integrated bus analyzer... like I did in my performance tests for the Zynq Ultrascale+:
In the block diagram you see that I am using the "AXI traffic generator" which does most likely what your AXI_test_top does.
And you see the System ILAs which I am able to check the AXI transaction and wee what I'm writing and reading.
Basically my proposal to you is to have 3 debug possibilities:
1. the write by AXI by means of the System ILA
2. the accessibility by means of memory read/write in SDK
3. the read by AXI by means of the System ILA
Then you can localize where your test fails.
02-22-2018 01:24 AM
as far as I can see the AXI protocol is generated correctly by the master, address and data seem to be ok. This is confirmed with the ILA. However when I read the written memory locations with the SDK I don't see the correct data there. Also the date received by the master during read, as far as I can tell from the ILA waveforms don't match the data read at the memory address by the SDK.
I'm not sure what I am missing and would appreciate help.
02-22-2018 04:59 AM - edited 02-23-2018 05:21 AM
02-26-2018 04:51 AM
I did some further debugging and figured out that reading from the PS is ok, expected data can be verified by ILA. Writing to the PS seems to be the problem. I see the correct data written at wrong addresses. I attached some pictures from the ILA. Data read via SDK shows an address offset of 0x5c and address is apparently masked with 0x07F. This would explain the behavior. By the way, I replaced the smartconnect block with an AXI interconnect.
02-26-2018 05:54 AM
Your ILA screenshots look like internal signals from your component... However you could as well post us the signals on the AXI connected on the diagram top (like in my example), then we could see if your component messes up the AXI bus... there is one thing about the AXI implementation from Xilinx: It does not forgive and forget! If you did a mess up with the AXI protocol the AXI may behave strangely. I saw this when a colleague of mine did a AXI master which locked up when an error happened and the AXI did not terminate properly.
You can check that manually using the ILA (and the AXI spec) or in combination with the AXI protocol checker from Xilinx... give them a try. They are good tools for power users.
Cheers and have fun
02-26-2018 06:19 AM
The first of the two pictures show the AXI outputs of my component. The addresses and the response seem to be ok in that case. I will see that I can deliver a picture of the AXI bus output of the interconnect block.
02-27-2018 08:07 AM
I have attached the waveform files form the ILA blocks and the protocol checkers. Apparently there is an violation indicated by the checker. Bit 9 and bit 19 are set in the checker. I find that strange that there are protocol violations since the simulations show no errors.
02-28-2018 03:05 AM
02-28-2018 03:58 AM
Handshake Checks: AWADDR must remain stable when AWVALID is asserted and AWREADY Low.
Handshake Checks: Once AWVALID is asserted, it must remain asserted until AWREADY is High
03-01-2018 04:31 AM