UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
2,201 Views
Registered: ‎03-18-2008

does the rst from the different modules need to be merged?

There is a global rst_n signal from pad. There include 6 moduels inside the project. Each module has itself reset ciruit logic.They are  not added bufg from the following high fanout statistics(rst)

 

 

1> do i need to add bufg after each rst for each instance?

 

2>do i need to merge/modify/simplify all modules rst to the global rst_n signal from pad?

 

which is prefer?

rst.png
0 Kudos
13 Replies
Voyager
Voyager
2,193 Views
Registered: ‎06-24-2013

Re: does the rst from the different modules need to be merged?

Hey @m006,

 

Each module has itself reset ciruit logic.

If the circuitry is similar or even identical and the clock is the same, then it would be a good idea to move the reset circuitry out of the modules and into a global reset module, which then can drive the various reset pins via a single clock network.

 

do i need to add bufg after each rst for each instance?

In case the reset signals are separate (i.e. separate clock domain or timing) you need to add one clock network per reset instance to distribute the reset signal to all cells in the module.

 

do i need to merge/modify/simplify all modules rst to the global rst_n signal from pad?

As long as you have enough clock network resources left you do not need to do that, but in case you can do that it would definitely improve the design in several aspects (including having one reset for the entire design).

 

Hope this clarifies,

Herbert

-------------- Yes, I do this for fun!
Moderator
Moderator
2,172 Views
Registered: ‎01-16-2013

Re: does the rst from the different modules need to be merged?

@m006,

 

Adding some additional information: 

Please check out Resets topic at page number 39 in below User guide. This has the clear explanation on using resets along with some good examples:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_2/ug949-vivado-design-methodology.pdf

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
Xilinx Employee
Xilinx Employee
2,154 Views
Registered: ‎08-01-2008

Re: does the rst from the different modules need to be merged?

you may refer this link as well for reset usage in FPGA

http://www.eetimes.com/document.asp?doc_id=1278998
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Moderator
Moderator
2,138 Views
Registered: ‎11-09-2015

Re: does the rst from the different modules need to be merged?

Hi @m006,

 

As per the Ultrafast methodology guide for vivado (UG949):

"Xilinx highly recommends that you take special care in deciding when the design requires a reset, and when it does not."

 

It is better to avoid resets in your design. Most of the time they are not needed because you can specify the value of a register when programming the FPGA:

"Xilinx devices have a dedicated global set/reset signal (GSR). This signal sets the initial value of all sequential cells in hardware at the end of device configuration."

 

Regards,

 

Florent


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
Explorer
Explorer
2,101 Views
Registered: ‎03-18-2008

Re: does the rst from the different modules need to be merged?

how to use the global set/reset signal (GSR) ?
0 Kudos
Moderator
Moderator
2,093 Views
Registered: ‎11-09-2015

Re: does the rst from the different modules need to be merged?

Hi @m006,

 

It is used automatically when you set a default value for your signals, reg...

 

Regards,

 

Florent


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Moderator
Moderator
2,091 Views
Registered: ‎01-16-2013

Re: does the rst from the different modules need to be merged?

@m006,

 

Xilinx devices have a dedicated global set/reset signal (GSR). This signal sets the initial value of all sequential cells in hardware at the end of device configuration. If an initial state is not specified, sequential primitives are assigned a default value. In most cases, the default value is zero. Exceptions are the FDSE and FDPE primitives that default to a logic one. Every register will be at a known state at the end of configuration. Therefore, it is not necessary to code a global reset for the sole purpose of initializing a device on power up.

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
Explorer
Explorer
2,080 Views
Registered: ‎03-18-2008

Re: does the rst from the different modules need to be merged?

 

why not to insert BUFG after module1/2 reset_n with high fanout(12245/12299)  automaticaly?

0 Kudos
Moderator
Moderator
2,076 Views
Registered: ‎11-09-2015

Re: does the rst from the different modules need to be merged?

Hi @m006,

 

why not to insert BUFG after module1/2 reset_n with high fanout(12245/12299)  automaticaly?

> Because you would "waste" resources. Reset are usually not needed.

Bufg might be save for clocking resources


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Explorer
Explorer
1,241 Views
Registered: ‎03-18-2008

Re: does the rst from the different modules need to be merged?

do i need add a BUFG for a common enable/control signal with high fanout(10000+)  manualy?

0 Kudos
Moderator
Moderator
1,239 Views
Registered: ‎11-09-2015

Re: does the rst from the different modules need to be merged?

Hi @m006,

 

This optimization is automatically performed in opt_design for nets with a fanout greater than 25000 only when a limited number of clock buffers are already used.

 

You might want to add the attribute MAX_FANOUT to forces the synthesis to replicate logic in order to meet a fanout limit.

 

Regards,

 

Florent


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Explorer
Explorer
1,219 Views
Registered: ‎03-18-2008

Re: does the rst from the different modules need to be merged?

1>IBUFGCTRL is BUFG? it can replace BUFG? it seems that vivado only adds a IBUFGCTRL on rst_n_ibuf/O,no BUFG.

 

2>what i felt wondering is vivado added a BUFG on a low fanout net(module 4) automatic ,not those hight fanout net(module1/2/3)

 

3>can it improve the following timing if i add a bufg on the net "snoop_ctrl/tfhg/encoder[0].u_yhuj/iol_nclk(fanout = 7820)" ?

---------------------------------------------------------------------------------------------------
From Clock:  clk_out2_clk_wiz_0_1
  To Clock:  clk_out2_clk_wiz_0_1

Setup :         1090  Failing Endpoints,  Worst Slack       -2.144ns,  Total Violation     -813.239ns
Hold  :           15  Failing Endpoints,  Worst Slack       -0.015ns,  Total Violation       -0.105ns
PW    :            0  Failing Endpoints,  Worst Slack        6.124ns,  Total Violation        0.000ns
---------------------------------------------------------------------------------------------------
Slack (VIOLATED) :        -2.144ns  (required time - arrival time)
  Source:                 snoop_ctrl/tfhg/iol_en_q/C
                            (rising edge-triggered cell FDCE clocked by clk_out2_clk_wiz_0_1  {rise@0.000ns fall@6.666ns period=13.332ns})
  Destination:            snoop_ctrl/tfhg/encoder[0].u_yhuj/current[300].valid_current.njkml_current.njkml_current_q_ret_13/S
                            (rising edge-triggered cell FDSE clocked by clk_out2_clk_wiz_0_1  {rise@0.000ns fall@6.666ns period=13.332ns})
  Path Group:             clk_out2_clk_wiz_0_1
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            13.332ns  (clk_out2_clk_wiz_0_1 rise@13.332ns - clk_out2_clk_wiz_0_1 rise@0.000ns)
  Data Path Delay:        14.996ns  (logic 0.170ns (1.134%)  route 14.826ns (98.866%))
  Logic Levels:           1  (LUT2=1)
  Clock Path Skew:        -0.350ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    1.495ns = ( 14.827 - 13.332 )
    Source Clock Delay      (SCD):    2.468ns
    Clock Pessimism Removal (CPR):    0.623ns
  Clock Uncertainty:      0.064ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Discrete Jitter          (DJ):    0.107ns
    Phase Error              (PE):    0.000ns
  Clock Net Delay (Source):      3.145ns (routing 0.649ns, distribution 2.496ns)
  Clock Net Delay (Destination): 2.657ns (routing 0.600ns, distribution 2.057ns)

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock clk_out2_clk_wiz_0_1 rise edge)
                                                      0.000     0.000 r 
    G31                                               0.000     0.000 r  sysclk1_300_p (IN)
                         net (fo=0)                   0.000     0.000    sys_crg/instance_name/inst/clkin1_ibufds/I
    HPIOBDIFFINBUF_X0Y204
                         DIFFINBUF (Prop_DIFFINBUF_HPIOBDIFFINBUF_DIFF_IN_P_O)
                                                      0.500     0.500 r  sys_crg/instance_name/inst/clkin1_ibufds/DIFFINBUF_INST/O
                         net (fo=1, routed)           0.000     0.500    sys_crg/instance_name/inst/clkin1_ibufds/OUT
    G31                  IBUFCTRL (Prop_IBUFCTRL_HPIOB_M_I_O)
                                                      0.000     0.500 r  sys_crg/instance_name/inst/clkin1_ibufds/IBUFCTRL_INST/O
                         net (fo=1, routed)           0.606     1.106    sys_crg/instance_name/inst/clk_in1_clk_wiz_0
    MMCM_X0Y8            MMCME4_ADV (Prop_MMCM_CLKIN1_CLKOUT1)
                                                     -2.034    -0.928 r  sys_crg/instance_name/inst/mmcme3_adv_inst/CLKOUT1
                         net (fo=1, routed)           0.227    -0.701    sys_crg/CLKIN53_c
    BUFGCE_X0Y194        BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.024    -0.677 r  sys_crg/cpu_clk_1_keep_cb/O
    X2Y7 (CLOCK_ROOT)    net (fo=343628, routed)      3.145     2.468    snoop_ctrl/tfhg/clk
    SLR Crossing[1->2]  
    SLICE_X129Y798       FDCE                                         r  snoop_ctrl/tfhg/iol_en_q/C
  -------------------------------------------------------------------    -------------------
    SLICE_X129Y798       FDCE (Prop_AFF_SLICEM_C_Q)
                                                      0.077     2.545 r  snoop_ctrl/tfhg/iol_en_q/Q
                         net (fo=7820, routed)       13.486    16.031    snoop_ctrl/tfhg/encoder[0].u_yhuj/iol_nclk
    SLICE_X106Y847       LUT2 (Prop_B6LUT_SLICEL_I0_O)
                                                      0.093    16.124 r  snoop_ctrl/tfhg/encoder[0].u_yhuj/current_yhuj_match_RNIR0KA/O
                         net (fo=210, routed)         1.340    17.464    snoop_ctrl/tfhg/encoder[0].u_yhuj/current_yhuj_match_RNIR0KA
    SLICE_X95Y876        FDSE                                         r  snoop_ctrl/tfhg/encoder[0].u_yhuj/current[300].valid_current.njkml_current.njkml_current_q_ret_13/S
  -------------------------------------------------------------------    -------------------

                         (clock clk_out2_clk_wiz_0_1 rise edge)
                                                     13.332    13.332 r 
    G31                                               0.000    13.332 r  sysclk1_300_p (IN)
                         net (fo=0)                   0.000    13.332    sys_crg/instance_name/inst/clkin1_ibufds/I
    HPIOBDIFFINBUF_X0Y204
                         DIFFINBUF (Prop_DIFFINBUF_HPIOBDIFFINBUF_DIFF_IN_P_O)
                                                      0.421    13.753 r  sys_crg/instance_name/inst/clkin1_ibufds/DIFFINBUF_INST/O
                         net (fo=1, routed)           0.000    13.753    sys_crg/instance_name/inst/clkin1_ibufds/OUT
    G31                  IBUFCTRL (Prop_IBUFCTRL_HPIOB_M_I_O)
                                                      0.000    13.753 r  sys_crg/instance_name/inst/clkin1_ibufds/IBUFCTRL_INST/O
                         net (fo=1, routed)           0.515    14.268    sys_crg/instance_name/inst/clk_in1_clk_wiz_0
    MMCM_X0Y8            MMCME4_ADV (Prop_MMCM_CLKIN1_CLKOUT1)
                                                     -2.312    11.956 r  sys_crg/instance_name/inst/mmcme3_adv_inst/CLKOUT1
                         net (fo=1, routed)           0.193    12.149    sys_crg/CLKIN53_c
    BUFGCE_X0Y194        BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.021    12.170 r  sys_crg/cpu_clk_1_keep_cb/O
    X2Y7 (CLOCK_ROOT)    net (fo=343628, routed)      2.657    14.827    snoop_ctrl/tfhg/encoder[0].u_yhuj/iol_cp0
    SLR Crossing[1->2]  
    SLICE_X95Y876        FDSE                                         r  snoop_ctrl/tfhg/encoder[0].u_yhuj/current[300].valid_current.njkml_current.njkml_current_q_ret_13/C
                         clock pessimism              0.623    15.450   
                         clock uncertainty           -0.064    15.385   
    SLICE_X95Y876        FDSE (Setup_DFF_SLICEM_C_S)
                                                     -0.066    15.319    snoop_ctrl/tfhg/encoder[0].u_yhuj/current[300].valid_current.njkml_current.njkml_current_q_ret_13
  -------------------------------------------------------------------
                         required time                         15.319   
                         arrival time                         -17.464   
  -------------------------------------------------------------------
                         slack                                 -2.144   

 

 

0 Kudos
Moderator
Moderator
1,216 Views
Registered: ‎11-09-2015

Re: does the rst from the different modules need to be merged?

Hi @m006,

 

1>IBUFGCTRL is BUFG? it can replace BUFG? it seems that vivado only adds a IBUFGCTRL on rst_n_ibuf/O,no BUFG.

> Yes this is the same

 

2>what i felt wondering is vivado added a BUFG on a low fanout net(module 4) automatic ,not those hight fanout net(module1/2/3)

> It should do it on clocks net not on other nets if low fanout

 

3>can it improve the following timing if i add a bufg on the net "snoop_ctrl/tfhg/encoder[0].u_yhuj/iol_nclk(fanout = 7820)" ?

Not sure because a BUFG will add net delay and you are already failing because of a high net delay. I would more check why you have a high net delay


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos