Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16612 Discussions

"When others" best practice?

Altera_Forum
Honored Contributor II
1,273 Views

Hello, 

 

I need to create a design that takes a different action according to the data input. I made a few tests here using both CASE and IF statements. From 64 different input values the system must do something only for 5 of them. The other cases it should "do nothing". 

My question is how should I program the "when others" case or the last "else" of the IF statements? There seems to be a big difference on the resulting system size depending on this 

 

From my tests I got the following compilation results (total logic elements): 

IF statement with no "else" on the last IF: 23521 

IF statement with (signal <= signal) on the last else: 23510 

IF statement with (signal <= value) on the last else: 22496 (please note that this is not the correct behavior of the system, I only did it for testing) 

 

CASE statement with nothing on the "when others": 24262 

CASE statement with (signal <= signal) on the "when others": 24342 

CASE statement with (signal <= value) on the "when others": 22882 

 

Thank you 

Best regards, 

Thiago
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
303 Views

this is going to depend on whether its clocked or not. 

 

If its an asynchronous code, you should always have an else or a when others with a signal <= value assignment, otherwise you will create latches (which are generally bad). 

 

For synchronous code, it will really depend on what behaviour you want. no else/when others should produce behaviour the same as when you have signal <= signal. But the difference probably comes from how the logic is generated. 

 

Without an else/when others, the logic will have a decoded value that connects to the enable input of the register. with the specific selection, it may instead build a mux to the input of the register with nothing connected to the enable input (held at '1'). Hence the small difference in LEs (but exactly the same functionality. 

 

The signal <= value case, it has to use the mux option with last input the value rather than a looped back version of the register.
0 Kudos
Altera_Forum
Honored Contributor II
303 Views

Hi, 

in theory, there can be a slighly different meaning to each option. 

A VHDL "if/elsif" strucuture implies priority. That is, in general, more than one branch may match and the first is used. 

The VHDL case statement is parallel: only one branch may match. 

 

But even if your "if/else" structure expressed some non-intentional priority, then the "case" statement should, ideally, lead to the same or less logic. Which is doesn't. 

 

What you're experiencing is, probably some tool limitation, which show up in a somewhat "random" fashion. 

There's no advice I can offer, except to do what you just did: try, somewhat randomly, multiple ways to express the same code. 

You can also try to use conditional assignments, "select" statements, etc. 

 

And try to see what kind of structures your VHDL is being translated into in the RTL netlist. That sometimes provides an hit of what the tool is doing.
0 Kudos
Altera_Forum
Honored Contributor II
303 Views

Thanks Tricky and rbugalho! 

 

Yes, all the code is synchronous.  

The difference in LE when I don't use "when others" and when I assign a value to the signal is huge. This is why I want to see if there is anything I can do to reduce the logic usage. 

I don't need priority in this system so I went first for the CASE statement usage. I was then shocked by the amount of logic generated so I started experimenting until I found that the IF statement was "more efficient"... 

 

Best regards, 

Thiago
0 Kudos
Altera_Forum
Honored Contributor II
303 Views

the best thing to do is check out the RTL viewer to see the physical differences. But I suspect its to do with generating enables rather than muxes for the d input.

0 Kudos
Reply