Verilog中的If语句导致锁存推断?[英] If statements causing latch inference in Verilog?

本文是小编为大家收集整理的关于Verilog中的If语句导致锁存推断?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我正在编写用于合成算法的Verilog代码,我对可能导致闩锁的情况有些困惑.以下是代码的这样的部分,尽管它在模拟方面效果很好,但我担心它可能会在硬件上引起问题.

always@(b1 or b2)

.....
// b1_map,b2_map,m1_map & m2_map are derived from combinational functions using b1 & b2
.....

if(b1_map<=20 && m2_map<=20 && b1_map>=0 && m2_map>=0)



begin
accumulator1[b1_map][m2_map]= accumulator1[b1_map][m2_map] + 1;
end

if(b2_map<=20 && m2_map<=20 && b2_map>=0 && m2_map>=0)

begin
accumulator2[b2_map][m2_map]= accumulator2[b2_map][m2_map] + 1;
end

//accumulator1  & accumulator2 are 2d registers mapped like 2d arrays

因此,在这种情况下,我希望仅在指定限制中映射数据.会因为没有定义"其他"方案,可以推断闩锁吗?我没有添加其他语句,因为如果该数据不在限制的情况下,我什么都不想做.

推荐答案

如果正确编写if语句,您会没事的.当通过IF语句没有更新一个或多个输出的IF语句的路径时,就会生成闩锁.如以下代码将生成一个闩锁:

always @* begin
    if (a) begin
        b <= c & d;
        e <= f;
    end else begin
        b <= c | d;
    end
end

请注意,仅当a为真时才分配E?这需要闩锁才能正确实现.

将生成闩锁的另一种优势是,当灵敏度列表不包含代码中使用的信号时.

always @(a) begin
    if (a) begin
        b <= c & d;
    end else begin
        b <= c | d;
    end
end

此代码将在C和D上或B上生成闩锁,因为它仅在更改时才能更新B.

其他推荐答案

您已经误解了您的问题(您不应该接受答案) - 这个问题与"闩锁"根本没有关系.您的代码不制作 感官(用于合成). Quartus知道这一点,基本上是告诉您 重写您的代码.

您有一个组合块,当 信号变化.两个问题:(1)这当然不是您真正想要的 硬件,(2)当B1时,数字必须保持不变,而不是增加 和B2不要改变.第二个ISUE是一个Quartus正在报告 - 您的 电路需要对某种形式的记忆,将其报告为"闩锁".它不是 足够聪明,可以报告第一个问题,这是真正的问题.

尝试将电路作为带有真实硬件的原理图.什么 更改B1或B2'实际上意味着?您将如何保持 B1和B2不变时的累加器?电路不是不可能的, 但这超出了一个问题.

使您的电路同步,在时钟边缘触发,只有一个时钟 (甚至可能是重置)在灵敏度列表中,并准确保留内脏 相同.您的if语句没有错,因为您实际上 如果没有任何有趣的事情发生,希望蓄能器保持不变 在B1/B2.

其他推荐答案

推断的闩锁可能来自不完整的灵敏度列表或不完整的作业.

组合块的灵敏度列表通常应使用always @*编写.这避免在更新代码时编码错误.合成的组合块(不包括边缘灵敏度的组合块)将以always @*的方式进行.具体的命名信号增加了更多的工作,可能会导致RTL到GATE级别(合成后)错误.

不完整的作业意味着必须保留该值,将推断出一个闩锁.闩锁并不是天生的不好,但需要仔细考虑.以这种方式推断一个可以消除您否则将拥有的思想充实和控制.这可能导致复杂的时机问题.因为闩锁对水平敏感而不是边缘敏感.理想情况下,您希望闩锁在时钟周期的第一个锁定中打开,以便在从中读取数据时将其关闭.推断的闩锁删除此控件.

if用其他语句完成,违约的案例卡斯塔内在设置明智的值(0)可以帮助避免这些意外闩锁.

本文地址:https://www.itbaoku.cn/post/2090970.html

问题描述

I am writing a Verilog code for synthesis of an algorithm, I am a little confused on what cases might cause latches to be inferred. Below is one such section of the code, though it works fine in simulation, I am worried it might cause problems on hardware.

always@(b1 or b2)

.....
// b1_map,b2_map,m1_map & m2_map are derived from combinational functions using b1 & b2
.....

if(b1_map<=20 && m2_map<=20 && b1_map>=0 && m2_map>=0)



begin
accumulator1[b1_map][m2_map]= accumulator1[b1_map][m2_map] + 1;
end

if(b2_map<=20 && m2_map<=20 && b2_map>=0 && m2_map>=0)

begin
accumulator2[b2_map][m2_map]= accumulator2[b2_map][m2_map] + 1;
end

//accumulator1  & accumulator2 are 2d registers mapped like 2d arrays

So, In this case I want the data to be mapped only if it is in the specified limits. Will a latch be inferred because there is no "else" scenario defined? I didn't add an else statement because there is nothing I want to do with that data if it's not in the limits.

推荐答案

If you write your if statements correctly, you will be fine. Latches are generated when there are paths through the if statement that do not update one or more of the outputs. Code like the following will generate a latch:

always @* begin
    if (a) begin
        b <= c & d;
        e <= f;
    end else begin
        b <= c | d;
    end
end

Notice that e is assigned only when a is true? This requires a latch to implement correctly.

Another posibility that will generate a latch is when the sensitivity list does not contain a signal used in the code.

always @(a) begin
    if (a) begin
        b <= c & d;
    end else begin
        b <= c | d;
    end
end

This code will generate latches on c and d or on b because it will only allow b to be updated when a changes.

其他推荐答案

You've misunderstood your problem (and you shouldn't have accepted an answer) - the issue isn't fundamentally related to 'latches'. Your code doesn't make sense (for synthesis). Quartus knows this, and it's basically telling you to rewrite your code.

You've got a combinatorial block that increments a number (immediately) when a signal changes. Two problems: (1) this is certainly not what you want in real hardware, and (2) the number must remain the same, and not increment, when b1 and b2 don't change. The second isue is the one Quartus is reporting - your circuit needs memory of some sort, which it's reporting as a 'latch'. It's not smart enough to report the first problem, which is the real issue.

Try to draw your circuit as a schematic with real hardware. What does 'any change on b1 or b2' actually mean? How are you going to maintain the value of the accumulators when b1 and b2 don't change? The circuit isn't impossible, but it's way beyond an SO question.

Make you circuit synchronous, triggering on a clock edge, with only a clock (and possibly a reset) in the sensitivity list, and keep the innards exactly the same. There's nothing wrong with your if statement, since you actually want the accumulator to remain unchanged if nothing interesting is happening on b1/b2.

其他推荐答案

Inferred latches can come from an incomplete sensitivity list or incomplete assignments.

Sensitivity lists for combinatorial blocks should generally be written with always @*. This avoid coding bugs when updating code. Combinatorial blocks (those not including an edge sensitivity) are once synthesised will perform in the manner of always @*. Specifically naming signals adds more work and will likely lead to RTL to gate level (post synthesis) errors.

Incomplete assignments which imply the value has to be held will infer a latch. Latches are not inherently bad but require careful consideration. Inferred one in this manner removes the thought fullness and control you would otherwise have over it. This can lead to complex timing issues. As the latch is level sensitive rather than edge sensitive. Ideally you want the latch to be open for the first have of the clock cycle so that it is closed when the data will be read from it. Inferred latches remove this control.

Completing if statements with an else, of default for case castanets which sets a sensible value (0's) can help avoid these accidental latches.