Strange issue wih a very simple VHDL code and Spartan 3A Sta

  • Thread starter Francesco Da Riva
  • Start date
F

Francesco Da Riva

Guest
Hi ALL,

my name is Francesco Da Riva and I have recentely bought a Spartan
3A starter kit board.

I have find a strange issue that i not be abble to solve. I
created a very simple greater 2 bit than comparator and connect it
with the switch and the led on the board.

All work perfectelly a part of for the input 1001, the led should
be turn on but it is not.

I try to simulate it on iSim and in simulation all work ok.

Could you help me?


Regards

Francesco Da Riva



VHDL CODE:



library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity gt2 is
Port ( a : in STD_LOGIC_VECTOR (1 downto 0);
b : in STD_LOGIC_VECTOR (1 downto 0);
al : out STD_LOGIC_VECTOR (1 downto 0);
bl : out STD_LOGIC_VECTOR (1 downto 0);
agtb : out STD_LOGIC);
end gt2;

architecture sop_arch of gt2 is
signal p0, p1, p2, p3, p4, p5 : std_logic;
begin
agtb <= p0 or p1 or p2 or p3 or p4 or p5;
al <= a;
bl <= b;
p0 <= (not a(1)) and a(0) and (not b(1)) and (not b(0));
p1 <= a(1) and (not a(0)) and (not b(1)) and (not b(0));
p2 <= a(1) and (not a(0)) and (not b(1)) and b(0);
p3 <= a(1) and a(0) and (not b(1)) and (not b(0));
p4 <= a(1) and a(0) and (not b(1)) and b(0);
p5 <= a(1) and a(0) and b(1) and (not b(0));

end sop_arch;

CONSTRAINTS FILE




#========================================================
# buttons & switches
#========================================================
# 8 slide switches
NET "a<0>" LOC = "T9" | IOSTANDARD = LVCMOS33;
NET "a<1>" LOC = "U8" | IOSTANDARD = LVCMOS33;
NET "b<0>" LOC = "U10" | IOSTANDARD = LVCMOS33;
NET "b<1>" LOC = "V8" | IOSTANDARD = LVCMOS33;

#========================================================
# 8 discrete led
#========================================================
NET "agtb" LOC = "R20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;

NET "al<0>" LOC = "W21" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "al<1>" LOC = "Y22" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<0>" LOC = "V20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<1>" LOC = "V19" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
 
On Jan 9, 11:05 am, Francesco Da Riva <use...@dariva.it> wrote:
Hi ALL,

    my name is Francesco Da Riva and I have recentely bought a Spartan
3A starter kit board.

    I have find a strange issue that i not be abble to solve. I
created a very simple greater  2 bit than comparator and connect it
with the switch and the led on the board.

   All work perfectelly a part of for the input  1001, the led should
be turn on but it is not.

   I try to simulate it on iSim and in simulation all work ok.

Could you help me?
Click to expand...
The first thing you should do is to break the problem into smaller
pieces to try to isolate the problem. Generally there are three areas
where your problem can lie, the input, the output or the processing.
You can effectively separate the I/O from the processing by connecting
one of the switches directly to the LED through the FPGA. If you test
this with each of the four inputs and throwing the switches makes the
LED go on and off, then your problem is in the logic of the code. If
the LED does not toggle with the switches, then you either have a
faulty switch or you have the I/O mapped to the wrong pins.

Any time you have a problem that you can't trace to a logic problem,
you need to simplify the situation to further isolate the bug.

Rick
 
On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote:
The first thing you should do is to break the problem into smaller
pieces to try to isolate the problem.
Click to expand...
I made this tests :
1)Connect each led to each swith, all work properly.
2)Try the same code on anther board, same issue.

Any time you have a problem that you can't trace to a logic problem,
you need to simplify the situation to further isolate the bug.
Click to expand...
I agree with you but in this case I no be able to find any trouble in
each single piece of the puzzle.

Regards
Francesco Da Riva
 
On Jan 9, 2:18 pm, Francesco Da Riva <use...@dariva.it> wrote:
On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote:

The first thing you should do is to break the problem into smaller
pieces to try to isolate the problem.

I made this tests :
1)Connect each led to each swith, all work properly.
2)Try the same code on anther board, same issue.

Any time you have a problem that you can't trace to a logic problem,
you need to simplify the situation to further isolate the bug.

I agree with you but in this case I no be able to find any trouble in
each single piece of the puzzle.

Regards
   Francesco Da Riva
Click to expand...
Sherlock Holmes says that "once you eliminate the impossible, whatever
remains, no matter how improbable, must be the truth". The only thing
left is your logic. You have a number of partial products in your
code. Bring each of them out to the LEDs. If they work ok, then
combine them again. I don't know what the polarity of the LEDs are.
Did you try combinations of switches that would both make the LED
light and go out?

This is not magic. But sometimes the solution is not obvious. In
those cases you have to gather more information to know enough to
figure out the problem.

Rick
 
On 9 Gen, 22:31, rickman <gnu...@gmail.com> wrote:
On Jan 9, 2:18 pm, Francesco Da Riva <use...@dariva.it> wrote:



On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote:

The first thing you should do is to break the problem into smaller
pieces to try to isolate the problem.

I made this tests :
1)Connect each led to each swith, all work properly.
2)Try the same code on anther board, same issue.

Any time you have a problem that you can't trace to a logic problem,
you need to simplify the situation to further isolate the bug.

I agree with you but in this case I no be able to find any trouble in
each single piece of the puzzle.

Regards
   Francesco Da Riva

Sherlock Holmes says that "once you eliminate the impossible, whatever
remains, no matter how improbable, must be the truth".
Click to expand...
:)

 The only thing left is your logic.
Click to expand...
But in simulation the wave form work ok for any Input combination.

 I don't know what the polarity of the LEDs are.
Did you try combinations of switches that would both make the LED
light and go out?
Click to expand...
All combination work properly instead of 1001 combination.
In my code is the p2 signal.

Regards
Francesco
 
On Jan 9, 5:25 pm, Francesco Da Riva <use...@dariva.it> wrote:
On 9 Gen, 22:31, rickman <gnu...@gmail.com> wrote:



On Jan 9, 2:18 pm, Francesco Da Riva <use...@dariva.it> wrote:

On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote:

The first thing you should do is to break the problem into smaller
pieces to try to isolate the problem.

I made this tests :
1)Connect each led to each swith, all work properly.
2)Try the same code on anther board, same issue.

Any time you have a problem that you can't trace to a logic problem,
you need to simplify the situation to further isolate the bug.

I agree with you but in this case I no be able to find any trouble in
each single piece of the puzzle.

Regards
   Francesco Da Riva

Sherlock Holmes says that "once you eliminate the impossible, whatever
remains, no matter how improbable, must be the truth".

:)

 The only thing left is your logic.

But in simulation the wave form work ok for any Input combination.

  I don't know what the polarity of the LEDs are.
Click to expand...
If you don't know the polarity, how do you know when it should be on
vs off?


Did you try combinations of switches that would both make the LED
light and go out?

All combination work properly instead of 1001 combination.
In my code is the p2 signal.
Click to expand...
I think you are saying that you have been able to activate p0, p1, p3,
p4, p5 and the LED lights up? When you input the other nine
combinations, is the LED off? If one of those causes the LED to
light, there is something wrong with your assumptions.

I see you pass the switch inputs back out of the chip. I assume each
of those drives an LED that lights when you expect it to?

There is something wrong, either with your circuit or your
assumptions. Keep tearing it apart until you find something wrong you
can put your finger on.


I think the hardest debug I've ever done was this past summer. The
design was only a little complex, but I had a few bugs that had gotten
past simulation. These were all found in testing with my customer.
Finally we had one problem that defied logic. Because it shouldn't
have been happening, it was very hard to add debug code to try to
figure out what the problem was. I went by the customer's site at
least twice a week for a couple of weeks and was making no ground. In
the third week I had some heavy duty code inserted into the design and
found that the PLL was acting as if it had not been initialized. We
had already gone over the initialization a couple of times and I
verified that he was doing it right... or so I thought. Turns out
even though we had gone over it at least twice, he had not done one
step that loaded the registers in the PLL.

The point is, when debugging, challenge all of your assumptions.

Rick
 
On Jan 10, 5:05 am, Francesco Da Riva <use...@dariva.it> wrote:
Hi ALL,

my name is Francesco Da Riva and I have recentely bought a Spartan
3A starter kit board.

I have find a strange issue that i not be abble to solve. I
created a very simple greater 2 bit than comparator and connect it
with the switch and the led on the board.

All work perfectelly a part of for the input 1001, the led should
be turn on but it is not.
Click to expand...
Look at the report files, and check the reduced logic
(try more than one target)

Should be along the lines of this

agtb = ((!b_1 & a_1)
# (a_0 & !b_0 & a_1)
# (a_0 & !b_0 & !b_1));

If it sims, this has high probability of being what you see.

Next, draw a table of ALL the bench-test values, (as here you do not
have many) - then work backwards to see what has dropped, or been miss-
mapped.

My guess is, you have a_1, a_0 swapped, and you forgot to test all
the expected-negative cases as well ? ;)

-jg
 
Hi All!!!

I found it!!!

I test with this architecture

architecture boolean_arch of gt2 is
begin
agtb <= '1' when a>b else '0';
al <= a;
bl <= b;
end boolean_arch;


but the problem remian identical so I cheked the UCF file and find the
problem!!!

I mapped the switch bad, with the MSB on the right side :)

This is the right UCF:

========================================================
# buttons & switches
#========================================================
# 8 slide switches
NET "a<1>" LOC = "T9" | IOSTANDARD = LVCMOS33;
NET "a<0>" LOC = "U8" | IOSTANDARD = LVCMOS33;
NET "b<1>" LOC = "U10" | IOSTANDARD = LVCMOS33;
NET "b<0>" LOC = "V8" | IOSTANDARD = LVCMOS33;

#========================================================
# 8 discrete led
#========================================================
NET "agtb" LOC = "R20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;

NET "al<1>" LOC = "W21" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "al<0>" LOC = "Y22" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<1>" LOC = "V20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<0>" LOC = "V19" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;


Thanks to all for the support


Regards

Francesco Da Riva
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top