"Latch generated" warning from Synplicity

K

kb33

Guest
Hi,

I have matched all the if-else statements in the following code, but
cannot get rid of the warnings for all the array elements:

"Latch generated from always block for signal array1_comb[1][15][7:0],
probably caused by a missing assignment in an if or case stmt"
....and so on for the others as well.

The code (with some missing I/O definitions) is:




reg [`DATA_SZ-1:0] array1 [0:`NUM_RSRC-1][0:`NUM_ATTRIB-1],
array1_comb [0:`NUM_RSRC-1]
[0:`NUM_ATTRIB-1];



always @(posedge sys_clk)
begin
for (i = 0; i < `NUM_RSRC; i = i+1)
for (j=0; j < `NUM_ATTRIB; j=j+1)
array1 [j] <= #1 array1_comb [j];
end


//array1_comb...
always @(reset_n, match_state, curr_attrib, rsrc_id, data_in)
begin
if (~reset_n)
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= 0;

else if (match_state == `RECORD_RSRC)
begin
for (k = 0; k < `NUM_RSRC; k = k+1)
if (k == rsrc_id)
for (l=0; l < `NUM_ATTRIB; l=l+1)
if (l == curr_attrib)
array1_comb [k][l] <= data_in;
else
array1_comb [k][l] <= array1 [k][l];
else
array1_comb [k][l] <= array1 [k][l];
end

else
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= array1 [k][l];
end // always @ (reset_n, match_state, curr_attrib, rsrc_id,
data_in)
 
On Sep 12, 10:50 am, kb33 <kanchan.devarako...@gmail.com> wrote:
Hi,

I have matched all the if-else statements in the following code, but
cannot get rid of the warnings for all the array elements:

"Latch generated from always block for signal array1_comb[1][15][7:0],
probably caused by a missing assignment in an if or case stmt"
...and so on for the others as well.

The code (with some missing I/O definitions) is:

reg [`DATA_SZ-1:0] array1 [0:`NUM_RSRC-1][0:`NUM_ATTRIB-1],
array1_comb [0:`NUM_RSRC-1]
[0:`NUM_ATTRIB-1];

always @(posedge sys_clk)
begin
for (i = 0; i < `NUM_RSRC; i = i+1)
for (j=0; j < `NUM_ATTRIB; j=j+1)
array1 [j] <= #1 array1_comb [j];
end

//array1_comb...
always @(reset_n, match_state, curr_attrib, rsrc_id, data_in)
begin
if (~reset_n)
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= 0;

else if (match_state == `RECORD_RSRC)
begin
for (k = 0; k < `NUM_RSRC; k = k+1)
if (k == rsrc_id)
for (l=0; l < `NUM_ATTRIB; l=l+1)
if (l == curr_attrib)
array1_comb [k][l] <= data_in;
else
array1_comb [k][l] <= array1 [k][l];
else
array1_comb [k][l] <= array1 [k][l];
end

else
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= array1 [k][l];
end // always @ (reset_n, match_state, curr_attrib, rsrc_id,
data_in)
Click to expand...

Since arrayl is not in the sensitivity list, I suspect this may be
causing the
latch warning.

John Providenza
 
"kb33" <kanchan.devarakonda@gmail.com> wrote in message
news:1189619456.778753.92100@y42g2000hsy.googlegroups.com...
Hi,

I have matched all the if-else statements in the following code, but
cannot get rid of the warnings for all the array elements:

"Latch generated from always block for signal array1_comb[1][15][7:0],
probably caused by a missing assignment in an if or case stmt"
...and so on for the others as well.

The code (with some missing I/O definitions) is:




reg [`DATA_SZ-1:0] array1 [0:`NUM_RSRC-1][0:`NUM_ATTRIB-1],
array1_comb [0:`NUM_RSRC-1]
[0:`NUM_ATTRIB-1];



always @(posedge sys_clk)
begin
for (i = 0; i < `NUM_RSRC; i = i+1)
for (j=0; j < `NUM_ATTRIB; j=j+1)
array1 [j] <= #1 array1_comb [j];
end


//array1_comb...
always @(reset_n, match_state, curr_attrib, rsrc_id, data_in)
begin
if (~reset_n)
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= 0;

else if (match_state == `RECORD_RSRC)
begin
for (k = 0; k < `NUM_RSRC; k = k+1)
if (k == rsrc_id)
for (l=0; l < `NUM_ATTRIB; l=l+1)
if (l == curr_attrib)
array1_comb [k][l] <= data_in;
else
array1_comb [k][l] <= array1 [k][l];
else
array1_comb [k][l] <= array1 [k][l];
end

else
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= array1 [k][l];
end // always @ (reset_n, match_state, curr_attrib, rsrc_id,
data_in)
Click to expand...

I don't see a"default" setting for array1_comb.

Also .. its a combinatorial always block .. so I'm not liking the <= part ..
this won't cause your latch though.

The most likely reason for a latch in a combinatorial always block is a
missing default condition.

Mike
 
"kb33" <kanchan.devarakonda@gmail.com> wrote in message
news:1189619456.778753.92100@y42g2000hsy.googlegroups.com...
Hi,

I have matched all the if-else statements in the following code, but
cannot get rid of the warnings for all the array elements:

"Latch generated from always block for signal array1_comb[1][15][7:0],
probably caused by a missing assignment in an if or case stmt"
...and so on for the others as well.

The code (with some missing I/O definitions) is:




reg [`DATA_SZ-1:0] array1 [0:`NUM_RSRC-1][0:`NUM_ATTRIB-1],
array1_comb [0:`NUM_RSRC-1]
[0:`NUM_ATTRIB-1];



always @(posedge sys_clk)
begin
for (i = 0; i < `NUM_RSRC; i = i+1)
for (j=0; j < `NUM_ATTRIB; j=j+1)
array1 [j] <= #1 array1_comb [j];
end


//array1_comb...
always @(reset_n, match_state, curr_attrib, rsrc_id, data_in)
begin
if (~reset_n)
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= 0;

else if (match_state == `RECORD_RSRC)
begin
for (k = 0; k < `NUM_RSRC; k = k+1)
if (k == rsrc_id)
for (l=0; l < `NUM_ATTRIB; l=l+1)
if (l == curr_attrib)
array1_comb [k][l] <= data_in;
else
array1_comb [k][l] <= array1 [k][l];
else
array1_comb [k][l] <= array1 [k][l];
end

else
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= array1 [k][l];
end // always @ (reset_n, match_state, curr_attrib, rsrc_id,
data_in)
Click to expand...

When "k is not rsrc_id", the line:

array1_comb[k][l] <= array1[k][l];

skips a lot of assignments as there isn't any inner
loop that scans the row by changing l.
 
On Sep 12, 4:12 pm, "Mike Lewis" <some...@micrsoft.com> wrote:
"kb33" <kanchan.devarako...@gmail.com> wrote in message

news:1189619456.778753.92100@y42g2000hsy.googlegroups.com...



Hi,

I have matched all the if-else statements in the following code, but
cannot get rid of the warnings for all the array elements:

"Latch generated from always block for signal array1_comb[1][15][7:0],
probably caused by a missing assignment in an if or case stmt"
...and so on for the others as well.

The code (with some missing I/O definitions) is:

reg [`DATA_SZ-1:0] array1 [0:`NUM_RSRC-1][0:`NUM_ATTRIB-1],
array1_comb [0:`NUM_RSRC-1]
[0:`NUM_ATTRIB-1];

always @(posedge sys_clk)
begin
for (i = 0; i < `NUM_RSRC; i = i+1)
for (j=0; j < `NUM_ATTRIB; j=j+1)
array1 [j] <= #1 array1_comb [j];
end

//array1_comb...
always @(reset_n, match_state, curr_attrib, rsrc_id, data_in)
begin
if (~reset_n)
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= 0;

else if (match_state == `RECORD_RSRC)
begin
for (k = 0; k < `NUM_RSRC; k = k+1)
if (k == rsrc_id)
for (l=0; l < `NUM_ATTRIB; l=l+1)
if (l == curr_attrib)
array1_comb [k][l] <= data_in;
else
array1_comb [k][l] <= array1 [k][l];
else
array1_comb [k][l] <= array1 [k][l];
end

else
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= array1 [k][l];
end // always @ (reset_n, match_state, curr_attrib, rsrc_id,
data_in)

I don't see a"default" setting for array1_comb.

Also .. its a combinatorial always block .. so I'm not liking the <= part ..
this won't cause your latch though.

The most likely reason for a latch in a combinatorial always block is a
missing default condition.

Mike
Click to expand...

Hi,
The last "else" denotes the default condition for the array1_comb
array. Also, if you see closely, the first always block is the
sequential logic, and the second always block is the combinational
block. I prefer to always keep the two apart, hence all the
combinational signals have a suffix of "comb". Moreover, I use non-
blocking assignments in all places to avoid issues after synthesis (my
logic is usually designed accordingly). Interestingly, I am getting
the same type of warning when I use a case statement that has the
default condition explicitly included. I am still confused. In
response to John's reply about not including the array1 signal in the
sensitivity list, I really don't know how to include that. I have
posed this question about including arrays in the sensitivity list in
this forum, but have yet to receive a convincing reply!

Thanks
Kanchan
 
"kb33" <kanchan.devarakonda@gmail.com> wrote in message
news:1189653482.754030.197360@d55g2000hsg.googlegroups.com...
On Sep 12, 4:12 pm, "Mike Lewis" <some...@micrsoft.com> wrote:
"kb33" <kanchan.devarako...@gmail.com> wrote in message

news:1189619456.778753.92100@y42g2000hsy.googlegroups.com...



Hi,

I have matched all the if-else statements in the following code, but
cannot get rid of the warnings for all the array elements:

"Latch generated from always block for signal array1_comb[1][15][7:0],
probably caused by a missing assignment in an if or case stmt"
...and so on for the others as well.

The code (with some missing I/O definitions) is:

reg [`DATA_SZ-1:0] array1 [0:`NUM_RSRC-1][0:`NUM_ATTRIB-1],
array1_comb [0:`NUM_RSRC-1]
[0:`NUM_ATTRIB-1];

always @(posedge sys_clk)
begin
for (i = 0; i < `NUM_RSRC; i = i+1)
for (j=0; j < `NUM_ATTRIB; j=j+1)
array1 [j] <= #1 array1_comb [j];
end

//array1_comb...
always @(reset_n, match_state, curr_attrib, rsrc_id, data_in)
begin
if (~reset_n)
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= 0;

else if (match_state == `RECORD_RSRC)
begin
for (k = 0; k < `NUM_RSRC; k = k+1)
if (k == rsrc_id)
for (l=0; l < `NUM_ATTRIB; l=l+1)
if (l == curr_attrib)
array1_comb [k][l] <= data_in;
else
array1_comb [k][l] <= array1 [k][l];
else
array1_comb [k][l] <= array1 [k][l];
end

else
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= array1 [k][l];
end // always @ (reset_n, match_state, curr_attrib, rsrc_id,
data_in)

I don't see a"default" setting for array1_comb.

Also .. its a combinatorial always block .. so I'm not liking the <=
part ..
this won't cause your latch though.

The most likely reason for a latch in a combinatorial always block is a
missing default condition.

Mike
Click to expand...



The last "else" denotes the default condition for the array1_comb
array.
Click to expand...
The "else" you talk about won't save you from latches.

Perhaps the concept behind "default condition" is better
expressed by "default assignment" or "default settings"
like Mike Lewis said.

If the "else" branch that you thought as default is never
executed whatever branch is executed in its place will find
no default assignment at all.
 
On Sep 14, 8:28 am, "devices" <me@home> wrote:
"kb33" <kanchan.devarako...@gmail.com> wrote in message

news:1189653482.754030.197360@d55g2000hsg.googlegroups.com...



On Sep 12, 4:12 pm, "Mike Lewis" <some...@micrsoft.com> wrote:
"kb33" <kanchan.devarako...@gmail.com> wrote in message

news:1189619456.778753.92100@y42g2000hsy.googlegroups.com...

Hi,

I have matched all the if-else statements in the following code, but
cannot get rid of the warnings for all the array elements:

"Latch generated from always block for signal array1_comb[1][15][7:0],
probably caused by a missing assignment in an if or case stmt"
...and so on for the others as well.

The code (with some missing I/O definitions) is:

reg [`DATA_SZ-1:0] array1 [0:`NUM_RSRC-1][0:`NUM_ATTRIB-1],
array1_comb [0:`NUM_RSRC-1]
[0:`NUM_ATTRIB-1];

always @(posedge sys_clk)
begin
for (i = 0; i < `NUM_RSRC; i = i+1)
for (j=0; j < `NUM_ATTRIB; j=j+1)
array1 [j] <= #1 array1_comb [j];
end

//array1_comb...
always @(reset_n, match_state, curr_attrib, rsrc_id, data_in)
begin
if (~reset_n)
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= 0;

else if (match_state == `RECORD_RSRC)
begin
for (k = 0; k < `NUM_RSRC; k = k+1)
if (k == rsrc_id)
for (l=0; l < `NUM_ATTRIB; l=l+1)
if (l == curr_attrib)
array1_comb [k][l] <= data_in;
else
array1_comb [k][l] <= array1 [k][l];
else
array1_comb [k][l] <= array1 [k][l];
end

else
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb [k][l] <= array1 [k][l];
end // always @ (reset_n, match_state, curr_attrib, rsrc_id,
data_in)

I don't see a"default" setting for array1_comb.

Also .. its a combinatorial always block .. so I'm not liking the <=
part ..
this won't cause your latch though.

The most likely reason for a latch in a combinatorial always block is a
missing default condition.

Mike
The last "else" denotes the default condition for the array1_comb
array.

The "else" you talk about won't save you from latches.

Perhaps the concept behind "default condition" is better
expressed by "default assignment" or "default settings"
like Mike Lewis said.

If the "else" branch that you thought as default is never
executed whatever branch is executed in its place will find
no default assignment at all.
Click to expand...

I am not sure I understand your point syntactically speaking, though
conceptually I see what you mean. All the array elements do have non-
ambiguous values, so why shouldn't an else statement at the end take
care of all other conditions? As I mentioned earlier, even an explicit
default statement in a case statement doesn't seem to solve the
problem. Also, I have observed that this situation arises when there
are loops involved (I may not be 100% correct, but it is my hunch..)

Thanks,
Kanchan
 
On Sep 14, 7:43 am, kb33 <kanchan.devarako...@gmail.com> wrote:
On Sep 14, 8:28 am, "devices" <me@home> wrote:

If the "else" branch that you thought as default is never
executed whatever branch is executed in its place will find
no default assignment at all.

...
All the array elements do have non-ambiguous values, so why
shouldn't an else statement at the end take
care of all other conditions?
...
Click to expand...
Kanchan - this is the problem - you THINK that you've unambiguously
assigned
all bits of array1_comb in all cases but you haven't. The synthesis
tool sees this, and is forced to generate a latch.

As "devices" mentioned in the other thread - you're missing
the "for 'l' loop" in the if( k != rsrc_id ) sub-clause.

Some coding style to insure you've always got a default condition
would be to first assign the default at the beginning of the loop
like below (and you should pay attention to Mike's comment on
blocking
assignment for combinational logic)

always @*
begin
for (k = 0; k < `NUM_RSRC; k = k+1)
for (l=0; l < `NUM_ATTRIB; l=l+1)
array1_comb = array1 [k][l];

// insert the reset of your logic here.
end

This way, you REALLY are unambiguously assigning to array1_comb in
every case. (Well, you'd need to insure you don't mess up the
for loop limits). You overwrite the default in your decode, but the
default is set up front.

The downside - the bug in your code (there is one!) would
need to be found through simulation - instead of this nice friendly
warning from your synthesis tool.

Regards,

Mark
 
Hi,
As "devices" mentioned in the other thread - you're missing
the "for 'l' loop" in the if( k != rsrc_id ) sub-clause.
Click to expand...
Thanks to "devices" and Mark...the culprit (for most of the cases
where I was getting the Latch warning) was the missing 'l' loop in the
if( k != rsrc_id ) sub-clause.

However, this discussion has raised some other questions for me:
1. Mike and Mark commented upon the use of non-blocking statements in
combinational blocks...is it wrong to do so? Wouldn't Synthesis
complain if I used blocking and non-blocking in the same verilog file?
Aren't the blocking-nonblocking issues governed more by how you want
the signals to behave rather than whether they are sequential or
combinational?


The downside - the bug in your code (there is one!) would
need to be found through simulation - instead of this nice friendly
warning from your synthesis tool.
Click to expand...
2. Mark, is this a specific bug you are talking about in the code, or
is it related to the style of coding? The simulations seem to be fine,
though.

Thanks,
Kanchan
 
On Sep 14, 11:27 am, kb33 <kanchan.devarako...@gmail.com> wrote:
However, this discussion has raised some other questions for me:
1. Mike and Mark commented upon the use of non-blocking statements in
combinational blocks...is it wrong to do so? Wouldn't Synthesis
complain if I used blocking and non-blocking in the same verilog file?
Aren't the blocking-nonblocking issues governed more by how you want
the signals to behave rather than whether they are sequential or
combinational?
Click to expand...
Thankfully, we've got a very good reference here.
Google: "Nonblocking Assignments in Verilog Synthesis, Coding
Styles That Kill" by Cliff Cummings.

Your answers to the above questions are answered in Cliff's
paper. If you want to deviate from Cliff's guidelines here
(which your code DOES), then you should do it with eyes
fully open as to the consequences. These specific guidelines
from Cliff are pretty much industry standard. Some folks
don't follow them but they do so in one of two cases:

1. They're a guru with detailed understanding of the
verilog stratified event queue, and have some kind
of other method of avoiding the pitfalls.
2. They're unaware, and are asking for trouble.

The downside - the bug in your code (there is one!) would
need to be found through simulation - instead of this nice friendly
warning from your synthesis tool.

2. Mark, is this a specific bug you are talking about in the code, or
is it related to the style of coding? The simulations seem to be fine,
though.
Click to expand...
I was referring to your missing "for" loop as the bug. The synthesis
tool told you about the bug with the "latch generated" warning.
If your simulation seemed fine with the bug, then your simulations
were probably inadequate. Well, you'd likely have a gate vs. rtl
mismatch,
since the latching logic generated would be highly weird, and not
explicity
matching the RTL behavior, I believe.

Regards,

Mark
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top