Verification errors using Xilinx Spartan 3E board


I have been working on a design lately where I use a the Xilinx Spartan

3E starter kit board. I use a logic analyser to check the output on some signals which are assigned to the boards' J1, J2 and J4 connectors. Sometimes, I get some of the signals to not even be "connected" on the external pins. When this happens, I find that going in to the VHDL code and adding a few changes that are usually never related to the signals I want to observe in the first palce, fix things for me.

Lately, I have tried verifying the FPGA after downloading a newly generated configuration to it. The verification came back with 3076 errors. When I look at the logic analyser trace, it seems to provide "most" of the signals except for one one that should be there but it is not.

Is there a way to obtain more info as to why thee would be so many errors during the programming of an FPGA? Are there some settings I may not be using correctly in the tool that causes the recompile to not be as clean as I think it should? Does the verification process pick up noise on te programming cable (I use the USB cable in this case)? Could the FPGA be damaged (static perhaps)?

I guess I am curious as to why this is happening. Most of the time things seem to work fine, but on the odd compile, something disapears.

Thanks for any help/hints.

Reply to
Jack Zkcmbcyk
Loading thread data ...

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.


David Ashley      
Embedded linux, device drivers, system architecture
Reply to
David Ashley

David Ashley schrieb:


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


Reply to


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:

Reply to
Ira Hart

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,


Reply to
John Williams

John Williams schrieb:


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.


Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.