12-06-2015 02:38 AM
Are a lot of days in which I'm experiencing a problem related to partial reconfiguration, and I've already written a post in which I expose the problem but no one did give me an hint.
The problem is related to read operations on peripherals into a reconfigurable partition.
Here there is all attempts made:
I placed an ILA IP linked on the M_AXI_GP1 port into static partition in order to see what happens when I perform a read and a write operation.
The first image is a write operation performed using Linux => it works. (but the PS hangs because it try to get data from memory)
The second image is related to a read operation performed under Linux (it works but the PS hangs) (it is performed separately from the first write).
This last image is related to a bare-metal read operation executed after a write operation (the value 0x12345678). As you can see the AXI read and write protocols are correct.
As said the PS hangs just after the read, and I think that it happens when read data are moved into memory.
Here there are all actions performed in order to use the partial reconfiguration flow, maybe I make in some step:
synth_design -mode out_of_context -flatten_hierarchy rebuilt -top pr_design_name -part xc7z020clg484-1
There are some warnings, but they are related to signals which aren't used and they are simply trimmed.
I think that the process is correct because, as stated above, the operations are performed correctly (I also wrote a complete bare-metal application because it didn't perform reads).
In addition I checked for clocks, resets, level_shifters and so on and all looks correct.
I'm using a Zedboard (rev D) with Zynq 7020 and Vivado/Xilinx SDK 2015.2.
There is something wrong in these steps?
12-07-2015 11:17 AM
I think one important item here is to isolate the cause of the issue. I can't think of any tool related issues that would cause something like this, but it may be worth trying to upgrade to 2015.4 if you are on an older version, just to eliminate any chances that this is a software or IP issue that has been fixed in the latest release.
Next, from a PR perspective, I don't see anything wrong with your flow. I also don't see anything here related to the PR flow though. I understand you did a PR flow in software, but it sounds like you are having issues with the full bitstream design (ie no PR in hardware). From a design perspective, PR should not be changing the design in anyway. If the initial, full device download worked, but then things broke after doing a partial reconfiguration, we should focus on PR. However, since it appears the full design is not working, we should probably concentrate on other potential design issues (timing failures, unconstrained timing paths, logical deisgn issues, etc).
What happens if you run the same implementation steps, except remove the PR related commands?
open_checkpoint [static_design.dcp] (blackbox on pr_instance_name)
Also, does every implementation fail in this way in hardware, or only some runs? I think you may want to try a forum post that focuses on the interaction of AXI. I briefly saw your other post. Maybe try one more of these, but don't mention the use of PR, as this may cloud the issue and prevent some people from responding. If you think the problem is specific to the PR flow still, please respond to this thead with more details about how PR is affecting this.
I hope this helps.