FPGA not getting programmed

Hi, I am using a custom board design in which i have 2 FPGAs (spartan 3 xc3s4000) and an EEPROM xcf16p daisy chained together. The chain is like this:

EEPROM -> FPGA1 -> FPGA2

Now the problem is that when i try to program the FPGA using JTAG, my DONE goes high, INIT_B stays high and PROG_B stays high after config, iMPACT says program succeeded but FPGA doesn't work. If i run chipscope, it says 0 cores found.

Same goes when i try to program FPGAs using EEPROM. I have tried in daisy chain and even programming the FPGAs individually by disconnecting them from the chain.

Now there's another dynamic to this problem, i have a previously built .bit file, when i program the FPGAs using it, they get programmed. But if i try to program the FPGAs with any other .bit file, they don't. I am clueless now and i cannot find the problem.

I need help here..

Thanks regards

--------------------------------------- Posted through

formatting link

Reply to
salimbaba
Loading thread data ...

unless the 2 FPGAs are identical, the first problem I can see here is that XCF16P (16 MBit) is not big enough to store the configuration bits for both FPGAs (11,316,864bits) .. see page 86 of UG332

Reply to
mit

like

The FPGAs are identical and i am trying to configure only one FPGA at the moment using JTAG. So, EEPROM signals can be ignored for now.

--------------------------------------- Posted through

formatting link

Reply to
salimbaba

As you have a bit file that does work, could it be a pin constraint problem? (worng UCF file, no ucf file...) could it be that the bit file you are using is not actually the file you intended to use? (impact pickin up the bit file from an other folder?)

Reply to
mit

E
0

it

y

Had this problem about four years ago. From memory, done is connected to both FPGAs with a single pull up. If you program one device using JTAG it lets go of done but the other unprogrammed device still pulls done low and config says that it has failed.

Program FPGA A. A lets go of done but B still pulls it low and the final bit of jtag says that it has failed (done is still low). Program FPGA B. B lets go of done which can now go high and B is configured correctly. Now program A again and it drives done low, configures, lets go of done and now knows that it has configured correctly.

Colin

Reply to
colin

like

DON=

says=

daisy

.b=

tr=

clueless

Colin, i have already done that, no success. On some .bit files it gets programmed,otherwise it doesn't. I saw in FPGA editor that xilinx XST sometimes maps my signals on to INIT_B pad, was wondering if it could create problems. I am not mapping any signal on the INIT_B pad, xilinx maps it i don't know why.

--------------------------------------- Posted through

formatting link

Reply to
salimbaba

T
m

ps

Which signal is being mapped on to the INIT_B pad? And where did you constrain this signal to be LOC'ed to?

You are using LOC constraints on all of your I/O right?

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

It is an IO which i didnt LOC'ed so INIT_B was mapped on to it.And i am not using LOC constraints on all the IOs ..

--------------------------------------- Posted through

formatting link

Reply to
salimbaba

ot

Creating a design to be downloaded into a board without fully LOC constraining all of the IO is just asking for trouble and can potentially damage the FPGA or another device on the board.

You need to fix this ASAP and it will very likely resolve your original problem.

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

you

n=

okay i'll fix it and then update you. Thanks

Regards

--------------------------------------- Posted through

formatting link

Reply to
salimbaba

u

not

Ed's point is very much valid. You should fully Constrain all the IO signals in your design before you start implementation. I have faced this problem long back. Every board has specific pins for JTAG interface, but if you don't constrain your IOBs, it may end up in using these JTAG specific IO's by your normal logic IO signals.

-- vasu

Reply to
vasu

you

am not

Some older FPGA families did not use dedicated JTAG pins, but all modern FPGAs do have dedicated JTAG pins.

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

d you

i am not

I faced this problem in Virtex-6 FPGA based design.

Reply to
vasu

I guess modern FPGA's have just sw dedicated jtag pins.. At least Altera's can be used as IO through megafunctions (like sld_virtual_jtag). I agree that's the way to do it instead of letting them loose as generic io.

Reply to
Morten Leikvoll

I am wondering if have two FPGAs being programmed from the same EEPROM is even a valid JTAG structure? Someone please correct if I am incorrect and has designed a working system this way before. I would almost lean towards having the JTAG chain only be

EEPROM -> FPGA1

Then have FPGA1 read the bit stream out of EEPROM and program FPGA2. Therefore you don't have bus contention between the two FPGAs. FPGA2 is then like a ghost FPGA on the JTAG chain.

Does this seem logical? I have just never heard of one EEPROM being dedicated to two FPGAs before with identical bit files.

Reply to
Dustin Brothers

a valid JTAG structure? Someone please correct if I am incorrect and has designed a working system this way before. I would almost lean towards having the JTAG chain only be

you don't have bus contention between the two FPGAs. FPGA2 is then like a ghost FPGA on the JTAG chain.

to two FPGAs before with identical bit files.

Actually it is quite common to use a single PROM or flash to program multiple FPGA's. This connection scheme is shown in the Spartan 3 Generation Configuration User Guide.

From the other posts in the thread, it seems more likely to be a problem with bit file generation rather than the board-level connections.

-- Gabor

Reply to
Gabor

Gabor,

Ok awesome, thanks for the clarity. I have never designed a system in this configuration which is why I was asking :)

-D

Reply to
Dustin Brothers

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.