FPGA not working after programming from EEPROM

Jan 26, 2012 5 Replies

Hi,



I am using xilinx spartan 3 xc3s4000 FPGA in my design interfaced with two gigabit phyters from National and I have xilinx xcf16p EEPROM on board to program the FPGA.


When I program the FPGA using JTAG, everything works perfectly fine. I get the behavior that I expect it to give but when I generate the .mcs file from that .bit file and program my EEPROM, then let EEPROM program my FPGA on startup, my FPGA doesn't work. The DONE signal goes high, I can see the core detected in Chipscope pro, but my FPGA's funcitonality is weird and by weird I mean it doesn't behave as expected. I don't know why is this happening when my .bit file is working fine. My whole system collapses when I use EEPROM. Any ideas ?


Regards



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

formatting link


What about the JTAG pins? Are they pulled up/down? If they are floating, your system may behave erratically. However if you use Chipscope, then probably JTAG pins are driven correctly.

What about the startup clock? What about reset? That's all I can imagine now.

-- HTH & Regards, WZab

Startup clock is CCLK, config clock is default (6). About the reset, It is defined pull down on an IO.

Also, when I program the FPGA using EEPROM, and try to send packets through the phyters, I get very frequent disconnections, which are not there when I program it using JTAG.

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

formatting link

This could be a DCM lock problem. If the FPGA or the oscillator drift after power up, then the DCM can lose lock. If you don't have a reset circuit, the DCM will not attempt to re-lock. In the JTAG programming case, the main difference may be waiting until the board has warmed up. You can test this theory if you re-program the FPGA via the EEPROM after it has warmed up. An easy way to do that is to momentarily ground the PROGRAM_B pin.

-- Gabor

salimbaba wrote:

I will look into that on the weekend. Btw I lowered the Configrate from default(6) to 3 and it got programmed and working fine. Thanks a lot.

through

when I

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

formatting link

I'm guessing that the lower configrate extended the configuration time enough for the external stuff to become stable. Since you could see the ChipScope core when the FPGA did not run correctly, it's unlikely that the issue was with the bitstream loading itself.

-- Gabor

salimbaba wrote:

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required