06-11-2020 05:50 PM - edited 06-13-2020 09:53 AM
Clock contention errors are blocking my ability to implement a partial reconfig design in Vivado. I’m posting here in the hopes someone can offer help better understanding these errors and ways to resolve them.
I am working with a design on an Ultrascale+ xcvu9p device using partial reconfiguration in Vivado 2019.2. Due to a limitation in Vivado which doesn't allow us to reuse IP sources across multiple reconfigurable modules we are using a non-project flow with static and each RM synthesized separately and linked together for implementation using design checkpoints.
In recent build attempts I have encountered errors on clock dedicated nets in the static region. The first set of errors occurred after place_design for the first configuration run. These errors claimed that two clocks had LOC constraints which placed them on the same routing track.
ERROR: [Place 30-838] The following clock nets need to use the same clock routing resource, as their clock buffer sources are locked to sites that use the same routing track.
One or more loads of these clocks are locked to clock region(s) X4Y7 X4Y8 which causes the clock partitions for these clocks to overlap. This creates unresolvable contention on the clock routing resources.
If the clock buffers need to be locked, we recommend users constrain them to a clock region and not to specific BUFGCE/BUFG_GT sites so they can use different routing resources.
If clock sources should be locked to specific BUFGCE/BUFG_GT sites that share the same routing resources, make sure loads of such clocks are not constrained to the same region(s). Clock nets sharing routing resources: i_reconfig_top/i_mmcm_tx/inst/CLK_TX_112 i_ext_ram_if_top/i_ddr3_core/inst/u_ddr3_infrastructure/c0_riu_clk ERROR: [Place 30-678] Failed to do clock region partitioning: failed to resolve clock partition contention for locked clock sources. Resolution: Try removing the area constraints set on the clocks (source and/or loads) that compete for resources in the same clock region(s).
In case an area constraint on the clock loads is necessary, please either extend the area constraint to cover the clock source, or make sure that the clock source is constrained/placed in a clock region in the same row or column as one of the regions in the specified area constraint.
Also try reducing the amount of clock resources in your design, by either combining some clock nets or by changing the placement of clock primitives to reduce the distance between the source and loads of each clock net involved in the area with higher clock routing utilization.
Generating a clock utilization report confirmed that both of the conflicting clocks were assigned to BUFGCE sites connected to the same routing track (track 14). As the error suggested I searched for LOC constraints on the associated clocks in our design’s main physical constraints file and in the XDC files associated with those IP, but I didn’t find any such constraints explicitly on those clock signals. I attempted to resolve this issue by adding a LOC constraint on one of the conflicting clocks to connect it to a BUFGCE site on another clock track which wasn’t occupied by any other clock net. This LOC constraint resolved the collision for the first pair of clock signals but caused another pair of clock signals to conflict on a different same track. Imposing another LOC constraint caused a third pair of clocks to conflict, but a third LOC constraint succeeded in completing place_design and route_design without any errors. However, after route_design finished a critical warning appeared from the dbg_hub module associated with ILA's in the design which reported that an internal clock within this block was partially routed with a list of a few dozen sites which were unreachable to the clock source.
These repeated issues with clock signals in the static region seem to me to indicate a problem with clock resource utilization. Our specific use case for PR requires that the Pblock for the reconfigurable partition contains nearly 90% of the device's resources. Despite this, analyzing the clock resource utilization for the clock regions which have been associated with all of these errors, X4Y7 and X4Y8, the clock routing resources don’t appear to have a high utilization.
| | HROUTES | HDISTRS | VROUTES | VDISTRS | +-------------------+------+-------+-------+------+-------+-------+------+-------+-------+------+-------+-------+ | Clock Region Name | Used | Avail | Util% | Used | Avail | Util% | Used | Avail | Util% | Used | Avail | Util% | +-------------------+------+-------+-------+------+-------+-------+------+-------+-------+------+-------+-------+ | X4Y7 | 0 | 24 | 0.00 | 9 | 24 | 37.50 | 5 | 24 | 20.83 | 6 | 24 | 25.00 | | X4Y8 | 4 | 24 | 16.67 | 9 | 24 | 37.50 | 2 | 24 | 8.33 | 1 | 24 | 4.17 |
Are there any other methods for gaining more insight into what is going on here?
06-15-2020 02:58 PM
Hi @spencer.williams Is the clock in question a boundary clock between the static and reconfigurable region? Also, does this have loads in the destination region. There has been a report of a similar issue that is currently under investigation. The workaround in that case was to add "dummy" loads to the boundary clock to avoid the error.
06-16-2020 09:47 AM
For the clock conflict errors I received during place_design each of the conflicting pairs involved one clock sourced from the RP crossing into the static and one clock entirely contained in the static region. Each of the conflicting clocks that have crossed the boundary do have loads in the static region.
06-25-2020 03:23 PM
If adding loads to the boundary clocks with no loads on a connected boundary doesn't help, can the post-opt_design DCP be uploaded? I can also send a personal message for a file exchange if that helps.
07-09-2020 02:51 PM
I have to take care with sending a DCP as this is under an export controlled contract. I have been advised by the FAE who works with our company to create a service request for this issue with the ITAR box checked so that is what I'll do.