Parallel if statement in clocked block

[Kiran]

Hi,

In the following code,

always @(posedge clk or negedge rstn)
begin
if (rstn == 1'b0)
begin
.
.
a <= 1'b0;//reset condition
end
else
begin
.
.
if ( condition1 == TRUE )
begin
a <= 1'b0;
end
.
.
if (condition2 == TRUE)
begin
a <= 1'b1;
end

end
.
end

what's happening is that FF 'a' is being assigned under 2 unrelated if
statements. 'condition1' and 'condition2' are not related. Will this
cause a simulation vs. synthesis mismatch? What will happen in
simulation & synthesis for this kind of code?

Thanks.

 

[Peng Cong]

The code is not safe, competition risk exist.
condition1 and condition2 should have differrent priority,
like

if ( condition1 == TRUE )
a <= 1'b0;
else
if (condition2 == TRUE)
a <= 1'b1;
else
a <= 1'b0;

"Kiran" <kirandev@msn.com> Đ´ČëĎűϢĐÂÎĹ
:9043844f.0310190551.49351cc@posting.google.com...

Hi,

In the following code,

always @(posedge clk or negedge rstn)
begin
if (rstn == 1'b0)
begin
.
.
a <= 1'b0;//reset condition
end
else
begin
.
.
if ( condition1 == TRUE )
begin
a <= 1'b0;
end
.
.
if (condition2 == TRUE)
begin
a <= 1'b1;
end

end
.
end

what's happening is that FF 'a' is being assigned under 2 unrelated if
statements. 'condition1' and 'condition2' are not related. Will this
cause a simulation vs. synthesis mismatch? What will happen in
simulation & synthesis for this kind of code?

Thanks.

 

[Kiran]

"Peng Cong" <pc_dragon@sohu.com> wrote in message news:<bmvfuf$1p7k$1@mail.cn99.com>...

The code is not safe, competition risk exist.
condition1 and condition2 should have differrent priority,
like

Will it not create a priority encoder with 'condition2' getting the higher priority?

Thanks.

 

[Andy Botterill]

In article <bmvfuf$1p7k$1@mail.cn99.com>, Peng Cong <pc_dragon@sohu.com>
writes

Shouldn't condition1 and condition2 be in the sensitivity list?

The code is not safe, competition risk exist.
condition1 and condition2 should have differrent priority,
like

if ( condition1 == TRUE )
a <= 1'b0;
else
if (condition2 == TRUE)
a <= 1'b1;
else
a <= 1'b0;

"Kiran" <kirandev@msn.com> Đ´ČëĎűϢĐÂÎĹ
:9043844f.0310190551.49351cc@posting.google.com...
Hi,

In the following code,

always @(posedge clk or negedge rstn)
begin
if (rstn == 1'b0)
begin
.
.
a <= 1'b0;//reset condition
end
else
begin
.
.
if ( condition1 == TRUE )
begin
a <= 1'b0;
end
.
.
if (condition2 == TRUE)
begin
a <= 1'b1;
end

end
.
end

what's happening is that FF 'a' is being assigned under 2 unrelated if
statements. 'condition1' and 'condition2' are not related. Will this
cause a simulation vs. synthesis mismatch? What will happen in
simulation & synthesis for this kind of code?

Thanks.

--
Andy Botterill

 

[Renaud Pacalet]

Kiran a écrit :

Hi,

In the following code,

always @(posedge clk or negedge rstn)
begin
if (rstn == 1'b0)
begin
.
.
a <= 1'b0;//reset condition
end
else
begin
.
.
if ( condition1 == TRUE )
begin
a <= 1'b0;
end
.
.
if (condition2 == TRUE)
begin
a <= 1'b1;
end

end
.
end

what's happening is that FF 'a' is being assigned under 2 unrelated if
statements. 'condition1' and 'condition2' are not related. Will this
cause a simulation vs. synthesis mismatch? What will happen in
simulation & synthesis for this kind of code?

The LRM is clear about this: "Non blocking assignments shall be performed in the
order the statements were executed". So 'a' will be the output of a DFF with
active low async reset 'rstn'; the input of the DFF (let's name it 'd') will be
a combinational part with a behaviour equivalent to:

if(condition1 == TRUE) d <= 1'b0;
else if(condition2 == TRUE) d <= 1'b1;
else d <= a;

Regards,
--
Renaud Pacalet, GET/ENST/COMELEC/LabSoC
Institut Eurecom BP 193, 2229 route des Cretes
F-06904 Sophia-Antipolis Cedex
Tel : +33 (0) 4 9300 2770
Fax : +33 (0) 4 9300 2627
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/

 

[Shalom Bresticker]

It should.

Shalom


Kiran wrote:

"Peng Cong" <pc_dragon@sohu.com> wrote in message news:<bmvfuf$1p7k$1@mail.cn99.com>...
The code is not safe, competition risk exist.
condition1 and condition2 should have differrent priority,
like


Will it not create a priority encoder with 'condition2' getting the higher priority?

Thanks.

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478

 

[John Ho]

"Renaud Pacalet" <MonPrenom.MonNom@MonOrganisation.MonPays> wrote in message
news:bn0phb$iku$1@lanfeust.eurecom.fr...

Kiran a écrit :
Hi,

In the following code,

always @(posedge clk or negedge rstn)
begin
if (rstn == 1'b0)
begin
.
.
a <= 1'b0;//reset condition
end
else
begin
.
.
if ( condition1 == TRUE )
begin
a <= 1'b0;
end
.
.
if (condition2 == TRUE)
begin
a <= 1'b1;
end

end
.
end

what's happening is that FF 'a' is being assigned under 2 unrelated if
statements. 'condition1' and 'condition2' are not related. Will this
cause a simulation vs. synthesis mismatch? What will happen in
simulation & synthesis for this kind of code?

The LRM is clear about this: "Non blocking assignments shall be performed
in the
order the statements were executed". So 'a' will be the output of a DFF
with
active low async reset 'rstn'; the input of the DFF (let's name it 'd')
will be
a combinational part with a behaviour equivalent to:

if(condition1 == TRUE) d <= 1'b0;
else if(condition2 == TRUE) d <= 1'b1;
else d <= a;

Regards,
--
Renaud Pacalet, GET/ENST/COMELEC/LabSoC
Institut Eurecom BP 193, 2229 route des Cretes
F-06904 Sophia-Antipolis Cedex
Tel : +33 (0) 4 9300 2770
Fax : +33 (0) 4 9300 2627
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/

According to the statement that you referred from the LRM, if condition 1

and condition 2 are all TRUE, a<=1'b0 and a<=1'b1 are executed sequentially,
which means at the end of the block, d will be assigned first 0 and then 1.
So the condition2==TRUE has a higher priority. If the original block is same
as below:

always @(posedge clk or negedge rtsn)
if ( rtsn ==1'b0 )
a <= 1'b0;
else begin
if ( condition2 == TRUE ) a <= 1'b1;
else if ( condition1 == TRUE ) a <= 1'b0;
else a <= a;
end
end

 

[Jan Decaluwe]

Kiran wrote:

Hi,

In the following code,

always @(posedge clk or negedge rstn)
begin
if (rstn == 1'b0)
begin
.
.
a <= 1'b0;//reset condition
end
else
begin
.
.
if ( condition1 == TRUE )
begin
a <= 1'b0;
end
.
.
if (condition2 == TRUE)
begin
a <= 1'b1;
end

end
.
end

what's happening is that FF 'a' is being assigned under 2 unrelated if
statements. 'condition1' and 'condition2' are not related. Will this
cause a simulation vs. synthesis mismatch?

No.

What will happen in

simulation & synthesis for this kind of code?

No problem with either. Probably you are concerned about the case in which
both conditions are true. In this case the last condition "wins", as
required by the code. The logic implementation is a piece of cake for
a synthesis tool, but surprizingly difficult to understand by many
designers, typically those who overemphasize "thinking hardware".

In the future it may help by not thinking of 'a' as *being* a flip-flop,
but just a Verilog reg (which is something completely different), that
needs to be *implemented* with a flip-flop and logic according to
the way it is used in the code.

Regards, Jan

--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Bored with EDA the way it is? Check this:
http://jandecaluwe.com/Tools/MyHDL/Overview.html

 

[Chris F Clark]

Kiran wrote: (some stuff clipped)

always @(posedge clk or negedge rstn)
begin
.
.
if ( condition1 == TRUE ) begin
a <= 1'b0;
end .
.
if (condition2 == TRUE)
begin
a <= 1'b1;
end
end
.
end

Jan replied:

Probably you are concerned about the case in which both conditions
are true. In this case the last condition "wins", as required by the
code.

What about "glitches"?

Is the simulator REQUIRED to eliminate the possible transition of the
output signal a from it's input value (say x) to 0, before
transitioning a to it's final value 1, when both conditions are true?

That is, if there is other code that does:

always @ ( negedge a ) $display ("negedge\n");
always @ ( posedge a ) $display ("posedge\n");

Is the simulator prohibited from printing the negedge message, if at
the clock edge both condition1 and condition2 are true? I could
believe that the simulator is not required to display negedge, but
prohibited from doing so?

The way I read section 5.4.1 of the standard, I see it guaranteeing
that there will be a (simulation) glitch, which is exactly the
opposite of what your response implies.

Explain to me where I am confused (where in the standard it guarantees
that the glitch is prvented).

Note, unless the synthesizer is capable of intentinally generating
gates that create glitches, it would seem that there could be a
synthesys/simulation mis-match (as the simulator might glitch and the
resulting synthesized hardware, might not). Moreover, if instead of
$display statements, one was using "a" as a clock on some other gates,
I could see those gates as triggering on the glitch in the simulator,
but potentially, not triggering if the glitch was removed in synthesis,
unless the synthesis tool was creative enough to substitute some much
fancier code in place of "a" on the clocks of the downstream flops.

For a precise example, consider the following:

initial begin // testbench
// initial values
a <= 0; q1 <= 0; q2 <= 0; cond1 <= 1; cond2 <= 1; enable <= 0;
// run the clock (turn on enable only after the clock is started)
clock <= 0; #(1) enable <= 1; #(1) clock <= 1; #(1) clock <= 0;
// display the results
@1 $display( q1, q2 );
end;

// device under test
always @ (posedge clock) begin
if ( cond1 ) a <= 1;
if ( cond2 ) a <= 0;
end;
always @ (posedge a) if (enable) q1 <= 1;
always @ (negedge a) if (enable) q2 <= 1;

What should be displayed for q1 and q2? What should be synthesized?

-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
19 Bronte Way #33M voice : (508) 435-5016
Marlboro, MA 01752 USA fax : (508) 251-2347 (24 hours)
------------------------------------------------------------------------------

 

[Jan Decaluwe]

Chris F Clark wrote:

Kiran wrote: (some stuff clipped)

always @(posedge clk or negedge rstn)
begin
.
.
if ( condition1 == TRUE ) begin
a <= 1'b0;
end .
.
if (condition2 == TRUE)
begin
a <= 1'b1;
end
end
.
end


Jan replied:


Probably you are concerned about the case in which both conditions
are true. In this case the last condition "wins", as required by the
code.


What about "glitches"?

In cases where glitches are relevant for correctness, the (mainstream)
synthesis paradigm breaks down. Therefore, my feedback was given under
the assumption that they are not.

Logic synthesis tools (the common ones) don't control glitch behavior
of an implementation. Similarly, some HDLs or simulators may have glitches
in cases where others have not; for example, Verilog may have glitches
in this case, but VHDL does not.

Typically when using synthesis you design in such a way that correctness
doesn't depend on glitch behavior: all that matters is the "end" value
before moving to the next timestep. When *not* using synthesis this
is a good idea also! If this is not possible (synchronizers etc.) special
measures and verification steps are required. Identifying (and avoiding)
those cases, by the way, is a good application of "thinking hardware".

For example, in this case, there's no problem with 'a' if it is used
elsewhere as an ordinary logic input, but there may be a simulation problem
if it is used as a clock.

Is the simulator REQUIRED to eliminate the possible transition of the
output signal a from it's input value (say x) to 0, before
transitioning a to it's final value 1, when both conditions are true?

I don't think so in Verilog - but in VHDL there would only be one event.

That is, if there is other code that does:

always @ ( negedge a ) $display ("negedge\n");
always @ ( posedge a ) $display ("posedge\n");

Is the simulator prohibited from printing the negedge message, if at
the clock edge both condition1 and condition2 are true? I could
believe that the simulator is not required to display negedge, but
prohibited from doing so?

The way I read section 5.4.1 of the standard, I see it guaranteeing
that there will be a (simulation) glitch, which is exactly the
opposite of what your response implies.

As stated earlier, my response assumed that glitches were not relevant, as
should typically the case for synthesis. The point is that the end value
of 'a' is unambiguously defined.

Explain to me where I am confused (where in the standard it guarantees
that the glitch is prvented).

As far as I can see, it doesn't.

Note, unless the synthesizer is capable of intentinally generating
gates that create glitches, it would seem that there could be a
synthesys/simulation mis-match (as the simulator might glitch and the
resulting synthesized hardware, might not). Moreover, if instead of
$display statements, one was using "a" as a clock on some other gates,
I could see those gates as triggering on the glitch in the simulator,
but potentially, not triggering if the glitch was removed in synthesis,
unless the synthesis tool was creative enough to substitute some much
fancier code in place of "a" on the clocks of the downstream flops.

In the common terminology, a synthesis mismatch is not defined in terms
of glitching behavior, but in terms of a stable end value.

Regards, Jan


--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Bored with EDA the way it is? Check this:
http://jandecaluwe.com/Tools/MyHDL/Overview.html

 

[Chris F Clark]

Jan replied (to a qustion I had about glitches in this thread):

In cases where glitches are relevant for correctness, the (mainstream)
synthesis paradigm breaks down. Therefore, my feedback was given under
the assumption that they are not.

Ok, this is a valid and reasonable assumption (at least for most
uses). I guess I just worry about the other cases, because we use
cycle based simulation (and thus the simulator itself discards
glitches), but we have to have special hacks to properly simulate
certain parts of the circuit and get the same results as the hardware
on the chip (and the "true" verilog simulation). Part of my job is to
worry about those hacks.

-Chris

 

[Renaud Pacalet]

John Ho a écrit :

"Renaud Pacalet" <MonPrenom.MonNom@MonOrganisation.MonPays> wrote in message
news:bn0phb$iku$1@lanfeust.eurecom.fr...

According to the statement that you referred from the LRM, if condition 1
and condition 2 are all TRUE, a<=1'b0 and a<=1'b1 are executed sequentially,
which means at the end of the block, d will be assigned first 0 and then 1.
So the condition2==TRUE has a higher priority. If the original block is same
as below:

always @(posedge clk or negedge rtsn)
if ( rtsn ==1'b0 )
a <= 1'b0;
else begin
if ( condition2 == TRUE ) a <= 1'b1;
else if ( condition1 == TRUE ) a <= 1'b0;
else a <= a;
end
end

You're perfectly right. Your equivalent code is the right one.

Regards,
--
Renaud Pacalet, GET/ENST/COMELEC/LabSoC
Institut Eurecom BP 193, 2229 route des Cretes
F-06904 Sophia-Antipolis Cedex
Tel : +33 (0) 4 9300 2770
Fax : +33 (0) 4 9300 2627
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/

 

[Andy Peters]

Andy Botterill <csm@plymouth2.demon.co.uk> wrote in message news:<M5HquKA$J4k$EwGq@plymouth2.demon.co.uk>...

In article <bmvfuf$1p7k$1@mail.cn99.com>, Peng Cong <pc_dragon@sohu.com
writes

Shouldn't condition1 and condition2 be in the sensitivity list?

No, since it's a clocked process. Clock and async reset only.

-a

 

[Cliff Cummings]

Hi, All -

kirandev@msn.com (Kiran) wrote in message news:<9043844f.0310190551.49351cc@posting.google.com>...

Hi,

In the following code,

always @(posedge clk or negedge rstn)
begin
if (rstn == 1'b0)
begin
.
.
a <= 1'b0;//reset condition
end
else
begin
.
.
if ( condition1 == TRUE )
begin
a <= 1'b0;
end
.
.
if (condition2 == TRUE)
begin
a <= 1'b1;
end

end
.
end

what's happening is that FF 'a' is being assigned under 2 unrelated if
statements. 'condition1' and 'condition2' are not related. Will this
cause a simulation vs. synthesis mismatch? What will happen in
simulation & synthesis for this kind of code?

Thanks.

There have been lots of good follow-ups to your question. Let me be
definitive with some answers and summarize other important points.

Your above coding style will not cause a simulation-synthesis
mismatch. Others have pointed out that the code is roughly equivalent
to the following:

always @(posedge clk or negedge rstn)
if (!rstn) a <= 1'b0; //reset condition
else if (condition2) a <= 1'b1;
else if (condition1) a <= 1'b0;

What was not said (that I could see) is that the above is a more clear
coding style and clarity can save project time. Consider the bandwidth
and "probable" responses that you received from readers of your
original post. Do you really want your design team spending time to
research a coding style that has a more clearly understood
representation?

As Jan mentioned, the Verilog standard does not prohibit vendors from
implementing your two nonblocking assignments either as a glitch or by
omitting the first assignment (for high performance simulators). This
is a combinational glitch and it happens all the time with synthesized
gates.

Consider the simple case of a 2-to-1 mux. Depending on it's
implementation, if both inputs to the mux are high, switching from
input0 to input1 can cause a momentary 0-glitch on the output of the
gate-version of the mux.

One could argue that it is better to have the hardware like Verilog
indeterminism related to this type of glitch or that it is better to
have the deterministic delta-delays of VHDL even if such determinism
does not exist in real hardware. Using either language, you just need
to realize that combinational glitches really do occur and either
method is a reasonable representation of hardware in simulations.

This is why good testbench styles only test combinational data just
before the next rising clock edge because the testbench is then
scalable to both 0-delay RTL models and actual-delay gate models. Jan
alluded to this, and ASIC vendors do this type of testing.
Combinational logic always glitches between clock edges until the
final value settles out.

You have to worry about glitches on clocks, resets and perhaps some
asynchronous trigger-source signals (the latter is somewhat rare).
Since most clocks and reset signals are inputs, you don't even have
control over these critical signals. There are reset issues that most
engineers are ignorant to and Steve Golson, Don Mills and myself
detailed many of the issues in our 2003 Boston SNUG paper freely
downloadable from www.sunburst-design.com/papers

Hope this helps.

Regards - Cliff Cummings
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
Verilog On-Site Training Sale - 4-day Courses for $1,200/Student
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training

 

[Gregorio Gervasio, Jr.]

Cliff Cummings writes:

c> Your above coding style will not cause a simulation-synthesis
c> mismatch. Others have pointed out that the code is roughly equivalent
c> to the following:

c> always @(posedge clk or negedge rstn)
c> if (!rstn) a <= 1'b0; //reset condition
c> else if (condition2) a <= 1'b1;
c> else if (condition1) a <= 1'b0;

c> What was not said (that I could see) is that the above is a more clear
c> coding style and clarity can save project time. Consider the bandwidth
[...]

However, this style (as well as the original one) doesn't
propagate X's, which could still result in an RTL-gate simulation
mismatch. This could hide a bug where "condition1/2" has not been
properly qualified.
--
Gregorio Gervasio, Jr.