IDaSS to Xilinx Spartan-II(E) FPGA conversion · directory of IDaSS (or the VisualWorks Smalltalk...

IDaSS to Xilinx Spartan-II(E) FPGA conversion page i

IDaSS to Xilinx Spartan-II(E) FPGA conversion

A.C. Verschueren

september 16, 2003

Trick photo of B5-SPARTAN2+ board (disguised as a B5-SPARTAN2E+ board)

IDaSS to Xilinx Spartan-II(E) FPGA conversion page ii

Contents:

1 Introduction...................................................................1 1.1 The basic design path ..................................................................2

2 Software, hardware and installation............................3 2.1 The basic IDaSS system ..............................................................3 2.2 The Spartan-II(E) specific IDaSS extensions..............................3

2.2.1 Installing the IDaSS Spartan-II(E) extensions.................................4 2.3 The Xilinx WebPACK tools...........................................................5

2.3.1 Installing the WebPACK system files..............................................5 2.4 The B3/5-SPARTAN2(E)+ prototyping boards............................7

2.4.1 Setting up the prototype boards......................................................9 Preparing the configuration download connection .............................. 9 System clock frequency selection .................................................... 10 Power supply connection ................................................................. 10

2.4.2 A simple test environment ............................................................10 Creating a proper ‘system reset’ FPGA input ................................... 11 Connecting switches and other (logic) devices to FPGA inputs ........ 12 Connecting LED’s and other (logic) devices to FPGA outputs.......... 12

3 Generating a synthesizable design with IDaSS........14 3.1 IDaSS design rules to enable FPGA synthesis ........................14

Generating multi-FPGA systems (advanced!) .................................. 15 3.1.1 IDaSS design element (non-memory) restrictions ........................15 3.1.2 Supported memory technologies ..................................................17

3.1.2.1 Single ported synchronous RAM ..............................................18 3.1.2.2 Dual ported synchronous RAM.................................................19 3.1.2.3 1.5-ported register file (a RAM technology) ..............................21 3.1.2.4 6-ported register file (a RAM technology) .................................22 3.1.2.5 Single ported asynchronous ROM............................................24 3.1.2.6 Single/dual ported synchronous ROM......................................25 3.1.2.7 First-In-First-Out (or ‘queue’) memory ......................................27 3.1.2.8 Last-In-First-Out (or ‘stack’) memory........................................28 3.1.2.9 Content Addressable (or ‘associative’) Memory .......................30

3.2 Indicating pin locations and I/O options...................................32 3.2.1 Device pin assignment..................................................................34

Automatic pin assignment ................................................................ 34 Clock pin assignment ....................................................................... 35 Manual pin assignment using properties .......................................... 35

3.2.2 I/O driver/receiver properties ........................................................37 3.3 Generating synthesis files from IDaSS.....................................39

3.3.1 Creating a WebPACK project directory.........................................40 3.3.2 Pre-conversion ‘checklist’ .............................................................42 3.3.3 Actual synthesis files generation...................................................43

IDaSS to Xilinx Spartan-II(E) FPGA conversion page iii

4 Synthesizing and downloading of the design in the FPGA ...........................................................................44

4.1 Synthesizing of the IDaSS design .............................................44 4.1.1 Indicating to WebPACK which files to use ....................................45

Project navigator ‘processes’............................................................ 46 Editing the ‘User Constraints File’ .................................................... 46

4.1.2 The ‘Synthesize’ process and its properties .................................46 ‘Synthesize’ process property settings ............................................. 47

4.1.3 The ‘Implement Design’ process and its properties ......................49 ‘Implement Design’ process property settings .................................. 50

4.1.4 The ‘Create Programming File’ process and its properties ...........52 ‘Create Programming File’ process property settings ....................... 53

4.2 Downloading the design into the FPGA....................................55 4.3 The next synthesis session .......................................................56

A IDaSS template menu settings...................................58

B Pin numbers for Spartan-II(E) devices ......................63 B.1 Global clock pins GCK0-GCK3..................................................63

Clock connections for XC2S15/30-VQ100........................................ 63 Clock connections for XC2S15/30/50/100-TQ144 ............................ 63 Clock connections for XC2S15/30-CS144........................................ 63 Clock connections for XC2S30/50/100/150/200-PQ208 ................... 63 Clock connections for XC2S50/100/150/200-FG256 ........................ 63 Clock connections for XC2S100/150/200-FG456 ............................. 63 Clock connections for XC2S50E/100E-TQ144 ................................. 64 Clock connections for XC2S50E/100E/150E/200E/300E-PQ208 ..... 64 Clock connections for XC2S50E/100E/150E/200E/300E-FT256 ...... 64 Clock connections for XC2S100E/150E/200E/300E-FG456............. 64

B.2 Data I/O pin tables ......................................................................64 59 data connections for XC2S15/30-VQ100..................................... 65 85 data connections for XC2S15-TQ144.......................................... 65 91 data connections for XC2S30/50/100-TQ144 .............................. 66 85 data connections for XC2S15-CS144.......................................... 66 91 data connections for XC2S30-CS144.......................................... 67 131 data connections for XC2S30-PQ208........................................ 67 139 data connections for XC2S50/100/150/200-PQ208 ................... 68 175 data connections for XC2S50/100/150/200-FG256 ................... 69 195 data connections for XC2S100-FG456...................................... 70 259 data connections for XC2S150-FG456...................................... 71 283 data connections for XC2S200-FG456...................................... 72 97 data connections for XC2S50E/100E-TQ144 .............................. 73 141 data connections for XC2S50E/100E/150E/200E/300E-PQ208 73 177 data connections for XC2S50E/100E/150E/200E/300E-FT256 . 74 197 data connections for XC2S100E-FG456.................................... 75 260 data connections for XC2S150E-FG456.................................... 76 284 data connections for XC2S200E-FG456.................................... 77 324 data connections for XC2S300E-FG456.................................... 78

IDaSS to Xilinx Spartan-II(E) FPGA conversion page 1

1 Introduction

This document describes how to get an IDaSS design up and running in a Xilinx Spartan-II(E) ‘Field Programmable Gate Array’ (FPGA).

We specifically target the Spartan-II 200 device as mounted on the B3-SPARTAN2+ and B5-SPARTAN2+ prototyping boards and the Spartan-IIE 300 device placed on the B5-SPARTAN2E+ prototyping board available from Burch Electronic Designs (www.burched.com.au) using the freely available Xilinx WebPACK synthesis and FPGA programming tools (see www.xilinx.com).

This combination allows you to use IDaSS to create and test synchronous digital hardware designs in a single ‘chip’ with the following capabilities:

Up to 300K logic gate equivalents (may be traded for 95K bits of RAM) Up to 6900 Flip-Flops Up to 64K bits of high speed dual-ported synchronous RAM Up to 141 fully configurable I/O pins Complex system clock speeds reach between 25 and 80 MHz All RAM can be (mis-)used as ROM, where necessary

This should be enough for rather complex designs, including multiprocessor systems on a single chip!


1.1 The basic design path

This document assumes that you know how to work with IDaSS. We indicate here the specific do’s and don’ts you have to adhere to in order to create a synthesizable design. The basic path from IDaSS to the Spartan-II(E) device can be summarised as follows (assuming all software has been set up properly):

1) Use IDaSS to design your system as usual, restricting yourself to use only supported memory technologies (and keeping track of the total amount of memory you are using). Make sure that the system parts which have to be placed on the FPGA are located in a single sub-schematic (a test environment can be placed outside this sub-schematic).

2) If necessary, use IDaSS properties to control assignment of bits of IDaSS buses to specific FPGA pins. The hardware behaviour of these I/O pins (like drive power and special output configurations) can also be controlled with properties.

3) Use the ‘alien file generation’ functionality of IDaSS to generate a Verilog description for the FPGA to be synthesized. This will also generate a ‘User Configuration File’ which contains extra information needed by the FPGA synthesis software – information which could not be placed in the basic Verilog description.

4) Use the Xilinx WebPACK toolbox to synthesize the logic and memory structures from the Verilog description and User Configuration File, followed by placing and connecting (‘routing’) these structures on the FPGA chip. After this, a ‘.bit’ file containing the FPGA programming information can be generated, ready for ‘downloading’.

5) Connect the FPGA to your computer’s printer port (via a small interface board) and use the FPGA programmer in the Xilinx WebPACK toolbox to load the programming information into the FPGA. If a proper clock signal is applied to the FPGA, the designed hardware will immediately start operation from system reset state after downloading completes.

Starting with chapter 3, these steps will be explained in more detail. But first, chapter 2 will explain the stuff you need to get this all operational.


2 Software, hardware and installation

This chapter explains the parts you need and how to get them up and running. A lot of tool settings can only be done when actually using the tools, so these are left for later (these settings need to be made only once, as they are stored automatically).

2.1 The basic IDaSS system

This system is freely downloadable from the IDaSS homepage which is located at http://www.xs4all.nl/~averschu/idass/ (make sure you get a version dated november 2002 or later, as earlier versions lack some functionality needed here).

There are two versions available:

1) A stand-alone version for Windows-95/98/NT (and Linux Windows emulators), packaged as a self installing idass5i4.exe file.

2) A ‘parcel’ version to be installed in a VisualWorks Smalltalk version 5i.x environment (available for a large number of processor/operating system ‘platforms’). You can download non-commercial versions from www.cincom.com, or buy fully licenced versions from the same company.

For installation of these two versions, see file install5i4.txt which can be reached from the IDaSS homepage.

2.2 The Spartan-II(E) specific IDaSS extensions

The Spartan-II(E) specific extensions to IDaSS are placed in four files which come with the basic IDaSS system:

• spartan2e.pdf is the file you are reading now (placed in the support directory)…

• spartan2e.aft is the ‘alien file template’ file which enables IDaSS to generate a Verilog description of an IDaSS design (also placed in the support directory). This Verilog is targeted towards the Xilinx WebPACK tools and Spartan-II(E) FPGA’s. It will also generate a ‘User


Constraints File’ when necessary to hold information which cannot be placed in the Verilog code.

• spartan2.ini is a replacement for the standard idass.ini file delivered with the IDaSS system (placed in the IDaSS installation directory). It attaches the spartan2e.aft file automatically and initialises settings to those needed for the Spartan-II 200 device as mounted on the B3-SPARTAN2+ and B5-SPARTAN2+ prototyping boards.

• spartan2e.ini is a replacement for the standard idass.ini file delivered with the IDaSS system (placed in the IDaSS installation directory). It attaches the spartan2e.aft file automatically and initialises settings to those needed for the Spartan-IIE 300 device as mounted on the B5-SPARTAN2E+ prototyping board.

2.2.1 Installing the IDaSS Spartan-II(E) extensions

An experienced IDaSS user should be able to attach the spartan2e.aft file from entries in the ‘miscellaneous…’ menu of an IDaSS schematic window, after which the ‘template menu’ settings can be adjusted to match the settings as described in appendix A (starting at page 58) of this document. Do not forget to save the ‘image’ file (with ‘File/system’/’save image’) to store the new attachments and settings!

For the less experienced user, there is a simpler way – do one of two things with the spartan2(e).ini files you just unpacked:

1) Simply copy one of them over the idass.ini file in the installation directory of IDaSS (or the VisualWorks Smalltalk system). This will remove the settings you made in this initialisation file – for instance, you will have to re-select the correct timezone.

OR

2) Use a text editor to copy and paste only those parts of spartan2(e).ini into idass.ini which perform the attachment of the spartan2e.aft file and settings of the ‘template menu’ to preserve the settings you made in idass.ini.

Next, start IDaSS and open an empty top level simulator window (if not already opened). Save all designs you were working on (if any) and close their windows. Then select from menu ‘miscellaneous…’ the entries ‘system management…’/’initialise IDaSS’. Confirm the notifier which pops up and wait while IDaSS is being re-initialised with the correct files and settings. IDaSS will be saved automatically to the idass.im file (which contains the complete working environment) with all these settings and attachments. After this, you can immediately start with your first design for the Spartan-II(E) device.


2.3 The Xilinx WebPACK tools

The Xilinx WebPACK tools can be downloaded from the Xilinx website (with homepage www.xilinx.com). Before downloading, you have to register, but that is just a formality – they like to know who is using their tools, and there is nothing wrong with that. Note that there is a lot to download: the file you need is more than 100 megabyte in size, so have patience (or get a very fast internet connection)…

The version of (officially) ‘WebPACK ISE’ we target here is ‘V4.2 WP 3.x’, so be sure to get this one or a higher version. If you obtain a higher numbered version and find that settings have markedly changed, please contact us at [email protected] (we would like to hear from you anyway!).

WebPACK version 5.1

The new version of v5.1 of WebPACK can be run only under Windows 2000 or Windows XP. When downloading using the 'web installation' feature, ask for just the FPGA synthesis and programming tools as this saves a lot of time.

The most important difference with V4.2 is when adding source files to the project: Both the Verilog source code file (with extension .v) and the User Constraints File d2vSCHEMA_1.ucf must be selected, after which you must indicate that this constraints file should govern the top level schematic of the design called 'd2vSCHEMA_1' (at the top of the selection list presented).

As with older versions, v5.1 only requires one setting to be changed: In the ‘Create Programming File’ process property settings, the 'Start_Up Clock' property in the 'Startup options' should be set to 'JTAG Clock'.

The old WebPACK version should still be available on the Xilinx web site. Indicate that you want to download the standard FPGA synthesis system. You will then be offered two files to download (with approximately the following names - version numbers may change):

• WebPACK_42wp30_fpga_installer.exe, the basic working environ-ment including the actual synthesizer, design process manager and FPGA programmer for a number of different FPGA families.

• MXE_42wp00_full_installer.exe, a full featured but code size limited Verilog/VHDL simulation environment. Downloading this is optional (not downloading it saves time, this file is another 35 megabytes!).

2.3.1 Installing the WebPACK system files

Install WebPACK_42wp30_fpga_installer.exe by simply running it as a program. You will be asked for a base directory to install all software – choose


a directory on a disk which has enough space as the total size after installation will be in excess of 130 megabytes!

WARNING: Do not choose a directory whose full path name includes spaces (for instance, ‘C:\progam files\xilinx’ may not be used!).

If you plan to use asynchronous and/or synchronous Read Only Memories (ROM’s) in your designs, you need to make some changes to one of the files you installed above. It is a good idea to make these changes after installation, so you do not run into surprises later. Instructions to do so are on pages 24 and 26 respectively (always a good idea to keep a copy of the original file under another name!).

It does not make much sense to run the main ‘WebPACK project navigator’ application directly after this installation, as you can not configure its tool settings before an actual ‘project’ has been defined and a source code (Verilog) file has been loaded in that project.


2.4 The B3/5-SPARTAN2(E)+ prototyping boards

The B3-SPARTAN2+, B5-SPARTAN2+ and B5-SPARTAN2E+ prototyping boards contains the following major elements:

• A Spartan-II 200 device with 139 data I/O pins brought out to so-called header connectors. On the B5-SPARTAN2E+, it is a Spartan-IIE 300 device with 141 data I/O pins brought out.

There are 8 header connectors with a 2 rows of 10 pins configuration, each carrying 18 data pins or 17 data pins and a clock pin, a ground (0 volt) pin and a 3.3 volt power supply pin (which can be disconnected).

On the B3-SPARTAN2+ board, one of these header connectors is re-placed by a 2 rows of 13 pins header connector which carries 17 data pins, connected in such a way that the printer port cable normally connected to the download ‘pod’ can be plugged in there.

• A programmable clock generator which can be set to frequencies between 1 and 100 MHz by placing jumper blocks. This has a fixed connection to pin 77 (named ‘GCK1’) of the Spartan-II(E) device.

• Connectors for downloading via the JTAG and serial download pins of the Spartan-II(E) device. Download mode selection is done with three jumper blocks. An 8 pins socket for a serial PROM (to allow the Spartan-II(E) to configure itself without a computer attached) is also present.

• Power supply connectors to connect the board to a regulated 5 volt power supply. These feed 3.3 and 2.5 volt power supply regulators for the Spartan-II(E) I/O pins and Spartan-II core respectively. The Spartan-IIE core on the B5-SPARTAN2E+ board is fed with a 1.7 volt power supply regulator.

• A test switch and test LED which are connected as follows:

B3-SPARTAN2+ has the LED at pin 49, switch at pin 61. Both are normal data I/O pins also brought out to the header connectors.

B5-SPARTAN2+ has the LED at pin 82 (normal data I/O), switch at pin 80 (this is a 'Global Clock' input on the FPGA). Both are brought out to header connectors.

B5-SPARTAN2E+ has the LED at pin 82 (normal data I/O, also on a header connector), switch at pin 57 (a separate extra data I/O pin with its own header for external connection).


The following picture shows the general layout of the B3-SPARTAN2+ board:

The following picture shows the general layout of the B5-SPARTAN2+ board, the B5-SPARTAN2E+ board is almost identical in layout:

Power supply regulators

5 volt power in5 volt power out

JTAG mode download connector

Serial mode download connector

Serial PROM socket

Test switch (Pin 61)

Test LED (Pin 49)

Download mode select

Programmable clock gen.

Data I/O connectors

Power LED

5 volt power out

5 volt power in

Power test conn.

Power LED

JTAG mode download connector

Power supply regulators Serial mode

download connector

Serial PROM socket

Test LED

Test switch

Download mode select

Program-mable clock generator

Data I/O connectors


2.4.1 Setting up the prototype boards

Preparing the configuration download connection

Use the 'JTAG-mode' connector (on the side of the voltage regulators and the power connectors) and the download ‘pod’ cable to connect to the PC's printer port. Make sure the cables are connected correctly (the connectors have a bump on one side which should line up with the outline of these connectors printed on the boards).

B3-Spartan2+ board

Download ‘pod’ board

Short cable (10 conductor)

Long cable with printer port conn.

PC

5 volt power cord with plug

JP5 with ’M1’

B5-Spartan2(E)+ board

Download ‘pod’ boardw. protection switch

Short cable (10 conductor)

Long cable with printer port conn.

PC

5 volt power cord with plug

conf. mode with ’M1’

A jumper should be installed on 'M1' (on the 3x2 pin download mode select header at the indicated locations), 'M0' and 'M2' should remain open.

NOTE: we have chosen to use the JTAG mode of downloading here, as this leaves the maximum amount of data I/O pins open for general use. Serial mode download (all ‘M…’ jumpers open) and loading from a serial PROM (all ‘M…’ jumpers installed) both require one data I/O pin for operation. More complex download configurations are supported by Spartan-II(E) devices (for instance ‘chaining’ more than one of them so that they can be downloaded in one go), but these require special cables and generally more data I/O pins.


System clock frequency selection

Select a suitable system clock frequency with headers JP6 and JP8. A good default is 24 MHz, which requires all indicated 'V…', 'S…' and 'R…' headers to be shunted with jumpers, except 'S2', 'R1' and 'V2'. Note that the clock generator is connected to the 'GCK1' input pin of the Spartan-II device (pin number 77) and can not be disconnected.

To determine the jumper block settings for other frequencies, you can use the ‘calculator’ at www.icst.com/products/ics525inputForm.html (specify 20 MHz as input frequency and 3.3 Volt power supply). This will give you three sets of ‘S…’, ‘R…’ and ‘V…’ settings to choose from (for most precise output frequency, lowest power and lowest jitter) – choose the one which meets your requirements best and then set the jumper blocks accordingly (a ‘0’ needs a jumper, a ‘1’ must be left open).

NOTE: this ‘calculator’ provides settings for two separate devices – on the B3/5-SPARTAN2(E)+ boards, an ICS525-01R is used.

Power supply connection

Connect the power supply lead to the connector nearest to the JTAG download header and attach the other end of the wire to a suitable 5 volt (stabilised) power supply – red wire to +, black wire to ground/–. The current should be around 70-90 milliamperes when the power is turned on (the green power LED should light up), but the startup current can be much higher, so make sure you have a power supply rated at at least 0.5 Ampere!

It should be no problem to turn the power supply on or off with the download connection cable plugged into a PC printer port – likewise, you can turn your PC on or off without disturbing the operation of the prototyping board. The download ‘pod’ board has been designed specifically to allow all this and isolate the power supplies of both systems.

2.4.2 A simple test environment

The prototype board contains a test LED attached to one of the data I/O pins (turns on if that output is switched to a logic 0) and a test switch attached to either a data I/O pin or an unused clock input pin (pulls the input to logic 0 if pressed). This is, however, a bit simplistic…

For more complete tests, it may be an idea to create a (homebrew) board containing switches and LED’s which can be attached to the headers on the prototype board. Burch Electronic Designs sells these boards for a very reasonable price, but it is also possible to build your own. Some ideas are described below.


Creating a proper ‘system reset’ FPGA input

Most IDaSS designs assume the presence of a ‘system reset’ functionality. In principle, the system automatically starts up from system reset state after FPGA downloading completes, but a manual system reset switch (push button type) may come in handy.

A system reset input will always be synthesized and assigned to a pin when there is something to reset inside an IDaSS design. If you are not connecting a reset switch circuit to this input (after all, the system is reset during downloading), the input pin should be connected to 0 Volt. This can be done with a wire (connect to a terminal labeled ‘GND’), but the connection can also be made inside the FPGA by setting the RESETRESISTOR property to ‘pulldown’. More information on controlling the reset input pin number and setting input properties is given in section 3.2 starting at page 32.

A system reset switch should be connected to the assigned reset input pin on the FPGA. For proper operation, the mechanical switch should be debounced and the input should be active high (a binary 1 represented by 3.3 volts resets the system). Insert a resistor (1 kilo-Ohm will do nicely) between the output of the debounce circuit and the input of the FPGA. This prevents blowing up things when unintentionally setting the attached input as an output. We give two suitable circuits below:

R2

R1

R3 3.3 V GND

N.C.

N.O. FPGA reset

N1

N2

Switch is push button with Common, Normally Open and Normally Closed contacts. R1, R2 = 22..47 KOhm. R3 = 1 KOhm. N1, N2 = ½ of a 4011 ‘quad two-input NAND’ device (pins 7,8,9,12,13 = GND, pin 14 = 3.3 volt, pins 10,11 open).

Com.

pin 1 pin 2

pin 3

pin 4 pin 5 pin 6

R3

R1

3.3 V

GND FPGA reset N1

Switch is push button with Normally Open contacts. R1 = 4.7..10 KOhm. R2 = 220 KOhm, R3 = 1 KOhm. C1 = 0.1 microFarad. N1 = 1/6 of a 74HC14 ‘hex Schmitt trigger’ device (pin 7 = GND, pin 14 = 3.3 volt, other I/O's at pins 3/4, 5/6, 9/8, 11/10 and 13/12 - connect unused inputs to GND).

pin 1

pin 2 R2

GND C1


Connecting switches and other (logic) devices to FPGA inputs

Inputs can be driven by simple switches to ground, with a resistor (of, say, 330 Ohm) in series again to prevent blowing up output drivers of the FPGA. No need to use pull-up resistors (to 3.3 volt!), as these can be programmed inside the FPGA.

On the Spartan-II devices, input pins can withstand 5 volt, so they can be connected to other digital IC’s (any ‘TTL’ or ‘CMOS’ logic family§ will do) without any problems.

On the Spartan-IIE devices, input pins can only handle 3.3 volt. When driving an FPGA input from standard 5 volt TTL devices, place a resistor (of, say, 470 Ohm) between the TTL output and the FPGA input to protect the FPGA pin. When connecting to CMOS logic running at 3.3 volt, no protection resistors are needed - although it is always safer to insert them.

Special output types (like ‘open collector’) connected to FPGA inputs can be accomodated by programmable pull-up and pull-down resistors within the FPGA at the input pins.

Connecting LED’s and other (logic) devices to FPGA outputs

LED’s can be driven directly from the output pins of the FPGA, attach them between the 3.3 volt power supply (available on one pin of each header connector) and the output, with a suitable series resistor on one side of the LED. For good quality LED’s, a 330 Ohm resistor provides enough current (approximately 5 milliampere) to light the LED. IDaSS allows output pins to run in a special ‘switch’ mode which closes a switch to 0 volt on a logic 1 output – very convenient for LED’s connected this way, as they will light up on a logic 1.

When connecting FPGA outputs to other logic circuits, keep in mind that the output levels are 0 (logic 0) and 3.3 volt (logic 1). This is no problem for most ‘TTL’ families and ‘CMOS’ devices having ‘fully TTL compatible’ inputs (or normal ‘CMOS’ devices running at 3.3 volt).

For the Spartan-II series FPGA's, you can obtain an output level of 5 volt instead of 3.3 volt by programming the output pin to behave as an ‘open collector’ output (a switch to 0 volt which closes on a logic 0) and use an external pull-up resistor (somewhere between 2.2 and 22 KiloOhm) to 5 volt.

§ ‘TTL’ = ‘Transistor-Transistor Logic’, with input 0/1 decision level at 1.4 volt, output 0 at 0.4 volt and output 1 above 2.4 volt. Power supply voltage is 5 volt. ‘CMOS’ = ‘Complementary Metal-Oxide-Semiconductor’, with input 0/1 decision level normally at half the power supply voltage, output 0 at 0 volt and output 1 at the power supply voltage – these run best if the inputs are also at these voltages. Some CMOS families can run with power supply voltages as low as 1.5 volt, others as high as 15 (!) volt. We should run them at 3.3 or 5 volt, however.


Voltages at Spartan -IIE FPGA I/O pins MUST be kept between 0 and 3.3 volt!


3 Generating a synthesizable design with IDaSS

If you know how to handle IDaSS as it is, generating a synthesizable design to be downloaded into a Spartan-II(E) FPGA is not very difficult. During the actual designing, you have to follow a few rules (which for a large part are enforced by IDaSS itself). You will also have to indicate I/O pin numbers and configurations. Once the design is finished and the I/O pin configuration has been attached, converting the design into the form suitable for the Xilinx WebPACK synthesis tools is as simple as saving the design in the normal IDaSS .des design file format.

These three subjects (design rules, I/O configuration and synthesis files generation) are described in separate sections of this chapter.

3.1 IDaSS design rules to enable FPGA synthesis

The major rule is that you have to place the system (part) you want to put into an FPGA in an IDaSS sub-schematic. All communication between this sub-schematic and its environment must be done using data buses crossing this sub-schematic’s boundary.

Note that you can create a state controller outside this sub-schematic which tests and/or controls elements inside it. The necessary test and control buses and pins will then be synthesized automatically – this is not recommended practice, however!

Outside the FPGA sub-schematic you can build an IDaSS test environment representing the actual hardware environment connected to the FPGA. This test environment may contain elements which break the synthesis rules (as it will not be synthesized anyway). For instance, ‘Algorithmic Level’ blocks cannot be synthesized at all, but they may be present in the test environment as a convenient means to generate and check complex test sequences.

Because the IDaSS memory models have the most explicit restrictions (to match the possibilities of the Spartan-II(E) FPGA’s), the remainder of this section is split in two – the first part explains the restrictions for the non-memory elements of IDaSS and the last part handles the memories separately. First, however, a few remarks for those who need more than one FPGA in their system…


Generating multi-FPGA systems (advanced!)

It is possible to design multi-FPGA systems by placing separate sub-schematics for each FPGA in an IDaSS design. You will have to do the partitioning of the system yourself, though, and also have to make sure the clocks and system reset inputs of the different FPGA’s will be synchronised properly in the final hardware.

Be careful when you synthesize the FPGA’s in a multi-FPGA design: the spartan2e.aft rulebase can generate Verilog files with different names, but the accompanying ‘User Configuration File’ is always called d2vSCHEMA_1.ucf and overwritten without warning!

3.1.1 IDaSS design element (non-memory) restrictions

In this sub-section, we provide a list of the IDaSS design elements (other than memories) and their restrictions. For the memories, we refer to the next sub-section.

A general (and very obvious) rule is, of course, that the contents of the sub-schematic you want to put into an FPGA should actually fit in there. If you are not sure, convert separate sub-schematics or blocks up to the ‘Synthesize’ process in the WebPACK tools – the ‘Synthesis Report’ gives you a rather accurate estimate of the amount of logic needed for those sub-parts so you can keep track of the ‘running total’ of hardware you’re generating.

Registers The system reset value may not be set to ‘hold on reset’ (IDaSS assumes some kind of non-volatile storage if you specify that, and this is simply not possible in the FPGA). All other functions (including semaphore bits) are completely supported.

State controllers Completely supported, including external commands and subroutine stacks. For the internal test expressions, read the remark on combina-torial logic/arithmetic operators below.

‘Operator’ blocks Completely supported, but read the remark on combinatorial logic/arith-metic operators below.

Three-state buffers Fully supported, but use with caution (see remark on three-state outputs below).

Constant generators No restrictions.


Algorithmic Level blocks These can not be converted and may not be present within the FPGA sub-schematic.

Sub-schematics No restrictions, re-use is allowed.

Multiple sub-schematics At least one ‘tag’ (with accompanying schematic contents entity) should have been defined.

Single bit synchronisation ‘signals’ Although these are system-global in IDaSS (any state controller or Algorithmic Level block can access the complete set of them), the conversion only allows their use to be localised within the FPGA sub-schematic. In other words: a specific signal may be accessed by all state controllers within an FPGA sub-schematic, but there should be no other entities outside that sub-schematic accessing the same signal. Aside from this, there are no functional restrictions with signals.

Normal input and output connectors No restrictions on these.

Bidirectional connectors No restrictions on these either. For the bidirectional connectors at the FPGA sub-schematic boundary, the following remarks must be made:

• The actual pad direction (in, out or truly bidirectional) is assigned during conversion. This pad direction is determined solely by the internal structure of the filed-out FPGA sub-schematic.

• Input pads which after optimisation loose their function (are not con-nected to any internal logic anymore) give problems during synthesis. Make sure all input bits are actually used!

• Truly bidirectional off-chip buses driven by a single internal TS output are not implemented optimally (they do work, though).

Three-state output connectors Fully supported, although it is better to restrict their use to on-chip ‘system’ buses or for driving FPGA output-only or bidirectional pads. Three-state outputs connected to an internal ‘local’ bus should be avoided and replaced by multiplexers.

Control input connectors No restrictions, you are allowed to place more than one of them in a single block.

Combinatorial logic/arithmetic operators All operators are supported, but not all of them have been verified to handle input widths greater than 128 bits without problems. Signed


multiply operations (‘+∗∗∗∗’, ‘∗∗∗∗+’ and ‘+∗∗∗∗+’) and bit counting operations (‘onecnt’, ‘zerocnt’ and ‘maj’) need some better way to write them out in Verilog, as the generated logic is currently pretty slow (they do work, though).

Parameters Are fully supported. Be careful, though, that parameters used within the filed out FPGA sub-schematic must also be defined within this sub-schematic. If this is not done, parameter input pads will be created automatically which may interfere with manual pad assignments.

Probe sets Do not form part of the actual designed system and are therefore ignored during conversion.

3.1.2 Supported memory technologies

The main rule here is that you may only use memory (and memory port) technologies as provided in the IDaSS technology file idass.tec – never select the ‘unrestricted’ technology for a memory model within the FPGA sub-schematic.

Before we describe the available memory technologies in detail, we provide some background information on the two methods used within a Xilinx Spartan-II(E) FPGA to implement memories efficiently:

'distributed RAM' uses the combinatorial logic Look Up Tables (LUT’s) of a Spartan-II device. These are essentially RAM’s with 16 words of one bit each, initialised during downloading, which are used as programmable 4-input/1-output logic gate. They can be used as asynchronous reading (data output changes as soon as the address input has changed) register file with a single read/write port or as single port asynchronous ROM. Connecting two LUT’s in parallel provides a means to create an asynchronously reading register file with one read/write port and one read-only port (this technology is called ‘1.5 port register file’ because the second port cannot write).

For this type of memory, the IDaSS technology file allows up to 16 Kilobits for one module, with memory depth rounded up to the next multiple of 16 words. Note that this may use up to half the available LUT’s of a Spartan-II(E) 200 when used as 1.5 port register file! Single port register files and asynchronous ROM's use half the amount of LUT's of a 1.5 port register file (one for each 16 bits stored).

'block RAM' uses separate 4096 bit memory modules which can each be organised as 4096 words of 1 bit, 2048 words of 2 bits, 1024 words of 4 bits, 512 words of 8 bits or 256 words of 16 bits. These are combined automatically by the spartan2e.aft converter to cover the requested memory size. Block RAM can be used as synchronous dual port RAM


or ROM. The outputs are latched – for reading, you provide the memory with an address and a ‘read’ command. At the next clock the output will be updated to the contents of the indicated address and remain in that state indefinitely. The output latches can be initialised to 0 on system reset. As RAM, these modules have the strange habit that writing implies reading – you provide an address and data together with a ‘write’ command, on the next clock the data will be written into the memory and also be output on the data output at that time (and remain there). 'Write through' from one port to the other is NOT possible.

The size limits set in the IDaSS technology file coincide with what spartan2e.aft can handle (16 MEGAwords of 256 bits each) – we have to wait for the 'big memory simulation' under development for IDaSS (and also for Xilinx to come up with a megahyperextended Spartan-II(E) as a Spartan-IIE 300 has 'only' 16 block RAM modules) before we can actually use memories of this size. It is quite simple: if you ask for too much memory, the Xilinx WebPACK tools will tell you...

Separate Flip-Flops and attached combinatorial logic are used to implement multiported register files, FIFO’s, LIFO’s and Content Addressable Memories (CAM’s). The maximum size allowed by the technology file is 1024 bits for a memory module of these types, which may use up to a quarter of the available flip-flops on a Spartan-II 200 device (not to mention the amount of logic needed for a CAM of that size)!

The next sections will describe the available memory technologies in detail, including operation, restrictions, port technologies etcetera.

3.1.2.1 Single ported synchronous RAM

This is a memory model implemented with block RAM modules by disabling the second read/write port. The remaining port must be a combined read/write port (one address input, a data input and a data output).

Reading: place the address you want to read at the address input and send a ‘read’ command to the memory (or the address input). After the next clock, the output will be updated to hold the value which was present in the memory at the indicated address – this output will remain stable until the next update by another read or write operation.

Writing: place the address you want to write at the address input, the data you want to write at the data input and send a ‘write’ command to the memory (or the address input). At the next clock the data will be written into the indicated memory location. Also, the output will be updated to hold the value which was written – this output will remain stable until the next update by another write or read operation.

Timing: the address, data and command inputs are clocked into Flip-Flops inside the block RAM modules. There is very little (if any) logic added for address decoding when combining block RAM modules into a larger


memory. This means that these inputs need only a short setup time to the clock. The data output, however, needs a relatively long time to stabilise after the clock – for optimal system performance, do not put much logic between the output of the RAM and the next register in which this output must be stored!

Restriction: the system reset value should be set as UNKnown in IDaSS. Although block RAM modules can be initialised during downloading (and are by default loaded with all words zero), there is no (simple) way to load all words with a specific value at the press of a ‘reset’ button.

Port technologies:

1) The ‘Latched output read/write port with automatic RD on WR’ follows the true behaviour of the actual read/write port on the single ported synchronous RAM implementation. This port allows read and write commands to be given in the same clock cycle (behaves like a write) and also allows the output to be initialised to 0 after system reset (default is UNKnown).

2) The ‘Synchronous read/write port with automatic TS-enable’ is provi-ded for backwards compatibility (older designs may still use this one). This port does not allow read and write commands to be given in the same clock cycle, the output is (in the IDaSS simulation!) not latched but falls back to UNKnown after the output clock cycle and the output is always UNKnown after system reset. If the output is made a three-state output, this one will be enabled automatically during the output clock cycle following a read command.

3.1.2.2 Dual ported synchronous RAM

This is a memory model implemented with block RAM modules, both ports must be used. Read-only, write-only and read/write ports may be combined here (with some restrictions).

Reading: place the address you want to read at the address input of a port and send a ‘read’ command to that address input. After the next clock, the output of the port will be updated to hold the value which was present in the memory at the indicated address after that clock – this output will remain stable until the next update by another read or write operation on the same port. If you send the ‘read’ command to the memory module instead of to a specific address input, all ports with reading functionality will perform a read action.

Writing: place the address you want to write at the address input of a port, the data you want to write at the data input of that port and send a ‘write’ command to that address input. At the next clock the data will be written into the indicated memory location. If this is a read/write port, the output will be updated to hold the value which was written – this


output will remain stable until the next update by another write or read operation.

If the other port is reading the same location at the same time, its output will become UNKnown and IDaSS simulation will by default be aborted (the error notification can be changed to a mere warning or be ignored) – this so-called 'Write Through' is NOT allowed on Xilinx Block RAM modules. If the other port is writing the same location at the same time, the value actually written in the memory and output on the outputs is unknown (so this 'write clash' is definitely not a good idea – IDaSS by default breaks off simulation when this happens).

If you send the ‘write’ command to the memory module instead of to a specific address input, all ports with writing functionality will perform a write action.

Timing: the address, data and command inputs are clocked into Flip-Flops inside the block RAM modules. There is very little (if any) logic added for address decoding when combining block RAM modules into a larger memory. This means that these inputs need only a short setup time to the clock. The data outputs, however, need a relatively long time to stabilise after the clock – for optimal system performance, do not put much logic between the outputs of the RAM and the next registers in which these outputs must be stored!

Restrictions:

• The system reset value should be set as UNKnown in IDaSS. Although block RAM modules can be initialised during downloading (and are by default loaded with all words zero), there is no (simple) way to load all words with a specific value at the press of a ‘reset’ button.

• Read and write functionality should both be present (for instance, two read-only ports are not allowed). If the widths of the address inputs of the two ports differ and the port with the smallest amount of address bits cannot address the complete memory, the port with the largest number of address bits should be a combined read/write port (this rule prevents creating a RAM which is partially read-only or write-only).

Port technologies:

1) The ‘Latched output read/write port with automatic RD on WR’ follows the true behaviour of the actual read/write ports on the dual ported synchronous RAM implementation. This port allows read and write commands to be given in the same clock cycle (behaves like a write) and also allows the output to be initialised to 0 after system reset (default is UNKnown).

2) The ‘Synchronous read/write port with automatic TS-enable’ is provi-ded for backwards compatibility (older designs may still use this one). This port does not allow read and write commands to be given in the


same clock cycle, the output is (in the IDaSS simulation!) not latched but falls back to UNKnown after the output clock cycle and the output is always UNKnown after system reset. If the output is made a three-state output, this one will be enabled automatically during the output clock cycle following a read command.

3) The ‘Latched output read-only port’ is the read-only version of port type 1) and follows the true behaviour of the actual read ports on the dual ported synchronous RAM implementation.

4) The ‘Synchronous read-only port with automatic TS-enable’ is the read-only version of port type 2) and is provided for backwards compatibility.

5) The ‘Synchronous write-only port’ is the write-only version of ports types 1) or 2) (there is no difference in their basic writing behavior). Using this port type gives some warnings during synthesis and pro-gramming file generation (‘block RAM output is not connected’), but these warnings can be safely ignored.

3.1.2.3 1.5-ported register file (a RAM technology)

This is a memory model implemented with distributed RAM blocks. The first port must be a combined read/write port, the second (optional) port must be a read-only port. It is called a ‘register file’ because it behaves like a number of (numbered) registers connected in such a way that you can address one of the registers for writing at the clock, with reading done by multiplexing the outputs of the registers. The ‘1.5-ported’ refers to the fact that the second port (if used) has to be a read-only port – in essence, an extra set of independent output multiplexers.

Reading: simply place the address you want to read at the address input of a port, after a short delay the output will be updated to the value which is present in the memory at the indicated address. Writing to that address will automatically update the output (again, after a short delay). No commands are necessary to read, nor do you have to wait for the clock.

Writing: place the address you want to write at the address input of the read/ write port, the data you want to write at the data input of that port and send a ‘write’ command to the memory (or the address input of that port). At the next clock the data will be written into the indicated memo-ry location and the output will be updated to the value which was written.

If the read-only port is addressing the same location at that time, its output will be updated too.

Timing: reading is a combinatorial operation done with (a lot of) multiplexers. The four lowest address bits select the bits within the distributed RAM blocks to be read, higher address bits control multiplexers which select


between the outputs of these distributed RAM blocks. For memory depths up to 16 words, the delay from address change to output upda-te is constant (and rather short). Above 16 words, the delay increases with each extra address bit.

For writing, the address must be decoded to point to one of the words in the distributed RAM blocks, so the address setup time to the clock is significant and increases with every address bit added above four address bits. Data and command input setup times are not as large as for the address input, but are definitely longer than for a normal register.

Restrictions:

• The system reset value should be set as UNKnown in IDaSS. Although distributed RAM modules can be initialised during downloading, there is no (simple) way to load all words with a specific value at the press of a ‘reset’ button.

• If both the read/write and read-only ports are present, then only the read-only port is allowed to address only a part of the memory (this rule prevents creating a 1.5-ported register file which is partially read-only).

Port technologies:

1) The ‘Asynchronous read/synchronous write port’ follows the true beha-viour of the read/write port on the 1.5-ported register file implementa-tion and should therefore be used as the first port.

2) The ‘Asynchronous read-only port’ should be used for the optional second port on the 1.5-ported register file.

3.1.2.4 6-ported register file (a RAM technology)

This is a memory model which will be implemented in one of two different ways, depending on the functionality as defined in the IDaSS model:

1) If the module as defined in IDaSS adheres to the functional limitations of the 1.5-ported register file technology (one read/write port, one optio-nal read-only port and system reset value set to UNKnown), it will be implemented using distributed RAM blocks.

2) If the module does not adhere to these limitations, implementation will be done with separate Flip-Flops and associated combinatorial logic.

This model allows up to six different ports to be present in any combination of read/write, read-only and/or write-only – provided that read and write functionality is available for all memory words. It is called a ‘register file’ because it behaves like a number of (numbered) registers connected in such


a way that you can address the registers for writing at the clock, with reading done by multiplexing the outputs of the registers.

Reading: simply place the address you want to read at the address input of a read/write or read-only port, after a short delay the output will be updated to the value which is present in the memory at the indicated address. Writing to that address will automatically update the output (again, after a short delay). No commands are necessary to read, nor do you have to wait for the clock.

Writing: place the address you want to write at the address input of a read/ write or write-only port, the data you want to write at the data input of that port and send a ‘write’ command to the address input of that port. At the next clock the data will be written into the indicated memory location and all ports reading that location will have their output updated to the value which was written.

If another port is writing the same location at the same time, the value actually written in the memory is unknown (so this 'write clash' is definitely not a good idea – IDaSS by default breaks off simulation when this happens).

Sending the ‘write’ command to the memory module instead of the port’s address input will invoke a write action in all ports with write functionality.

Timing: reading is a combinatorial operation done with (a lot of) multiplexers. The delay depends mainly on the number of words in the memory (and also upon the implementation method – the ‘distributed RAM’ is much faster than the separate Flip-Flops implementation).

For writing, the address must be decoded to point to one of the words in the memory, so the address setup time to the clock is significant and increases with every address bit added. Data and command input setup times are not as large as for the address input, but are definitely longer than for a normal register.

Restrictions:

• The system reset value may not be set to ‘hold on reset’ (IDaSS assu-mes some kind of non-volatile storage if you specify that, and this is simply not possible in the FPGA). Implementation with distributed RAM modules is only possible if the system reset value is UNKnown.

• Read and write functionality must be available for all memory words – it is not allowed to define a 6-ported register file module which is partially read-only or partially write-only. It is allowed, of course, to have extra ports which do not access the complete memory.


Port technologies:

1) The ‘Asynchronous read/synchronous write port’ follows the true beha-viour of the read/write port on the 6-ported register file implementation. Up to six of these ports may be present.

2) The ‘Asynchronous read-only port’ provides the reading behaviour of port type 1). Up to 5 of these ports may be used, together with a sixth port which must be either read/write or write-only.

3) The ‘Synchronous write-only port’ provides the writing behaviour of port type 1). Up to 5 of these ports may be used, together with a sixth port which must be either read/write or read-only.

3.1.2.5 Single ported asynchronous ROM

This is a memory model implemented with distributed RAM blocks whose write function is disabled. The RAM is loaded during programming of the FPGA with the contents of the simulated ROM in IDaSS as they were during the Verilog file generation process. A single read-only port should be used.

The data to be stored in asynchronous ROM’s is defined using ‘INIT’ parameters in the generated Verilog code. Unfortunately, the Xilinx WebPACK tools (as delivered) do not recognise these parameters. Note that the commercial Xilinx tools do not have this limitation.

To get the WebPACK synthesis tools to handle asynchronous ROM initialisation correctly, you have to add one text line to a source text file delivered with the Xilinx WebPACK tools:

Open the file <WebPACK>\verilog\src\iSE\unisim_comp.v (you should replace <WebPACK> by the directory in which you installed the Xilinx WebPACK tools), using a text editor like ‘write’ or ‘wordpad’. Search for the text fragment ‘module RAM16X1S’. Below the ‘input’ connectors line in that module description, add the following line (copy this line exactly, as Verilog is letter case sensitive!):

parameter INIT = 16’h0000;

After this addition, you can save the file (as ‘flat text’, no formatting!) and close the text editor. Note that, if you plan to use synchronous ROM’s too, you have to make some other additions to the same file – see the next section.

Reading: simply place the address you want to read at the address input of the read-only port, after a short delay the output will be updated to the value in the memory at the indicated address. No commands are necessary to read, nor do you have to wait for the clock.

Timing: reading is a combinatorial operation done with (a lot of) multiplexers. The four lowest address bits select the bits within the distributed RAM


blocks to be read, higher address bits control multiplexers which select between the outputs of these distributed RAM blocks. For memory depths up to 16 words, the delay from address change to output upda-te is constant (and rather short). Above 16 words, the delay increases with each extra address bit.

Restriction:

• The read port should be able to address all memory words in the ROM.

Port technology:

• The ‘Asynchronous read-only port’ should be used for the read-only port on the asynchronous ROM.

3.1.2.6 Single/dual ported synchronous ROM

This is a memory model implemented with block RAM modules whose write function is disabled. The RAM is loaded during programming of the FPGA with the contents of the simulated ROM in IDaSS as they were during the Verilog file generation process. One or two read-only ports must be present.

The data to be stored in synchronous ROM’s is defined using ‘INIT’ parameters in the generated Verilog code. Unfortunately, the Xilinx WebPACK tools (as delivered) do not recognise these parameters. Note that the commercial Xilinx tools do not have this limitation.


To get the WebPACK synthesis tools to handle synchronous ROM initialisation correctly, you have to add some text fragments to a source text file delivered with the Xilinx WebPACK tools:

Open the file <WebPACK>\verilog\src\iSE\unisim_comp.v (you should replace <WebPACK> by the directory in which you installed the Xilinx WebPACK tools), using a text editor like ‘write’ or ‘wordpad’. Search for the text fragment ‘module RAMB4_S1’. Below the ‘input’ connector lines in that module description, add the following lines (copy these lines exactly, as Verilog is letter case sensitive – notice the lowercase ‘a’ through ‘f’ in the parameter names!):

parameter INIT_00 = 256’d0; parameter INIT_01 = 256’d0; parameter INIT_02 = 256’d0; parameter INIT_03 = 256’d0; parameter INIT_04 = 256’d0; parameter INIT_05 = 256’d0; parameter INIT_06 = 256’d0; parameter INIT_07 = 256’d0; parameter INIT_08 = 256’d0; parameter INIT_09 = 256’d0; parameter INIT_0a = 256’d0; parameter INIT_0b = 256’d0; parameter INIT_0c = 256’d0; parameter INIT_0d = 256’d0; parameter INIT_0e = 256’d0; parameter INIT_0f = 256’d0;

After this addition, add the same lines to the following modules (copy and paste of text will save a lot of typing here…):

‘module RAMB4_S16’ ’module RAMB4_S4’ ’module RAMB4_S16_S16’ ’module RAMB4_S4_S4’ ’module RAMB4_S1_S1’ ’module RAMB4_S8’ ’module RAMB4_S2’ ’module RAMB4_S8_S8’ ’module RAMB4_S2_S2’

After this, you can save the file (as ‘flat text’, no formatting!) and close the text editor. Note that, if you plan to use asynchronous ROM’s too, you have to make one other addition to the same file – see the previous section.

Reading: place the address you want to read at the address input of a port and send a ‘read’ command to that address input. After the next clock, the output of the port will be updated to hold the value which is present in the ROM at the indicated address – this output will remain stable until the next update by another read operation on the same port. If you send the ‘read’ command to the memory module instead of to a specific address input, all ports will perform a read action.

Timing: the address and command inputs are clocked into Flip-Flops inside the block RAM modules. There is very little (if any) logic added for address decoding when combining block RAM modules into a larger memory. This means that these inputs need only a short setup time to the clock. The data outputs, however, need a relatively long time to stabilise after the clock – for optimal system performance, do not put much logic between the outputs of the ROM and the next registers in which these outputs must be stored!


Restriction:

• At least one of the read ports should be able to address all memory words in the ROM.

Port technologies:

1) The ‘Latched output read-only port’ follows the true behaviour of the actual read-only ports on the single/dual ported synchronous ROM implementation. This port’s output can be set up to initialise to 0 after system reset (default is UNKnown).

2) The ‘Synchronous read-only port with automatic TS-enable’ is provided for backwards compatibility (older designs may still use this one). This port’s output is (in the IDaSS simulation!) not latched but falls back to UNKnown after the output clock cycle and the output is always UNKnown after system reset. If the output is made a three-state output, this one will be enabled automatically during the output clock cycle following a read command.

3) The ‘Synchronous read-only port’ is provided for backwards compatibi-lity too. It has the same behaviour as port type 2) but lacks the automa-tic three-state output enable feature.

3.1.2.7 First-In-First-Out (or ‘queue’) memory

This is a memory model implemented with separate Flip-Flops and associated combinatorial logic. A specialised write input is used to write words into this memory sequentially, starting at the lowest available address, incrementing the write address automatically after each write. A read port may be attached which always reads at address 0, a read operation shifts all words in the memory down by one address, allowing the read port to ‘see’ the next word written in the memory (if any).

Reading: the read port always outputs the word at address 0 in the FIFO, which should be the first word written and not yet read. To access the next word written in the memory, send the ‘read’ command to the FIFO module, which will shift all words in the FIFO down by one address at the next clock.

When reading and not writing, the count of words in the FIFO will be decremented by one. In IDaSS, simulation stops with an error if you execute the ‘read’ command on an empty FIFO – the hardware imple-mentation does not have any protection against this error and its behavior is unspecified.

Writing: place the data you want to write at the data input of the special write input port and send a ‘write’ command to the FIFO module. It is also possible to issue the ‘write: <value>’ command for writing values without using a data input. Only one write command may be issued at


the same time. At the next clock the data will be written into the word following the already written memory words (or at address 0 if the FIFO was empty).

When writing and not reading, the count of words in the FIFO will be incremented by one. In IDaSS, simulation stops with an error if you execute ‘write’ or ‘write: <value>’ commands on a full FIFO (when not reading at the same time) – the hardware implementation does not have any protection against this error and its behaviour is unspecified.

When writing and reading at the same time, the count of memory words in the FIFO will remain the same, the already present words will shift down one address and the new word will be written in the location which was occupied by the previously highest addressed word.

Timing: the read port is attached directly to the Flip-Flops which store the word at address 0. If a state controller needs to check the amount of words in the FIFO, this test channel will be attached directly to the Flip-Flops of the write address up/down counter. Both outputs will be updated immediately after the clock.

Data moves within the FIFO are done with multiplexers. As write address generation is done internally, it does not add timing constraints. In effect, data and command input setup times to the clock are comparable to a normal register module.

Restriction:

• Read and write functionality should both be present and should also be used. The write data input need not be present when ‘write: <value>’ commands are issued. The read port need not be present when a state controller is used to test the head value of the FIFO directly.

Port technology:

• The ‘Head output’ port should be used to read from the FIFO. This is actually a fixed address read port which is limited to read address 0 only.

3.1.2.8 Last-In-First-Out (or ‘stack’) memory

This is a memory model implemented with separate Flip-Flops and associated combinatorial logic. A specialised write input is used to write words into this memory at address 0, optionally ‘pushing’ already present words to higher addresses with each write. Two read ports may be attached which read at addresses 0 and 1 respectively. A ‘pop’ operation shifts all words in the memory down by one address, allowing the read ports to ‘see’ the previous words written in the memory (if any).


Reading: two read ports may be placed in the LIFO. The first one always outputs the word at address 0 in the FIFO, which (in general) is the last word written and not yet removed. The other read port outputs the word at address 1, which contains the next-to-last word written. To access the previous words written in the memory, send the ‘pop’ command to the LIFO module, which will shift all words in the LIFO down by one word at the next clock (removing the last word written). A ‘pop2’ command shifts all words down by two words (effectively removing the last two words written).

When reading and not writing, the count of words in the LIFO will be decremented by one or two. In IDaSS, simulation stops with an error if you execute the ‘pop’ or ‘pop2’ commands on a LIFO which does not contain the amount of words to be removed – the hardware implemen-tation does not have any protection against this error and its behavior is unspecified.

Writing: place the data you want to write at the data input of the special write input port and send a ‘push’, ‘replace’ or ‘poprepl’ command to the FIFO module. It is also possible to issue the ‘push: <value>’, ‘replace: <value>’ or ‘poprepl: <value>’ commands for writing values without using a data input. Only one command may be issued at the same time (with one exception: the ‘reset’ command to reset the ‘fill level’ counter to zero overrules all other commands).

At the next clock the data will be written into the word at address 0. What happens to the already stored words depends upon the actual command issued – a ‘push..’ shifts them one word higher, a ‘replace..’ does not move them and a ‘poprepl..’ shifts them one word lower (removing the word at address 1 and replacing the word at address 0 at the same time). The ‘pushcopy’ command works like ‘push’ but leaves the word at address 0 intact. The ‘swap’ command is not an actual writing command as it simply swaps the words at addresses 0 and 1 in the LIFO (the number of words remains the same).

In IDaSS, simulation stops with an error if you execute commands on a LIFO which does not contain enough words to fulfill the command or which contains too many words to handle the command – the hardware implementation does not have any protection against these errors and its behaviour is unspecified.

Timing: the read ports are attached directly to the Flip-Flops which store the words at addresses 0 and 1. If a state controller needs to check the amount of words in the LIFO, this test channel will be attached directly to the Flip-Flops of a ‘fill level’ up/down counter (which is specificatlly created for this purpose). All these outputs will be updated immediately after the clock.

Data moves within the LIFO are done with multiplexers. Data and command input setup times to the clock are comparable to a normal register module. Note that the use of the ‘pop2’ command brings a


huge increase in the amount of hardware needed and a noticeable decrease in attainable speed (it requires an extra multiplexer input on all Flip-Flops in the LIFO storage structure – with a ‘huge increase’, we mean a factor of more than two!).

Restriction:

• Read and write functionality of some kind should both be present and should also be actually used.

Port technologies:

1) The ‘Top-of-stack output’ port should be used to read from the first word of the LIFO. This is actually a fixed address read port which is limited to read address 0 only.

2) The ‘Next-of-stack output’ port should be used to read from the second word of the LIFO. This is actually a fixed address read port which is limited to read address 1 only.

3.1.2.9 Content Addressable (or ‘associative’) Memory

This is a complex memory model implemented with separate Flip-Flops and associated combinatorial logic. Specialised inputs are used for searching and modifying the memory contents in a single clock cycle. Specialised outputs are used to indicate the search results and data words found. Additional memory ports can not be added, although normal (addressed) read/write functionality can be provided through the specialised inputs and outputs.

Searching and modifying: these form the most important operations of the CAM. A search-and-modify operation is done in a single clock cycle.

Searching is done by comparing a given data word with all words already stored in the memory. A ‘mask’ word can be used to indicate which bits of this data word must actually be compared (a 0 bit in the mask indicates this bit is not compared – the data word and memory words may differ there). More than one word in the memory may match with the given data and mask words. Which words match can be output on a special ‘match mask’ output (a 1 bit indicates a match there). Alternatively, a ‘first matching address’ output can be generated which indicates the address of the first word which matched the data and mask words. The actual value of the first matching word in the memory can be output on a special output, this word can also be tested directly from a state controller. State controllers can also check whether or not a match occurred, with an optional extension to check whether more than one match occurred. Sending the ‘match’ command performs a search action without modifying the memory contents.

Modifying memory words is done either by directly writing a new value (from a special data input) or by setting and/or resetting bits (using ‘set


mask’ and ‘reset mask’ inputs). The ‘wrfirst’ command performs the modify operation on the first word found matching in the memory (the one at the lowest address) only. The ‘wrall’ command performs the same modify operation on all matching words in the memory – in addition, ‘wrall’ can perform a completely separate modify operation on all non-matching words in the memory.

All the input values for searching and modifying can be specified with separate commands (like ‘mask: <value>’). If an input is present for a specific value, the command specifying that same value may not be issued anymore.

All search-and-modify commands are synchronous – commands and input values must be stable before the clock, the actual operation is performed on the clock and outputs are updated after the clock.

Reading: normal (addressed) reading of a CAM is possible with the ‘rdaddr’ command, but only when a special address input is present. The data at the addressed word is output on the output normally used for the first matching word (and can also be checked by state controllers). Reading is synchronous, the output is updated after the clock while the com-mand and the address have to be given before the clock. The search status is updated to indicate a single match at the address which is read.

Writing: addressed writing of a CAM is possible with the ‘wraddr’ command, but only when a special address input is present. The operation performed on the addressed word is the same as for the ‘wrfirst’ command (uses the same data or set/reset mask values). The search status is updated to indicate a single match at the address which is written.

Timing: there is a lot of combinatorial logic involved in the CAM. Compare logic, a (huge) priority encoder to determine the first matching word and logic to determine the new values in the memory are all placed in front of the Flip-Flops containing the memory words. As a consequen-ce, the match data, match mask and address inputs as well as the command have to be stable a long time before the clock. Data and set/reset mask inputs may stabilise later, but still well before the clock. Almost all outputs are taken directly from Flip-Flops, so they are updated immediately after the clock. The only exception is the match status check output for state controllers, which requires some logic to generate out of Flip-Flop states.

Restrictions:

• The CAM implementation does not support the status mode ‘count of matches’, as this requires too much (sloooow) combinatorial logic inside the module. If needed, a ‘count of matches’ can be created with an external operator block attached to the ‘match mask’ output using the ‘onecnt’ basic expression operator.


• A one bit wide CAM with a parameter defining the default function will place the parameter input in the sensitivity list of one of the processes written out in Verilog. This input may not be used in that process which may (at least) generate some warnings. As it is very unlikely that such a CAM will ever be used, no attempt has been made to resolve this problem.

Port technologies:

• None. The CAM implementation does not allow extra read and/or write ports to be added

3.2 Indicating pin locations and I/O options

When converting an IDaSS design into the Verilog code needed to synthesize an FPGA, pin numbers for all input/output connectors of the IDaSS design can be assigned automatically. If you convert a single IDaSS building block other than a sub-schematic (not recommended!) or fail to set conversion options correctly, placement is left to the Xilinx tools with completely unpredictable results – these optimise internal logic placement and then route signals to the pins physically closest to the logic blocks.

If you set the conversion switches (explained in appendix A, page 58) as indicated in the spartan2e.ini file and write out a sub-schematic, a ‘User Constraints File’ will be generated which forces a more sensible (but still automatic) pin placement in the Xilinx tools. This form of automatic pin placement will be described in the next section.

It is possible to modify the generated User Constraints File by hand to control pin placement, but this is not recommended – it is an error-prone process and the modifications will be lost when you re-generate the file during the next IDaSS-to-Verilog conversion.

It is much more convenient to fix pin locations within the IDaSS design. The conversion can then take these into account when generating the Verilog code and User Constraints File. This is done with the ‘properties’ facility in IDaSS which allows attaching extra information to IDaSS design elements. Attached properties are stored in the design file (so they do not get lost) and are also included in automatically generated documentation.

Aside from pin placement, it may be necessary to control other I/O options. By default, pins are compatible with normal TTL logic (see footnote on page 12) and active outputs are normal ‘push-pull’ outputs capable of driving 12 milli-Ampère loads. The current spartan2e.aft conversion does not allow the logic family to be changed, but provides a lot of other options (like drive power, output configuration and speed) through additional property settings.


The first part of a property name indicates where the property applies (to all pins, the pins of a bus or a single pin). This part of the name also indicates to which IDaSS design element the property must be attached:

• GLOBAL, RESET and CLOCK properties must be attached to the schematic contents of the actual FPGA sub-schematic to be filed out (open an edit window on this sub-schematic, then select ‘properties…’ from the menu of an empty location on this schematic).

• BUS and PIN properties must attached to the (in IDaSS bidirectional) connectors within off-schematic connector blocks on the filed-out FPGA sub-schematic. PIN properties have a secondary (numeric) key (indicated with <bitNumber> below) which defines the bit number of the bus for which this property is defined.

A PIN property overrules BUS and GLOBAL properties, while a BUS property overrules GLOBAL properties where no PIN property applies. RESET and CLOCK properties apply to the (in IDaSS invisible) reset and clock input pins, these overrule GLOBAL properties applicable to input pins.

The second part of a property name indicates the actual function of the property.

The next two sections split the properties in two – the first section describes pin placement properties and the last section describes the I/O option properties.

Note: if a property value is indicated with <…String>, you should enter one of the text strings indicated in bold font. To tell IDaSS that it is a text string value, you should start with a single quote (this quote is not stored as part of the property value). Do not put a single quote at the end, as this one will be stored as part of the property value. So, for the BUSORDER property, you may enter <orientationString> ‘reversed’ – in the IDaSS text entry window, you should enter ’reversed (the underlined characters only!). Property names and string values are letter case unsensitive (as usual in IDaSS).


3.2.1 Device pin assignment

Pin assignment is based upon lists of device pins which are actually available for user input/output. The Xilinx Spartan-II(E) device datasheets give ‘device pinout’ lists which are ordered according to the attachment of pins to the actu-al chips inside the packages. So-called ‘ball grid array’ packages have a square array of connection bumps which do not appear to have any ordering, but the cheaper ‘plastic flat square’ packages have a straightforward connection pattern from the pins to the chip boundary, as illustrated in the next drawing for the PQ208 package:

Pin 53

Pin 1

Pin 104

Pin 52 Pin 105

Pin 156

Pin 157 Pin 208

actual chip

Pin 1 indication

The Spartan-II devices placed in this package provide up to 139 usable data input/output pins (141 for the Spartan-IIE devices in this package) and 4 specialised clock input pins. The remaining pins are used to power the device and for program and test purposes. For automatic pin placement (and easier manual pin placement), the actual data pins are given index numbers from zero up to the number of data pins minus one. By default, pin index 0 refers to the lowest numbered data pin number (pin 3 for this package), pin 1 refers to the next data pin (pin 4 in this case), up to the highest index which points to the highest numbered data pin number. Appendix B provides tables relating the index numbers to the actual device pin names for the devices currently supported by the spartan2e.aft converter.

Automatic pin assignment

Automatic pin placement will always place the system reset input pin (if used) at index 0, then works through the data buses crossing the FPGA sub-sche-matic one at a time. Each of these buses is assigned progressively higher pin index numbers. The buses are grouped by data direction (inputs first, then outputs, then bidirectional buses), then ordered alphabetically by name within each group. Within a multi-bit bus, bit number 0 is by default assigned the lowest pin index with higher numbered bits assigned progressively higher


indexes. Conversion will fail with an error message if there are more data pins required than actually available on the selected package.

Automatic data pin assignment is influenced by the ‘data pad nr. offset’ value setting available in the template settings menu (see appendix A). All automati-cally assigned index numbers have this offset value added, effectively rotating the data connections around the chip periphery. The addition is done with ‘wrap around’ – if the assigned index number with the offset added produces a too-high index, the number of data pins is subtracted again to bring it back into range. For instance, a data pin with index 138 (the highest number for the PQ208 package) with offset 1 added gives illegal index 139. The number of data pins (139 in this case) is subtracted, yielding pin index 0. As a result, the data pad offset value of 1 moves all pins to the next higher index number except for the highest indexed pin which is moved to index 0.

It is a good idea to set the data pad offset to the index number of the pin which is connected to an external system reset circuit. This makes sure that the system reset is connected correctly even if no manual pin assignments are done.

Clock pin assignment

The Spartan-II(E) devices have four special clock input pins, named ‘GCK0’ through ‘GCK3’. Each of these is connected to an internal clock distribution network through a special synchronisation circuit which can also double the clock frequency. The actual pins used for these clock inputs depends upon the device/package combination. Lists relating the clock pin names to actual device pins can be found in appendix B.

The template settings menu allows you to select one of the clock inputs for clocking the IDaSS design. It is also possible there to select the kind of internal clock handling (pin connected directly to the distribution network, through a synchronisation circuit which removes the distribution network delay or through a clock frequency doubler). See appendix A for more details.

Manual pin assignment using properties

Below, you will find the list of properties which can be used to assign device pins to IDaSS buses from within IDaSS itself. Remember that BUS… and PIN… properties must be attached to the bidirectional connector within off-schematic connector blocks on the filed-out FPGA sub-schematic. All other properties must be attached to the contents of the actual FPGA sub-schematic.

If you assign data pin locations with IDaSS properties, the data pad offset value used for automatic assignment is completely ignored. You either use the index numbers indicated in the tables in appendix B (with the ‘…LOC’ properties) or direct pad names (with the ‘…PAD’ properties). Note that pad names are case-sensitive and have to be entered exactly as given in the


tables (if the tables indicate ‘P3’, enter ’P3 in the text input window with an uppercase P).

BUSLOC <pinIndex>

Defines the device pins to be used for this connector’s bus by giving the first data pin index to be used. This is normally the pin for bit 0 of the bus, with higher bits assigned to progressively higher pin indexes. Overrules automatic pin placement, but uses the same index to pin number translation tables given in appendix B. Wraps around like automatic placement, but does not check if the pins are already in use!

BUSORDER <orientationString>

If the <orientationString> is set to ‘reversed’, the pins for this connector’s bus will start with the highest bit number at the lowest pin index (instead of with bit number 0 as usual). Works for automatic placement as well as when BUSLOC is used, wraparound remains active.

PINLOC <bitNumber> <pinIndex>

Forces a specific pin index to be used for the indicated bit number (numeric sub-key) of this connector’s bus. Overrules automatic pin placement as well as BUSLOC, but uses the same index to pin number translation tables given in appendix B. Does not check if the pin is already in use!

RESETLOC <pinIndex>

Fixes the pin on the device to be used for the system reset input. Overrules automatic pin placement controlled by ‘data pad number offset’ (where reset would always be the first pin), but uses the same index to pin number translation tables given in appendix B. Does not check if the pin is already in use!

PINPAD <bitNumber> <padString>

Overrules pad name generation for the pin associated with the indica-ted bit number (numeric sub-key) of this connector’s bus. The given <padString> is inserted as-is in the User Constraints File between double quotes after ‘LOC = ‘. No checking done at all!

This property can be used to assign an input bit to unused clock input pins. This provides extra input pins, although it does not remove the check for the available amount of data pins (it helps when you are placing more than one design in a single FPGA, although you will have to combine the designs within the WebPACK tools). When using a clock input as extra data input, you have to change the pad type in the Verilog .v file from 'IBUF' to 'IBUFG' with a text editor (needed when using the test switch on a B5-SPARTAN2+ protoyping board).


RESETPAD <padString>

Overrules reset pad name generation (automatic or with RESETLOC), inserting the given <padString> as-is in the User Constraints File between double quotes after ‘LOC = ’. No checking done at all!

CLOCKPAD <padString>

Overrules clock pad name generation set by template menu, inserting the given <padString> as-is in the User Constraints File between double quotes after ‘LOC = ’. No checking done at all – note that it is not allowed to assign a clock input to a normal input pin. This property is meant to be used only when working with devices not yet supported by spartan2e.aft.

3.2.2 I/O driver/receiver properties

Below, you will find the list of properties which can be used to modify properties of input/output pins. BUS… and PIN… properties must be attached to the bidirectional connector within off-schematic connector blocks on the filed-out FPGA sub-schematic – these apply to all pins in the bus and to a sin-gle pin respectively. All other properties must be attached to the contents of the actual FPGA sub-schematic. BUS… properties overrule the GLOBAL… properties while PIN… properties overrule both BUS… and GLOBAL… set-tings.

GLOBALDRIVE <strength> BUSDRIVE <strength> PINDRIVE <bitNumber> <strength>

Defines the output drive strength for normal, three-state and bidirectio-nal outputs. <strength> is given as numeric value in milli-Ampères, with possible values 2, 4, 6, 8, 12 (default), 16 or 24.

GLOBALOUTTYPE <outTypeString> BUSOUTTYPE <outTypeString> PINOUTTYPE <bitNumber> <outTypeString>

Defines the output circuit configuration for normal, three-state and bidirectional outputs. <outTypeString> can be one of the following:

‘normal’: This is the default, a logic 0 pulls the output down to 0 Volt while a logic 1 pulls the output up to the supply voltage of 3.3 Volt.

‘oc’: Short for ‘open collector’, a logic 0 pulls the output down to 0 Volt, a logic 1 leaves the output unconnected (may be pulled up to 3.3 or 5 Volt externally through a resistor, it is


also possible to pull the output up to the 3.3 Volt suppy voltage through an internal ‘pull-up’ resistor).

‘oe’: Short for ‘open emitter’, a logic 1 pulls the output up to the supply voltage of 3.3 Volt while a logic 0 leaves the output unconnected (may be pulled down to 0 Volt through an internal or external ‘pull-down’ resistor).

‘switch’: For this special type, a logic 1 pulls the output down to 0 Volt, a logic 0 leaves the output unconnected (may be pulled up to 3.3 or 5 Volt externally through a resistor, it is also possible to pull the output up to the 3.3 Volt suppy voltage through an internal resistor). This output type is very suitable for driving LED’s.

GLOBALRESISTOR <resistorString> BUSRESISTOR <resistorString> PINRESISTOR <bitNumber> <resistorString>

Allows an internal resistor to 0 Volt or to the supply voltage of 3.3 Volt to be enabled on input, three-state output and bidirectional pins. This resistor can also be enabled for normal outputs which use a non-default <outTypeString>. Because the ‘resistor’ is actually a small transistor, the resistance value depends upon the output voltage and a lot of other factors, but is at least 13 Kilo-Ohm. The <resistorString> can be one of the following:

‘none’: This is the default, no internal resistor enabled.

‘pullup’: Enables an internal resistor connected between the pin and the supply voltage of 3.3 Volt.

‘pulldown’: Enables an internal resistor connected between the pin and 0 Volt.

‘keeper’: Enables a special internal circuit which tries to keep the pin voltage stable at either 0 Volt or the supply voltage of 3.3 Volt. Because this ‘keeper’ circuit is connected to the pin via a resistor, it is no problem to change the pin voltage. This option can not be used on an input-only pin.

CLOCKRESISTOR <resistorString>

Defines an internal resistor to be connected to the clock input pin. <resistorString> can be ‘none’, ‘pullup’ or ‘pulldown’. If not given, the GLOBALRESISTOR setting applies to the clock input.

RESETRESISTOR <resistorString>

Defines an internal resistor to be connected to the system reset input pin. <resistorString> can be ‘none’, ‘pullup’ or' ‘pulldown’. If not given, the GLOBALRESISTOR setting applies to the reset input.


GLOBALSPEED <speedString> BUSSPEED <speedString> PINSPEED <bitNumber> <speedString>

Defines the output transition speed for normal, three-state and bidirec-tional outputs. <speedString> can be set ‘slow’ (default) or ‘fast’.

It is not a good idea to set a lot of outputs to ‘fast’, as fast output transi-tions require a lot of power – if many of these occur at the same time (for instance when a 32 bit output bus switches from all zeroes to all ones), the power supply current pulse may cause power supply voltage drop-outs (which in turn may lead to Flip-Flops loosing their state).

GLOBALDELAY <delayString> BUSDELAY <delayString> PINDELAY <bitNumber> <delayString>

Advanced, most users will never need these properties…

When an input pin (or the input side of a bidirectional pin) is connected to a Flip-Flop within the Input/Output Block of a Spartan-II(E) FPGA, a delay circuit is inserted between them to prevent certain timing pro-blems (see the Xilinx documentation for more information).

Normally, Flip-Flops are synthesized outside the Input/Output Blocks, so this delay is not present (and you don’t have to worry about it). To let the WebPACK synthesis tools use these Flip-Flops, you have to change the ‘Pack I/O Registers/Latches Into IOBs’ setting of the ‘map options’ for the ‘implement design’ process within the WebPACK project navigator to ‘on’ (the default is ‘off’).

The …DELAY properties allow you to bypass the delay circuit to make the inputs faster – keep in mind that the delay is there to prevent problems! <delayString> can be set to ‘normal’ (default) or ‘none’, the latter removes the delay.

3.3 Generating synthesis files from IDaSS

Once everything has been set up, generating the necessary Verilog description of an IDaSS design (with an accompanying ‘User Constraints File’ containing extra information) is as simple as saving an IDaSS design.


The only problem lies in where to store these files. There are two different ways to transfer them to the WebPACK synthesis tools, the ‘official’ way and a ‘direct’ way:

• The ‘official’ way to transfer synthesis files to WebPACK is to store them in any convenient spot (for instance, the normal IDaSS designs directory). From there, the Verilog code can be ‘added’ to a so-called ‘project’ within WebPACK. This ‘add’ operation will either set up a pointer to the generated file or copy the file to a special project directory and use this copy.

The main problem with this ‘official’ way is that the ‘User Configuration File’ has to be copied (or moved) separately into the project directory. To make certain that its presence is detected, this copy operation has to be done before the ‘add’ operation.

• The ‘direct’ way to transfer synthesis files to WebPACK is to let IDaSS generate them in the project directory. The ‘add source to project’ operation will then find the Verilog file immediately and the ‘User Constraints File’ can not get lost (and, because of its filename, it will be used automatically).

For convenience, we have chosen the ‘direct’ way and are going to explain things in the order which must be followed. If you want to go the ‘official’ way, you can leave the next section for later until you start up the WebPACK tools for the first time.

3.3.1 Creating a WebPACK project directory

Before you can actually use the Xilinx WebPACK tools, you have to create a project directory to store all files related to a synthesis session. To do so, start the main WebPACK ‘project navigator’ tool (easiest from the desktop icon created during installation, otherwise look for a file called webpack.exe) and select ‘File’/’new project’ from the menu bar. This will open the following entry form window:


Give the project a name and select a ‘project location’ directory (click on the […] button if you don’t want to type a directory path yourself). A sub-directory with the project name will be created automatically in this ‘project location’ directory. This sub-directory is what we call the ‘project directory’ here.

WARNING: to prevent problems, both the project name as well as the ‘project location’ path may not contain any spaces. If you really want to, you can use underscore characters (‘_’) instead of spaces.

Next, you have to set the three indicated properties to their correct values. The top two indicate the device family and actual device within this family you are going to synthesize. The bottom selection indicates the synthesis langu-age (has to be Verilog as this is what IDaSS generates) and accompanying tool. To change a value, point your mouse within the field containing the value at the right hand border, then click your left mouse button and select from the drop-down menu which opens. For using the B3/5-SPARTAN2+ prototyping boards, you have to choose the following values:

Device Family = Spartan2 Device = xc2s200-5pq208 Synthesis Tool = XST Verilog

For using the B5-SPARTAN2E+ prototyping board, you have to choose the following values:

Device Family = Spartan2E Device = xc2s300e-6pq208 Synthesis Tool = XST Verilog

After completing these selections, click the OK button to close the entry form. The ‘Module view’ of the top-left subwindow should now show something like the following:

This completes the preparation of the project directory. If you have an IDaSS design ready for synthesis, you can keep the project navigator open. Otherwise, close the project navigator window – project settings will be saved automatically.

If you want to change the project properties later, click the right mouse button while pointing at the white-on-blue text (to the right of the ‘integrated circuit’ icon) and select ‘project properties’ from the menu which pops up.


3.3.2 Pre-conversion ‘checklist’

In this section we give a short list of ‘reminders’ – things which must have been taken care of before actually generating synthesis files from within IDaSS. Even experienced users sometimes miss one of these points and end up with surprising hardware behavior…

Most of the design rules explained in section 3.1 are checked during the conversion process and will break off conversion if they are not met. The items indicated in the following checklist can not (or only in in a limited way) be checked there – you have to do the checking to get an operational system!

System reset: Make sure your system can actually start up after a system reset – do not forget to define a non-UNKnown system reset value for those registers which need one.

Pin locations and I/O properties: Make sure you have correctly set up all the IDaSS properties to control pin locations and input/output driver properties – double check every-thing here!

ROM’s: If you are using ROM’s in your design, make sure that they contain the actual contents they should have in the FPGA. Also, do not forget the necessary modifications to one of the WebPACK files as explained on pages 24 and 26 of this text.

Test environment links: At the moment of conversion, a test environment outside the system should not have any invisible test and/or control links with the system – be careful with state controllers and Algorithmic Level blocks in the test environment!

Parameter value definitions: All numerical IDaSS parameters used within the converted system should be defined (given a value) within that system.

Template menu settings: Before actually filing out, make sure you set have the ‘template menu settings’ properly. Appendix A gives a full list of all settings and what they mean, the default settings indicated there (and in the spartan2e.ini file) are correct for generating synthesizable files for the Spartan-IIE 300 FPGA as mounted on the B5-SPARTAN2E+ prototy-ping board or the Spartan-II 200 PQ208 as mounted on the B3/5-SPARTAN2+ boards.

With all items in this checklist checked, you can start the actual sythesis process by generating the files which describe your IDaSS design in a form which the WebPACK tools can handle.


3.3.3 Actual synthesis files generation

After installing all programs, creating a WebPACK project directory and creating and checking an IDaSS design, the actual synthesis files generation starts by selecting ‘save…’ in the menu of the subschematic symbol which represents the FPGA to synthesize, followed by ‘to Spartan-II(E) Verilog’.

In the file selection window which opens, select the actual project directory you created in section 3.3.1 and save the design there in a Verilog file with extension .v (you can choose your own base name but, again, do not use spaces in this name). The accompanying ‘User Constraints File’ named d2vSCHEMA_1.ucf will automatically be placed in the same directory (overwriting earlier versions of this file without warning!).

After some initial checks, the system will ask for a ‘designer name’ – the text string you enter will be placed as-is in the headers of both the Verilog file and the ‘User Constraints File’.

The actual conversion may take some time (with really large systems, think in tens of minutes). Its progress will be shown in one of the IDaSS message sub-windows. As there is no way to predict the actual time needed, the progress indication does not show the amount of time left but rather the design element which is handled and the operations performed there. Be patient – some conversion steps (like complex expression optimisation) can take minutes, even on a fast computer!


4 Synthesizing and downloading of the design in the FPGA

With the IDaSS design finished and converted into a Verilog description and accompanying ‘User Constraints File’, most of the work is done. After proper configuration of the Xilinx WebPACK tools and attaching an actual FPGA to the computer, getting the design to run in the FPGA hardware is a handful of mouse-clicks away.

Be warned, however, that the synthesis process may take some time. A design which fits easily in the target FPGA and does not require optimisation for highest speed can be ready for downloading in less than a minute. This time can extend to an overnight synthesis run if the FPGA can barely hold the design (say, more than 95% used) and/or you want the highest possible clock frequency!

One problem here is that configuration of the Xilinx WebPACK tools is only possible when an actual design has been created in the project directory. The first two sections of this chapter handle the synthesis and downloading operations including ‘on-the-fly’ configuration steps (which need to be done only once). The last section shows how you can run the same operations much more quickly once this first configuration has been done.

4.1 Synthesizing of the IDaSS design

After you saved your IDaSS design in the Xilinx tools’ project directory, it is time to synthesize the system. In this section, we explain in chronological order the five steps to get ready for actual downloading:

1) ‘Logic synthesis’ (inappropriately called ‘Synthesize’ in the WebPACK tools) which analyses the Verilog source code and creates a generic logic circuit out of it at the level of logic gates, Flip-Flops and some more complex modules like memories.

2) ‘Translate’ which is used to convert the (more-or-less) general purpose logic synthesis tools’ output file to another format suitable for the actual FPGA synthesis.

3) ‘Map’ which packs combinatorial logic and Flip-Flops into the actual logic blocks available on the FPGA and also performs some other optimisations.

4) ‘Place-and-Route’ which assigns the logic, memory and I/O blocks in the design to the actual hardware resources on the FPGA and then interconnects these with programmable ‘wires’.


5) ‘Create Programming File’ converts the generated FPGA hardware configuration into a .bit file which can be downloaded into the actual FPGA device.

It is assumed that initial configuration of the WebPACK tools has not been done, so we show the necessary settings here (these settings need to be done only once – they are saved to disk as soon as they are entered, no need to separately ‘save’ them).

4.1.1 Indicating to WebPACK which files to use

If not yet running, start the WebPACK ‘project navigator’ tool (if you have not created an icon on your desktop during installation, look for a webpack.exe executable file and run this one).

If you have been following the ‘direct’ way to transfer synthesis files to WebPACK, you have already created a project directory (as explained in section 3.3.1) and generated your Verilog description (a .v text file) and ‘User Configuration File’ (named d2vSCHEMA_1.ucf) in that directory.

If you chose the ‘official’ way to transfer synthesis files to WebPACK and have not yet created a (properly configured) project with acompanying directory, it is now time to do so (again, see section 3.3.1).

You can now indicate to the project navigator the source file to use by clicking ‘Project’ on its menu bar followed by ’Add source’ (for the ‘official’ way, it may be better to select ‘Add copy of source’ as this will place a local copy of the source file in the project directory). This will open a standard file selection window with which you select the Verilog source code .v file you generated with IDaSS. This file is analysed and the hierarchical structure of your converted design should be made visible in the top-left ‘Module view’ window.

The actual schematics in your design are numbered in the Verilog code, with the top-level FPGA sub-schematic always named ‘d2vSCHEMA_1’. All ROM’s and single/dual port RAM’s have been moved into this schematic by the conversion process and are also numbered. You can view (and even edit) the generated .v file in the top-right window by double clicking on the ‘d2vSCHEMA_1’ text line (shown in white-on-blue text in the picture).


Project navigator ‘processes’

After telling Xilinx which source file to use, several ‘processes’ become visible in the middle-left ‘Process view’ window of the project navigator. The ‘Synthe-size’, ‘Implement Design’ and ‘Create Programming File’ processes represent the major steps to be taken to get a design running in an FPGA.

Sub-processes can be made visible by clicking on the [+] squares in this window. The normal flow of operations is top-down through this hierarchy. Each successfully finished process is indicated with a green checkmark, while red crosses are used to indicate processes which finished with errors.

Not all processes are mandatory, but the process navigator knows which ones must be completed. You can start a process by simply double-clicking on its name. Processes which should be completed before this process but which have not yet run are automatically run in the correct sequence – in essence, once all settings are made, you only need to double click on ‘Create Programming File’ and everything runs automatically…

Editing the ‘User Constraints File’

The file d2vSCHEMA_1.ucf generated by IDaSS contains ‘User Con-straints’ – extra information needed by the synthesis and implementation processes which could not be placed in the Verilog source code. Although it should normally not be necessary to modify the ‘User Constraints’ as generated, it is possible.

The ‘Design Entry Utilities’ entry in the process view window has a sub-entry ‘User Constraints’ (click on the [+] to show sub-entries), which in turn offers sub-entries ‘Edit Implementation Constraints File’ and ‘Edit Implementation Constraints (Constraints Editor)’. The former process (when double clicked) opens a text editor on the constraints file – use with caution! The ‘Constraints Editor’ is a menu driven program which also edits this file, but is somewhat restricted in its capabilities.

More information on the syntax and capabilities of the ‘User Constraints File’ and the ‘Constraints Editor’ can be found in the WebPACK ISE online help system. Look in the ‘FPGA WebPACK ISE’, ‘Design methodologies and hints’, ‘Attributes’ hierarchy entries there.

4.1.2 The ‘Synthesize’ process and its properties

Before you can run the ‘Synthesize’ process for the first time, you will have to set its properties to the correct settings indicated below (these can all be kept


at their default values, but it can not harm to check them). To do so, select the ‘Synthesize’ process in the Process View window with a mouse click (the text becomes white-on-blue) and then choose ‘Process’ from the project navigator’s menu bar followed by ‘Properties…’. This will open a value entry form as indicated below:

After setting the options and clicking ‘OK’ to close the entry window, actual synthesis becomes very simple: just double click on the ‘Synthesize’ process indicated in the Process View window to synthesize the actual logic. This may give warnings flashing by in the bottom window (indicated with bright yellow markers), but it should give no errors (which are indicated with red markers there). When finished, a green checkmark should appear before the ‘Synthesize’ process name in the Process View window.

If you want to see what happened in more detail, start the ‘View Synthesis Report’ sub-process of the ‘Synthesize’ process. This report provides a first estimate of the amount of logic, memory and I/O blocks used by your design.

‘Synthesize’ process property settings

All property settings for the ‘Synthesize’ process can be kept at their default states (as displayed in the screendumps below). Some specific settings require some explanation as you may want to change them depending on your requirements.


The property ‘Synthesis Constraints File’ may be left blank because the filename d2vSCHEMA_1.ucf matches the name of the top level schematic written out in the Verilog code – this file will be used automatically. If more designs are placed in the same project directory, it is a good idea to rename this .ucf file to prevent it from being overwritten (IDaSS does not warn when overwriting this file!). After renaming, it is necessary to specifically set this property to point to the renamed file.

The ‘FSM Encoding Algorithm’ is set to ‘Auto’, which means that the synthesis tool will select an ‘optimal’ state encoding based upon timing and space requirements. In essence, the encoding as present in the Verilog file (selected by the IDaSS ‘template options…’ menu entry ‘state numbering’ – see appendix A) will not be followed. If you want to force the encoding as present in the Verilog file, select ‘User’ for this property.

Note that, although ‘RAM Extraction’ is set to ‘Yes’, the synthesis tools will not automatically use ‘block RAM’ modules – this is one of the differences between the WebPACK and commercial versions of the Xilinx tools. The IDaSS spartan2e.aft converter will instantiate and connect these block RAM modules automatically, bypassing this restriction of the WebPACK tools.


The ‘Xilinx Specific Options’ are best kept at the default values as shown.

4.1.3 The ‘Implement Design’ process and its properties

Before you can run the ‘Implement Design’ process for the first time, you will have to set its properties to the correct settings indicated below (in principle, all these properties can be kept at their default setting, but, again, it does not hurt to check…). To do so, select the ‘Implement Design’ process in the Process View window with a mouse click (the text becomes white-on-blue) and then choose ‘Process’ from the project navigator’s menu bar followed by ‘Properties…’. This will open a value entry form in which you can enter the settings. After setting the options correctly, you can click ‘OK’ to close the entry window and save the settings to disk.

When this is done, you can double click on the ‘Implement Design’ process which runs three sub-processes in sequence: ‘Translate’, ‘Map’ and ‘Place-and-Route’. If these are not visible, you can see these by clicking on the [+] marker before the ‘Implement Design’ process. Running these processes may generate warnings, but should give no errors. All of these processes create reports, some of which are very interesting (click some [+] markers to make the report names visible, then double click on them to open a report viewer window):

• The ‘Map Report’ generated by the ‘Map’ sub-process gives an exact indication of the amount of hardware resources used on the FPGA.

• The ‘Pad Report’ generated by the ‘Place-and-Route’ sub-process indicates the actual location of the I/O pins. It is always a good idea to check this report to make sure you have specified pin locations correctly!

To get information regarding the actual maximum clock speed which your design can run on, double click on the ‘Generate Post-Place & Route Static Timing’ sub-process of the ‘Implement Design’/'Place & Route' processes.


When it finishes, double click on ‘Text-Based Post-Place & Route Static Timing Report’ (one [+] click below the ‘Generate Post-Place & Route Static Timing’ process), and scroll to the end of this document where the maximum clock speed in MHz is indicated.

‘Implement Design’ process property settings

All property settings for the ‘Implement Design’ process can be kept at their default states indicated below. Some specific settings require some explana-tion as you may want to change them depending on your requirements. Note that default settings seem biased towards ‘quick and dirty’ implementation…

The property ‘Implementation User Constraints File’ may be left blank becau-se the filename d2vSCHEMA_1.ucf matches the name of the top level schematic written out in the Verilog code – this file will be used automatically. If more designs are placed in the same project directory, it is a good idea to rename this .ucf file to prevent it from being overwritten (IDaSS overwrites this file without a warning!). After renaming, it is necessary to specifically set this property to point to the renamed file.


In the 'Map Properties', ‘Pack I/O Registers/Latches Into IOBs’ is ‘off’ by default. If you want to use the IDaSS property setting ‘..DELAY’ with value ‘none’, you must set this property to ‘on’ here (the artificial input delay is inserted only when registers are actually synthesized within the Input/Output Blocks).

If you are running into timing problems and can not reach required clock speeds, the 'Place & Route effort Level (Overall)' is the first property to change to a higher setting. This may, however, drastically increase the time needed to convert an IDaSS design into an FPGA - this is the most time consuming step of the whole process…

This set of options controls the 'Post-Map Static Timing Report', which gives an indication of the speed of the synthesised design without taking actual placement and interconnection of design elements into account (in effect, the timing which could be reached with the generated logic if transferring signals across the FPGA did not take any time at all). Change the 'Report Type' into 'Verbose Report' if you want to see the slowest logic paths even if they do not violate timing constraints.


This set of options controls the 'Post-Place & Route Static Timing Report', which provides the maximum speed of the synthesised design, taking actual placement and interconnection of design elements into account. Change the 'Report Type' into 'Verbose Report' if you want to see the slowest logic paths even if they do not violate timing constraints.

The 'Simulation Model Properties' control the generation of Verilog simulation code files after translation (i.e. the design logic has been extracted but not yet mapped upon actual FPGA design elements), after mapping (design logic is mapped onto actual FPGA hardware but interconnection timing is not taken into account) and after place and route (a complete simulation of the design as it will run in the FPGA, taking signal delays into account).

4.1.4 The ‘Create Programming File’ process and its properties

The ‘Create Programming File’ process creates a .bit file which contains the ‘program’ to be downloaded into the actual FPGA device. There are several


methods to perform the actual downloading which require different settings for this process and also different settings for the ‘M0’, ‘M1’ and ‘M2’ input pins on the FPGA:

• use the JTAG test pins (which are available anyway) • use a special serial interface • use a serial PROM (does not require any extra hardware) • use an 8 bits parallel bus (easy interface to a microprocessor)

We have chosen here for the JTAG test pins as this leaves the maximum amount of input/output pins available to the user.

Before you can run the ‘Create Programming File’ process for the first time, you will have to set its properties to the settings indicated below (there is one setting which must be changed from its default setting). To do so, select the ‘Create Programming File’ process in the Process View window with a mouse click (the text becomes white-on-blue) and then choose ‘Process’ from the project navigator’s menu bar followed by ‘Properties…’. This will open a value entry form in which you can enter the settings. After setting the options correctly, you can click ‘OK’ to close the entry window and save the settings to disk.

When this is done, you can double click on the ‘Create Programming File’ process to generate the .bit file, which will be named after the top-level Verilog ‘module’ in the design (by default, d2vSCHEMA_1.bit). This operation may generate warnings, but should not result in errors. The actual download-ing of the .bit file in the FPGA to get your hardware running is described in the next section.

‘Create Programming File’ process property settings

Most of the property settings for the ‘Create Programming File’ process can be kept at their default states. Only the 'Start-Up Clock' setting is non-default and must be modified to allow configuration through the JTAG test pins!

The 'General options' can be kept at their default values.


The 'Configuration Options' can also be kept at their default values. Any value for the 'UserID Code' will do.

The ‘Start-Up Clock’ property must be set to 'JTAG Clock' as indicated to allow configuration downloading through the JTAG test pins.

These settings provide no 'reverse engineering' protection, but that should not be a problem in most cases. As we do not select to 'Create ReadBack Data Files' reading the configuration data back out of the FPGA (to check whether it downloaded and stofred correctly) is not possible.


4.2 Downloading the design into the FPGA

The last step to get a hardware design running is to to download the .bit file generated in the previous section into the actual FPGA device. As indicated in the previous section, there are several methods to do so. For each of these methods, separate programs are required (the WebPACK project navigator does not perform the downloading itself):

• For the JTAG interface, a special ‘programmer’ tool has been installed in the WebPACK system.

• For the serial interface, a tool called ‘BEDLOAD’ can be downloaded from www.burched.com.au .

• For generating files to program serial PROM’s (which in turn program the FPGA), a special ‘Generate PROM File’ process is present in the WebPACK system.

• The .bit file can be sent as-is through the parallel interface (the ‘Generate PROM File’ process may be used to re-format the .bit file for a parallel PROM programmer, if necessary).

We are now going to describe the steps to program the FPGA on the B3/5-SPARTAN2(E)+ prototyping boards using the JTAG interface. The first time this is done, some settings must be initialised – these can be saved to a file to save some time in later sessions.

1) Make sure the prototype board is properly connected to the printer port and its power supply is turned on.

2) Start the device programming tool. This can be done from the WebPACK project navigator’s Process Window by running the 'Configure Device (iMPACT)' process (if not visible, click on the [+] in front of 'Create Programming File'). Installation of WebPACK may have also created a separate icon (named ‘Device Programming’) on your desktop which you can double click. The actual file to run is named IMPACT.BAT (an MS-DOS batch file!).

Warning: It is NOT a good idea to start a second copy of the device programming tool if it is already running - nor is it necessary. You can leave a configured tool open as it will automatically re-read the latest version of the .bit file to program!

When starting the configuration program from the project navigator, it will start up with the correct configuration (JTAG chain checked out, .bit file 'attached' to FPGA), so you can proceed immediately.


When starting the configuration program separately, you are guided through a series of option windows - simply click 'next' buttons until you are allowed to select the .bit file to work with (would normally be called d2vschema_1.bit). After this, the system may complain that an incor-rect device is found (XCV200 instead of a XC2S200), simply click 'OK' as we can live with that.

3) Click on the FPGA device graphic to select it, then select from the window menu bar 'operations' followed by 'program'. In the ‘Program Options’ window which opens, UNcheck the 'Verify' checkbox to a blank box and click the 'OK' button.

This last action starts the actual programming operation. The bottom part of the device progamming tool's window shows the operations being performed. Once the FPGA device is programmed, it will start running automatically from the system reset state as defined in IDaSS.

For more convenience later, click on ‘File’/’save’ in the JTAG programming tool’s menu bar and choose a name for your JTAG chain configuration to be stored in the indicated directory. This allows you to simply reload this chain configuration (including the .bit file to use and all programming options) when you use the JTAG programmer again.

4.3 The next synthesis session

It is not necessary to create new projects for each IDaSS design you want to work on. The following steps clean up the mess from a previous synthesis session and allows a project directory to be re-used for a new design:

• Select the ‘d2vSCHEMA_1’ root element of the design in the project navigator’s Module View window, then press the [Delete] button on your keyboard. Click ‘OK’ to confirm the delete operation.

• Select ‘project’/’delete implementation data’ from the menu bar to clean up the project directory and prepare for a new synthesis session. Note that this also removes the d2vSCHEMA_1.bit file, so copy it under another name (or simply move it out of the project directory) if you want to retain it.

You can now generate a new .v Verilog file with accompanying ‘User Con-straints File’ in the project directory and synthesize them as follows:

• Select ‘project’/’add source’ and select the new Verilog source code file in the file selection window. This restores all processes in the Process View window again.

• If you’re in a hurry, double click on the ‘Create Programming File’ or 'Configure Device (iMPACT)' processes - the latter process will


automatically open the device programmer window (but should only be used if the device programmer is not already running).

Sit back and relax: this will run all the necessary operations automa-tically to generate a new .bit file for downloading.

• In the device programmer's window, click on the symbol representing the FPGA in the JTAG chain, then select ‘operations’/’program’/’OK’ to re-program the FPGA with the new design.

It doesn’t get any quicker than this, have fun!

IDaSS to Xilinx Spartan-II(E) FPGA conversion (appendices) page 58

A IDaSS template menu settings

The ‘template menu’ controls settings which change the overall functionality and appearance of the Verilog code generated by the spartan2e.aft ‘alien file generation’ template file, as well as some more detailed options. You access this menu from any schematic window’s menu bar entry ‘miscellaneous…’/ ’alien file template…’/’template menu…’.

We will show the entries in this menu with the possible settings in the order as they appear in the menu. A '�' marker is used to indicate the preferred setting to generate synthesizable code for the Xilinx WebPACK tools and a Spartan-IIE 300 device in 208 pin package as mounted on the B5-SPARTAN2E+ prototyping board. For the B3/5-SPARTAN2+ boards, select 'XC2S200-PQ208' for the ‘force pad numbers for’ option.

‘request speed optim.’:

‘NO’ does not place a target operating speed in the generated ‘User Constraints File’.

� ‘YES’ places a request to optimise for a specific target speed in the User Constraints file, but only when generating synthesizable Verilog with chip pad drivers for a specific Spartan-II(E) device which actually needs a system clock.

‘target speed (MHz)’:

If the previous setting is chosen ‘YES’, you can set the target speed anywhere from 10..1000 MHz (default 24 MHz). Don’t try ridiculous values!

� Choose a target speed setting which matches the actual clock speed on the prototyping board. 24 MHz is a good choice, as most designs should reach this without problems.

‘state numbering’:

� ‘N-hot’ numbers state controller states starting with an all-zeroes code, then 1-hot, 2-hot etcetera up to an all-ones code. Default as it uses the least amount of 1’s for a given number (not 2N) of states.

‘Gray’ numbers sequential states with Gray encoding. Is better than N-hot for a mostly sequential state progression using JK Flip-Flops.

‘Binary’ uses straight binary coding for states (just is more readable).


Note that Xilinx WebPACK by default tries to optimise state encoding, so this setting has no influence on the actual generated state machine. If you want to force the encoding chosen here, select the ‘synthesize’ process in the WebPACK project navigator’s ‘Process View’ window, then select from the menu bar ‘process’/‘properties’. In the window which opens, click on the tab ‘HDL options’ and select ‘user’ from the drop down menu of the ‘FSM encoding algorithm’ property. Click ‘OK’ to close the window and save the new settings.

'decode control with':

'if-else if' uses a chain of 'if'/'else if' statements which compare selected bits of the test result against constant values (use this one for Xilinx WebPACK version 3.2, as this version may generate non-functional logic with 'casex').

� 'casex' uses a 'casex' statement with don't care bits to decode test result values (use this when possible as it allows more complex tests to be done).

‘macrocells and pads’:

‘simulate’ includes simulatable versions of ROM/RAM macrocells and chip pads in the generated Verilog.

� ‘synthesize’ includes calls to real macrocells and pads in the Verilog code and may generate a ‘User Constraints File' called d2vSCHEMA_1.ucf to be copied to the Xilinx WebPACK project directory. If this file exists, it will be overwritten without warning!

‘FPGA bonding pads’:

‘ignore them’ does not generate any logic for input/output pin control.

‘assume ext.’ generates the necessary logic to control TS and bidirectional pins, assuming that buses which cross the outer perimeter of the filed out schematic are all headed towards device pins.

� ‘include here’ not only generates the control logic for the device pins but also instantiates (and optionally connects) them.

The following four entries are relevant only when generating a synthesizable Verilog file with FPGA bonding pads included:

‘bidir bus handling’:

‘simple’ uses a single channel for all bidir buses, with a TS 'feedback' buffer to get a bidir chip pad's input onto the internal channel.

� ‘split pad, TS mux’ splits the buses connected to a bidirectional pad into the original channel for carrying data into the FPGA and a


separate channel to connect (TS) output driver(s) to the pad for output.

‘force pad numbers for’:

‘NONE’ do not force pad numbering through the User Constraints File.

Other selections select a specific device and package for which pad numbering must be done. The list of currently supported devices (with number of data pins between braces - we assume configuration down-loading through the JTAG pins and INIT as well as clock pins unusable as I/O):

'XC2S15-VQ100’ (59) 'XC2S15-TQ144’ (85) 'XC2S15-CS144' (85) 'XC2S30-VQ100' (59) 'XC2S30-TQ144’ (91) 'XC2S30-CS144' (91) 'XC2S30-PQ208’ (131) 'XC2S50-TQ144' (91) 'XC2S50-PQ208' (139) 'XC2S50-FG256' (175) 'XC2S100-TQ144' (91) 'XC2S100-PQ208' (139) 'XC2S100-FG256' (175) 'XC2S100-FG456' (195) 'XC2S150-PQ208' (139) 'XC2S150-FG256' (175) 'XC2S150-FG456' (259) 'XC2S200-PQ208' (139, B3/5-SPARTAN2+ boards use this selection) 'XC2S200-FG256' (175) 'XC2S200-FG456' (283)

'XC2S50E-TQ144' (97) 'XC2S50E-PQ208' (141) 'XC2S50E-FT256' (177) 'XC2S100E-TQ144' (97) 'XC2S100E-PQ208' (141) 'XC2S100E-FT256' (177) 'XC2S100E-FG456' (197) 'XC2S150E-PQ208' (141) 'XC2S150E-FT256' (177) 'XC2S150E-FG456' (260, some Xilinx documents suggest only 258!) 'XC2S200E-PQ208' (141) 'XC2S200E-FT256' (177) 'XC2S200E-FG456' (284)

� 'XC2S300E-PQ208' (141) 'XC2S300E-FT256' (177) 'XC2S300E-FG456' (324)


‘force clock to pad’:

Selects which clock input on the Spartan-II(E) device will be used for the main clock input. The actual pad number only depends on the package selected in the previous entry (all devices in the same package have their clock inputs on the same pads). Valid selections are

‘GCK0’, � ‘GCK1’,

‘GCK2’ and ‘GCK3’.

‘data pad nr. offset’:

An offset value to shift automatically assigned data pins around the device periphery. If a system reset input is synthesized, this will by default be the first ‘data’ pin. If this offset is 0, the first pin used will be placed at the first available pin in the ‘Device Pinouts’ list in the Xilinx datasheets, working down through this list for other pads. An offset higher than 0 starts lower down the list (with wrap around).

If you assign I/O connections directly with IDaSS properties, this data pad offset is completely ignored as you either use the index numbers indicated in the tables in appendix B (with the ‘…LOC’ properties) or direct pin names (with the ‘…PAD’ properties).

The maximum value allowed is the number of data pins minus one. Complete lists of pin index numbers and corresponding actual device pin numbers are given in appendix B.

� Set the ‘data pad nr. offset’ value to the pin index of the pin which will be used to attach the system reset input to – automatic pin assignment will use pin index 0 (with the offset added) for the reset input if one is needed. You can always overrule the reset pin assignment with the ‘RESETLOC’ or ‘RESETPAD’ properties, if you want.

‘clock buffering’:

‘simple’ leads the external clock input directly to the clock buffer and clock signal distribution network on the FPGA device.

� ‘through DLL’ uses a Delay Locked Loop (DLL) to synchronise the internally distributed clock to the external clock input.

‘multiply by 2’ uses the CLK2X output of a DLL to get an internal clock frequency which is twice the input clock frequency (this option is implemented only when generating synthesizable Verilog). Note that this option should only be used when the external clock frequency is 25 MHz or higher.


‘synchronise reset’:

‘NO’ does not synchronise the system reset input pad.

‘1 level’ inserts a single Flip-Flop to synchronise the falling of the internal reset signal to the clock.

‘2 levels’ inserts two Flip-Flops to synchronise the falling of the internal reset signal - should be used to prevent metastability problems with an asynchronous reset input.'

� ‘use STARTUP’ uses the global reset buffer and synchroniser which is available in Spartan-II(E) FPGA’s. Only included when genera-ting synthesizable Verilog which includes chip pads.

‘system reset mode’:

� ‘async. (PCA)’ uses asynchronous set/reset inputs on Flip-Flops to force them into a defined system reset state, specifying this with ‘Procedural Continuous Assignments’ in Verilog.

‘async. (integrated)’ also uses asynchronous set/reset inputs on Flip-Flops, but integrates this within the clocked process in Verilog. In this mode, it is impossible to use a parametrised system reset value (Verilog cannot specify this correctly).

‘synchronous’ performs the system reset function with extra logic attached to the normal data input of Flip-Flops.

‘assume %0/synchr.’ assumes all Flip-Flops in a design power up in the %0 state, but uses extra logic attached to the data input in case the design specifies another reset state. Note that you should be careful with a reset input here – only the power-up state is defined, after that, the system reset input will not influence all Flip-Flops in the design!


B Pin numbers for Spartan-II(E) devices

The tables in this appendix show the pin names for the clock input pins and available data I/O pins on the Spartan-II(E) device/package combinations cur-rently supported by the spartan2e.aft converter. For other device/package combinations it is probably most convenient to let the converter perform automatic pin assignment and then modify the d2vSCHEMA_1.ucf file manu-ally to assign the correct pin names.

B.1 Global clock pins GCK0-GCK3

The global clock pin is normally chosen from the ‘template menu’ described in appendix A, but can be overruled with the ‘CLOCKPAD’ property. Unused clock input pins can be used as additional normal data inputs with the ‘PINPAD’ property.

Note that clock connections are common for all devices packaged in the same package type (the same goes for all non-user I/O connections like mode selection inputs and JTAG pins).

Clock connections for XC2S15/30-VQ100

GCK0 = 'P39' GCK1 = 'P36' GCK2 = 'P88' GCK3 = 'P91'

Clock connections for XC2S15/30/50/100-TQ144


Clock connections for XC2S15/30-CS144

GCK0 = 'K7' GCK1 = 'M7' GCK2 = 'A7' GCK3 = 'A6'

Clock connections for XC2S30/50/100/150/200-PQ208


Clock connections for XC2S50/100/150/200-FG256

GCK0 = 'N8' GCK1 = 'R8' GCK2 = 'C9' GCK3 = 'B8'

Clock connections for XC2S100/150/200-FG456

GCK0 = 'W12' GCK1 = 'Y11' GCK2 = 'A11' GCK3 = 'C11'


Clock connections for XC2S50E/100E-TQ144


Clock connections for XC2S50E/100E/150E/200E/300E-PQ208


Clock connections for XC2S50E/100E/150E/200E/300E-FT256

GCK0 = 'T9' GCK1 = 'T8' GCK2 = 'B8' GCK3 = 'C8'

Clock connections for XC2S100E/150E/200E/300E-FG456

GCK0 = 'AA12' GCK1 = 'AB12' GCK2 = 'A11' GCK3 = 'C11'

B.2 Data I/O pin tables

The data connection tables show the data I/O pin index numbers (which always start at 0) and the actual device pin names associated with them. ‘…PIN’ properties use the index numbers while ‘…PAD’ properties use the names. Automatic pin assignment starts at the ‘data pad nr. offset’ index chosen in the template menu, then sequentially assigns higher pin indexes with ‘wrap around’ back to index 0 after the highest pin index has been used.

Below each table, the INIT pin name is indicated as being skipped. Although Xilinx claims this pin is usable as normal data I/O, its use during programming of the FPGA (both as input and output) makes this very difficult.

Also, below each table the pin is indicated which is used as serial data input for programming via a serial data cable or from a serial PROM. This pin is difficult to use for normal data I/O when these modes of programming are used.

When two different devices (from the same series), packaged in the same package type, have a different number of data I/O pins, the smaller device always uses a subset of the data I/O pins of the larger device (all data I/O pins on the smaller device are also data I/O on the larger device).


59 data connections for XC2S15/30-VQ100

0: ‘P3' 10: ‘P16' 20: ‘P34' 30: ‘P55' 40: ‘P68' 50: ‘P83' 1: ‘P4' 11: ‘P17' 21: ‘P40' 31: ‘P56' 41: ‘P69' 51: ‘P84' 2: ‘P5' 12: ‘P18' 22: ‘P41' 32: ‘P57' 42: ‘P70' 52: ‘P86' 3: ‘P6' 13: ‘P19' 23: ‘P43' 33: ‘P58' 43: ‘P71' 53: ‘P87' 4: ‘P7' 14: ‘P20' 24: ‘P44' 34: ‘P59' 44: ‘P72' 54: ‘P93' 5: ‘P8' 15: ‘P21' 25: ‘P45' 35: ‘P60' 45: ‘P73'§ 55: ‘P95' 6: ‘P9' 16: ‘P22' 26: ‘P46' 36: ‘P62' 46: ‘P74' 56: ‘P96' 7: ‘P10' 17: ‘P30' 27: ‘P47' 37: ‘P65' 47: ‘P80' 57: ‘P97' 8: ‘P13' 18: ‘P31' 28: ‘P53' 38: ‘P66' 48: ‘P81' 58: ‘P98' 9: ‘P15' 19: ‘P32' 29: ‘P54' 39: ‘P67' 49: ‘P82' INIT pad ‘P52’ skipped here, not usable for normal I/O! §: pad ‘P73’ is not usable for normal I/O when basic serial download is used

85 data connections for XC2S15-TQ144

0: ‘P141' 15: ‘P121' 30: ‘P93' 45: ‘P63' 60: ‘P43' 75: ‘P19' 1: ‘P140' 16: ‘P120' 31: ‘P87' 46: ‘P62' 61: ‘P41' 76: ‘P13' 2: ‘P139' 17: ‘P118' 32: ‘P86' 47: ‘P60' 62: ‘P40' 77: ‘P12' 3: ‘P137' 18: ‘P117' 33: ‘P85' 48: ‘P59' 63: ‘P39'§ 78: ‘P11' 4: ‘P136' 19: ‘P115' 34: ‘P84' 49: ‘P58' 64: ‘P38' 79: ‘P10' 5: ‘P134' 20: ‘P114' 35: ‘P83' 50: ‘P57' 65: ‘P31' 80: ‘P7' 6: ‘P133' 21: ‘P113' 36: ‘P80' 51: ‘P56' 66: ‘P30' 81: ‘P6' 7: ‘P132' 22: ‘P112' 37: ‘P79' 52: ‘P54' 67: ‘P29' 82: ‘P5' 8: ‘P131' 23: ‘P103' 38: ‘P77' 53: ‘P51' 68: ‘P28' 83: ‘P4' 9: ‘P130' 24: ‘P102' 39: ‘P76' 54: ‘P50' 69: ‘P27' 84: ‘P3' 10: ‘P129' 25: ‘P100' 40: ‘P75' 55: ‘P49' 70: ‘P26' 11: ‘P126' 26: ‘P99' 41: ‘P74' 56: ‘P48' 71: ‘P23' 12: ‘P124' 27: ‘P96' 42: ‘P67' 57: ‘P47' 72: ‘P22' 13: ‘P123' 28: ‘P95' 43: ‘P66' 58: ‘P46' 73: ‘P21' 14: ‘P122' 29: ‘P94' 44: ‘P65' 59: ‘P44' 74: ‘P20' INIT pad ‘P68’ skipped here, not usable for normal I/O! §: pad ‘P39’ is not usable for normal I/O when basic serial download is used


91 data connections for XC2S30/50/100-TQ144

0: ‘P141' 16: ‘P121' 32: ‘P94' 48: ‘P65' 64: ‘P44' 80: ‘P20' 1: ‘P140' 17: ‘P120' 33: ‘P93' 49: ‘P64' 65: ‘P43' 81: ‘P19' 2: ‘P139' 18: ‘P118' 34: ‘P87' 50: ‘P63' 66: ‘P42' 82: ‘P13' 3: ‘P138' 19: ‘P117' 35: ‘P86' 51: ‘P62' 67: ‘P41' 83: ‘P12' 4: ‘P137' 20: ‘P116' 36: ‘P85' 52: ‘P60' 68: ‘P40' 84: ‘P11' 5: ‘P136' 21: ‘P115' 37: ‘P84' 53: ‘P59' 69: ‘P39'§ 85: ‘P10' 6: ‘P134' 22: ‘P114' 38: ‘P83' 54: ‘P58' 70: ‘P38' 86: ‘P7' 7: ‘P133' 23: ‘P113' 39: ‘P80' 55: ‘P57' 71: ‘P31' 87: ‘P6' 8: ‘P132' 24: ‘P112' 40: ‘P79' 56: ‘P56' 72: ‘P30' 88: ‘P5' 9: ‘P131' 25: ‘P103' 41: ‘P78' 57: ‘P54' 73: ‘P29' 89: ‘P4' 10: ‘P130' 26: ‘P102' 42: ‘P77' 58: ‘P51' 74: ‘P28' 90: ‘P3' 11: ‘P129' 27: ‘P101' 43: ‘P76' 59: ‘P50' 75: ‘P27' 12: ‘P126' 28: ‘P100' 44: ‘P75' 60: ‘P49' 76: ‘P26' 13: ‘P124' 29: ‘P99' 45: ‘P74' 61: ‘P48' 77: ‘P23' 14: ‘P123' 30: ‘P96' 46: ‘P67' 62: ‘P47' 78: ‘P22' 15: ‘P122' 31: ‘P95' 47: ‘P66' 63: ‘P46' 79: ‘P21' INIT pad ‘P68’ skipped here, not usable for normal I/O! §: pad ‘P39’ is not usable for normal I/O when basic serial download is used

85 data connections for XC2S15-CS144

0: ‘C2' 15: ‘H3' 30: ‘M6' 45: ‘J10' 60: ‘D13' 75: ‘B7' 1: ‘C1' 16: ‘H4' 31: ‘N8' 46: ‘J11' 61: ‘D11' 76: ‘C6' 2: ‘D4' 17: ‘J2' 32: ‘M8' 47: ‘J13' 62: ‘C13' 77: ‘D6' 3: ‘D2' 18: ‘J3' 33: ‘L8' 48: ‘H10' 63: ‘C12'§ 78: ‘A5' 4: ‘D1' 19: ‘K1' 34: ‘K8' 49: ‘H11' 64: ‘C11' 79: ‘B5' 5: ‘E3' 20: ‘K2' 35: ‘N9' 50: ‘H12' 65: ‘D10' 80: ‘A4' 6: ‘E2' 21: ‘K3' 36: ‘K9' 51: ‘H13' 66: ‘C10' 81: ‘B4' 7: ‘E1' 22: ‘L1' 37: ‘N10' 52: ‘G13' 67: ‘B10' 82: ‘C4' 8: ‘F4' 23: ‘K4' 38: ‘L10' 53: ‘F13' 68: ‘A10' 83: ‘A3' 9: ‘F3' 24: ‘L4' 39: ‘N11' 54: ‘F12' 69: ‘D9' 84: ‘B3' 10: ‘F2' 25: ‘N4' 40: ‘M11' 55: ‘F11' 70: ‘C9' 11: ‘G1' 26: ‘K5' 41: ‘L11' 56: ‘F10' 71: ‘D8' 12: ‘G4' 27: ‘N5' 42: ‘K10' 57: ‘E13' 72: ‘C8' 13: ‘H1' 28: ‘K6' 43: ‘K11' 58: ‘E12' 73: ‘B8' 14: ‘H2' 29: ‘L6' 44: ‘K12' 59: ‘E10' 74: ‘A8' INIT pad ‘L13’ skipped here, not usable for normal I/O! §: pad ‘C12’ is not usable for normal I/O when basic serial download is used


91 data connections for XC2S30-CS144

0: ‘C2' 16: ‘H3' 32: ‘L6' 48: ‘K12' 64: ‘E10' 80: ‘A8' 1: ‘C1' 17: ‘H4' 33: ‘M6' 49: ‘K13' 65: ‘D13' 81: ‘B7' 2: ‘D4' 18: ‘J2' 34: ‘N8' 50: ‘J10' 66: ‘D12' 82: ‘C6' 3: ‘D3' 19: ‘J3' 35: ‘M8' 51: ‘J11' 67: ‘D11' 83: ‘D6' 4: ‘D2' 20: ‘J4' 36: ‘L8' 52: ‘J13' 68: ‘C13' 84: ‘A5' 5: ‘D1' 21: ‘K1' 37: ‘K8' 53: ‘H10' 69: ‘C12'§ 85: ‘B5' 6: ‘E3' 22: ‘K2' 38: ‘N9' 54: ‘H11' 70: ‘C11' 86: ‘A4' 7: ‘E2' 23: ‘K3' 39: ‘K9' 55: ‘H12' 71: ‘D10' 87: ‘B4' 8: ‘E1' 24: ‘L1' 40: ‘N10' 56: ‘H13' 72: ‘C10' 88: ‘C4' 9: ‘F4' 25: ‘K4' 41: ‘M10' 57: ‘G13' 73: ‘B10' 89: ‘A3' 10: ‘F3' 26: ‘L4' 42: ‘L10' 58: ‘F13' 74: ‘A10' 90: ‘B3' 11: ‘F2' 27: ‘M4' 43: ‘N11' 59: ‘F12' 75: ‘D9' 12: ‘G1' 28: ‘N4' 44: ‘M11' 60: ‘F11' 76: ‘C9' 13: ‘G4' 29: ‘K5' 45: ‘L11' 61: ‘F10' 77: ‘D8' 14: ‘H1' 30: ‘N5' 46: ‘K10' 62: ‘E13' 78: ‘C8' 15: ‘H2' 31: ‘K6' 47: ‘K11' 63: ‘E12' 79: ‘B8' INIT pad ‘L13’ skipped here, not usable for normal I/O! §: pad ‘C12’ is not usable for normal I/O when basic serial download is used

131 data connections for XC2S30-PQ208

0: ‘P3' 22: ‘P34' 44: ‘P71' 66: ‘P109' 88: ‘P140' 110: ‘P175' 1: ‘P4' 23: ‘P35' 45: ‘P73' 67: ‘P110' 89: ‘P141' 111: ‘P176' 2: ‘P5' 24: ‘P36' 46: ‘P74' 68: ‘P111' 90: ‘P142' 112: ‘P178' 3: ‘P6' 25: ‘P37' 47: ‘P75' 69: ‘P113' 91: ‘P146' 113: ‘P179' 4: ‘P8' 26: ‘P41' 48: ‘P81' 70: ‘P114' 92: ‘P147' 114: ‘P180' 5: ‘P9' 27: ‘P42' 49: ‘P82' 71: ‘P115' 93: ‘P148' 115: ‘P181' 6: ‘P10' 28: ‘P43' 50: ‘P83' 72: ‘P119' 94: ‘P150' 116: ‘P187' 7: ‘P14' 29: ‘P45' 51: ‘P84' 73: ‘P120' 95: ‘P151' 117: ‘P188' 8: ‘P15' 30: ‘P46' 52: ‘P86' 74: ‘P121' 96: ‘P152' 118: ‘P189' 9: ‘P16' 31: ‘P47' 53: ‘P87' 75: ‘P122' 97: ‘P153'§ 119: ‘P191' 10: ‘P17' 32: ‘P48' 54: ‘P88' 76: ‘P123' 98: ‘P154' 120: ‘P192' 11: ‘P18' 33: ‘P49' 55: ‘P89' 77: ‘P125' 99: ‘P160' 121: ‘P193' 12: ‘P20' 34: ‘P57' 56: ‘P90' 78: ‘P126' 100: ‘P161' 122: ‘P194' 13: ‘P21' 35: ‘P58' 57: ‘P94' 79: ‘P127' 101: ‘P162' 123: ‘P195' 14: ‘P22' 36: ‘P59' 58: ‘P95' 80: ‘P129' 102: ‘P163' 124: ‘P199' 15: ‘P23' 37: ‘P61' 59: ‘P96' 81: ‘P132' 103: ‘P164' 125: ‘P200' 16: ‘P24' 38: ‘P62' 60: ‘P98' 82: ‘P133' 104: ‘P166' 126: ‘P201' 17: ‘P27' 39: ‘P63' 61: ‘P99' 83: ‘P134' 105: ‘P167' 127: ‘P203' 18: ‘P29' 40: ‘P67' 62: ‘P100' 84: ‘P135' 106: ‘P168' 128: ‘P204' 19: ‘P30' 41: ‘P68' 63: ‘P101' 85: ‘P136' 107: ‘P172' 129: ‘P205' 20: ‘P31' 42: ‘P69' 64: ‘P102' 86: ‘P138' 108: ‘P173' 130: ‘P206' 21: ‘P33' 43: ‘P70' 65: ‘P108' 87: ‘P139' 109: ‘P174' INIT pad ‘P107’ skipped here, not usable for normal I/O! §: pad ‘P153’ is not usable for normal I/O when basic serial download is used


139 data connections for XC2S50/100/150/200-PQ208

0: ‘P3' 24: ‘P35' 48: ‘P73' 72: ‘P111' 96: ‘P146' 120: ‘P179' 1: ‘P4' 25: ‘P36' 49: ‘P74' 73: ‘P112' 97: ‘P147' 121: ‘P180' 2: ‘P5' 26: ‘P37' 50: ‘P75' 74: ‘P113' 98: ‘P148' 122: ‘P181' 3: ‘P6' 27: ‘P41' 51: ‘P81' 75: ‘P114' 99: ‘P149' 123: ‘P187' 4: ‘P7' 28: ‘P42' 52: ‘P82' 76: ‘P115' 100: ‘P150' 124: ‘P188' 5: ‘P8' 29: ‘P43' 53: ‘P83' 77: ‘P119' 101: ‘P151' 125: ‘P189' 6: ‘P9' 30: ‘P44' 54: ‘P84' 78: ‘P120' 102: ‘P152' 126: ‘P191' 7: ‘P10' 31: ‘P45' 55: ‘P86' 79: ‘P121' 103: ‘P153'§ 127: ‘P192' 8: ‘P14' 32: ‘P46' 56: ‘P87' 80: ‘P122' 104: ‘P154' 128: ‘P193' 9: ‘P15' 33: ‘P47' 57: ‘P88' 81: ‘P123' 105: ‘P160' 129: ‘P194' 10: ‘P16' 34: ‘P48' 58: ‘P89' 82: ‘P125' 106: ‘P161' 130: ‘P195' 11: ‘P17' 35: ‘P49' 59: ‘P90' 83: ‘P126' 107: ‘P162' 131: ‘P199' 12: ‘P18' 36: ‘P57' 60: ‘P94' 84: ‘P127' 108: ‘P163' 132: ‘P200' 13: ‘P20' 37: ‘P58' 61: ‘P95' 85: ‘P129' 109: ‘P164' 133: ‘P201' 14: ‘P21' 38: ‘P59' 62: ‘P96' 86: ‘P132' 110: ‘P165' 134: ‘P202' 15: ‘P22' 39: ‘P60' 63: ‘P97' 87: ‘P133' 111: ‘P166' 135: ‘P203' 16: ‘P23' 40: ‘P61' 64: ‘P98' 88: ‘P134' 112: ‘P167' 136: ‘P204' 17: ‘P24' 41: ‘P62' 65: ‘P99' 89: ‘P135' 113: ‘P168' 137: ‘P205' 18: ‘P27' 42: ‘P63' 66: ‘P100' 90: ‘P136' 114: ‘P172' 138: ‘P206' 19: ‘P29' 43: ‘P67' 67: ‘P101' 91: ‘P138' 115: ‘P173' 20: ‘P30' 44: ‘P68' 68: ‘P102' 92: ‘P139' 116: ‘P174' 21: ‘P31' 45: ‘P69' 69: ‘P108' 93: ‘P140' 117: ‘P175' 22: ‘P33' 46: ‘P70' 70: ‘P109' 94: ‘P141' 118: ‘P176' 23: ‘P34' 47: ‘P71' 71: ‘P110' 95: ‘P142' 119: ‘P178' INIT pad ‘P107’ skipped here, not usable for normal I/O! §: pad ‘P153’ is not usable for normal I/O when basic serial download is used


175 data connections for XC2S50/100/150/200-FG256

0: ‘C2' 30: ‘K1' 60: ‘P7' 90: ‘R16' 120: ‘F15' 150: ‘B9' 1: ‘A2' 31: ‘K3' 61: ‘P8' 91: ‘M14' 121: ‘E16' 151: ‘E10' 2: ‘B1' 32: ‘L1' 62: ‘R7' 92: ‘L14' 122: ‘F14' 152: ‘A9' 3: ‘E3' 33: ‘L2' 63: ‘T7' 93: ‘M15' 123: ‘D16' 153: ‘D9' 4: ‘D2' 34: ‘K4' 64: ‘T8' 94: ‘L12' 124: ‘F12' 154: ‘A8' 5: ‘C1' 35: ‘M1' 65: ‘N9' 95: ‘P16' 125: ‘E15' 155: ‘A7' 6: ‘F3' 36: ‘L4' 66: ‘R9' 96: ‘L13' 126: ‘F13' 156: ‘D8' 7: ‘E2' 37: ‘M2' 67: ‘N10' 97: ‘N16' 127: ‘E14' 157: ‘A6' 8: ‘E4' 38: ‘L3' 68: ‘T9' 98: ‘M16' 128: ‘C16' 158: ‘B7' 9: ‘D1' 39: ‘N1' 69: ‘P9' 99: ‘K14' 129: ‘E13' 159: ‘C8' 10: ‘E1' 40: ‘P1' 70: ‘M10' 100: ‘L16' 130: ‘B16' 160: ‘D7' 11: ‘F2' 41: ‘L5' 71: ‘R10' 101: ‘K13' 131: ‘D14'§ 161: ‘E7' 12: ‘G3' 42: ‘N2' 72: ‘P10' 102: ‘L15' 132: ‘C15' 162: ‘C7' 13: ‘F1' 43: ‘M4' 73: ‘T10' 103: ‘K12' 133: ‘B13' 163: ‘B6' 14: ‘F4' 44: ‘R1' 74: ‘R11' 104: ‘K16' 134: ‘C13' 164: ‘A5' 15: ‘F5' 45: ‘M3' 75: ‘M11' 105: ‘J16' 135: ‘C12' 165: ‘C6' 16: ‘G2' 46: ‘N5' 76: ‘T11' 106: ‘J14' 136: ‘A14' 166: ‘B5' 17: ‘H3' 47: ‘T2' 77: ‘N11' 107: ‘K15' 137: ‘D12' 167: ‘D6' 18: ‘G4' 48: ‘P5' 78: ‘R12' 108: ‘J15' 138: ‘B12' 168: ‘A4' 19: ‘H2' 49: ‘T3' 79: ‘P11' 109: ‘H16' 139: ‘C11' 169: ‘B4' 20: ‘G5' 50: ‘T4' 80: ‘T12' 110: ‘H14' 140: ‘A13' 170: ‘E6' 21: ‘H4' 51: ‘M6' 81: ‘T13' 111: ‘H15' 141: ‘D11' 171: ‘D5' 22: ‘G1' 52: ‘T5' 82: ‘N12' 112: ‘J13' 142: ‘A12' 172: ‘A3' 23: ‘J2' 53: ‘N6' 83: ‘R13' 113: ‘G16' 143: ‘E11' 173: ‘C5' 24: ‘H1' 54: ‘R5' 84: ‘P12' 114: ‘H13' 144: ‘B11' 174: ‘B3' 25: ‘J4' 55: ‘P6' 85: ‘P13' 115: ‘G14' 145: ‘A11' 26: ‘J1' 56: ‘R6' 86: ‘T14' 116: ‘G15' 146: ‘C10' 27: ‘J3' 57: ‘M7' 87: ‘N14' 117: ‘G12' 147: ‘B10' 28: ‘K5' 58: ‘N7' 88: ‘T15' 118: ‘F16' 148: ‘D10' 29: ‘K2' 59: ‘T6' 89: ‘M13' 119: ‘G13' 149: ‘A10' INIT pad ‘N15’ skipped here, not usable for normal I/O! §: pad ‘D14’ is not usable for normal I/O when basic serial download is used


195 data connections for XC2S100-FG456

0: ‘B1' 33: ‘P4' 66: ‘W10' 99: ‘U20' 132: ‘H20' 165: ‘D13' 1: ‘F5' 34: ‘P3' 67: ‘AB10' 100: ‘U19' 133: ‘H22' 166: ‘C13' 2: ‘D2' 35: ‘R2' 68: ‘Y10' 101: ‘T18' 134: ‘H18' 167: ‘B13' 3: ‘E3' 36: ‘T1' 69: ‘V11' 102: ‘W22' 135: ‘G21' 168: ‘E12' 4: ‘G5' 37: ‘R4' 70: ‘W11' 103: ‘U21' 136: ‘G18' 169: ‘B12' 5: ‘F3' 38: ‘T2' 71: ‘AB11' 104: ‘T20' 137: ‘G20' 170: ‘D12' 6: ‘E2' 39: ‘U1' 72: ‘U12' 105: ‘T21' 138: ‘F19' 171: ‘D11' 7: ‘E1' 40: ‘R5' 73: ‘Y12' 106: ‘R18' 139: ‘F21' 172: ‘A10' 8: ‘H5' 41: ‘U2' 74: ‘AA12' 107: ‘U22' 140: ‘F20' 173: ‘B10' 9: ‘F2' 42: ‘T3' 75: ‘AB13' 108: ‘R19' 141: ‘F18' 174: ‘C10' 10: ‘F1' 43: ‘T4' 76: ‘AA13' 109: ‘T22' 142: ‘E21' 175: ‘A9' 11: ‘H4' 44: ‘W1' 77: ‘Y13' 110: ‘R21' 143: ‘D22' 176: ‘B9' 12: ‘G1' 45: ‘U4' 78: ‘V13' 111: ‘P18' 144: ‘E20' 177: ‘E10' 13: ‘H3' 46: ‘Y1' 79: ‘AA14' 112: ‘P20' 145: ‘D20'§ 178: ‘A8' 14: ‘H2' 47: ‘W2' 80: ‘V14' 113: ‘P21' 146: ‘C21' 179: ‘D9' 15: ‘J5' 48: ‘Y2' 81: ‘AB15' 114: ‘N18' 147: ‘C19' 180: ‘E9' 16: ‘J2' 49: ‘W3' 82: ‘AA15' 115: ‘N20' 148: ‘A20' 181: ‘A7' 17: ‘K5' 50: ‘V7' 83: ‘Y15' 116: ‘N21' 149: ‘D17' 182: ‘B7' 18: ‘K1' 51: ‘Y6' 84: ‘AB16' 117: ‘N22' 150: ‘A19' 183: ‘E8' 19: ‘K3' 52: ‘AA4' 85: ‘AB17' 118: ‘M19' 151: ‘B18' 184: ‘D8' 20: ‘K4' 53: ‘W6' 86: ‘V15' 119: ‘M20' 152: ‘C17' 185: ‘C7' 21: ‘L6' 54: ‘Y7' 87: ‘Y16' 120: ‘M22' 153: ‘D16' 186: ‘D7' 22: ‘L1' 55: ‘AA5' 88: ‘AB18' 121: ‘L20' 154: ‘A18' 187: ‘D6' 23: ‘L4' 56: ‘AB5' 89: ‘AB19' 122: ‘L17' 155: ‘B17' 188: ‘C6' 24: ‘L3' 57: ‘AB6' 90: ‘Y17' 123: ‘L21' 156: ‘D15' 189: ‘B5' 25: ‘M1' 58: ‘AA7' 91: ‘V16' 124: ‘L22' 157: ‘C16' 190: ‘E7' 26: ‘M3' 59: ‘W7' 92: ‘W17' 125: ‘K20' 158: ‘D14' 191: ‘E6' 27: ‘M4' 60: ‘W8' 93: ‘AB20' 126: ‘K21' 159: ‘E14' 192: ‘B4' 28: ‘M5' 61: ‘Y8' 94: ‘AA19' 127: ‘K22' 160: ‘A16' 193: ‘A3' 29: ‘N2' 62: ‘AA8' 95: ‘AA20' 128: ‘J21' 161: ‘C15' 194: ‘C5' 30: ‘N3' 63: ‘V9' 96: ‘W18' 129: ‘J18' 162: ‘B15' 31: ‘N4' 64: ‘AB9' 97: ‘Y21' 130: ‘J22' 163: ‘F12' 32: ‘P2' 65: ‘Y9' 98: ‘W21' 131: ‘H19' 164: ‘C14' INIT pad ‘V19’ skipped here, not usable for normal I/O! §: pad ‘D20’ is not usable for normal I/O when basic serial download is used



0: ‘B1' 44: ‘R1' 88: ‘V10' 132: ‘W21' 176: ‘H22' 220: ‘D13' 1: ‘E4' 45: ‘P3' 89: ‘W10' 133: ‘U20' 177: ‘H18' 221: ‘C13' 2: ‘C1' 46: ‘R2' 90: ‘AB10' 134: ‘U19' 178: ‘G21' 222: ‘B13' 3: ‘F5' 47: ‘T1' 91: ‘Y10' 135: ‘V21' 179: ‘G18' 223: ‘E12' 4: ‘D2' 48: ‘R4' 92: ‘V11' 136: ‘T18' 180: ‘G20' 224: ‘B12' 5: ‘E3' 49: ‘T2' 93: ‘W11' 137: ‘W22' 181: ‘G19' 225: ‘D12' 6: ‘F4' 50: ‘U1' 94: ‘AB11' 138: ‘U21' 182: ‘F22' 226: ‘C12' 7: ‘G5' 51: ‘R5' 95: ‘U11' 139: ‘T20' 183: ‘F19' 227: ‘D11' 8: ‘F3' 52: ‘V1' 96: ‘U12' 140: ‘T19' 184: ‘F21' 228: ‘E11' 9: ‘E2' 53: ‘T5' 97: ‘V12' 141: ‘V22' 185: ‘F20' 229: ‘A10' 10: ‘E1' 54: ‘U2' 98: ‘Y12' 142: ‘T21' 186: ‘F18' 230: ‘B10' 11: ‘G4' 55: ‘T3' 99: ‘AA12' 143: ‘R18' 187: ‘E22' 231: ‘C10' 12: ‘G3' 56: ‘T4' 100: ‘AB13' 144: ‘U22' 188: ‘E21' 232: ‘A9' 13: ‘H5' 57: ‘W1' 101: ‘AA13' 145: ‘R19' 189: ‘D22' 233: ‘B9' 14: ‘F2' 58: ‘V2' 102: ‘Y13' 146: ‘T22' 190: ‘E20' 234: ‘E10' 15: ‘F1' 59: ‘U4' 103: ‘V13' 147: ‘R21' 191: ‘D21' 235: ‘D10' 16: ‘H4' 60: ‘Y1' 104: ‘W14' 148: ‘P18' 192: ‘C22' 236: ‘A8' 17: ‘G1' 61: ‘W2' 105: ‘AA14' 149: ‘P19' 193: ‘D20'§ 237: ‘D9' 18: ‘H3' 62: ‘V3' 106: ‘V14' 150: ‘P20' 194: ‘C21' 238: ‘B8' 19: ‘H2' 63: ‘V4' 107: ‘Y14' 151: ‘P21' 195: ‘C19' 239: ‘E9' 20: ‘H1' 64: ‘Y2' 108: ‘AB15' 152: ‘N19' 196: ‘A20' 240: ‘A7' 21: ‘J5' 65: ‘W3' 109: ‘AA15' 153: ‘N18' 197: ‘B19' 241: ‘B7' 22: ‘J2' 66: ‘W5' 110: ‘Y15' 154: ‘N20' 198: ‘C18' 242: ‘E8' 23: ‘J3' 67: ‘AB3' 111: ‘AB16' 155: ‘N21' 199: ‘D17' 243: ‘D8' 24: ‘K5' 68: ‘V7' 112: ‘AB17' 156: ‘N22' 200: ‘A19' 244: ‘C7' 25: ‘K1' 69: ‘Y6' 113: ‘V15' 157: ‘M19' 201: ‘B18' 245: ‘D7' 26: ‘K3' 70: ‘AA4' 114: ‘Y16' 158: ‘M20' 202: ‘E16' 246: ‘B6' 27: ‘K4' 71: ‘AB4' 115: ‘AA17' 159: ‘M18' 203: ‘C17' 247: ‘A5' 28: ‘L6' 72: ‘W6' 116: ‘W16' 160: ‘M22' 204: ‘D16' 248: ‘D6' 29: ‘L1' 73: ‘Y7' 117: ‘AB18' 161: ‘L20' 205: ‘A18' 249: ‘C6' 30: ‘L5' 74: ‘AA5' 118: ‘AB19' 162: ‘L17' 206: ‘B17' 250: ‘B5' 31: ‘L4' 75: ‘AB5' 119: ‘Y17' 163: ‘L18' 207: ‘E15' 251: ‘E7' 32: ‘L3' 76: ‘V8' 120: ‘V16' 164: ‘L21' 208: ‘A17' 252: ‘A4' 33: ‘M1' 77: ‘AA6' 121: ‘AA18' 165: ‘L22' 209: ‘D15' 253: ‘E6' 34: ‘M6' 78: ‘AB6' 122: ‘W17' 166: ‘K20' 210: ‘C16' 254: ‘B4' 35: ‘M3' 79: ‘AA7' 123: ‘AB20' 167: ‘K21' 211: ‘D14' 255: ‘A3' 36: ‘M4' 80: ‘W7' 124: ‘AA19' 168: ‘K22' 212: ‘E14' 256: ‘B3' 37: ‘M5' 81: ‘W8' 125: ‘V17' 169: ‘J21' 213: ‘A16' 257: ‘D5' 38: ‘N2' 82: ‘Y8' 126: ‘Y18' 170: ‘J20' 214: ‘C15' 258: ‘C5' 39: ‘N3' 83: ‘AA8' 127: ‘AA20' 171: ‘J18' 215: ‘B15' 40: ‘N4' 84: ‘V9' 128: ‘W18' 172: ‘J22' 216: ‘A15' 41: ‘N5' 85: ‘W9' 129: ‘Y21' 173: ‘J19' 217: ‘F12' 42: ‘P2' 86: ‘AB9' 130: ‘V20' 174: ‘H19' 218: ‘C14' 43: ‘P4' 87: ‘Y9' 131: ‘AA22' 175: ‘H20' 219: ‘B14' INIT pad ‘V19’ skipped here, not usable for normal I/O! §: pad ‘D20’ is not usable for normal I/O when basic serial download is used



0: ‘B1' 48: ‘P4' 96: ‘AA9' 144: ‘W21' 192: ‘H19' 240: ‘D13' 1: ‘E4' 49: ‘R1' 97: ‘W10' 145: ‘U20' 193: ‘H20' 241: ‘C13' 2: ‘C1' 50: ‘P5' 98: ‘AB10' 146: ‘U19' 194: ‘H22' 242: ‘B13' 3: ‘F5' 51: ‘P3' 99: ‘Y10' 147: ‘V21' 195: ‘H18' 243: ‘E12' 4: ‘D2' 52: ‘R2' 100: ‘V11' 148: ‘T18' 196: ‘G21' 244: ‘A13' 5: ‘E3' 53: ‘T1' 101: ‘AA10' 149: ‘W22' 197: ‘G18' 245: ‘B12' 6: ‘F4' 54: ‘R4' 102: ‘W11' 150: ‘U21' 198: ‘G20' 246: ‘D12' 7: ‘G5' 55: ‘T2' 103: ‘AB11' 151: ‘T20' 199: ‘G19' 247: ‘C12' 8: ‘F3' 56: ‘U1' 104: ‘U11' 152: ‘T19' 200: ‘F22' 248: ‘D11' 9: ‘E2' 57: ‘R5' 105: ‘U12' 153: ‘V22' 201: ‘F19' 249: ‘E11' 10: ‘E1' 58: ‘V1' 106: ‘V12' 154: ‘T21' 202: ‘F21' 250: ‘A10' 11: ‘G4' 59: ‘T5' 107: ‘Y12' 155: ‘R18' 203: ‘F20' 251: ‘B10' 12: ‘G3' 60: ‘U2' 108: ‘AA12' 156: ‘U22' 204: ‘F18' 252: ‘F11' 13: ‘H5' 61: ‘T3' 109: ‘W13' 157: ‘R19' 205: ‘E22' 253: ‘C10' 14: ‘F2' 62: ‘T4' 110: ‘AB13' 158: ‘T22' 206: ‘E21' 254: ‘A9' 15: ‘F1' 63: ‘W1' 111: ‘AA13' 159: ‘R21' 207: ‘D22' 255: ‘B9' 16: ‘H4' 64: ‘V2' 112: ‘Y13' 160: ‘P18' 208: ‘E20' 256: ‘E10' 17: ‘G1' 65: ‘U4' 113: ‘V13' 161: ‘R22' 209: ‘D21' 257: ‘C9' 18: ‘H3' 66: ‘Y1' 114: ‘AB14' 162: ‘P19' 210: ‘C22' 258: ‘D10' 19: ‘H2' 67: ‘W2' 115: ‘W14' 163: ‘P20' 211: ‘D20'§ 259: ‘A8' 20: ‘J4' 68: ‘V3' 116: ‘AA14' 164: ‘P21' 212: ‘C21' 260: ‘D9' 21: ‘H1' 69: ‘V4' 117: ‘V14' 165: ‘N19' 213: ‘C19' 261: ‘B8' 22: ‘J5' 70: ‘Y2' 118: ‘Y14' 166: ‘P22' 214: ‘A20' 262: ‘C8' 23: ‘J2' 71: ‘W3' 119: ‘W15' 167: ‘N18' 215: ‘B19' 263: ‘E9' 24: ‘J3' 72: ‘W5' 120: ‘AB15' 168: ‘N20' 216: ‘C18' 264: ‘A7' 25: ‘J1' 73: ‘AB3' 121: ‘AA15' 169: ‘N21' 217: ‘D17' 265: ‘B7' 26: ‘K5' 74: ‘V7' 122: ‘Y15' 170: ‘N22' 218: ‘A19' 266: ‘E8' 27: ‘K1' 75: ‘Y6' 123: ‘AB16' 171: ‘M17' 219: ‘B18' 267: ‘D8' 28: ‘K3' 76: ‘AA4' 124: ‘AB17' 172: ‘M19' 220: ‘E16' 268: ‘C7' 29: ‘K4' 77: ‘AB4' 125: ‘V15' 173: ‘M20' 221: ‘C17' 269: ‘D7' 30: ‘K2' 78: ‘W6' 126: ‘Y16' 174: ‘M18' 222: ‘D16' 270: ‘B6' 31: ‘L6' 79: ‘Y7' 127: ‘AA17' 175: ‘M22' 223: ‘A18' 271: ‘A5' 32: ‘L1' 80: ‘AA5' 128: ‘W16' 176: ‘L20' 224: ‘B17' 272: ‘D6' 33: ‘L5' 81: ‘AB5' 129: ‘AB18' 177: ‘L17' 225: ‘E15' 273: ‘C6' 34: ‘L4' 82: ‘V8' 130: ‘AB19' 178: ‘L18' 226: ‘A17' 274: ‘B5' 35: ‘L3' 83: ‘AA6' 131: ‘Y17' 179: ‘L21' 227: ‘D15' 275: ‘E7' 36: ‘M1' 84: ‘AB6' 132: ‘V16' 180: ‘L22' 228: ‘C16' 276: ‘A4' 37: ‘M6' 85: ‘AA7' 133: ‘AA18' 181: ‘K19' 229: ‘D14' 277: ‘E6' 38: ‘M3' 86: ‘W7' 134: ‘W17' 182: ‘K20' 230: ‘E14' 278: ‘B4' 39: ‘M4' 87: ‘W8' 135: ‘AB20' 183: ‘K21' 231: ‘A16' 279: ‘A3' 40: ‘N1' 88: ‘Y8' 136: ‘AA19' 184: ‘K22' 232: ‘C15' 280: ‘B3' 41: ‘M5' 89: ‘AA8' 137: ‘V17' 185: ‘J21' 233: ‘B15' 281: ‘D5' 42: ‘N2' 90: ‘V9' 138: ‘Y18' 186: ‘K18' 234: ‘E13' 282: ‘C5' 43: ‘N3' 91: ‘AB8' 139: ‘AA20' 187: ‘J20' 235: ‘A15' 44: ‘N4' 92: ‘W9' 140: ‘W18' 188: ‘J18' 236: ‘F12' 45: ‘P1' 93: ‘AB9' 141: ‘Y21' 189: ‘J22' 237: ‘C14' 46: ‘N5' 94: ‘Y9' 142: ‘V20' 190: ‘J19' 238: ‘B14' 47: ‘P2' 95: ‘V10' 143: ‘AA22' 191: ‘H21' 239: ‘A14' INIT pad ‘V19’ skipped here, not usable for normal I/O! §: pad ‘D20’ is not usable for normal I/O when basic serial download is used


97 data connections for XC2S50E/100E-TQ144

0: ‘P3' 17: ‘P24' 34: ‘P49' 51: ‘P78' 68: ‘P100' 85: ‘P124' 1: ‘P4' 18: ‘P26' 35: ‘P50' 52: ‘P79' 69: ‘P101' 86: ‘P125' 2: ‘P5' 19: ‘P27' 36: ‘P56' 53: ‘P80' 70: ‘P102' 87: ‘P131' 3: ‘P6' 20: ‘P28' 37: ‘P57' 54: ‘P82' 71: ‘P103' 88: ‘P132' 4: ‘P7' 21: ‘P29' 38: ‘P58' 55: ‘P83' 72: ‘P104' 89: ‘P133' 5: ‘P8' 22: ‘P30' 39: ‘P59' 56: ‘P84' 73: ‘P105'§ 90: ‘P134' 6: ‘P10' 23: ‘P31' 40: ‘P60' 57: ‘P85' 74: ‘P106' 91: ‘P137' 7: ‘P11' 24: ‘P32' 41: ‘P63' 58: ‘P86' 75: ‘P112' 92: ‘P138' 8: ‘P12' 25: ‘P38' 42: ‘P64' 59: ‘P87' 76: ‘P113' 93: ‘P139' 9: ‘P13' 26: ‘P39' 43: ‘P65' 60: ‘P89' 77: ‘P114' 94: ‘P140' 10: ‘P14' 27: ‘P40' 44: ‘P66' 61: ‘P92' 78: ‘P115' 95: ‘P141' 11: ‘P15' 28: ‘P41' 45: ‘P67' 62: ‘P93' 79: ‘P116' 96: ‘P142' 12: ‘P18' 29: ‘P42' 46: ‘P68' 63: ‘P94' 80: ‘P117' 13: ‘P20' 30: ‘P43' 47: ‘P69' 64: ‘P95' 81: ‘P118' 14: ‘P21' 31: ‘P44' 48: ‘P75' 65: ‘P96' 82: ‘P121' 15: ‘P22' 32: ‘P47' 49: ‘P76' 66: ‘P97' 83: ‘P122' 16: ‘P23' 33: ‘P48' 50: ‘P77' 67: ‘P98' 84: ‘P123' INIT pad ‘P74’ skipped here, not usable for normal I/O! §: pad ‘P105’ is not usable for normal I/O when basic serial download is used

141 data connections for XC2S50E/100E/150E/200E/300E-PQ208

0: ‘P3' 24: ‘P35' 48: ‘P70' 72: ‘P109' 96: ‘P141' 120: ‘P176' 1: ‘P4' 25: ‘P36' 49: ‘P71' 73: ‘P110' 97: ‘P145' 121: ‘P178' 2: ‘P5' 26: ‘P40' 50: ‘P73' 74: ‘P111' 98: ‘P146' 122: ‘P179' 3: ‘P6' 27: ‘P41' 51: ‘P74' 75: ‘P112' 99: ‘P147' 123: ‘P180' 4: ‘P7' 28: ‘P42' 52: ‘P75' 76: ‘P113' 100: ‘P148' 124: ‘P181' 5: ‘P8' 29: ‘P43' 53: ‘P81' 77: ‘P114' 101: ‘P149' 125: ‘P187' 6: ‘P9' 30: ‘P44' 54: ‘P82' 78: ‘P115' 102: ‘P150' 126: ‘P188' 7: ‘P10' 31: ‘P45' 55: ‘P83' 79: ‘P116' 103: ‘P151' 127: ‘P189' 8: ‘P11' 32: ‘P46' 56: ‘P84' 80: ‘P120' 104: ‘P152' 128: ‘P191' 9: ‘P15' 33: ‘P47' 57: ‘P86' 81: ‘P121' 105: ‘P153'§ 129: ‘P192' 10: ‘P16' 34: ‘P48' 58: ‘P87' 82: ‘P122' 106: ‘P154' 130: ‘P193' 11: ‘P17' 35: ‘P49' 59: ‘P88' 83: ‘P123' 107: ‘P160' 131: ‘P194' 12: ‘P18' 36: ‘P55' 60: ‘P89' 84: ‘P125' 108: ‘P161' 132: ‘P198' 13: ‘P20' 37: ‘P56' 61: ‘P93' 85: ‘P126' 109: ‘P162' 133: ‘P199' 14: ‘P21' 38: ‘P57' 62: ‘P94' 86: ‘P127' 110: ‘P163' 134: ‘P200' 15: ‘P22' 39: ‘P58' 63: ‘P95' 87: ‘P129' 111: ‘P164' 135: ‘P201' 16: ‘P23' 40: ‘P59' 64: ‘P96' 88: ‘P132' 112: ‘P165' 136: ‘P202' 17: ‘P24' 41: ‘P60' 65: ‘P97' 89: ‘P133' 113: ‘P166' 137: ‘P203' 18: ‘P27' 42: ‘P61' 66: ‘P98' 90: ‘P134' 114: ‘P167' 138: ‘P204' 19: ‘P29' 43: ‘P62' 67: ‘P99' 91: ‘P135' 115: ‘P168' 139: ‘P205' 20: ‘P30' 44: ‘P63' 68: ‘P100' 92: ‘P136' 116: ‘P169' 140: ‘P206' 21: ‘P31' 45: ‘P64' 69: ‘P101' 93: ‘P138' 117: ‘P173' 22: ‘P33' 46: ‘P68' 70: ‘P102' 94: ‘P139' 118: ‘P174' 23: ‘P34' 47: ‘P69' 71: ‘P108' 95: ‘P140' 119: ‘P175' INIT pad ‘P107’ skipped here, not usable for normal I/O! §: pad ‘P153’ is not usable for normal I/O when basic serial download is used


177 data connections for XC2S50E/100E/150E/200E/300E-FT256

0: ‘D3' 30: ‘L1' 60: ‘P7' 90: ‘N15' 120: ‘E16' 150: ‘B10' 1: ‘C2' 31: ‘L2' 61: ‘R7' 91: ‘N16' 121: ‘G13' 151: ‘A10' 2: ‘C1' 32: ‘K4' 62: ‘T7' 92: ‘N14' 122: ‘F14' 152: ‘D9' 3: ‘D2' 33: ‘K5' 63: ‘M7' 93: ‘M14' 123: ‘E15' 153: ‘C9' 4: ‘D1' 34: ‘L3' 64: ‘N8' 94: ‘M15' 124: ‘D16' 154: ‘B9' 5: ‘E3' 35: ‘M2' 65: ‘P8' 95: ‘M16' 125: ‘F13' 155: ‘A9' 6: ‘E4' 36: ‘M1' 66: ‘R8' 96: ‘M13' 126: ‘E14' 156: ‘A8' 7: ‘E2' 37: ‘N1' 67: ‘R9' 97: ‘L14' 127: ‘D15' 157: ‘D8' 8: ‘E1' 38: ‘L4' 68: ‘P9' 98: ‘L15' 128: ‘C16' 158: ‘A7' 9: ‘F4' 39: ‘L5' 69: ‘N9' 99: ‘L16' 129: ‘G12' 159: ‘E7' 10: ‘F3' 40: ‘M3' 70: ‘T10' 100: ‘L13' 130: ‘F12' 160: ‘D7' 11: ‘F2' 41: ‘M4' 71: ‘R10' 101: ‘K14' 131: ‘E13' 161: ‘C7' 12: ‘F1' 42: ‘N2' 72: ‘P10' 102: ‘K15' 132: ‘D14' 162: ‘B7' 13: ‘F5' 43: ‘N3' 73: ‘R11' 103: ‘K16' 133: ‘B16'§ 163: ‘A6' 14: ‘G5' 44: ‘P1' 74: ‘T11' 104: ‘L12' 134: ‘C15' 164: ‘B6' 15: ‘G3' 45: ‘P2' 75: ‘N10' 105: ‘K12' 135: ‘A14' 165: ‘C6' 16: ‘G4' 46: ‘P4' 76: ‘M10' 106: ‘K13' 136: ‘A13' 166: ‘A5' 17: ‘G2' 47: ‘R4' 77: ‘P11' 107: ‘J14' 137: ‘B13' 167: ‘B5' 18: ‘G1' 48: ‘T3' 78: ‘R12' 108: ‘J15' 138: ‘C12' 168: ‘D6' 19: ‘H4' 49: ‘T4' 79: ‘T12' 109: ‘J16' 139: ‘B12' 169: ‘E6' 20: ‘H3' 50: ‘N5' 80: ‘T13' 110: ‘J13' 140: ‘A12' 170: ‘D5' 21: ‘H2' 51: ‘P5' 81: ‘N11' 111: ‘H16' 141: ‘D12' 171: ‘C5' 22: ‘H1' 52: ‘R5' 82: ‘M11' 112: ‘G16' 142: ‘E11' 172: ‘B4' 23: ‘J4' 53: ‘T5' 83: ‘P12' 113: ‘H14' 143: ‘D11' 173: ‘C4' 24: ‘J2' 54: ‘N6' 84: ‘N12' 114: ‘H15' 144: ‘C11' 174: ‘A4' 25: ‘J3' 55: ‘P6' 85: ‘R13' 115: ‘G15' 145: ‘B11' 175: ‘A3' 26: ‘J1' 56: ‘R6' 86: ‘P13' 116: ‘F16' 146: ‘A11' 176: ‘B3' 27: ‘K1' 57: ‘T6' 87: ‘T14' 117: ‘H13' 147: ‘E10' 28: ‘K2' 58: ‘M6' 88: ‘R14' 118: ‘G14' 148: ‘D10' 29: ‘K3' 59: ‘N7' 89: ‘P16' 119: ‘F15' 149: ‘C10' INIT pad ‘P15’ skipped here, not usable for normal I/O! §: pad ‘B16’ is not usable for normal I/O when basic serial download is used


197 data connections for XC2S100E-FG456

0: ‘D3' 33: ‘R1' 66: ‘Y9' 99: ‘Y22' 132: ‘H22' 165: ‘C14' 1: ‘D1' 34: ‘P5' 67: ‘V9' 100: ‘V20' 133: ‘H21' 166: ‘B14' 2: ‘E2' 35: ‘P6' 68: ‘W10' 101: ‘V22' 134: ‘H20' 167: ‘D13' 3: ‘E3' 36: ‘R2' 69: ‘Y10' 102: ‘U22' 135: ‘H19' 168: ‘C13' 4: ‘F4' 37: ‘R3' 70: ‘V10' 103: ‘U18' 136: ‘H18' 169: ‘B13' 5: ‘F3' 38: ‘R5' 71: ‘U10' 104: ‘U19' 137: ‘F22' 170: ‘A13' 6: ‘F2' 39: ‘T2' 72: ‘W11' 105: ‘T21' 138: ‘G21' 171: ‘B12' 7: ‘F1' 40: ‘T3' 73: ‘AB11' 106: ‘T22' 139: ‘G20' 172: ‘D12' 8: ‘G3' 41: ‘T1' 74: ‘Y12' 107: ‘T19' 140: ‘E22' 173: ‘A12' 9: ‘G2' 42: ‘U1' 75: ‘U12' 108: ‘R21' 141: ‘F21' 174: ‘B11' 10: ‘G1' 43: ‘U2' 76: ‘AB13' 109: ‘R22' 142: ‘E21' 175: ‘A10' 11: ‘H3' 44: ‘U3' 77: ‘W13' 110: ‘R18' 143: ‘F20' 176: ‘C10' 12: ‘H4' 45: ‘W1' 78: ‘V13' 111: ‘R19' 144: ‘D22' 177: ‘D10' 13: ‘H2' 46: ‘V2' 79: ‘U13' 112: ‘P22' 145: ‘D21' 178: ‘F10' 14: ‘H1' 47: ‘W2' 80: ‘AB14' 113: ‘P21' 146: ‘E20' 179: ‘A9' 15: ‘J5' 48: ‘Y2' 81: ‘Y14' 114: ‘P19' 147: ‘C22'§ 180: ‘C9' 16: ‘J3' 49: ‘W3' 82: ‘W14' 115: ‘N22' 148: ‘C21' 181: ‘D9' 17: ‘K5' 50: ‘AA5' 83: ‘AA15' 116: ‘N19' 149: ‘B20' 182: ‘A8' 18: ‘K6' 51: ‘W5' 84: ‘Y15' 117: ‘N20' 150: ‘A20' 183: ‘B8' 19: ‘K3' 52: ‘Y5' 85: ‘W15' 118: ‘N18' 151: ‘A19' 184: ‘C8' 20: ‘K4' 53: ‘AB5' 86: ‘V15' 119: ‘N17' 152: ‘B18' 185: ‘D8' 21: ‘L1' 54: ‘AB6' 87: ‘AB17' 120: ‘M21' 153: ‘A18' 186: ‘B7' 22: ‘L3' 55: ‘V6' 88: ‘AA16' 121: ‘M18' 154: ‘B17' 187: ‘C7' 23: ‘L5' 56: ‘W6' 89: ‘Y16' 122: ‘L22' 155: ‘A17' 188: ‘D7' 24: ‘L6' 57: ‘AB7' 90: ‘AA17' 123: ‘L21' 156: ‘E16' 189: ‘A6' 25: ‘M1' 58: ‘AA7' 91: ‘Y17' 124: ‘L20' 157: ‘E17' 190: ‘B6' 26: ‘M4' 59: ‘W7' 92: ‘AB18' 125: ‘L17' 158: ‘C16' 191: ‘C6' 27: ‘M5' 60: ‘AB8' 93: ‘W17' 126: ‘K22' 159: ‘B16' 192: ‘A5' 28: ‘N2' 61: ‘AA8' 94: ‘Y18' 127: ‘K19' 160: ‘A16' 193: ‘B4' 29: ‘N3' 62: ‘V8' 95: ‘W18' 128: ‘K18' 161: ‘D15' 194: ‘C5' 30: ‘N4' 63: ‘W8' 96: ‘AB19' 129: ‘K17' 162: ‘C15' 195: ‘A4' 31: ‘N5' 64: ‘AB9' 97: ‘AB20' 130: ‘J22' 163: ‘B15' 196: ‘D5' 32: ‘P2' 65: ‘AA9' 98: ‘AA20' 131: ‘J19' 164: ‘A15' INIT pad ‘W21’ skipped here, not usable for normal I/O! §: pad ‘C22’ is not usable for normal I/O when basic serial download is used



0: ‘D3' 44: ‘P3' 88: ‘Y9' 132: ‘V21' 176: ‘H21' 220: ‘A14' 1: ‘C1' 45: ‘P5' 89: ‘V9' 133: ‘V19' 177: ‘H20' 221: ‘D13' 2: ‘D2' 46: ‘P6' 90: ‘U9' 134: ‘V20' 178: ‘H19' 222: ‘C13' 3: ‘D1' 47: ‘R2' 91: ‘W10' 135: ‘V22' 179: ‘H18' 223: ‘B13' 4: ‘E2' 48: ‘R3' 92: ‘Y10' 136: ‘U22' 180: ‘F22' 224: ‘A13' 5: ‘E3' 49: ‘R5' 93: ‘V10' 137: ‘U20' 181: ‘G21' 225: ‘B12' 6: ‘F5' 50: ‘T2' 94: ‘U10' 138: ‘U18' 182: ‘G20' 226: ‘D12' 7: ‘F4' 51: ‘T3' 95: ‘W11' 139: ‘U19' 183: ‘G19' 227: ‘E12' 8: ‘F3' 52: ‘T4' 96: ‘Y11' 140: ‘T21' 184: ‘G18' 228: ‘A12' 9: ‘F2' 53: ‘T5' 97: ‘AB11' 141: ‘T22' 185: ‘E22' 229: ‘B11' 10: ‘F1' 54: ‘T1' 98: ‘Y12' 142: ‘T20' 186: ‘F21' 230: ‘A10' 11: ‘G5' 55: ‘U1' 99: ‘V12' 143: ‘T18' 187: ‘E21' 231: ‘B10' 12: ‘G4' 56: ‘U2' 100: ‘U12' 144: ‘T19' 188: ‘F20' 232: ‘C10' 13: ‘G3' 57: ‘U3' 101: ‘AB13' 145: ‘R21' 189: ‘F19' 233: ‘D10' 14: ‘G2' 58: ‘U4' 102: ‘W13' 146: ‘R22' 190: ‘D22' 234: ‘F10' 15: ‘G1' 59: ‘W1' 103: ‘V13' 147: ‘R18' 191: ‘D21' 235: ‘A9' 16: ‘H3' 60: ‘V2' 104: ‘U13' 148: ‘R19' 192: ‘E20' 236: ‘C9' 17: ‘H4' 61: ‘W2' 105: ‘AB14' 149: ‘P22' 193: ‘E19' 237: ‘D9' 18: ‘H2' 62: ‘V3' 106: ‘Y14' 150: ‘P21' 194: ‘C22'§ 238: ‘F8' 19: ‘H1' 63: ‘V4' 107: ‘W14' 151: ‘P18' 195: ‘C21' 239: ‘E9' 20: ‘J4' 64: ‘Y2' 108: ‘U14' 152: ‘P19' 196: ‘B20' 240: ‘A8' 21: ‘J5' 65: ‘W3' 109: ‘V14' 153: ‘N22' 197: ‘A20' 241: ‘B8' 22: ‘J3' 66: ‘AA3' 110: ‘AA15' 154: ‘N21' 198: ‘C18' 242: ‘C8' 23: ‘J2' 67: ‘AB3' 111: ‘Y15' 155: ‘N19' 199: ‘B19' 243: ‘D8' 24: ‘K5' 68: ‘AA5' 112: ‘W15' 156: ‘N20' 200: ‘A19' 244: ‘B7' 25: ‘K6' 69: ‘W5' 113: ‘V15' 157: ‘N18' 201: ‘B18' 245: ‘C7' 26: ‘K3' 70: ‘Y5' 114: ‘AB17' 158: ‘N17' 202: ‘A18' 246: ‘D7' 27: ‘K4' 71: ‘AB5' 115: ‘AA16' 159: ‘M21' 203: ‘C17' 247: ‘E8' 28: ‘L1' 72: ‘AB6' 116: ‘Y16' 160: ‘M18' 204: ‘B17' 248: ‘E7' 29: ‘L3' 73: ‘AA6' 117: ‘W16' 161: ‘M19' 205: ‘A17' 249: ‘A6' 30: ‘L2' 74: ‘V6' 118: ‘V16' 162: ‘L22' 206: ‘E16' 250: ‘B6' 31: ‘L5' 75: ‘W6' 119: ‘AA17' 163: ‘L21' 207: ‘E17' 251: ‘C6' 32: ‘L6' 76: ‘AB7' 120: ‘Y17' 164: ‘L20' 208: ‘E15' 252: ‘A5' 33: ‘M1' 77: ‘AA7' 121: ‘AB18' 165: ‘L18' 209: ‘D16' 253: ‘B5' 34: ‘M3' 78: ‘Y7' 122: ‘W17' 166: ‘L17' 210: ‘C16' 254: ‘B4' 35: ‘M4' 79: ‘V7' 123: ‘V17' 167: ‘K22' 211: ‘B16' 255: ‘C5' 36: ‘M5' 80: ‘W7' 124: ‘Y18' 168: ‘K19' 212: ‘A16' 256: ‘A4' 37: ‘N2' 81: 'AB8' 125: ‘W18' 169: ‘K18' 213: ‘D15' 257: ‘A3' 38: ‘N3' 82: ‘AA8' 126: ‘AB19' 170: ‘K17' 214: ‘C15' 258: ‘B3' 39: ‘N4' 83: ‘V8' 127: ‘AA19' 171: ‘J22' 215: ‘B15' 259: ‘D5' 40: ‘N5' 84: ‘W8' 128: ‘Y19' 172: ‘J20' 216: ‘A15' 41: ‘P1' 85: ‘AB9' 129: ‘AB20' 173: ‘J19' 217: ‘D14' 42: ‘P2' 86: ‘AA9' 130: ‘AA20' 174: ‘H22' 218: ‘C14' 43: ‘R1' 87: ‘W9' 131: ‘Y22' 175: ‘J18' 219: ‘B14' INIT pad ‘W21’ skipped here, not usable for normal I/O! §: pad ‘C22’ is not usable for normal I/O when basic serial download is used

NOTE: Xilinx document DS077-1 (v1.1) states this device/package combina-tion has only 263 user I/O pins. When subtracting the four clock inputs and the INIT pin, this would leave only 258 I/O pins free. The table above is based upon Xilinx document DS077-4 (v1.1).



0: ‘D3' 48: ‘R1' 96: ‘V9' 144: ‘V21' 192: ‘J18' 240: ‘E13' 1: ‘C1' 49: ‘P3' 97: ‘U9' 145: ‘V19' 193: ‘J17' 241: ‘D13' 2: ‘D2' 50: ‘P4' 98: ‘AA10' 146: ‘V20' 194: ‘H21' 242: ‘C13' 3: ‘D1' 51: ‘P5' 99: ‘W10' 147: ‘V22' 195: ‘H20' 243: ‘B13' 4: ‘E2' 52: ‘P6' 100: ‘Y10' 148: ‘U22' 196: ‘H19' 244: ‘A13' 5: ‘E3' 53: ‘R2' 101: ‘V10' 149: ‘U20' 197: ‘H18' 245: ‘C12' 6: ‘F5' 54: ‘R3' 102: ‘U10' 150: ‘U18' 198: ‘F22' 246: ‘B12' 7: ‘F4' 55: ‘R5' 103: ‘V11' 151: ‘U19' 199: ‘G21' 247: ‘D12' 8: ‘F3' 56: ‘T2' 104: ‘W11' 152: ‘T21' 200: ‘G20' 248: ‘E12' 9: ‘F2' 57: ‘T3' 105: ‘Y11' 153: ‘T22' 201: ‘G19' 249: ‘A12' 10: ‘F1' 58: ‘T4' 106: ‘AB11' 154: ‘T20' 202: ‘G18' 250: ‘B11' 11: ‘G5' 59: ‘T5' 107: ‘Y12' 155: ‘T18' 203: ‘E22' 251: ‘F11' 12: ‘G4' 60: ‘T1' 108: ‘V12' 156: ‘T19' 204: ‘F21' 252: ‘A10' 13: ‘G3' 61: ‘U1' 109: ‘U12' 157: ‘R21' 205: ‘E21' 253: ‘B10' 14: ‘G2' 62: ‘U2' 110: ‘AB13' 158: ‘R22' 206: ‘F20' 254: ‘C10' 15: ‘G1' 63: ‘U3' 111: ‘AA13' 159: ‘R18' 207: ‘F19' 255: ‘D10' 16: ‘H3' 64: ‘U4' 112: ‘W13' 160: ‘R19' 208: ‘D22' 256: ‘F10' 17: ‘H4' 65: ‘W1' 113: ‘V13' 161: ‘P22' 209: ‘D21' 257: ‘A9' 18: ‘H2' 66: ‘V2' 114: ‘U13' 162: ‘P21' 210: ‘E20' 258: ‘B9' 19: ‘H1' 67: ‘W2' 115: ‘AB14' 163: ‘P20' 211: ‘E19' 259: ‘E10' 20: ‘J6' 68: ‘V3' 116: ‘AA14' 164: ‘P18' 212: ‘C22'§ 260: ‘C9' 21: ‘J4' 69: ‘V4' 117: ‘AB15' 165: ‘P19' 213: ‘C21' 261: ‘D9' 22: ‘J5' 70: ‘Y2' 118: ‘Y14' 166: ‘N22' 214: ‘B20' 262: ‘F9' 23: ‘J3' 71: ‘W3' 119: ‘W14' 167: ‘N21' 215: ‘A20' 263: ‘E9' 24: ‘J2' 72: ‘AA3' 120: ‘U14' 168: ‘P17' 216: ‘C18' 264: ‘A8' 25: ‘J1' 73: ‘AB3' 121: ‘V14' 169: ‘N19' 217: ‘B19' 265: ‘B8' 26: ‘K5' 74: ‘AA5' 122: ‘AA15' 170: ‘N20' 218: ‘A19' 266: ‘C8' 27: ‘K6' 75: ‘W5' 123: ‘Y15' 171: ‘N18' 219: ‘B16' 267: ‘D8' 28: ‘K3' 76: ‘Y5' 124: ‘W15' 172: ‘N17' 220: ‘A16' 268: ‘B7' 29: ‘K4' 77: ‘AB5' 125: ‘V15' 173: ‘M20' 221: ‘C17' 269: ‘C7' 30: ‘K1' 78: ‘AB6' 126: ‘AB17' 174: ‘M21' 222: ‘B17' 270: ‘D7' 31: ‘L1' 79: ‘AA6' 127: ‘AA16' 175: ‘M18' 223: ‘A17' 271: ‘E8' 32: ‘L3' 80: ‘V6' 128: ‘Y16' 176: ‘M19' 224: ‘E16' 272: ‘E7' 33: ‘L2' 81: ‘W6' 129: ‘W16' 177: ‘L22' 225: ‘E17' 273: ‘A6' 34: ‘L5' 82: ‘AB7' 130: ‘V16' 178: ‘L21' 226: ‘E15' 274: ‘B6' 35: ‘L6' 83: ‘AA7' 131: ‘AA17' 179: ‘L20' 227: ‘D16' 275: ‘C6' 36: ‘M1' 84: ‘Y7' 132: ‘Y17' 180: ‘L18' 228: ‘C16' 276: ‘A5' 37: ‘M3' 85: ‘V7' 133: ‘AB18' 181: ‘L17' 229: ‘B16' 277: ‘B5' 38: ‘M4' 86: ‘W7' 134: ‘W17' 182: ‘K22' 230: ‘A16' 278: ‘B4' 39: ‘M5' 87: ‘AB8' 135: ‘V17' 183: ‘K21' 231: ‘D15' 279: ‘C5' 40: ‘M6' 88: ‘AA8' 136: ‘Y18' 184: ‘K19' 232: ‘C15' 280: ‘A4' 41: ‘N2' 89: ‘V8' 137: ‘W18' 185: ‘K18' 233: ‘B15' 281: ‘A3' 42: ‘N3' 90: ‘W8' 138: ‘AB19' 186: ‘K17' 234: ‘A15' 282: ‘B3' 43: ‘N4' 91: ‘AB9' 139: ‘AA19' 187: ‘J22' 235: ‘E14' 283: ‘D5' 44: ‘N5' 92: ‘AA9' 140: ‘Y19' 188: ‘J21' 236: ‘D14' 45: ‘N6' 93: ‘AB10' 141: ‘AB20' 189: ‘J20' 237: ‘C14' 46: ‘P1' 94: ‘W9' 142: ‘AA20' 190: ‘J19' 238: ‘B14' 47: ‘P2' 95: ‘Y9' 143: ‘Y22' 191: ‘H22' 239: ‘A14' INIT pad ‘W21’ skipped here, not usable for normal I/O! §: pad ‘C22’ is not usable for normal I/O when basic serial download is used



0: ‘D3' 48: ‘N2' 96: ‘Y7' 144: ‘AB17' 192: ‘N19' 240: ‘E19' 288: ‘A10' 1: ‘C2' 49: ‘N3' 97: 'V7' 145: ‘AA16' 193: ‘N20' 241: ‘D20' 289: ‘B10' 2: ‘C1' 50: ‘N4' 98: ‘W7' 146: ‘Y16' 194: ‘N18' 242: ‘C22'§ 290: ‘E11' 3: ‘D2' 51: ‘N5' 99: ‘AB8' 147: ‘W16' 195: ‘N17' 243: ‘C21' 291: ‘C10' 4: ‘D1' 52: ‘N6' 100: ‘AA8' 148: ‘V16' 196: ‘M22' 244: ‘B20' 292: ‘D10' 5: ‘E2' 53: ‘P1' 101: ‘Y8' 149: ‘AA17' 197: ‘M20' 245: ‘A20' 293: ‘F10' 6: ‘E3' 54: ‘P2' 102: ‘V8' 150: ‘Y17' 198: ‘M21' 246: ‘D18' 294: ‘A9' 7: ‘E1' 55: ‘R1' 103: ‘W8' 151: ‘AB18' 199: ‘M18' 247: ‘C18' 295: ‘B9' 8: ‘F5' 56: ‘P3' 104: ‘AB9' 152: ‘W17' 200: ‘M19' 248: ‘B19' 296: ‘E10' 9: ‘F4' 57: ‘P4' 105: ‘AA9' 153: ‘V17' 201: ‘M17' 249: ‘A19' 297: ‘C9' 10: ‘F3' 58: ‘P5' 106: ‘AB10' 154: ‘AA18' 202: ‘L22' 250: ‘B18' 298: ‘D9' 11: ‘F2' 59: ‘P6' 107: ‘W9' 155: ‘Y18' 203: ‘L21' 251: ‘A18' 299: ‘F9' 12: ‘F1' 60: ‘R2' 108: ‘Y9' 156: ‘W18' 204: ‘L20' 252: ‘D17' 300: ‘E9' 13: ‘G5' 61: ‘R3' 109: ‘V9' 157: ‘AB19' 205: ‘L19' 253: ‘C17' 301: ‘A8' 14: ‘G4' 62: ‘R4' 110: ‘U9' 158: ‘AA19' 206: ‘L18' 254: ‘B17' 302: ‘B8' 15: ‘G3' 63: ‘R5' 111: ‘AA10' 159: ‘Y19' 207: ‘L17' 255: ‘A17' 303: ‘C8' 16: ‘G2' 64: ‘T2' 112: ‘W10' 160: ‘AB21' 208: ‘K22' 256: ‘E16' 304: ‘D8' 17: ‘G1' 65: ‘T3' 113: ‘Y10' 161: ‘AB20' 209: ‘K21' 257: ‘E17' 305: ‘A7' 18: ‘H5' 66: ‘T4' 114: ‘V10' 162: ‘AA20' 210: ‘K20' 258: ‘E15' 306: ‘B7' 19: ‘H3' 67: ‘T5' 115: ‘U10' 163: ‘Y22' 211: ‘K19' 259: ‘D16' 307: ‘C7' 20: ‘H4' 68: ‘T1' 116: ‘U11' 164: ‘W22' 212: ‘K18' 260: ‘C16' 308: ‘D7' 21: ‘H2' 69: ‘U1' 117: ‘V11' 165: ‘V21' 213: ‘K17' 261: ‘B16' 309: ‘E8' 22: ‘H1' 70: ‘U2' 118: ‘W11' 166: ‘V19' 214: ‘J22' 262: ‘A16' 310: ‘E7' 23: ‘J6' 71: ‘U3' 119: ‘Y11' 167: ‘V20' 215: ‘J21' 263: ‘F14' 311: ‘A6' 24: ‘J4' 72: ‘U4' 120: ‘AA11' 168: ‘V22' 216: ‘J20' 264: ‘D15' 312: ‘B6' 25: ‘J5' 73: ‘V1' 121: ‘AB11' 169: ‘U22' 217: ‘J19' 265: ‘C15' 313: ‘C6' 26: ‘J3' 74: ‘W1' 122: ‘Y12' 170: ‘U21' 218: ‘H22' 266: ‘B15' 314: ‘A5' 27: ‘J2' 75: ‘V2' 123: ‘W12' 171: ‘U20' 219: ‘J18' 267: ‘A15' 315: ‘B5' 28: ‘J1' 76: ‘W2' 124: ‘V12' 172: ‘U18' 220: ‘J17' 268: ‘E14' 316: ‘D6' 29: ‘K5' 77: ‘V3' 125: ‘U12' 173: ‘U19' 221: ‘H21' 269: ‘D14' 317: ‘B4' 30: ‘K6' 78: ‘V4' 126: ‘AB13' 174: ‘T21' 222: ‘H20' 270: ‘C14' 318: ‘C5' 31: ‘K3' 79: ‘Y1' 127: ‘AA13' 175: ‘T22' 223: ‘H19' 271: ‘B14' 319: ‘A4' 32: ‘K4' 80: ‘Y2' 128: ‘Y13' 176: ‘T20' 224: ‘H18' 272: ‘A14' 320: ‘A3' 33: ‘K2' 81: ‘W3' 129: ‘W13' 177: ‘T18' 225: ‘G22' 273: ‘E13' 321: ‘B3' 34: ‘K1' 82: ‘AA3' 130: ‘V13' 178: ‘T19' 226: ‘F22' 274: ‘D13' 322: ‘C4' 35: ‘L1' 83: ‘AB3' 131: ‘U13' 179: ‘R21' 227: ‘G21' 275: ‘C13' 323: ‘D5' 36: ‘L3' 84: ‘AB4' 132: ‘AB14' 180: ‘R22' 228: ‘G20' 276: ‘B13' 37: ‘L2' 85: ‘AA5' 133: ‘AA14' 181: ‘R20' 229: ‘G19' 277: ‘A13' 38: ‘L4' 86: ‘W5' 134: ‘AB15' 182: ‘R18' 230: ‘G18' 278: ‘F13' 39: ‘L5' 87: ‘Y5' 135: ‘Y14' 183: ‘R19' 231: ‘E22' 279: ‘C12' 40: ‘L6' 88: ‘AB5' 136: ‘W14' 184: ‘P22' 232: ‘F21' 280: ‘B12' 41: ‘M1' 89: ‘AB6' 137: ‘U14' 185: ‘P21' 233: ‘E21' 281: ‘D12' 42: ‘M2' 90: ‘Y6' 138: ‘V14' 186: ‘P20' 234: ‘F20' 282: ‘E12' 43: ‘M3' 91: ‘AA6' 139: ‘AA15' 187: ‘P18' 235: ‘F19' 283: ‘F12' 44: ‘M4' 92: ‘V6' 140: ‘Y15' 188: ‘P19' 236: ‘F18' 284: ‘A12' 45: ‘M5' 93: ‘W6' 141: ‘W15' 189: ‘N22' 237: ‘D22' 285: ‘B11' 46: ‘M6' 94: ‘AB7' 142: ‘V15' 190: ‘N21' 238: ‘D21' 286: ‘D11' 47: ‘N1' 95: ‘AA7' 143: ‘AB16' 191: ‘P17' 239: ‘E20' 287: ‘F11' INIT pad ‘W21’ skipped here, not usable for normal I/O! §: pad ‘C22’ is not usable for normal I/O when basic serial download is used

Date post:	08-Jul-2020
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times

IDaSS to Xilinx Spartan-II(E) FPGA conversion · directory of IDaSS (or the VisualWorks Smalltalk...

Documents