Speedster22i

Achronix Speedster22i User Manual Configuration

Download

Speedster22i Configuration

User Guide

UG033 – December 18, 2013

UG033, December 18, 2013

Copyright © 2013 Achronix Semiconductor Corporation. All rights reserved. Achronix is a trademark and Speedster is a registered trademark of Achronix Semiconductor Corporation. All other trademarks are the property of their prospective owners. All specifications subject to change without notice.

NOTICE of DISCLAIMER: The information given in this document is believed to be accurate and reliable. However, Achronix Semiconductor Corporation does not give any representations or warranties as to the completeness or accuracy of such information and shall have no liability for the use of the information contained herein. Achronix Semiconductor Corporation reserves the right to make changes to this document and the information contained herein at any time and without notice. All Achronix trademarks, registered trademarks, and disclaimers are listed at http://www.achronix.com and use of this document and the Information contained therein is subject to such terms.

2 UG033, December 18, 2013

Table of Contents

Table of Contents .............................................................................................. 3

Overview ............................................................................................................ 4

Power-Up and Configuration Sequence .......................................................... 5

Device Power-Up ........................................................................................................................... 5

Read Non-Volatile Memories ......................................................................................................... 5

Clear Configuration Memory .......................................................................................................... 5

Bitstream Sync and Device ID ........................................................................................................ 6

Load Configuration Bits .................................................................................................................. 6

CRC Check ................................................................................................................................ .... 6

Startup Sequence .......................................................................................................................... 6

User Mode ................................................................................................ ..................................... 7

Configuration Modes and Pins ......................................................................... 8

CPU ....................................................................................................................................... 9

Serial x1 Flash ..................................................................................................................... 10

Serial x4 Flash ..................................................................................................................... 11

JTAG .................................................................................................................................... 13

Configuration Pins and Clock Selection ............................................................................... 14

Bitstream File Generation Through ACE ....................................................... 16

Design Security ............................................................................................... 18

Revision History .............................................................................................. 20

UG033, December 18, 2013

Overview

Core FabricIO Ring

Configuration Pins

Control Logic and

State Machines

JTAG

CPU Flash x1 Flash x4

FPGA Configuration Unit (FCU)

Configuration Mode

Interfaces

To config bits

in IO ring

Parallel load of config memory in FPGA fabric core

The configuration architecture in Speedster22i HD devices is composed of a few key pieces:

Figure 1 below provides a block level diagram showing the pieces of the configuration architecture . Data from the configuration pins are brought into the FCU located in the IO ring. Depending on the configuration mode, this data passes through one of four interfaces and is then provided into the control logic and state machines in the FCU. At this point, the data bus is standardized to a common interface. This data is interpreted here and then fans out to the configuration registers in the IO ring and a bus to be parallelly loaded into column based configuration memory frames in the FPGA fabric core. Once all of the configuration bits have been successfully loaded, the FCU transitions the FPGA into user mode, providing the capability for the user to provide stimuli and enable operation.

1. Configuration pins enabling data transfer from an external interface to the FPGA

2. FPGA Configuration Unit (FCU) which is the IP block containing the modes,

interfaces, state machines and other control logic to take data from the pins, perform the necessary FPGA mode transitions and assemble the incoming data stream into a form to be ultimately provided to the rest of the FPGA

3. Configuration registers in the IO ring and the configuration memory in the fabric

core which are the recipients of the bitstream data coming from the FCU

Figure 1: FPGA Configuration Blocks

4 UG033, December 18, 2013

Power-Up and Configuration Sequence

1 2 3 4 5 6 7

Device

power-up

Read non-

volatile

memories

Clear

configuration

memory

Bitstream

sync and

device ID

Load

configuration

bits

CRC check

Startup

sequence

User Mode

The requirements for the power-up and configuration sequencing for Speedster22i HD devices are illustrated in Table 1 and detailed below.

Table 1: Power-Up and Configuration Sequencing Steps

Device Power-Up: The first step in bringing up the Speedster22i HD FPGAs is to

appropriately power it up. The Power Sequencing section of the Speedster22i Pin Connections and Power Supply Sequencing User Guide provides an illustration of how the power supplies and configuration related pins/signals need to be asserted to ensure a successful FPGA power-up. To summarize these requirements:

a. Power-up all power supplies except for PA_VDD1, PA_VDD2 and VDDL to full rail. b. Power-up PA_VDD1 and PA_VDD2 after VCC reaches full rail. c. Bring CONFIG_RSTN low to assert the reset after PA_VDD1 and PA_VDD2 reach

full rail. This will perform an FPGA reset.

d. After some time (~ms), release CONFIG_RSTN. Once the FPGA is out of reset, steps

2 and 3 in Table 1 above, the reading of the non-volatile memories and the clearing of the configuration memory, will be performed. After the configuration memory is cleared, the CONFIG_STATUS signal will be released.

e. Power-up VDDL and wait for it to reach full rail. At this point, the FPGA is ready to

accept the bitstream.

Read Non-Volatile Memories: After coming out of reset, the FCU reads the non-

volatile memory (fuse) contents and latches the data coming out. The fuses are factory set to zero and can be programmed. Manufacturing and ID related fuses are set during ATE testing. Fuses that pertain to design security are available for customers to program. Please refer to the section on Design Security for operation details.

Clear Configuration Memory: After the non-volatile memory is read, the FCU

enters the state to clear configuration memory. Configuration memory cells are 6-T SRAM cells and are cleared one frame at a time by writing 0s into them. If this state is entered after a full FPGA power-up, it is imperative that all configuration memory be cleared prior to

UG033, December 18, 2013

powering up VDDL. Otherwise, with SRAM cells powering up in unknown states, the presence of one-hot muxes in the routing interconnect will undoubtedly mean that there will be shorts leading to contention, and as a result unexpected behavior as far as current profiles and draws.

This step can be bypassed as a debug or optimization step by asserting the BYPASS_CLR_MEM pin/signal. This is really only acceptable/feasible if the application involves re-configuring the FPGA without a power-down.

Once the memory clear is complete, the pin CONFIG_STATUS is released by the device, and the weak external pull-up will pull this signal high to indicate that the FCU is ready to read the bitstream.

It should be noted that only the configuration memory is cleared in this step. The embedded BRAM and LRAM memory cells are NOT cleared and should be assumed to power up to unknown states after configuration and in user mode. There is a separate option to preload the memory contents using an initialization file.

Bitstream Sync and Device ID: Speedster22i HD FPGA bitstreams always start

with a sync code which is pre-programmed to 0xAA55AA55. The sync code is always written in the bitstream by the ACE software and is transparent to the user. Followed by sync, a Device specific ID Code is checked to avoid programming the device with bitstream meant for other devices. This is also a pre-programmed code provided by ACE.

Load Configuration Bits: The configuration bitstream is a series of data words

which are ultimately made to internally form a bus and get shifted into a register chain before being parallelly loaded into configuration memory frames in the FPGA fabric. There are also command words which control whether the IO ring configuration registers or the core configuration memory gets loaded.

The configuration file size and the configuration time are directly proportional to the number of configuration memory frames that need to be programmed in the FPGA fabric. The configuration file size is also dependent on the programming mode used, but strictly as a raw hex file (see section on Bitstream File Generation Through ACE below) the bitstream size can vary from <1MB for very small designs to close to 100MB for the largest designs that fill up the entire FPGA and preload the BRAM memories.

CRC Check: At the end of the bitstream, a CRC check is performed on the bitstream to

ensure that the data going into the configuration memory is error-free. This is disabled in ACE for ES devices, but will be done by default on all production devices.

Startup Sequence: After the configuration memory is programmed, the command

sequence to enter the user mode can be issued by the bitstream. Entering and exiting user mode is controlled by a startup/shutdown state machine also implemented in the FCU. This operates independently of the configuration state machine and so the configuration state machine can process bitstream commands even after entering user mode.

6 UG033, December 18, 2013

The startup sequence consists of sequentially asserting a number of signals to ensure proper

Stage

Event

Assert Global Clock Enable

Assert I/O Enable

Assert Global Reset Enable

Assert Global Core Enable

Assert Config Done

Assert User Mode Enable

operation during user mode. These events are highlighted in Table 2 below.

Table 2: Startup Sequence Events

The shutdown sequence is very similar in nature to the startup sequence and essentially entails deasserting these same signals in reverse order.

User Mode: Once the device enters user mode, the design has been fully programmed

and the user can start sending and receiving data to/from the FPGA and performing intended operations.

UG033, December 18, 2013

Configuration Modes and Pins

Configuration Mode

CONFIG_MODESEL[2:0]

CPU

100

Serial x1 Flash

001

Serial x4 Flash

010

JTAG

Always active

Configuration Logic User

Logic

Speedster22iHD FPGA

JTAG

Interface

Configuration

Manager

SPI Flash Controller

CPU Slave

Controller

JTAG Cable

Serial (SPI)

Flash

External

CPU

USB JTAG

Serial Data

Speedster22iHD devices have four configuration modes: CPU, Serial Flash x1, Serial Flash x4 and JTAG. The selection between the first 3 is done by tying CONFIG_MODESEL pins to the values shown in Table 3. The fourth configuration mode, which is JTAG, is independent of the mode pins and can be enabled by setting the appropriate bits in the User Data Register of the JTAG TAP Controller. Once JTAG mode is enabled, it overrides all other configuration modes until disabled.

Table 3: Configuration Modes and CONFIG_MODESEL Settings

Figure 2 below shows a simplified block diagram view of the different configuration interfaces connecting up to the Speedster22iHD FPGA.

Figure 2: Configuration Interface Connections to the Speedster22iHD FPGA

8 UG033, December 18, 2013

CPU

config_rstn

config_done

config_status

config_modesel[2:0]Tied to 3'b100 for CPU mode

CSN[2]DQ[7]

CSN[3]DQ[6]

HOLDNDQ[5]

SDO[0]DQ[4]

SDO[1]DQ[3]

SDO[2]DQ[2]

SDO[3]DQ[1]

SDIDQ[0]

CSN[0]CSN

CPU_CLKCLK

CPU

Speedster22iHD

Valid Bitstream Data

CPU_CLK

CONFIG_RSTN

CONFIG_STATUS

CSN

DQ[7:0]

CONFIG_DONE

In CPU mode, an external CPU acts as the master and controls the programming operations for the FPGA. CPU mode is an 8-bit parallel interface, clocked using CPU_CLK, with chip select support to indicate valid data. This is generally the fastest programming mode as it provides for the widest data width interface and a maximum supported clock rate of 25MHz. Figure 3 below provides a block diagram of how the external CPU would be hooked up to Speedster22iHD FPGA.

UG033, December 18, 2013

Figure 3: External CPU Connectivity to Speedster22iHD FPGA

As described in the Power-Up and Configuration Sequence section, the configuration mode specific operations occur between the release of CONFIG_STATUS (indicating that the configuration memory has been cleared and that the FPGA is ready to accept bitstream data) and the assertion of CONFIG_DONE (stating completion of configuration). The waveform in Figure 4 shows the sequence of events, clocking and control signal states needed for successful configuration in CPU mode.

Figure 4: Clocking and Control Signals for Successful Configuration

In Figure 4 above:

CPU_CLK

CSN

DQ[7:0]

CONFIG_STATUS

AA 55 AA 55 20 20 16 41 00 00 00 00 00 00 00 00 00 38 00 01 00 00 00 07 11 15 00

Sync ID Code NOP NOP Write Cmd Write Data

1. After CONFIG_RSTN is deasserted, CPU_CLK needs to continue being clocked to

ensure that the FPGA cycles through the FCU states and the configuration memory is cleared. At that point, CONFIG_STATUS is released and is pulled high.

2. Some time after CONFIG_STATUS is pulled high, CSN should be pulled low to

begin writing the bitstream data into the FPGA. When the last set of data is written into the FPGA, CSN is pulled high.

3. Once CSN is pulled high, CPU_CLK needs to continue being clocked for a total of

about 12,000 clock cycles. After 9,000 clock cycles, CONFIG_DONE should be asserted to indicate that configuration has completed, and the remaining 3,000 clock cycles are needed to ensure that the FCU can successfully transition into user mode.

The waveform in Figure 5 depicts the window of a sample valid bitstream programming section of the configuration.

Serial x1 Flash

10 UG033, December 18, 2013

Figure 5: Sample Valid Bitstream Programming

The Serial Flash programming mode allows flash memories to be used to configure the Speedster22iHD FPGA. In this mode the FPGA is the master, and therefore supplies the clock to the Flash memory.

Figure 6 below provides a block diagram of how a serial flash can be connected to a Speedster22iHD FPGA in x1 mode.

SPI Flash Speedster22iHD FPGA

SCLK

HOLDN

CSN

SCK HOLDN SDI CSN[0] SDO[0]

This interface contains a configuration mode fast read engine that reads the data from the flash from address 0. The number of words read in the bitstream can be controlled by the bitstream by programming one of the configuration registers. This block also contains a master controller that interfaces to the JTAG unit for programming of the serial flash. The flash programming instructions are sent via JTAG.

Configuration operation in serial flash x1 mode is very similar to CPU mode. The only difference comes during the writing of the bitstream. SCK is used for clocking and the bitstream is a single bit interface provided through the SDO[0] port. CSN[0] is pulled low during the valid bitstream window and is then pulled high once the last bit is clocked in. Transitioning from the end of the bitstream to user mode is done exactly as in CPU mode, with SCK providing the clock to the FPGA.

Serial x4 Flash

Figure 6: Flash Connectivity to Speedster22iHD FPGA in x1 Mode

Serial x4 Flash programming mode is essentially an enhanced and higher bandwidth implementation of the Serial x1 Flash mode. The FPGA is again the master, and interfaces with not 1 but 4 Flash memory modules to increase the data bandwidth from x1 to x4.

Figure 7 below provides a block diagram of how 4 Serial Flash memories can be connected to a Speedster22iHD FPGA in Flash x4 mode.

UG033, December 18, 2013

SPI Flash Speedster22iHD FPGA

SCLK

HOLDN

CSN

SCK HOLDN SDI CSN[0] SDO[0]

SPI Flash

SCLK

HOLDN

CSN

SPI Flash

SCLK

HOLDN

CSN

SPI Flash

SCLK

HOLDN

CSN

CSN[1] SDO[1]

CSN[2] SDO[2]

CSN[3] SDO[3]

Figure 7: Flash Connectivity to Speedster22iHD FPGA in x4 Mode

When writing to the 4 Flash memories, the FPGA would pull the CSN for a single Flash memory in turn, write the data and then move onto the next Flash memory by pulling the corresponding CSN low. When reading from the 4 Flash memories, all CSN signals are pulled low, and a x4 width configuration data is read from the Flash memories and transferred to the FPGA through the SDO ports. Once bitstream operations are completed (Flash memory contents are read), transitioning from the end of the bitstream to user mode is done the same way as in CPU and Flash x1 modes.

12 UG033, December 18, 2013

JTAG

JTAG Header / Controller

Speedster22iHD FPGA

TCK TMS TRSTN TDI TDO

Speedster22iHD

FPGA

JTAG Header / Controller

Device A Device B

TCK

TMS

TRSTN

TDI

TDO

TCK

TMS

TRSTN

TDI

TDO

TCK

TMS

TRSTN

TDI

TDO

TCK

TMS TRSTN TDI TDO

JTAG configuration and operation mode is independent of CONFIG_MODESEL settings, although the recommendation is to ensure that the CONFIG_MODESEL values are one of '100', '001', '010' or '000' to avoid unknown or illegal states.

The JTAG Tap controller design is compliant to the IEEE Std 1149.1. The TMS and TCK inputs determine whether an instruction register scan or data register scan is performed. TMS and TDI are sampled on the rising edge of TCK, while TDO changes on the falling edge.

Achronix recommends using an on-board JTAG header for Bitporter compatibility, direct programming through the STAPL jam file (see Bitstream File Generation Through ACE below) and the debug capability provided for Snapshot and SerDes debug in the PMA GUI.

JTAG configuration can be done for a Speedster22iHD device that in and of itself is the only device in the JTAG scan chain, or is part of a series of devices all connected up in the chain. Figure 8 below shows a block diagram of a single Speedster22iHD device in the JTAG scan chain. Figure 9 shows the case where multiple devices are connected in series.

UG033, December 18, 2013

Figure 8: Single Speedster22iHD Device Connectivity to JTAG Header

Figure 9: Multiple Device Connectivity to JTAG Header

Configuration Pins and Clock Selection

External Pin Name

CPU

Serial Flash x1

Serial Flash x4

JTAG

SDI

DQ[0]

Serial data output to flash memory

SDO[3]

DQ[1]

Input of configuration

data from flash

SDO[2]

DQ[2]

Input of configuration

data from flash

SDO[1]

DQ[3]

Input of configuration

data from flash

SDO[0]

DQ[4]

Input of configuration data from flash

SCK - Flash clock output

HOLDN

DQ[5]

Hold output to flash

CSN[3]

DQ[6]

Active-low chip select

CSN[2]

DQ[7]

Active-low chip select

CSN[1] -

Active-low chip select

CSN[0]

Active-low chip select

CPU_CLK

CPU clock

- - -

CONFIG_RSTN

Active-low configuration reset

CONFIG_DONE

Open-drain configuration done output

CONFIG_STATUS

Open-drain SRAM initialization complete output

CONFIG_MODESEL

[2:0]

Config mode select.

Set to '100'.

Config mode select.

Set to '001'.

Config mode select.

Set to '010'.

Config mode select.

Not used in JTAG

mode, but these pins

should be set to '100',

'001', '010' or '000'.

CONFIG_SYSCLK_

BYPASS

Bypass config system

clock. Tie to '0' or '1'.

Bypass config system clock. Set to '0'.

Bypass config system

clock. Tie to '0' or '1'.

CONFIG_CLKSEL

Selects configuration clock. Set to '0'.

Tie to '0' or '1'

TDI - -

Input of config data

from JTAG controller

TDO - -

Serial data output to

JTAG controller

TMS - -

Mode select from

JTAG controller

TRSTN - -

Active-low reset from

JTAG controller

TCK - -

Clock from JTAG

controller

CONFIG_SYS_CLK

_BYPASS

CONFIG_CLKSEL

CONFIG_MODESEL

[2:0]

FCU CLK

001, 010

On-chip oscillator

001, 010

CPU_CLK

0/1 0 100

CPU_CLK

000, 001, 010, 100

TCK

Table 4 below lists the names and functions of all of the configuration and JTAG pins used in the four different configuration modes.

Table 4: Configuration/JTAG Pins and Functions

14 UG033, December 18, 2013

Table 5 highlights the different clock sources that can be selected in the various configuration modes, and Figure 10 illustrates the same FPGA configuration clock selection logic.

Table 5: Clock Sources for Configuration Modes and Settings

3'b100

CPU_CLK

SYSCLK

CONFIG_SYSCLK_BYPASS

TCK

CONFIG_MODESEL[2] CONFIG_MODESEL[1] CONFIG_MODESEL[0]

CONFIG_CLKSEL

JTAG_CLKSEL

(From Internal FCU)

FCU_CLK

Figure 10: FPGA Configuration Clock Selection Logic

Note that if programming will be done exclusively using JTAG mode, it is important to understand how to control the CONFIG_MODESEL and clock selection pins. In order to clear the FPGA configuration memory after a power-on or a reset of the device, an active (nonJTAG) clock needs to be selected to cycle through the FCU states. For example, if

CONFIG_MODESEL is set to ‘100’ (thereby selecting CPU_CLK prior to the JTAG override),

CPU_CLK needs to be toggled to ensure correct operation.

UG033, December 18, 2013

Bitstream File Generation Through ACE

ACE has a straightforward interface to generate the bitstream files required to implement all

of the supported configuration modes. The bitstream files will get generated in the ‘FPGA

Programming – Generate Bitstream’ step of the compilation flow.

The STAPL jam file needed for JTAG mode configuration will by default, always be generated. The ‘Bitstream Generation’ section of the Project Options menu, shown in Figure 11 below, provides users with a menu selection to generate bitstream files for the other configuration modes as well.

Figure 11: ACE Screen Capture of Bitstream Generation Options

These bitstream file types are described in a little more detail below:

1. JTAG: STAPL .jam file for JTAG mode programming. There are options for

generating a single and a multi-device scan chain configuration file in which the scan chain details need to be specified.

2. Serial Flash: A single serial flash (.flash) binary file. This is literally a full binary file

of the bitstream data that could be burned into a single flash memory. There are NO newline characters in the file. It is completely binary.

16 UG033, December 18, 2013

3. 4x Flash: A 4x Flash (.flash4x_0-3) binary file supporting configuration from 4 flash

memory devices. This the same full flash memory binary as above, but split into 4 files intended for a x4 flash memory configuration. There are NO newline characters in the files and is again completely binary.

4. CPU Mode: File formatted for CPU mode programming (.cpu). This contains the

entire bitstream organized as 9 bits per line. The MSB is the read/write bit (always 1 for write), and the other 8 bits are 8 bits of bitstream data per line.

5. In addition a raw hex (.hex) file generation option is provided. This contains

bitstream data in hexadecimal format with 32-bits of data per line (and no read/write bit like the .cpu file).

UG033, December 18, 2013

Design Security

Speedster22iHD devices provide design security features using a 256‐bit Advanced Encryption Standard (AES) algorithm in Cipher Block Chaining (CBC) mode. The FPGA contains a non‐volatile memory (known as a high-security or HS eFuse) for the storage of the required AES key.

Design security on Speedster22iHD devices is provided by putting the device in secure mode. This puts the following two mechanisms into effect:

 FPGA configuration bitstream encryption: the FPGA only accepts encrypted

bitstreams. During configuration the FCU decrypts the encrypted bitstream using a decryption key based off of the same encryption key.

 Readback disable: Configuration bitstream readback is disabled, meaning that the

design information cannot be read out and copied. HS eFuse readback capability is also blocked.

Enabling design security features requires two functions:

a. Generation of encrypted bitstreams after enabling AES encryption and specifying the

encryption key that will be programmed into the FPGA in ACE. This is simply done in the ACE Bitstream Options GUI interface by checking the appropriate box and typing in the actual key to be written.

b. One-time blowing of HS eFuses to program in the key needed for AES.

The blowing of eFuses has to be very carefully integrated into the design security implementation process, since it is irreversible. Recovery from unintentionally blown fuses is not feasible, and should be diligently validated for correct operation before enabling it in a production flow. Also please note that as specified in the Pin Connections and Power Supply Sequencing User Guide, one of the fuse power rails, VCCFHV_EFUSE[3:1] needs to be powered by its own separate regulator to ensure that this rail can be increased to the voltage level needed for fuse blowing without affecting the rest of the FPGA operation. Therefore, the FPGA board and setup needs to provide for this ability.

The fuse blowing process consists of 3 phases:

1. Run phase 1 programming steps to cycle through the FCU states, write required

values to the eFuse registers and bring the device to a state where eFuses are ready to be blown

2. Raise VCCFHV_EFUSE[3:1] to 2.2V and VCCRAM_EFUSE[3:1]/VDDA_NOM_E/W

to 1.1V. Run phase 2 steps needed to blow the eFuses.

18 UG033, December 18, 2013

3. Lower VCCFHV_EFUSE[3:1], VCCRAM_EFUSE[3:1] and VDDA_NOM_E/W all back

down to 1.0V. Run phase 3 steps to validate the eFuse blowing process and return the FCU back to a state to resume programming operations.

Once the eFuses are blown, the Speedster22iHD FPGA will be ready to accept encrypted bitstreams as part of regular programming operation.

UG033, December 18, 2013

Revision History

Date

Version

Revisions

12/18/2013

1.0

Initial Achronix release.

The following table shows the revision history for this document.

20 UG033, December 18, 2013

Achronix Speedster22i User Manual Configuration

Specifications and Main Features

Frequently Asked Questions

User Manual