Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

if/else vs. if/if in combo logic

Status
Not open for further replies.

stanford

Full Member level 2
Joined
Feb 16, 2014
Messages
132
Helped
4
Reputation
8
Reaction score
6
Trophy points
1,298
Activity points
2,223
This code (which has if/else) will take the comparison of "in == a" as higher priority.

Code:
always_comb begin

out = 0;
if (in == a)
  out = y;
else if (in == b)
  out = z;

end

However, this code below (which has if, if) also imply the same priority. Are they functionally the same? Will the two get synthesized into the same hardware?

Code:
always_comb begin

out = 0;
if (in == b)
  out = z;
if (in == a)
  out = y;

end
 

how do you measure priority?

they do slightly different things and in different order

the "if else" never evaluates the second if statement, if the first "if" statement were true

the if if always evaluates both if statements

because the if else behaves differently than the if if, they would not be the same in hardware.
 

Hi,

In the first code ...
When the first "if" is true, then all following "if" are not processed.
Thus the first true "if" wins and thus has priority.

In the second code...
All the following "if" are processed and the last one "true" wins.
Thus the last true "if" wins and thus has priority.

Now I see you changed the order in the second code, thus - in my eyes - both should behave identical.
But I'm no expert in this...

Klaus
 

If you can't understand the result intuitively, write a truth table.
 

If you can't understand the result intuitively, write a truth table.

i do, i just wanted to confirm. I was also trying to see if there is any benefit to writing if/else vs. if/if
 

Hi,

In the first code ...
When the first "if" is true, then all following "if" are not processed.
Thus the first true "if" wins and thus has priority.

In the second code...
All the following "if" are processed and the last one "true" wins.
Thus the last true "if" wins and thus has priority.

Now I see you changed the order in the second code, thus - in my eyes - both should behave identical.
But I'm no expert in this...

Klaus

Given this, "... The Optimizer can optimize both combinational and sequential designs for speed, area, and power ... "

Is it possible that the Optimizer realizes that it can be faster to execute the second "IF" statement first?
If the second "IF" statement is TRUE then there is no reason to even execute the first "IF" statement.
Then if, and only if, the second "IF" statement is FALSE then execute the first "IF" Statement.
If the Optimizer can do this then the Synthesized Hardware for both of these specific "If / Else" and "If / If" examples could be identical.

Code:
always_comb begin

out = 0;
if (in == b) <== Optimized to execute 2nd and only if the "IF" statement below is FALSE?
  out = z;
if (in == a)  <== Optimized to execute 1st ?
  out = y;

end
 

Hi,

Is it possible that the Optimizer realizes that it can be faster to execute the second "IF" statement first?
You think as if it is software, processed line after line.

But I think you talk about hardware / HDL, which has to be seen to be processed in parallel.
I'm pretty sure the compiler does not treat it as sequentially performed "if", thus it will not "optimize" it (in regards of sequential design).
Again: This is what I've been thaught, but I have no detailed experience.

But for sure you can design it to be processe sequentially. Just write your code in a way that each 'if' is performed one clock after the previous "if". (Although I see not much benefit in this. Maybe one can decrease area, or avoid timing violations.)

Maybe a more experienced member can show (and explain) the difference of the output of the compiler... of both sources.

Klaus
 

for synthesis they are equivalent. For simulation I think there is a minor difference /wrt how always blocks using "out" get triggered. IIRC, style 2 can cause other always blocks to trigger when the in == b case it is met even if the in == a case sets out to the same value. In sim, the triggered always blocks might have system calls or other impure behavior that can be observed.

if/else vs if/if is something for debate. Using blocking assigns means possible weirdness if "out" is used between the if statements. overriding assigns should really only be done in a way where it is very clear that it was intentional.
 

If "a" and "b" are different values, the truth tables for the "out" bits will be identical, so the synthesized result should be identical for a good synthesizer.

For an if/else chain, only one case will be considered.
A chain of if/if will only give the same result if the conditions are such that the synthesizer can see that only one of them can be true.
 

Given this, "... The Optimizer can optimize both combinational and sequential designs for speed, area, and power ... "

Is it possible that the Optimizer realizes that it can be faster to execute the second "IF" statement first?
If the second "IF" statement is TRUE then there is no reason to even execute the first "IF" statement.
Then if, and only if, the second "IF" statement is FALSE then execute the first "IF" Statement.
If the Optimizer can do this then the Synthesized Hardware for both of these specific "If / Else" and "If / If" examples could be identical.

Code:
always_comb begin

out = 0;
if (in == b) <== Optimized to execute 2nd and only if the "IF" statement below is FALSE?
  out = z;
if (in == a)  <== Optimized to execute 1st ?
  out = y;

end

Think of the structure of a mux gate (which tends to be used to implement if-like structures). There is no priority, S=0 or S=1, period. There is no notion of 'executed first'.
 

Yes they will synthesize to the same thing.

I'm personally ok using that coding style but only if there is a reason. In this toy example the first example is better practice. But sometimes the 'last one wins' strategy can make for more compact or simpler code.

The simulator should also produce the same result but execution time might vary. I've also seen 'glitches' in the simulation waveform viewer when using this coding style as it records transitions that ultimately get written over. Zoomed out the waveform is 'thick' implying there are transitions but when you zoom in they go away (Xilinx bug).
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top