# Minimization with a binary to seven segment decoder in Verilog

1. Jun 25, 2007

### Maxwell

Hey guys, I have two questions about something I'm trying to minimize. I'm making a binary to seven segment decoder in Verilog, and I have a truth table set up. The board I'm going to be placing this on is active low.

My questions: I want to reduce, or minimize, this truth table, I was going to do it by each segment. So my inputs b0, b1, b2, b3 would be put on a k-map with respect to each segment.

- Since my device is active low, does that change how I fill out my k-maps? I don't think so, but I haven't done any digital logic design in quite a while. Do I draw my boxes in terms of '0's instead of '1's since the '0's drive my logic? I.e. do I fill out the k-maps backwards?

- When minimized, I will have seven reduced equations. One for each segment. I guess I just don't see the benefit of reducing the equations. Or how it works, even.

I'm going to be implementing this in Verilog, so simply hard coding the inputs to a certain output directly off the truth table is pretty easy.

What will having seven reduced equations for each segment actually do for me?

Thanks!

2. Jun 25, 2007

### Staff: Mentor

Reduced equations will potentially reduce the number of gates required to implement the logic function. And yes, you would write your K-maps with 0's and 1's with the 0's representing output low (turning on the LED segment). Keep in mind, though, that you can also see if it is simpler to generate an inverted signal, and run it through an inverter. Once you draw the K-map for each segment, it should be apparent whether the 1's or 0's (LED off or on) is easier to make.

3. Jun 25, 2007

### Maxwell

Yeah, I knew about the reducing of the logic gates. The thing is, I'm implementing this in Verilog, so it just seems easier to map the inputs right to an output.

I don't really see how I can use each of the seven equations to produce the numbers on the seven segments that I need.

If I'm reducing by segments, and I get seven different equations for each segments, what if I need to turn on two, or three different segments? What about 5 different segments?

Doesn't this get uglier to code than just coding them straight? I.e.:

0000 -> 0000001
0001 -> 1001111
0010 -> 0010010

etc.

And thanks for the filling out the k-map answer. I'll definitely do it both ways - that's a good idea.

Thanks.

4. Jun 25, 2007

### Staff: Mentor

The input to your circuit is the number in binary, and the output is the 7 segment drive lines, a-g. For an input 0. = 0000, you would drive segment cathodes a, b, c, d, e, and f low. For in input 1. = 0001, you would drive segment cathodes b and c low. And so on.

You will have 7 equations, one per segment. The equations determine how the 4 input bits affect the segment drive lines.

5. Jun 25, 2007

### rbj

isn't this what Karnaugh maps are s'pose to be for? especially for multiple outputs that could make use of some common intermediate variables?

6. Jun 25, 2007

### Maxwell

Yeah, I see what he is saying. That makes sense, I have no idea why I wasn't connecting it all.

Thanks, Berkeman.

7. Jun 26, 2007

### Maxwell

Ok, I've just started to work on this, and I would like some verification.

The truth table for the (active low) seven segment display is posted below.

I then did the k-map for the A segment. I'm wondering if my equation turned out correctly. This is attached as an image as well. Sorry it is so blurry, I decided just to take a picture of my k-map with my camera phone.

* I just noticed I made one mistake in the second product. It should be just plain D, not ~D.

Thanks.

#### Attached Files:

File size:
48.1 KB
Views:
140
• ###### 4b_truth_table.JPG
File size:
13.3 KB
Views:
139
8. Jun 26, 2007

### Maxwell

Ok, I've decided to do one more segment before I go to sleep. I've attached my k-map for seg_b.

The equations came out to be:

seg_A = (~AC~D) + (B~CD) + (A~C) + (~A~B~C~D)
seg_B = (~A~D) + (~A~B~C) + (AB~C) + (~C~D)

where ~A is "not A"

#### Attached Files:

• ###### 06-26-07_0537.jpg
File size:
42.1 KB
Views:
112
9. Jun 26, 2007

### Staff: Mentor

LOL. Camera phone. Guess I'll need to do some image processing to view the K-maps. :rofl:

I wasn't able to check the K-maps, but it looks like you are using the correct techniques.

10. Jun 26, 2007

### ranger

Looking at your k-map for seg b (from what little I can see), it looks like you're missing (and adding unneeded) entries.

Segment b will go high when:
input = /A/B/C/D + /A/B/CD + /A/BC/D + /A/BCD + /AB/C/D + /ABCD + A/B/C/D + A/B/CD

[ an "/" precedes and inversion]
Segment b comes on when the input is 0011 (SOP entry #4 above), it looks like you're missing that.
Recheck the k-map and my equation above. I sort of skimmed through your truth table.

EDIT: wait one minute. Is the second attachment for seg_b? I can't make out the heading.

Last edited: Jun 26, 2007
11. Jun 26, 2007

### Maxwell

To make this a little (or a lot) more clear, I redid the k-maps in paint.

I've included a k-map template I made just in case you want to create your own.

The equations I got for each are:

seg_A = (~AC~D) + (B~CD) + (A~C) + (~A~B~C~D)
seg_B = (~A~D) + (~A~B~C) + (AB~C) + (~C~D)

It's quite possible I've added some redundant boxes, especially in seg_B, where I think I added two extra.

Thanks.

#### Attached Files:

File size:
5.7 KB
Views:
111
File size:
7.9 KB
Views:
102
• ###### seg_B.JPG
File size:
8.8 KB
Views:
92
12. Jun 26, 2007

### Staff: Mentor

The extra boxes in segment b don't look redundant. You're just trying to use the smallest terms to cover the outputs.

However, in segment a, it does look like you missed the opportunity to cover 0000 and 0010 with a single box... Always look for edge-connected terms, as you have shown in your b segment K-map.

13. Jun 26, 2007

### Maxwell

Ah, nice catch.

14. Jun 26, 2007

### Maxwell

Ok, so seg_A is now:

seg_A = (~AC~D) + (B~CD) + (A~C) + (~A~B~C~D) + (~B~C~D)

15. Jun 27, 2007

### Maxwell

Well, I coded up the device and it's giving me very wrong outputs.

Do you guys see any problems with the two equations I came up with that correspond to the two k-maps I posted? They are giving me wrong results.

I'm using:

seg_A = (~AC~D) + (B~CD) + (A~C) + (~A~B~C~D)
seg_B = (~A~C~D) + (~A~B~C) + (AB~C) + (~A~D)

for the first two. They are yielding incorrect results in simulation.

Any ideas?

Thanks.

16. Jun 27, 2007

### ranger

Last edited: Jun 27, 2007
17. Jun 27, 2007

### Maxwell

That is a very cool applet, ranger, I'm going to be using that in the future.

However, I'm still getting an incorrect result during simulation. It's driving me crazy.

I'm getting the same result as the applet, entering it directly, and I'm still getting errors.

18. Jun 27, 2007

### Maxwell

Ok, I'm going to do this piece-wise and very explicitly. If you can see where I'm going wrong, please let me know.

For seg_B only:

1) K-map is attached.

seg_B = (A & B & ~C) + (~A & ~B & ~C) + (~C & ~D) + (~A & ~D)

3) Test input (A = 0, B = 1, C = 0, D = 0). Result: '1'

0 + 0 + 1 + 1 = 0 + 1 = 1

4) Result: Wrong. seg_B should be 0 when 0100 is entered.

Thanks.

#### Attached Files:

• ###### seg_B.JPG
File size:
9.8 KB
Views:
73
19. Jun 27, 2007

### ranger

Maxwell, post your verilog code so others can take a look. I can't really do anything right now, maybe I'll get a chance to test your code at work tomorrow and take a proper look at your equations and so on.

20. Jun 27, 2007

### Staff: Mentor

I didn't look in detail, but I think maybe you've got the msb and lsb swapped in your binary input data. Your original truth table kind of bothered me a little when I saw it, because it listed b0 b1 b2 b3, which looks like you've put the lsb b0 on the left. The more traditional way to order the bits would be b3 b2 b1 b0, with the msb on the left.

So in your notation when b[0:3] = 0100, that is equal to decimal "2", which does have the b segment off (=1).

Like I said, I didn't check this out in detail, but could that be the issue?