cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tessitd
Explorer
Explorer
2,337 Views
Registered: ‎11-13-2009

PhysOpt Design won't replicate highly loaded synchronous reset?

Jump to solution

Below is a section of an implementation log during the PhysOpt design step.  We have a pre-tcl script which is of the form:

 

phys_opt_design -force_replication_on_nets [get_nets <path>/sreset] I just focusing on this one net right now as this is a synchronous reset which is very heavily loaded and a focus of timing closure for this design.

 

Phase 2 Fanout Optimization
INFO: [Physopt 32-81] Processed net common_top_i/caa_i/odi_pdw_ip/sreset. Replicated 10 times.

Phase 4 Very High Fanout Optimization
INFO: [Physopt 32-239] Net common_top_i/caa_i/odi_pdw_ip/sreset_BUFG is fully routed. phys_opt_design does not optimize fully routed nets. Net common_top_i/caa_i/odi_pdw_ip/sreset_BUFG could not be optimized.
INFO: [Physopt 32-76] Pass 1. Identified 1 candidate net for fanout optimization.
INFO: [Physopt 32-81] Processed net common_top_i/caa_i/odi_pdw_ip/pdw_pulse_detect_1/pdw_input_mux_1/valid_out_i. Replicated 19 times.
INFO: [Physopt 32-232] Optimized 1 net. Created 19 new instances.
INFO: [Physopt 32-775] End 1 Pass. Optimized 1 net or cell. Created 19 new cells, deleted 0 existing cell and moved 0 existing cell
INFO: [Physopt 32-619] Estimated Timing Summary | WNS=-0.449 | TNS=-876.344 |
Netlist sorting complete. Time (s): cpu = 00:00:00.98 ; elapsed = 00:00:00.98 . Memory (MB): peak = 10215.953 ; gain = 0.000 ; free physical = 13656 ; free virtual = 27252
Phase 4 Very High Fanout Optimization | Checksum: 12226e0b2

What I don't understand is the first line after Phase 4, how could this net be fully routed as this stage?  We are in PhyOpt design which is after Placement but before Routing.  Also why does this signal name sreset_BUFG?  Does this have something to do with setting the "fanout" limit in Synthesis and it already buffered this signal?  I do see mention of BUFG during the "place_design" for this net in Phase 4 of the Place_Design.  But again didn't expect it to be routed?

 

Just looking for understanding of how to deal with this behavior.  The way I would like it to work is there is a register as the boundary of this IP (odi_pdw_ip) block.  Within the IP there is ~80K loads for this sreset signal.  I want to the tool to replicate this register as necessary to meet timing. 

 

Is there something I should do in Synthesis to better prepare this net for replication, our current fanout limit is set to 400 loads.

 

Thanks,

TomT...

 

 

0 Kudos
1 Solution

Accepted Solutions
graces
Moderator
Moderator
2,278 Views
Registered: ‎07-16-2008

BUFG optimization occurs in opt_design and place_design, and is on by default.

Please have a look at UG904,

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug904-vivado-implementation.pdf

pg54, section "BUFG Optimization (Default)"

pg69, section "Using the -no_bufg_opt Option"

 

You may want to try set CLOCK_BUFFER_TYPE to NONE for the reset net.

e.g.

set_property CLOCK_BUFFER_TYPE NONE [get_nets <net_name>]

-----------------------------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs.
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

9 Replies
jmcclusk
Mentor
Mentor
2,326 Views
Registered: ‎02-24-2014

Vivado is probably (i.e. very likely) inserting a BUFG driver on your reset net.   Depending on your target device and clock speed, this may or may not be what you want.    But once you have a BUFG driving a high fanout net,  physical replication of the BUFG driver makes no sense, since a clock net has inherently high fanout and low skew characteristics.    As long as the BUFG delay is small enough to meet your setup requirements with your clock net,  leave it alone.   

 

On the other hand, if you get timing failure with your BUFG driven reset net,  you may have to take other actions, like preventing the bufg insertion, and allowing phys_opt_design to replicate the reset drivers.

Don't forget to close a thread when possible by accepting a post as a solution.
tessitd
Explorer
Explorer
2,321 Views
Registered: ‎11-13-2009

So do I need to review the Synthesis results first to see if the BUFG has been inserted?  Would something like "DONT_TOUCH" stop that from occuring but then after I get out of Place_Design, I would have to remove the "DONT_TOUCH" so that PhyOptDesign could replicate?  Is that what you are proposing?

 

TomT....

0 Kudos
jmcclusk
Mentor
Mentor
2,317 Views
Registered: ‎02-24-2014

Load your netlist into Vivado, and then in the TCL console, paste this command:

 

select_objects [get_nets common_top_i/caa_i/odi_pdw_ip/sreset_BUFG ]

 

then hit F4 to show the schematic of your reset net.    IF the driving element is a BUFG, it's pretty obvious what happened.

 

To suppress inference of BUFG's,  go to "Synthesis Settings" and set the -bufg parameter to 0.   This requires, of course, that you instantiate explicitly all your clock buffers in your design.    This is what I do.  

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
tessitd
Explorer
Explorer
2,298 Views
Registered: ‎11-13-2009

Unfortunately this is a very large team design and BUFGs show up elsewhere as necessary.  So I cannot change the synthesis switch to for everyone to instantiate there own BUFGs (yes that is my preference as well but in this role I am an integrator not the project lead).

 

This is one shortfall I see in Xilinx's synthesis approach.  I cannot set options based on Hierarchy, is there a way to disable BUFG instantiation from the HDL within a design?

 

TomT...

0 Kudos
graces
Moderator
Moderator
2,279 Views
Registered: ‎07-16-2008

BUFG optimization occurs in opt_design and place_design, and is on by default.

Please have a look at UG904,

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug904-vivado-implementation.pdf

pg54, section "BUFG Optimization (Default)"

pg69, section "Using the -no_bufg_opt Option"

 

You may want to try set CLOCK_BUFFER_TYPE to NONE for the reset net.

e.g.

set_property CLOCK_BUFFER_TYPE NONE [get_nets <net_name>]

-----------------------------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs.
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

tessitd
Explorer
Explorer
2,263 Views
Registered: ‎11-13-2009

graces,

 

Thanks for that hint, so this should be a pre_tcl script to "opt_design" that sets that attribute on the net.

 

Then in either "opt_design", "place_design" or "phy_opt_design" I can force replication on this net.  At this point the tool will see the loads and replicate as necessary.

 

Let me give that a try and I will make this solution if it works.

TomT...

0 Kudos
g2cacheq
Visitor
Visitor
1,453 Views
Registered: ‎04-22-2019

You can set that attribute in your RTL as well as in XDC.  The syntax is covered in the language templates and in the synthesis user guide.

0 Kudos
g2cacheq
Visitor
Visitor
1,452 Views
Registered: ‎04-22-2019

One other piece of information to answer your previous question.  Once a reset net is assigned to a BUFG, then it is effectively treated as a low skew clock tree.  Clock signals are placed and routed during the plac_design step - so it does make sense that that particular signal is now fully placed AND routed prior to the route_design step.

0 Kudos
tessitd
Explorer
Explorer
1,404 Views
Registered: ‎11-13-2009

Thanks for the input, my question was way beyond that simplictic view of how to do what I wanted.  All of those techniques had been exhasted and still I was not getting the correct results.  This was a very big design with LOTS of clocks and resets and other nets which were consuming the global buffers.  As I had Marked a Solution, I wasn't expecting much additional information.

Thanks for your reply,

TomT...

0 Kudos