An Integrated Environment for Analysis of Fault Effects in FPGA Routing

(1)

UNIVERSITÀ DI PISA

Scuola di Ingegneria

Laurea magistrale in Ingegneria Informatica

Master’s thesis

Academic Year 2016/2017

Supervisors

Prof. Cinzia BERNARDESCHI

Prof. Andrea DOMENICI

Prof. Luca STERPONE

An Integrated Environment for Analysis of Fault Effects in

FPGA Routing

Candidate

Corrado DE SIO

(2)

Abstract

In the last years, FPGAs have been heavily used in many different critical applications, such as spatial and military ones, where these devices operate in harsh environments. For this reason, research studies about faults (detection, recovery, modelling etc.) in FPGA technology are of primary concern.

The main objective of this thesis is the development of an integrated environment for the analysis of fault effects in FPGA routing. The integrated environment has been developed as a Python library, named PyXEL, that integrates Xilinx Software, such as Vivado and ISE tools, and exploits a strong know-how to carry out experiments on routing faults in FPGAs in an automated way. In particular, PyXEL provides an easy way to execute design manipulation, fault injection, bitstreams manipulation, collection and analysis of results.

Furthermore, PyXEL has been used for the analysis of fault effects in the interconnec-tion network of the Xilinx Artix-7 XC7A100T FPGA. Routing faults such as conflicts and opens have been injected in the FPGA using randomly chosen Programmable-Interconnect-Points (PIPs). The experiments conducted show that it is possible to use PyXEL in order to gain insight into the real behaviours of fault effects in FPGA routing.

(3)

Acknowledgements

First of all, I would like to thank Prof. Cinzia Bernardeschi for her precious support and her advice for the development of this thesis. A special thanks goes to Prof. Luca Sterpone and Ludovica Bozzoli for helping and guiding me during these last months. I would thank Jacopo, Chiara and Maria for helping me with the revision of this work. I thank my family, my parents, my brother and sisters because they always supported me, as well as my aunts and cousins. Thank you for your guidance and support, there are no words that can describe how grateful I am.

I also thank my friends Amedeo, Marco, Marco, Michela. They supported me for all this years and I am sure that if I am here I owe it to you as well.

I want to also thanks Eli, Jacopo and Riccardo. I always enjoy my days with you, guys. So, thanks to you and to all the Osbstinate, since it is always better to have fun together.

Thanks to Maria for making these last months more happy and peaceful.

A special thanks to my friends in Pisa: Matteo, Angela, Pierluigi, Michele, Giulia, Anna, Francesco, Luana, Sabina, Simona, Rosanna, Rossella, Simone, Cosimo, Angelo and Mariano. I am so glad you were there.

(4)

List of Figures

2.1 Structure of a FPGA . . . 13

2.2 Switch matrices and CLBs . . . 14

2.3 CLBs structure . . . 15

2.4 Switch Matrix structure . . . 16

2.5 PIP properties in Vivado . . . 17

2.6 FPGA design flow . . . 18

2.7 Topological Faults in a switch matrix . . . 20

2.8 ISE FPGA design flow . . . 22

2.9 Netlist and device objects in Vivado . . . 24

4.1 PyXEL_Viv Input and Output Files . . . 32

4.2 Starting Designs showed in Vivado . . . 33

4.3 Modified Design created by PyXEL through Vivado with PIPs under test in tile X12Y169 . . . 33

4.4 Particular of modified design, switch matrix in tile X12Y169 of Figure 4.4 34 4.5 PyXEL_Xdl Input and Output Files . . . 35

(8)

4.6 PyXEL_Bin Input and Output Files . . . 36

4.7 PyXEL_Run Input and Output Files . . . 37

4.8 PyXEL Integrated Environment Map . . . 39

4.9 Create a configuration with 2 PIPs combining two configurations of one PIP . . . 40

5.1 FPGA test application scheme . . . 43

5.2 A general workflow for fault injection experiments . . . 44

5.3 Switch Matrix configurations tested to verify bitstream modification . . 46

5.4 Analysis of results for bitstream manipulation test . . . 49

5.5 Open Faults . . . 52

5.6 View of the junctions and PIPs used in conflict faults . . . 54

(9)

List of Tables

5.1 Some of the PIPs used in bitstream manipulation experiments . . . 49 5.2 Results of experiments on conflict faults . . . 57

(10)

Introduction

The use of FPGAs in critical applications is increased in the last decades. In particular, SRAM-FPGAs feature a high flexibility due to the possibility to be reprogrammed via software and they are often used in the aerospace industry for their capability of allowing system reconfiguration.

However, when FPGAs are used in space applications, they are exposed to radiations, therefore soft faults can affect the configuration memory of the device. These faults may cause a wide range of effects and the implemented functionalities may be modified. In this thesis, we will focus on routing faults inducted by SEUs (Single Event Upset) in the configuration memory of the FPGA. Routing resources account for the largest part of FPGAs structure, almost the 80% of transistors in FPGAs are related to the programmable routing network.

Fault effects are usually modelled and simulated either via software or via experiments on real devices. Anyway, these activities need deep knowledge about FPGAs structure and their configuration memory. Furthermore, testing on real devices is time-consuming and hard to execute, and software suites are moving to a higher level of abstraction and this makes low level information, such as resources availability and place and route implementation, more difficult to be accessed.

(11)

The objective of this thesis is to build an integrated environment, named PyXEL, for the development of experiments on routing faults in physical Xilinx FPGA devices. Experiments on FPGA routing are usually conducted exploiting Xilinx Description Language (XDL). XDL allows to operate on the routing resources of the design and makes it possible to inject faults and retrieve resources information.

However, since Xilinx Series 7 FPGAs release, Vivado is slowly replacing ISE Design Suite as the main EDA (Electronic Design Automation) software. Vivado presents a high level of abstraction, a strong integration between the steps of the FPGAs design flow and integrates the Tool Command Language (tcl) for executing operations and retrieving information about resources. Therefore, for new FPGA families, the injection of faults in the routing structure and their analysis have become more complicated. PyXEL wants to exploit new features of Vivado to create an integrated environment that allows to carry out experiments about routing faults on real FPGAs in an auto-mated, simple and not error-prone way. Several experiments and test have been conduc-ted to create a simple method to act on routing resources using bitstream manipulation through bitmaps. The know-how acquired on the Xilinx software and the practical work on FPGA architecture analysis made it possible to develop and implement PyXEL. Finally, PyXEL has been used in some experiments on the Xilinx Artix-7 XC7A100T real device, in order to gain insight into the logic behaviour of faults in the routing structure of this FPGA family.

Thesis Overview

Chapter 2 presents background concepts about FPGAs, their architecture and pro-gramming. Moreover, notions about faults and their effects are illustrated. Finally, some information regarding Xilinx software and the FPGA bitstream is given.

Chapter 3 introduces previous work related to subjects discussed in this thesis. Some studies are illustrated in order to provide notions on problems and to present already developed solutions.

(12)

Chapter 4 describes PyXEL, the integrated software environment developed in this thesis. We will describe the architecture of the integrated environment and how to carry out experiments on FPGAs using PyXEL. Notions about the idea, the implementation and the usage of bitmaps in PyXEL will be also given.

Chapter 5 focuses on experiments about fault effects on FPGA routing carried out with PyXEL. One of the results of the thesis has been the identification of the logical effects of these faults on a real device. A brief analysis of the results of the experiments will be also provided.

(13)

Background

2.1 Field Programmable Gate Array

Field Programmable Gate Arrays (FPGAs) are integrated circuits with a large number of resources, that can be programmed by designers to implement complex hardware. The main feature of these devices is the possibility to be reconfigured with new ap-plications over and over. The flexibility given by the reconfigurability allows FPGAs to compete with ASIC technology. Strengths of FPGAs include lower NRE (Not-recurring expenses), a shorter time-to-market and the possibility to solve errors deeper in the implementation process and with less costs. Initially, FPGAs were used mainly for prototyping, but in the last years their increasing performances made them a com-mon choice for many different applications such as Aerospace, Automotive, Military, Medical and more.

2.1.1 Architecture

It is necessary to clarify that FPGA architecture is vendor dependent. In this thesis we will focus on Xilinx 7 series and in particular on Artix 7 FPGA family[1]. Nevertheless, most of the concepts presented below are still true or can be generalised for the majority of vendors and devices.

(14)

The FPGA architecture is very regular and is organised as a matrix of tiles as shown in figure 2.1.

Tiles are rectangular components that compose a FPGA. They include different ele-ments with different functionalities and can be divided in three groups:

• Logic Blocks

• Interconnection Network • IO Blocks

Figure 2.2 shows specific elements contained in a tile, such as switch matrices and logic blocks.

(15)

Figure 2.2: Switch matrices and CLBs

2.1.1.1 Logic Blocks

FPGAs contain components that are specialised for specific functions as well as more general purpose configurable logic blocks. The most common logic blocks in FPGAs are the CLBs (Configurable Logic Blocks). CLBs are composed of several elements such as multiplexer, LUTs and flip-flops as shown in figure 2.2. Storage and logic functions

(16)

are implemented in the CLBs.

Many other elements, with more specific roles, belong to the logic blocks group such as DSPs and BRAMs. Logic blocks are connected to each other and with IO blocks through the interconnection network.

Figure 2.3: CLBs structure

2.1.1.2 Interconnection Network

In FPGAs, the interconnection network is composed of two main elements: PIPs and nodes.

The nodes are permanent, not programmable, wires that connect logic elements, switch matrices and IO elements to each other. Each switch matrix has several nodes as input and others as output which connect the switch matrices to other switch matrices, logic blocks or IO blocks.

In switch matrices, programmable-interconnection-points (PIPs) can be programmed to connect nodes for creating paths that link various elements. Figure 2.4 shows a particular of a switch matrix and some PIPs.

(17)

Figure 2.4: Switch Matrix structure

2.1.1.3 IO Blocks

IO blocks are the components that implement the connection between the internal FPGA elements and the outside. It consists of input and output pad and can be programmed to perform input or output functions. Flip-flops are present on the output in order to send clocked signals to the pins without delay. Flip-flops are also present on the inputs in order to reduce delay on a signal before reaching a flip-flop. The presence of these flip-flops allows to reduce the time requirements of the FPGA. [2].

2.1.2 Programmable-Interconnection-Points (PIPs)

Programmable-Interconnection-Points (PIPs) are the main elements to program routing in FPGAs. A PIP can be programmed to connect two junctions in the same switch matrix. A junction belongs to a switch matrix and to a single node, so when a PIP is programmed, it links two nodes.

(18)

A PIP can be identified univocally by its tile and its junctions. Usually a PIP is named using the format: Source_junction -> Destination_junction. More PIPs can have junctions in common. Figure 2.5 shows the main properties of PIPs provided by Vivado, such as the nodes related to the PIP (“First node” and “Second node”) and its tile[3].

Figure 2.5: PIP properties in Vivado

2.1.3 FPGA design flow

FPGA is programmed by loading a bitstream into the configuration memory of the device. A Bitstream contains information about which resources are utilised in the FPGA.

(19)

A Bitstream is a binary sequence that is generated by tools provided by the vendor, but FPGA vendors do not disclose details about its structure. Several steps have to be followed in order to generate a bitstream. A typical design flow is shown in figure 2.6.

Figure 2.6: FPGA design flow

To start, a hardware circuit is coded using a hardware description language (HDL), usually VHDL or Verilog. The HDL description defines the circuit behaviour or its structure. From HDL description a logic block description is built through the synthesis phase.

Then, in the implementation phase, logic blocks are mapped on the physical resources of the FPGA and routing resources allocation is performed. At this point, a bitstream can be generated. Using the bitstream, the circuit coded in HDL (step one) can be programmed into the FPGA.

(20)

Vivado or ISE for Xilinx FPGAs.

2.2 Faults in FPGAs

2.2.1 SEUs

High energy particles hitting the silicon areas of memory elements, mainly SRAM, can cause a Single Event Upset (SEU). A SEU is a transient bit flip in a memory cell of a FPGA that is usually overwritten at the next clock cycle. Anyway, when this bit flip occurs in the configuration memory of the FPGA, it may have a long term effect compromising the functions and the interconnections programmed in the FPGA. In fact, the configuration memory could be never written again after the first configur-ation or there could be a long time between consecutive reconfigurconfigur-ations and the SEU may alter the FPGA functionalities and outputs.

When FPGAs operate in a space environment, they are exposed to a high incidence of bit flips causing concerns about their reliability and safety. An early study of these effects on safety-critical applications allows adopt fault tolerance technique. To do this, classification and analysis of faults are fundamental[4].

2.2.2 Topological Faults in Routing

A large part of the configuration memory in FPGAs is dedicated to routing resources. When SEUs occur in sections of the configuration memory associated to a switch matrix, the switch matrix’s configuration may change. Specifically, depending on the position and the electrical properties of a PIP, different topological modifications may occur. In [5, 6], topological modification, caused by bit flips of configuration bits controlling PIPs’ state, are modelled as shown in figure 2.7.

(21)

Figure 2.7: Topological Faults in a switch matrix

Starting from the original configuration, the following topological faults are identified:

Open A PIP that was programmed is deleted.

Antenna A PIP that was not programmed is now activated between a not used source

junction and a used destination junction.

Conflict A PIP that was not programmed is now activated between a used source

(22)

Bridge A PIP that was programmed is now deleted. A new PIP is activated between

a used source junction and the destination junction of the PIP just deleted.

2.3 Xilinx Software

2.3.1 ISE Tools and XDL

ISE[7] is a software suite distributed by Xilinx that implements FPGA design flow. Since 2012, Vivado Design Suite has started to replace ISE. Xilinx released the last version of ISE in October 2013 and there are no more planned releases. A simplified ISE design flow is composed of the steps shown in figure 2.8

(23)

Figure 2.8: ISE FPGA design flow

What we obtain as results after the MAP and PAR step is a ncd (native circuit de-scription) file. The ncd file obtained is a physical representation of the HDL design to be implemented on the Xilinx FPGA, and describes how logical and routing resources of the FPGA have been allocated.

(24)

In ISE, a ncd file is needed to generate a bitstream in order to program FPGAs. Ncd files are encrypted and compressed and their format is proprietary and not human-readable. However, together with ISE, some tools are distributed and allow to visualise the physical representation of the design saved in a ncd file (FPGA Editor) or translate ncd files in xdl files (xdl command language).

Xilinx Design Language (XDL) is a proprietary language created by Xilinx used to describe a FPGA design in a human-readable format. XDL can be generated from a ncd file using xdl tool and vice versa. Xdl file can be used to observe how place and route step has been implemented. Moreover, by acting on xdl files it is possible to manipulate placed and routed designs[8].

It is possible to translate manipulated xdl files in ncd files in order to generate the associated bitstream. By comparing bitstreams generated by different xdl files is pos-sible to gather relevant information on bitstream generation that FPGA vendors rarely share.

Furthermore, using xdl tool it is possible to generate XDL reports (xdlrc files) in order to give a description of all FPGA resources and their connections to each other.

2.3.2 Vivado and tcl

The Vivado Design Suite is the new Xilinx Software for FPGA design and it improved the capabilities of ISE Design Suite. Going forward Vivado will replace ISE completely, indeed series 7 is the last FPGA series supported by ISE. Any support to xdl and ncd files has been removed from Vivado, preventing any form of backward compatibility. However, a significant improvement in Vivado is the introduction of a Tool Command Language (tcl) interface. Tcl is a high-level language designed to be simple and power-ful, and it allows to use an objected-oriented approach in Vivado[3].

Figure 2.9 shows a schema of the objects implemented in the tcl version of Vivado. The objects can be retrieved through their relations (e.g. from a tile object I can obtain the PIPs that belong to it).

(25)

Figure 2.9: Netlist and device objects in Vivado

With tcl, it is possible to automatise any action performable through graphical user interface (GUI). Tcl can also be used to retrieve information about resources of the FPGA and execute operations on them. The possibility of coding scripts and run them in Vivado batch mode is a precious feature (not present in ISE), which provides a way to interface Vivado with other software and improves automation.

(26)

Related Work

This chapter provides a brief overview of previous work related to topics discussed in this thesis.

In particular, three main groups of research activities can be identified: the first group includes work related to bitstream generation and bitstream reverse engineering; the second group covers some work related to model, analysis and simulation environments for faults in FPGAs; the third group includes software applications developed in order to integrate or emulate Xilinx EDA (Electronic Design Automation) software.

3.1 Bitstream

Bitstream decoding and manipulation is a hard topic. The lack of information from FPGA vendors about bitstream generation steps and on how resources are mapped in the configuration memory makes going from bitstream back to netlist or develop applications for bitstream generation a laborious activity.

A tool, named debit, has been developed by Note and Rannaud[9] in order to obtain a xdl file through bitstream decompilation for Virtex-5 by using a cross-correlations algorithm.

(27)

In Open-Source Bitstream Generation for FPGAs by Ritesh K Soni[10], it is shown a new approach to obtain a bitstream file for Virtex-5 and Virtex-7 from a placed and routed xdl file, in order to obtain a faster and more embedded oriented way to generate bitstreams.

3.2 Fault Effects Model and Simulation Environments for

Routing Faults Analysis

Accurate models for topological modifications in FPGAs routing structure caused by SEUs in the configuration memory have been presented in [6, 5]. These classifications of faults have been used by several simulators for modelling errors in configuration memory of FPGAs.

In particular, ASSESS (a digital circuit simulator for the study of soft errors in the configuration memory of SRAM-based FPGAs) uses the previous models for topolo-gical and electrical effects in logic and routing[11]. ASSESS works at the netlist level, showing the logical connections but not the physical routing. Logic effects in the net-list caused by faults affecting routing resources are made possible by using E2_STAR. E2_{STAR[12, 13] is able to associate topological modifications of routing resources to} lo-gic effects. Moreover, E2_{STAR is able to map SEUs occurring in memory configuration} with topological modification affecting routing structure of the device.

More recently UA2_{TPG, a static analysis tool for the untestability proof and automatic} test pattern generation for SEUs in the configuration memory of SRAM-based FPGAs, has been developed adopting fault models implemented in E2_{STAR tool[14].}

E2_{STAR tool has been used in online testing approach too, like OLT(RE)}2_{, an online} on-demand approach to test permanent faults induced by radiations in the routing resources of SRAM-based FPGAs [15].

(28)

3.3 Software Applications

RapidSmith[16] is a research-based open source FPGA CAD tool written in Java for modern Xilinx FPGAs. Based on XDL, its objective is to serve as a rapid prototyping platform for research ideas and algorithms related to low level FPGA CAD tools[17]. Anyway, RapidSmith is fully based on XDL that is not supported any more in Vivado Designed Suite.

Another effort in order to interface Vivado with third parties CAD-tools to design FP-GAs through XDL has been conducted in Vivado Design Interface: Enabling CAD-Tool Design for Next Generation Xilinx FPGA Devices by Thomas James Townsend[18]. An attempt to obtain backward compatibility between Vivado and XDL format has been shown in Viv2XDL[19].

An approach based on tcl, instead of XDL, for the implementation of CAD-tool within Vivado has been made using Tincr[20]. In addition, Tincr also provides the ability of importing and exporting XDL- and XDLRC-like information to and from Vivado[21]. RapidSmith2, the Vivado successor to RapidSmith, has been implemented using Tincr. Unlike RapidSmith, which was based on XDL, RapidSmith2 exports/imports design data from/to Vivado using Vivado’s built-in Tcl interface[22].

Anyway, all these frameworks and software applications work at a high level of abstrac-tion and focus more on design manipulaabstrac-tion and integraabstrac-tion of third parties CAD-tool in the design flow than on bitstream generation, analysis or manipulation.

Recently COMET, a configuration memory tool to analyse, visualise and manipulate FPGAs bitstream[23] has been developed. COMET features powerful functionalities for relating resources in series 7 FPGAs and bits in the configuration memory and for performing bitstream manipulation.

(29)

PyXEL: A Python Library to

perform experiments on Xilinx

FPGAs

4.1 Introduction

Nowadays FPGA industry provides a large collection of software to support FPGA designers in the developing process from design to implementation. Since the release of Xilinx 7 series FPGAs, Vivado is the new software suite for FPGA design flow and is replacing Xilinx ISE Design Suite.

The higher level of abstraction and the replacement of XDL with the more powerful and simple tcl in Vivado are seen as an issue by the research community. Indeed, Xdl was largely used to obtain a description of FPGA resources in a human-readable format and a large number of third parties software utilised XDL to perform a lot of different tasks such as fault injection, bitstream reverse engineering and design modification for easily interfacing themselves with the Xilinx Software.

In this chapter we describe PyXEL, a software developed with the purpose of exploiting Python, ISE tools, tcl and Vivado Design Suite to provide an easy and automatised

(30)

way to operate experiments and fault analysis on bitstreams and designs.

The combination of ISE and Vivado allows to build a powerful integrated environment for conducting experiments and research activities focused on the analysis of the effects of FPGAs routing faults.

4.2 PyXEL

PyXEL (Python Xilinx-FPGAs Environment Library) is a collection of functions that integrates Vivado and ISE tools (xdl and bitgen) and exploits strong know-how with the purpose of building an integrated environment where the creation of automatised repro-ducible experimental workflows is simple and not error-prone. PyXEL has been written in Python[24]. Python is a high-level programming language for general-purpose pro-gramming that is frequently used as a scientific scripting language thanks to the large support from scientific libraries. However, the concepts we have used are very general and it is possible to use any program language. With PyXEL, we want to create an environment where users can code complex experimental workflows for FPGAs with the possibility to operate with resources under test manipulation, faults injection, PIPs activation and deactivation, bitstream analysis and modification, collection and ana-lysis of results. Additionally, we want to make available the use of a strong and simple programming language to implement any users’ need on-the-fly.

4.3 Architecture

In order to show the structure of PyXEL we have to describe two main elements: the files that are used by PyXEL (as input, output or information storage) and the modules that compose PyXEL.

(31)

4.3.1 PyXEL Files

In order to execute a lot of different tasks and integrate different software, PyXEL works with several files. Some of them are used as input or output where others are created on-the-fly by PyXEL. The Python module os.py is used to refer and locate the files in the file system. Files are univocally identified by their paths. Most of the files are strictly related to the FPGA device and to the resources under test, those files are created by the Xilinx Software.

4.3.1.1 Vivado Related Files

.dcp files dcp (design checkpoint) files are used in Vivado to save the stages of a

FPGA design flow, such as a synthesis or an implementation.

.xdc files xdc (Xilinx Design Constraints) files are used in Vivado to list design

con-straints and are written in tcl. In PyXEL .xdc files are used to impose concon-straints on resources that have to be used, such as PIPs or flip-flops.

4.3.1.2 ISE Related Files

.xdl files xdl files are written in XDL and describe FPGA designs in a human-readable

form. It is possible to act on xdl files to modify designs or generate ncd files.

.ncd files ncd files are files used by ISE Design Suite that represent a physical design.

From a ncd file it is possible to obtain a xdl file (and vice versa) as well as a binary file to program the FPGA.

4.3.1.3 Binary Files for Configuration (bitstreams)

.bit files bit files are binary files. The bitstream is loaded in the FPGA configuration

memory of the device during its programming phase .

.bin files Bin files are binary files which are very similar to .bit files. They share

(32)

header. For this reason, it is easier to modify them. PyXEL works mainly on .bin files instead of .bit files without any loss of precision, functionality or generality.

4.3.1.4 Bitmaps

Bitmaps are binary files used and created by PyXEL modules. Their role is to highlight some bits in the bitstream for identifying bits related to a specific resource of the FPGA. Most of the bitmaps are built on-the-fly by PyXEL and stored using the file system. How bitmaps are generated and used is illustrated further in section 4.5.

4.3.2 PyXEL Modules

Six modules compose the architecture of PyXEL. Each module is a collection of func-tions which interact with specific software or act on specific files in order to support users in the implementation of experimental workflow steps.

4.3.2.1 PyXEL_Viv

PyXEL_Viv is a module that implements resources under test manipulation, using tcl to interact with Vivado. In order to obtain designs that use particular resources, a starting design has to be provided by the user, together with a set of PIPs or couples of PIPs and a switch matrix under test. Through PyXEL_Viv, it is possible to modify the starting design to create a set of new designs where PIPs (or couples of PIPs) chosen by the user are used. PyXEL_Viv allows to generate design checkpoint files, constraints files, ncd files or binary configuration files for these new designs. Figure 4.1 shows the architecture of the PyXEL_Viv module.

(33)

Figure 4.1: PyXEL_Viv Input and Output Files A brief description of the functions shown in figure 4.1 follows:

Rut2Xdc, RutRut2Xdc modify a starting design in order to obtain a modified

design where PIPs passed as parameters are used. A view in Vivado of the starting and modified designs is shown in figure 4.2 and 4.3. Figure 4.4 shows a particular of figure 4.3 where resources under test belonging to the switch mat-rix are used. Rut2Xdc and RutRut2Xdc generate a design checkpoint file and a design constraint file for the modified design.

(34)

Figure 4.2: Starting Designs showed in Vivado

Figure 4.3: Modified Design created by PyXEL through Vivado with PIPs under test in tile X12Y169

(35)

Figure 4.4: Particular of modified design, switch matrix in tile X12Y169 of Figure 4.4

Rut2Bin, RutRut2Bin execute the same tasks of Rut2Xdc and RutRut2Xdc but a

binary configuration file is generated.

Xdc2Ncd, Xdc2Ncd_2r allow to generate a ncd file from a xdc file describing a

fully placed and routed design. Vivado 2012.4 need to be used for this task. The functions listed above are capable of managing single input files, lists of input files or directories. Directories are handled in the same way as the list of all the files in that specific directory.

4.3.2.2 PyXEL_Xdl

PyXEL_Xdl is a module to act on xdl files. It allows to modify xdl designs and to generate ncd, bit and bin files from xdl files using ISE software tools (xdl and bitgen).

(36)

Using PyXEL_Xdl, it is possible to inject open faults in a xdl file and generate the bitstreams associated correctly.

Anyway, fault injections through xdl for more complex fault effects than opens, where PIPs with junctions in commons are involved, should be avoided. In this scenario bitstreams generated from fault injected xdl are incorrectly translated in ncd files and only one of the two PIPs is programmed.

Figure 4.5 shows the architecture of PyXEL_Xdl.

Figure 4.5: PyXEL_Xdl Input and Output Files A brief description of the functions shown in figure 4.5 follows:

close_Xdl, open_Xdl act on xdl files to delete or add a PIPs in a specific net. Xdl2Ncd generates a ncd file from a xdl file.

Xdl2Bit, Xdl2Bin generate a bitstream (a bin or bit file) from a xdl file. Ncd2Bit, Ncd2Bin generate a bitstream (a bin or bit file) from a ncd file. Ncd2Xdl generates a xdl file from a ncd file.

(37)

The functions listed above are capable of managing single input files, lists of input files or directories. Directories are handled in the same way as the list of all the files in that specific directory.

4.3.2.3 PyXEL_Bin

PyXEL_Bin is the module that works on bitmaps and on bitstream manipulation. This module allows to build or retrieve bitmaps for PIPs and switch matrices, it can be also used in order to set or reset bits in a bitstream. Moreover, PyXEL_Bin allows to act bitwise operations on binary files and to program or open PIPs in binary configuration files. More about how bitmaps are obtained is illustrated in section 4.5.

Figure 4.6 shows the architecture of PyXEL_Bin.

Figure 4.6: PyXEL_Bin Input and Output Files A brief description of the functions shown in figure 4.6 follows:

(38)

set_bits, reset_bits apply set or reset operations to bits of a binary files selected

through a bitmap.

build_SM_bitmap, get_SM_bitmap create or retrieve the bitmap related to a

specific switch matrix.

build_PIP_bitmap, get_PIP_bitmap create or retrieve the bitmap related to a

specific PIP.

4.3.2.4 PyXEL_Run

PyXEL_Run is the module that allows FPGA programming, data transmission and results collection, aggregation and analysis. PyXEL_Run allows to program FPGA with bitstream and to test the design behaviour sending bytes on the serial port and receiving it back. Results are collected, analysed (in order to obtain an input-output boolean function) and exposed in a csv file.

Figure 4.7 shows the architecture of PyXEL_Run.

(39)

A brief description of the functions shown in figure 4.7 follows:

program_and_test programs the FPGA with one or more bitstreams. Each

con-figuration programmed by the function is tested using the bytes provided by the user in a txt file.

CollectResultGeneral collects the results and analyse them in order to obtain an

input-output boolean function. Results are exposed in a csv file.

4.3.2.5 PyXEL_Uti

PyXEL_Uti includes functions that are used by other modules. Moreover, it includes some functions for binary file analysis that the user can use to gain insights. The role of this module is to support other modules and the user with functions and scripts that allow binary files comparison and analysis, checks on parameters, files manipulation, files storage, PIPs query and managing files groups for automatised operations.

4.3.2.6 PyXEL_Log

PyXEL_Log generates log records using logging.py, the Python native module for log files.

4.4 Integrated Environment

Some PyXEL modules need to interact with Xilinx Software and with the FPGA device in order to perform their tasks. In this section it is described how the PyXEL integrated environment has been realized.

Using the PyXEL environment, the user can exploit Vivado to perform designs manipu-lation, synthesis and implementation in order to obtain bitstreams, designs checkpoints and netlists. PyXEL_Viv interacts with Vivado running it through the shell and the

(40)

usage of Vivado is transparent to the user. Using the shell, tcl scripts and their paramet-ers are passed from PyXEL_Viv to Vivado to be executed in the Vivado environment and results are stored in the file system and their path is returned to the PyXEL mod-ule. In Vivado, Tcl can be used to perform any action allowed by Vivado differently from what was possible in ISE Design Suite, where command line language was hard and complex to use. Moreover, tcl can be used to gain insight into the resources and characteristics of the FPGA designs and devices in an easier and more structured way than what was possible in XDL.

Interacting in a similar way with the ISE Tools ( xdl and bitgen) and using simple commands through the shell, PyXEL_Xdl can generate netlist and bitstream files but these tasks are executed faster and easier using PyXEL_Viv and Vivado. However, PyXEL_Xdl and ISE tools play a fundamental role in the creation of bitmaps.

Figure 4.8 shows the architecture of PyXEL integrated environment.

Figure 4.8: PyXEL Integrated Environment Map

4.5 Bitmaps

Bitmaps play a main role in the implementation of PyXEL. They are largely used to perform fault injection and PIPs manipulation, acting directly on the bitstream.

(41)

Indeed, using Vivado or XDL language, it is not possible to generate faulted bitstreams of corrupted designs (e.g. where antennas or conflicts exist). Consequently, the main idea is to activate and deactivate PIPs in order to inject particular fault effects acting on the bitstream itself, modifying the bit related to the PIPs.

From Open-Source Bitstream Generation for FPGAs by Ritesh K Soni[10] some hypo-thesis and ideas have been taken to build an easy way to act on bitstreams. The main idea is that PIPs can be activated or deactivated by setting or resetting particular bits in the bitstreams. Therefore, the sections of the bitstream that refer to a particular tile can be modified in order to change the routing configuration of the switch matrix under test with the purpose of activating or deactivating PIPs as the result of the injection of faults in the designs.

The bits in the bitstreams related to a particular resource are saved by PyXEL in bitmaps. Bitmaps are binary files of the same length of the bitstream. If the bits in a bitmap program the particular resource associated to the bitmap their value is 1, if they do not their value is 0. Consequently, a PIP can be activated in a bitstream performing a bitwise OR between its bitmap and the bitstream, or can be deactivated resetting the same bits.

Figure 4.9: Create a configuration with 2 PIPs combining two configurations of one PIP

(42)

PIPs bitmap are created in PyXEL using PyXEL_Bin module. With support of PyXEL_Xdl, PyXEL_Bin module builds the bitmaps related to PIPs on-the-fly and stores them for future needs. For obtaining the bitmap related to a specific PIP the following steps are executed:

1. A PIP is chosen, univocally identified by its name and its tile.

2. A xdl file of a simple design with just a logic element (that is needed to

declare a net), named INST.xdl , is created. The coordinates of the logic element are not relevant.

3. A binary configuration file for INST.xdl, named INST.bin , is generated. This is the bitmap for the logic element described above in point 2.

4. A dummy_net composed of a single PIP is added to the INST.xdl file and a binary configuration file for this new design is obtained, named INST_and_PIP.bin .

5. Acting a bitwise XOR between INST_and_PIP.bin and INST.bin, a binary file with only the bits related to the PIP are obtained. This is an extended PIP

bitmap, named bitmap_ext_PIP.bin .

6. A bitwise AND is executed between bitmap_ext_PIP.bin and the bitmap_TILE.bin . The binary file obtained is the PIP bitmap for the PIP in point 1,

named bitmap_PIP.bin .

Few notions need to be given about extended PIP bitmaps and tile bitmaps to fully understand the steps listed above.

In step 6 a bitmap_TILE.bin is used. This bitmap highlights the section of the bit-stream related to a specific tile. PyXEL_Bin can build this bitmap starting from two source files provided by the user. These source files are two similar bitstreams but the first has the bits of the portions of bitstream associated to a specific tile with values 0, while the second has the same bits associated with value 1. A bitmap is created performing a simple bitwise XOR between the two sources. PyXEL does not provide a method to obtain the two sources needed to build the bitmaps related to the tiles. The sources have been created using COMET a memory configuration tool to analyse,

(43)

visualise and manipulate FPGAs bitstream[23]. However, any method to build the source files or the bitmaps for the tiles themselves can be used.

Bitmaps related to the tiles are used to obtain a PIP bitmap starting from an extended PIP bitmap. When XDL is used to program a PIP of a switch matrix, a set of bits that was 0 is set to 1, in order to activate the PIP, as we can see in the INST_and_PIP.bin file. Anyway, analysing the portion of the bitstream of these bits we have seen that just a subset of this set belongs to the portions of the bitstream that refer to the tile of the PIP. For this reason, the extended PIP bitmap is filtered and only the bits related to the PIP and to the tiles are chosen to compose the PIP bitmap.

(44)

Experiments and Results

5.1 Introduction

PyXEL has been exploited to carry out experiments on Xilinx Artix-7 XC7A100T FPGA on Nexys 4 DDR board[25]. Using PyXEL, it is possible to analyse the logic behaviour of faults injected into the FPGA routing.

A simple application has been coded in VHDL. A UART (Universal Asynchronous Receiver-Transmitter) receiver and a UART transmitter for serial communications and two 8-bit registers compose the design. The application just receives a byte from the PC using the serial port, stores it in the registers and sends it back to the PC, then waits for the next byte.

(45)

A simple experimental workflow has been created in Python using PyXEL in order to inject and observe fault effects related to PIPs belonging to tile INT_L_X12Y169. The bitstream is manipulated to activate or delete PIPs, causing fault effects, such as opens and conflicts. Then the FPGA is programmed with the manipulated bitstreams and bytes are sent and received back. The comparison between sent and received bytes shows the logic behaviour of the injected faults.

(46)

5.2 Experiments using PyXEL environment

Several PIPs and nodes have been tested. Tests have been conducted on switch matrix belonging to tile INT_L_X12Y169. Python scripts have been coded, using PyXEL, to generate designs with resources under test belonging to the switch matrix under test. After that, bitmaps are created or retrieved and the bitstream is modified to change the switch matrix configuration. Finally, the FPGA is programmed with the new bitstream and tested by sending bytes. Results are received back and they are analysed in order to define the logic function that relates the bits given as input to the corrupted output bits . All the combinations of the 8 input bits (256 different bytes) are sent during the test phase.

All the experiments that follow have been executed using tile-filtered PIP bitmaps as described in section 4.5. Experiments using extended bitmaps have been performed with same results, but they are not shown in this thesis. We believe that extended bitmaps (that highlight a superset of the bits highlighted by the associated tile-filtered PIP bitmap) include bits related to other tiles (which we do not want to modify) near to the switch matrix under test. Given that all our experiments have been performed on an almost isolated switch matrix with a low number of nets and programmed logic around, it is reasonable that extended and tile-filtered bitmaps have produced the same results. Our choice was motivated by the fact that using tile-filtered PIP bitmaps we act on fewer bits in the bitstream than using extended PIP bitmap.

5.2.1 Testing Bitstream Manipulation

Some tests have been conducted in order to verify whether, performing manipulation on the bitstream, design routing changes as planned. A starting design is modified to use particular PIPs as resources under test and then its bitstream is generated. After that, the starting design routing configuration is modified several times, acting on the bitstream, obtaining a bitstream for each configuration shown in figure 5.3. Finally, bitstreams are used to program the FPGA and test bytes are sent to and returned

(47)

by the device. Subsequently, these data are analysed in order to verify whether the behaviour was the one expected by the new routing configuration.

Figure 5.3: Switch Matrix configurations tested to verify bitstream modification In figure 5.3 the configurations of a switch matrix that have been tested for this exper-iment are shown. The configuration (a) is the starting one: in this case bytes returned back from the FPGA should be the same sent by the Python scripts. In configurations

(48)

(b), (c) and (d) the bytes received should be different. In particular, in configuration (d), the first and the second bit of the test bytes used as input should appear exchanged in the returned bytes. In configuration (b) the first bit of the input bytes should be seen in the second bit of the output bytes. In the configuration (c) the second bit of the input bytes should be the first bit of the output bytes.

A simple script is shown as an example. The script can be easily modified to iterate on a list of PIPs under test, automatising a set of experiments on a group of PIPs. Only the simpler version is shown here for clarity.

(49)

1 import PyXEL

2 to_prog=[]

3 #parameters

4 run_dir = test_dir/base_test/

5 tile = INT_L_X12Y169

6 s0 = NR1END1 ; s1 = NN6END1 ; d0 = NL1BEG0 ;d1 = EL1BEG0

7 P00 = s0+ ->> +d0 8 P11 = s1+ ->> +d1 9 P01 = s0+ ->> +d1 10 P10 = s1+ ->> +d0

11 pip_l = [P00, P01, P10, P11] #pip list

12 pip_n_l = [ P00 , P01 , P10 , P11 ] #pip id

13 rut= [P00+ , +P11] #starting configuration

14

15 #get bitmaps for PIPs

16 R_MAP00 = PyXEL.get_PIP_bitmap_rdx(tile, pip_l[0]) 17 R_MAP01 = PyXEL.get_PIP_bitmap_rdx(tile, pip_l[1]) 18 R_MAP10 = PyXEL.get_PIP_bitmap_rdx(tile, pip_l[2]) 19 R_MAP11 = PyXEL.get_PIP_bitmap_rdx(tile, pip_l[3]) 20 R_MAPs = [R_MAP00, R_MAP01, R_MAP10, R_MAP11] 21

22 #create the starting design

23 a = PyXEL.RutRut2Bin(tile, rut, run_dir)

24 to_prog.append(a)

25

26 #deactivate PIPs in the starting design

27 a_D00 = PyXEL.reset_bits(a, R_MAPs[0], run_dir+ a_D00.bin )

28 a_D00_D11 = PyXEL.reset_bits(a_D00, R_MAPs[3], run_dir+ a_D00_D11.bin ) 29

30 #build designs (b), (c), (d)

31 b=PyXEL.set_bits(a_D00_D11, R_MAPs[1], run_dir+ b.bin ) 32 c=PyXEL.set_bits(a_D00_D11, R_MAPs[2], run_dir+ c.bin ) 33 d=PyXEL.set_bits(c, R_MAPs[1], run_dir+ d.bin )

34 to_prog.append(b); to_prog.append(c); to_prog.append(d) 35

36 #programming FPGA

37 PyXEL.prog_and_test(to_prog, testfile= test.txt , dir_proj=run_dir) 38

39 #visualize results

40 PyXEL.collectResultsGeneral(run_dir)

The previous experiments confirmed what we expected. All the designs behave correctly and the outputs match what we expected. The csv file obtained in this way (slightly

(50)

modified for better readability) appears like in the following figure.

Figure 5.4: Analysis of results for bitstream manipulation test

In the last two columns, first and second bit of the output byte depend on the input bits. Input bits are identified from the least to the most significant one with an increasing index (i0, i1, i2 and so on) as well as for output bits (b0, b1, b2 and so on). The results for open connections (stuck-at-1 ) will be analysed in the next experiments. The following table lists some of the PIPs used in our tests. All PIPs tested in these experiments have been programmed correctly and all the manipulated bitstreams have given the expected outputs.

PIP S0 -> D0 PIP S1 -> D1 PIP S0 -> D1 PIP S1 -> D0

ER1END1 -> SS2BEG1 SW6END1 -> ER1BEG2 ER1END1 -> ER1BEG2 SW6END1 -> SS2BEG1 NE6END2 -> NW2BEG2 NW2END2 -> NE2BEG2 NE6END2 -> NE2BEG2 NW2END2 -> NW2BEG2 SS6END1 -> WW4BEG2 SS2END1 -> SL1BEG1 SS6END1 -> SL1BEG1 SS2END1 -> WW4BEG2 NW6END2 -> NE2BEG2 EE2END2 -> EL1BEG1 NW6END2 -> EL1BEG1 EE2END2 -> NE2BEG2

EL1END2 -> SE2BEG2 SW6END2 -> SS2BEG2 EL1END2 -> SS2BEG2 SW6END2 -> SE2BEG2 SE6END1 -> NE2BEG1 NR1END1 -> EL1BEG0 SE6END1 -> EL1BEG0 NR1END1 -> NE2BEG1

Table 5.1: Some of the PIPs used in bitstream manipulation experiments

5.2.2 Testing Fault Effects

PyXEL has been used to inject faults in bitstreams, causing typical fault effects in routing configuration of the switch matrix INT_L_X12Y169.

(51)

5.2.2.1 Open Faults

A starting design (in figure 5.1) has been created in order to test open faults. Similarly to what we have done in the script to test bitstream manipulations, the design has been modified in order to use specific resources and then the bitmaps have been used in order to delete PIPs in the switch matrix, causing open fault effects.

The script shown below carries out experiments on a set of PIPs chosen randomly. The FPGA is programmed and the designs are tested automatising the experimental workflow.

(52)

1 import PyXEL 2 to_prog=[] 3 #parameters 4 run_dir = test_dir/base_test/ 5 tile = INT_L_X12Y169 6 for i inrange(0,5): 7 juns= PyXEL.rnd_jun() 8 s = juns[0]; d = juns[1] 9 pip = s+ ->> +d 10 rut=[pip] 11

12 #get bitmaps for PIPs

13 R_MAP00 = PyXEL.get_PIP_bitmap_rdx(tile, pip) 14

15

16 #create the routed design

17 a = PyXEL.Rut2Bin(tile, rut, run_dir) 18

19 #deactivate PIPs in the routed design

20 a = PyXEL.reset_bits(a, R_MAP00, a )

21 to_prog.append(a);

22 23

24 #programming FPGA

25 #note that PyXEL functions can handle file lists (of bitstreams, of designs, of xdc..) too 26 PyXEL.prog_and_test(to_prog, testfile= test.txt , dir_proj=run_dir)

27 #visualize results

28 PyXEL.collectResultsGeneral(run_dir)

Several opens have been injected using different PIPs. The behaviour observed is identical for each open connection. In particular, when we delete a PIP, the opened connection causes a stuck-at-1 logical effect on the node under test.

Figure 5.5 shows a topological view of the switch matrix configuration and the logic effect associated to it .

(53)

Figure 5.5: Open Faults

5.2.2.2 Conflict Faults

In a switch matrix with two programmed PIPs, SEUs in the configuration memory can cause a conflict fault. Precisely, a new PIP is programmed between the source junction of the first one and the destination junction of the second one.

In order to test a conflict fault on a node, a set of PIPs is needed. This set is made of three or four PIPs. Two of them are the couple of resources to be tested, that we named

P IPa and P IPb. This couple of PIPs has not junction in common. The junctions of

(54)

Sa Source junction of P IPa.

Da Destination junction of P IPa.

Sb Source junction of P IPb.

Db Destination junction of P IPb.

Additionally, a third PIP, named P IPba, has to exist. P IPba is the PIP initially not

programmed and that will be activated in the switch matrix. P IPba has the form

Sb æ Da. If P IPba exists, it is possible to test a conflict on the node related to Da.

Finally, if a fourth PIP exists, namedP IPab of form Saæ Db, then the node associated

to Db could be tested too.

(55)

Figure 5.6: View of the junctions and PIPs used in conflict faults

In the configuration (a) the couple of PIPs to be used as resources under test and their junctions are illustrated; configurations (b) and (c) show the PIPs that allow to test the nodes associated to Da and Db, respectively.

(56)

A starting design is created as in figure 5.1 to test conflict faults. Afterwards, the design is modified to use a couple of PIPs as resources under test. The bitmaps are created or retrieved and used to manipulate the bitstream in order to activate P IPba.

Several couples of PIPs have been tested, and distinct behaviours have been observed. The output of the node driven by the single PIP (e.g. P IPb in figure 5.7) is the correct

one (i.e. the same obtained before the bitstream manipulation).

Distinct behaviours have been obtained for nodes subject to conflict faults (i.e. driven by P IPa and P IPba in figure 5.7). The two main ones are:

WIRED-AND the logic value on the node related to Dx, driven by P IPxand P IPyx,

is the logic AND between the logic values on Sx and Sy.

WIRED-OR the logic value on the node related to Dx, driven by P IPx and P IPyx,

is the logic OR between the logic values on Sx and Sy.

A different behaviour occurs very rarely:

FORCED-BY If the logic value on the node related to Dx, driven by P IPx and

P IPyx, is the logic value in Sx, we say that it is Forced-by P IPx. Similarly, if

the logic value on the node related to Dx is the logic value in Sy, we say that it

is Forced-by P IPyx

Furthermore, the same node may present different behaviours based on which PIPs are acting on it. Therefore, when we describe a logic behaviour of a node we should specify which PIPs are causing it and on which destination junction or node.

(57)

Figure 5.7: Conflict Faults Some results are listed in the table 4.2

5.2.3 Analyses of Results

In subsection 5.2.1, we have verified that bitstream manipulation can be used to pro-duce specific modifications in an application behaviour. In particular, we succesfully manipulated bits related to a specific switch matrix and we have obtained a new

(58)

bit-C ou pl e of P IP s PI Pba ac ti vat ed PI Pab ac ti vat ed PI Pa PI Pb PI P L ogi c E ffe ct PI P L ogi c E ffe ct NR1END1->NL1BEG0 NN6END1->EL1BEG0 NN6END1->NL1BEG0 WIRED-OR NR1END1->EL1BEG0 WIRED-OR SE6END0->SS6BEG0 EE2END0->SE2BEG0 EE2END0->SS6BEG0 WIRED-AND SE6END0->SE2BEG0 WIRED-OR NE6END0->NN6BEG0 NN2END0->NE2BEG0 NN2END0->NN6BEG0 WIRED-AND NE6END0->NE2BEG0 WIRED-OR NN6END0->NE6BEG0 SE2END0->EE2BEG0 SE2END0->NE6BEG0 WIRED-OR NN6END0->EE2BEG0 WIRED-OR WW2END0->NW6BEG1 NN6END1->WW2BEG0 NN6END1->NW6BEG1 WIRED-OR WW2END0->WW2BEG0 WIRED-OR EE2END0->ER1BEG1 SW2END0->SL1BEG0 SW2END0->ER1BEG1 WIRED-AND EE2END0->SL1BEG0 WIRED-AND WW4END3->SR1BEG3 SW2END2->WL1BEG1 SW2END2->SR1BEG3 WIRED-OR WW4END3->WL1BEG1 WIRED-OR EL1END3->SE2BEG3 SS6END3->EE2BEG3 SS6END3->SE2BEG3 WIRED-OR EL1END3->EE2BEG3 WIRED-OR SS6END2->SW2BEG2 SL1END2->SR1BEG3 SL1END2->SW2BEG2 WIRED-OR SS6END2->SR1BEG3 WIRED-OR WW4END2->SS6BEG1 SW6END1->WW4BEG2 SW6END1->SS6BEG1 WIRED-AND WW4END2->WW4BEG2 WIRED-AND SW2END1->SS2BEG1 SS2END1->ER1BEG2 SS2END1->SS2BEG1 WIRED-AND SW2END1->ER1BEG2 WIRED-AND SE6END3->EE4BEG3 SS6END3->ER1BEG_S0 SS6END3->EE4BEG3 FORCED-BY PI Pa SE6END3->ER1BEG_S0 FORCED-BY PI Pab SW6END2->SS6BEG2 SS6END2->SE2BEG2 SS6END2->SS6BEG2 WIRED-AND SW6END2->SE2BEG2 FORCED-BY PI Pab Tab le 5. 2: R es ul ts of ex pe rim en ts on con fli ct fau lts

(59)

stream implementing a different function (i.e. to switch two input bits).

In subsection 5.2.2, we have used this feature to modify configuration of a switch matrix through bitstream manipulation in order to carry out experiments on open and conflict faults.

5.2.3.1 Open Faults

Each time we have deleted a PIP in a switch matrix a stuck-at-1 effect occured on the output. Several switch matrices and PIPs have been tested. Experiments have been conducted using extended and tile-filtered bitmaps of PIPs, both with the same result. It seems reasonable to suppose that open faults usually cause stuck-at-1 logic effects on Xilinx Artix-7 XC7A100T.

More experiments could be executed, testing all the PIPs in a switch matrix, in order to obtain a complete view of the realistic behaviour of the open faults in a specific FPGA devices.

5.2.3.2 Conflict Faults

Experiments on conflict faults showed interesting results. We obtained distinct beha-viours for conflict faults, such as Wired-OR, Wired-AND, Forced-By.

We executed some analyses on bitmaps. Tile-filtered bitmaps of PIPs seem to contain only two bits with value 1. We noticed that when a conflict is caused by two PIPs with an 1 in the same position in both the bitmaps, it behaves as a Wired-AND. Differently, if this condition is not satisfied the two PIPs in conflict cause a Wired-OR behaviour. Still, it is not clear when a Forced-by behaviour occurs.

More than one hundred configurations have been tested and less than 3% resulted in Forced-by behaviour. The other configurations presented a Wired-AND or a Wired-OR behaviour, and what reported above about the relation between conflicts behaviours and bitmaps was verified.

(60)

Anyway, experiments have been carried out on a subset of the possible configurations of a switch matrix and more experiments should be executed in order to obtain a complete view of conflicts.

(61)

Conclusions and Future Work

In this thesis, PyXEL, an integrated environment for injection and analysis of faults in FPGA routing, has been implemented. PyXEL provides an easy way to automatise experimental workflows exploiting Python, Vivado and ISE. Furthermore, it allows to modify the configuration of switch matrices by manipulating the bitstream.

Using PyXEL, the user can activate and delete PIPs acting on the bitstream at an high-level, without knowing how these operations are performed. Additionally, the user can still obtain a low-level view of the bitstream for tests and analysis.

Finally, PyXEL has been used to gain insight into the behaviours of open and conflict faults in the routing structure of switch matrices in Xilinx Artix-7 FPGA devices. Some hypotheses about results obtained and their meanings have been provided.

Currently, PyXEL works only on Xilinx Artix-7 FPGA architectures. In addition, the module PyXEL_Viv can not route particular PIPs (e.g. PIPs for clock nets). Improvements on these aspects could be carried on.

Moreover, PyXEL does not provide a way to build tile bitmaps. It could be integrated with other software to obtain it. Alternatively, a way to build them by itself could be implemented in future.

Finally, tests should be executed on all the routing resources in order to provide a complete view of fault effects and their logical behaviours in FPGA devices.

(62)

Bibliography

[1] 7 Series FPGAs Data Sheet: Overview, DS180, Xilinx, 2018. [2] W. Wolf, FPGA-Based System Design. Prentice Hall PTR, 2004. [3] Vivado Design Suite Properties Reference Guide, UG912, Xilinx, 2015.

[4] M. Ceschia, M. Violante, M. Sonza Reorda, A. Paccagnella, P. Bernardi, M. Re-baudengo, D. Bortolato, M. Bellato, P. Zambolin, and A. Candelori, “Identification and Classification of Single-Event Upsets in the Configuration Memory of SRAM-Based FPGAs,” in IEEE Transactions on Nuclear science, 2003.

[5] M. Violante, N. Battezzati, and L. Sterpone, Reconfigurable Field Programmable

Gate Arrays for Mission-Critical Applications. Springer Science & Business

Me-dia, 2011.

[6] M. Bellato, P. Bernardi, D. Bortolato, A. Candelori, M. Ceschia, A. Paccagnella, M. Rebaudengo, M. Sonza Reorda, M. Violante, and P. Zambolin, “Evaluating the effects of seus affecting the configuration memory of an sram-based fpga,” in

Proceedings of the Conference on Design, Automation and Test in Europe - Volume 1, ser. DATE ’04. IEEE Computer Society, 2004.

[7] ISE Design Suite Software Manuals and Help, Xilinx, 2010.

[8] C. Beckhoff, D. Koch, and J. Torresen, “The Xilinx Design Language (XDL): Tutorial and use cases.” IEEE, 2011.

(63)

of the 16th International ACM/SIGDA Symposium on Field Programmable Gate Arrays, ser. FPGA ’08. New York, NY, USA: ACM, 2008, pp. 264–264.

[10] R. K. Soni, “Open-Source Bitstream Generation for FPGAs,” Master’s thesis, Virginia Polytechnic Institute and State University, 2013.

[11] C. Bernardeschi, L. Cassano, A. Domenici, and L. Sterpone, “ASSESS: A simulator of soft errors in the configuration memory of sram-based fpgas,” IEEE Trans. on

CAD of Integrated Circuits and Systems, vol. 33, no. 9, pp. 1342–1355, 2014.

[12] ——, “Accurate Simulation of SEUs in the Configuration Memory of SRAM-based FPGAs,” in Proceedings of the IEEE International Symposium on Defect and Fault

Tolerance in VLSI and Nanotechnology Systems (DFT 2012), October 2012.

[13] ——, “Unexcitability Analysis of SEUs Affecting the Routing Structure of SRAM-based FPGAs,” in Proceedings of the Great Locations Symposium on Very Large

Scale of Integration (GLSVLSI2013), May 2013.

[14] ——, “UATPG: An untestability analyzer and test pattern generator for seus in the configuration memory of SRAM-based FPGAs,” Integration, vol. 55, pp. 85–97, 2016.

[15] Cozzi, D. and Korf, S. and Cassano, L. and Hagemeyer, J. and Domenici, A. and Bernardeschi, C. and Porrmann, M. and Sterpone, L., “OLT(RE): an on-line on-demand testing approach for permanent radiation effects in reconfigurable systems,” IEEE Transactions on Emerging Topics in Computing, 2016.

[16] C. Lavin, M. Padilla, J. Lamprecht, P. Lundrigan, B. Nelson, B. Hutchings, and M. Wirthlin, RAPIDSMITH: A Library for Low-level Manipulation of Partially

Placed-and-Routed FPGA Designs, 2014.

[17] C. Lavin, M. Padilla, J. Lamprecht, P. Lundrigan, B. Nelson, and B. Hutchings, “RapidSmith: Do-It-Yourself CAD Tools for Xilinx FPGAs,” in ReConFigurable

Computing and FPGAs (ReConFig), 2014 International Conference, 2014.

(64)

Generation Xilinx FPGA Devices,” Master’s thesis, Department of Electrical and Computer Engineering,Brigham Young University, 2017.

[19] L. Santangelo, “Viv2XDL: a bridge between Vivado and XDL based software,” Master’s thesis, Dipartimento di Ingegneria dell’Informazione, UniversitÃ di Pisa, 2014.

[20] B. S. White, “Tincr: Integrating Custom CAD Tool Frameworks with the Xilinx Vivado Design Suite,” Master’s thesis, Department of Electrical and Computer Engineering, Brigham Young University, 2014.

[21] W. Brad and N. Brent, “Tincr - a custom cad tool framework for vivado,” in

International Conference on Field Programmable Logic and Applications (FPL),

2011.

[22] N. Brent, T. Townsend, and T. Haroldsen, RAPIDSMITH2: A Library for

Low-level Manipulation of Vivado Designs at the CELL/BEL Level, 2018.

[23] L. Bozzoli and L. Sterpone, “COMET: a configuration memory tool to analyze, visualize and manipulate FPGAs bitstream,” in The 2nd Workshop on Computer

Architectures in Space (CompSpace’18), April 2018.

[24] Python Core Team, “Python: A dynamic, open source programming language,” Python Software Foundation. [Online]. Available: https://www.python.org/ [25] Nexys 4 DDR Reference Manual, Diglient Inc., 2016.