Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

"When others" best practice?

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

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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.