如何避免通过BUFG推动逆变器

在逆变器上尝试DONT_TOUCH属性。
布雷特



以下为原文

Try a DONT_TOUCH property on the inverter.
 
Bret

布雷特，谢谢 - 我试图在HDL文件中设置属性：
我首先尝试将此属性添加到全局时钟：
（* dont_touch =“true”*）wire axi_rst;
// reset，active highBUFG bufg_axi_rst_i（.O（axi_rst）,. I（~frst [0]））;
不用找了：
阶段1.1.5.2实现可行性检查警告：[放置30-568] LUT'bufg_axi_rst_i_i_1'正在驱动888个寄存器的时钟引脚。
这可能会导致大量的保留时间违规。
前几个涉及的寄存器是：ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [7] .dq_i / dqs_in_dly_i / fdly_reg [0] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [4] .dq_i / dqs_out_dly_i / fdly_reg [1
] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [4] .dq_i / dqs_out_dly_i / fdly_reg [2] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [4] .dq_i / dqs_out_dly_i / fdly_reg [0] {
FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [4] .dq_i / dqs_out_dly_i / fdly_pre_reg [1] {FDCE}阶段1.1.5.2实施可行性检查|
校验和：842e0bff
然后我补充说
（* dont_touch =“true”*）wire axi_rst;
（* dont_touch =“true”*）wire frst_inv = ~frst [0]; BUFG bufg_axi_rst_i（.O（axi_rst）,. I（frst_inv））;阶段1.1.5.2实施可行性检查警告：[放置30-568] A LUT
'bufg_axi_rst_i_i_1'正在驱动888个寄存器的时钟引脚。
这可能会导致大量的保留时间违规。
前几个涉及的寄存器是：ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [7] .dq_i / dqs_in_dly_i / fdly_reg [0] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [4] .dq_i / dqs_out_dly_i / fdly_reg [1
] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [4] .dq_i / dqs_out_dly_i / fdly_reg [2] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [4] .dq_i / dqs_out_dly_i / fdly_reg [0] {
FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / byte_lane0_i / dq_block [4] .dq_i / dqs_out_dly_i / fdly_pre_reg [1] {FDCE}
此代码有效：
reg frst_inv; always @（negedge frst [0]或posedge axi_aclk）if if（！frst [0]）frst_inv else frst_inv endBUFG bufg_axi_rst_i（.O（axi_rst）,. I（frst_inv））;
但我认为这是一个肮脏的解决方案。
安德烈菲利波夫
Elphel，Inc。



以下为原文

Bret, thank you - I tried to set the property in HDL file:
 
I first tried to add this property to global clock:
(* dont_touch = "true" *)   wire           axi_rst;     // reset, active high
BUFG bufg_axi_rst_i  (.O(axi_rst),.I(~frst[0]));
 no change:
Phase 1.1.5.2 Implementation Feasibility check
WARNING: [Place 30-568] A LUT 'bufg_axi_rst_i_i_1' is driving clock pin of 888 registers. This could lead to large hold time violations. First few involved registers are:
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[7].dq_i/dqs_in_dly_i/fdly_reg[0] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[4].dq_i/dqs_out_dly_i/fdly_reg[1] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[4].dq_i/dqs_out_dly_i/fdly_reg[2] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[4].dq_i/dqs_out_dly_i/fdly_reg[0] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[4].dq_i/dqs_out_dly_i/fdly_pre_reg[1] {FDCE}
Phase 1.1.5.2 Implementation Feasibility check | Checksum: 842e0bff


 
Then I added
(* dont_touch = "true" *)   wire           axi_rst;
(* dont_touch = "true" *) wire frst_inv= ~frst[0];
BUFG bufg_axi_rst_i  (.O(axi_rst),.I(frst_inv));
Phase 1.1.5.2 Implementation Feasibility check
WARNING: [Place 30-568] A LUT 'bufg_axi_rst_i_i_1' is driving clock pin of 888 registers. This could lead to large hold time violations. First few involved registers are:
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[7].dq_i/dqs_in_dly_i/fdly_reg[0] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[4].dq_i/dqs_out_dly_i/fdly_reg[1] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[4].dq_i/dqs_out_dly_i/fdly_reg[2] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[4].dq_i/dqs_out_dly_i/fdly_reg[0] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/byte_lane0_i/dq_block[4].dq_i/dqs_out_dly_i/fdly_pre_reg[1] {FDCE}
 
This code works:
reg frst_inv;
always @ (negedge frst[0] or posedge axi_aclk) begin
    if (!frst[0]) frst_inv <= 1'b1;
    else          frst_inv <= 1'b0;
end
BUFG bufg_axi_rst_i  (.O(axi_rst),.I(frst_inv));
 
But it is a dirty solution I think.
 
Andrey Filippov
Elphel, Inc.
 

错误的复制粘贴：
后
（* dont_touch =“true”*）wire axi_rst;
（* dont_touch =“true”*）wire frst_inv = ~frst [0]; BUFG bufg_axi_rst_i（.O（axi_rst）,. I（frst_inv））;
我有 ：
阶段1.1.5.2实现可行性检查警告：[放置30-568] LUT'frst_inv_inferred_i_1'正在驱动888个寄存器的时钟引脚。
这可能会导致大量的保留时间违规。
前几个涉及寄存器是：ddrc_sequencer_i / phy_cmd_i / phy_top_i / cmd_addr_i / cmda_ba1_i / dqs_out_dly_i / fdly_pre_reg [0] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / cmd_addr_i / cmda_ba1_i / dqs_out_dly_i / fdly_pre_reg [1] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i /
cmd_addr_i / cmda_ba1_i / dqs_out_dly_i / fdly_pre_reg [2] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / cmd_addr_i / cmda_ba1_i / dqs_out_dly_i / fdly_reg [0] {FDCE} ddrc_sequencer_i / phy_cmd_i / phy_top_i / cmd_addr_i / cmda_ba1_i / dqs_out_dly_i / fdly_reg [2] {FDCE
阶段1.1.5.2实施可行性检查|
校验和：842e0bff



以下为原文

Wrong copy-paste:
 
After
(* dont_touch = "true" *)   wire           axi_rst;
(* dont_touch = "true" *) wire frst_inv= ~frst[0];
BUFG bufg_axi_rst_i  (.O(axi_rst),.I(frst_inv));
 
I've got :
Phase 1.1.5.2 Implementation Feasibility check
WARNING: [Place 30-568] A LUT 'frst_inv_inferred_i_1' is driving clock pin of 888 registers. This could lead to large hold time violations. First few involved registers are:
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/cmd_addr_i/cmda_ba1_i/dqs_out_dly_i/fdly_pre_reg[0] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/cmd_addr_i/cmda_ba1_i/dqs_out_dly_i/fdly_pre_reg[1] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/cmd_addr_i/cmda_ba1_i/dqs_out_dly_i/fdly_pre_reg[2] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/cmd_addr_i/cmda_ba1_i/dqs_out_dly_i/fdly_reg[0] {FDCE}
    ddrc_sequencer_i/phy_cmd_i/phy_top_i/cmd_addr_i/cmda_ba1_i/dqs_out_dly_i/fdly_reg[2] {FDCE}
Phase 1.1.5.2 Implementation Feasibility check | Checksum: 842e0bff

嗨，看起来逆变器输出正在驱动更大的负载，所以我更喜欢在代码中实例化BUFG并更换逆变器的连接并通过bufg输出驱动它.Regards，Achutha
--------------------------------------------------
-------------------------------------------请注意 - 请标记答案
如果提供的信息有用，请“接受为解决方案”。给予您认为有用并回复导向的帖子。感谢Kudos .------------------------
--------------------------------------------------
--------------



以下为原文

Hi,

It looks like the inverter output is driving larger no of load , so i would prefer instantiating the BUFG in the code and replacing the connectivity of the inverter and drive it through the bufg output.

Regards,
Achutha---------------------------------------------------------------------------------------------
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.
----------------------------------------------------------------------------------------

Achutha，我正在努力做到这一点 - 在代码中实例化BUFG（https://github.com/Elphel/eddr3/blob/master/ddrc_test01.v中的第245行），但软件是（正如我猜的）移动反转
在BUFG输入到输出。
正如布雷特建议我尝试过dont_touch，但它没有帮助。
我确定这是我的愚蠢错误，但我看不出它在哪里。
我做了类似的事情（在BUFG输入上指定反转）和ISE多次没有问题，Vivado可能有些东西我不见了 - 我是新手。
安德烈菲利波夫
Elphel，Inc。



以下为原文

Achutha, I was trying do do exactly that - instantiate BUFG in the code (line 245 in https://github.com/Elphel/eddr3/blob/master/ddrc_test01.v), but software was (as I guess) moving inversion on the BUFG input to the output.
 
As Bret suggested I tried dont_touch, but it did not help. I'm sure it is my stupid mistake, but I can not see where it is. I did similar things (specifying inversion on the BUFG input) with ISE many times with no problems, there may be something in Vivado I'm missing - I'm new to it.
 
Andrey Filippov
Elphel, Inc.

嗨安德烈，
当BUFG用于时钟（其设计用于时钟）时，此严重警告是一般警告。
因此我认为你可以放心地忽略它。
在你的情况下，有一些事实，但不是直接的：当你试图通过在BUFG上重置来解决时序问题时，在路径中使用LUT不是一个好主意并且会伤害时机。
实际上，我从未成为将BUFG用于非时钟信号的忠实粉丝。
我还没有看到一个案例，它有所帮助，没有其他更好的解决方案。
在您的情况下，您的复位必须路由到FPGA的中心，然后返回到设备的其余部分。
相反，我建议以下解决方案：
1）寄存器平衡：将LUT从寄存器的输出移到寄存器的输入并保持行为。
XST能够自动执行此操作，遗憾的是此功能尚未在Vivado中实现。
您需要更改代码并执行此操作。
2）移植：如果无法移动寄存器，添加一个流水线寄存器，只需添加一个时钟周期延迟，就可以摆脱关键路径中的LUT
3）寄存器复制：如果扇出是一个问题，手动或自动寄存器复制将解决由于高扇出引起的时序问题
最好的祝福
德赖斯
--------------------------------------------------
--------------------------------------------------
----------------如果提供的信息有用，请将答案标记为“接受为解决方案”。给予您认为有用的帖子并通过点击星标回复导向
在帖子旁边。



以下为原文

Hi Andrey,
 
This critical warning is a general critical warning when the BUFG is used for clocks (for which it is designed for). Therefor I think you can safely ignore it.
In your case, there is some truth to it, but not directly: when you try to resolve timing issues by placing a reset on a BUFG, having a LUT in the path is not a good idea and hurts timing.
 
Actually, I've never been a big fan of using BUFGs for non-clock signals. I have yet to see a case where it helped and there were no other and better solutions.
In your case, your reset has to route to the center of the FPGA and then back to the rest of the device.
 
Instead I suggest the following solutions:
1) register balancing: move the LUT from the output of the register to the input of the register and preserve behaviour. XST was able to do this automatically, unfortunately this feature is not yet implemented in Vivado. You need to change your code and do this.
2) pipeling: if it is not possible to move the register, add a pipeline register and by just adding one clock cycle delay, get rid of the LUT in the critical path
3) register duplication: if fanout is a problem, manual or automatic register duplication will resolve timing issues due to high fanout
 
 
Best regards
Dries
--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

从信号名称，我们可以告诉它是一个复位信号。
因此有趣的是，警告表明逆变器正在驱动寄存器的CLOCK引脚。
如果打开合成设计，那么连接是什么样的？
合成后LUT是否通过BUFG？
它是否驱动FDCE的C或CLR引脚？
--------------------------------------------------
-----------------------不要忘记回答，kudo，并接受为解决方案.-------------
--------------------------------------------------
----------



以下为原文

From the signal name, we can tell it's a reset signal. Thus it's interesting that the warning states the inverter is driving CLOCK pin of registers.
 
If you open synthesized design, what's the connection like? Is the LUT pushed through BUFG after synthesis? Does it drive C or CLR pin of FDCE?
 
 
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

我必须在这里同意Dries，并且通过扩展：你可以将异步复位转换为同步复位;
即。
你知道重置会持续至少两个时钟周期吗？
这将有助于计时很多，并可能使您无需在非时钟上使用BUFG。
丹尼尔



以下为原文

I have to agree with Dries here, and by extension: can you convert the asynchronous reset into a synchronous reset; ie. do you know that reset will last for at least two clock ticks?  That will help the timing a lot and probably keep you from needing a BUFG on a non-clock.
 
Daniel
 

是的，它是复位信号，但是时钟输入完全相同。
如果我在BUFG（驱动FDCE的时钟）输入上使用时钟反转，我得到相同的警告）。
看看“bufg_axi_rst_i”工具制作的名称“bufg_axi_rst_i_i_1”，我猜在BUFG之后有一个自动实例化的逆变器。



以下为原文

Yes, it is reset signal, but with the clock inputs it was exactly the same. If I use clock inversion on the BUFG (driving clocks of FDCE) input I get the same warning). And looking at the name "bufg_axi_rst_i_i_1" made by the tools from the "bufg_axi_rst_i" I guess there is an automatically instantiated inverter after the BUFG.

嗨，Dries，
它看起来它是BUFG之后的实际额外逆变器，而不仅仅是我可以忽略的误报警告。
因为当我在BUFG输入上没有变频器时，我没有收到任何警告。
因此BUFG驱动数百/数千个输入不会触发警告。
从BUFG驱动重置 - 是的，我知道它不需要，我可以使用约束来忽略相关的时序违规，但最初我会尝试保持代码清理器并尽可能少地使用约束，为工具提供合理的自由。
但为此，我需要理解工具“决策”背后的“推理”，这可能是我身上的愚蠢行为，也可能是工具中的错误。
如果它是一个错误 - 它可能与复位和时钟信号的来源有关 - 它们来自特殊模块PS7  - 我没有尝试从常规I / O焊盘驱动BUFG。



以下为原文

Hi Dries,
 
It looks to me that it is an actual extra inverter after BUFG, not just a false-positive warning that I can ignore. Because when I do not have inverter on the BUFG input I get no warnings. So BUFG driving hundreds/thousands of inputs does not trigger a warning.
 
Driving resets from BUFG - yes, I know it is not needed, I can use constraints to ignore related timing violations, but initially I would try to keep code cleanerer and use as little of constraints as possible, giving tools the reasonable freedom. But for this I need to understand the "reasoning" behind the tools "decisions" and this can be either something stupid on my side or a bug in the tools. And if it is a bug - it may be related to the source of the signals for resets and clock - they came from the special module PS7 - I did not experiment with driving the BUFG from the regular I/O pads.

elphel写道：
从BUFG驾驶重置 - 是的，我知道不需要它。
在我看来，除了时钟输入（触发器，RAM等）之外，你无法将BUFG的输出连接起来。
----------------------------是的，我这样做是为了谋生。



以下为原文

elphel wrote:
 
Driving resets from BUFG - yes, I know it is not needed.

Seems to me that you cannot connect the output of a BUFG for anything other than a clock input (flip-flop, RAM, whatever). 
----------------------------Yes, I do this for a living.

绝对可以将复位连接到全局时钟网，我的问题不依赖于它是时钟还是复位输入，而只是将逆变器从BUFG输入移到BUFG输出。
没有反向输入，Vivado很乐意将时钟和复位输入连接到BUFG输出，没有来自任何综合/实现工具的警告。
安德烈菲利波夫
Elphel，Inc。



以下为原文

It definitely is possible to connect resets to global clock net, the problem I have does not depend on if is it clock or reset input, but with just moving inverter from BUFG input to BUFG output. Without inverted input Vivado happily connects clock and reset inputs to BUFG output, no warnings from any of the synthesis/implementation tools.
 
Andrey Filippov
Elphel, Inc.

elphel写道：
是的，它是复位信号，但是时钟输入完全相同。
如果我在BUFG（驱动FDCE的时钟）输入上使用时钟反转，我得到相同的警告）。
看看“bufg_axi_rst_i”工具制作的名称“bufg_axi_rst_i_i_1”，我猜在BUFG之后有一个自动实例化的逆变器。
嗨，安德烈，这不是BUFG之前/之后的LUT问题，而是时钟线上的LUT。
设置和保持路径不再相同，因此不推荐这种做法。
最好的问候干
--------------------------------------------------
--------------------------------------------------
----------------如果提供的信息有用，请将答案标记为“接受为解决方案”。给予您认为有用的帖子并通过点击星标回复导向
在帖子旁边。



以下为原文

elphel wrote:
Yes, it is reset signal, but with the clock inputs it was exactly the same. If I use clock inversion on the BUFG (driving clocks of FDCE) input I get the same warning). And looking at the name "bufg_axi_rst_i_i_1" made by the tools from the "bufg_axi_rst_i" I guess there is an automatically instantiated inverter after the BUFG.

Hi Andrey,

It's not a question of a LUT before/after BUFG, but a LUT on a clock line.
Setup and hold paths are not identical anymore and therefor this practice is not recommended.


Best regards
Dries
--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

elphel写道：
从BUFG驱动重置 - 是的，我知道它不需要，我可以使用约束来忽略相关的时序违规，但最初我会尝试保持代码清理器并尽可能少地使用约束，为工具提供合理的自由。
但为此，我需要理解工具“决策”背后的“推理”，这可能是我身上的愚蠢行为，也可能是工具中的错误。
如果它是一个错误 - 它可能与复位和时钟信号的来源有关 - 它们来自特殊模块PS7  - 我没有尝试从常规I / O焊盘驱动BUFG。
嗨安德烈，
永远不会在重置时设置set_false_path约束！
它不是忽视它，而是满足时机要求。
它只是掩盖了一个问题。
只是不要在重置时使用BUFG来解决扇出时间问题。然后你就不会得到严重的警告。
添加另一个流水线寄存器以避免关键路径上的逆变器（LUT），并让phys_opt_design或synth_design复制此寄存器以减少扇出并满足时序要求。
最好的祝福
德赖斯
--------------------------------------------------
--------------------------------------------------
----------------如果提供的信息有用，请将答案标记为“接受为解决方案”。给予您认为有用的帖子并通过点击星标回复导向
在帖子旁边。



以下为原文

elphel wrote:

Driving resets from BUFG - yes, I know it is not needed, I can use constraints to ignore related timing violations, but initially I would try to keep code cleanerer and use as little of constraints as possible, giving tools the reasonable freedom. But for this I need to understand the "reasoning" behind the tools "decisions" and this can be either something stupid on my side or a bug in the tools. And if it is a bug - it may be related to the source of the signals for resets and clock - they came from the special module PS7 - I did not experiment with driving the BUFG from the regular I/O pads.

Hi Andrey,
 
never put a set_false_path constraint on a reset!
It's not by ignoring it, that timing is met. It just masks a problem.
 
Just don't use a BUFG on a reset to resolve fanout timing issues.Then you won't get the critical warning.
Add another pipeline register to avoid the inverter (LUT) on your critical paths and let phys_opt_design or synth_design duplicate this register to reduce fanout and meet timing.
 
 
Best regards
Dries
--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

bassman59写道：
elphel写道：
从BUFG驾驶重置 - 是的，我知道不需要它。
在我看来，除了时钟输入（触发器，RAM等）之外，你无法将BUFG的输出连接起来。
嗨，亚历克斯，
是的，它可能并且允许，但我认为这不是好习惯。
同样，关键警告用于时钟，因为BUFG通常用​​于时钟。
在这种情况下没有，所以你可以考虑一个错误：当BUFG不用于时钟时，不应该有一个严重的警告。
然而，问题是：将BUFG用于时钟以外的信号是一种好习惯吗？
最好的祝福
德赖斯
--------------------------------------------------
--------------------------------------------------
----------------如果提供的信息有用，请将答案标记为“接受为解决方案”。给予您认为有用的帖子并通过点击星标回复导向
在帖子旁边。



以下为原文

bassman59 wrote:

elphel wrote:
 
Driving resets from BUFG - yes, I know it is not needed.

Seems to me that you cannot connect the output of a BUFG for anything other than a clock input (flip-flop, RAM, whatever). 

Hi Alex,
 
yes, it possible and allowed, but I don't think it's good practice.
Again, the critical warning was intended for clocks as BUFGs are typically used for clocks. In this case not, so you could consider that a bug: there shouldn't be a critical warning when the BUFG is not used for a clock. However, then the question is: is it good practice to use BUFGs for signals other than clocks??
 
 
Best regards
Dries
--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

感谢您关于不使用BUFG进行重置的建议。
正如我上面所写 - 问题并不取决于我是使用全局时钟网进行复位还是使用时钟 - 时钟也是如此。
如果BUFG输入上没有逆变器 - 所有工具都很高兴，如果我把逆变器放在BUFG输入上 - 工具抱怨LUT驱动数百个FDCE的CLOCK输入。
所以它是无意中推动逆变器通过BUFG。
工具制作了一个由BUFG驱动的实例（LUT），它反过来驱动FDCE的所有时钟，这不是一个我可以“安全地忽略”的警告。



以下为原文

Thank you for the suggestions about not using BUFG for resets. As I wrote above - the problem does not depend on if I use global clock net for resets or for clocks - with clock it is all the same. If there is no inverter on the BUFG input - all tools are happy, if I put inverter on the BUFG input - tools complain that LUT drives hundreds of CLOCK inputs of FDCE. So it is about unintended pushing the inverter through the BUFG. Tools made an instance (LUT) driven by BUFG that in turn drives all the clocks of the FDCEs, and it is not a warning I can "safely ignore".

您是否检查过BUFG上的扇出以确保它没有驱动单个FF，然后驱动多个重置端口？
丹尼尔



以下为原文

Have you checked the fanout on the BUFG to make sure it is not driving a single FF, which is then driving many reset ports?
 
Daniel
 

Daniel，我没有特别检查扇出，但是当我使用BUFG作为时钟时，它们之间不能有FF，只是一个逆变器（报告为LUT）。
而且 - 好的和坏的区别在于BUFG输入上的逆变器。
试着“保持”或“dont_touch”没有用--Vivado将反转移动到BUFG输出和FDCE时钟输入之间的新LUT。



以下为原文

Daniel, I did not check fanout specifically, but when I use BUFG for clocks there can be no FFs between, just an inverter (reported as LUT). And again - all the difference between good and bad is an inverter on the BUFG input. tryin to "keep" or "dont_touch" does not help - Vivado moves the inversion to a new LUT between BUFG output and FDCE clock inputs.

driesd写道：
这不是BUFG之前/之后的LUT问题，而是时钟线上的LUT。
设置和保持路径不再相同，因此不推荐这种做法。
Dries，我不明白 - “BUFG之后的LUT”和“时钟线上的LUT”之间有什么区别。
我假设当BUFG驱动时钟网络时，BUFG输出和FDCE时钟输入之间应该没有LUT。
但是这些工具将这种逆变器LUT连接到BUFG输出并试图驱动所有FDCE时钟输入。
所以这就是为什么我认为逆变器出错 - 要么是由于我做错了，要么是由工具软件bug引起的。
安德烈菲利波夫
Elphel，Inc。



以下为原文

driesd wrote:
It's not a question of a LUT before/after BUFG, but a LUT on a clock line.
Setup and hold paths are not identical anymore and therefor this practice is not recommended.

Dries, I did not understand - what is the difference between "LUT after BUFG" and "LUT on a clock line". I assumed that when BUFG drives clock network there should be no LUTs between the BUFG output and FDCE clock inputs. But the tools put such inverter LUT connected to the BUFG output and tried to drive all the FDCE clock inputs. So this is why I consider that inverter an error - either caused by me doing something wrong, or caused  by the tools software bug.
 
Andrey Filippov
Elphel, Inc.