Value of variables

[Johnsy Joseph]

Hello Everybody,

I am new to Verilog and would be very grateful if somebody could
kindly answer my doubt.

I understand that there are 2 ways by which we can specify things in
the sensitivity list of the always construct. Suppose I have a
variable called "moving". I can write it in 2 ways as "always @
(moving)" or "always @ (negedge moving)" depending on the application
I require. I now consider only the cases where 'moving' can have 0 or
1 and not 'x' or 'z'.

In that case I believe that "always @ (moving)" will enter at 2 times,
when moving from 0 to 1 or when it changes from 1 to 0. My question
is, when changing from 0 to 1, what will be the value of 'moving'
inside the always statement? Will it be 0 or 1? When changing from 1
to 0, what will be the value of 'moving' inside the always statement?
Will it be 0 or 1?

Similarly I believe that "always @ (negedge moving)" will enter only
once, when moving from 1 to 0. My question is, when changing from 1 to
0, what will be the value that 'moving' will hold inside the always
statement? Will it be 0 or 1? In short do we hold the final value or
the previous value of the change which caused the always to enter?

Please forgive me for such a qn, if it looks stupid.

Thanks for the help
Warm Regards
Johnsy

 

[Andy Peters]

johnsy_podimala@hotmail.com (Johnsy Joseph) wrote in message news:<c1a0a9f2.0402292124.5ee399d6@posting.google.com>...

I understand that there are 2 ways by which we can specify things in
the sensitivity list of the always construct. Suppose I have a
variable called "moving". I can write it in 2 ways as "always @
(moving)" or "always @ (negedge moving)" depending on the application
I require. I now consider only the cases where 'moving' can have 0 or
1 and not 'x' or 'z'.

In that case I believe that "always @ (moving)" will enter at 2 times,
when moving from 0 to 1 or when it changes from 1 to 0. My question
is, when changing from 0 to 1, what will be the value of 'moving'
inside the always statement? Will it be 0 or 1?

It'll be 1.

When changing from 1
to 0, what will be the value of 'moving' inside the always statement?
Will it be 0 or 1?

It'll be 0.

You can easily convince yourself with the following code:

always @(moving) begin
$display("%t: moving = %b", $time, moving);
end

Similarly I believe that "always @ (negedge moving)" will enter only
once, when moving from 1 to 0. My question is, when changing from 1 to
0, what will be the value that 'moving' will hold inside the always
statement? Will it be 0 or 1?

It'll be zero. Similar test code will show you:

always @(negedge moving) begin
$display("%t: moving = %b", $time, moving);
end

--a

 

[Steven Sharp]

johnsy_podimala@hotmail.com (Johnsy Joseph) wrote in message news:<c1a0a9f2.0402292124.5ee399d6@posting.google.com>...

I understand that there are 2 ways by which we can specify things in
the sensitivity list of the always construct.

It is incorrect to describe always constructs as having sensitivity
lists in Verilog. Most always constructs do contain an event control,
which suspends execution of the construct until the event occurs. You
are asking about the situation when an event control wakes up after
the event has occurred.

In that case I believe that "always @ (moving)" will enter at 2 times,
when moving from 0 to 1 or when it changes from 1 to 0. My question
is, when changing from 0 to 1, what will be the value of 'moving'
inside the always statement? Will it be 0 or 1?

The event control will not wake up until the event has occurred, so
the subsequent code will see the changed value, which is 1 in this case.

However, this does not quite guarantee that the subsequent code will
see the value that caused it to wake up. For example, you might
assume that after "@(negedge moving)" wakes up, you will be guaranteed
that moving is 0. However, it could have been woken up by a series of
assignments that created a zero-width glitch, like

moving = 1;
moving = 0;
moving = 1;

This glitch includes a negedge, but the value of moving immediately
changed to 1 again afterward. The event control may or may not
wake up on this glitch. If it does wake up because of the negedge,
the value of moving will probably already have changed to 1. The
behavior may be different between different simulators, different
command line options, or differences in the Verilog code. Relying
on particular behavior in such a situation is a bad idea.

But if you avoid creating zero-width glitches by assigning multiple
different values to the same variable at the same time, you should
see the final value that woke the event control up.

I will also comment that nets are different from variables, and are
more likely to appear in these contexts. Because of their scheduling
behavior, they are less likely to have zero-width glitches.

 

[Johnsy Joseph]

Hello,

Thanks a lot for the answers, I got the idea. I am still groping in
the dark after reading some of the queries posted here, that are
related to this. What is the problem if I mix an edge triggered signal
and a level sensitive signal together in the senstivity list of an
always statement as in the case of a D flip flop with asynchronous
reset? I know many people have asked it so please forgive me for
asking it again.

This is from a previous post on this group

"always @(posedge clk or rstn)
if (!rstn) q <= 0; // asynchronous reset
else if(clk) q <= d; // error!

because if rstn changes from 1 to 0 when clk is 1, d will be latched
to q by clk's HIGH LEVEL. it's not a FF."

As I was asking earlier when rstn changes from 1 to 0, when the always
block is entered the value is 0, hence it goes into the asynchronous
reset part. How then can the problem described above occur? Does it
happen at the synthesis level only but works fine when simulated?

Could anybody be kind to tell me if there will be any problems if I
mix both level sensitive and edge sensitive signals in the sensitivity
list? Does it always cause problems and should be avoided?

When all the siganls specified in the sensitivity list get true at a
perticular time, does the evaluation depend only on the order in which
signals are checked? In other words, if I have an 'if-else' construct
will that mean that only the statements in the very first block of the
if else ladder will get executed thus creating a priority among the
signals?

Thanks for the help
Warm Regards
Johnsy.

 

[Steven Sharp]

johnsy_podimala@hotmail.com (Johnsy Joseph) wrote in message news:<c1a0a9f2.0403012220.61634649@posting.google.com>...

This is from a previous post on this group

"always @(posedge clk or rstn)
if (!rstn) q <= 0; // asynchronous reset
else if(clk) q <= d; // error!

because if rstn changes from 1 to 0 when clk is 1, d will be latched
to q by clk's HIGH LEVEL. it's not a FF."

As I was asking earlier when rstn changes from 1 to 0, when the always
block is entered the value is 0, hence it goes into the asynchronous
reset part. How then can the problem described above occur? Does it
happen at the synthesis level only but works fine when simulated?

The description of the problem situation is incorrect in the quote.
The problem is when rstn changes from 0 to 1 while clk is 1. This
should have no effect on the output of a real flip-flop, which
should stay in the reset state. However, the change in rstn causes
the always block to execute, and !rstn is false, and clk is true,
so q gets set to d. Since this is not the desired behavior, this
is not the correct way to write a model of a flip-flop. To get the
desired behavior, you would write something like

always @(posedge clk or negedge rstn)
if (!rstn) q <= 0;
else q <= d;

Then somebody will complain that rstn is level sensitive, so why
does the event control wake up on negedge rstn? The answer is
because that is what makes the model behave as desired.

Could anybody be kind to tell me if there will be any problems if I
mix both level sensitive and edge sensitive signals in the sensitivity
list? Does it always cause problems and should be avoided?

There is no mysterious problem with mixing level and edge sensitive
signals in a simulation model. The language will define exactly how
the model you write will behave in a simulator. If that behavior
matches your desired device, then you are fine. If not, then you
need to fix it. For example, your quoted code does not correctly
model a flip-flop. My version fixes the problem (aside from possible
issues involving x states).

Synthesis tools are another matter. They don't necessarily duplicate
the behavior that the language defines. They "infer" what kind of
hardware you are trying to specify, and the result may not have the
behavior that the language defined for the original code. The rules
they use for this may be mysterious. But you still have to ensure
that your code makes the synthesis tool infer the hardware that you
intended, as well as producing the correct behavior in the simulator.

Synthesis tools have become so important that some people seem to
think that the behavior of a piece of Verilog is defined by the
hardware produced by synthesis. It is actually defined by the
language definition, which a simulator implements, and a synthesis
tool just approximates. When writing code for both simulation and
synthesis, it is important to write it so the synthesis approximation
is close to correct.

When all the siganls specified in the sensitivity list get true at a
perticular time, does the evaluation depend only on the order in which
signals are checked? In other words, if I have an 'if-else' construct
will that mean that only the statements in the very first block of the
if else ladder will get executed thus creating a priority among the
signals?

In the language definition, when an "if" condition is true, the "else"
statement will not get executed (like pretty much any programming
language). In general, a synthesis tool will produce logic that
duplicates the specified behavior by creating a priority among the
signals. However, there may be directives for telling the synthesis
tool that conditions are mutually exclusive, so that it can eliminate
the prioritization logic (i.e. use a simpler approximation that should
still be accurate if the provided assumption is true). But if the
directive is wrong, and the conditions are not mutually exclusive,
then this is an incorrect simplification, and the logic will not
correctly match the specified behavior.

 

[Johnsy Joseph]

Hello

Thanks a lot Steven for the post. Things are becoming more clear. I
just want to clarify one more thing based on this. Your post said "My
version fixes the problem (aside from possible issues involving x
states)."

Could please elaborate on this? Do we have things like x states at the
synthesis level? There should be either a 1 or a 0 only I suppose.

How do we handle x states, do we add stricter control by imposing more
checking at the if statements like the one below to get over it? or is
there any method to block them?

always @(posedge clk or negedge rstn)
if (!rstn) q <= 0;
else if (clock) q <= d; // added a check

I was thinking on another similar case. Suppose I was trying to having
a 2:1 mux, what would be the output if an 'x' came in the select
control? Is this similar to the case above or do we need any new
methods to get over it.

Please forgive my ignorance in my posts, I am very new to these
things.

Thanks for all the help
Warm Regards
Johnsy

 

[Andy Peters]

johnsy_podimala@hotmail.com (Johnsy Joseph) wrote in message news:<c1a0a9f2.0403022155.57874d68@posting.google.com>...

How do we handle x states, do we add stricter control by imposing more
checking at the if statements like the one below to get over it? or is
there any method to block them?

You should understand why a signal has the value x. Trying to get
around this could lead to pain and suffering when your hardware
doesn't match your simulations.

I was thinking on another similar case. Suppose I was trying to having
a 2:1 mux, what would be the output if an 'x' came in the select
control? Is this similar to the case above or do we need any new
methods to get over it.

You should dig out any Verilog book and read the page where it shows
you the truth tables for the various operators.

--a