Spartan3: INIT_B doesn't go LOW after PROG_B goes LOW in 2% of cases

Hi All,

I have a big system which uses more than 1000 Spartan3 FPGAs. The chips are configured either remotely via a dedicated communication interface, or downloaded automatically from FLASH by simple state machine based on another programmable device.

The problem is, that in some cases (probability of c.a. 2%) the INIT_B doesn't go down after PROG_B is set to LOW. When I retry to reconfigure the chip in which the problem occured (without power cycling), the problem usually disappears. However sometimes, INIT_B doesn't go LOW during a few consecutive retries.

What can be the cause of the above problem? It seems, that JTAG pins are correctly pulled up (I've heard, that they may disturb the configuration problem).

--
TIA & Regards,
Wojtek Zabolotny
Reply to
Wojciech Zabolotny
Loading thread data ...

I have found the following post:

formatting link
So as I can see it was more common problem.

In the part of my system I have switched to monitoring of the DONE line instead of the INIT line to detect, that the device have been deconfigured. Unfortunately in some chips the previous policy is almost hardcoded (they are the FLASH based CPLDs, which must be removed from the system to be reprogrammed).

Reply to
wzab

post:

formatting link

This really doesn't sound right. In the post you link to, one guy had a problem, another guy gives him bad information and a third gives him some good advice which is not replied to. I don't see where this shows that this issue is at all "common".

Configuration of FPGAs seems much more complex than it really is. The operation of the INIT and DONE lines involve certain time delays and conditions. For example, the INIT signal is not immediately brought low when PROG is brought low. It takes a bit of time, I forget how long, but it is in the data sheet. Are you checking this in a program which may be running too fast? Or does the INIT line *never* go low in the 2% of the cases where it fails?

JTAG can override the configuration interface. So be sure that the JTAG signals are pulled to the correct state. My understanding is that the TCK signal should be pulled low, not high to prevent a positive clock edge from being seen on power up. There may be a number of other possible issues in the design. But I would not say it is a problem with the chips...

Oh, that reminds me of a real flaw in the Spartan 3 chips. If you are working with the original chips (not the A or E versions) they ended up with much stiffer internal pullups than was planned. As a result, pulling signals low, like the configuration select pins, may not be low enough if you are using resistors instead of 0 ohm jumpers. I think the maximum value for pull down resistors is around 400 ohms... that's right, not 400K ohms, 400 ohms. To be safe, a 0 ohm jumper is good.

I don't recall if this affects the JTAG signals, but I expect it would. So the TCK signal needs a 330 ohm resistor to ground I think.

Rick

Reply to
rickman

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.