扇出大为什么会导致路径延时比较大
但是应该也有很多人不清楚为什么扇出大会导致路径延时增大，发个帖子，讨论一下，特别是刚刚学习FPGA的新人可以好好想一下这个问题，另外对于信号扇出大的解决办法也在该贴讨论范围内哈
特别是像复位信号这种扇出很大，需要上全局时钟网络
我用的xilinx器件，复位信号不能走全局时钟网络
在FPGA中，延时由两部分组成，逻辑延时和走线延时。一个寄存器输出的信号要走线到接收信号的地方，而FPGA的布线是有一定规则的，如果扇出太大，导致有的资源布线困难，就会增大布线的长度，导致增加了走线延时。
又是你啊，确实扇出大导致源端到无法满足到所有目的端的走线延迟，这样会造成部分路径的走线延迟会很大。
通常的解决办法：1.寄存器复制（可以通过约束最大扇出由工具自己实现，也可以自己手动添加同时添加不优化的约束)
2.上全局时钟网络或者其它的专用网络
xilinx的复位信号或者其它普通信号都可以上全局时钟网络。
用ISE的XST综合时，如果是上升沿复位可以直接上全局网络，而下降沿复位则需要做特殊的处理，XST才会将复位信号放到全局网络上。
使用synplify综合时，不管是上升沿还是下降沿都可以直接上全局网络。
XST综合，下降沿复位上全局的解决办法：
BUFG u_bufg
( .O (rst_bufg)
.I (~rst_n)
);
assign sys_rst_n = ~rst_bufg;
先去反进BUFG，再将BUFG输出取反作为全局复位。
不知道你说的xilinx复位不能上全局是不是这个问题，如果不是的话，说一下具体的情况
我用spartan6的片子，只有时钟才能上bufg的网络，不知道你用的什么片子
我前面也用过spartan6的，不过好像没有把复位上全局，前面用z7000和v5的片子的时候有上过。
前面我看spartan6关于时钟结构的用户手册的时候，上面有说过bufg的源可以是普通的信号，你说的不能上全局网络，具体是个什么情况，能说一下吗?
上全局网络之后有什么问题，如果出错了，出的什么错误?
BUFG BUFG_reset_sync_inst (
.O(o_reset_parallel ), // 1-bit output: Clock buffer output
.I(w_reset_parallel ) // 1-bit input: Clock buffer input
);
ERRORlace:1136 - This design contains a global buffer instance,
<clk_rst_top_inst/BUFG_reset_sync_inst>, driving the net, <w_reset_parallel>,
that is driving the following (first 30) non-clock load pins.
< PIN: ctrl_channel_inst/spi_slave_inst/spi_user_logic_inst/ov_wd_data_15.SR;
>
< PIN: ccd_top_inst/ccd_vclear_inst/o_waitflag.SR; >
< PIN: ctrl_channel_inst/spi_slave_inst/spi_if_inst/rx_shift_data_33.SR; >
< PIN: ctrl_channel_inst/spi_slave_inst/spi_user_logic_inst/ov_wd_data_3.SR;
>
< PIN: ctrl_channel_inst/spi_slave_inst/spi_user_logic_inst/ov_wd_data_5.SR;
>
< PIN: ctrl_channel_inst/spi_slave_inst/spi_user_logic_inst/ov_wd_data_7.SR;
>
< PIN: ctrl_channel_inst/spi_slave_inst/spi_user_logic_inst/ov_wd_data_2.SR;
>
< PIN: ccd_top_inst/ccd_reg_inst/ov_frame_period_m_5.SR; >
< PIN: ccd_top_inst/ccd_vclear_inst/exposure_end.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_0.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_11.SR; >
< PIN: data_top_inst/ctrl_data_inst/vsync_start.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_13.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_15.SR; >
< PIN: ccd_top_inst/ccd_reg_inst/ov_frame_period_m_9.SR; >
< PIN: ccd_top_inst/ccd_reg_inst/ov_frame_period_m_7.SR; >
< PIN: ccd_top_inst/ccd_reg_inst/ov_frame_period_m_1.SR; >
< PIN: ccd_top_inst/ccd_reg_inst/ov_frame_period_m_2.SR; >
< PIN: ccd_top_inst/ccd_reg_inst/ov_frame_period_m_14.SR; >
< PIN: ccd_top_inst/ccd_reg_inst/ov_frame_period_m_12.SR; >
< PIN: ctrl_channel_inst/spi_slave_inst/spi_if_inst/o_rd_received.SR; >
< PIN: ccd_top_inst/ccd_exp_inst/xsub_last.SR; >
< PIN: usb3_interface_top_inst/frame_full_flag.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_18.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_27.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_1.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_7.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_29.SR; >
< PIN: usb3_interface_top_inst/ov_usb_data_21.SR; >
< PIN: ccd_top_inst/ccd_reg_inst/ov_frame_period_m_4.SR; >
This is not a recommended design practice in Spartan-6 due to limitations in
the global routing that may cause excessive delay, skew or unroutable
situations. It is recommended to only use a BUFG resource to drive clock
loads. If you wish to override this recommendation, you may use the
CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote
this message to a WARNING and allow your design to continue.
< PIN "clk_rst_top_inst/BUFG_reset_sync_inst.O" CLOCK_DEDICATED_ROUTE =
FALSE; >
在map阶段产生了error。翻译成中文就是说“bufg的输出只能接到时钟的负载上，不能接到FF的复位端口”
spartan6 时钟手册 ug382，没见到说bufg的时钟源可以是普通的逻辑。
从手册来看，bufg的输入可以是 1.GCLK的引脚 2.bufio2的输出 3.CMT的输出
ug382第13页
The global clock network in Spartan-6 FPGAs is driven by 16 BUFGMUXes located in the
center of the device. The 16 BUFGMUXes can be fed from three different sources; clock
inputs from top and bottom banks, clock inputs from left and right banks, and clocks from
FPGA logic interconnect and/or PLL/DCM.
可以来自FPGA logic，这个你可以自己去试一下，普通信号上BUFG，是可以的
clocks from FPGA logic interconnect
OK,bufg的时钟源确实可以是FPGA的内部逻辑，但是BUFG的输出呢，可以输出到任何地方吗?
我的理解，BUFG的输出只能接到时钟负载上，不能接到FF的SR引脚。
因此，至少在spartan6上，消除复位扇出较大的方法不能用你说的第二种。
我试过把BUFG的输出接到引脚和FF的复位端口，都是不可以的。而且，从xilinx的报告中也可以看到这一点。
至于你所说的第一种方法 寄存器复制，也不一定是很好的方法。
xilinx有control set的概念，即一个slice中只能有一个control set，如果认为复制了复位管脚，会造成大规模的control set复制，有时候会导致资源占用率急剧上升。
在ise的资源报告中，有一栏专门报告了control set的内容。
建议你看看wp309中关于“Analysis and Use of Control Signals and Control Sets”的内容。
嗯，一会找来看看。寄存器复制和上全局时钟网络都只是在大扇出导致时序不能收敛时的一种解决办法，时序问题的根本还是设计。
同意你的观点。
时序是设计出来的，而不是约束或者修改出来的。
做设计时间长了就会发现，RTL编码其实用的时间很短，占大头的时间还是方案设计和详细设计阶段。
ps，用好了脚本语言，写代码刷刷的。
刚刚我去测试了一下，spartan6上BUFG的输出确实只能驱动时钟端口，v6和z7000上是可以的，这个我已经用过了，刚刚又在v6上测试了一把，确实是可以的。
以前还没注意这个问题，以为xilinx的FPGA都具备这个功能。
你用的什么编码工具啊?VIM?
可能是xilinx家不同的器件有不同的使用方法吧。
我用UE，把常用的模块都做成了脚本。公司文化吧，都用UE，只好也用UE 了。
扇出大就需要驱动能力更强的器件（速度较慢），或者不断的在布线路径上添加buffer或者LUT来增加信号驱动能力。个人猜想是这个原因导致的延迟增大。至于FPGA内，从来没有特别关注过reset是走哪个网络的。只关心过时钟。
全局时钟网络保证到时钟每个寄存器的延时基本保持一致，而普通布线资源没办法做到这一点，扇出过大，就会导致有的路径上延时比较短，有的路径延时会比较长，增加时序收敛的风险。
至于你说的过buf或者LUT增强驱动导致延时的问题，这个我也不是很清楚是不是会有这么一回事，期待其它人的解答。其实我以前和你这个想法差不多，但是不确定是因为要布线才穿过LUT，还是为了增强驱动。
期待大神的声音。
好贴 我也一直有这个疑问
请教一下，如果FPGA复位作为全局多个模块的复位信号，有什么设计方能适当优化其扇出吗?多谢！
据我所知，lut当做布线资源使用完全是因为正常的布线资源不够使用，才被迫使用lut的。
在ise的综合报告里面，有一项是 lut route through的报告。
xilinx的文档里面说了一些这方面的知识，大致的意思就是通过只能通过lut才能布线到某些资源
您可以参考一下xilinx有关复位的两片 white paper。大致的思想是
1.复位可以不用的地方就不用
2.复位可以少用的地方就少用
3.复位信号最好是同步的
4.用不同复位的方法(always 敏感列表里面没有reset)
1 2 两项能够显著提高资源使用率。 3 4两项可以保证把reset信号作为普通的输入信号，这样就没有扇出的问题了，因为reset不需要专用的布线资源。
使用同步复位的方法，复位信号同步到本地时钟域。这样ise会将复位信号作为一般信号处理，就无需考虑扇出问题了。
好的，受教了，多谢！看来平常还是要多充充电才行
首先要理解扇出是指什么，一个信号要驱动一个单位电容的负载和100个单位电容的负载的时候他的电压变化速度是不一样的，当电容太大时变化速度会很慢，这个时候就是驱动能力不够了
这个问题讨论的好。
我一直在使用ALTERA的产品，最近听了一堂Xilinx的课，FAE在谈到复位的时候也是建议使用同步复位，这和altera的建议正好相反，可能两家产品内部LE（slice）的结构有些许差异造成。而且FAE提出一个观点“同步复位异步释放”，而altera提出的却是异步复位同步释放，这两个观点应该是截然相反的；非常有意思。困扰了一段时间。
是的，xilinx一直建议同步复位异步释放的方法
我觉的只需要在fpga引脚的地方考虑扇出的问题，如果fpga驱动的外部负载电容过大可以增加驱动电流。
fpga内部的时钟连线会自己考虑驱动的问题，无需用户关心
内部走线工具确实会自己考虑驱动的问题，不会出现驱动不够的问题，但是扇出过大，会导致两个问题，一是负载增加电压变化变缓导致的数据有效窗口缩小，二是同一信号到不同位置的延时会不一样，这样就增加了时序收敛的难度，可能出现无法同时保证到a和到b的时序都满足。所以编译选项里面会有一个最大扇出的设置，超过这个扇出可能就会使用寄存器复制等方式来保证时序。
扇出大导致电压变化变缓这个不知道影响有多大，但是第二点会很大程度上影响时序收敛。
嗯，有道理