Question about x = x + 1

Hello all
Can anyone tell me if I do x = x + 1 does this have to be inside
an 'always @ (clock edge)' block, for example,

always @ ( posedge CLK)
begin
x = x + 1;
end

always @ ( y )
begin
x = x + 1;
end

which 'always' is correct ?

 

[Ralf Hildebrandt]

nn schrieb:

Hello all
Can anyone tell me if I do x = x + 1 does this have to be inside
an 'always @ (clock edge)' block, for example,

always @ ( y )
begin
x = x + 1;
end

Synthesis tools "ignore" the sensitivity list. Therefore this would be
(AFAIK) equivalent to

assign x = x + 1;

Even if you modify your always block this way

always @ ( y )
begin
if ( y==1'b1 ) begin
x = x + 1;
end //if
end

This would lead to an infinite loop. Remember that as long as y is 1'b1
the addition would take place.

The solution is: x has to be a flipflop triggered by the edge of some
signal (let's say posedge y):

always @ (posedge y)
begin
x <= x + 1;
-- nonblocking assignment is better practice in edge
-- triggered always blocks
end

Then the new value (x+1) will computed as combinational logic and the
flipflop (x) will be loaded with this value at posedge y.


Ralf

 

thank you !!

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralf Hildebrandt wrote:

always @ ( y )
begin
if ( y==1'b1 ) begin
x = x + 1;
end //if
end

This would lead to an infinite loop. Remember that as long as y is 1'b1
the addition would take place.

Good heavens no. The @ blocks waiting for an event on y.
When that event happens, the statement that it guards is executed.
The "always" causes it to be repeated.

This is poor style, but is no infinite loop. Time will advance
according to events on y.


- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFlT24rPt1Sc2b3ikRAoIrAJ99BfbPEydtyOaUhmtd/dQFgkrqGwCg6ZuV
Gl7JPqfZFGSdUiS/PDVDjdo=
=/LoL
-----END PGP SIGNATURE-----

 

always @ ( y )
begin
if ( y==1'b1 ) begin
x = x + 1;
end //if
end

This would lead to an infinite loop. Remember that as long as y is 1'b1
the addition would take place.

Good heavens no. The @ blocks waiting for an event on y.
When that event happens, the statement that it guards is executed.
The "always" causes it to be repeated.

That's right, this is not an infinite loop, thanks for reminding me.
What complete nonsense, "synthesis tools ignore sensitivity list".

thanks!!

This is poor style, but is no infinite loop. Time will advance
according to events on y.


- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFlT24rPt1Sc2b3ikRAoIrAJ99BfbPEydtyOaUhmtd/dQFgkrqGwCg6ZuV
Gl7JPqfZFGSdUiS/PDVDjdo=
=/LoL
-----END PGP SIGNATURE-----

 

[Rob Dekker]

There is an interesting history on this subject. See below.

"Stephen Williams" <spamtrap@icarus.com> wrote in message news:5NydnaIipY8moAjYnZ2dnUVZ_uS3nZ2d@giganews.com...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralf Hildebrandt wrote:

always @ ( y )
begin
if ( y==1'b1 ) begin
x = x + 1;
end //if
end

This would lead to an infinite loop. Remember that as long as y is 1'b1
the addition would take place.

Good heavens no. The @ blocks waiting for an event on y.
When that event happens, the statement that it guards is executed.
The "always" causes it to be repeated.

You are correct, simulation behaves this way.
What Ralf refers to though is how synthesis tools interpret this.

There are two ways essentially (for synthesis tools to interpret this always stmt) :

(1) The 'correct' way (to match simulation). This is actually possible in this case !!
That is because there is only ONE signal on the sensitivity list.
Thus the event control list specifies two edges : rising y and falling y.
That signal is also nicely tested in an 'if' statement, meaning that the x = x + 1 statement is only executed under the RISING edge
of y.
So, this can be correctly implemented with flip-flops !!

(2) The 'common' way (what most tools do). This is to interpret the sensitivity list as non-edge and thus create combinational logic
for the contents.
The 'if' statement then causes 'latches' to be created on reg 'x'. And that creates the infinite loop that Ralf talks about. The
counter will race when y is '1'.
At least, most tools will complain (warn) that 'x' is missing from the sensitivity list... At least that way as a designer that
there might be simulation-synthesis differences.

When I implemented the 'correct' way for Leonardo back in the old days, I very quickly got bug-reports from people that wanted the
other 'common' way to be done.
The reason given was that "Synopsys does it that way" or "the intent of the designer is to create combinational logic".
After years of fighting this, I finally gave in. Verific (front-end for about 50 HDL tools) also does the 'common' way now.
Most, if not all, tools synthesize the 'common' way nowadays. Even though it is not correct and does not match simulation.

Rob

 

[Chris F Clark]

<nn> writes:

always @ ( y )
begin
if ( y==1'b1 ) begin
x = x + 1;
end //if
end

This would lead to an infinite loop. Remember that as long as y is 1'b1
the addition would take place.

Good heavens no. The @ blocks waiting for an event on y.
When that event happens, the statement that it guards is executed.
The "always" causes it to be repeated.

That's right, this is not an infinite loop, thanks for reminding me.
What complete nonsense, "synthesis tools ignore sensitivity list".

Actually, "synthesis tools ignore sensitivity list", is not complete
nonsense. But, the meaning in this case is not an infinite loop, it
is a simulation/synthesis mismatch. There is no "gate" which waits on
all events of signal y and can increment a counter when they occur.
Therefore the synthesizer, can not create logic which does what the
simulator will show. Whatever, logic the synthesizer creates will
behave differently than your simulation under some conditions.

There is a lot of "code" one can write in Verilog that doesn't
correspond to a circuit (given the current synthesis technology).
Using "sensitivity lists" that aren't edge-triggered and aren't
"always *" (or its equivalent) is a good way of creating such code.

Thus, your "always @ x = x + 1;" may be legal well-defined Verilog
code and simulate to exactly what you want, but it won't synthesize to
a circuit that implements what you want, because "synthesis tools do
ignore sensitivity lists" except for certain specific exceptions--the
edge triggered always blocks that correspond to flip-flops and other
state devices.

Closer to what you want is, "always @posedge x <= x+ 1;". That
will synthesize to a nice counter that counts posedges. If you want a
separate counter, that counts negedges, you can write that as a
separate block. Then, you can sum the two counters to get a counter
that counts all "changes". Then, you are back in the world of digital
design, and you only have to worry that your clock doesn't oscillate
so fast that it violates the setup of hold times of the circuit.

Now, I will leave it to you why you want to count both types of
transitions (both posedges and negedges)--it isn't a common
requirement, and suggests that something about your design is unusual,
which means it is also suspect.

In fact, it wouldn't be surprising to learn that the reason
synthesizers don't create two counters on opposite edges, plus some
combination circuity to add them together, is not that it is too hard
for the synthesizer writers to recognize and implement, but instead
that it is usually a sign of a design error that the synthesizer
writers are trying to keep the users from accidentally falling into.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------