09-28-2011 02:38 PM
I have a PCB with two XC2S100 FPGAs dasy-chained and a setup to configure these devices a couple of different ways. I have been successful at configuring the chain using JTAG and have used this method to finish the development of my firmware. I am now trying to use a single XC17S200A OTP to configure the chain on power-up, but it doesn’t seem like the design is being loaded onto the FPGAs.
I have attached a schematic of the connections relevant to configuration and here are some details about the design:
* I am using Xilinx WebPACK 10.1 to generate a programming file for each Spartan II device
* Configuration Options: Default (pull ups on configuration pins)
* Startup Options: Default (Enable Internal Done Pipe – Not selected, FPGA Start-Up Clock – CCLK, DriveDone pin High – Not selected)
* I am using the PROM File Formatter from IMPACT to generate a single .mcs file from two .bit files (following the procedure to add devices):
Calculating PROM checksum with fill value ff
Format Mcs86 (32-bit)
PROM start 0000:0000
PROM end 0003:33ff
PROM checksum 00f26762
Addr1 Addr2 Date File(s)
0000:0000 0002:faf7 Sep 26 13:36:34 2011 C:/Documents and Settings/K_Enriquez/XILINX Projects/PLC_REM_IO_1TEST/rem104ch.bit
* I am using an ADVIN PILOT programmer. After selecting the correct PROM from the device list, I load the .mcs file and select a HEX format. I also select the option to program the RESET polarity to active low.
* The device checksum after verification matches the PROM file checksum reported in the .prm file
This is the first time I try to configure a daisy-chain from a PROM, so I am not sure if I am missing a setting when I generate the .mcs file or if I need to use a different format. In a previous post somebody mentioned that changing the format from HEX to Binary solved the problem. Is this right?
If the setup I have is correct, my next step is to put a scope on the configuration pins to see if this is a hardware or signal integrity problem. What is the best place to start when doing this?
Thanks in advance.
Solved! Go to Solution.
09-29-2011 12:56 PM
I found a soldering error on the board that was setting one of the mode pins on the master to the wrong value. This did not affect Boundary Scan configuration since it is independent of mode selection. The setup described above works for both Boundary Scan configuration and configuration from a serial PROM.