Hi everybody,I am experiencing a strange behavior on my design. The USB JTAG programmer detects the two devices, reads the IDs, programs them correctly, and the contents are verified. Evrything is perfect. But when I power up the FPGA fails to load its config from the prom device.
After reading the other posts, I found that Bob Elkind (thanks Bob) suggested to connect a switch for force reloading the config. It doesn't work.
I checked with a scope and found that the CCLK signal is generated, so the init sequence takes place. I have been using the same schematics in two previous designs and it works.Any clever or most stupid suggestion will be welcome at this stage!!Thanks to allJean Louis. The only thing obvious is that you have some pull-up resistors going to 2.5V while the XCF02S is running with Vcc of 3.3V. You may want to check that these signals meet the Vih requirements of the PlatformFlash.Are you able to directly program the FPGA via JTAG? If not I suspect there may be a problem other than just the way the flash is hooked up.Also your schematic shows one flash device but the text says 'Piggyback.' Are you actually using two XCF02S devices? If so how are they chained together?
Gabor, first thank you for replying.the pull-up resistors going to 2.5V are explicitely described in the Xilinx app note DS312, page 72, and the piggyback is a very small PCB board that plugs into the mother board for easy PROM swapping when required on a customer site. I am using only one XCF02S device, and I am sure of the connections of this piggyback board (already used twice in previous FPGA designs) (see pic).And yes, I can program the FPGA via JTAG. Strange behavior.THANKS again, I appreciate.JEan Louis. This is an interesting post. So I took at look at DS312 (July 19, 2013), figure 51, page 71 that the OP referenced. This figure shows a 2.5v JTAG interface, and not a 3.3v JTAG interface. The figure shows the PROM's VCCJ at 2.5v.
It shows the 3E's VCC02 at 3.3v. Because the PROM's VCCJ supplies power to the PROM's TDO driver and to the TCK, TDI, and TMS input buffers, it would appear that in the OP's circuit that those pins do not meet VIH for his PROM.But then, I took a look at UG332 (Oct 26, 2009), figure 3-1, page 80, and it looks similar to the OP's circuit, with the exception that the FPGA is first in the chain. Digilent's NEXSYS-2 Spartan-3E board's configuration schematic also looks similar to UG332 figure 3-1.So it looks to me that the OP's circuit should work, if I've read all of the docs correctly. Since it doesn't, I guess I'm confused. Can you check the state of INITB when the board has powered up but fails to program?
Normally it should start up low and go high just before CCLK begins to toggle and then stay high. If it goes back low, that would indicate that there is a CRC error. I have seen this when the.mcs file for the serial PROM was prepared incorrectly (bits need to be swapped for serial platformflash).
Ruby Autoload
CRC errors can also happen if there is a signal integrity problem on CCLK which could cause the flash to put out more than one bit per CCLK cycle. This would be easy to scope on since it usually shows up as transitions on DIN for both edges of CCLK.
Autoload Pro 2008 Serial Key
Fixing this sort of issue is usually easy, too. Either by inserting a series terminating resistor near the FPGA CCLK pin, or parallel termination resistors or RC network at the flash chip. Just to answer your other question, the.bit file format saves a bitstream with 8 bits per byte. When a Xilinx device configures with any serial protocol (i.e.
1 bit at a time) it wants to receive the MSB (bit 7) from the byte first. This also happens to be the order that bits shift out from a SPI flash. However the PlatformFlash serial devices like XCF02S shift out the LSB (bit 0) of each byte first. That means that when Impact prepares the.mcs file for these devices it needs to reverse the order of bits (7 0, 6 1, 5 2, 4 3) within each byte with respect to the way they come from the.bit file. If you don't do this bit reversal, then the device won't program and typically you will see the symptoms of CRC error. Impact will do this bit swap by default when you tell it to prepare a bit file for a 'Xilinx PROM.'
In any case this was not your problem, but it has bitten me in the past.