在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 15078|回复: 27

[讨论] 扇出大为什么会导致路径延时比较大

[复制链接]
发表于 2014-4-22 10:23:43 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

x
FPGA的应该都知道扇出大会导致路径延时大,时序不容易收敛,特别是像复位信号这种扇出很大,需要上全局时钟网络。
但是应该也有很多人不清楚为什么扇出大会导致路径延时增大,发个帖子,讨论一下,特别是刚刚学习FPGA的新人可以好好想一下这个问题,另外对于信号扇出大的解决办法也在该贴讨论范围内哈
发表于 2014-4-22 12:31:57 | 显示全部楼层
特别是像复位信号这种扇出很大,需要上全局时钟网络
我用的xilinx器件,复位信号不能走全局时钟网络
在FPGA中,延时由两部分组成,逻辑延时和走线延时。一个寄存器输出的信号要走线到接收信号的地方,而FPGA的布线是有一定规则的,如果扇出太大,导致有的资源布线困难,就会增大布线的长度,导致增加了走线延时。
 楼主| 发表于 2014-4-22 13:28:38 | 显示全部楼层
回复 2# haitaox


    又是你啊,确实扇出大导致源端到无法满足到所有目的端的走线延迟,这样会造成部分路径的走线延迟会很大。
    通常的解决办法: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复位不能上全局是不是这个问题,如果不是的话,说一下具体的情况
发表于 2014-4-22 13:36:46 | 显示全部楼层
我用spartan6的片子,只有时钟才能上bufg的网络,不知道你用的什么片子
 楼主| 发表于 2014-4-22 14:16:23 | 显示全部楼层
回复 4# haitaox


    我前面也用过spartan6的,不过好像没有把复位上全局,前面用z7000和v5的片子的时候有上过。
    前面我看spartan6关于时钟结构的用户手册的时候,上面有说过bufg的源可以是普通的信号,你说的不能上全局网络,具体是个什么情况,能说一下吗?
    上全局网络之后有什么问题,如果出错了,出的什么错误?
发表于 2014-4-22 14:39:09 | 显示全部楼层
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的复位端口”
发表于 2014-4-22 14:43:27 | 显示全部楼层
spartan6 时钟手册 ug382,没见到说bufg的时钟源可以是普通的逻辑。
从手册来看,bufg的输入可以是 1.GCLK的引脚 2.bufio2的输出 3.CMT的输出
5b94d8c3-10a4-45a3-9ad8-7d56a7c6a916.jpg
 楼主| 发表于 2014-4-22 14:55:59 | 显示全部楼层
回复 7# haitaox

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,是可以的
发表于 2014-4-22 15:06:49 | 显示全部楼层
clocks from FPGA logic interconnect
OK,bufg的时钟源确实可以是FPGA的内部逻辑,但是BUFG的输出呢,可以输出到任何地方吗?
我的理解,BUFG的输出只能接到时钟负载上,不能接到FF的SR引脚。
因此,至少在spartan6上,消除复位扇出较大的方法不能用你说的第二种。

我试过把BUFG的输出接到引脚和FF的复位端口,都是不可以的。而且,从xilinx的报告中也可以看到这一点。
发表于 2014-4-22 15:11:54 | 显示全部楼层
至于你所说的第一种方法 寄存器复制,也不一定是很好的方法。
xilinx有control set的概念,即一个slice中只能有一个control set,如果认为复制了复位管脚,会造成大规模的control set复制,有时候会导致资源占用率急剧上升。
在ise的资源报告中,有一栏专门报告了control set的内容。

建议你看看wp309中关于“Analysis and Use of Control Signals and Control Sets”的内容。
EM截图_201442215939.png
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐 上一条 /2 下一条

×

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-5-9 11:24 , Processed in 0.033567 second(s), 10 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表