FPGA Central

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 [i][j] <= #1 array1_comb [i][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 <[email protected]> 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 [i][j] <= #1 array1_comb [i][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)

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

John Providenza

"kb33" <[email protected]> wrote in message
news:[email protected] ups.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 [i][j] <= #1 array1_comb [i][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

"kb33" <[email protected]> wrote in message
news:[email protected] ups.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 [i][j] <= #1 array1_comb [i][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)
>

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" <[email protected]> wrote:
> "kb33" <[email protected]> wrote in message
>
> news:[email protected] ups.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 [i][j] <= #1 array1_comb [i][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

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" <[email protected]> wrote in message
news:[email protected] oups.com...
> On Sep 12, 4:12 pm, "Mike Lewis" <[email protected]> wrote:
> > "kb33" <[email protected]> wrote in message
> >
> > news:[email protected] ups.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 [i][j] <= #1 array1_comb [i][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.

On Sep 14, 8:28 am, "devices" <me@home> wrote:
> "kb33" <[email protected]> wrote in message
>
> news:[email protected] oups.com...
>
>
>
> > On Sep 12, 4:12 pm, "Mike Lewis" <[email protected]> wrote:
> > > "kb33" <[email protected]> wrote in message
>
> > >news:[email protected] oups.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 [i][j] <= #1 array1_comb [i][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.

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 <[email protected]> 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?
> ...

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.
>

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.
>

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 <[email protected]> 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?

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.

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