• No results found

Truth Table Function Reduction

I like to tell new circuit designers to approach optimizing a logic circuit by first looking for opportunities in its truth table. This may not seem like a useful tool (especially in light of Table 2-1), but it can be as effective a tool as any of the others presented in this chapter. It can also be used as a useful verification tool for making sure that an optimized logic circuit will perform the desired function. The drawback to the truth table function reduction is that it tends to be the most demanding in terms of the amount of rote effort that you will have to put into it.

In the introduction to this chapter, the initial truth table I came up with didn’t seem very helpful. The reason for this is something that I will harp upon throughout this book – listing logic responses to binary input is not very effective, because of the large number of states that can change at any given time. If you look at Table 2-1, you will see that going from the state where P¼0, D¼W1¼W2¼1 to P¼1, D¼W1¼W2¼0 involves the changing of four bits. While this is a natural progression of binary numbers and probably an intuitive way of coming up with a number of different input states, it is not an effective way to look at how a logic circuit responds to varying inputs.

A much better method is to list the output responses in a truth table that is ordered using Gray codes, as I have shown in Table 2-2. Gray codes are a numbering system in which only one bit changes at a time: they are explained in detail along with how they are generated in Chapter 4. When you are listing data, regardless of the situation, you should always default to using Gray code inputs instead of incrementing binary inputs, as I have shown in Table 2-1.

Taking this advice, I recreated the home alarm system truth table using Gray codes in Table 2-2. When you look at Table 2-2, you should notice that the ‘‘discontinuities’’ of Table 2-1 have disappeared. The bit patterns which ‘‘Sound Alarm’’ group together quite nicely.

Looking at each value which ‘‘Sound Alarm’’, you’ll notice that each pair has three bits in common. To illustrate this, in Table 2-3, I have circled the bit which is different between each of the four pairs. In each of these

pairs, to sound the alarm we have very specific requirements for three bits, but the fourth bit can be in either state.

Another way of saying this is: for the alarm to sound, we don’t care what the fourth bit is and it can be ignored when we are determining the sum of products equation for the logic function. To indicate the ‘‘don’t care’’ bit, in Table 2-4, I have combined the bit pairs and changed the previously circled bits with an ‘‘x’’. This ‘‘x’’ indicates that the bit can be in either state for the output to be true. By replacing the two truth table entries with a single one with the don’t care bit indicated by an ‘‘x’’ you should see that something magical is starting to happen.

Table 2-3 Uncommon bits in ‘‘Sound Alarm’’ pairs.

Table 2-4 Home alarm truth table with don’t care bits replaced with an ‘‘x’’.

The obvious observation is that the table is shorter, but you should notice that the number of events which ‘‘Sound Alarm’’ has been halved and they are less complex than the eight original events. The sum of products equation for the bits shown in Table 2-4 is:

Alarm State¼ ð!PW1!W2Þ

þ ðPDW2Þ

þ ðPW1!W2Þ

þ ðP!DW2Þ

This sum of products expression will require four NOT gates, eight AND gates and three OR gates and the maximum gate delay will be nine. This has reduced the total gate count to less than 50% of the original total and this logic equation will operate somewhat faster than the original.

This is pretty good improvement in the logic circuit. You should be asking yourself if we can do better. To see if we can do better, I rearranged the data in Table 2-4 so that the ‘‘Sound Alarm’’ events with common don’t care bits were put together and came up with Table 2-5.

When I put the ‘‘Sound Alarm’’ events that had the same don’t care bits together, I noticed that in each of these cases, two of the remaining bits were in common and one bit changed in the two events (which I circled in Table 2.5).

In Table 2-5, you may have noticed that the single changing bit of the original Gray code input sequence has been lost; this is not a problem. The Gray code sequence has served its purpose – it has indicated the initial input patterns which are common with its neighbors. In complex truth tables, you may have to rearrange bit patterns multiple times to find different

Table 2-5 Optimized home alarm truth table rearranged with don’t care event bits moved together.

commonalities. When you do this, don’t worry about ‘‘loosing data’’; the important bit patterns are still saved in the active bit patterns.

Table 2-6 shows what happens when the second don’t care bit is indicated. Since the two events which ‘‘Sound Alarm’’ do not have common don’t care bits, we can’t repeat this process any more. The two events from Table 2-6 can be written out as the sum of products:

Alarm State¼ ðW1!W2Þ

þ ðPW2Þ

This optimized ‘‘Alarm State’’ truth table has reduced our component count to one NOT gate, two AND gates and one OR gate and executes in five gate delays – quite an improvement from the original 43 gates and 11 gate delays! Depending on how cynical you are, you might think that I ‘‘cooked up’’ this example to come up with such a dramatic improvement. Actually, the application shown here was my first attempt at coming up with a logic circuit to demonstrate how optimization operations of a logic circuit are performed; you will find similar improvements as this one when you start with a basic logic circuit and want to see how much you can reduce it.