Mixing
Use of “hanging” latches in combinational always blocks
We have a designer here that has assigned a temporary result to a variable in a combinational always block in order to improve readability. His code looks similar to this:
logic second_condition;
always_comb begin
if (condition) begin
second_condition = long_statement;
if (second_condition) begin
(...)
end
end
end
The problem here is that second_condition arguably describes a latch, but since this latch has no load (it's not used in any other always block), it is optimized away, and there is no warning about latches being inferred during synthesis. Some tool vendors seem to call this a "hanging latch". Notably a loop iterator can also be considered a hanging latch.
Is this something that is completely safe with all tools, or is it worth having a coding guideline never to do this? In this case you could just add an assignment to zero in the top of the always_comb block to remove the "hanging latch".
verilog system-verilog
asked Jan 2 at 17:49
pc3epc3e
799612
add a comment |
We have a designer here that has assigned a temporary result to a variable in a combinational always block in order to improve readability. His code looks similar to this:
logic second_condition;
always_comb begin
if (condition) begin
second_condition = long_statement;
if (second_condition) begin
(...)
end
end
end
The problem here is that second_condition arguably describes a latch, but since this latch has no load (it's not used in any other always block), it is optimized away, and there is no warning about latches being inferred during synthesis. Some tool vendors seem to call this a "hanging latch". Notably a loop iterator can also be considered a hanging latch.
Is this something that is completely safe with all tools, or is it worth having a coding guideline never to do this? In this case you could just add an assignment to zero in the top of the always_comb block to remove the "hanging latch".
verilog system-verilog
asked Jan 2 at 17:49
pc3epc3e
799612
3
I have used it, although rarely, in ASIC designs without any adverse effects. Nowadays I prefer to make it an independent 'assign' outside the always which works in the same way but does not have the implied 'latch threat'.
– Oldfart
Jan 2 at 18:04
2
Seems like a gamble to me. Even if it's 'safe' today... doesn't mean an issue won't pop up someday as tools get updated, new tools come along etc.
– ajcrm125
Jan 2 at 18:29
For the sake of maintainability, I would recommend never using code if it isn't completely clear what will be produced by the synthesis engine. If statements without either an else statement or a default declaration of output values prior to the if statement describe a latch. Depending on the synthesis engine to override what you've written on the basis of the always_comb is a bad idea. Plus what happens if someone needs to convert this code back to regular Verilog at some point? (For example, Xilinx's Vivado tool still can't use SV for the top level of custom IP blocks).
– Barry Moss
Jan 3 at 20:03
add a comment |
We have a designer here that has assigned a temporary result to a variable in a combinational always block in order to improve readability. His code looks similar to this:
logic second_condition;
always_comb begin
if (condition) begin
second_condition = long_statement;
if (second_condition) begin
(...)
end
end
end
The problem here is that second_condition arguably describes a latch, but since this latch has no load (it's not used in any other always block), it is optimized away, and there is no warning about latches being inferred during synthesis. Some tool vendors seem to call this a "hanging latch". Notably a loop iterator can also be considered a hanging latch.
Is this something that is completely safe with all tools, or is it worth having a coding guideline never to do this? In this case you could just add an assignment to zero in the top of the always_comb block to remove the "hanging latch".
verilog system-verilog
asked Jan 2 at 17:49
pc3epc3e
799612
We have a designer here that has assigned a temporary result to a variable in a combinational always block in order to improve readability. His code looks similar to this:
logic second_condition;
always_comb begin
if (condition) begin
second_condition = long_statement;
if (second_condition) begin
(...)
end
end
end
The problem here is that second_condition arguably describes a latch, but since this latch has no load (it's not used in any other always block), it is optimized away, and there is no warning about latches being inferred during synthesis. Some tool vendors seem to call this a "hanging latch". Notably a loop iterator can also be considered a hanging latch.
Is this something that is completely safe with all tools, or is it worth having a coding guideline never to do this? In this case you could just add an assignment to zero in the top of the always_comb block to remove the "hanging latch".
verilog system-verilog
verilog system-verilog
asked Jan 2 at 17:49
pc3epc3e
799612
asked Jan 2 at 17:49
pc3epc3e
799612
edited Jan 2 at 18:07
pc3e
asked Jan 2 at 17:49
pc3epc3e
799612
asked Jan 2 at 17:49
pc3epc3e
799612
asked Jan 2 at 17:49
pc3epc3e
799612
799612
3
I have used it, although rarely, in ASIC designs without any adverse effects. Nowadays I prefer to make it an independent 'assign' outside the always which works in the same way but does not have the implied 'latch threat'.
– Oldfart
Jan 2 at 18:04
2
Seems like a gamble to me. Even if it's 'safe' today... doesn't mean an issue won't pop up someday as tools get updated, new tools come along etc.
– ajcrm125
Jan 2 at 18:29
For the sake of maintainability, I would recommend never using code if it isn't completely clear what will be produced by the synthesis engine. If statements without either an else statement or a default declaration of output values prior to the if statement describe a latch. Depending on the synthesis engine to override what you've written on the basis of the always_comb is a bad idea. Plus what happens if someone needs to convert this code back to regular Verilog at some point? (For example, Xilinx's Vivado tool still can't use SV for the top level of custom IP blocks).
– Barry Moss
Jan 3 at 20:03
add a comment |
3
I have used it, although rarely, in ASIC designs without any adverse effects. Nowadays I prefer to make it an independent 'assign' outside the always which works in the same way but does not have the implied 'latch threat'.
– Oldfart
Jan 2 at 18:04
2
Seems like a gamble to me. Even if it's 'safe' today... doesn't mean an issue won't pop up someday as tools get updated, new tools come along etc.
– ajcrm125
Jan 2 at 18:29
For the sake of maintainability, I would recommend never using code if it isn't completely clear what will be produced by the synthesis engine. If statements without either an else statement or a default declaration of output values prior to the if statement describe a latch. Depending on the synthesis engine to override what you've written on the basis of the always_comb is a bad idea. Plus what happens if someone needs to convert this code back to regular Verilog at some point? (For example, Xilinx's Vivado tool still can't use SV for the top level of custom IP blocks).
– Barry Moss
Jan 3 at 20:03
3
3
I have used it, although rarely, in ASIC designs without any adverse effects. Nowadays I prefer to make it an independent 'assign' outside the always which works in the same way but does not have the implied 'latch threat'.
– Oldfart
Jan 2 at 18:04
I have used it, although rarely, in ASIC designs without any adverse effects. Nowadays I prefer to make it an independent 'assign' outside the always which works in the same way but does not have the implied 'latch threat'.
– Oldfart
Jan 2 at 18:04
2
2
Seems like a gamble to me. Even if it's 'safe' today... doesn't mean an issue won't pop up someday as tools get updated, new tools come along etc.
– ajcrm125
Jan 2 at 18:29
Seems like a gamble to me. Even if it's 'safe' today... doesn't mean an issue won't pop up someday as tools get updated, new tools come along etc.
– ajcrm125
Jan 2 at 18:29
For the sake of maintainability, I would recommend never using code if it isn't completely clear what will be produced by the synthesis engine. If statements without either an else statement or a default declaration of output values prior to the if statement describe a latch. Depending on the synthesis engine to override what you've written on the basis of the always_comb is a bad idea. Plus what happens if someone needs to convert this code back to regular Verilog at some point? (For example, Xilinx's Vivado tool still can't use SV for the top level of custom IP blocks).
– Barry Moss
Jan 3 at 20:03
For the sake of maintainability, I would recommend never using code if it isn't completely clear what will be produced by the synthesis engine. If statements without either an else statement or a default declaration of output values prior to the if statement describe a latch. Depending on the synthesis engine to override what you've written on the basis of the always_comb is a bad idea. Plus what happens if someone needs to convert this code back to regular Verilog at some point? (For example, Xilinx's Vivado tool still can't use SV for the top level of custom IP blocks).
– Barry Moss
Jan 3 at 20:03
add a comment |
2 Answers
2
active
oldest
votes
In your code you are creating a latch with condition & second_condition. None of those define the latch load. The load is applied to somewhere inside (...) which you forgot to specify.
always_comb is a contract with system verilog and it is supposed to guarantee that there is no latch in the block. Any SV compiler should error-out if it sees this code. Check your log file, might have warnings instead. Should be an error.
if you need latches, use always_latch instead.
If you worry about the temp variable, synthesizer should optimize it away (if it is a good synthesizer :-)).
answered Jan 2 at 21:17
SergeSerge
4,12221016
I believe you have misunderstood the question. The "hanging latch" in question is thesecond_conditionvariable itself. Variable assignments inside the(...)part are always driven somehow (e.g., through an else clause of the outer if statement), even though I'm not showing this in the code example.
– pc3e
Jan 2 at 22:05
the question was about a temporary result to a variable in a combinational always block. This is an incorrect concept in the first place. there should be no latch at all. You probably need to ask a different question then.
– Serge
Jan 2 at 22:10
Design Compiler does produce a loadless latch (and a "latch inferred" warning) if you turn off optimizations. It does not produce any warnings with the default settings. The concern is that some other tool that our customers use might. It sounds like your opinion is that this should not be a concern, then?
– pc3e
Jan 2 at 22:30
1
this should be a concern, because this code will not be compilable by some tools, because of incorrect use of always_comb.
– Serge
Jan 2 at 22:56
add a comment |
Since second_condition is an intermediate signal that is completely contained within the always_comb block, declare it within the always_comb block.
always_comb begin
logic second_condition;
if (condition) begin
second_condition = long_statement;
if (second_condition) begin
(...)
end
end
end
Presto! No need to fear any pesky "hanging latches".
answered Jan 3 at 6:36
Unreasonable SinUnreasonable Sin
97
The issue isn't the declaration of the signal, but rather the fact that the behavior of second_condition describes a latch since a value isn't isn't always assigned to anything inside that second if statement.
– Barry Moss
Jan 3 at 19:59
Hi Barry. Note that in Serge's answer the OP stated that the outputs of interest in this always_comb block are always driven for all combination of inputs, and so it correctly describes combinational logic. The issue is that since second_condition is declared outside of the always_comb block, and is also driven from within the always_comb block, then it would initially be considered a latch, to be optimized away. By declaring second_condition within the always_comb block this should eliminate any synthesis warnings and is a good example of "declaring variables close to where they are used."
– Unreasonable Sin
Jan 3 at 21:29
@UnreasonableSin I think Barry might be right that this doesn't make any difference, but I have not had a chance to test it out. What it definitely does is to prevent any other blocks from reading the signal, so in this way it ensures no "real" latches are introduced. But I do think that if you instruct the tool to preservesecond_condition(or preserve everything), it still makes a latch.
– pc3e
Jan 4 at 15:29
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54010902%2fuse-of-hanging-latches-in-combinational-always-blocks%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
In your code you are creating a latch with condition & second_condition. None of those define the latch load. The load is applied to somewhere inside (...) which you forgot to specify.
always_comb is a contract with system verilog and it is supposed to guarantee that there is no latch in the block. Any SV compiler should error-out if it sees this code. Check your log file, might have warnings instead. Should be an error.
if you need latches, use always_latch instead.
If you worry about the temp variable, synthesizer should optimize it away (if it is a good synthesizer :-)).
answered Jan 2 at 21:17
SergeSerge
4,12221016
I believe you have misunderstood the question. The "hanging latch" in question is thesecond_conditionvariable itself. Variable assignments inside the(...)part are always driven somehow (e.g., through an else clause of the outer if statement), even though I'm not showing this in the code example.
– pc3e
Jan 2 at 22:05
the question was about a temporary result to a variable in a combinational always block. This is an incorrect concept in the first place. there should be no latch at all. You probably need to ask a different question then.
– Serge
Jan 2 at 22:10
Design Compiler does produce a loadless latch (and a "latch inferred" warning) if you turn off optimizations. It does not produce any warnings with the default settings. The concern is that some other tool that our customers use might. It sounds like your opinion is that this should not be a concern, then?
– pc3e
Jan 2 at 22:30
1
this should be a concern, because this code will not be compilable by some tools, because of incorrect use of always_comb.
– Serge
Jan 2 at 22:56
add a comment |
In your code you are creating a latch with condition & second_condition. None of those define the latch load. The load is applied to somewhere inside (...) which you forgot to specify.
always_comb is a contract with system verilog and it is supposed to guarantee that there is no latch in the block. Any SV compiler should error-out if it sees this code. Check your log file, might have warnings instead. Should be an error.
if you need latches, use always_latch instead.
If you worry about the temp variable, synthesizer should optimize it away (if it is a good synthesizer :-)).
answered Jan 2 at 21:17
SergeSerge
4,12221016
I believe you have misunderstood the question. The "hanging latch" in question is thesecond_conditionvariable itself. Variable assignments inside the(...)part are always driven somehow (e.g., through an else clause of the outer if statement), even though I'm not showing this in the code example.
– pc3e
Jan 2 at 22:05
the question was about a temporary result to a variable in a combinational always block. This is an incorrect concept in the first place. there should be no latch at all. You probably need to ask a different question then.
– Serge
Jan 2 at 22:10
Design Compiler does produce a loadless latch (and a "latch inferred" warning) if you turn off optimizations. It does not produce any warnings with the default settings. The concern is that some other tool that our customers use might. It sounds like your opinion is that this should not be a concern, then?
– pc3e
Jan 2 at 22:30
1
this should be a concern, because this code will not be compilable by some tools, because of incorrect use of always_comb.
– Serge
Jan 2 at 22:56
add a comment |
In your code you are creating a latch with condition & second_condition. None of those define the latch load. The load is applied to somewhere inside (...) which you forgot to specify.
always_comb is a contract with system verilog and it is supposed to guarantee that there is no latch in the block. Any SV compiler should error-out if it sees this code. Check your log file, might have warnings instead. Should be an error.
if you need latches, use always_latch instead.
If you worry about the temp variable, synthesizer should optimize it away (if it is a good synthesizer :-)).
answered Jan 2 at 21:17
SergeSerge
4,12221016
In your code you are creating a latch with condition & second_condition. None of those define the latch load. The load is applied to somewhere inside (...) which you forgot to specify.
always_comb is a contract with system verilog and it is supposed to guarantee that there is no latch in the block. Any SV compiler should error-out if it sees this code. Check your log file, might have warnings instead. Should be an error.
if you need latches, use always_latch instead.
If you worry about the temp variable, synthesizer should optimize it away (if it is a good synthesizer :-)).
answered Jan 2 at 21:17
SergeSerge
4,12221016
answered Jan 2 at 21:17
SergeSerge
4,12221016
answered Jan 2 at 21:17
SergeSerge
4,12221016
answered Jan 2 at 21:17
SergeSerge
4,12221016
4,12221016
I believe you have misunderstood the question. The "hanging latch" in question is thesecond_conditionvariable itself. Variable assignments inside the(...)part are always driven somehow (e.g., through an else clause of the outer if statement), even though I'm not showing this in the code example.
– pc3e
Jan 2 at 22:05
the question was about a temporary result to a variable in a combinational always block. This is an incorrect concept in the first place. there should be no latch at all. You probably need to ask a different question then.
– Serge
Jan 2 at 22:10
Design Compiler does produce a loadless latch (and a "latch inferred" warning) if you turn off optimizations. It does not produce any warnings with the default settings. The concern is that some other tool that our customers use might. It sounds like your opinion is that this should not be a concern, then?
– pc3e
Jan 2 at 22:30
1
this should be a concern, because this code will not be compilable by some tools, because of incorrect use of always_comb.
– Serge
Jan 2 at 22:56
add a comment |
I believe you have misunderstood the question. The "hanging latch" in question is thesecond_conditionvariable itself. Variable assignments inside the(...)part are always driven somehow (e.g., through an else clause of the outer if statement), even though I'm not showing this in the code example.
– pc3e
Jan 2 at 22:05
the question was about a temporary result to a variable in a combinational always block. This is an incorrect concept in the first place. there should be no latch at all. You probably need to ask a different question then.
– Serge
Jan 2 at 22:10
Design Compiler does produce a loadless latch (and a "latch inferred" warning) if you turn off optimizations. It does not produce any warnings with the default settings. The concern is that some other tool that our customers use might. It sounds like your opinion is that this should not be a concern, then?
– pc3e
Jan 2 at 22:30
1
this should be a concern, because this code will not be compilable by some tools, because of incorrect use of always_comb.
– Serge
Jan 2 at 22:56
I believe you have misunderstood the question. The "hanging latch" in question is the
second_condition variable itself. Variable assignments inside the (...) part are always driven somehow (e.g., through an else clause of the outer if statement), even though I'm not showing this in the code example.– pc3e
Jan 2 at 22:05
I believe you have misunderstood the question. The "hanging latch" in question is the
second_condition variable itself. Variable assignments inside the (...) part are always driven somehow (e.g., through an else clause of the outer if statement), even though I'm not showing this in the code example.– pc3e
Jan 2 at 22:05
the question was about a temporary result to a variable in a combinational always block. This is an incorrect concept in the first place. there should be no latch at all. You probably need to ask a different question then.
– Serge
Jan 2 at 22:10
the question was about a temporary result to a variable in a combinational always block. This is an incorrect concept in the first place. there should be no latch at all. You probably need to ask a different question then.
– Serge
Jan 2 at 22:10
Design Compiler does produce a loadless latch (and a "latch inferred" warning) if you turn off optimizations. It does not produce any warnings with the default settings. The concern is that some other tool that our customers use might. It sounds like your opinion is that this should not be a concern, then?
– pc3e
Jan 2 at 22:30
Design Compiler does produce a loadless latch (and a "latch inferred" warning) if you turn off optimizations. It does not produce any warnings with the default settings. The concern is that some other tool that our customers use might. It sounds like your opinion is that this should not be a concern, then?
– pc3e
Jan 2 at 22:30
1
1
this should be a concern, because this code will not be compilable by some tools, because of incorrect use of always_comb.
– Serge
Jan 2 at 22:56
this should be a concern, because this code will not be compilable by some tools, because of incorrect use of always_comb.
– Serge
Jan 2 at 22:56
add a comment |
Since second_condition is an intermediate signal that is completely contained within the always_comb block, declare it within the always_comb block.
always_comb begin
logic second_condition;
if (condition) begin
second_condition = long_statement;
if (second_condition) begin
(...)
end
end
end
Presto! No need to fear any pesky "hanging latches".
answered Jan 3 at 6:36
Unreasonable SinUnreasonable Sin
97
The issue isn't the declaration of the signal, but rather the fact that the behavior of second_condition describes a latch since a value isn't isn't always assigned to anything inside that second if statement.
– Barry Moss
Jan 3 at 19:59
Hi Barry. Note that in Serge's answer the OP stated that the outputs of interest in this always_comb block are always driven for all combination of inputs, and so it correctly describes combinational logic. The issue is that since second_condition is declared outside of the always_comb block, and is also driven from within the always_comb block, then it would initially be considered a latch, to be optimized away. By declaring second_condition within the always_comb block this should eliminate any synthesis warnings and is a good example of "declaring variables close to where they are used."
– Unreasonable Sin
Jan 3 at 21:29
@UnreasonableSin I think Barry might be right that this doesn't make any difference, but I have not had a chance to test it out. What it definitely does is to prevent any other blocks from reading the signal, so in this way it ensures no "real" latches are introduced. But I do think that if you instruct the tool to preservesecond_condition(or preserve everything), it still makes a latch.
– pc3e
Jan 4 at 15:29
add a comment |
Since second_condition is an intermediate signal that is completely contained within the always_comb block, declare it within the always_comb block.
always_comb begin
logic second_condition;
if (condition) begin
second_condition = long_statement;
if (second_condition) begin
(...)
end
end
end
Presto! No need to fear any pesky "hanging latches".
answered Jan 3 at 6:36
Unreasonable SinUnreasonable Sin
97
The issue isn't the declaration of the signal, but rather the fact that the behavior of second_condition describes a latch since a value isn't isn't always assigned to anything inside that second if statement.
– Barry Moss
Jan 3 at 19:59
Hi Barry. Note that in Serge's answer the OP stated that the outputs of interest in this always_comb block are always driven for all combination of inputs, and so it correctly describes combinational logic. The issue is that since second_condition is declared outside of the always_comb block, and is also driven from within the always_comb block, then it would initially be considered a latch, to be optimized away. By declaring second_condition within the always_comb block this should eliminate any synthesis warnings and is a good example of "declaring variables close to where they are used."
– Unreasonable Sin
Jan 3 at 21:29
@UnreasonableSin I think Barry might be right that this doesn't make any difference, but I have not had a chance to test it out. What it definitely does is to prevent any other blocks from reading the signal, so in this way it ensures no "real" latches are introduced. But I do think that if you instruct the tool to preservesecond_condition(or preserve everything), it still makes a latch.
– pc3e
Jan 4 at 15:29
add a comment |
Since second_condition is an intermediate signal that is completely contained within the always_comb block, declare it within the always_comb block.
always_comb begin
logic second_condition;
if (condition) begin
second_condition = long_statement;
if (second_condition) begin
(...)
end
end
end
Presto! No need to fear any pesky "hanging latches".
answered Jan 3 at 6:36
Unreasonable SinUnreasonable Sin
97
Since second_condition is an intermediate signal that is completely contained within the always_comb block, declare it within the always_comb block.
always_comb begin
logic second_condition;
if (condition) begin
second_condition = long_statement;
if (second_condition) begin
(...)
end
end
end
Presto! No need to fear any pesky "hanging latches".
answered Jan 3 at 6:36
Unreasonable SinUnreasonable Sin
97
answered Jan 3 at 6:36
Unreasonable SinUnreasonable Sin
97
answered Jan 3 at 6:36
Unreasonable SinUnreasonable Sin
97
answered Jan 3 at 6:36
Unreasonable SinUnreasonable Sin
97
97
The issue isn't the declaration of the signal, but rather the fact that the behavior of second_condition describes a latch since a value isn't isn't always assigned to anything inside that second if statement.
– Barry Moss
Jan 3 at 19:59
Hi Barry. Note that in Serge's answer the OP stated that the outputs of interest in this always_comb block are always driven for all combination of inputs, and so it correctly describes combinational logic. The issue is that since second_condition is declared outside of the always_comb block, and is also driven from within the always_comb block, then it would initially be considered a latch, to be optimized away. By declaring second_condition within the always_comb block this should eliminate any synthesis warnings and is a good example of "declaring variables close to where they are used."
– Unreasonable Sin
Jan 3 at 21:29
@UnreasonableSin I think Barry might be right that this doesn't make any difference, but I have not had a chance to test it out. What it definitely does is to prevent any other blocks from reading the signal, so in this way it ensures no "real" latches are introduced. But I do think that if you instruct the tool to preservesecond_condition(or preserve everything), it still makes a latch.
– pc3e
Jan 4 at 15:29
add a comment |
The issue isn't the declaration of the signal, but rather the fact that the behavior of second_condition describes a latch since a value isn't isn't always assigned to anything inside that second if statement.
– Barry Moss
Jan 3 at 19:59
Hi Barry. Note that in Serge's answer the OP stated that the outputs of interest in this always_comb block are always driven for all combination of inputs, and so it correctly describes combinational logic. The issue is that since second_condition is declared outside of the always_comb block, and is also driven from within the always_comb block, then it would initially be considered a latch, to be optimized away. By declaring second_condition within the always_comb block this should eliminate any synthesis warnings and is a good example of "declaring variables close to where they are used."
– Unreasonable Sin
Jan 3 at 21:29
@UnreasonableSin I think Barry might be right that this doesn't make any difference, but I have not had a chance to test it out. What it definitely does is to prevent any other blocks from reading the signal, so in this way it ensures no "real" latches are introduced. But I do think that if you instruct the tool to preservesecond_condition(or preserve everything), it still makes a latch.
– pc3e
Jan 4 at 15:29
The issue isn't the declaration of the signal, but rather the fact that the behavior of second_condition describes a latch since a value isn't isn't always assigned to anything inside that second if statement.
– Barry Moss
Jan 3 at 19:59
The issue isn't the declaration of the signal, but rather the fact that the behavior of second_condition describes a latch since a value isn't isn't always assigned to anything inside that second if statement.
– Barry Moss
Jan 3 at 19:59
Hi Barry. Note that in Serge's answer the OP stated that the outputs of interest in this always_comb block are always driven for all combination of inputs, and so it correctly describes combinational logic. The issue is that since second_condition is declared outside of the always_comb block, and is also driven from within the always_comb block, then it would initially be considered a latch, to be optimized away. By declaring second_condition within the always_comb block this should eliminate any synthesis warnings and is a good example of "declaring variables close to where they are used."
– Unreasonable Sin
Jan 3 at 21:29
Hi Barry. Note that in Serge's answer the OP stated that the outputs of interest in this always_comb block are always driven for all combination of inputs, and so it correctly describes combinational logic. The issue is that since second_condition is declared outside of the always_comb block, and is also driven from within the always_comb block, then it would initially be considered a latch, to be optimized away. By declaring second_condition within the always_comb block this should eliminate any synthesis warnings and is a good example of "declaring variables close to where they are used."
– Unreasonable Sin
Jan 3 at 21:29
@UnreasonableSin I think Barry might be right that this doesn't make any difference, but I have not had a chance to test it out. What it definitely does is to prevent any other blocks from reading the signal, so in this way it ensures no "real" latches are introduced. But I do think that if you instruct the tool to preserve
second_condition (or preserve everything), it still makes a latch.– pc3e
Jan 4 at 15:29
@UnreasonableSin I think Barry might be right that this doesn't make any difference, but I have not had a chance to test it out. What it definitely does is to prevent any other blocks from reading the signal, so in this way it ensures no "real" latches are introduced. But I do think that if you instruct the tool to preserve
second_condition (or preserve everything), it still makes a latch.– pc3e
Jan 4 at 15:29
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54010902%2fuse-of-hanging-latches-in-combinational-always-blocks%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
I have used it, although rarely, in ASIC designs without any adverse effects. Nowadays I prefer to make it an independent 'assign' outside the always which works in the same way but does not have the implied 'latch threat'.
– Oldfart
Jan 2 at 18:04
2
Seems like a gamble to me. Even if it's 'safe' today... doesn't mean an issue won't pop up someday as tools get updated, new tools come along etc.
– ajcrm125
Jan 2 at 18:29
For the sake of maintainability, I would recommend never using code if it isn't completely clear what will be produced by the synthesis engine. If statements without either an else statement or a default declaration of output values prior to the if statement describe a latch. Depending on the synthesis engine to override what you've written on the basis of the always_comb is a bad idea. Plus what happens if someone needs to convert this code back to regular Verilog at some point? (For example, Xilinx's Vivado tool still can't use SV for the top level of custom IP blocks).
– Barry Moss
Jan 3 at 20:03