Is this a synthesizable code?

[nicety]

I am in the process of analyzing the code given to me. Is the following
always construct synchronous or not? What change should I make to the
code to make it work correctly? Thanx in advance.
The code and the warning is as follows.

always @(REclk or circ_queue_empty or RE_nRESET)
begin
if(~RE_nRESET)
InWAIT <= 1'b1;
else if((circ_queue_empty == 1'b0) && (REclk == 1'b1))
InWAIT <= 1'b1;
else if((circ_queue_empty == 1'b1) && (REclk == 1'b0))
InWAIT <= 1'b0;
end

Warning: Verilog HDL Always Construct warning at Dbeq.v(89): variable
"InWAIT" may not be assigned a new value in every possible path through
the Always Construct. Variable "InWAIT" holds its previous value in
every path with no new value assignment, which may create a
combinational loop in the current design.

 

[hisaikrishna@gmail.com]

I think, the always construct's sensitivity list needs to be changed to
work the always block in synchronous to the clock.Use posedge or
negedge in sensitivity lists inorder to instantiate "InWait" as
registered output depending on the asynchronous inputs

 

[Art Stamness]

The error is telling you that it thinks that this should be a wire
because of coding style .It expects there to be a final else, so that
this can be combinational ( read the output is fully dependent on
inputs, not previous state). This is not true in this case, because
what you are describing is a very funky latch.

The latch allows the output to be set, during the high phase on
circ_queue_empty == 0, and be cleared on the low phase when that signal
== 1 . It is also asynchronously cleared by active low RE_nRESET.
Basically this sounds really really wrong, and unlike any latch I have
seen! You may be able to implement this with some type of S/R latch and
some combinational logic, but the description provided clearly doesn't
help the compiler figure out which type of device to use.

You may be able to write up a UDP that describes this behavior, and it
may be better interpreted by the compiler. But frankly, it just looks
like bad code. Find who wrote it and ask them what they intended, is
always the best solution.

-Art

 

[William L. Bahn]

"nicety" <nicety@innosign.co.kr> wrote in message
news:1127801251.209992.240350@g14g2000cwa.googlegroups.com...

I am in the process of analyzing the code given to me. Is the
following
always construct synchronous or not? What change should I make
to the
code to make it work correctly? Thanx in advance.
The code and the warning is as follows.

always @(REclk or circ_queue_empty or RE_nRESET)
begin
if(~RE_nRESET)
InWAIT <= 1'b1;
else if((circ_queue_empty == 1'b0) && (REclk == 1'b1))
InWAIT <= 1'b1;
else if((circ_queue_empty == 1'b1) && (REclk == 1'b0))
InWAIT <= 1'b0;
end

Warning: Verilog HDL Always Construct warning at Dbeq.v(89):
variable
"InWAIT" may not be assigned a new value in every possible path
through
the Always Construct. Variable "InWAIT" holds its previous
value in
every path with no new value assignment, which may create a
combinational loop in the current design.

One way to answer this question is to ask yourself what signal it
can possibly be synchronous with? There are three signals in the
sensitivity list and for each one you can choose appropriate
states for those three signals such that InWAIT changes as soon
as soon as that input changes. Hence it is very much not
synchronous.

You should use the posedge or negedge keyword if you want changes
to be synchronous to a clock.

A bigger problem (and this is what the warning is getting at) is
that you do not specify the value of InWAIT for all combinations
of the input signals. This means that a latch must be inferred.
But the basic construct you are using is generally used to
indicate a combinatorial construct and if the synthesis tool
isn't smart enough you can end up with the output signal being
fed back to the input without a latch which can result in very
errant behavior.

Are you sure you know what the code is *supposed* to do
(independent of what it may *actually* do). If not, you would
probably be well advised to find out what the required behavior
is instead of trying to back it out from the code. Once you have
that, then you can better see where this code deviates from it
(which I'm willing to bet it does).

 

[nicety]

Thank you for the good advices. There are lots of weird codes like
above. I need to fix them all asap. The dev board is Altera Stratix II
with PXA 255 board.