Minimization with a binary to seven segment decoder in Verilog

[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!

 

[berkeman]

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.

 

[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.

 

[berkeman]

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.

 

[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?

 

[Maxwell]

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

Thanks, Berkeman.

 

[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.

 

[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"

 

[berkeman]

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

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

 

[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.

 

[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.

 

[berkeman]

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.

 

[Maxwell]

However, in segment a, it does look like you missed the opportunity to cover 0000 and 0010 with a single box...

Ah, nice catch.

 

[Maxwell]

Ok, so seg_A is now:

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

 

[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.

 

[ranger]

Maxwell, here is a nice little applet that you can use to check your k-maps. Its better if you're in a hurry and can't wait hours for someone here to verify it.

http://www-ihs.theoinf.tu-ilmenau.de/~sane/projekte/karnaugh/embed_karnaugh.html

 

[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.

 

[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.
2) Equation made:

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.

 

[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.

 

[berkeman]

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?

 

[ranger]

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.

This is exactly what I had thought initially in my first reply [it was a little confusing to look at]. he should just stick to A,B,C...

 

[Maxwell]

Ah, I didn't even notice that. Thanks.

I started doing this in VHDL with ModelSim because I know it better.

However, I still think it has to be the way the k-maps are being done. Would the way I had the MSB and LSB before change the output of the k-map? I did it with them reversed and got the same result.

Attached is my testing data.

As you can see, I'm putting in 0110, which should give me 010000.

 

[berkeman]

Weird, and it looks like when you put in 0000, you get 1111111 ?

 

[Maxwell]

Yup! I just can't figure this out.

 

[berkeman]

I'm heading home from work. I can do my own solution tonight at home, and use it tomorrow to check your equations. When is this due?

 

[berkeman]

BTW, since you mapped the 0's did you add an inverter to the output? Maybe it would be worth trying mapping the 1's instead. Maybe that's part of the problem...

 

[Maxwell]

I've got plenty of time, I'll just code it up a different way for now. I'm not handing this part in (it's a small part of a bigger project), so it doesn't really matter how I do it right now.

Do you want my VHDL code?

 

[Maxwell]

BTW, since you mapped the 0's did you add an inverter to the output? Maybe it would be worth trying mapping the 1's instead. Maybe that's part of the problem...

No, I didn't. I'll try that tonight.

 

[ranger]

Hey Max, yea post the VHDL code. I"m only familiar with Verilog, but I'll pop this in Multisim VHDL just to get a feel of what you're doing.

 

[berkeman]

I did some sketching for the 4-bit binary to 7-segment display problem, and have attached some of the work. I haven't checked it in detail, but hopefully it will help. The truth table shows 0's where the segments are turned on, and I K-mapped the 1's for the final equations.

I'll check this against your work (and VHDL code when you post that), when I get a bit more time. Hope this helps.


EDIT -- Hmmm. Guess I should have scanned them in color; that would have been more readable. Anyway, it should give you something to check against.