Programming the FPGA

Programming the FPGA

Programming is the process changing the state of a non-volatile programmable element (such as embedded Flash and external SPI Flash devices) by downloading data from JEDEC, bitstream, or PROM files transmitted to the download cable through the host computer’s serial communications port; from an embedded system; or from a third party programmer.

Configuring is the process of changing the state of a volatile programmable element (such as SRAM in the FPGA).

Before programming or configuring an FPGA, you need to create and verify your design, and then generate data files. To download a data file into the target device, use the Programmer tool which is integrated into the Diamond software, and also available in a standalone version.

Programmer Design Flow

The design flow for creating and downloading a design chain is the same, whether you select the devices and settings from the software or use an existing chain configuration file.

1.
2.
3.
4.
5.

The following flow chart describes the Lattice programming process:

Programming Basics

To successfully program devices in-system, there are a few simple requirements that must first be met. The first of these requirements is that the devices on the board must be correctly connected into an 1149.1 scan chain. This scan chain can be used for either programming or testing the board.

To program using Programmer a description of the scan chain must be developed. This description, called a chain file, contains basic information about all of the devices in the chain. For the Lattice devices, it includes the device type, the operation to be performed, and the data file, if required by the operation. Additional information in the chain file can include the state of the I/O pins during programming, along with security requirements. If the chain includes non-Lattice devices, the instruction register length is required for these devices. The instruction register length can be found from the BSDL file or the SVF file for the device.

Another requirement for successful programming is thoughtful board design. The signals used in a scan chain (TCK, TMS, TDI, and TDO) rarely operate as fast as the data path signals on the board. However, correct board layout methodologies, such as buffering for large chains and termination resistors, are required to ensure trouble-free operation. Some Lattice devices have some additional pins (TRST, ispEN, PROGRAMN, INITN, DONE, SLEEPN, and TOE) that can affect boundary scan programming and test if not taken care of properly.

After all of these requirements have been met, it should be relatively straightforward to program any number of devices on a board. You can program the devices using a PC or Linux system and a board test system connected by one of the following cables:

*
*
In-System Programming

After you have compiled your design to a data file (JEDEC, ISC, hex, or bitstream) and device programming is necessary, you must serially shift the fuse map (a fuse map file is a design file that has the fuse data already pre-arranged in exactly the same format as the physical layout of the fuse array of the device) data into the device along with the appropriate addresses and commands.

Traditionally, PLD/PROM programmers have been used for generating all the signals and algorithms for programmable logic devices because of the supervoltage requirement (typically 12-14 volts) of non-ISP devices. But with In- System Programmable (ISP™) devices, the ISP programming super-voltage is generated within the device from the power supply.

Lattice non-volatile FPGA devices use embedded flash memory and require only TTL-level programming signals. An integrated state machine controls the sequence of programming operations, such as identifying the device, shifting in the appropriate data and commands, and controlling internal signals to program and erase the embedded Flash in the device. Programming consists of serially shifting the logic implementation stored in a data file into the device along with appropriate addresses and commands, programming the data into the embedded Flash, and shifting the data from the logic array out for device programming verification.

Most of Lattice’s devices use the IEEE 1149.1-1993 Boundary Scan Test Access Port (TAP) as the primary interface for in-system programming.

Programming Algorithm Basics

Programming a device is similar to programming any piece of memory, such as an EPROM or a Flash memory. The device can be thought of as an array that is programmed one row at a time. The programming information is provided to the software in the form of a data file that must be converted into the row and column fuse map data. Before a non-volatile device can be programmed, it first has to be erased. After the device has been erased, the programming data can be loaded and the device programmed. After the device has been programmed, it will be verified by reading out the data in the device and comparing it to the original.

The figure below shows the basic programming flow for the device. It does not include the data file conversion into fuse map data, for it assumes that step has already been done. This programming flow will be the same, regardless of the programming hardware used.

 

Programming Times

The time it takes to program a device can often determine where in the manufacturing process a device, or group of devices, is programmed. A board test system costing hundreds of thousands of dollars to purchase and as much as one dollar per minute to operate can be an expensive alternative to programming if programming times are too long. In many instances, it is more cost-effective to buy a couple of PCs and program the devices using these much cheaper systems.

The time it takes to completely program a device is based on the time it takes to first erase the device, then to program each row in the device, and finally to verify the device. The erase time for all devices is between 100 ms and 200 ms. A single row is programmed in 10 ms to 50 ms, depending on the device. The verification process is the quickest of the required steps in the programming sequence and mainly depends on the time required to shift the verification data out of any given device.

The benefit of minimal programming times is much more obvious on board test systems, because they are included as a part of the test program and are running at the fastest speed possible. Additionally, there is no translation needed to or from the data file, since this has already been done by Programmer.

USERCODE

User-programmable identification can ease problems associated with document control and device traceability. Every Lattice 1149.1-compliant device contains a 32-bit register that is accessible through the optional IEEE 1149.1 USERCODE instruction. This user-programmable ID register is basically a user’s notepad provided in Flash or SRAM cells on each device.

In the course of system development and production, the proliferation of PLD architectures and patterns can be significant. To further complicate the record-keeping process, design changes often occur, especially in the early stages of product development. The task of maintaining which pattern goes into what device for which socket becomes exceedingly difficult. Once a manufacturing flow has been set, it becomes important to “label” each PLD with pertinent manufacturing information, which is beneficial in the event of a customer problem or return. A USERCODE register is incorporated into devices to store such design and manufacturing data as the manufacturer’s ID, programming date, programmer make, pattern code, checksum, ISC data file CRC, PCB location, revision number, or product flow. This assists you with the complex chore of record maintenance and product flow control. In practice, the user-programmable USERCODE register can be used for any of a number of ID functions.

Within 32 bits available for data storage, you may find it helpful to define specific fields to make better use of the available storage. A field may use only one bit (or all bits), and can store a wide variety of information. The possibilities for these fields are endless, and their definition is completely up to you.

Even with the device’s security feature enabled, the USERCODE register can still be read. With a pattern code stored in the USERCODE register, you can always identify which pattern has been used in a given device. As a second safety feature, when a device is erased and re-programmed, the USERCODE identification is automatically erased. This feature prevents any situation in which an old USERCODE might be associated with a new pattern.

It is your responsibility to update the USERCODE when reprogramming. The USERCODE information is not included in the fuse map checksum reading.

Loading the USERCODE instruction makes the USERCODE available to be shifted out in the Shift-DR state of the TAP controller. The USERCODE register can be read while the device is in normal functional operation, allowing the device to be scanned while operating.

Programming Hardware

All programming specifications, such as the programming cycle and data retention, are guaranteed when programming devices over the commercial temperature range (0 to 70 degrees C). It is critical that the programming and bulk erase pulse width specifications are met by the programming platform to ensure proper in-system programming. The details of device programming are invisible to you if you use Lattice programming hardware and software.

Computer Hardware

Programming is most commonly performed on a PC or Linux system using the parallel port cable or the USB port cable.

Parallel Port Cable

The cable uses the parallel port of a PC or Linux system for in-system programming of all Lattice devices. Programmer generates programming signals from the parallel port and passes them through the cable to the JTAG port of the devices. With this cable and a connector on the printed circuit board, no additional components are required to program a device. Refer to the cable data sheet for more detailed specifications and ordering information.

Hardware design considerations for new boards include whether the hardware designer will be using boundary scan test operations or low-voltage (3.3 V–1.8 V) devices. In a system using 3.3 V devices, the cable version 2.0 should be used. This cable operates with either a 3.3 V or 5 V power source. In a system using 1.8 V devices, cable version 3.0 must be used. This cable operates with a power of 1.8 V to 5.0 V.

USB Port Cable

The USB port cable uses the USB port of a PC or Linux system for in-system programming of all Lattice devices. Programmer generates programming signals from the USB port and passes them through the USB port cable to the JTAG port of the device.

Programming Software

Programmer supports programming of all Lattice devices in a serial daisy chain programming configuration in a PC or Linux environment. The software is built around a graphical user interface. Any required data files are selected by browsing with a built-in file manager. The software supports both serial and concurrent (turbo) programming of all Lattice devices. Any non-Lattice devices that are compliant with IEEE 1149.1 can be bypassed after their instruction register lengths are defined in the chain description. Any non-Lattice devices that are compliant with IEEE 1532 can be programmed using an IEEE 1532-compliant BSDL and ISC data file. Programmable devices from other vendors can be programmed through the vendor supplied SVF file.

Embedded Programming

Programmer embedded source code is available for programming devices in an embedded or customized environment. The programming source code is written in ANSI-standard C language, which can be easily incorporated into an embedded system or tester software to support programming of devices. This code supports such common operations as Erase, Program, Verify, and Secure. After completion of the logic design and creation of a JEDEC file, Programmer can create the data files required for in-system programming on customer-specific hardware: PCs, testers, or embedded systems.

FPGA Configuration

Programmer provides efficient and economical alternatives to large and expensive PROMs that are normally used for configuring FPGA devices.

Because SRAM-based FPGA devices are volatile, they require reconfiguration on power cycles. This means that external configuration data must be held in a non-volatile device. On systems that require quick configurations or that do not have processor resources readily available, a dedicated serial PROM can be used. But such a PROM has to be large to accommodate large FPGA devices or multiple devices.

A much easier solution is to use a low-cost, industry-standard flash memory device combined with a LatticeECP/EC, LatticeECP2, LatticeSCM/SC, or Lattice CPLD device.

Serial Peripheral Interface Flash

Programmer, combined with a Lattice cable fly-wire, supports the programming of Serial Peripheral Interface (SPI) flash devices.

LatticeECP3, LatticeECP2, LatticeECP/EC, MachXO2, LatticeXP2, LatticeSCM/SC, and iCE40 Devices

The LatticeECP3, LatticeECP2, LatticeECP/EC, MachXO2, LatticeXP2, LatticeSCM/SC, and iCE40 device families of FPGAs can be configured directly from a serial peripheral interface (SPI) flash memory devices. Each of these devices contains Lattice's Reveal IP Programmer, which uses the JTAG interface to program the SPI flash device. Because of their bitstream compression capability, these FPGAs allow the use of smaller-capacity SPI memory devices.