The Xilinx® Spartan™-3E family of FPGAs targets high-volume, cost-sensitive consumer electronic applications with a density range from 100,000 to 1.6 million system gates. It offers performance and cost enhancements over the previous generation of Spartan devices, as well as a new configuration mode allowing a glueless interface to standard parallel NOR flash memories. Nearly all of the configuration pins can be used as user I/Os after configuration.

This configuration mode, known as the byte-wide peripheral interface (BPI) parallel flash mode, lets you take advantage of low-cost and high-density Intel StrataFlash 3V Memory (J3), or J3 Memory. J3 Memory uses Intel ETOX process technology with multi-level cell capability, which provides 2X the bits in 1X the space. J3 Memory is available in a variety of packages and densities for increased flexibility and can be gluelessly connected to the Spartan-3E FPGA to store any of the following:

• Bitstreams for one or more FPGAs
• Boot code, parameters, and data for soft CPU cores in the FPGA
• Multiple bitstreams for the same FPGA utilizing the MultiBoot feature of the Spartan-3E device

Figure 1 shows how dual bitstreams (for MultiBoot) and code/data storage can coexist in a J3 Memory device.

Design Notes
Figure 2 illustrates the connection between two Spartan-3E FPGAs and a J3 Memory flash device in a 3.3V environment. In this section, we’ll examine key design considerations, such as power sequence, reset, hot-swap, flash content protection, and x8/x16 mode toggling.

Power-Up Sequence
Three supply voltages are required to support the Spartan-3E device and J3 Memory in a 3.3V application:

• 3.3V: connected to the VCC and VCCQ supplies of J3 Memory, as well as to the VCCO_1 and VCCO_2 supplies of the FPGA
• 2.5V: connected to the VCCAUX supply of the FPGA
• 1.2V: connected to the VCCINT supply of the FPGA

The Spartan-3E FPGA datasheet describes the power-on precaution in the serial flash mode (SPI mode), where the FPGA might be reading from the flash device before the flash memory is ready. The same consideration applies to parallel flash devices, because typical flash devices require some time (60 ìs for J3 Memory) to complete internal initialization after the voltage reaches a nominal level (2.7V for J3 Memory).

If the 2.5V and 1.2V are valid and the 3.3V reaches 0.4V to 1.0V (a voltage level below the minimum operating voltage of a flash device such as J3 Memory), the FPGA starts its programming sequence before the flash device is ready. Either of two scenarios might occur:

• 3.3V is valid (reaching 2.7V) before 2.5V and 1.2V reach their minimum required voltage. This scenario typically does not cause issues because the flash device (such as J3 Memory) is ready for reading when the FPGA starts its programming sequence.
• 3.3V is valid after 2.5V and 1.2V. To work around this scenario, you can typically use a 3.3V voltage monitor to hold the PROG_B or INIT_B pin low for at least 1 ms after the 3.3V power supply reaches the minimum operating threshold.

The following connection options are available for the RP# pin:

• Connecting RP# to 3.3V. This connection means that the flash device (such as J3 Memory) does not reset until power is cycled. This connection is suitable for applications where the FPGA is programmed only on power up and is not reprogrammed without power cycling. This connection is also applicable if you are certain that the risk of putting the flash device into non-read-array mode while the PROG_B pin is toggled is minimal.
• Connecting RP# to System Reset. When this connection is made, you must ensure that the PROG_B pin is not driven from low to high before RP# goes high, so that the FPGA does not start reading from the flash device before it comes out of reset. For J3 Memory, this duration is 150 ns to 210 ns after RP# goes high, under typical operating voltages.
• Connecting RP# and PROG_B together. When an FPGA reprogram is issued, this connection automatically resets the flash device to read-array mode. The output of a voltage monitor can be used to drive both inputs, but only under the following conditions:
  • The minimum reset pulse width for the flash device (such as J3 Memory) is met. The PROG_B pin on the FPGA requires only 0.3 ìs low pulse, but J3 Memory requires 35 ìs.
  • The TPL delay, from the time the PROG_B pin on the FPGA transitions high until INIT_B transitions high, exceeds the typical range of 150 ns to 210 ns (the R5 parameter in the Intel StrataFlash Memory [J3] datasheet). According to the Xilinx datasheet, the TPL minimum is approximately 2 ms.

If the application requires the HSWAP pin to be pulled high, then external pull-up resistors are required on the LDC0, LDC1, and HDC outputs. A pull-down resistor of 4.7K is required on the LDC2 (BYTE#) pin.

x8 Model-Only Operation
In BPI mode (M[2:0] = 0b010 or 0b011), the FPGA powers up in x8 mode, and drives the LDC2 pin (connected to the BYTE# pin of the flash device) low throughout the configuration period. If the application does not require x16 mode, tie J3 Memory’s BYTE# pin low and do not connect the LDC2 output to J3 Memory.

Toggling Between x8 and x16 Modes
If the LDC2 pin is connected to the BYTE# pin of the flash device, the FPGA can drive the LDC2 pin high to switch the flash device from x8 mode to x16 mode after configuration.

When toggling between the byte (x8) and word (x16) modes, the least significant address location and mode switching delay must be considered. On a J3 Memory device the A0 address line selects the byte location.

The switching latency between x8/x16 modes is 1000 ns (the R12 tFLQV/FHQV parameter in the Intel datasheet) from the time the LDC2 pin changes logic state until valid data can be output from the flash device. This latency must be taken into consideration, together with the HSWAP setting, because HSWAP controls the ability to tri-state LDC2 upon power up, in the following two scenarios:

• HSWAP is tied high (internal pull-ups are disabled). Connect a 4.7K pulldown resistor to LDC2. This pin is pulled low upon power up and remains low during configuration. J3 Memory is in x8 mode when the FPGA starts to load its configuration bitstream. LDC1 and LDC0 must have pull-up resistors so that the flash device is not accidentally selected or put into non-read-array mode during power up.
• HSWAP is tied low. In this scenario, the LDC2 pin is pulled high through an internal pull-up resistor upon power up and then driven low at the same time as LDC0 (CE#), LDC1 (OE#). The FPGA starts reading configuration data in less than 1000 ns, a period required for the flash device to switch modes. Three workarounds exist:
  • Workaround #1, as shown in Figure 1, requires a 340 ohm pull-down resistor on the LDC2 output to overcome the internal pull-up resistor and ensure that the flash device is in x8 mode when the FPGA starts to read its configuration data. The 340 ohm value is based on Spartan-3 data and can be increased as more characterization data on the internal pull-up of the FPGA becomes available. The downside to this workaround is that a large output buffer must be used to overcome the strong pull-down resistor when an application requires switching the LDC2 pin high to use the x16 mode.
  • Workaround #2 takes advantage of the fact that the FPGA requires an initialization sequence before it starts configuration. When the flash is switching from x8 to x16 mode, invalid data is present on the bus, which prevents the FPGA from seeing this sequence until the flash device completes its mode switching. If the FPGA device does not see the start sequence, it continues to increment the address, step through the remaining valid addresses, and then wrap around to address 0 until it finds the right sequence. This can result in a prolonged bitstream load time (the bitstream is eventually loaded).
  • Workaround #3 requires prefixing the FPGA bitstream with as many as 16 bytes of 0xFF dummy data. This prefix helps the FPGA device find its start sequence when it reaches the address for byte 17, at which time the flash would have completed its mode switching. This workaround involves Xilinx modifying its bitstream generation code and slightly increases the bitstream size. Contact Xilinx for the availability of this workaround.