When do truth tables use the "Don't-care" term?

Question

1. In which situation can be used the Don't-care term?

2. Suppose that I want to use 6 symbols: I need 3 bits, which in turn can generate 8 combinations. Since the last two combinations aren't useful in my case, should I put them to 0or Don't care?

This is the truth table of the useful symbols

0 0 0 | 1
0 0 1 | 0
0 1 0 | 0
0 1 1 | 1
1 0 0 | 0
1 0 1 | 1
------

The output of the combinations below doesn't exist, or it's irrelevant

1 1 0
1 1 1

Answer 1

Truth tables are used for two main, but distinct, purposes:

• Indicating to a person or program which is implementing some logic what the logic is required to do

• Indicating to a person or program which is using some logic what the logic should be expected to do

In either situation, a "don't care" line on an input is a shorthand way for indicating that the circuit in question will behave identically when the input is high or when it is low. In many contexts, it will imply that the input in question must nor or will not affect the output state at all; ideally, exceptions to that would be clearly annotated, but in practice they aren't. It may be good to have an annotation to indicate that situation. For example, consider a mux with the following truth table:

Sel A B   Out
0   0 X    0
0   1 X    1
1   X 0    0
1   X 1    1
X   0 0    0
X   1 1    1

From a pure static combinatorial logic standpoint, the last two lines are redundant. There is, however, an important reason for them. In their absence, if A and B are both high and Sel changes from high to low, there would be no guarantee that the output must remain high; to put it another way, the first four lines define the state of the output when Sel input is a valid high and when it is a valid low, but only the last two lines specify the output state when Sel is at a level which is neither valid high nor low (e.g. while it is transitioning).

With regard to outputs, "don't care" specifications are only relevant when truth are used to specify what logic is required to do. Many synthesis tools will cause outputs to behave in some specific fashion for all combination of inputs whose behavior is not otherwise specified. Consider, for example, the following truth table:

A B C   Q
0 0 X   0
1 0 0   0
0 1 0   0
1 0 1   1
0 1 1   1

Nothing explicitly specifies what the Q should do if A and B are both set. It's entirely possible that this logic is going to be placed behind circuitry which will never set A and B simultaneously [e.g. they'll be active on different non-overlapping phases of a multi-phase clock], in which case Q=(A or B) and C would probably be the optimal realization. In some languages, however, outputs are required to be low for unspecified combinations of inputs, and in others outputs are required to hold their present state. If the truth table included a line that specified the output state as "don't care" when both A and B are high, then a person or program implementing the design would know that Q=(A or B) and C would be an acceptable realization. Otherwise, if the output was required to hold its value whenever A and B were both high, it would be necessary to add a lot of additional complexity to the circuit (including quite possibly a latch!), but such complexity would serve no useful function.

Answer 2

For the collective input symbols that are not relevant in terms of what output they produce, you should treat their output(s) as "don't care". Once you realize the design (by way of, for example, logic gates), they will -of course- produce a definite output, but by not specifying which, you are allowing them to be treated as wild cards, so that the specific values that optimize your final realization (in terms of # of gates, or physical area, or speed, etc.) are chosen. If instead you specify them prematurely, you may not allow your synthesis tool (or yourself) reach the most optimal solution.

Answer 3

If these input combinations (110 and 111) will never occur you should not care what is the output. Assigning don't care will simplify your logic.