We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Visitor mbroz
Registered: ‎09-20-2015

The PS hangs when reads from reconfigurable partition (urgent)


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:

  1. I used different static designes, even one provided by ADI for ADV7511. I can state that all these designes are correct because I tested them.
  2. I used different reconfigurable designes, and in the last attempt I used only an AXI4 Full Slave generated by Vivado because my goal is only to read and write into a register.
  3. The boundary between static and reconfigurable partition consists of two AXI Signals (linked to M_AXI_GPx port of the PS, but only one is used in my tests), four clocks (only one is used by the last design) and two reset (active_low and active_high, but only the first is used).

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:

  1. Static design: generate output product (no OOC) and then press "Synthesize" on Vivado. The synth design is placed in /my_project/*.runs/synth/*.dcp
  2. Reconfigurable design: generate OOC, and then synth using the command
    synth_design -mode out_of_context -flatten_hierarchy rebuilt -top pr_design_name -part xc7z020clg484-1
  3. write_checkpoint rec_design.dcp
  4. open_checkpoint [static_design.dcp] (blackbox on pr_instance_name)
  5. read_checkpoint -cell pr_instance_name rec_design.dcp
  6. set_property HD.RECONFIGURABLE 1 [get_cells pr_instance_name]
  7. Assign a pBlock on pr_instance_name, set RESET_AFTER_RECONFIG and SNAPPING_MODE=ON
  8. Run DRC (partial reconfiguration) => No violations
  9. write_checkpoint top_with_reconfigurable_pblock.dcp
  10. opt_design, place_design, route_design => ok
  11. write_bitstream fullBitExample.bit => OK

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?

I should apply some change on the configuration of the static partition before the synthesis?


P.s. I exposed the problem in other posts like POST1 and POST2

0 Kudos
1 Reply
Xilinx Employee
Xilinx Employee
Registered: ‎04-16-2008

Re: The PS hangs when reads from reconfigurable partition (urgent)

Hi mbroz,


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)

  1. read_checkpoint -cell pr_instance_name rec_design.dcp
  2. set_property HD.RECONFIGURABLE 1 [get_cells pr_instance_name]
  3. Assign a pBlock on pr_instance_name, set RESET_AFTER_RECONFIG and SNAPPING_MODE=ON
  4. Run DRC (partial reconfiguration) => No violations
  5. write_checkpoint top_with_reconfigurable_pblock.dcp
  6. opt_design, place_design, route_design => ok
  7. write_bitstream fullBitExample.bit => OK

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.

0 Kudos