Rapid Smith Documentation

RAPIDSMITH
A Library for Low-level Manipulation of Partially Placed-and-Routed FPGA Designs

Technical Report and Documentation
Christopher Lavin, Marc Padilla, Jaren Lamprecht, Philip Lundrigan, Brent Nelson, Brad Hutchings, and Michael Wirthlin NSF Center for High Performance Reconfigurable Computing (CHREC) Department of Electrical and Computer Engineering Brigham Young University Provo, UT 84602
This work was supported by the I/UCRC program of the National Science Foundation under grant number 0801876.
Page | 2
TABLE OF CONTENTS
Table of Figures ...................................................................................................................................................... 5 Introduction ............................................................................................................................................................. 6 What is RapidSmith? .......................................................................................................................................... 6 Who Should Use RapidSmith? ........................................................................................................................... 6 Why RapidSmith? ............................................................................................................................................... 6 Which Xilinx Parts does RapidSmith Support? .................................................................................................. 6 How is This Different than VPR? ....................................................................................................................... 7 Why Java? ........................................................................................................................................................... 7 Legal and Dependencies ......................................................................................................................................... 8 RapidSmith Legal Text ....................................................................................................................................... 8 Included Dependency Projects ............................................................................................................................ 8 Getting Started ...................................................................................................................................................... 10 Installation......................................................................................................................................................... 10 Getting RapidSmith ...................................................................................................................................... 10 Requirements for Installation ........................................................................................................................ 10 Steps for Installation ..................................................................................................................................... 10 Additional Notes for Mac OS X Installation ................................................................................................ 11 Overview ........................................................................................................................................................... 12 bitstreamTools.* Package ................................................................................................................ 13 design Package .......................................................................................................................................... 13 design.explorer Package .................................................................................................................... 15 design.parser Package ......................................................................................................................... 17 device Package .......................................................................................................................................... 17 device.browser Package....................................................................................................................... 18 device.helper Package ......................................................................................................................... 19 examples Package ..................................................................................................................................... 19 placer Package .......................................................................................................................................... 19 primitiveDefs Package ......................................................................................................................... 19 router Package .......................................................................................................................................... 20 tests Package ............................................................................................................................................ 20 timing Package .......................................................................................................................................... 20 util Package............................................................................................................................................... 20 Examples ........................................................................................................................................................... 20
Copyright 2010-2011 Brigham Young University 4/29/2011 1:25 PM
Page | 3
Hello World .................................................................................................................................................. 20 Hand Router .................................................................................................................................................. 22 Part Tile Browser .......................................................................................................................................... 22 Understanding XDL .............................................................................................................................................. 24 What is XDL? ................................................................................................................................................... 24 Basic Syntax of XDL Files ............................................................................................................................... 25 Design Statement .......................................................................................................................................... 25 Module Statement ......................................................................................................................................... 25 Instance Statement ........................................................................................................................................ 26 Net Statement ................................................................................................................................................ 26 Basic Syntax of XDLRC Files .......................................................................................................................... 27 Tiles............................................................................................................................................................... 27 Primitive Sites ............................................................................................................................................... 27 Wire............................................................................................................................................................... 28 PIP ................................................................................................................................................................. 28 Primitive Definitions..................................................................................................................................... 29 RapidSmith Structure ............................................................................................................................................ 30 A RapidSmith Design ....................................................................................................................................... 30 Loading Designs ........................................................................................................................................... 30 Saving Designs.............................................................................................................................................. 31 A RapidSmith Device ....................................................................................................................................... 31 Device ........................................................................................................................................................... 31 Wire Enumerator ........................................................................................................................................... 31 Memory and Performance................................................................................................................................. 32 Device Performance and Memory Usage ..................................................................................................... 32 Wire Enumerator Size and Performance....................................................................................................... 32 Placement in RapidSmith...................................................................................................................................... 33 Primitive Resources in RapidSmith .................................................................................................................. 33 Primitive Site ................................................................................................................................................ 33 Primitive Definitions and Types ................................................................................................................... 34 Primitive Instances ........................................................................................................................................ 34 Placement .......................................................................................................................................................... 35 Placement Techniques ...................................................................................................................................... 35 Routing in RapidSmith ......................................................................................................................................... 36 Wire Resources in RapidSmith ......................................................................................................................... 36 Wire Representation...................................................................................................................................... 36
Page | 4
Basic Routing .................................................................................................................................................... 38 Router Structure ............................................................................................................................................ 38 Routing Static Sources (VCC/GND) ............................................................................................................ 39 Routing Clocks.............................................................................................................................................. 39 Internal Pin Names and External Pin Names ................................................................................................ 39 Bitstreams in RapidSmith ..................................................................................................................................... 42 Bitstream Composition ..................................................................................................................................... 42 Bitstream Header .......................................................................................................................................... 43 Dummy and Synchronization Data ............................................................................................................... 44 Packet List ..................................................................................................................................................... 44 Bitstream Configuration Data ........................................................................................................................... 44 FPGA ............................................................................................................................................................ 44 Xilinx Configuration Specification ............................................................................................................... 44 Frame Address Register ................................................................................................................................ 45 Frame ............................................................................................................................................................ 45 Configuration Block...................................................................................................................................... 46 Appendix ............................................................................................................................................................... 48 Appendix A: Modifying LUT Content ............................................................................................................. 48 LUT Equation Syntax ................................................................................................................................... 48 XDL LUT Equation Syntax .......................................................................................................................... 48 Appendix B: Hard Macros in XDL and RapidSmith ........................................................................................ 49 Xilinx NMC files .......................................................................................................................................... 49 Xilinx Hard Macros ...................................................................................................................................... 49 RapidSmith Hard Macro Generator .............................................................................................................. 49 Appendix C: Xilinx Family Names and Part Names ........................................................................................ 50 Xilinx Part Names in RapidSmith................................................................................................................. 50 Xilinx Family Names in RapidSmith ............................................................................................................ 50 Appendix D: XDLRC Compatible Families ..................................................................................................... 51 Appendix E: Memory and Performance of RapidSmith ................................................................................... 51 Wire Enumerator Files .................................................................................................................................. 52 Primitive Definitions Files ............................................................................................................................ 52 Device Files .................................................................................................................................................. 52
Copyright 2010-2011 Brigham Young University
4/29/2011 1:25 PM
Page | 5
TABLE OF FIGURES
Figure 1 - Design and Attribute classes ................................................................................................................ 14 Figure 2 - Instance class ........................................................................................................................................ 14 Figure 3 - Net, Pin and PIP Classes ...................................................................................................................... 15 Figure 4 - Hyperlinks in Design Explorer............................................................................................................. 16 Figure 5 - Timing report loaded in Design Explorer ............................................................................................ 17 Figure 6 - Device Browser screenshot .................................................................................................................. 18 Figure 7 - Device browser screenshot showing wire connections ........................................................................ 19 Figure 8: Screenshot of Part Tile Browser ............................................................................................................ 23 Figure 9: Block diagram of where XDL fits in CAD flow. .................................................................................. 24 Figure 10: (a) The classes involved in defining a design in RapidSmith, (b) The major classes involved representing a device............................................................................................................................................. 30 Figure 11 Device Browser screenshot showing site SLICE_X1Y121 in tile CLB_X1Y60.............................. 34 Figure 12 - A DOUBLE line in an FPGA illustrating how each part of the wire has a different name depending on the tile it is located in. ...................................................................................................................................... 36
4/29/2011 1:25 PM
Page | 6
INTRODUCTION
What is RapidSmith?
The BYU RapidSmith project is a set of tools and APIs written in Java that aim to provide academics with an easy-to-use platform to try out experimental ideas and algorithms on modern Xilinx FPGAs. RapidSmith is based on the Xilinx Design Language (XDL) which provides a human-readable file format equivalent to the Xilinx proprietary Netlist Circuit Description (NCD). With RapidSmith, researchers are able to import XDL/NCD, manipulate, place, route and export designs among a variety of design transformations. The RapidSmith project makes an excellent test bed to try out new ideas and algorithms for FPGA CAD research as code can quickly be written to take advantage of the APIs available. RapidSmith also contains packages which can parse/export bitstreams (at the packet level) and represent the frames and configuration blocks in the provided data structures. It can parse, manipulate and export bitstreams according to Xilinx documented methods. RapidSmith does not include any proprietary information about Xilinx FPGAs that is not publicly available.
Who Should Use RapidSmith?

RapidSmith is aimed at use by academics in all fields of FPGA CAD research. It is written in Java; therefore those using it will need to have a basic knowledge of programming and using Java. It also depends on some understanding of Xilinx FPGAs and XDL, however, this documentation hopes to bring people unfamiliar with these topics up to speed. RapidSmith by no means is a Xilinx ISE replacement and cannot be used without a valid and current license to a Xilinx tools installation. RapidSmith should not be used for designs bound for commercial products and is offered mainly as a research tool.
Why RapidSmith?
The Xilinx ISE tools provide an xdl executable that allows conversion of NCD files to and from XDL which can then be parsed, manipulated and exported using RapidSmith. The xdl executable also creates special device files which are huge in size but contain useful detailed device data. RapidSmith takes care of all of the parsing and detailed FPGA part information that can be cumbersome to usealleviating the need to build such parsing tools by the researcher. RapidSmith creates special part files from these device files created by the ISE tools which can then be used by RapidSmith for design manipulation. This project provides researchers the ability to leverage all of the XDL work previously done and avoid duplicate work. This will enable researchers to have more time to focus on what matters most: their research of new ideas and algorithms.
Which Xilinx Parts does RapidSmith Support?

Virtex 4 and 5 families have been tested the most and are currently supported in all forms and applications. However, the XDLRC reports which can be extracted from the xdl executable are very regular and so RapidSmith can create device files for all modern Xilinx FPGA families. Therefore, RapidSmith supports (to a
Page | 7
lesser extent than Virtex 4 and Virtex 5) the following families: Kintex 7, Spartan 2, Spartan 2E, Spartan 3, Spartan 3A, Spartan 3ADSP, Spartan 3E, Spartan 6, Virtex, Virtex E, Virtex 2, Virtex 2 Pro, Virtex 6, and Virtex 7. To create the device files for the legacy devices, Xilinx ISE 10.1.03 or earlier will be needed. The table below provides a complete set of compatible features for each Xilinx FPGA family. See the Appendix for more family compatibilities (Spartan 6L, Virtex 6L, etc.).
Xilinx FPGA Family Device Database, XDL Parsing, Manipulation & Export Placement Capabilities Router Capabilities Bitstream Parsing, Manipulation & Export
Kintex 7 Spartan 2 Spartan 2E Spartan 3 Spartan 3A Spartan 3ADSP Spartan 3E Spartan 6 Virtex Virtex E Virtex 2 Virtex 2 Pro Virtex 4 Virtex 5 Virtex 6 Virtex 7
X X X X X X X X X X X X X X X X
X X X X X X X X X X X X X X X X
X X
X X X
How is This Different than VPR?

VPR (Versatile Place and Route) has been an FPGA research tool for several years and has led to hundreds of publications on new FPGA CAD research. It has been a significant contribution to the FPGA research community and has grown to be a complete FPGA CAD flow for research-based FPGAs. The main difference between RapidSmith and VPR is that RapidSmith aims to provide the ability to target commercial Xilinx FPGAs. All features of these FPGAs which are accessible via XDL are available in RapidSmith. Our understanding is that VPR currently is limited to FPGA features which can be described using VPR's architectural description facilities.
Why Java?
We have found Java to be a rapid prototyping platform for FPGA CAD tools. The Java libraries are rich with data structures useful for such applications and Java eliminates the need to clean up objects in memory. This eliminates the time needed to debug such things in other development platforms, leaving more time for the researcher to focus on the real research at hand. Some may argue that Java is a poor platform for FPGA CAD tool design as it has a reputation of being a memory hog and slow. We believe that these claims are overstated and that both speed and memory can be controlled to the point where this is not an issue.
4/29/2011 1:25 PM
Page | 8
LEGAL AND DEPENDENCIES

RapidSmith Legal Text
BYU RapidSmith Tools Copyright (c) 2010-2011 Brigham Young University BYU RapidSmith Tools is free software: you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (at your option) any later version. BYU RapidSmith Tools is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. A copy of the GNU General Public License is included with the BYU RapidSmith Tools. It can be found at doc/gpl2.txt. You may also get a copy of the license at <http://www.gnu.org/licenses/>.
Included Dependency Projects

RapidSmith includes the Caucho Technology Hessian implementation which is distributed under the Apache License. A copy of this license is included in the doc directory in the file APACHE2-LICENSE.txt. This license is also available for download at: http://www.apache.org/licenses/LICENSE-2.0 The source for the Caucho Technology Hessian implementation is available at: http://hessian.caucho.com RapidSmith also includes the Qt Jambi project jars for Windows, Linux and Mac OS X. Qt Jambi is distributed under the LGPL GPL3 license and copies of this license and exception are also available in the /doc directory in files LICENSE.GPL3.TXT and LICENSE.LGPL.TXT respectively. These licenses can also be downloaded at: http://www.gnu.org/licenses/licenses.html Source for the Qt Jambi project is available at: http://qt.nokia.com/downloads and more recent versions are available at: http:/qt.gitorious.org/qt-jambi
Page | 9
RapidSmith also includes the JOpt Simple option parser which is released under the open source MIT License which can be found in this directory in the file MIT_LICENSE.TXT. A copy of this license can also be found at: http://www.opensource.org/licenses/mit-license.php A copy of the source for JOpt Simple can also be downloaded at: http://jopt-simple.sourceforge.net/download.html The user is responsible for providing copies of these licenses and making available the source code of these projects when redistributing these jars.
4/29/2011 1:25 PM
Page | 10
GETTING STARTED
Installation
Getting RapidSmith
You can download the latest release of RapidSmith from the sourceforge page here: http://sourceforge.net/projects/rapidsmith/files/ You can also checkout the repository from SVN. We recommend using Eclipse, however, any IDE will work fine. To check out the RapidSmith project, the SVN URL is: https://rapidsmith.svn.sourceforge.net/svnroot/rapidsmith/trunk rapidsmith This repository contains all the files you need (including supporting JAR files). If you are using Eclipse as your IDE, it contains project files to get the project up and running with minimal effort. If you downloaded the distribution, just extract the files into your workspace (eg: ~/workspace/rapidSmith). Then, in Eclipse, you can import the project by going to File->Import, then choose "General/Existing Projects into Workspace". On the next screen, choose "Select root directory" and choose the newly created folder "rapidSmith". Then click finish. This should load up the project in your workspace. Then follow the steps below to complete the installation. You may have to restart Eclipse after setting the environment variables to get things to work.
Requirements for Installation

400 MB free disk space Windows XP/Vista/7 or Linux (Mac OS X will work (see notes below), but Xilinx tools do not run on Mac OS X) Xilinx ISE 11.1 or higher (10.1.03 or earlier for legacy devices). JDK 1.6 (earlier versions may work, but have not been tested). Supporting JARs o INCLUDED: Caucho Hessian Implementation JAR v.4.0.6 (Used for compressing database device files) o INCLUDED: Qt Jambi (Qt for Java) for the Part Tile Browser example. Just adding the jars to the CLASSPATH variable is adequate. o INCLUDED: JOpt Simple for use by some examples in the bitstream tools packages. o OPTIONAL: JavaCC if the user wants to change the XDL design parser. There is also a good plugin for Eclipse for JavaCC which makes it easier to modify and compile .jj files.
Steps for Installation

1. Make sure the Xilinx tools and JDK are on your PATH. 2. Add all the jar files in the jars folder (hessian-4.0.6.jar, qtjambi-4.6.3.jar, qtjambi-<your_platform>4.6.3.jar, jopt-simple-3.2.jar) to your CLASSPATH environment variable. 3. Add the RapidSmith Java project to your CLASSPATH environment variable. 4. Create an environment variable called RAPIDSMITH_PATH and set its value to the path where you have the Java project located on your computer.
Page | 11
5. (Skip this step if you are not using legacy devices) When using RapidSmith with legacy Xilinx devices (Spartan 2/2E, Virtex, Virtex E/2/2Pro), ISE 10.1 or earlier will be needed. In order to point RapidSmith to the appropriate installation of tools, we use an environment variable: XILINX_LEGACY_PATH which you must add and set its value to the bin path of the 10.1 or earlier tools. For example, setting XILINX_LEGACY_PATH=/opt/xilinx/10.1/ISE/bin/lin64 would use the 64-bit tools of ISE 10.1 of a Linux installation. 6. Compile all of the Java classes (this can be done automatically if the project is imported into an IDE such as Eclipse). 7. Test your installation by running any of the programs, for example, run:
java edu.byu.ece.rapidSmith.util.BrowseDevice xc5vlx20tff323
OBSOLETE: Device files are now included with RapidSmith, so the Installer class no longer needs to be run. The following instructions are simply included for legacy users (versions of RapidSmith older than 0.5.0, and using older device versions). Generate the supporting device and enumeration files needed to run the various parts of RapidSmith. Please note that if you are generating both families of Virtex 4 and Virtex 5 parts, it will take several hours and is best left to run overnight because of the time requirement. This only needs to be done once, however. To generate the part files, follow these steps: a. Choose which parts you plan to use, or you can choose to do all parts in the Virtex 4 and Virtex 5 families (in the future, more parts will be compatible). b. Run the installer for RapidSmith by executing the main method in the class edu.byu.ece.rapidSmith.util.Installer. This is accomplished by running the following at the command line:
Java Xmx1600M edu.byu.ece.rapidSmith.util.Installer virtex4 virtex5
c. The previous command will take several hours. Some of the larger parts will also require a lot of heap memory to generate the part file (sometimes 1600M is too large for some computers, if it fails, try 1200M). d. You can test if the file generation worked by looking in the appropriate folders (devices/virtex4 and devices/virtex5). You can also run the BrowseDevice class as a test to see if you are able to browse any of the parts that have just been created. You can run this with the following command:
Additional Notes for Mac OS X Installation

The Xilinx tools do not run under Mac OS X and therefore, the installer would have to generate the files on Linux or Windows. However, once the files are created, they could be moved to a Mac OS X installation. To add/modify global environment variables in Mac OS X, one preferred way would be to edit the environment.plist file in the ~/.MacOSX directory. Here is an example of a proper setup for RapidSmith:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>RAPIDSMITH_PATH</key> <string>/Users/[user name]/Documents/workspace/rapidSmith</string> <key>CLASSPATH</key> <string>$CLASSPATH:/Users/[user name]/Documents/workspace/rapidSmith:/Users/[user name]/Documents/workspace/rapidSmith:/Users/[user Copyright 2010-2011 Brigham Young University 4/29/2011 1:25 PM
Page | 12 name]/Documents/workspace/rapidSmith/jars/hessian-4.0.6.jar:/Users/[user name]/Documents/workspace/rapidSmith/jars/qtjambi-4.6.3.jar:/Users/[user name]/Documents/workspace/rapidSmith/jars/qtjambi-macosx-gcc-4.6.3.jar</string> </dict> </plist>
Another difference is that when running programs that use Qt in Java under Mac OS X, the user will need to supply an extra JVM switch, -XstartOnFirstThread
Overview
RapidSmith is organized into several packages (all packages are prefixed with edu.byu.ece.rapidSmith): Package Name bitstreamTools.bitstream Description Represents the packet view of a Xilinx bitstream. It contains classes to represent the header, packets, types, configuration registers and bitstream parsing and export facilities. Contains classes and scripts to test the bitstream package. Provides an FPGA-level view of the configuration data in a bitstream using frames and contains an implementation of the frame address register. This package contains specifications (column layouts) of all supported devices. It also defines different constructs such as block types, block sub types and part library functions. This package provides some examples on how to use the bitstream functionality in RapidSmith. Some support classes for the examples in the previous package. Represents all of the constructs in XDL design files (Instances, Nets, PIPs, Modules, and Designs). This is a GUI interactive explorer that allows the user to navigate through the various constructs in the design (Nets, Instances, Modules and Module Instances). It also has a tile map which allows the user to view the locations of various objects on the FPGA fabric. It also contains an experimental timing report parser to correlate timing information with a design. A JavaCC-based parser for XDL files which populate an instance of the Design class in the design package. This package encompasses all the details of an
4/29/2011 1:25 PM
bitstreamTools.bitstream.test bitstreamTools.configuration
bitstreamTools.configurationSpecification
bitstreamTools.examples bitstreamTools.examples.support design design.explorer
design.parser device
Page | 13
device.browser
device.helper examples gui
placer primitiveDefs
router tests timing
util
FPGA device (part name, tiles, primitive sites, routing resources). All information about Xilinx parts is populated in device from the XDLRC files generated by the xdl executable. This program is an extension of the part tile browser found in the examples package. It allows the user to browse all of the installed parts and also navigate primitive sites as well as routing resources. Some classes to help in the creation of the device files. Some user examples of how to use RapidSmith. This package is used to help build graphical programs in Qt for RapidSmith. It contains useful and common widgets that can be put together easily using the Qt framework. This contains classes to place designs. This is also populated from the XDLRC file. It is specific to a Xilinx family of parts (such as Virtex 4 or Virtex 5). It defines all primitives which are part of a Xilinx family of parts (SLICEL, SLICEM, RAMB16, ). This contains classes to route designs and has a framework to help users of RapidSmith create new routers. This package contains test classes that will exercise various portions of RapidSmith. Currently, this is an experimental TWR parser that will parse timing reports output from Xilinx Trace (trce). This contains miscellaneous support classes and utilities, including the installer.
bitstreamTools.* Package
Please see the chapter on Bitstreams in RapidSmith for details on the bitstream functionality in RapidSmith.
design Package
The design package has all the essential classes necessary to represent all kinds of XDL designs with classes to represent each type of XDL construct. Below in Figures 1, 2, and 3 are some basic illustrations of how the most common XDL constructs map into RapidSmith design classes:
4/29/2011 1:25 PM
Page | 14
# ======================================================= # XDL NCD CONVERSION MODE $Revision: 1.01$ # time: Thu Jun 11 11:48:44 2009 # =======================================================
DESIGN CLASS
String name; String partName; String NCDVersion; ArrayList<Attribute> attributes;
# ======================================================= # The syntax for the design statement is: # design <design_name> <part> <ncd version>; # or # design <design_name> <device> <package> <speed> <ncd_version> # ======================================================= design "top" xc4vfx12ff668-10 v3.2 , cfg " _DESIGN_PROP::BUS_INFO:4:OUTPUT:gpio<3:0> _DESIGN_PROP::PIN_INFO:gpio<0>:/top/PACKED/top/gpio<0>/gpio<0>/PAD:OUTPUT: 3:gpio<3\:0> _DESIGN_PROP::PIN_INFO:gpio<1>:/top/PACKED/top/gpio<1>/gpio<1>/PAD:OUTPUT: 2:gpio<3\:0> _DESIGN_PROP::PIN_INFO:gpio<2>:/top/PACKED/top/gpio<2>/gpio<2>/PAD:OUTPUT: 1:gpio<3\:0> _DESIGN_PROP::PIN_INFO:gpio<3>:/top/PACKED/top/gpio<3>/gpio<3>/PAD:OUTPUT: 0:gpio<3\:0> _DESIGN_PROP::PK_NGMTIMESTAMP:1231972339";
ATTRIBUTE CLASS String physicalName; String logicalName; String value;
# ======================================================= Attribute classes Figure 1 - Design and # The syntax for instances is: # instance <name> <sitedef>, placed <tile> <site>, cfg <string> ; # # ======================================================= or # # The syntax for<name> <sitedef>, unplaced, cfg <string> ; instance instances is: ## instance <name> <sitedef>, placed <tile> <site>, cfg <string> ; # # or For typing convenience you can abbreviate instance to inst. ## instance <name> <sitedef>, unplaced, cfg <string> ; # # For IOs there are two special keywords: bonded and unbonded # # For typing be used to designate whether the instance to inst. IO is that can convenience you can abbreviate PAD of an unplaced # # bonded out. If neither keyword is specified, bonded is assumed. # # For IOs there are two special keywords: bonded and unbonded # # that can be usedplaced IOs is determined by the site unplaced IO is in. The bonding of to designate whether the PAD of an they are placed # # bonded out. If neither keyword is specified, bonded is assumed. # # If you specify bonded or unbonded for an instance that is not an # # The bondingignored. IOB it is of placed IOs is determined by the site they are placed in. ## # # If you specify bonded or unbonded for an instance that is not an Shown below are three examples for IOs. instance IO1 IOB, unplaced ; # This will be bonded # # IOB it is ignored. instance IO1 IOB, unplaced bonded ; # This will be bonded ## instance IO1 IOB, examples for IOs. # # Shown below are three unplaced unbonded ; # This will be unbonded # # ======================================================= bonded instance IO1 IOB, unplaced ; # This will be "DCM_AUTOCALIBRATION_DCM_clock/DCM_clock" "DCM_ADV",placed # inst instance IO1 IOB, unplaced bonded ; # This will be bonded # DCM_BOT_X15Y4 IO1 IOB, unplaced unbonded ; # This will be unbonded instance DCM_ADV_X0Y1 , cfg " BGM_CONFIG_REF_SEL::CLKIN BGM_DIVIDE::16 BGM_LDLY::5 # ======================================================= BGM_MODE::BG_SNAPSHOT BGM_MULTIPLY::16 BGM_SAMPLE_LEN::2 BGM_SDLY::3 BGM_VADJ::5 inst "counter<18>" "SLICEL",placed CLB_X17Y51 SLICE_X27Y103 , BGM_VLDLY::7 cfg " BXINV::#OFF BYINV::#OFF CEINV::#OFF CLKINV::CLK COUTUSED::0 BGM_VSDLY::0 CLKDV_DIVIDE::2.0 CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4 CY0F::0 CY0G::0 CYINIT::CIN DXMUX::XMUX DYMUX::YMUX CLKIN_DIVIDE_BY_2::FALSE _BEL_PROP::F:PK_PACKTHRU: F5USED::#OFF F:counter<18>_rt:#LUT:D=A1CLKOUT_PHASE_SHIFT::FIXED CLK_FEEDBACK::1X CTLGOINV::#OFF CTLMODEINV::#OFF CTLOSC1INV::#OFF CTLOSC2INV::#OFF FFX:counter_18:#FF FFX_INIT_ATTR::INIT0 FFX_SR_ATTR::SRLOW CTLSEL0INV::#OFF FFY_INIT_ATTR::INIT0 FFY_SR_ATTR::SRLOW FFY:counter_19:#FFCTLSEL1INV::#OFF CTLSEL2INV::#OFF DADDR0INV::#OFF DADDR1INV::#OFF DADDR2INV::#OFF DADDR3INV::#OFF DADDR4INV::#OFF FXMUX::FXOR FXUSED::#OFF G:counter<19>_rt:#LUT:D=A1 DADDR5INV::#OFF _BEL_PROP::G:PK_PACKTHRU: GYMUX::GXOR REVUSED::#OFF SRINV::#OFF DADDR6INV::#OFF XBUSED::#OFF XMUXUSED::#OFF XUSED::#OFF SYNC_ATTR::ASYNC DCM_CLKDV_CLKFX_ALIGNMENT::TRUE DCM_EXT_FB_EN::FALSE YBUSED::#OFF YMUXUSED::#OFF YUSED::#OFF DCM_LOCK_HIGH::FALSE CYMUXG:Mcount_counter_cy<19>: CYMUXF:Mcount_counter_cy<18>:DCM_PERFORMANCE_MODE::MAX_SPEED DCM_UNUSED_TAPS_POWERDOWN::TRUE GNDF:ProtoComp1.GNDF.8: GNDG:ProtoComp1.GNDG.8: DCM_VREF_SOURCE::VBG_DLL DCM_VREG_ENABLE::TRUE DENINV::#OFF XORF:Mcount_counter_xor<18>: DESKEW_ADJUST::17 XORG:Mcount_counter_xor<19>: DFS_AVE_FREQ_ADJ_INTERVAL::3 DFS_AVE_FREQ_GAIN::2.0 _INST_PROP::XDL_SHAPE_MEMBER:Shape_0:0,9 " DFS_AVE_FREQ_SAMPLE_INTERVAL::2 DFS_COARSE_SEL::LEGACY DFS_EARLY_LOCK::FALSE DFS_EN_RELRST::TRUE Figure 2 - Instance class DFS_EXTEND_FLUSH_TIME::FALSE DFS_EXTEND_HALT_TIME::FALSE DFS_EXTEND_RUN_TIME::FALSE Copyright DFS_FINE_SEL::LEGACY DFS_FREQUENCY_MODE::LOW DFS_NON_STOP::FALSE 2010-2011 Brigham Young University DFS_OSCILLATOR_MODE::PHASE_FREQ_LOCK DFS_SKIP_FINE::FALSE DFS_TP_SEL::LEVEL DFS_TRACKMODE::1 DI0INV::#OFF DI10INV::#OFF DI11INV::#OFF DI12INV::#OFF DI13INV::#OFF DI14INV::#OFF DI15INV::#OFF DI1INV::#OFF DI2INV::#OFF
DESIGN CLASS
HashMap<String,Instance> instances;
INSTANCE CLASS
String name; PrimitiveType type; PrimitiveSite site; ArrayList<Attribute> attributes;
ATTRIBUTE CLASS String physicalName; String logicalName; String value;
4/29/2011 1:25 PM
Page | 15
# Wire indicates that this a normal wire. # Power indicates that this net is tied to a DC power source. # You can use "power", "vcc" or "vdd" to specify a power net. # # Ground indicates that this net is tied to ground. # You can use "ground", or "gnd" to specify a ground net. # # The <dir> token will be one of the following: # # Symbol Description # ====== ========================================== # == Bidirectional, unbuffered. # => Bidirectional, buffered in one direction. # =Bidirectional, buffered in both directions. # -> Directional, buffered. # # No pips exist for unrouted nets. # ================================================ net "GLOBAL_LOGIC0_11" gnd, outpin "XDL_DUMMY_INT_X33Y26_TIEOFF_X33Y26" HARD0 , inpin "FFT_F/U_CNTRL/Madd_ADDRF_addsub0000_cy<1>" BX , pip CLB_X33Y26 BYP_INT_B5_INT -> BX_PINWIRE1 , pip INT_X33Y26 BOUNCE3 -> BYP_INT_B5 , pip INT_X33Y26 GND_WIRE -> BOUNCE3 , ;
DESIGN CLASS
HashMap<String,Instance> instances;
NET CLASS
String name; NetType type; ArrayList<Pin> pins;
PIN CLASS
boolean isOutputPin; Instance instance; String pinName; ArrayList<PIP> pips;
PIP CLASS
Tile tile; int startWire; Int endWire;
Figure 3 - Net, Pin and PIP Classes
There are other classes such as Module and ModuleInstance classes that abstract the macro-like property of XDL which will be explained later. There are also enumeration classes such as InstanceType which are an exhaustive list of all primitive types found in XDL and NetType which determines if a net is a WIRE, GND, or VCC.
design.explorer Package
The design explorer loads XDL design files and allows the user a GUI interface to the design members (Instances, Nets, Modules and Module Instances) with hyperlinks to the various other sites, tiles, modules and instances. Currently the design explorer is read only although there is potential for it to be able to modify designs. Below is a screenshot from the design explorer.
4/29/2011 1:25 PM
Page | 16
Figure 4 - Hyperlinks in Design Explorer
Recently, a timing report parser has been added which allows the timing information for a particular design to be loaded at the same time as a design. This can be done through the file menu or through the tool bar with a folder/clock icon. This timing report parser is still experimental and so mixed results may result depending on the type of timing report and the device used.
4/29/2011 1:25 PM
Page | 17
Figure 5 - Timing report loaded in Design Explorer
design.parser Package
The XDL parser parses xdl design or hard macro files and populates the Design class accordingly. The parser is a custom parser (previously a JavaCC parser was used but was ultimately abandoned) written exclusively for RapidSmith.
device Package
This package works closely with the design package in that the specific Device class is loaded when a design is loaded. The Xilinx XDLRC part descriptions partition the FPGA into a 2D grid of tiles. Each tile contains some mixture of primitive sites, wires and PIPs (Programmable Interconnect Points). Primitive sites are resource locations where XDL inst or instances of primitives are allowed to reside. Wires and PIPs provide wiring and routing resources information to connect the primitive instances together to form a complete design. With this information provided by Xilinx and leveraged by RapidSmith a number of different placement and routing algorithms can be constructed by leveraging the APIs in this package. The device package also contains a class called WireEnumerator. All of the wires in a family are enumerated to an integer so they do not need to be stored as Strings. The WireEnumerator class helps translates wires from integers to Strings and vice versa. It also keeps track of important information about wires such as the type of wire (DOUBLE, HEX, PENT, ) and wire direction (NORTH, SOUTH, EAST, ) among other attributes.
Page | 18
device.browser Package
The device browser application allows the user to see a color coded tile array that allows them to browse any installed device. The primitive and wire lists are populated by double clicking a tile. The user can zoom in and out using the mouse wheel and can also pan by holding down the right mouse button while moving the mouse. See below for a screenshot of the application.
Figure 6 - Device Browser screenshot
The device browser also allows the user to follow the various connections found in the FPGA. By double clicking a wire in the wire list, the application will draw the connection on the tile array (as shown in the screenshot below). By hovering the mouse pointer over the connection, the wire becomes red and a tooltip will appear describing the connection made by declaring the source tile and wire followed by an arrow (->) and the destination tile and wire. By clicking on the wire, the application will redraw all the connections that can be made from the currently selected wire. By repeating this action, the user can follow connections and discover how the FPGA interconnect is laid out.
4/29/2011 1:25 PM
Page | 19
Figure 7 - Device browser screenshot showing wire connections
device.helper Package
This package contains special classes to help pack the device files smaller. They are generally used only during installation.
examples Package
This package contains some examples of how to get started with RapidSmith and some different ways of using the various APIs available.
placer Package
This package still has yet to be completed but will have an example of a placer.
primitiveDefs Package
In the XDLRC descriptions produced by the Xilinx xdl executable, each copy has a section at the end called primitive_defs which has a list of primitive definitions for all types of primitives found in the part. The primitiveDefs packages makes that information available in a convenient data structure to access the attributes and various parameters the primitives can be configured with.
Page | 20
router Package
This package has an example of a basic router that routes Virtex 4 and Virtex 5 designs. It also contains an abstract class for which routers can be built upon.
tests Package
In order to help ensure correct functionality in RapidSmith as it grows, a tests package has been added to hold all of the different tests that can be performed to check for correct functionality with each new update. Currently, this package contains a class for testing the device, primitive defs and wire enumerator files (it is the class used to create the statistical information on RapidSmith files found in the Appendix).
timing Package
A new experimental package that contains a timing report parser (TWR files output from Xilinx Trace) has been added. This can parse a TWR file into a basic data structure contained in the timing package. This parser has been integrated into the design explorer application in RapidSmith.
util Package
This has miscellaneous classes used for support of all other packages. It is suggested to have the user browse the JavaDoc API descriptions to get a better feel for what is contained in the util package.
Examples
Hello World
To get started programming with RapidSmith, here is an example of a very simple program.
/* * Copyright (c) 2010 Brigham Young University * * This file is part of the BYU RapidSmith Tools. * * BYU RapidSmith Tools is free software: you may redistribute it * and/or modify it under the terms of the GNU General Public License * as published by the Free Software Foundation, either version 2 of * the License, or (at your option) any later version. * * BYU RapidSmith Tools is distributed in the hope that it will be * useful, but WITHOUT ANY WARRANTY; without even the implied warranty * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * A copy of the GNU General Public License is included with the BYU * RapidSmith Tools. It can be found at doc/gpl2.txt. You may also * get a copy of the license at <http://www.gnu.org/licenses/>. * */ package edu.byu.ece.rapidSmith.examples; import java.util.HashMap; import edu.byu.ece.rapidSmith.design.*; import edu.byu.ece.rapidSmith.device.*; /** * A simple class to illustrate how to use some of the basic methods in RapidSmith. * @author Chris Lavin */ public class HelloWorld{ public static void main(String[] args){ // Create a new Design from scratch rather than load an existing design
4/29/2011 1:25 PM
Page | 21
Design design = new Design(); // Set its name design.setName("helloWorld"); // When we set the part name, it loads the corresponding Device and // WireEnumerator. Always include package and speed grade with the part name. design.setPartName("xc4vfx12ff668-10"); // Create a new instance Instance myInstance = new Instance(); myInstance.setName("Bob"); myInstance.setType(PrimitiveType.SLICEL); // We need to add the instance to the design so it knows about it design.addInstance(myInstance); // Make the F LUT an Inverter Gate myInstance.addAttribute(new Attribute("F","LUT_of_Bob","#LUT:D=~A1")); // Add the instance to the design design.addInstance(myInstance); // This is how we can get the reference to the instance from the design, // by name Instance bob = design.getInstance("Bob"); // Let's find a primitive site for our instance Bob HashMap<String, PrimitiveSite> primitiveSites = design.getDevice().getPrimitiveSites(); for(PrimitiveSite site : primitiveSites.values()){ // Some primitive sites can have more than one type reside at the site, such as // SLICEM sites which can also have SLICELs placed there. Checking if the site // is compatible makes sure you get the best possible chance of finding a place // for bob to live. if(site.isCompatiblePrimitiveType(bob.getType())){ // Let's also make sure we don't place bob on a site that is already used if(!design.isPrimitiveSiteUsed(site)){ bob.place(site); System.out.println("We placed bob on tile: " + bob.getTile() + " and site: " + bob.getPrimitiveSiteName()); break; } } } // Another way to find valid primitive sites if we want to use an exclusive site type PrimitiveSite[] allSitesOfTypeSLICEL = design.getDevice().getAllSitesOfType(bob.getType()); for(PrimitiveSite site : allSitesOfTypeSLICEL){ // Let's also make sure we don't place bob on a site that is already used if(!design.isPrimitiveSiteUsed(site)){ bob.place(site); System.out.println("We placed bob on tile: " + bob.getTile() + " and site: " + bob.getPrimitiveSiteName()); break; } } // Let's create an IOB to drive our Inverter gate in Bob's LUT Instance myIOB = new Instance(); myIOB.setName("input"); myIOB.setType(PrimitiveType.IOB); design.addInstance(myIOB); // These are typical attributes that need to be set to configure the IOB // the way you like it myIOB.addAttribute(new Attribute("INBUFUSED","","0")); myIOB.addAttribute(new Attribute("IOATTRBOX","","LVCMOS25")); // Another way to find a primitive site is by name, this is the pin name
4/29/2011 1:25 PM
Page | 22
// that you might find in a UCF file myIOB.place(design.getDevice().getPrimitiveSite("C17")); // Let's also create a new net to connect the two pins Net fred = new Net(); // Be sure to add fred to the design design.addNet(fred); fred.setName("fred"); // All nets are normally of type WIRE, however, some are also GND and VCC fred.setType(NetType.WIRE); // Add the IOB pin as an output pin or the source of the net fred.addPin(new Pin(true,"I",myIOB)); // Add Bob as the input pin or sink, which is the input to the inverter fred.addPin(new Pin(false, "F1", bob)); // Now let's write out our new design // We'll print the standard XDL comments out String fileName = design.getName() +".xdl"; design.saveXDLFile(fileName, true); // We can load XDL files the same way. Design inputFromFile = new Design(); inputFromFile.loadXDLFile(fileName); // Hello World System.out.println(inputFromFile.getName()); } }
Hand Router
This is a command-line-based router than allows a user to route one net at a time and write out the design changes afterwards. Although not particularly useful as a router, it illustrates how RapidSmith could be used to build a router.
Part Tile Browser

This GUI will let you browse Virtex 4 and 5 parts at the tile level. On the left, the user may choose the desired part by navigating the tree menu and double-clicking on the desired part name. This will load the part in the viewer pane on the right (the first available part is loaded at startup). The status bar in the bottom left displays which part is currently loaded. Also displayed is the name of the current tile which the mouse is over, highlighted by a yellow outline in the viewer pane. The user may navigate inside the viewer pane by using the mouse. By right-clicking and dragging the cursor, the user may pan. By using the scroll-wheel on the mouse, the user may zoom. If a scroll-wheel is unavailable, the user may zoom by clicking inside the viewer pane and pressing the minus(-) key to zoom out or the equals(=) key to zoom in. See below for a screenshot.
4/29/2011 1:25 PM
Page | 23
Figure 8: Screenshot of Part Tile Browser
4/29/2011 1:25 PM
Page | 24
UNDERSTANDING XDL
What is XDL?
XDL (or Xilinx Design Language, see ISE 6.1 documentation in help/data/xdl folder) is a humanreadable ASCII format compatible with the more widely used Xilinx format NCD (or Netlist Circuit Description). XDL has most if not all the same capabilities of the NCD format and Xilinx provides an executable called xdl which can convert NCD designs to XDL and vice versa (run xdl h for details). XDL and NCD are both native Xilinx netlist formats for describing and representing Xilinx FPGA designs. XDL is the interface used by RapidSmith to insert and extract design information at different points in the Xilinx design flow. XDL can represent designs that are: Mapped (unplaced and unrouted) Partially placed and unrouted Partially placed and partially routed Fully placed and unrouted Fully placed and partially routed Fully placed and fully routed Contain hard macros and instances of hard macros A hard macro definition (equivalent to Xilinx NMC files)
Xilinx
Xilinx
.NCD
Xilinx
.NCD
map
par r
(place only)
par p
(route only)
.NCD
Xilinx
bitgen
.BIT
Xilinx
Xilinx
Xilinx
xdl
.XDL
xdl
.XDL
xdl
.XDL
BYU
RapidSmith Tools
Figure 9: Block diagram of where XDL fits in CAD flow.
RapidSmith provides some Java methods that can perform the XDL/NCD conversion (by calling the xdl executable) from within Java in the util.FileConverter class. It also has methods for calling a number of Xilinx programs from within the RapidSmith environment.
Page | 25
The Xilinx xdl executable also contains options for generating report files (with extension .XDLRC) which contain descriptive information about a particular Xilinx part. XDLRC report files have a different format to that of XDL (as they describe an FPGA rather than a design) and depending on the options given can create enormous files (several gigabytes) of text but are quite complete in describing the primitive sites, routing resources and tile layout of a Xilinx FPGA. RapidSmith makes uses of these XDLRC files by generating them and parsing them into much smaller device files that can them be used with the rest of the RapidSmith API. DISCLAIMER: The user must be aware that XDL is an externally unsupported format by Xilinx. All questions about XDL and any problems associated with XDL or this tool should NOT be addressed to Xilinx, but through the RapidSmith website and forum. The RapidSmith project is merely a tool to make use of the XDL software technical interface and cannot be used without a valid and current license for the Xilinx ISE tools. The RapidSmith project is at the mercy of Xilinx in the availability of XDL and will attempt to accommodate updates and changes to the interface as they arise.
Basic Syntax of XDL Files

XDL is a self-documenting file format in that each type of statement is generally preceded by comments that explain the syntax. Comments in XDL are denoted by using a # character at the beginning of a line. The # is also used in other constructs that are part of the language that do not fall on the beginning character of the line. In XDL there are four basic statements that make up the entire content of the file and description of the circuit.
Design Statement
The design statement (represented as the design.Design class) is included in every XDL file (even hard macros) and there is only one design statement in a file. It includes global information such as the design name and part name of the targeted FPGA. It can also contain a list of attributes in a cfg string. Below is an example of a design statement.
# ======================================================= # The syntax for the design statement is: # design <design_name> <part> <ncd version>; # or # design <design_name> <device> <package> <speed> <ncd_version> # ======================================================= design "designName" xc4vfx12ff668-10 v3.2 , cfg " _DESIGN_PROP::BUS_INFO:4:OUTPUT:gpio<3:0> _DESIGN_PROP::PIN_INFO:gpio<0>:/top/PACKED/top/gpio<0>/PAD:OUTPUT:3:gpio<3\:0> _DESIGN_PROP::PIN_INFO:gpio<1>:/top/PACKED/top/gpio<1>/PAD:OUTPUT:2:gpio<3\:0> _DESIGN_PROP::PIN_INFO:gpio<2>:/top/PACKED/top/gpio<2>/PAD:OUTPUT:1:gpio<3\:0> _DESIGN_PROP::PIN_INFO:gpio<3>:/top/PACKED/top/gpio<3>/PAD:OUTPUT:0:gpio<3\:0> _DESIGN_PROP::PK_NGMTIMESTAMP:1231972339";
Module Statement
Modules (represented as the design.Module class) are collections of instances and nets which can be described as hard macros if the instances are placed and nets are routed. A module will have a list of ports that determine the interface of the hard macro or module and each module will have its own list of instances and nets to describe the logic inside. An abbreviated module statement is shown below.
4/29/2011 1:25 PM
Page | 26 # ======================================================= # The syntax for modules is: # module <name> <inst_name> ; # port <name> <inst_name> <inst_pin> ; # . # instance ... ; # . # net ... ; # . # endmodule <name> ; # ======================================================= module "moduleName" "anchorInstanceName" , cfg "_SYSTEM_MACRO::FALSE" ; port "portName1" "anchorInstanceName" "F2"; port "portName2" "anotherInstanceInTheModule" "F4"; ... inst "anchorInstanceName" "SLICEL", placed CLB_X14Y4 SLICE_X23Y8 , ... net "aNetInsideTheModule" , ... endmodule "moduleName";
Instance Statement
The instance statement (represented as the design.Instance class), which begins with the keyword inst, is an instance of an FPGA primitive which can be placed or unplaced depending if a tile and primitive site location are specified. The instance also has a primitive type (such as SLICEL, SLICEM, DCM_ADV, ). Instance names should be unique in a design to avoid problems in RapidSmith. Instances are configured with a cfg string which is a list of attributes that define LUT content, and other functionality. An example of an instance statement is shown below.
inst "instanceName" "SLICEL",placed CLB_X14Y4 SLICE_X23Y8 , cfg " BXINV::#OFF BYINV::#OFF CEINV::#OFF CLKINV::#OFF COUTUSED::#OFF CY0F::#OFF CY0G::#OFF CYINIT::#OFF DXMUX::#OFF DYMUX::#OFF F::#OFF F5USED::#OFF FFX::#OFF FFX_INIT_ATTR::#OFF FFX_SR_ATTR::#OFF FFY::#OFF FFY_INIT_ATTR::#OFF FFY_SR_ATTR::#OFF FXMUX::#OFF FXUSED::#OFF G:DCM_AUTOCALIBRATION_DCM_clock/DCM_clock/md/RSTOUT1:#LUT:D=A1 _BEL_PROP::G:LIT_NON_USER_LOGIC:DCM_STANDBY GYMUX::#OFF REVUSED::#OFF SRINV::#OFF SYNC_ATTR::#OFF XBUSED::#OFF XMUXUSED::#OFF XUSED::#OFF YBUSED::#OFF YMUXUSED::#OFF YUSED::0 " ;
Net Statement
The net statement (represented as the design.Net class) are the nets that describe inputs/outputs and routing of nets in a design. Nets can be of 3 different types: GND, VCC, or WIRE. The GND and VCC keyword must be present to mark a net as being sourced by ground or power, the keyword WIRE is not required as it is the default type. Nets also must have a unique name when compared with all other nets. Nets have two sub components to describe them: pins and PIPs. An example of a net statement is shown below. Pins (represented as the design.Pin class) define the source and one or more sinks within the net. A pin is uniquely identified by the name of the instance where the pin resides as well as the internal name of the pin on this instance. It also has a direction of being an outpin (source) or an inpin (sink). A net can only have one source or outpin in the net.
4/29/2011 1:25 PM
Page | 27 net "netName" , outpin "instanceNameOfSourcePin" Y , inpin "instanceNameOfSinkPin" RST , pip CLB_X14Y4 Y_PINWIRE1 -> BEST_LOGIC_OUTS5_INT , pip DCM_BOT_X15Y4 SR_B0_INT3 -> DCM_ADV_RST , pip INT_X14Y4 BEST_LOGIC_OUTS5 -> OMUX8 , pip INT_X15Y5 OMUX_EN8 -> N2BEG0 , pip INT_X15Y7 N2END0 -> SR_B0 , ;
PIPs (programmable interconnect points, represented by the design.PIP class) define routing resources used within the net to complete routing connections between the source and sinks. A PIP is uniquely described as existing in a tile (ex: INT_X2Y3) and two wires with a connection between them. Almost all PIPs are unidirectional (->) in that they can only go in one direction. Long lines are the one exception to that rule as they are bidirectional and are denoted by using a -= symbol, however RapidSmith uses the -> symbol for all PIPs as this does not cause the xdl converter any problems.
Basic Syntax of XDLRC Files

XDLRC files are report files generated by the Xilinx xdl executable. During installation, RapidSmith will create XDLRC files and parse them for their pertinent information and then pack it into small device files that can be used later with the tool. Each construct found in XDLRC files and the corresponding RapidSmith representation is described in the remainder of this subsection.
Tiles
# Example of an XDLRC tile declaration (tile 1 14 CLB_X6Y63 CLB 4 (tile_summary CLB_X6Y63 CLB 122 403 148) ) Tiles (represented in the device.Tile class) are the building blocks of Xilinx FPGAs. Every FPGA is described as 2D array or grid of tiles laid out like a checker board (this can be seen also in the Part Tile Browser example). Each tile is declared with a (tile directive as shown above followed by the unique row and column index of where the tile fits into the grid of tiles found on the FPGA. The tile declaration also contains a name followed by a type with the final number being the number of primitive sites found within the tile. The tile ends with a tile_summary statement repeating the name and type with some other numbered statistics. Tiles can contain three different sub components, primitive sites, wires, and PIPs.
Primitive Sites
# Example of an XDLRC primitive site declaration (primitive_site SLICE_X9Y127 SLICEL internal 27 (pinwire BX input BX_PINWIRE3) (pinwire BY input BY_PINWIRE3) (pinwire CE input CE_PINWIRE3) (pinwire XMUX output XMUX_PINWIRE3) )
4/29/2011 1:25 PM
Page | 28
Primitive sites (represented in the device.PrimitiveSite class) are declared in tiles. A primitive site is a location on the FPGA that allows for an instance of that primitive type (primitive types are enumerated in the device.PrimitiveType enum) to reside. For example, in the declaration of a SLICEL primitive site above, any SLICEL instance can be placed at that site. A primitive site has a unique name (SLICE_X9Y127) and type (SLICEL). However, in some cases, more than one primitive type is compatible with a given primitive site. One example of this is the primitive type SLICEM (Virtex 4 slices that contain RAM functionality in the LUT among other enhancements to the SLICEL type) is a superset of SLICEL functionality. Therefore, a SLICEL primitive instance can be placed in a SLICEM primitive site. RapidSmith allows the developer to determine if a given site is compatible in the device.PrimtiveSite class using the method isCompatiblePrimitiveType(PrimitiveType otherType). Primitive site declarations in XDLRC also contain a list of pinwires which describe the name and direction of pins on the primitive site. The first pinwire declared in the example above is the BX input pin which is the internal name to the SLICEL primitive site. Pinwires have an external name as well to differentiate the multiple primitive sites that may be present in the same tile. In this case, BX of SLICE_X9Y127 has the external name BX_PINWIRE3. RapidSmith provides mechanisms to translate between these two names in the device.PrimitiveSite class with the method getExternalPinName(String internalName).
Wire
# Example of an XDLRC wire declaration (wire E2BEG0 5 (conn CLB_X7Y63 CLB_E2BEG0) (conn INT_X8Y63 E2MID0) (conn CLB_X8Y63 CLB_E2MID0) (conn INT_X9Y63 E2END0) (conn INT_X9Y62 E2END_S0) ) A wire as declared in XDLRC is a routing resource that exists in the tile that may have zero or more connections leaving the tile. In the example above, the wire E2BEG0 connected to 5 other neighboring tiles. These connections (denoted by conn) are described using the unique tile name and wire name of that tile to denote connectivity. These connections are not programmable, but hard wired into the FPGA. Inter-tile connections are not programmable, however, intra-tile connections (PIPs, see below) are. RapidSmith must represent the routing resources of Xilinx FPGAs very carefully as a significant fraction of the FPGA description is routing. Therefore, the wire names (such as E2BEG0, ) are enumerated into integers or Java primitive int data types using the device.WireEnumerator class. The WireEnumerator class keeps track of what integer value goes with each wire name and allows for significant compaction of the FPGA routing description. The wire connections are described using a relative tile offset to reuse data structure elements. The class used to represent these wires and corresponding connections is in the device.WireConnection class.
PIP
# Example of an XDLRC PIP declaration (pip INT_X7Y63 BEST_LOGIC_OUTS0 -> BYP_INT_B5) A PIP (programmable interconnect point) is a possible connection that can be made between two wires. In the example above the PIP is declared in the tile and repeats the tile name for reference. It specifies two wires by name that both exist in that same tile (BEST_LOGIC_OUTS0 and BYP_INT_B5) and declares that the wire BEST_LOGIC_OUTS0 can drive the wire BYP_INT_B5 if the PIP exists in a nets PIP list in a given design.
Page | 29
A collection of these PIPs in a net define how a net is routed and is consistent with saying that those PIPs are turned on. The connections are also represented in the device.WireConnection class as connections with a special flag denoting the connection as a PIP.
Primitive Definitions
At the end of every XDLRC file (regardless of verboseness) is a list of all primitive definitions for the Xilinx part. Primitive definitions are used mainly for reference and are reflected in the primitiveDefs.* package. In more recent Xilinx parts, some of the primitive definitions have been found to lack some information which may require special handling in RapidSmith. Currently, the primitive definitions are not widely used in RapidSmith.
4/29/2011 1:25 PM
Page | 30
RAPIDSMITH STRUCTURE
This section details much of the complexity and theory behind the structure of RapidSmith. There are two main abstractions that developers need to be aware of; that of the device and design. A hierarchy of classes within RapidSmith can be seen in Figure 6 below.
Design Instance PrimitiveType Attribute (List) PrimitiveSite Net NetType Pin (List) PIP (List) Module Port (List) Instance (List) Net (List) ModuleInstance Instance (List) Net (List) TileType
Device
Tile (2D Array) PrimitiveSite (Array) Wire
PrimitiveType
Tile
(a)
(b)
Figure 10: (a) The classes involved in defining a design in RapidSmith, (b) The major classes involved representing a device.
A RapidSmith Design
Designs in RapidSmith are represented and stored in the data structures found in the design package. The classes found in this package closely follow the constructs found in XDL design files to make the classes easier to follow and make the abstraction understandable to those who are familiar with XDL. For those who have less experience with XDL, see the previous section on understanding XDL.
Loading Designs
There is typically only one way to load a design with RapidSmith and that is to create a new design and call the method loadXDLDesign(String fileName) on that instance of the design. An NCD file can also be loaded indirectly by using methods in the util.FileConverter class which enables the conversion of an existing NCD file to XDL by calling the Xilinx xdl executable. Example code of how this could be done is shown below:
// Loading an XDL design Design myDesign = new Design(); myDesign.loadXDLFile("myDesign.xdl"); // Loading an existing NCD file by converting it to XDL String ncdFileName = "myOtherDesign.ncd"; String xdlFileName = FileConverter.convertNCD2XDL(ncdFileName); if(xdlFileName == null){ MessageGenerator.briefErrorAndExit("ERROR: Conversion of " + ncdFileName + " to XDL failed."); } Design otherDesign = new Design(); otherDesign.loadXDLFile(xdlFileName); Copyright 2010-2011 Brigham Young University 4/29/2011 1:25 PM
Page | 31
When loading a design, one must be conscious of everything that gets loaded. In RapidSmith, a JavaCC-based XDL parser (found in the design.parser package) reads and parses the given XDL file and populates the instance of the Design class respectively. When the parser populates the design with the design part name, it causes the corresponding device file of the Xilinx part as well as the wire enumerator to be loaded and populates the design. This is done be default because the primitive sites and wires in the design reference those same resources in the device class.
Saving Designs
RapidSmith also has a method to save designs in the XDL format similar to the method for loading them. In a similar manner, the saved XDL file can be converted to NCD using the FileConverter class. Very little error checking is made when loading and saving XDL designs, but a good test would be the conversion to NCD as Xilinx runs several DRCs when the design is converted.
A RapidSmith Device
A device is defined in RapidSmith as a unique Xilinx FPGA part that includes package information but not speed grade (such as xc4vfx12ff668). Each device contains specific information concerning its primitive sites, tiles, wires, IOBs, and PIPs that are available to realize designs. This information is made available through the Xilinx executable xdl in -report mode. See the previous section on XDLRC for more details on these device resources.
Device
During the initial setup of RapidSmith, the Installer creates fully verbose XDLRC files ($xdl report pips all_conns <partName>) for each device specified as command line parameters. After the creation of each XDLRC file, they are parsed, compacted by the Installer, and a device file is generated for later use. These device files are placed in $(RAPIDSMITH_PATH)/devices/familyName/partName_db.dat and then the corresponding XDLRC file is deleted as they can be several gigabytes in size. These device files make accessing device information about a specific FPGA part much more convenient than a gigantic text file. Most of the device files are just a few megabytes or less and can be loaded in a few seconds or less. RapidSmith uses a custom form of serialization as well as a compression library to make sure the device files are small and load quickly.
Wire Enumerator
In order to make the device files small, each uniquely named wire is assigned to an integer as enumeration. This avoids moving strings around in memory which would be costly in terms of space and comparison times. RapidSmith has a class called WireEnumerator which enumerates all uniquely named wires in an FPGA family and has methods to convert to and from the wire name and enumeration or enum for short. It also stores information about each wire such as a direction or type which can be useful in building a router. Note that wires with the same name can occur several times within a device and they are uniquely identified not only by their name, but also by the tile in which they are present. In order to create the wire enumeration files, a subset of XDLRC files must be parsed so that a complete set of wires can be enumerated. This is automatically done by the installer and the files are placed in $(RAPIDSMITH_PATH)/devices/familyName/wireEnumerator.dat. Only one wire enumerator is needed per FPGA family.
4/29/2011 1:25 PM
Page | 32
Memory and Performance

Although Java typically has a reputation for being slow and a memory hog, RapidSmith has been able to create a very good device representation that is compact and fast loading, even for some of the largest parts offered by Xilinx. A summary of some performance and memory footprint figures are shown in the tables below for selected parts. These results were taken a Windows 7 Enterprise 64-bit OS with an Intel Core i7 860 running at 2.8GHz. The test machine had 8 GB of DDR3 memory, a conventional 1 TB SATA hard drive and was using version 0.5.0 of RapidSmith and the 32-bit Oracle JVM version 1.6.0_22. Note that the Device and WireEnumerator classes are both required before loading any design in RapidSmith. For a more extensive list of performance figures of all RapidSmith-compatible devices, see the Appendix.
Device Performance and Memory Usage

Family Name VIRTEX 4 VIRTEX 4 VIRTEX 4 VIRTEX 5 VIRTEX 5 VIRTEX 5 VIRTEX 5 VIRTEX 6 VIRTEX 6 VIRTEX 6 VIRTEX 7 VIRTEX 7 VIRTEX 7 Part Name SX55 FX140 LX200 FX200T TX240T SX240T LX330 CX240T SX475T LX760 855T 1500T 2000T XDLRC Report Size 3.5GB 8.0GB 10.0GB 9.4GB 10.0GB 11.9GB 12.5GB 8.5GB 17.7GB 22.8GB 32.0GB 53.0GB 73.6GB File Size 539KB 1546KB 1010KB 1227KB 1111KB 1135KB 1069KB 937KB 1506KB 1758KB 2634KB 4985KB 5956KB Java Heap Size 34MB 70MB 61MB 60MB 56MB 61MB 69MB 35MB 61MB 77MB 115MB 263MB 301MB Load Time from Disk 0.299s 0.616s 0.602s 0.585s 0.620s 0.630s 0.622s 0.460s 0.814s 1.068s 1.408s 2.653s 3.339s
Wire Enumerator Size and Performance

Family Name VIRTEX4 VIRTEX5 VIRTEX6 VIRTEX7 Heap Memory Footprint 233KB 264KB 171KB 200KB File Size on Disk 8.1MB 9.9MB 6.3MB 7.4MB Load Time from Disk 0.100s 0.111s 0.079s 0.096s
4/29/2011 1:25 PM
Page | 33
PLACEMENT IN RAPIDSMITH
This chapter is intended to help users of RapidSmith understand how placement works in RapidSmith and in XDL.
Primitive Resources in RapidSmith

RapidSmith uses the XDLRC primitive definitions and sites declared to help create a map of useable places where objects may be placed. In order to understand placement in RapidSmith, lets review the following: primitive sites, primitive definitions and types, and primitive instances.
Primitive Site
A primitive site is an actual physical location in an FPGA. Lets take a look at a typical primitive_site declaration found in an XDLRC report for a Virtex 4:
(primitive_site SLICE_X1Y121 SLICEL internal 27 (pinwire BX input BX_PINWIRE1) (pinwire BY input BY_PINWIRE1) (pinwire CE input CE_PINWIRE1) (pinwire CIN input CIN1) (pinwire CLK input CLK_PINWIRE1) (pinwire SR input SR_PINWIRE1) (pinwire F1 input F1_PINWIRE1) (pinwire F2 input F2_PINWIRE1) (pinwire F3 input F3_PINWIRE1) (pinwire F4 input F4_PINWIRE1) (pinwire G1 input G1_PINWIRE1) (pinwire G2 input G2_PINWIRE1) (pinwire G3 input G3_PINWIRE1) (pinwire G4 input G4_PINWIRE1) (pinwire FXINA input FXINA1) (pinwire FXINB input FXINB1) (pinwire F5 output F51) (pinwire FX output FX1) (pinwire X output X_PINWIRE1) (pinwire XB output XB_PINWIRE1) (pinwire XQ output XQ_PINWIRE1) (pinwire Y output Y_PINWIRE1) (pinwire YB output YB_PINWIRE1) (pinwire YQ output YQ_PINWIRE1) (pinwire COUT output COUT1) (pinwire YMUX output YMUX_PINWIRE1) (pinwire XMUX output XMUX_PINWIRE1) )
This declaration is found inside of a tile declaration in XDLRC reports which denotes where the primitive site is located on the FPGA. Every primitive site belongs to a tile. If you open the Virtex 4 FX12 part in the Device Browser, you could find the primitive site SLICE_X1Y121 as shown in the screenshot below. You would find that it belongs to the tile CLB_X1Y60.
4/29/2011 1:25 PM
Page | 34
Figure 11 Device Browser screenshot showing site SLICE_X1Y121 in tile CLB_X1Y60
Primitive sites all have a unique name (SLICE_X1Y121 in this example) to uniquely identify each one. Although the XY coordinates in the name help reference their location, they are not found in all primitive site names (IOBM/IOBS sites being a common example). Each site also has a type associated with it. RapidSmith enumerates all of the primitive types in the device.PrimitiveType enum.
Primitive Definitions and Types

Each Xilinx FPGA family has a list of primitive definitions which appear at the end of every XDLRC report in the primitive_defs declaration. A list of primitive_def declarations are contained in this declaration, each detailing the inputs, outputs, elements, and configurations of each primitive. Theses definitions are stored in the primitiveDefs package found in RapidSmith and are easily accessible using the data structures created. The names of each of the primitive definitions are called primitive types in RapidSmith. The PrimitiveType enum found in the device package contains all of the primitive types found in every Xilinx FPGA family supported in RapidSmith (see Appendix C for a complete list).
Primitive Instances
A primitive instance (or instance for short) is an actual instantiation of a primitive definition and is the same instance as declared in XDL inst constructs. These instances are represented in the design package using the Instance class. Each instance has a unique name and primitive type associated with it and can be placed or unplaced in an XDL design. When an instance is unplaced, it will have the keyword unplaced in its declaration. When an instance is placed, it will have the keyword placed followed by a tile name and a primitive site name (such as CLB_X1Y60 SLICE_X1Y121). An example of the first part of an instance declaration is shown below:
inst "instanceName" "SLICEL",placed CLB_X1Y60 SLICE_X1Y121 , Copyright 2010-2011 Brigham Young University 4/29/2011 1:25 PM
Page | 35
Placement
Placement occurs by assigning an instance to a specific primitive site on the FPGA. Generally, an instance of type X can only be placed on a primitive site of type X. However, there are some exceptions where type X can actually be placed onto more than just the primitive site of the same type. A common example in modern devices is that a SLICEL instance can be placed on either a SLICEL primitive site or a SLICEM primitive site. There are actually several scenarios where this exception occurs. Sometimes, a primitive site of the same type never occurs on the FPGA fabric such as an IOB primitive type. IOB primitives must be placed on either an IOBM or IOBS primitive site. In order to help avoid the special cases in placement with different primitive types, RapidSmith includes all of the legal placement types in the PrimitiveSite class and they can be accessed with the following methods:
/** * This method will check if the PrimitiveType otherType can be placed * at this primitive site. Most often only if they are * equal can this be true. However there are a few special cases that require * extra handling. For example a SLICEL can reside in a SLICEM site but not * vice versa. * @param otherType The primitive type to try to place on this site. * @return True if otherType can be placed at this primitive site, false otherwise. */ public boolean isCompatiblePrimitiveType(PrimitiveType otherType); /** * This method gets the type of otherSite and calls the other method * public boolean isCompatiblePrimitiveType(PrimitiveType otherType); * See that method for more information. * @param otherSite The other site to see if its type is compatible with this site. * @return True if compatible, false otherwise. */ public boolean isCompatiblePrimitiveType(PrimitiveSite otherSite);
Placement Techniques
Currently RapidSmith only has a very limited random placer which is found in the placer package.
4/29/2011 1:25 PM
Page | 36
ROUTING IN RAPIDSMITH
This chapter is intended to help users and developers in understanding how routing resources are handled in RapidSmith. It also illustrates how to build on the existing classes to create custom routers.
Wire Resources in RapidSmith

RapidSmith has a unique way of representing wires and connections for Xilinx devices. This approach was developed mainly to minimize disk and memory usage while also maintaining some level of efficiency and speed.
Wire Representation
The wire enumerator class keeps a list of all uniquely XDLRC-named wires that exist in a given Xilinx FPGA family. Wires can span multiple tiles in the FPGA, however, the wire has a separate name for each tile in which it crosses. An example of this concept is illustrated in the DOUBLE lines found in several family architectures. A DOUBLE line is a wire that connects switch boxes either one or two hops away in a given direction. An example of this layout is given in Figure 7.
INT_X1Y1
CLB_X1Y1
INT_X2Y1
CLB_X2Y1
INT_X3Y1
E2BEG4
CLB_E2BEG4
E2MID4
CLB_E2MID4
E2END4
Figure 12 - A DOUBLE line in an FPGA illustrating how each part of the wire has a different name depending on the tile it is located in.
In this example, we see a wire that can be driven by one point, E2BEG4, and can drive either E2MID4 in tile INT_X2Y1 and/or E2END4 in tile INT_X3Y1. However, the wire is assigned a name as it travels through the CLB tiles (CLB_E2BEG4 and CLB_E2MID4). For the purposes of RapidSmith, these wires have been removed from device files as they do not contribute to the overall possible connections a wire can make and simply add overhead to the device data structures. This technique has actually dramatically reduced the size of the devices files and improved routing speed as dead-end connections do not need to be examined. In RapidSmith, these uniquely-named wire segments are represented either as a String or as an int or Integer. Often it is represented as an integer to save space and increase comparison speed with other wires. To illustrate how this representation works, here is some example Java code that exposes the wire segments:
// Load the appropriate Device and WireEnumerator // (this is done automatically when loading XDL designs) String partName = "xc4vfx12ff668"; Device dev = FileTools.loadDevice(partName); WireEnumerator we = FileTools.loadWireEnumerator(partName); // Here we pick a wire name String wireName = "E2BEG4"; // Here we get the integer enum value for that wire name int wire = we.getWireEnum(wireName); // The wire enumerator also keeps information about these wire segments Copyright 2010-2011 Brigham Young University 4/29/2011 1:25 PM
Page | 37 // such as wire direction and type WireDirection direction = we.getWireDirection(wire); WireType type = we.getWireType(wire);
Now, there are actually several wires in an FPGA device with the same name. The wire E2BEG4 exists in almost every switch box tile in the FPGA. To uniquely identify routing resources in a device, a tile and its name or wire enumeration is required (that is, INT_X1Y1 E2BEG4 is its unique representation). In an effort to save space and ultimately reuse much of the routing connections, the WireConnection class is used to represent internal and external tile connections. Each tile has a special hash map where the key is the integer enum value of the wire and the value is an array of WireConnection objects. Each WireConnection object contains the following information to define a connection:
/** The wire enumeration value of the wire to be connected to */ private int wire; /** The tile row offset from the source wire's tile */ private int rowOffset; /** The tile column offset from the source wire's tile */ private int columnOffset; /** Does the source wire connected to this wire make a PIP? */ private boolean isPIP;
The WireConnection objects can define the connecting wire by using the integer enumeration value of the wire name and a relative offset of the tile differences between the two wires (again, relative to save space and increase reuse of the object). The WireConnection object also defines if the connection made is a programmable connection (or PIP). When the row and column tile offsets are both 0, the connection exists within the same tile and is likely a PIP. To query the connections that can be made from INT_X1Y1 E2BEG4, here is some sample Java code to illustrate how this is done:
// Load the appropriate Device and WireEnumerator // (this is done automatically when loading XDL designs) String partName = "xc4vfx12ff668"; Device dev = FileTools.loadDevice(partName); WireEnumerator we = FileTools.loadWireEnumerator(partName); // Here we pick a wire name String wireName = "E2BEG4"; // Here we get the integer enum value for that wire name int wire = we.getWireEnum(wireName); String tileName = "INT_X1Y1"; Tile tile = dev.getTile(tileName); WireConnection[] wireConnections = tile.getWireConnections(wire); for(WireConnection w : wireConnections){ System.out.println(tileName + " " + wireName + " connects to " + dev.getTile(tile.getRow()-w.getRowOffset(), tile.getColumn()-w.getColumnOffset()) + " " + we.getWireName(w.getWire()) + " (is" + (w.isPIP()? " " : " not ") + "a PIP connection)"); }
Console Output:
INT_X1Y1 E2BEG4 connects to INT_X1Y1 BOUNCE1 (is a PIP connection) Copyright 2010-2011 Brigham Young University 4/29/2011 1:25 PM
Page | 38 INT_X1Y1 E2BEG4 connects to INT_X1Y1 BOUNCE2 (is a PIP connection) INT_X1Y1 E2BEG4 connects to INT_X3Y1 E2END4 (is not a PIP connection) INT_X1Y1 E2BEG4 connects to INT_X2Y1 E2MID4 (is not a PIP connection)
Routes in XDL are specified only with PIPs. Non-PIP connections (that is E2BEG4 to E2MID4, etc.) are not declared in an XDL Net since the connection is implied. The two wire segments are part of the same piece of metal on the FPGA. Thus, when declaring the routing resources used in a Net (the list of PIPs), these connections are not explicitly listed. However, the PIP connections are, for example: net "main_00/i_ila/i_dt0/1/data_dly1_20" , outpin "main_00/i_ila/i_dt0/1/data_dly1_20" XQ , inpin "main_00/i_ila/i_yes_d/u_ila/idata_70" BY , pip CLB_X16Y48 XQ_PINWIRE2 -> SECONDARY_LOGIC_OUTS2_INT , pip CLB_X18Y48 BYP_INT_B4_INT -> BY_PINWIRE0 , pip INT_X16Y48 SECONDARY_LOGIC_OUTS2 -> OMUX7 , pip INT_X17Y48 OMUX_E7 -> E2BEG4 , pip INT_X18Y48 E2MID4 -> BYP_INT_B4 , ; The listing of PIPs in XDL is arbitrary, that is, they do not always follow from one connection to the next.
Basic Routing
RapidSmith has included an AbstractRouter class that allows for a common template so that routers can be constructed quite easily. However, the user should not feel restricted in using this template as it may not meet everyones needs and/or requirements. An example BasicRouter class has also been provided to illustrate how a router can be constructed easily. The BasicRouter class is ~400 lines of code. It is very simple and does not do any routing conflict resolution (it is a basic Maze router implementation) and it will commonly be unable to route certain connections in a design. Also, because the timing information for Xilinx parts is not publicly available, the router must use other means to optimize the router rather than delay. However, it does perform re-entrant routing, that is, it will attempt to route all nets that dont have any PIPs while keeping the original routed nets intact. If a net is impartially routed or improperly routed before given to the router, it does not resolve these problems. The behavior and mechanics of this router are described in the remainder of this section.
Router Structure
The basic router provided in RapidSmith is based on a simple maze router algorithm. It does not allow routing resources to be used more than once, and thus, routing resources come on a first-come-first-served basis. This makes for a very simple implementation but does not resolve routing conflicts when they arise. The router chooses a route by iterating through a growing set of nodes, represented by the Node class. A node is a unique tile and wire combination to uniquely identify any routing wire available in the FPGA. Nodes are given a cost based on their Manhattan distance from the sink of the current connection to be routed and then placed in a priority queue. Those nodes with the smallest cost propagate to the bottom of the queue. The least cost node of the queue is iteratively removed. With each removal, the node is examined for its expanding connections and those new potential nodes are also placed on the queue. Each time a node is removed, it is tested to see if it is the sink, if it is, the method traverses the path it has found and returns, otherwise it continues to expand more connections of the current node. The router uses the following basic algorithm:
Page | 39
1. The central routing method, routeDesign() prepares the nets in the design for routing. 2. For each net in the design, routeDesign() will call routeNet(). a. routeNet() prepares each inpin or sink in the net for routing. i. If this is the first inpin of the net, it will only supply the outpin or source of the net as a starting point to the router. ii. If this is the second or later inpin routed in the net, all intermediate points along those routes are added as starting points. b. For each inpin, routeNet() will call routeConnection(). i. routeConnection() initializes the priority queue of potential source nodes. ii. routeConnection() calls the main routing method route() for each connection to be routed. 1. The route() method iterates over the nodes in the priority queue, expanding their connections and adding new ones to the queue and putting more connections on the queue. The process continues until the sink is found. 3. After a net has been routed, the routing resources used will be marked as used to avoid reusing the resources twice.
Routing Static Sources (VCC/GND)

One major preparation step in routing a full design is preparing where the static sources will be supplied from. The basic primitive in all Xilinx FPGAs to supply VCC and GND signals to a design is the TIEOFF. The TIEOFF accompanies every switch matrix and has several connections to all sink connections to its neighboring logic tile (CLB, BRAM, DSP, etc.). It has 3 pins, HARD0 or GND, KEEP1 (VCC) and HARD1 (VCC). By default, without any configuration, it seems that pins will default to KEEP1. Some pins, however, require a HARD1 when specified to be driven with VCC. The StaticSourceHandler class takes care of partitioning the various nets and sinks into their respective tiles and instancing the TIEOFF automatically. It also will instance SLICEs when necessary. It also reserves certain routing resources for certain nets that could potentially introduce routing conflicts later. These reserved nodes are released just before the net is routed in the basic router.
Routing Clocks
When routing clocks, it is quite important that they get routed to the appropriate clock tree routing resources. The best current method to determine this is based on the WireDirection (the type CLK was placed in WireDirection because there are certain CLK wires that also fell into certain WireType categories). The cost function for determining node position in the priority queue take into account clock wires and significantly reduces their cost when routing clock nets.
Internal Pin Names and External Pin Names

In RapidSmith, there is the notion of each pin on an instance having an internal name and an external name. This can easily get confusing, especially where this can be a weak point for XDLRC report files which lack some of this information for some primitive types. Internal pin names occur commonly in two places (although, they do occur in other places): 1. In XDL nets which contain outpin and inpin statements 2. In XDLRC primitive_def declarations in the primitive_defs section of an XDLRC report.
4/29/2011 1:25 PM
Page | 40
First, lets talk about pins found in nets in XDL designs. In XDL, pins in a net are declared first with either the keyword outpin (to designate the source) or inpin (to designate a sink). Following the keyword is the name of the instance the pin belongs to. To illustrate this, lets look at an example:
net "netName" , outpin "fred" Y , inpin "barney" RST , pip CLB_X14Y4 Y_PINWIRE1 -> BEST_LOGIC_OUTS5_INT , pip DCM_BOT_X15Y4 SR_B0_INT3 -> DCM_ADV_RST , pip INT_X14Y4 BEST_LOGIC_OUTS5 -> OMUX8 , pip INT_X15Y5 OMUX_EN8 -> N2BEG0 , pip INT_X15Y7 N2END0 -> SR_B0 , ;
In the example above, there are two pins, a source and a sink. The source is found on the instance fred and the sink is found on the instance barney. The source pin on fred is pin Y and the sink pin is RST on barney. However, a problem arises when trying to use pin names in routing. For example if the pin name Y were used to specify routing to the instance it would be ambiguous because the Y pin belongs to a slice. Since PIPs declare routing resources at the tile level, the pin Y would have to be unique to the tile, however, there are actually multiple slices in a CLB tile making the reference Y ambiguous. To eliminate the ambiguity, Xilinx developed what we call an internal pin name and external pin name. The internal pin name (Y and RST in the example) is used when talking about a pin on an instance, however, to route to/from that pin the external name is used. In the PIP list of the example net above, the first PIP contains the external name Y_PINWIRE1 of pin Y on fred and the second PIP contains that external name DCM_ADV_RST of the pin RST. In the Virtex 4 architecture, there are 4 slices in each CLB, so the Y pin on each slice is named Y_PINWIRE0, Y_PINWIRE1, Y_PINWIRE2 and Y_PINWIRE3 respectively. The mapping of an internal pin name to an external pin name is found in the primitive_site declaration in an XDLRC report. Lets look at an example of an XDLRC primitive_site:
(primitive_site SLICE_X1Y126 SLICEL internal 27 (pinwire BX input BX_PINWIRE1) (pinwire BY input BY_PINWIRE1) (pinwire CE input CE_PINWIRE1) (pinwire CIN input CIN1) (pinwire CLK input CLK_PINWIRE1) (pinwire SR input SR_PINWIRE1) (pinwire F1 input F1_PINWIRE1) (pinwire F2 input F2_PINWIRE1) (pinwire F3 input F3_PINWIRE1) (pinwire F4 input F4_PINWIRE1) (pinwire G1 input G1_PINWIRE1) (pinwire G2 input G2_PINWIRE1) (pinwire G3 input G3_PINWIRE1) (pinwire G4 input G4_PINWIRE1) (pinwire FXINA input FXINA1) (pinwire FXINB input FXINB1) (pinwire F5 output F51) (pinwire FX output FX1) (pinwire X output X_PINWIRE1) (pinwire XB output XB_PINWIRE1) (pinwire XQ output XQ_PINWIRE1) (pinwire Y output Y_PINWIRE1) Copyright 2010-2011 Brigham Young University 4/29/2011 1:25 PM
Page | 41 (pinwire (pinwire (pinwire (pinwire (pinwire ) YB output YB_PINWIRE1) YQ output YQ_PINWIRE1) COUT output COUT1) YMUX output YMUX_PINWIRE1) XMUX output XMUX_PINWIRE1)
XDLRC report files show a mapping of internal pin name to external pin name on each line which starts with (pinwire. The pattern is: (pinwire <internal pin name> <direction of pin> <external pin name>) This is very straight forward and is the second common location to find internal and external pin names in XDL/XDLRC. In RapidSmith, the mapping between internal and external pin names can be made using the following methods: In the PrimitiveSite class:
/** * Gets the external wire enumeration of the name of the wire corresponding to the * internal wire name. * @param internalName The internal wire name in the primitive. * @return The corresponding external wire enum (Integer) name of the internal wire * name. */ public Integer getExternalPinName(String internalName);
In the Device class:

/** * Gets the external wire enumeration on the instance pin. * @param pin The pin to get the external name from. * @return The wire enumeration of the internal pin on the instance primitive of * pin. */ public Integer getPrimitiveExternalPin(Pin pin);
There is a problem, however, with some primitive types and getting mappings for their internal pin names to external pin names. Sometimes, a primitive type does not have a native primitive site in any device in Xilinx FPGA family. Therefore, the primitive must be placed on a compatible primitive site of a different type. For example, an IOB primitive instance does not have a native site on most families. However, it is fully compatible with IOBM or IOBS sites. In certain instances, the internal pin names differ on the primitive with no native sites to the sites on which it can be placed. The biggest example of this is in the Virtex 5 which has 9 different primitive types which all use the same primitive site type (RAMBFIFO36). Because the RAMBFIFO36 site is declared several times in the Virtex 5 devices, all of the internal-to-external pin mappings are available. However, 8 other sets of mappings are not present. The lack of mappings makes routing designs which contain these primitives impossible. The solution to this problem is to apply a patch with the proper mappings. A complete patch will be included with RapidSmith in a future release.
4/29/2011 1:25 PM
Page | 42
BITSTREAMS IN RAPIDSMITH
In RapidSmith, bitstreams can be parsed, manipulated, and exported for Virtex 4, Virtex 5 and Virtex 6 Xilinx FPGA families. Because of the proprietary nature of Xilinx bitstreams, RapidSmith provides only documented functionality when working with bitstreams. This functionality comes mainly from the documents distributed by Xilinx in the form of user guides, whitepapers and application notes. Any discussion relating to bitstreams in this document (unless explicitly clarified) refers to Virtex 4/5/6 bitstreams. Bitstreams are stored in 32-bit words for ease of interpretation. The best reference for much of the details and specifics of the bitstream can be found in the Configuration Users Guide for each of the FPGA family architectures. Here are links to the references: Xilinx UG071 Virtex 4 FPGA Configuration User Guide Xilinx UG191 Virtex 5 FPGA Configuration User Guide Xilinx UG360 Virtex 6 FPGA Configuration User Guide
Although each guide contains valuable information for each FPGA architecture family, the Virtex 5 guide is the most comprehensive and complete. It will provide the most insights and most of those insights can be applied to the other architecture families. RapidSmith has a bitstream parser which is capable of importing bitstream files into the bitstream data structure. This data structure can also export bitstreams after modification to a bitstream file and/or an MCS PROM file. For more details on the bitstream import and export capabilities see the bitstreamTools.bitstream.BitstreamParser class and bitstreamTools.bitstream.Bitstream class.
Bitstream Composition
In order to effectively use the bitstream capabilities provided in RapidSmith a preliminary understanding of how Xilinx bitstream are organized is necessary. In RapidSmith, Xilinx bitstream files are composed of three main elements as encapsulated by the bitstreamTools.bitstream.Bitstream class: 1. A bitstream header (bitstreamTools.bitstream.BitstreamHeader) 2. Dummy and Synchronization data (bitstreamTools.bitstream.DummySyncData) 3. A list of bitstream packets (bitstreamTools.bitstream.PacketList) Figure 13 below provides an illustrative diagram of how all of the components of a bitstream file correlate with the bitstreamTools.bitstream package in RapidSmith.
4/29/2011 1:25 PM
Page | 43
LEGEND
BITSTREAM FILE
Bitstream Header
(part name, date, time created, )
Names in Courier type are RapidSmith or Java Classes, the complete bitstream package name is: edu.byu.ece.rapidSmith.bitstreamTools.bitstream
bitstream.BitstreamHeader
Dummy & Synchronization Data

(dummy word, sync word, )
bitstream.DummySyncData
Packet List
Packet Packet Packet Packet Packet Packet
bitstream.PacketList
Packet Packet Header

Header (Packet) Type [31:29] OpCode Register Address [26:13] Reserved Word Count [10:0]
bitstream.Packet
int
[28:27]
[12:11]
Packet Data
bitstream.RegisterType
List<Integer>
Packet
bitstream.PacketOpCode bitstream.PacketType
Figure 13 - This diagram represents how RapidSmith encapsulates bitstream files using the bitstream package.
The entire package bitstreamTools.bitstream.* is dedicated to the representation of bitstream files. A bitstream file contains everything the configuration logic needs to setup the FPGA in preparation for configuration as well as containing all of the configuration data itself.
Bitstream Header
The first set of data that appears in a bitstream file is the bitstream header. The bitstream header contains information about the bitstream such as: The name of the NCD file the bitstream from which it was created The FPGA part name the bitstream targets The date the bitstream was created The time the bitstream was created All bitstream header information is actually ignored by the configuration logic and theoretically could be very large if a custom header was created. The bitstreamTools.bitstream.BitstreamHeader class is designed to parse headers and allow users to read and write the header and also export it to an XML format.
4/29/2011 1:25 PM
Page | 44
Dummy and Synchronization Data

In order for the configuration process to begin, the configuration controller must lock onto the sequence of words it is receiving from JTAG. It does this by waiting for a dummy word followed by a sync word (0xFFFFFFFF and 0xAA995566) in order to lock onto the incoming data. The bitstreamTools.bitstream.DummySyncData class is responsible for representing all dummy and synchronization data that is found immediately after the header but before the packet list as this data can be different from family to family.
Packet List
Packets are like configuration controller instructions that read or write a particular register. Once the configuration process has been synchronized, the configuration controller will begin to read the packets in the bitstream and execute their read or register write. Much of the details concerning packets can be found in the configuration user guides referenced at the beginning of this section, however, Figure 13 shows how a packet header is described in RapidSmith. One of the reliability mechanisms in bitstreams are CRC checks. Bitstreams include special packets which contain a CRC checksum based on the previous data in the bitstream file. This CRC ensures that the bitstream arrives correctly when parsed by the configuration logic. RapidSmith has facilities to create and/or update CRC packets when data changes. See the bitstreamTools.bitstream.CRC and bitstreamTools.bitstream.PacketListCRC classes for more details. There are two types of packets, Type I and Type II as indicated in the most significant bits of the packet header. Type I packets are used for small amounts of data being written to configuration registers. Type II packets always must follow a Type I packet and are able to carry a much bigger payload such as the entire configuration data for an FPGA. Generally, a normal bitstream will only have one Type II packet which is the packet carrying all of the configuration data for the FPGA. The configuration data can be sent in Type I packets, but a Type II packet is used for efficiency in programming and speed. This configuration data has its own addressing scheme and thus, the bitstream tools in RapidSmith accommodate this with a few other packages.
Bitstream Configuration Data

FPGA
The large Type II packet present in most bitstreams will likely contain all of the configuration data for the FPGA fabric. The bitstream tools in RapidSmith are able to emulate the configuring (at an abstract bitstream level) of the FPGA fabric in the bitstreamTools.configuration.FPGA class. In essence, the bitstream in the bitstreamTools.bitstream.Bitstream class configures or gets applied to the FPGA class.
Xilinx Configuration Specification

Because each FPGA is a little different and can vary among FPGA family architectures, RapidSmith has special classes that contain part specific information automatically generated from debug bitstreams to enable the FPGA class to emulate any device in the Virtex 4/5/6 families. In order to accommodate any device in the Virtex 4/5/6 families, the FPGA class requires what is called a XilinxConfigurationSpecification which defines certain bitstream attributes about a particular device. The XilinxConfigurationSpecification is a public Java interface declared in bitstreamTools.configurationSpecification.XilinxConfigurationSpecification. This interface is implemented by an abstract class
Page | 45
(bitstreamTools.configurationSpecification.AbstractConfigurationSpecificati on) and further extended by other classes, where each class contains information for each family. Specific parts are represented in PartLibrary classes which extend the family specific {V4,V5,V6}ConfigurationSpecifications. Much of the headache of trying to understand the previous paragraph is avoided by simply doing the following to initialize an FPGA instance:
String partName = "xc4vfx12ff668-10"; XilinxConfigurationSpecification spec = DeviceLookup.lookupPartV4V5V6(partName); FPGA virtex4fx12 = new FPGA(spec);
Frame Address Register

An organized mechanism is used to access various parts of the configuration data in an FPGA. This mechanism is called the frame address register or FAR for short, it is represented in RapidSmith as the bitstreamTools.configuration.FrameAddressRegister class. The FAR is one of the configuration registers found in the configuration logic. Like all configuration registers, the FAR is 32 bits and although the bits are laid out in a different order for different architectures, they all contain the same fields: Top/Bottom: A bit indicating if the referenced bits are in the top half rows or bottom half rows of the device. Block Type: The type of block (configuration block) that is being referenced by the register. The block types vary depending on the architectureSee configuration guides for more details. Row Address: References a row of frames. Row addresses start at 0 in the middle of the chip and increment towards the top or bottom. Column Address: Selects a major column (such as CLBs) to reference. Column addresses start at 0 at the left side of the chip and increment towards the right. Minor Address: Selects a frame inside of a configuration block. Different configuration blocks have different sizes of frames.
The bit field assignments for Virtex 4/5/6 are shown in the table below: FAR Address Fields Block Type Top / Bottom Bit Row Address Column Address Minor Address Virtex 4 [21:19] 22 [18:14] [13:6] [5:0] Virtex 5 [23:21] 20 [19:15] [14:7] [6:0] Virtex 6 [23:21] 20 [19:15] [14:7] [6:0]
Frame
A frame is the smallest addressable configuration data in a Xilinx FPGA. In Virtex 4 and Virtex 5 architectures, a frame is 1312 bits or 41 32-bit words. In Virtex 6, a frame is 2592 bits or 81 32-bit words. The frame is addressed using the FAR and populating the appropriate fields. Each frame will have a unique address which corresponds to a different value in the FAR or what is called a frame address. A frame in RapidSmith is represented by the bitstreamTools.configuration.Frame class. A frame has a unique frame address (represented by a 32-bit int) and contains 41/81 words of data which are stored in the bitstreamTools.configuration.FrameData class. Frame data is organized fairly similarly
Page | 46
among architectures. As an example of how frame data is organized, consider the figure below taken from the Xilinx UG191(v3.9.1) - Virtex 5 Configuration Guide (Figure 6-9, p. 130):
Figure 14 - Layout of the data in a Virtex 5 configuration frame.
As can be seen from Figure 14, the center configuration word contains configuration bits the control the horizontal clock wires and contains ECC bits for the frame data. The words before the center word configure the top half of a configuration block (or in the case of Virtex 5, the top 10 CLBs) and the words after the center word configure the bottom half of the configuration block.
Configuration Block
Frames are grouped into groups called configuration blocks. Although there is no explicit class to represent a configuration block in RapidSmith, it is heavily used concept. A configuration block can be defined as the grouping of frames that have the same top/bottom-bit, row address and column address in a frames address (also as indicated in the frame address register). Configuration blocks come in different types, and each type has a subtype. Block types and subtypes are represented in the bitstreamTools.configurationSpecification.BlockType and bitstreamTools.configurationSpecification.BlockSubType classes. Block types and
Page | 47
subtypes are specified in the architectures corresponding configuration specification. To give a quick overview of some block types and their frame sizes, consider the table below: Configuration Block Virtex 4 Virtex 5 Virtex 6 Type/SubType CLB Block 22 frames 36 frames 36 frames IO Block 30 frames 54 frames 44 frames DSP Block 21 frames 28 frames 28 frames CLK Block 3 frames 4 frames 38 frames MGT/GTX Block 20 frames 32 frames 30 frames BRAM Interconnect 20 frames 30 frames 28 frames Block BRAM Content Block 64 frames 128 frames 128 frames Overhead 2 frames 2 frames 2 frames BRAM Overhead 2 frames 2 frames 2 frames
Figure 15 - Frame counts for different block types and block subtypes in Virtex 4/5/6 architectures.
4/29/2011 1:25 PM
Page | 48
APPENDIX
Here is just a grouping of useful topics that may not fit in the rest of this document.
Appendix A: Modifying LUT Content

LUTs (look up tables) found in Xilinx slices can be easily modified using RapidSmith. LUT content is stored in an attribute in an instance of a SLICEL or SLICEM or whatever type of SLICE the device has. Often the name of the LUT is a single letter such as F or G as in the Virtex 4 family. Virtex 5 FPGAs have 4 LUTs in a slice and are called {A, B, C, D}{5, 6}LUT which have the capability to act as a 5 input or 6 input LUT.
LUT Equation Syntax

Xilinx uses the following syntax for operators in a LUT equations string: Operator * + @ ~ Operator Meaning Logical AND Logical OR Logical XOR Unary NOT
The parenthesis characters are also used to denote precedence in equation. Valid equation values are A1, A2, A3 and A4 for 4-input LUTs with an additional A5 for 5-input LUTs and A6 for 6-input LUTs. Some examples of LUT equations are: LUT Equation A1 A1*A2 ~A4 (A4+(A1+(A2+A3))) Equation Meaning Passes through the signal A1 A 2-input AND gate using A1 and A2 Inverts the signal on A4 A multi-level OR of 4 inputs
XDL LUT Equation Syntax

An instance is configured by zero or more attributes in a list where an attribute has the pattern <Physical Name>:<Optional Logical Name>:<Value>. The physical name of a LUT has been mentioned at the beginning of this subsection as being F or G for Virtex 4 parts and {A, B, C, D}{5, 6}LUT for Virtex 5 parts. The optional logical name is generally chosen by the synthesis tools or whatever name propagated through to Xilinx NGDBuild and Map when the signal was converted. It is only for reference back to the users original design and should correspond with the output of the LUT. The value has the following syntax: #LUT:D=<equation> This syntax can also be found in the XDLRC primitive_defs. If we put this altogether with our examples above we would get: F:mySignal0:#LUT:D=A1 G:mySignal1:#LUT:D=A1*A2
Page | 49
F:mySignal2:#LUT:D=~A4 G:mySignal3:#LUT:D=(A4+(A1+(A2+A3))) Notice that the value also contains the colon (:). RapidSmith defines the separation of the three components of an attribute as the first and second colons, any colons found after the second colon is part of the attribute value. It is also of some value to recognize that the router can re-arrange LUT inputs to make routing easier and this can change equation to some extent.
Appendix B: Hard Macros in XDL and RapidSmith

A hard macro is a collection of primitive instances and nets that have been placed and possibly routed. The XDL construct that represents a hard macro is the module. A hard macro file only has a single module and no other nets, instances or module instances present in the file. The design name is "__XILINX_NMC_MACRO" which is a static variable in the Design class:
public static final String hardMacroDesignName = "__XILINX_NMC_MACRO";
Xilinx NMC files

The NCD file format is not used for hard macros; instead, Xilinx uses the NMC format which is fairly similar. NMC files can be converted to and from XDL using the same xdl executable. For example: xdl ncd2ndl myHardMacro.nmc [optional: myHardMacro.xdl] xdl xdl2ncd myHardMacro.xdl myHardMacro.nmc The user must specify the output file name for NMC files when converting from XDL to NMC, otherwise it will output a file with the same name but NCD extension and the Xilinx tools wont read it properly. You may also need to apply the force option if there is an error.
Xilinx Hard Macros

There are several hidden restrictions and conventions that must be adhered to in order to create a valid Xilinx hard macro. Here is a list of the known quirks to creating Xilinx-compatible hard macros: Any nets that are designated as GND or VCC are invalid (this will cause xdl to run in an infinite loop) The TIEOFF primitive found in INT tiles (switch matrix tiles) cannot be used in hard macros (this will cause a problem later on with map and/or par) Conventional XDL_DUMMY SLICEs which contain a _NO_USER_LOGIC attribute will not work with the Xilinx tools. Nets can only have 1 (one) hard macro port assigned to its pin list.
RapidSmith Hard Macro Generator

RapidSmith provides a generic hard macro generator that will take a placed and routed NCD design file (or XDL equivalent) and replace IOBs with module ports among other transformations to make it a valid and legal hard macro. The hard macro generator provided is the same as used in the published paper, Using Hard Macros to Reduce FPGA Compilation Time, C. Lavin, et al., FPL2010. This class is found in the util package and can be run from the command line: java edu.byu.ece.rapidSmith.util.HardMacroGenerator <input.xdl | input.ncd> <output file type: xdl | nmc> [optional: original_toplevel.vhd]
Page | 50
The hard macro generator has to remove TIEOFFs (which supply GND and VCC) because they are not legal primitives in hard macros. Therefore, the hard macro generator creates input ports accordingly. It also renames ports according to primitive instance names of the IOBs and will attempt to name them as they were found in the original HDL. However, it only can guess, and for a more complete naming, the top level VHDL file can optionally be provided as a parameter to help the generator get the port names correctly. Unfortunately, the generator cannot parse Verilog.
Appendix C: Xilinx Family Names and Part Names

The part and family naming conventions used in RapidSmith largely follow those used in the Xilinx tool partgen. RapidSmith includes an enum type called FamilyType for all known family architectures in the util package.
Xilinx Part Names in RapidSmith

RapidSmith uses the part name pattern as produced by the Xilinx partgen tool. These part names start with X for Xilinx and are then often followed by a C for commercial parts, A for automotive parts, Q for military grade parts, and QR for space grade parts. The part names also include the package, however, because RapidSmith does not have any timing information, the speed grade is optional. Some examples are shown below: Examples of valid part names in RapidSmith XC4VFX12FF668 XC5LX110TFF1136-2 XCV50BG256 Examples of invalid part names in RapidSmith Virtex 4 LX30 XC5VSX35T-2FF665C XC5VLX20T
RapidSmith contains methods in util.RunXilinxTools to automatically run partgen and parse its output to obtain part names of installed devices. The installer uses these methods in order to determine which parts are valid on the system. The user can also refer to the final table in the Appendix entry on Memory and Performance of RapidSmith for a long list of part names. Other manipulation and conversion function for part names are found in the util.PartNameTools class.
Xilinx Family Names in RapidSmith

By using the FamilyType enum, it makes writing code easier when trying to figure out what family the current design is targeting. The util.PartNameTools has several methods to help identify a family type from a part name and also identify sub family names. With the most recent Xilinx tools (ISE 11.1 and above) do not support legacy devices (Spartan 2, Spartan 2E, Virtex, Virtex E, Virtex 2 and Virtex 2 Pro families) and must use ISE 10.1.03 or older to create XDLRC reports and import/export XDL design. PartNameTools contains a method to determine if a given family type is a legacy type:
/** * This method determines which family types require the older version * of the Xilinx tools (10.1.03 or older). * @param familyType The family type to check. * @return True if this part requires older tools (10.1.03) or older, false * otherwise. */ public static boolean isFamilyTypeLegacy(FamilyType familyType); Copyright 2010-2011 Brigham Young University 4/29/2011 1:25 PM
Page | 51
Appendix D: XDLRC Compatible Families

RapidSmith depends on Xilinx XDLRC files for device descriptions. Xilinx offers several different families which in actuality use the same XDLRC information. Therefore, there is a set of base (commercial grade) families that are compatible with other families as well. The follow is a table showing these compatibilities:
Base Families (Formal Name)
Spartan2 Spartan2E Spartan3 Spartan3A and Spartan3AN Spartan-3A DSP Spartan3E Spartan6 Virtex Virtex2 Virtex2P Virtex4 Virtex5 Virtex6 VirtexE
Base Families (partgen Name)

spartan2 spartan2e spartan3 spartan3a spartan3adsp spartan3e spartan6 virtex virtex2 virtex2p virtex4 virtex5 virtex6 virtexe
XDLRC Compatible Families

aspartan2e aspartan3 aspartan3a aspartan3adsp aspartan3e spartan6l, aspartan6, qspartan6, qspartan6l qvirtex, qrvirtex qvirtex2, qrvirtex2 qvirtex2p qrvirtex4, qvirtex4 qvirtex5, qrvirtex5 virtex6l qvirtexe
Only device files are generated for the base families. Therefore, when loading designs or RapidSmith files, its always best to use the base family name. One way to ensure this is to use the following method:
/** * This method will take a familyType and return the base familyType * architecture. For example, the XDLRC RapidSmith uses for Automotive * Spartan 6, Low Power Spartan 6 and Military Grade Spartan 6 all have * the same base architecture: Spartan 6. This method determines the * base architecture based on the familyType. * @param type The given family type. * @return The base family type architecture. */ public static FamilyType getBaseTypeFromFamilyType(FamilyType type);
Appendix E: Memory and Performance of RapidSmith

This section contains a dump from the shell script generated in the tests.TestFileLoading class in RapidSmith. It determines the files size, Java heap usage in MB and load time from disk for the following 3 types of files. This script was run on a Windows 7 Enterprise 64-bit OS with an Intel Core i7 860 running at 2.8GHz. The test machine had 8 GB of DDR3 memory, a conventional 1 TB SATA hard drive and was using version 0.5.0 of RapidSmith and the 32-bit Oracle JVM version 1.6.0_22. Running RapidSmith in 64-bit Java will work exactly the same as in 32-bit mode; however its performance will be slightly slower and use more memory.
4/29/2011 1:25 PM
Page | 52
Wire Enumerator Files

Family Name SPARTAN2 SPARTAN2E SPARTAN3 SPARTAN3A SPARTAN3ADSP SPARTAN3E SPARTAN6 VIRTEX VIRTEX2 VIRTEX2P VIRTEX4 VIRTEX5 VIRTEX6 File Size 17KB 19KB 15KB 25KB 33KB 26KB 168KB 17KB 21KB 90KB 233KB 264KB 171KB Java Heap Usage 0.6MB 0.6MB 0.5MB 0.9MB 1.2MB 0.9MB 6.6MB 0.6MB 0.7MB 3.1MB 8.1MB 9.9MB 6.3MB Load Time From Disk 0.030s 0.030s 0.030s 0.032s 0.035s 0.033s 0.081s 0.030s 0.033s 0.055s 0.109s 0.128s 0.098s
Primitive Definitions Files

Family Name SPARTAN2 SPARTAN2E SPARTAN3 SPARTAN3A SPARTAN3ADSP SPARTAN3E SPARTAN6 VIRTEX VIRTEX2 VIRTEX2P VIRTEX4 VIRTEX5 VIRTEX6 File Size 8KB 9KB 17KB 23KB 63KB 21KB 117KB 8KB 18KB 88KB 179KB 322KB 191KB Java Heap Usage 0.1MB 0.1MB 0.1MB 0.1MB 0.1MB 0.1MB 0.1MB 0.1MB 0.1MB 0.1MB 0.1MB 0.1MB 0.1MB Load Time From Disk 0.085s 0.084s 0.082s 0.097s 0.110s 0.085s 0.114s 0.075s 0.079s 0.108s 0.144s 0.191s 0.149s
Device Files
Family Name KINTEX7 KINTEX7 KINTEX7 KINTEX7 KINTEX7 KINTEX7 KINTEX7 KINTEX7 KINTEX7 Part Name xc7k160tfbg484 xc7k160tfbg676 xc7k160tffg676 xc7k30tfbg484 xc7k30tsbg324 xc7k325tfbg676 xc7k325tfbg900 xc7k325tffg676 xc7k325tffg900 File Size 1093KB 1093KB 1093KB 619KB 619KB 1424KB 1424KB 1424KB 1424KB Java Heap Size 40MB 40MB 40MB 17MB 17MB 58MB 58MB 58MB 58MB Load Time from Disk 0.430s 0.424s 0.442s 0.221s 0.209s 0.628s 0.628s 0.629s 0.665s
4/29/2011 1:25 PM
Page | 53
KINTEX7 KINTEX7 KINTEX7 KINTEX7 KINTEX7 KINTEX7 KINTEX7 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2 SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E
xc7k410tfbg676 xc7k410tfbg900 xc7k410tffg676 xc7k410tffg900 xc7k70tfbg484 xc7k70tfbg676 xc7k70tsbg324 xc2s100fg256 xc2s100fg456 xc2s100pq208 xc2s100tq144 xc2s150fg256 xc2s150fg456 xc2s150pq208 xc2s15cs144 xc2s15tq144 xc2s15vq100 xc2s200fg256 xc2s200fg456 xc2s200pq208 xc2s30cs144 xc2s30pq208 xc2s30tq144 xc2s30vq100 xc2s50fg256 xc2s50pq208 xc2s50tq144 xc2s100efg456 xc2s100eft256 xc2s100epq208 xc2s100etq144 xc2s150efg456 xc2s150eft256 xc2s150epq208 xc2s200efg456 xc2s200eft256 xc2s200epq208 xc2s300efg456 xc2s300eft256 xc2s300epq208 xc2s400efg456 xc2s400efg676 xc2s400eft256 xc2s50eft256
1704KB 1705KB 1704KB 1705KB 778KB 778KB 778KB 134KB 134KB 134KB 134KB 150KB 150KB 150KB 84KB 84KB 84KB 179KB 179KB 179KB 103KB 103KB 103KB 103KB 117KB 117KB 118KB 137KB 137KB 137KB 137KB 154KB 154KB 154KB 189KB 189KB 189KB 233KB 233KB 233KB 326KB 326KB 326KB 121KB
72MB 72MB 72MB 72MB 25MB 25MB 25MB 3MB 3MB 3MB 3MB 5MB 5MB 5MB 1MB 1MB 1MB 7MB 7MB 7MB 1MB 1MB 1MB 1MB 2MB 2MB 2MB 3MB 3MB 3MB 3MB 5MB 5MB 5MB 7MB 7MB 7MB 8MB 8MB 8MB 13MB 13MB 13MB 2MB
0.774s 0.777s 0.807s 0.797s 0.345s 0.358s 0.324s 0.082s 0.082s 0.083s 0.091s 0.096s 0.101s 0.096s 0.054s 0.052s 0.057s 0.115s 0.119s 0.116s 0.062s 0.059s 0.060s 0.060s 0.078s 0.078s 0.082s 0.102s 0.095s 0.095s 0.086s 0.095s 0.097s 0.101s 0.119s 0.118s 0.121s 0.129s 0.129s 0.128s 0.182s 0.179s 0.180s 0.076s
4/29/2011 1:25 PM
Page | 54
SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN2E SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3 SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A
xc2s50epq208 xc2s50etq144 xc2s600efg456 xc2s600efg676 xc3s1000fg320 xc3s1000fg456 xc3s1000fg676 xc3s1000ft256 xc3s1000lfg320 xc3s1000lfg456 xc3s1000lft256 xc3s1500fg320 xc3s1500fg456 xc3s1500fg676 xc3s1500lfg320 xc3s1500lfg456 xc3s1500lfg676 xc3s2000fg456 xc3s2000fg676 xc3s2000fg900 xc3s200ft256 xc3s200pq208 xc3s200tq144 xc3s200vq100 xc3s4000fg1156 xc3s4000fg676 xc3s4000fg900 xc3s4000lfg900 xc3s400fg320 xc3s400fg456 xc3s400ft256 xc3s400pq208 xc3s400tq144 xc3s5000fg1156 xc3s5000fg676 xc3s5000fg900 xc3s50cp132 xc3s50pq208 xc3s50tq144 xc3s50vq100 xc3s1400afg484 xc3s1400afg676 xc3s1400aft256 xc3s1400anfgg676
4/29/2011 1:25 PM
Page | 55
SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3A SPARTAN3ADSP SPARTAN3ADSP SPARTAN3ADSP SPARTAN3ADSP SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN3E SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6
xc3s200afg320 xc3s200aft256 xc3s200anftg256 xc3s200avq100 xc3s400afg320 xc3s400afg400 xc3s400aft256 xc3s400anfgg400 xc3s50aft256 xc3s50antqg144 xc3s50atq144 xc3s50avq100 xc3s700afg400 xc3s700afg484 xc3s700aft256 xc3s700anfgg484 xc3sd1800acs484 xc3sd1800afg676 xc3sd3400acs484 xc3sd3400afg676 xc3s100ecp132 xc3s100etq144 xc3s100evq100 xc3s1200efg320 xc3s1200efg400 xc3s1200eft256 xc3s1600efg320 xc3s1600efg400 xc3s1600efg484 xc3s250ecp132 xc3s250eft256 xc3s250epq208 xc3s250etq144 xc3s250evq100 xc3s500ecp132 xc3s500efg320 xc3s500eft256 xc3s500epq208 xc3s500evq100 xc6slx100csg484 xc6slx100fgg484 xc6slx100fgg676 xc6slx100tcsg484 xc6slx100tfgg484
4/29/2011 1:25 PM
Page | 56
SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 SPARTAN6 VIRTEX VIRTEX VIRTEX VIRTEX
xc6slx100tfgg676 xc6slx100tfgg900 xc6slx150csg484 xc6slx150fgg484 xc6slx150fgg676 xc6slx150fgg900 xc6slx150tcsg484 xc6slx150tfgg484 xc6slx150tfgg676 xc6slx150tfgg900 xc6slx16cpg196 xc6slx16csg225 xc6slx16csg324 xc6slx16ftg256 xc6slx25csg324 xc6slx25fgg484 xc6slx25ftg256 xc6slx25tcsg324 xc6slx25tfgg484 xc6slx45csg324 xc6slx45csg484 xc6slx45fgg484 xc6slx45fgg676 xc6slx45tcsg324 xc6slx45tcsg484 xc6slx45tfgg484 xc6slx4cpg196 xc6slx4csg225 xc6slx4tqg144 xc6slx75csg484 xc6slx75fgg484 xc6slx75fgg676 xc6slx75tcsg484 xc6slx75tfgg484 xc6slx75tfgg676 xc6slx9cpg196 xc6slx9csg225 xc6slx9csg324 xc6slx9ftg256 xc6slx9tqg144 xcv1000bg560 xcv1000fg680 xcv100bg256 xcv100cs144
4/29/2011 1:25 PM
Page | 57
VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2
xcv100fg256 xcv100pq240 xcv100tq144 xcv150bg256 xcv150bg352 xcv150fg256 xcv150fg456 xcv150pq240 xcv200bg256 xcv200bg352 xcv200fg256 xcv200fg456 xcv200pq240 xcv300bg352 xcv300bg432 xcv300fg456 xcv300pq240 xcv400bg432 xcv400bg560 xcv400fg676 xcv400hq240 xcv50bg256 xcv50cs144 xcv50fg256 xcv50pq240 xcv50tq144 xcv600bg432 xcv600bg560 xcv600fg676 xcv600fg680 xcv600hq240 xcv800bg432 xcv800bg560 xcv800fg676 xcv800fg680 xcv800hq240 xc2v1000bg575 xc2v1000ff896 xc2v1000fg256 xc2v1000fg456 xc2v1500bg575 xc2v1500ff896 xc2v1500fg676 xc2v2000bf957
4/29/2011 1:25 PM
Page | 58
VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2 VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P
xc2v2000bg575 xc2v2000ff896 xc2v2000fg676 xc2v250cs144 xc2v250fg256 xc2v250fg456 xc2v3000bf957 xc2v3000bg728 xc2v3000ff1152 xc2v3000fg676 xc2v4000bf957 xc2v4000ff1152 xc2v4000ff1517 xc2v40cs144 xc2v40fg256 xc2v500fg256 xc2v500fg456 xc2v6000bf957 xc2v6000ff1152 xc2v6000ff1517 xc2v8000ff1152 xc2v8000ff1517 xc2v80cs144 xc2v80fg256 xc2vp100ff1696 xc2vp100ff1704 xc2vp20ff1152 xc2vp20ff896 xc2vp20fg676 xc2vp2ff672 xc2vp2fg256 xc2vp2fg456 xc2vp30ff1152 xc2vp30ff896 xc2vp30fg676 xc2vp40ff1148 xc2vp40ff1152 xc2vp40fg676 xc2vp4ff672 xc2vp4fg256 xc2vp4fg456 xc2vp50ff1148 xc2vp50ff1152 xc2vp50ff1517
4/29/2011 1:25 PM
Page | 59
VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX2P VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX4 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5
xc2vp70ff1517 xc2vp70ff1704 xc2vp7ff672 xc2vp7ff896 xc2vp7fg456 xc2vpx20ff896 xc2vpx70ff1704 xc4vfx100ff1152 xc4vfx100ff1517 xc4vfx12ff668 xc4vfx12sf363 xc4vfx140ff1517 xc4vfx20ff672 xc4vfx40ff1152 xc4vfx40ff672 xc4vfx60ff1152 xc4vfx60ff672 xc4vlx100ff1148 xc4vlx100ff1513 xc4vlx15ff668 xc4vlx15ff676 xc4vlx15sf363 xc4vlx160ff1148 xc4vlx160ff1513 xc4vlx200ff1513 xc4vlx25ff668 xc4vlx25ff676 xc4vlx25sf363 xc4vlx40ff1148 xc4vlx40ff668 xc4vlx60ff1148 xc4vlx60ff668 xc4vlx80ff1148 xc4vsx25ff668 xc4vsx35ff668 xc4vsx55ff1148 xc5vfx100tff1136 xc5vfx100tff1738 xc5vfx130tff1738 xc5vfx200tff1738 xc5vfx30tff665 xc5vfx70tff1136 xc5vfx70tff665 xc5vlx110ff1153
4/29/2011 1:25 PM
Page | 60
VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX5 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6
xc5vlx110ff1760 xc5vlx110ff676 xc5vlx110tff1136 xc5vlx110tff1738 xc5vlx155ff1153 xc5vlx155ff1760 xc5vlx155tff1136 xc5vlx155tff1738 xc5vlx20tff323 xc5vlx220ff1760 xc5vlx220tff1738 xc5vlx30ff324 xc5vlx30ff676 xc5vlx30tff323 xc5vlx30tff665 xc5vlx330ff1760 xc5vlx330tff1738 xc5vlx50ff1153 xc5vlx50ff324 xc5vlx50ff676 xc5vlx50tff1136 xc5vlx50tff665 xc5vlx85ff1153 xc5vlx85ff676 xc5vlx85tff1136 xc5vsx240tff1738 xc5vsx35tff665 xc5vsx50tff1136 xc5vsx50tff665 xc5vsx95tff1136 xc5vtx150tff1156 xc5vtx150tff1759 xc5vtx240tff1759 xc6vcx130tff1156 xc6vcx130tff484 xc6vcx130tff784 xc6vcx195tff1156 xc6vcx195tff784 xc6vcx240tff1156 xc6vcx240tff784 xc6vcx75tff484 xc6vcx75tff784 xc6vhx250tff1154 xc6vhx255tff1155
4/29/2011 1:25 PM
Page | 61
VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX6 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7 VIRTEX7
xc6vhx255tff1923 xc6vhx380tff1154 xc6vhx380tff1155 xc6vhx380tff1923 xc6vhx380tff1924 xc6vhx565tff1923 xc6vhx565tff1924 xc6vlx130tff1156 xc6vlx130tff484 xc6vlx130tff784 xc6vlx195tff1156 xc6vlx195tff784 xc6vlx240tff1156 xc6vlx240tff1759 xc6vlx240tff784 xc6vlx365tff1156 xc6vlx365tff1759 xc6vlx550tff1759 xc6vlx550tff1760 xc6vlx75tff484 xc6vlx75tff784 xc6vlx760ff1760 xc6vsx315tff1156 xc6vsx315tff1759 xc6vsx475tff1156 xc6vsx475tff1759 xc7v1500tffg1761 xc7v1500tfhg1157 xc7v2000tffg1925 xc7v2000tfhg1761 xc7v285tffg1157 xc7v285tffg1761 xc7v285tffg484 xc7v285tffg784 xc7v450tffg1157 xc7v450tffg1761 xc7v450tffg784 xc7v585tffg1157 xc7v585tffg1761 xc7v855tffg1157 xc7v855tffg1761 xc7vx485tffg1157 xc7vx485tffg1158 xc7vx485tffg1761
4/29/2011 1:25 PM
Page | 62
VIRTEX7 VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE
xc7vx485tffg1929 xcv1000ebg560 xcv1000efg1156 xcv1000efg680 xcv1000efg860 xcv1000efg900 xcv1000ehq240 xcv100ebg352 xcv100ecs144 xcv100efg256 xcv100epq240 xcv1600ebg560 xcv1600efg1156 xcv1600efg680 xcv1600efg860 xcv1600efg900 xcv2000ebg560 xcv2000efg1156 xcv2000efg680 xcv2000efg860 xcv200ebg352 xcv200ecs144 xcv200efg256 xcv200efg456 xcv200epq240 xcv2600efg1156 xcv300ebg352 xcv300ebg432 xcv300efg256 xcv300efg456 xcv300epq240 xcv3200efg1156 xcv400ebg432 xcv400ebg560 xcv400efg676 xcv400epq240 xcv405ebg560 xcv405efg676 xcv50ecs144 xcv50efg256 xcv50epq240 xcv600ebg432 xcv600ebg560 xcv600efg676
4/29/2011 1:25 PM
Page | 63
VIRTEXE VIRTEXE VIRTEXE VIRTEXE VIRTEXE
xcv600efg680 xcv600efg900 xcv600ehq240 xcv812ebg560 xcv812efg900
413KB 413KB 413KB 634KB 634KB
19MB 19MB 19MB 26MB 26MB
0.258s 0.259s 0.246s 0.349s 0.344s
4/29/2011 1:25 PM

Rapid Smith Documentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapid Smith Documentation

Uploaded by

Copyright:

Available Formats

RAPIDSMITH

A Library for Low-level Manipulation of Partially Placed-and-Routed FPGA Designs

Copyright 2010-2011 Brigham Young University

Copyright 2010-2011 Brigham Young University

Who Should Use RapidSmith?

Which Xilinx Parts does RapidSmith Support?

How is This Different than VPR?

Copyright 2010-2011 Brigham Young University

LEGAL AND DEPENDENCIES

Included Dependency Projects

Copyright 2010-2011 Brigham Young University

Requirements for Installation

Steps for Installation

Additional Notes for Mac OS X Installation

Page | 12 name]/Documents/workspace/rapidSmith/jars/hessian-4.0.6.jar:/Users/[user name]/Documents/workspace/rapidSmith/jars/qtjambi-4.6.3.jar:/Users/[user name]/Documents/workspace/rapidSmith/jars/qtjambi-macosx-gcc-4.6.3.jar</string> </dict> </plist>

bitstreamTools.examples bitstreamTools.examples.support design design.explorer

device.helper examples gui

router tests timing

Copyright 2010-2011 Brigham Young University

ATTRIBUTE CLASS String physicalName; String logicalName; String value;

ATTRIBUTE CLASS String physicalName; String logicalName; String value;

Figure 3 - Net, Pin and PIP Classes

Copyright 2010-2011 Brigham Young University

Figure 4 - Hyperlinks in Design Explorer

Copyright 2010-2011 Brigham Young University

Figure 5 - Timing report loaded in Design Explorer

Figure 6 - Device Browser screenshot

Copyright 2010-2011 Brigham Young University

Figure 7 - Device browser screenshot showing wire connections

Copyright 2010-2011 Brigham Young University

Copyright 2010-2011 Brigham Young University

Part Tile Browser

Copyright 2010-2011 Brigham Young University

Figure 8: Screenshot of Part Tile Browser

Copyright 2010-2011 Brigham Young University

Basic Syntax of XDL Files

Copyright 2010-2011 Brigham Young University

Copyright 2010-2011 Brigham Young University

Basic Syntax of XDLRC Files

Copyright 2010-2011 Brigham Young University

Copyright 2010-2011 Brigham Young University

Copyright 2010-2011 Brigham Young University

Memory and Performance

Device Performance and Memory Usage

Wire Enumerator Size and Performance

Copyright 2010-2011 Brigham Young University

Primitive Resources in RapidSmith

Copyright 2010-2011 Brigham Young University

Figure 11 Device Browser screenshot showing site SLICE_X1Y121 in tile CLB_X1Y60

Primitive Definitions and Types

Copyright 2010-2011 Brigham Young University

Wire Resources in RapidSmith

Routing Static Sources (VCC/GND)

Internal Pin Names and External Pin Names

Copyright 2010-2011 Brigham Young University

In the Device class:

Copyright 2010-2011 Brigham Young University

Copyright 2010-2011 Brigham Young University

Dummy & Synchronization Data

Packet Packet Header

Copyright 2010-2011 Brigham Young University

Dummy and Synchronization Data

Bitstream Configuration Data

Xilinx Configuration Specification