Has anyone worked with a 3AN design? The Xilinx documentation is a little convoluted, and I want to do a sanity check.

As I understand it, you set the M[2:0] bits to 011 for internal SPI boot or 101 for JTAG, and pull PROG_B down, then up to program.

-Can PROG_B be tied high, requiring a power cycle to start configuration? It appears to require a delay. I was hoping to avoid POR circuitry...
-Do the M bits really need to be twiddled? I was assuming (for some reason) that JTAG boundary scan was always active? That is I don't need to boot from JTAG; I do need to use it sometimes, to write the flash..
-VS[2:0] bits appear to be pulled up and not do too much... Can I just leave them disconnected?
-I am grounding SUSPEND...
-Am I forgetting anything else?
EDITED...
Main question is this: can I set the M bits to 011 for internal boot, and still use the JTAG interface to reprogram the internal SPI flash? It seems so...

Thanks for any insights. I am still waiting for the breakouts to be fabricated (any day now)...

Use the Spartan 3AN family quite regularly.

I always recommend a POR circuit. A delay is required to ensure voltages are stable, but with the power system I've been able to employ, this is not an issue. This allows me to connect a PU to nPROG and a 2-pin jumper or PB switch.


The internal configuration engine will automatically enter a configuration cycle. The type of cycle depends on the settings of the mode pins. The pins are sampled by the FPGA after nPROG is released. If the designer wants to delay configuration, there are a number of ways to do that, and holding nPROG is one. Configuration will not start until nPROG is high, the on-chip voltage detection circuit has qualified the voltages, and the internal configuration memory has been cleared. At this point, the mode pins are sampled, and the configuration engine proceeds accordingly. The settings you give for the mode pins are correct.

No, the mode bits need to be stable. If you want to change the configuration method, you can twiddle the mode bits and cycle nPROG. Generally speaking, the mode pins are set for the default configuration mode and never changed.

The JTAG setting of the mode pins simply locks out the other configuration modes. Setting the modes pin to 011 does not prevent the JTAG interface from taking control of the part for debugging (Chipscope), configuration, or for indirect programming of the on-board SPI Flash.

On the 3AN family, programming the on-board configuration Flash is an indirect operation. Using JTAG, a special configuration is loaded using the JTAG programming interface and then started. This FPGA configuration provides access and control of the SPI Flash bonded on the FPGA carrier board along with the FPGA die. The desired configuration image is then downloaded to the FPGA using JTAG and the special FPGA SPI Flash programmer writes the data to the SPI Flash device.

Both the mode bits and the variant select bits have internal pull ups. You can simply connect them to ground for a logic 0, or let them float for a logic 1. I always connect them to PUs. I don't trust the high impedance PUs in the FPGAs.

I leave SUSPEND unconnected.

You need to PU DONE. I always pull up DONE, and always connect an LED (Red) that is on when DONE is low (not programmed), and off after configuration is complete. It's a simple two component BIT circuit.

Hope this helps.

_________________
Michael A.

Reviewed the SUSPEND pin description. Since we don't enable suspend in our designs, leaving the SUSPEND pin unconnected is probably fine. However, connecting it to ground is likely to provide a safer implementation in the event the SUSPEND feature is activated in the FPGA configuration bit stream.

_________________
Michael A.

Thanks, I almost understand.

To summarize:

VS[2:0] - unconnected or PU
M[2:0] - 011 for internal SPI boot
SUSPEND - PD
PUDC - PD (enable pullups on config pins during boot)
DONE - PU, led
PROG_B - PU

Confused about this: am I correct in assuming that all the above pins have to do with booting on power-up, and JTAG can be used to reconfigure (not just probe) the FPGA at any time? If yes, is PROG_B involved in non-boot reconfigurations?

In all devboards (never used AN parts though) JTAG provides access to FPGA for reconfiguration and SPI flash, and booting is a separate issue. My goal is to be able to boot from internal SPI normally, reconfigure the FPGA via JTAG for development, and finally flash the SPI Flash for final storage as it usually takes longer.

Hmm. What about INIT_B?

The manual actually talks about VS[2:0] and M[2:0] sampled as INIT_B goes to high, not PROG_B. Now I am even more confused.

UG332, page 75:


Also, at the end of the page at http://forums.xilinx.com/t5/Spartan-Family-FPGAs/Spartan-6-configuration-problem/m-p/154560#M11558:


I guess you can leave INIT_B alone or hold it low to delay configuration, but only if it's already low!? Doesn't really matter.

Per your questions:

SUSPEND is not associated with configuration.

PUDC_B enables PUs on I/O pins with no dedicated PUs, not on the mode or version select pins of the Spartan 3AN devices, because they have dedicated PUs which are not affected by PUDC_B. Table 2-17 in the Spartan-3 Generation Configuration User Guide, UG332, defines that the pins with dedicate PUs for Spartan 3AN FPGAs. The pins listed in Table 2-17 do not require PUs to be attached, or for PUDC_B to be grounded. Unlike the other Spartan 3AN, the Spartan 3 FPGA do not have dedicated PUs on the mode pins. (See Table 2-16.)

PUDC_B should be pulled down with a resistor less than 1.8k if you want to have any I/O pins pulled high while configuration is taking place. I used to do this. More recently, I use the DONE pin as one of the reset signals for external logic. Thus, when DONE goes high, external logic is allowed to come out of reset.

As I indicated in an earlier post, I generally connect PROG_B to a PU and a 2-pin jumper or PB switch to ground. I generally include an external POR circuit like a Microchip MCP130/MCP120 and connect it to an I/O pin on the FPGA instead of PROG_B.

Cycling PROG_B initiates configuration of the part. The JTAG interface also initiates configuration, but I have never tested whether the internally generated pulse is reflected on the PROG_B pin. Following PROG_B, configuration memory is cleared, and when that operation is complete, the mode pins are sampled. When the clearing of configuration memory is complete, the INIT_B pin is released and either the internal PU or an additional external PU will pull it up. It is when INIT_B is released that the mode pins are sampled.

I have never needed to delay configuration, so I've never held INIT_B low to delay configuration. Immediately after completing the clearing of internal configuration memory, the INIT_B is released and the mode pins and version select pins are sampled.

If I have any trouble configuring the FPGA, the LED on the DONE pin will indicate that configuration never occurred. Another LED on INIT_B can be used to indicate that the internal configuration memory is being cleared, or if a failure occurred during configuration. If INIT_B goes high and subsequently returns low, an error has occurred during configuration. If INIT_B goes high, but DONE remains low, then the issue is that synch pattern in the configuration bitstream was not detected, or that the bitstream is for a different part type. i.e. it's not for a Spartan 3AN FPGA.

One final note. I generally put PUs on configuration pins whether they are necessary or not. Most of the configuration pins are found near the center of the BGA packages. The PU/PD on these pins can be used as test points even if the components are not installed. The state of the mode pins and other configuration pins is available to the JTAG controller. If there are problems with soldering, etc. the dedicated PUs plus the JTAG interface can be used to verify the mode pins are correct.

_________________
Michael A.

MichaelM, thank you for a very thorough reply.

Do you think it's a bad idea to just connect pins like M[2:0] to the nearby ground/VCC pins instead of pulling them up? They seem to be input only, and I don't use them for anything else.

Also, you mention that you like to pull pins up even though Xilinx has internal pullups. Is there a story behind it or is it just superstition?

It's amazing how many questions come up even in a simple design (perhaps especially in a simple design). A reference board is an overkill in order to show off the different features. I am looking for a lowest part-count design, and there is very little information out there about what you absolutely need and what you don't.

I did see someone mention that for a JTAG-only configuration, all you need is to pull down PUDC_B and connect the JTAG pins, which seems to be in line with the Xilinx docs, the more I read them. I don't need absolute reliability, but would like to avoid turning the board on and off a bunch of times to get a clean configuration.

My other concern is that my 3.3V supply may come up before 1.2V, using 1117 regulators. It seems that as the 5V input ramps up through the capacitors, there will be enough voltage to feed the 1.2V regulator before the 3.3V regulator. I hope. I won't know until I put a scope on the prototype boards that should be arriving this week.

For the most part, the core, aux, and I/O voltages can come up in any order. The aux voltage, which can be tied to +2.5V or +3.3V, is the voltage used for the configuration memory. (Note: on the Spartan 3AN, the aux voltage must be set to +3.3V because that is the I/O voltage of the on-board SPI configuration SEEPROM. This is also the voltage connected to the JTAG connector.) The on-chip POR circuit, and configuration engine should take care of most power on issues. However, if there is an long delay between the +3.3V and the +1.2V core such that INIT_B goes high before VCCO is stable, you may have to delay configuration. I expect that this would be a very remote possibility unless you undersize your regulators, or attach an excess amount of bulk decoupling capacitance.

The Spartan 3AN PUs are not particularly strong, and on previous generations, I've occassionly been bit by poor cleanliness. The excess flux and other conductive residue would override the PUs. More recent parts like the Spartan 3AN, have stronger PUs, but I still remain a bit cautious about this issue since the allowable variation in resistance is so large. In addition, since most of these pins are toward the inner rings on a BGA package, it will be impossible to attach wires or probe the pins if a problem is suspected. The debug capabilities of the native JTAG tools are limited. For your purposes, I would use a SMT resistor of 220 to 470 Ohms in an 0603 package on PUDC_B and any other configuration pins with dedicated PUs. For the mode pins, I will generally pull then up with 4.7k, and PD with 470.
Unpopulated SMT resistors for these pins are fairly inexpensive, and will relieve a great deal of stress in the event the part does not immediately configure after you assemble the first one.
I also put PUs on all four JTAG pins. It gives me a place to attach a scope when things are not going well during initial checkout. I get a kick from things working right, but I really don't like to debug on real hardware; in simulation, debugging is somewhat more tolerable.

_________________
Michael A.

After some more perusing of the documentation, it appears that the minimum required to boot from internal flash is:

-PUDC_B should be pulled down to keep IO lines pulled up during config;
-M[2] should be pulled down and M[1:0] unconnected to force mode 011 - Internal Master SPI;
-VS[2:0] should be unconnected for mode 111 - 50MHz fast mode;
-DONE should be unconnected (or drive an LED high when done);
-PROG_B should be unconnected for power-on initialization/configuration;
-INIT_B should be unconnected (or drive an LED high while configuring);
-SUSPEND should be grounded;

It may be 'safer' to pull-up or pull-down all of these, but the manual states pretty clearly that dedicated pull-ups should take care of the unconnected pins.

I am collecting all Spartan-3AN configuration information here:
http://apple2.x10.mx/FPGA/FPGA.html#SpartanConfiguration