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

High Fanout Reset Net, not replicating

Hello,

 

I have a design with a high fanout of the reset net wire. I applied a few techniques combined, and however, suddenly my synthesis is not replicating the reset net signal

I added in my design:

set_property CLOCK_BUFFER_TYPE NONE [get_nets {reset}]
set_property MAX_FANOUT 20 [get_nets {reset}]

my reset net has a pipe

with an async_flop, that feeds 3 stages, flip-flops on the third the output connects to the signal, and the goal was to allow the system to replicate the reset signal accordingly:

my reset controller outputs the reset

this way

  async_reset_sync  async_flop (
         .async_reset    (async_reset)
        ,.clk            (clk)
        ,.sync_reset     (to_sync_reset)
    );

    rff reg_pipe1(.clk(clk), .reset(async_reset), .en(1'b1), .d(to_sync_reset), .q(adc_pipe1));
    rff reg_pipe2(.clk(clk), .reset(async_reset), .en(1'b1), .d(adc_pipe1), .q(adc_pipe2));
    rff reg_pipe3(.clk(clk), .reset(async_reset), .en(1'b1), .d(adc_pipe2), .q(reset));

so in my top, I have

reset_controller(
.clk(),
...
.reset(reset)

 and my reset net on top is declared this way

(* direct_reset = "yes" *) wire reset;

Now, why is the system not replicating the flops for the reset signal? It was working before, and all of a sudden, it doesn't do that anymore.

 

Any suggestions? Or solutions?

Regards

 

0 Kudos
11 Replies
Highlighted
Xilinx Employee
Xilinx Employee
552 Views
Registered: ‎01-30-2019

Hi @muscularbeaverwhoosh ,

Can you open your synthesized design and check if the property MAX_FANOUT is applied to the net or not?

If yes then you need not worry, since further downstream in the flow, the PSIP ( Physical Synthesis in Placer) will use this property and replicate the drivers of this net to match the fanout of driver with the value mentioned in the property.

If not then we need to check why is it not getting applied and the reason for this might be this 

see note in the attached image

why are you using clock_buffer_type on the net reset?

max_fanout.PNG
0 Kudos
Highlighted
525 Views
Registered: ‎01-06-2020

Hi @surajc , thanks for looking into this

I specifically set the clock_buffer_type to NONE to avoid it using BUFGs instead of replicating the signal, because I saw it passing the reset net before through BUFGs.

and no it is no applying the constraint, no idea why, literally it have the following info:

INFO: [Synth 8-5777] Ignored max_fanout on net reset because some of its loads are not in same hierarchy as its driver   

as you can see I did:

set_property CLOCK_BUFFER_TYPE NONE [get_nets {reset}]

I'll remove it and try again in the meantime 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
506 Views
Registered: ‎05-14-2008

Did the max_fanout work well with clock_buffer_type before in your design?

BUFG insertion on non-clock net happens in opt_design for fanout above 25000.

You don't need clock_buffer_type if the fanout of the reset is lower than 25000 or you're expecting it to be lower than 25000 by using max_fanout.

Another thing to check is the flatten_hierarchy option of Synthesis. Do not set it to "None". Fanout optimization driven by max_fanout in Synthesis does not occur for "solid" hierarchy boundary (IP top level hierarchy, hierarchies with keep_hierarchy, dont_touch, mark_debug constraints). Please refer to below ARs for more infomation.

https://www.xilinx.com/support/answers/62162.html

https://www.xilinx.com/support/answers/65212.html

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
495 Views
Registered: ‎01-06-2020

Hi @viviany,

 

No, it is the first time I tried, I removed it, after the previous answer from @surajc, re-run, and still keep seeing:

INFO: [Synth 8-5777] Ignored max_fanout on net reset because some of its loads are not in same hierarchy as its driver   

My fanout is above 5k, this is just one I have 4 reset domains, two of them are above 5K.

 

Before this was working, suddenly it stopped, no idea why. I even used with hierarchical design, when all my modules on the top had (* keep_hierarchy = true *) when I was testing to identify time issues related to each module, however, this is not the production target.

As I mentioned I remove the NONE constraints for the buffer, let me test the other items you mentioned, my flatten_hierarchy is set to rebuilt. Regarding the don_touches and keep_hierarchy, I don't have any of those on my design on the reset net.

0 Kudos
Highlighted
483 Views
Registered: ‎01-06-2020

@viviany 

 

Also, I tried the force replication, however, when I add on 'More Options' in my phys_opt_design step it conflicts with '-directive', and when I try on the TCL shell after it generated the imply, I get the following error:

ERROR: [Vivado_Tcl 4-265] Option -force_replication_on_nets is specified but not supported yet for post-route physical synthesis. Please remove the option and rerun phys_opt_design
0 Kudos
Highlighted
482 Views
Registered: ‎01-06-2020

By the way

 

@viviany and @surajc I even tried with 

first

  (* max_fanout = 100 *)wire  reset;

failed then:

(* max_fanout = 100 *)(* direct_reset = "yes" *) logic reset;

also failed

and even with max_fanout on the RTL it is not working

0 Kudos
Highlighted
464 Views
Registered: ‎01-06-2020

I did tried with -directive default and add in more option the 

-force_replication_on_nets [get_nets {reset}]

still it didn't worked

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
300 Views
Registered: ‎01-30-2019

HI @muscularbeaverwhoosh ,

This kind of physical optimisations i.e. force_replication_on_nets is valid for a post place design only.

Can you try to Create a TCL file, put these commands in it and attach this as a post place hook script and see if this helps.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
290 Views
Registered: ‎05-14-2008

-force_replication_on_nets is not the best choice.

If max_fanout does not work in Synthesis, phys_opt_design would replicate the reset driver register in order to meet your timing requirement. You can set fanout optimization directive for phys_opt_design and see how it goes.

Regarding the max_fanout in Synthesis, does the reset signal driven any logics inside Xilinx IPs? Xilinx IPs are added dont_touch constraint automatically in Synthesis. So any loads inside the IPs would not be considered in fanout optimization in Synthesis. This is also mentioned in the ARs I pointed out.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
Highlighted
268 Views
Registered: ‎01-06-2020

Thanks @surajc  and @viviany,

 

the XDC and RTL flags end-up working, the key trick was in the XDC I was overconstrained,  I did have a constraints:

set_false_path -from [get_cells {reset_control/reset}]

Since I declared the reset net a false path, there was no need to replicate, since it was a false path so any time for the signal to travel on it is OK, so that was preventing the replication to happen, once I removed the flag it worked., the keyword for me to guess that constraint was the issue was this vague message:

INFO: [Synth 8-5777] Ignored max_fanout on net reset because some of its loads are not in same hierarchy as its driver   

the hierarchy part, because I remember getting this working in a hierarchical flow, that was failing now in a flat run. So my guess was the constraint was creating an architectural path, we're it doesn't exist.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
247 Views
Registered: ‎05-14-2008

set_false_path constraint prevents many optimizaton on objects.

But the message seems misleading.

I'll run some tests and let you know.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos