case statement vs if statement

Status
Not open for further replies.
V

VLSI_CHE

Junior Member level 1
Joined
Jul 10, 2011
Messages
15
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,395
What would be infered in the fpga for case statement and if statement?
 

they implement different circuit.
If 'if' statement is used, it generates cascaded logic which checks for the 1st if statement condition, then next if statement condition, and so on.
If 'case' is used, all conditions in the statement have equal weight.
 

VLSI_CHE said:
What would be infered in the fpga for case statement and if statement?
Click to expand...
It depends...if the 'if' statement specifies mutually exclusive conditions that could have been implemented with a case statement, then there is no difference.

Kevin Jennings
 

Oh, sorry. What I was assuming was that there is a cascaded if statements such as if...elsif....elsif....
 

gongdori said:
Oh, sorry. What I was assuming was that there is a cascaded if statements such as if...elsif....elsif....
Click to expand...
My previous answer still applies

Kevin Jennings
 

Verilog's case statement is an if-else style. this allows odd constructs like "case 1'b1" which can have cases that correspond to expressions. Synthesizers support "parallel-case" and "full-case" for verilog, which tell the tools that the cases are mutually exclusive (parallel case). Some developers (mainly ASIC) will avoid parallel case, as RTL simulations will not match post-synthesis simulations when the cases are not actually mutually exclusive. The "case 1'b1" is common in verilog for manual encoding of "one-hot" state machines. The parallel case can have a more efficient structure -- the user is imparting and assumption that the cases are mutually independent when such is not obvious from the code itself.

www.sunburst-design.com/papers/CummingsSNUG1999Boston_FullParallelCase.pdf
 

"case" statement will inferr a mux logic in fpga. where, "if" statement will infer a rpiority encoder?
 

if you have a good synthesis tool, the two should be the same -- it should pick up a mux structure from the case statement or the if-else's. This is true for VHDL. However, the if-else can also describe a priority encoder.

However, for Verilog another situation exits -- that a case statement can describe a priority encoder. This is because Verilog allows multiple matching cases (or no matching cases). As a result, Verilog will only infer the mux when the case and if-else structure could both infer a mux. Unless the user specifies full-case/parallel-case as needed. Then the case can infer a mux even when such would mean a simulation mismatch.
 

K-J said:
My previous answer still applies
Click to expand...

Hm... Really? As far as I know, the implementation from case and if statements were different. I don't know how the synthesizer can create case statement from multiple if-elsif statement. I thought that was the reason designers prefer using case statement instead of if... is it not?
 


Consider the following bits of code, they both infer the same logic:

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

signal a : integer range 0 to 3;
 
case a is
  when 0 => --do something
  when 1 => --do something else
  when 2 => --do a third thing
  when 3 => --make some toast
end case;
 
if a = 0 then
  --do something
elsif a = 1 then
  --do something else
elsif a = 2 then
  --do a third thing
else
  --make some toast
end if;


Both bits of code should create exactly the same circuit, a mux, because all the if branches are mutually exclusive. priority encoders will only occur if you have more general conditions, like this:

Code VHDL - [expand]
1
2
3
4
5

if cond1 then
  --do something
elsif cond2 then
  --do something else
end if;


here, if cond1 is true, it doesnt matter what the state of cond2 is. but ion the top example, because all branches check the same signal, there is no priority.
 
gongdori said:
Hm... Really? As far as I know, the implementation from case and if statements were different.
Click to expand...
And what 'you know' is based on synthesizing a circuit or just guessing? It appears to be guessing.
I don't know how the synthesizer can create case statement from multiple if-elsif statement.
Click to expand...
Perhaps you should read what I wrote in my first post. If the conditions in the 'if' statement are mutually exclusive as they would have to be in order to be able to use a 'case' statement instead, then the synthesizer will create the same logic.
I thought that was the reason designers prefer using case statement instead of if... is it not?
Click to expand...
Designer preferences are not the topic though are they?

Perhaps you and the OP should construct a test case and synthesize it both ways to prove to yourself.

Kevin Jennings
 

K-J said:
And what 'you know' is based on synthesizing a circuit or just guessing? It appears to be guessing.
Click to expand...

Yes, what I know is based on synthesizing a circuit. Not just guessing. I was curious about exactly on this issue and tested it before. It was long time ago, though.

Perhaps you should read what I wrote in my first post. If the conditions in the 'if' statement are mutually exclusive as they would have to be in order to be able to use a 'case' statement instead, then the synthesizer will create the same logic.
Click to expand...
I thought you said that your answer still applies, didn't you?

Designer preferences are not the topic though are they?
Click to expand...
Perhaps YOU should read what I wrote. I did not say that designers "prefer" using case statement for no reason. I said that they use it because of the reason I explained.

Perhaps you and the OP should construct a test case and synthesize it both ways to prove to yourself.
Click to expand...
I may, when I get a chance.

KJ,
We are here for constructive discussion so that we can learn more from others. I don't know why it looks that I am guessing to you... and what you said does not look constructive to me. People who post here post what they know, they don't write research papers in order to post in this forum. Their posting can be right or wrong, but it would be helpful as long as it is constructive discussion. We all have enough finger-pointing at work...:-(
 

Well, there are certain limitations(Maybe hesitation) in using if and case statements in all situations. You cannot use a case statement very well for a nested-if statement. For eg.

Code: 
if a = 1 then
 if b = 2 and c = 3 then
  en_1 <= '1';
  if d = 40 and e = 50
     en <= '1';
  else
     en <= '0';
  end if;
  en_1 <= '0';
 end if;
end if;

Similarly for describing a state machine, case statements are best at it's own. So it is purely based on the designer point of view. Because both has it's own pros and cons.
 
The example you posted can't be expressed as a case statement at all which renders the comparison between 'if' and 'case' moot. The person writing this code could not choose between using 'if' and 'case' any more than they would choose between 'if' and 'with/select'.

However, any code that can be written with a 'case' statement (which implies the selection is with a single signal with mutually exclusive condtions as I mentioned in my first post) can also be written with an 'if' statement as well and the synthesis result will be identical. If the synthesized result is different, it implies that whoever translated the code made a mistake and produced something that is functionally different.

I do agree that given code that potentially can be expressed either way, that the choice between 'if' and 'case' can be influenced by the whims of the designer. Hopefully, those whims are driven by factors such as code maintainability and clarity of what function is being described rather than simply "I like if statements 'cuz I can always use them"...but you never know.

Kevin Jennings
 

Agreed, I was just trying to justify that not all logic can be written using either If-statements or case-statements only, however this is deviated from the actual subject of this thread.
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…