# Spartan 6 FPGA IO changes state disregarding design

Hello I have made Spartan 6 board and now I'm trying to get it work, I have successfully managed to get programming of SPI flash working so I can upload bitstreams, but I have problem that some of IO pins doesn't stay at their desired state.

For example I have 4 IO used to control relays of attenuators (used in oscilloscope module) and when I set state at reset it holds it for 40 nanoseconds and then it gets back to zero.. I even have communication protocol in which I can set IO state programatically through software and it change state but again only for 40ns or so then go back to logical zero.

In simulation everything works as expected, also post par static timing shows that my timing constraints (60MHz clock of FTDI's FT245 and 150MHz clock of ADC oscillator) were met. I have triple checked my UCF if I have not used wrong pins but it's all the same.

I was thinking that I am somehow reseting design (I use FTDI for that) in FPGA but it's not the case because I have hooked scope on reset pin of my design and it didn't triggered. Also other things in my design works, for example I can successfully set reference voltages of ADCs (controlled by DAC) values through serial interface (which is slow - 100kHz) so reset that would kill IO state after 40ns would also stop setting of DAC.

Do you know what could force FPGA to disregard design set IO states?

this is part that sets IOs: (the led1 faintly blinks when this happens)

              when SET_ATTENUATORS =>
led1 <= '0';
state <= IDLE;


and this is IDLE state:

             when IDLE =>
ft245rw <= '0';
ft245strobe <= '1';
ft245dataWaitIn <= '0';
if (to_boolean(ft245busy) and (ft245oe = '0')) then
ft245strobe <= '0';
else
state <= IDLE;
end if;


and this is reference voltage setup state:

              when SET_VREF0 =>
led1 <= '0';
dacVrefTopA <= commandData(72-1 downto 64);
dacVrefBotA <= commandData(64-1 downto 56);
dacVrefTopB <= commandData(56-1 downto 48);
dacVrefBotB <= commandData(48-1 downto 40);
if to_boolean(dacBusy) then
dacStrobe <= '0';
state <= SET_VREF1;
else
state <= SET_VREF0;
dacStrobe <= '1';
end if;
when SET_VREF1 =>
if to_boolean(dacBusy) then
state <= SET_VREF1;
else
state <= IDLE;
end if;


In this state the led1 also only faintly blinks (it should stay on, not blink) but also only other state that I change state of LED is reset which couldn't happen because that reset would also reset DAC module which would prevent DAC setup module from setting DAC values (it successfully does that).

• The FPGA is only going to do what it is told, so I seriously doubt that the pins are changing value of their own accord. I have a spartan 6 board too and have never seen this behaviour. The most likely scenario is that there is something in the code that is causing this to happen. Could you post the relevant parts of your code, please? – stanri Apr 26 '13 at 11:20
• On Altera devices some pins have several different uses depending on configuration; are you sure you're setting up the pins you are using as user I/O and not some internal function? "dim LED" is telling. – akohlsmith Apr 26 '13 at 11:40
• Pins are set as LVTTL outputs in UCF and there is no complaint about it from P&R. It's BGA so I tripple checked their location.. BGA was X-rayed if it's soldered correctly so it's probably code error, but I have no single clue what could possibly be wrong when simulation is OK. Funny is that more complex interfaces as I2C and 4 wire DAC serial interface are working correctly and simple setting of logic value is not.. – Bruno Kremel Apr 26 '13 at 11:45
• Have you checked the .pad file to check that the tools have actually done what you expected with the UCF file you have so carefully verified? I've seen pin locs disappear from seemingly good UCFs (pin name mistyped, but however many times the UCF was stared at, no-one saw it!) – Martin Thompson Apr 26 '13 at 12:26
• Martin: I'll look into that, thanks ! I didn't know that there is way to check pinout after P&R :) – Bruno Kremel Apr 26 '13 at 13:37

I finally found that problem was that I have been loading the same design over and over.. So I thought that I have design that light the led but there was none.. Now it works as expected. because I thought that *.MCS files are generated only once not that I have to generate MCS file from BIT file every time I change bitstream.. now it is working, my problem now is that some of packets doesn't go intact through FT245.. I'll make simple acknowledge protocol to fix that.

• Just a suggestion... Mark this answer as accepted, and/or edit your question to reflect that it's solved. – darron Apr 27 '13 at 15:44
• I'll do that as soon as stackexchange allows me to do :) – Bruno Kremel Apr 27 '13 at 21:39

Here's one I've seen...

Switching an IO pin caused lots of current to suddenly be drawn (not dissimilar to a relay coil). The power supply browned-out (only for 1 ms), came back and the FPGA reconfigured back to its initial state, including the IO pin now inactive.

(As I started off debugging remotely, I didn't see the current-limit light on the PSU flicker on... all became clear once I went to the lab :)

So I'm assuming commandData is some SPI register from a micro-controller? If this is a new board (and not a proven development board hooked up to some other circuitry), I would start by doing some sanity checks. For example, do you have spare pins? Can you combinatorically (that is, outside of the state machine) do something like:

test_pin_0 <= commandData(0);
test_pin_1 <= commandData(1);


also combinatorically assign adc1relatt and adc2relatt as a test (meaning outside of the state machine - do not even enclose it in a process, just straight up wire the pin to commandData register):

adc1relatt <= commandData(71);


this will show or disregard the possibility of a circuit error (wrong I/O in UCF, blown FPGA driver, something else loading the pin down).

That will at least isolate the state machine portion of your code. For example, it is possible that your clock is basically not working and that your state machine is stuck in an unexpected state. You might not be able to see this just by using SPI commands, as they are clocked in externally.

Also, I noticed that you said the LED faintly blinks even when the pin that is on it is assigned to '0'. What happens when it is assigned to '1'? How do you have the LED wired, is it positive polarity or inverted. Also, is there a current limiting resistor? Finally, what does the .UCF say about the I/O standard and drive level?

Finally, if those states are part of the same state machine, you have an implicit latch on your led1 signal in the IDLE state (unless you have a default value somewhere else), as the value is undefined in this state. This is unlikely to be the problem, but for sanity check sake either put a default value for it at the beginning of the process or assign it to a value explicitly in every state.

• It is actually synchronous FT245 which is proven working because I can successfully send command which makes design program DAC (I tried different values 0x20, 0x80, 0xFF and measured output with voltmeter and these values were correct). It is probably stuck somewhere in state machine, but some parts of it must work because it successfully decodes incoming messages (with all data intact).. I'm going to try insert some led indications of states and I'll see where it stucks.. – Bruno Kremel Apr 26 '13 at 12:37
• And for that blink, it's actually the same 40ns (on 3,3V level which is correct, I have set UCF for LVTTL) peak as those on relay control signals. And diode is connected in way that it is on if I set logic level to '0' (limiting resistor on anode hooked to +VCC and cathode connected to IO pin). – Bruno Kremel Apr 26 '13 at 12:43
• It would be impossible to see a single 40ns pulse. So is the pulse periodic then? What is the period of the resetting....that is, how long does it take in between successive resets. – Zuofu Apr 26 '13 at 12:49
• I also thought that it would be impossible to see but I didn't see successive pulses when I was measuring it with scope.. And also that DAC controller is clocked on 100kHz so it's setting up values for more than half second. – Bruno Kremel Apr 26 '13 at 13:17
• Hmm, that is a bit weird. I think what is happening is that for some reason either the LED is draining too much current, or that pin is being loaded down somewhere else (so that most of the current is going somewhere else on the board and the LED is very barely being lit). It is possible that there is a voltage on that pin, but you can't see it due to the loading. At this point, it is also possible that your problem isn't with the FPGA at all, something else could be loading that pin on the board. Can you check the resistance of that pin to ground on a blank board? – Zuofu Apr 26 '13 at 14:30