Verification errors using Xilinx Spartan 3E board

My spartan-3e Rev-D has performed flawlessly for me, no unpredictable behaviour as you describe. Recently I'm using the xup-0.0.2 + XC3Sprog approach described here earlier (bypass Impact + reprogram CPLD and use a linux utility to download the bitfile image in 8 seconds). Either before with windows/impact or now with linux have I ever experienced a failure to download the bitfile intact. Hope this data point is useful. Note I'm using the USB interface also.

-Dave

David Ashley schrieb:

Jack,

I have seen FPGA verification errors once (this was also an S3e board designed by Digilent) - and that was defenetly proven damaged FPGA. It did take me long time to understand that, I even optimized some simple counter HDL to be more 'fault tolerant' eg to work in that damaged FPGA.

So something is badly wrong, either damaged FPGA or partially malfunctioning power supply, or maybe your design takes too much power and those causes power supply spike so heavy that configuration is lost.

whatever the reason - STOP trying out any designs loaded into the FPGA as long as the verificiation errors are not gone.

config verification *MUST* pass or your design can have any undesired unpredictable behavior

Antti

Jack,

If I understand you correctly, you are saying that some internal signals that you expect to be at certain chip IO are not there.

I've had problems like that before when signals were NOT asigned in the ucf file. If that is the case, Xilinx will randomly assign these signals for you. I believe the assignment will change at each place and route based on internal logic used.

Check your .ucf file.

Good luck. Ira-

Jack Zkcmbcyk wrote:

Try setting the FPGA Mode jumpers to JTAG. By default I think they are in master serial (to configure from the platform flash parts). A few people have reported problems to me doing JTAG configurations on these boards when the contents of the platform flash PROM does not match the bitstream you are downloading. I also saw this on older V2-1000 boards as well.

Hope this helps,

John

John Williams schrieb:

John,

non-JTAG mode settings do cause configuration problems - it happens when SYNC is 'seen' at specific time slot within the JTAG sequence, it resets the configuration logic. For early Spartan3E silicon placing a bitststream at low offset rendered the device non programmable over JTAG The fix for that required changing mode pins or to use special programming software from Xilant that placed the parallel flash into CFI command mode during the JTAG configuration and allowed the chip to reconfigured without the need of the mode pin change.

This kind of errors however should yield to Programming error, not to succesful programming with verification failing.

If a part gets programmed ok, done ok, and then afterwards gets verification errors, specially when there is different amount of the errors, then it can be indicator of serious problem with the FPGA.

Antti