03-10-2014 02:21 PM
[Note: I'm not sure if the Spartan-3 Starter Board is a Xilinx product or 3rd-party... please let me know if I should post elsewhere.]
I have a Spartan-3 Starter Board (this one: http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD) which I have used in my physics research. I want to put a new program on the device PROM, but I get this error when I try to program it using iMPACT:
INFO:iMPACT:583 - '1': The idcode read from the device does not match the idcode in the bsdl File.
INFO:iMPACT:1578 - '1': Device IDCODE : 00001111111111111111111111111110
INFO:iMPACT:1579 - '1': Expected IDCODE: 00000101000001000101000010010011
I'm using a Xilinx Platform Cable USB to connect to the board. I run Windows 7, and I have ISE 14.1. A previous student was able to program the device using this computer, so I really don't know why I can't get it to work.
I have the jumpers on the board set to:
<M0:M1:M2> = <1:0:1> (from the manual: "JTAG: The FPGA waits for configuration via the four-wire JTAG
JP1: "Disable" (from the manual: "Jumper removed. Platform Flash is disabled. Other configuration data source
provides FPGA boot data.") (It doesn't seem to matter what I set this to, but who knows, maybe this information is important.)
This is what I do in iMPACT after I generate a .bit file in ISE:
03-10-2014 03:02 PM
I think there's some restrictions on new users that may have prevented your images from posting correctly. However the symptom showing up in your Device ID code looks a lot like a signal integrity problem on the JTAG chain itself. The fact that the detected ID code has long strings of 1's followed by long strings of 0's implies there may be a bad signal connection on TMS or perhaps poor signal quality (ringing) on the TCK signal.
If the same board and cable works well on another computer, it is also possible you have a driver issue. There was a new answer record about Impact and drivers posted just today. There could also be some issues if you had at some time installed the Digilent cable drivers (same guys who made your board) and then use the Xilinx software and cable.
03-10-2014 03:09 PM
Have a look at the below link
03-10-2014 03:39 PM
That's too bad that the images won't load--they show up for me! Thanks for taking a look anyway.
There are definitely also Digilent drivers and cables installed on the computer I'm using. I've tried to program the FPGA with the Digilent software (Adept) and a Digilent cable, but that also failed for different (?) reasons. I wasn't able to initialize the JTAG chain with the Digilent cable because whenever I tried to talk to it (in Adept or in iMPACT, using the Digilent plugin), I immediately got an error from Windows saying that the device had malfunctioned and was stopped. I then had to unplug the cable and plug it back in before it would be recognized. If the Digilent and Xilinx drivers could be in conflict, what's the best way to totally purge one or the other?
I can look at the JTAG chain with a scope, as in the thread yenigal linked to below, but I wouldn't really know what to look for. If there were a signal integrity problem in the JTAG chain, would that be something I could fix myself?
03-11-2014 08:49 AM
Update: I was able to get a Digilent USB JTAG cable to intialize the chain after a firmware fix, but I still get the same 583 error in iMPACT when I try to program/read the device ID/anything.
Also, the only device I see in the JTAG chain is the xcf02s... should I see other devices, e.g. the FPGA?
03-11-2014 09:05 AM
I modified the .bsd file for the xcf02s, changing the expected IDCODE to what iMPACT was getting. This stops the 583 error, but now I get
// *** BATCH CMD : identifyMPM
INFO:iMPACT - Current time: 3/11/2014 11:02:55 AM
// *** BATCH CMD : ReadIdcode -p 1
Maximum TCK operating frequency for this device chain: 0.
INFO:iMPACT:1206 - Instruction Capture = '1111111100000001'
INFO:iMPACT:1207 - Expected Capture = '10101010XXXXX001'
INFO:iMPACT:2130 - Boundary-scan chain test failed . Please check tdi->tdo connection between the cable and device:'1' ( 'xcf02s').
A problem may exist in the hardware configuration.
Check that the cable, scan chain, and power connections are intact,
that the specified scan chain configuration matches the actual hardware, and
that the power supply is adequate and delivering the correct voltage.
I guess that's another sign that it's a hardware failure?