cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
270 Views
Registered: ‎01-08-2020

Does PR/DFX with Incremental Implementation work?

I've tried around a dozen different variations in my build scripts trying to get incremental implementation to actually work when also using partial reconfiguration. Each time I end up with either an error during routing:

CRITICAL WARNING: [Route 35-341] Fixed routing constraint on net <blah> conflicts with pin GNDTerm of net GNDNet. The said pin is unroutable.
Conflicted HDRTNode (321 108 41) nc = 2

or failure during pr_verify:

ERROR: [Constraints 18-893] HDPRVerify-10: the net GND (or <const0>) uses routing node CLEL_L_X47Y105/CLE_CLE_L_SITE_0_E_O in design check point static_route_design.dcp, yet this routing node is not used by the same net in design check point rp1_route_design.dcp. The routing nodes used to route net GND (or <const0>) must be the same in both design check points
ERROR: [Constraints 18-894] HDPRVerify-11: the net GND (or <const0>) uses the static arc INT.INT_NODE_IMUX_56_INT_OUT1->>IMUX_W38 at tile INT_X31Y235 in design check point static_route_design.dcp, yet this arc is not used for the same net routing in design check point rp1_route_design.dcp. Both design check points must use exactly the same static arcs for routing net GND (or <const0>)

 

I'm guessing what's happening here is the first RP I built with did not use net <blah>, so it got optimized to GND. But then my second RP DOES use that net and is unable to due to the optimization that occurred in my first run. However, setting the HD.RECONFIGURABLE property on the PR region is supposed to prevent this kind of optimization from occurring. Is it possible there is a priority conflict in Vivado between honoring incremental (optimize across boundaries) or honoring reconfigurable? I'm using 2018.3 FWIW.

If this flow DOES work, can anyone share an example script with both features included that they've had success with?

Tags (4)
0 Kudos
3 Replies
Highlighted
Moderator
Moderator
208 Views
Registered: ‎11-04-2010

For DFX/PR design, the boundary should be locked for the different configurations, so HD.RECONFIGURABLE property on the PR region will prevent any optimization across the boundary.

It looks to be a tool's issue if your flow is correct.

If you still see the situation that normal DFX flow can complete without error, while only introducing incremental flow will causes the pr_verify error or routing conflicting in 2020.1, please provide the related dcp files and script for us to reproduce the issue and debug it further.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
135 Views
Registered: ‎01-08-2020

Weird, I distinctly remember replying to this thread, but my reply is not here...

Is it possible to get an example script that should work?

Unfortunately I cannot provide my dcp, but I can provide an outline of my script. Please take a look and let me know if you see anything out of place.

# Starting from a project that has been run through synth_design, with 2 PR regions empty (black boxed)
open_project $PROJ_FILE
open_run synth_1 -name synth_1
# Fill in the black boxes with the first RM using an EDIF netlist as the source. Could also use dcp source with "read_checkpoint -cell x y.dcp" instead.
update_design -cell $pr0_cell -strict -from_file $rm0_netlist
update_design -cell $pr1_cell -strict -from_file $rm0_netlist
set_property HD.RECONFIGURABLE 1 [get_cells $pr0_cell]
set_property HD.RECONFIGURABLE 1 [get_cells $pr1_cell]
# Create the pblocks, define physical constraints for them, and add $pr0/1_cell to them 
read_xdc pr_regions.xdc
# Start the actual implementation phase
opt_design
# Enable incremental implementation using a checkpoint from the previous time this script was run
read_checkpoint -incremental reference.dcp
place_design
phys_opt_design
route_design
phys_opt_design
write_checkpoint -force rm0_post_route.dcp
# Update the incremental checkpoint if slack > 0
if {[get_property SLACK [get_timing_paths -delay_type min_max]] >= 0} {
  file copy -force rm0_post_route.dcp reference.dcp
}
write_bitstream -force rm0
# Now blackbox the PR regions and lock the static region to prepare for subsequent RM implementations
update_design -cell $pr0_cell -black_box
update_design -cell $pr1_cell -black_box
lock_design -level routing
write_checkpoint -force static.dcp

Then after the static region is done, any other RM implementations are done similarly:

# Starting from the static region checkpoint that was just created
open_checkpoint static.dcp
# Fill in the black boxes with the additional RM using an EDIF netlist as the source. Could also use dcp source with "read_checkpoint -cell x y.dcp" instead.
update_design -cell $pr0_cell -strict -from_file $rm1_netlist
update_design -cell $pr1_cell -strict -from_file $rm1_netlist
# Start the actual implementation phase
opt_design
place_design
phys_opt_design
route_design
phys_opt_design
write_checkpoint -force rm1_post_route.dcp
write_bitstream -force rm1
# Now verify that rm1 is compatible with the static region
pr_verify -full_check static.dcp rm1_post_route.dcp

 

The above script works if I comment out the read_checkpoint -incremental, but fails if I have incremental implementation enabled.

0 Kudos
Highlighted
Moderator
Moderator
130 Views
Registered: ‎11-04-2010

The flow looks correct for me and I think it's issue for incremental flow in DFX. 

Is possible please try the flow in 2020.1 and check whether the issue still occurs.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos