Approaches to Extend FPGA Reverse-Engineering Technology from ISE to Vivado

Abstract

SRAM-based FPGA(Field Programmable Logic Arrays) requires external memory since its internal memory gets erased when power is cut off. The process of transmitting the circuit netlist in bitstream from external memory during power-up in FPGA is vulnerable to malicious attacks such as bitstream theft and tampering. Previous FPGA reverse-engineering methods focus on FPGAs, supported by ISE (ISE Design Suite). This is because ISE provides XDLRC (Xilinx Design Language Routing Configurable logic) and XDL (Xilinx Design language) files, which are essential for reverse engineering. However, Vivado Design Suite (Vivado) does not offer those files, making it impossible to extend the coverage of reverse engineering to the FPGAs supported by Vivado. In this paper, we propose a method to generate XDLRC and XDL through Vivado. According to experimental results, the XDLRC and XDL generated through Vivado, respectively, match 99% and 75% with those generated in ISE for Artix-7 100T. As a result, this paper has expanded the scope of reverse engineering from being mainly focused on ISE to now also include Vivado. It is important to note that this paper does not encourage bitstream attacks through reverse engineering but rather highlights the risk associated with malicious attacks and emphasizes the importance of security.

1. Introduction

SRAM-based FPGAs, along with the Flash-based FPGA (Field Programmable Logic Array) and the Antifuse-based FPGA, play a significant role in various applications, such as signal processing, communication systems, image processing, control systems, encryption, and security [1]. Notably, AMD Xilinx and Intel Altera FPGAs demonstrate the highest market share in the SRAM-based FPGA industry [2]. FPGA chip manufacturers typically provide EDA tools to support circuit synthesis and implementation on FPGA chips, with Xilinx offering two such tools: ISE (ISE Design Suite) for low-power, low-end FPGAs [3], and Vivado (Vivado Design Suite) for the latest high-end FPGAs [4]. Specifically, ISE supports older FPGA series up to 7-series and some low-end 7-series FPGAs [3], while Vivado supports all 7-series and subsequent state-of-the-art FPGAs [4].

Table 1. Design Suites available for each FPGA series.

Family	Series	ISE	Vivado
Spartan	3	O	X
	6	O	X
	7	X	O
Virtex	5	O	X
	6	O	X
	7	Δ	O
	UltraScale	X	O
	UltraScale+	X	O
Artix	7	O	O
	UltraScale+	X	O
Kintex	7	O	O
	UltraScale	X	O
	UltraScale+	X	O

summarizes the FPGA-specific support Design Suite for each Xilinx FPGA, where Virtex and Kintex series FPGAs generally have larger chip sizes and are fabricated using more advanced processes compared to Spartan and Artix series FPGAs [5].

Through the diverse FPGA chip portfolio provided by FPGA manufacturers and the stability of EDA tools, FPGA applications have expanded significantly. However, SRAM-based FPGAs have a critical drawback, which is that they require external memory since their internal memory gets erased when power is cut off [6]. The process of transmitting the netlist in bitstream format from external memory during power-up in FPGA systems makes it vulnerable to malicious attacks like bitstream theft and tampering, as shown in Figure 1 [7,8,9]. The complete extraction of the bitstream enables the potential for a cloning attack, and tampering with the hardware results in malfunctions, leading to potential damage. Additionally, intelligent reverse engineering [10,11,12,13,14,15,16,17,18,19,20,21] can be utilized to analyze the design of the netlist. When a circuit is attacked, the circuit does not behave as intended, causing serious problems. In the case of reverse engineering, all circuit information is exposed to the attacker, causing serious problems with circuit security.

The previous FPGA reverse-engineering tools primarily focus on FPGAs supported by ISE, as shown in Table 1. The FPGAs that have been targeted by reverse engineering are mostly devices in the Spartan-3 series and Virtex-5 series in previous research [10,11,12,13,14]. This is because ISE provides of readable XDLRC (Xilinx Design Language Routing Configurable logic) and XDL (Xilinx Design language) files [22]. Note that the XDLRC file is a hardware structure file, and the XDL file is the netlist file provided by ISE. Based on XDLRC, the previous FPGA reverse-engineering techniques [10,11,12,13,14] identify the association between XDL and bitstream. The association is converted into a database that is used for reverse engineering. All hardware elements in the FPGA described in XDLRC appear in the bitstream, and the value is 1 in the bitstream only for the hardware elements used in XDL. The database is generated by modifying the XDL files that applying information on XDLRC and comparing bitstreams. Therefore, XDL and XDLRC files are essential for securing a database for reverse engineering. Although some reverse-engineering techniques using Vivado have been announced [15,16,17,18,19,20,21], the techniques are very limited and still at a rudimentary level. The reason the latest FPGA reverse-engineering techniques in Vivado are restricted and disturbed is the absence of textual netlist files such as XDLRC and XDL. Consequently, this paper proposes a method to generate XDLRC and XDL files in Vivado, similar to those in ISE, to extend the coverage of the previous reverse-engineering techniques. It is important to note that this paper does not encourage bitstream attacks through reverse engineering but rather highlights the risk associated with malicious attacks and emphasizes the importance of security. The remaining sections of this paper are organized as follows: Section 2 explains the structure of Xilinx FPGAs and the design flow of ISE and Vivado. In Section 3, we verify XDL and XDLRC files generated using ISE and propose a method to generate them using Vivado. Section 4 analyzes the differences between the files generated by the two EDA tools. Finally, Section 5 presents the conclusions of this paper.

2. Background

In Xilinx FPGA devices, the XDLRC file represents a textual description of all available hardware resources within the FPGA device, while the XDL file specifically details the activated resources among the entire hardware [22]. To properly comprehend XDLRC and XDL files, it is fundamental to grasp the fundamental structure of Xilinx FPGA devices. In this chapter, we provide a comprehensive overview of the inherent hierarchical structure of Xilinx FPGA architectures. Following that, we outline the sequential procedures for circuit synthesis, implementation, and bitstream generation using both the ISE and Vivado.

2.1. Structure of Xilinx FPGA

Xilinx FPGAs feature a hierarchical structure for their hardware resources, which can be simplified as depicted in Figure 2 [23,24,25,26,27,28,29,30]. The interior of the FPGA is composed of tiles. The positions of these tiles are defined using Cartesian coordinates (X, Y). The interconnections between tiles are fixed, and these static connections within the FPGA are referred to as conn. The input and output ports of the tiles are defined as wires, and the internal connections between wires are denoted as PIPs (Programmable Interconnect Points). Each wire can be connected to one or more PIPs, with the appropriate PIPs selected depending on the circuit implementation.

Within each tile, there is a sub-level block known as a site. The input and output ports of the site are defined as pin, and the connections between pins are also represented as conn. Inside the site, there is another sub-level block called an element. Like the site, the input and output ports of the element are composed of pins. Elements can either include or exclude a configurable logical option referred to as cfg. Among elements that include cfg, those responsible for constructing logic elements such as MUXs (Multiplexers) are called PLPs (Programmable Logic Points), while those supporting data storage functions like LUTs (Look-Up Tables) are termed PDPs (Programmable Data Points).

2.2. ISE Design Flow

The design flow in ISE, from circuit synthesis to implementation, is depicted in Figure 3. As shown in Figure 3, the ISE design flow comprises a total of five stages, each executed using Tcl commands. The process begins with synthesis, which requires HDL source files, including the design, and a UCF (User Constraint File) file specifying constraints. Once these two files are prepared, synthesis is initiated using the ‘xst’ command. After synthesis, an NGC (Native Generic Constraint) file is generated, combining the design and constraints.

Following that, the ‘ngdbuild’ stage is executed, which assigns the information described in the NGC file to the physical resources of the FPGA, generating the NGD (Native Generic Database) file, which includes routing and timing details in the form of a netlist. After this, during the ‘map’ stage, the physical resources outlined in the NGD file are mapped to real hardware components such as LUTs, MUXs, and BRAMs (Block RAMs). Finally, when the ‘par’ stage, responsible for P&R (Placement and Routing), is executed, it results in the generation of the netlist files, the NCD (Native Circuit Description) file, and the XDL file. While netlist files such as NGC and NGD, including the NCD file, are all in a binary format, the XDL file is in textual format, making it user-readable. Once the P&R process is completed, the netlist files can be transformed into a BIT file, which can be programmed onto the FPGA, via the ‘bitgen’ stage. It is noteworthy that, within the ISE, the XDLRC file, describing all available hardware resources within the FPGA, can be generated at any stage of the design flow after project creation.

2.3. Vivado Design Flow

Vivado, on the other hand, follows a design flow consisting of a total of seven stages, as depicted in Figure 4. In the Vivado design flow, it is essential to have both the HDL source, comprising the design, and the XDC file, detailing the constraints. Once these two files are prepared, circuit synthesis is performed using the ‘synth_design’ command. After synthesis, the implementation proceeds through five stages. As the initial step of implementation, ‘opt_design’ is performed to optimize the synthesis results, followed by ‘power_opt_design’ to further optimize from a power perspective.

Following that, ‘place_design’ is responsible for positioning the optimized design onto the FPGA hardware resources, while ‘phys_opt_design’ focuses on optimization with regard to physical placement. Afterward, ‘route_design’ manages routing, and the ‘write_bitstream’ stage generates the BIT file that can be programmed onto the FPGA. It is important to note that no netlist files, including XDL files, are generated during the synthesis and implementation stages in Vivado design flow, and XDLRC files are also not provided.

3. Netlist File Generation

The XDLRC is essential for understanding the hardware structure, and the XDL shows that the hardware elements appear in the bitstream as a readable netlist. These two files are extracted from ISE with a single Tcl command in ISE, but in Vivado, they are extracted with multiple Vivado Tcl commands. This section describes how to extract XDLRC and XDL files from ISE and Vivado.

3.1. XDLRC File Generated by ISE

An XDLRC file can be generated using a Tcl command in ISE, and the Tcl command to create an XDLRC file is as follows:

xdl -report [-pips] [-all_conns] <part> [<outfile name>]

The options [-pips] and [-all_conns] are used with the ‘xdl -report’ command. [-pips] generates a report containing pip routing information, while [-all_conns] displays all connections to a tile wire, regardless of the containing adjacent tile. The <part> parameter represents the FPGA device, and it should include the speed grade and package details. [<outfile name>] is an optional parameter; if not specified, the XDLRC file will be created with a default name following the pattern ‘<part>.xdlrc’.

As an example in this paper, the Artix-7 100t device, with a speed grade of −1 and 324 external I/O pads in the csg324 package, is used. If you want to generate an XDLRC file to list the tiles and sites included for this device, ‘xdl -report xc7a100t-1csg324’ should be executed to generate the XDLRC file. However, if you wish to obtain comprehensive information, including all pips, wires, and conns for the same device, ‘xdl-report -pips -all_conns xc7a100t-1csg324’ should be executed to generate the XDLRC file. Figure 5 provides an example of an XDLRC file generated using the options [-pips] and [-all_conns]. The XDLRC file, as seen in Figure 5, consists of three parts: the tile resource part, the primitive_defs part, and the summary part.

The Tile resource part represents all of the FPGA hardware resources at the tile level, starting from the tile at position (0, 0) and describing each tile position, tile name, and tile type. In Figure 5, line 7 begins to depict the internal structure of the tile located at (1, 10). The numbers 1 and 10 represent the X and Y coordinates of the tile, respectively. The subsequent CLBLL_L_X2Y199 indicates the tile name, with CLBLL_L denoting the tile type. The number, 2, signifies the number of sites contained within this tile. Line 8 provides information about the sites configured within the tile. The sites are declared as primitive_site. The SLICE_X1Y199 indicates the site name, SLICEL represents the site type, and internal 45 specifies that the site contains 45 pins. Lines 9 and 10 detail the site pins and wires. In the tile resource part, the internal structure of the tile is described by only the site pins. Following primitive_site, the wires associated with the tile are listed. At a lower level of wire, the conn describes how each wire is linked, specifying which tile wire it connects to. Therefore, through lines 12 and 13, we can discern that the CLBLL_CLK0 wire is connected to the CLK_L0 wire of INT_L_X2Y199 via the conn. The last line representing the tile includes the tile name, type, the number of pinwires, wires, and pips present in the tile.

In the primitive_defs part, the complete internal structures of all sites included in this device are shown. Line 19 marks the beginning of revealing the internal structure of the SLICEL site, with the numbers 45 and 140 following SLICEL signifying the respective counts of input/output pins and elements within the site. Each pin in the section describes the pin name, the associated pinwire name from the tile resource part, and whether the pin functions as an input or output represented in line 21 and line 22. The details of the elements appear, as seen in line 23, where the element name and a number denoting the number of pins within the element are provided. If there is a configuration present representing cfg in Figure 6, all configurations of the element are listed, like line 25. The conn of the elements represent the connections between pins of the elements. For instance, line 26 signifies the connection between the OUT pin of the D5FFMUX element and the D pin of the D5FF element. When the line beginning with the element name in the primitive_defs part is suffixed with # BEL, it indicates that this element serves as a basic element as representing bel in Figure 6, such as an LUT or an FF(Flip-Flop).

In the summary part, details regarding the number of tiles, sites, site types, site input/output pin counts, and the number of PIPs encompassed by this device are presented.

3.2. XDLRC File Generated by Vivado

In Vivado, there is no Tcl command like ‘xdl-report’ to generate an XDLRC file. However, through Vivado Tcl commands supported by Vivado, it is possible to obtain information about FPGA hardware resources and create an XDLRC file.

To construct the tile resource part of the XDLRC file, information about tile names, tile types, sites within the tile, wires and conns contained within the tile, and pips are required. To access this information, commands such as ‘get_tiles’, ‘get_sites’, ‘get_wires’, and ‘get_pips’ are demanded. These commands alone provide only the names of each component.

Identifying tile types and site types corresponds to particular attributes referred to as TILE_TYPE and SITE_TYPE. To access these properties, the ‘get_property’ command should be employed. It is important to note that extracting information about fixed connections conn with Tcl commands in Vivado is not feasible.

The primitive_defs part, which describes the internal structure of each site type, requires information about the pins within the site, the cfg of elements, conn, and whether an element is a bel. Information regarding the pins within a site can be obtained through the use of the ‘get_site_pins’ command. The configuration of an element, which represents the programmable points within the site, can be obtained using the ‘get_site_pips’ command. Elements that are bels can be distinguished using ‘get_bels’. However, it is important to note that extracting conn, similar to the tile resource part, is not feasible through available commands.

Figure 6 illustrates the process of generating an XDLRC file in Vivado as a flowchart. To create the tile resource part, the process of extracting the required information for each tile is repeated for all tiles. For the primitive_defs part, the process of discovering internal site details is repeated for each site type. The summary part determines the count of each component using the Tcl command ‘llength’. Through these steps, the XDLRC file was created in Vivado, as shown in Figure 7.

3.3. XDL File Generated by ISE

The TCL command for creating an XDL file using ISE is as follows:

xdl -ncd2xdl [-nopips] <ncdfile name> [<xdlfile name>]

[-nopips] is an option for the ‘xdl-ncd2xdl’ command that suppresses the reporting of PIPs, and <ncdfile name> is the name of the netlist file generated after performing P&R, typically matching the top module name. [<xdlfile name>] is an optional parameter to specify the output file name. If the output file name is not specified, an XDL file with the same name as the NCD file is generated. For instance, if the top module name is ‘TestDesign’ and you want to generate an XDL file for this module with the name ‘TestDesign_v1.xdl’, the Tcl command should be written as follows: ‘xdl -ncdtoxdl TestDesign.ncd TestDesign_v1.xdl’. An example of an XDL file generated using the ‘xdl-ncd2xdl’ command in ISE is illustrated in Figure 8 and is structured in four parts: the design part, the instance part, the net part, and the summary part. In the design part, information such as the design name, device type, and the version of ISE are presented.

The instance part displays hardware resources used in the design implementation at the cell. A cell can be either a primitive or a hierarchical instance within a netlist. Examples of cells include FFs, LUTs, I/O buffers, and hierarchical instances. The first line representing information about a single cell, as seen in line 11 of Figure 8, and includes the cell name, the site type and site name where the cell is implemented, and the name of the tile where it is located. Following the keyword cfg on the next line are all PLPs contained within the site, used for the circuit implementation, listed along with their respective configurations. Unused PLPs are marked with #OFF in the configuration string, while PDPs display data stored as Boolean functions.

The net part encompasses all the necessary nets for circuit implementation. Most of these nets, as seen in the green lines of Figure 9, represent a collection of all the PIPs required to connect an outpin from site A to an inpin in site C. In this context, the connections along this path, conn, are not explicitly detailed in the net part since their routing is predetermined. Therefore, when these nets are represented in XDL, each green line is described with one outpin, one inpin, and three PIPs. For instance, let us consider the O_OBUF net from Figure 8 when examining Figure 9. In this case, pin A in line 31 of Figure 8 corresponds to the outpin of site A in Figure 9, and pin O in line 32 of Figure 8 corresponds to the inpin of site C in Figure 9. These two pins are interconnected by the five PIPs detailed from line 33 to line 37 in Figure 8. However, nets connected to input and output pads, as illustrated in line 28 and line 29 of Figure 8, provide information solely about the pads themselves.

3.4. XDL File Generated by Vivado

To generate an XDL file in Vivado, several Vivado Tcl commands that allow obtaining the necessary information, like with XDLRC, should be used. To obtain the necessary information for the design part in Vivado, the following commands are required: ‘find_top’ for retrieving the top design name, ‘get_parts’ for obtaining the FPGA device name, and version to fetch the tool version. For the instance part, the cell names can be identified using the ‘get_cells’ command. Information about the site type, site name, and tile name containing the cell can be acquired, similar to XDLRC, by utilizing the ‘get_property’, ‘get_sites’, and ‘get_tiles’ commands. The ‘get_site_pips’ command should be used to obtain information about the PLPs within a site, ensuring the inclusion of the ‘-filter {IS_USED}’ option to focus on the activated logic necessary for circuit implementation. The data stored in PDP can be revealed in hexadecimal format using the ‘get_property’ INIT command.

The information needed for the net part can be acquired using the following commands: ‘get_nets’ for net names, ‘get_pins’ for pins, and ‘get_pips’ for PIPs. When obtaining information about pins and PIPs, like with PLP, it is essential to include the ‘-filter {IS_USED}’ option to extract only the active pins and PIPs, similar to in the instance part.

Figure 10 represents the flowchart of the XDL file generation process in Vivado. It involves obtaining information about the design part, followed by iterating through the process of obtaining all the information about cells and nets required for the instance part and the net part. Through this process, the XDL file generated in Vivado appears, as shown in Figure 11.

4. Analysis

In this paper, experiments were conducted using the Artix-7 100T device with a speed grade of −1 and the csg324 package. ISE version 14.7 and Vivado version 2020.2 were employed for the generation of both XDL and XDLRC files.

4.1. Comparison of XDLRC

If you create XDLRC with two EDA tools for the same FPGA, as shown in Figure 12, Figure 12a shows the XDLRC file generated by ISE, and Figure 12b shows part of the XDLRC file generated by Vivado. The components shown highlighted in blue in Figure 12 mean that they appear exactly the same in both files. In the tile resource part, the tile name, the tile type, the site type that constitutes the tile, the wire of the tile, and the PIP inside the tile are the same. In the primary_defs part, the site type, the site pin, and the elements including PLP or PDP inside the site are the same. On the other hand, in Figure 12, the component highlighted in red, the conn of the element, and the pin of the element can be checked in the XDLRC file generated by ISE with fixed connections, but not in the XDLRC file generated by Vivado, which only shows information related to programmable points. For example, it was figured out that the LIOI3_SING_X0Y199 tile contains one primitive_site, OLOGIC_X0Y199, with three inputs, including CLK, D2, and D1 and two wires and three PIPs through Figure 12a,b, while three conns of the wire IOI_CLK1_0 and one conn of the wire LIOI_T0 are only seen in XDLRC extracted from ISE, as shown in Figure 12a. The components contained in the primitive_site OLOGIC_X0Y199 appear the same in Figure 12a,b except for conn and pin of the element.

For most tiles, the basic structure appears the same in the XDLRC files generated by both EDA tools, as shown in Figure 12. However, sites that do not contain PLP or PDP cannot be verified in the XDLRC file generated by Vivado. In addition, if the connection between start wire and end wire is determined to be only one of the PIPs, the PIPs cannot also be confirmed in the XDLRC generated by Vivado because the connection operates as fixed. In summary, only when programmable points among the components are identified in the XDLRC file generated by ISE can the XDLRC generated by Vivado be verified.

4.2. Comparison of XDL

To generate XDL files, an RTL design is essential. In this paper, a design instantiated with one six-input LUT primitive, as shown in Figure 13, is used as an example design to generate XDL files. The six-input LUT primitive, which employs six inputs and one output and utilizes a single LUT, is configured with an INIT value of 64’h0000_0000_0000_0001.

The XDL files generated by the two EDA tools are compared in Figure 14. In the comparison, information that is identical in both files is highlighted in blue, and information unique to ISE is emphasized in red. Additionally, the content highlighted in yellow represents information present in both files but with differing names.

In the XDL file generated by ISE, the PLP and PDP used in the SLICE_X0Y145 site of CLBLL_L_X2Y145 tile, implementing the O_OBUF logic, are identical. Note that, in the case of PDP, it is all expressed as a Boolean function in ISE, but in Vivado, it is expressed as hexadecimal. However, dummy cells that do not use logic are confirmed in XDL generated by ISE by adding the keyword DUMMY in line 18 to line 20 of Figure 14a, but not in XDL generated by Vivado because logic is not used. For the net part, the two files are identified as the same number of nets and the same name. However, some pins for the input/output of the net, such as the A5 pin in line 30 of XDL generated by ISE, as shown in Figure 14a, are represented differently in the XDL file produced by Vivado, appearing as I5 in the line 18 of Figure 14b. Regarding the PIPs, which consist of the net, while the PIPs connected to input and output pins are the same in both files, as shown in Figure 14a,b, some PIPs that constitute the internal connection of the net differ due to variations in the P&R algorithms of the ISE and Vivado. For example, the I5_IBUF net represents the net for the I5 input of the six inputs in Figure 11, from the IOI (Input/Output Interface) tile where I5 is connected to the CLB tile where the six-input LUT is implemented. The IOI tile and the CLB tile are not connected directly but through an interconnect tile, the INT tile. As shown in the two files in Figure 14, the wires where the I5_IBUF net starts are the same as the LIOI_IBUF1 wire in the ILIOI3_TBYTESRC_X0Y143 tile. However, the net ends at tile CLBLL_L_X2Y145, but the wires are different: CLBLL_LL_A5 in Figure 14a and CLBLL_LL_A2 in Figure 14b. In other words, the input pins of a six-input LUT described as I5 in the HDL are connected differently to the input wires of the CLB where the LUT is implemented, even though they are placed in the same IOI tile in ISE and Vivado. In addition, some of the PIPs from the LIOI_IBUF1 wire to the destination wire are different due to the different termination points. The reason for the different connections is due to the different routing algorithms mentioned earlier, which only affect the configuration of the network.

In summary, while there are differences in dummy cells and PIPs due to variations from the P&R algorithms, both XDL files generated by ISE and Vivado present all the necessary information for logic implementation in an identical manner. Consequently, the circuits represented in both XDL files are logically perfect and the same.

5. Conclusions

In this paper, a method for generating textual netlists in both ISE and Vivado is proposed. When comparing XDL and XDLRC files generated from ISE and Vivado using the proposed method, it is found that XDLRC files match by 99% for programmable points such as PLP, PIP, and PDP. In the case of XDL files, there is approximately a 75% match between files generated by the two EDA tools. The remaining 25% mismatch is attributed to differences in dummy cells and routing algorithms. However, these differences in XDL files do not impact the functionality of the circuit when using each respective XDL file for circuit reconfiguration.

This paper demonstrates that through the proposed method, textual netlists generated from Vivado contain the same programmable point information as those from ISE. It is possible to extend the application scope of the previous reverse-engineering tools to cover devices supported by Vivado, as essential textual netlists can be obtained from both ISE and Vivado. This indicates that the scope of previous reverse-engineering techniques can be extended. Therefore, we believe that the XDLRC and XDL files generated by the proposed method can be used to develop reverse-engineering techniques for FPGAs supported by ISE and Vivado simultaneously. It is also expected that a basis will be provided for developing reverse-engineering techniques for FPGAs supported only by Vivado.

Finally, this paper does not encourage malicious bitstream attacks through reverse engineering but rather highlights the risk associated with malicious attacks and emphasizes the importance of security measures. In addition, in terms of reverse engineering the design implemented in the FPGA, it can help researchers understand the feasibility of such attacks from the white hacker side and develop countermeasures against such methods.