cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
corrado
Visitor
Visitor
398 Views
Registered: ‎03-01-2019

Partial Reconfiguration using HLS IP and Clock Net Rule Violation

Jump to solution

Hello,

I am moving my first steps in Partial Reconfiguration. 

I implemented two very simple IP using Vivado HLS. (they write and read from a BRAM and are controlled by AXI Lite interfaces)

I want to build a reconfigurable design able to switch between the two IPs. The reconfiguration should be triggered by the processor system (I am using a Zynq), but I have issues in generating the partial bitstreams because I cannot complete the implementation due to the error:

ERROR: [DRC HDPR-41] Clock Net Rule Violation: Reconfigurable cell 'PR_platform_i/march_0' has a route-through (direct connection between input port and output port inside reconfigurable cell) driven by clock net 'PR_platform_i/pr_decoupler_0/U0/s_intf_0_CLK_BUFG'. This connection is not supported by partial reconfiguration flow. Resolution: Remove the clock net route-through by modifying the module interface.

But it is not very clear to me what it means with a route-through (direct connection between input port and output port inside reconfigurable cell).

As a first step, I synthesized both the configurations as "out_of_context".

Then,  I started from the full design (including IP1), removing the reconfigurable module using update_design -black_box command to generate the static design.
Then I did floor planning, and set RESET_AFTER_RECONFIG 1 and SNAPPING_MODE ON.
Then, I combined the static with the first reconfigurable module (IP1) and I set HD.RECONFIGURABLE TRUE .
So, I performed place and route of the first design with config1.
Then I removed the RM using update_design -black-box and I locked the routing of the static design using lock_design -level routing.
I continued attaching the second config (IP2) to the static design using : read_checkpoint.
When we tried to do the place and route of the this design, I receive the error.

If I try to reuse the IP1 for the second configuration, I observe the same behavior.

I had the error also before inserting the decoupler (but an IP clock signal). I tried to move my pblock around and to insert the decoupler but it is still here.

I already tried several solution as the "update_design -cells [get_cells <my cell>] -buffer_ports" but it doesn't change anything. (probably because it is not very clear what is the issue).

I used block design. 

 

 

Thanks

 

Tags (1)
0 Kudos
Reply
1 Solution

Accepted Solutions
corrado
Visitor
Visitor
316 Views
Registered: ‎03-01-2019

Hi @marcb,

thankyou for your suggestions. I did that but I could not find the net going directly through the RM.

Anyway, I was using Vivado 2019. Yesterday, I tried on Vivado 2020 and it worked without any problem. So, it could be a problem related to the tool version. 

 

View solution in original post

0 Kudos
Reply
2 Replies
marcb
Moderator
Moderator
346 Views
Registered: ‎05-08-2012

Hi @corrado 

To see what is causing the error, I would suggest the following:

  1. Open the netlist either right before or just after the failure.
  2. Open a schematic of the cell mentioned in the message. "select_objects [get_cells PR_platform_i/pr_decoupler_0/U0/s_intf_0_CLK_BUFG]" and select F4 to open the schematic.
  3. Follow the output of the BUFG into the Reconfigurable Module (RM)  'PR_platform_i/march_0'. 

According to the message, it should go directly through the Reconfigurable Module. To avoid this, prevent the global clock from exiting the RM (it already drives the static region).

 

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
0 Kudos
Reply
corrado
Visitor
Visitor
317 Views
Registered: ‎03-01-2019

Hi @marcb,

thankyou for your suggestions. I did that but I could not find the net going directly through the RM.

Anyway, I was using Vivado 2019. Yesterday, I tried on Vivado 2020 and it worked without any problem. So, it could be a problem related to the tool version. 

 

View solution in original post

0 Kudos
Reply