Wrong Truth Table for 2 bit comparator using 2 inputs and 3 outputs

Question

I am making a 2 Bit Comparator with 2 inputs and 3 outputs. I wrote the following code in VHDL and when I created schematic using Xilinx, it showed the wrong truth tables and K maps for all of them. Here's my code:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity comparator is
    Port ( a : in  STD_LOGIC_VECTOR(1 downto 0);
           b : in  STD_LOGIC_VECTOR(1 downto 0);
           a_lt_b : out  STD_LOGIC;
           a_eq_b : out  STD_LOGIC;
           a_gt_b : out  STD_LOGIC);
end comparator;

architecture Behavioral of comparator is

begin

a_lt_b <=    (    b(1) and not a(1))
              or(    b(1) and     b(0) and not a(0))
              or(    b(0) and not a(1) and not a(0));

a_eq_b <=    (not b(1) and not b(0) and not a(1) and not a(0))
             or (not b(1) and     b(0) and not a(1) and     a(0))
             or (    b(1) and not b(0) and     a(1) and not a(0))
             or (    b(1) and     b(0) and     a(1) and     a(0)); 

a_gt_b <=    (not b(1) and     a(1))
             or (not b(1) and not b(0) and a(0))
             or (not b(0) and     a(1)  and a(0));


end Behavioral;

So what is your question? You already know that the table is false, why don't you fix it? — Paebbels, Aug 16 '15 at 17:00
Your results are not in evidence here. Your question doesn't demonstrate a specific issue that can be reproduced, it's not verifiable. See [How to create a Minimal, Complete, and Verifiable example](http://stackoverflow.com/help/mcve). — , Aug 16 '15 at 17:04

scary_jeff · Answer 1 · 2015-08-18T09:32:24.807

You have written your code in a pretty obtuse way. Why don't you write lines like:

a_lt_b <= '1' when unsigned(a) < unsigned(b) else '0';
a_eq_b <= '1' when unsigned(a) = unsigned(b) else '0';

To do this, you need to use the numeric_std library at the top of your file:

use IEEE.NUMERIC_STD.ALL;

With this in place, there's far less chance of making a mistake of the kind you could easily have with your explicit and, not, or combinations (which I did not take the time to check). Another benefit is that it's obvious straight away to anyone else reading your code what it is trying to do. Lastly, writing the code like this means that it automatically adapts to any change in the width of the operands.

Having done this, you really don't need to dig around in the resulting schematic to check whether the tools have done exactly what you thought they would. The tools are very good at mapping your code efficiently into the hardware, so you can usually trust them to do the right thing. There are a few cases where it can be valuable to check the schematic:

You want your code to infer a particular element in the FPGA, for example a memory or multiplier block; the schematic can be a quick way to see that this has happened.
There is a timing closure problem, and you want to understand exactly how the tools have implemented your code.
Your device is running out of space or is using more of a particular resource than you thought; the schematic might show, for example, that discreet registers were used, when you thought a shift register could be used for a particular signal.
The designs works in your simulation, but not when it comes to the real hardware, and you suspect a bug in the tools. In a rare circumstance you might be able to go through the schematics carefully and discover a bug, but it's more likely that in doing this, you will discover some sort of design error. Either way the schematics can be useful in this case too.

In summary, use the language to make simple descriptions of functionality, and trust the tools to do their logic optimisation job.

How can you tell there's an error in his VHDL code without knowing the results that were produced? '... of the kind you could easily have with...' is speculation. — , Aug 17 '15 at 10:03
I took time to check, See [comparator_test](http://i.stack.imgur.com/uS6aw.png) results. — , Aug 17 '15 at 10:43
@user1155120 it's not speculative to say that large combinatorial statements are more error prone than simple numerical comparisons. Coding style is the only issue presented. — scary_jeff, Aug 17 '15 at 12:50
@user1155120: I don't recognise the waveform viewer - which one is it? — EML, Aug 17 '15 at 15:56
'Having done this, ...' predicates your answer on a particular view of coding style but doesn't address why the wrong truth tables and K maps are produced from a valid, synthesis eligible VHDL design description. That's not surprising, the question doesn't present enough information. (Evan - waveform viewer is [GTKWave](http://gtkwave.sourceforge.net/)). — , Aug 17 '15 at 18:07

Wrong Truth Table for 2 bit comparator using 2 inputs and 3 outputs

1 Answers1