Xilinx Spartan FPGA : Strange Errors

Hi,

I wonder if anyone has seen something like this.

I have an FPGA design targeted at an Spartan xc3s1500 and using ISE8.2.

We are using a spartan evaluation board with some 7 segment LED's.

If I make minor changes to the pinout, sometimes the FPGA stops functioning completely. What is interesting, is that the 7 segment LED's are not driven. The VHDL code for this is :

p_seven_seg : process(clk system_reset_n,)

begin if(system_reset_n = '0')then seven_seg_1

My guess is that you're downloading the bitstream, watching it work, making a small change, downloading it again, etc., etc.

There are situations where the second (and subsequent) bit stream loads just don't work. This depends mostly on your programming method and hardware.

Try removing the power from the FPGA completely before doing bitstream loads.

G.

Hi Steven, Your VHDL is missing an 'end if' I think, and you should use numeric.std, it's much nicer.

Have you 'loc'ked all the pins in your design? Does your design meet the timing?

HTH., Syms.

-Just out of curiousity, why are you changing the pin outs?? For an eval board, many pins are hard-wired to chips, LEDs, etc, and so the pinouts must _not_ be changed! You do have flexibility if FPGA pins are connected to expansion connectors.

for this is :

Bug 1 - p_seven_seg : process(clk system_reset_n,) There should be a comma (,) between "clk" and "system_reset_n". Remove the comma before ")". Bug 2 - elsif(clk = '1' and clkt'event) then OK, is the clock named "clk" or "clkt" ?? An alternate form is elsif rising_edge(clk) then

HTH

-Dave Pollum

code for this is :

Hi,

Sorry for the confusion - the VHDL was cut and pasted (and simplified). I wanted to simply show how "simple" the functionality that is not working. It does compile (and the FPGA works 90% of the time)

Anyway, to other points, the eval board has expansion connectors where we can add eval boards and connect to test equipment. This is why I change the pinout.

The design is timing clean (which of course depends on me constraining it correctly). However, even with timing problems I would expect the above logic to at least drive the O/P's.

I haven't locked all I/O's down - I will try this tomorrow.

One more note. I have an O/P bus called DVDD. Is this likely to be an issue for the Xilinx tool chain (it works most of the time).

Thanks,

Steven