Project #3 : HEX Decoder/Display Driver

---

• The Project -- This is the project file for this one.
• The First Solution -- This is solution #1
• The Second Solution -- This is solution #2 (preferred)
• A Brute Force Solution -- Not recommended but educational.

Show a hexadecimal digit on a 7 segment LED display, allow the display to be blanked (all segments off) and tested (all segments on) at any time. This project is a purely combinatorial project. Easy right? BZZZT! Actually the project is quite easy but the way it turned out took me on an interesting side trip.

If you're using the XESS board you can use the display on that board, but if you're using the BED-SPARTAN2+ you will need to add a plug-on board with a display. You will also need some way to enter a 4 bit value.  

Now go do the project and come back here. :-)

The interesting bit started when I looked at the synthesis report from the WebPACK ISE software. When synthesizing the first version it came back with this:

========================================================================= HDL Synthesis Report Found no macro ========================================================================= Starting low level synthesis... Optimizing unit <hex_display> ... Building and optimizing final netlist ... ========================================================================= Final Results Top Level Output File Name : hex_display.edn Output Format : EDIF crit : Speed Users Target Library File Name : Virtex Keep Hierarchy : NO Macro Generator : Macro+ Design Statistics # IOs : 13 Cell Usage : # BELS : 26 # LUT2 : 5 # LUT3 : 2 # LUT4 : 14 # MUXF5 : 5 # IO Buffers : 13 # IBUF : 6 # OBUF : 7 =========================================================================

Now look at those numbers carefully, 26 logic elements to synthesize a stupid display decoder? Are they nuts? So I figured, "Ah... its optimizing for speed so it is spending gates to shorten propagation paths." Thus I changed the preference for Area in the Synthesis->Properties menu. Ran it again and guess what, same result. Only now it says 'crit   AREA' rather than speed. 

Now I knew that this could be done in fewer gates because I could do it with logic similar to the Xilinx CLBs with fewer gates. Remember Karnaugh or K-maps ? The Xilinx base architecture has something that they call a Complex Logic Blocks (CLB). This CLB is really a 16 bit RAM that, because it is RAM, can "pretend" that it is any combinational logic that can be expressed as 4 inputs and one output. It does this by filling the RAM bits with the truth table of desired function. Complexity isn't an issue as any 4 input truth table should take one CLB. 

Looking at the hex decoder spec yet again you notice that you could express it as 7 independent logic functions, each taking six inputs (TEST, BLANK, and DATA[3..0]). And the output being a segment. 

Now the interesting thing is that you can think of each segment independently as a function of four input bits (the display value) and if you label the display value bits ABCD, then you can write the K-map for the "A" segment as follows:

AB \ CD	00	01	11	10
00	on	off	on	on
01	off	on	on	on
11	on	off	on	on
10	on	on	on	off

You could no doubt minimize it but you can see that these four inputs produce one output (segment A). Now, let's call that output DATA and notice that the truth table for the LED attached to the segment driver function is:

BLANK	TEST	DATA	OUTPUT
"on"	don't care	don't care	off
"off"	"on"	don't care	on
"off"	"off"	output of segment function	data

This second function is another function of three input variables and one output variable.

What that implies is that unless you were not trying, you could get the circuit to fit into 7 CLBs to hold the segment functions and 7 CLBs to hold the selection function. That is 14 CLBs or one half what the WebPACK ISE tool was getting.

If you instantiate a lot of displays you will waste a lot of your FPGA.

So I wrote it the second way, and while the synthesizer liked this one better, it wasn't that much better. In fact the result is shown here:

========================================================================= HDL Synthesis Report Found no macro ========================================================================= Starting low level synthesis... Optimizing unit <hex1_display> ... Building and optimizing final netlist ... ========================================================================= Final Results Top Level Output File Name : hex1_display.edn Output Format : EDIF crit : Area Users Target Library File Name : Virtex Keep Hierarchy : NO Macro Generator : Macro+ Design Statistics # IOs : 13 Cell Usage : # BELS : 26 # LUT2 : 5 # LUT3 : 2 # LUT4 : 14 # MUXF5 : 5 # IO Buffers : 13 # IBUF : 6 # OBUF : 7 =========================================================================

What I really wanted was an EDIF viewer to tell just what the heck this thing was synthesizing for my simple circuit. I tried reading through it but it was too opaque for me. I then tried writing the same circuit several different ways. Until finally I wrote it using the brute force method, of defining a bunch of little circuits, and then wiring them up together. That got me down to 14 logic units. Which was certainly better than the XST compiler was doing on its own. 

So my local expert says, "But how do the non-free tools work on it?" and so I tried it on a Foundation 3.1i system, the answer, "7 SLICEs." Yes, the Synopsys FPGA compiler synthesized the circuit into seven of the Spartan2 "SLICE" blocks (think of them as super CLBs). 

The bottom line was, you get what you pay for.  Sigh. No one seems to have figured out that you would get a lot more for less if normal people could get access to the specs for less than $250 each. Welcome to the "standards" world. Reminds me of the Lily Tomlin sketch about the phone company, "We don't care, we don't have to, we're the IEEE." 

Previous Project	Back To FPGA Journey	Next Project
Copyright © 2001 Chuck McManis, All Rights Reserved.