FASE: An Open Run-Time Reconfigurable FPGA Architecture forTamper-Resistant and Secure Embedded Systems

Sumanta CHAUDHURI , Jean-Luc DANGERSylvain GUILLEY, Philippe HOOGVORST

GET / Telecom Paris, CNRS – LTCI (UMR 5141)46 rue Barrault, 75634 PARIS Cedex 13, FRANCE

Abstract

The Run-Time Reconfigurable (RTR) feature is highly de-sirable for flexible and fast self-contained systems. RTR canbe achieved on some commercial FPGA platforms. We pro-pose an open solution, called FASE, that allows for fine-grain RTR, designed to be more intuitive than currentlyavailable solutions. The issues of initializing RTR soft IP-cores and a design flow to manage the dynamics of RTR arepresented.

In the context of secure embedded systems, there is aneed for both flexibility and tamper-resistance. However,the robustness level for security constraints is difficult toget and to prove because of the proprietary hidden struc-tures. The FASE architecture addresses these issues. Itmakes it possible for any designer to implement custom andarbitrary dynamic strategies. We illustrate two case stud-ies: an implementation-level counter-measure against side-channel attacks and an efficient strategy to thwart fault in-jection attacks against cryptographic functions.

1. Introduction

The hardware reconfigurability is considered when ap-plications are constrained by a high degree of both flexibil-ity and performance. Many academic projects studied RTRarchitectures, to speed up reconfiguration time and increasethe flexibility for reconfigurable computing [1, 2, 3]. Somecommercial FPGAs provide dynamic reconfigurability fea-tures. XILINX offers partial reconfigurability by columnsin its VIRTEXII offer [4]. ATMEL proposes the AT40Kand an embedded FPGA in the FPSLIC family based onAVR microcontrollers [5]. Many academics studied opti-mized tools for fast reconfiguration [6, 7]. However, mostinnovative architectures like the ATMEL AT6000 and XIL-INX XC6200 did not get any commercial success and dis-appeared. With new emerging challenges like security, re-

configurable architectures could have a second wind.Reconfigurability is a good strategy to secure crypto-

graphic accelerators, that are targets of side-channel or faultinjection attacks. We suggest, for instance, that a permanentand random change of the configuration is able to concealside-channel information from the attacker. The main draw-backs of existing reconfigurable architectures are twofold:

1. The architectures are proprietary with many unknownsin the routing structure and reconfiguration hardware.

2. The proposed methods and tools appear to be very con-strained by the architecture without improvement pos-sibility.

The XILINX architectures are the most constrained be-cause of their coarse-grain column-wise approach. TheATMEL has a fine-grain approach with a reconfigurationat the cell level. However, their legacy Place/Route tool(FIGARO [8]) imposes a static placement of the reconfig-ured area.Therefore, it seems quite challenging to evaluatethe robustness of FPGAs and propose tamper resistant cir-cuits without a close collaboration with the manufacturer.In the security context, the FASE “FPGA Architecture forSecure Embedded systems” project aims at designing anFPGA architecture with RTR capability which meets theserequirements:

• A fine grain architecture which allows the designerto place/route dynamically the reconfigured area any-where and at cell boundaries.

• An open architecture with detailed and exhaustivespecifications of the routing and logic resources.

• A simple configuration interface which allows the pro-grammer to build his own reconfiguration strategy.

FASE is an offshoot of the SAFE (Secured Asyn-chronous FPGA for Embedded systems) project [9] whichtakes profit of asynchronous cells to increase the robust-ness against side-channel attacks. This project specifies

RST

CLK

ADDR_ROW

ADDR_COL

ADDR_INTRA_CT[1:0]

CONF_DATA

CONF_CLK

bus

° ° °

° ° °

VCI INTERFACEVCI WRAPPER VCI INTERFACEVCI WRAPPERVCI INTERFACEVCI WRAPPER VCI INTERFACEVCI WRAPPERVCI INTERFACEVCI WRAPPER

VCI INTERFACEVCI WRAPPERFASE CONF

FASE

CPU MEMORY ARBITER

DESFASE ARRAY

Figure 1. VCI interface for FASE ARRAY andFASE CONF.

that the partial and dynamic configuration has to accom-modate several modules possibly implemented in differentstyles of asynchronous logic [10]. It should also be able tomodify the design on-the-fly on detection of intrusion. Bycontrast, FASE is a synchronous FPGA, thus intrinsicallyunsafe against side-channel attacks. However, its dynamicreconfiguration capability also enables it to implement bothpreventive and resilience strategies (that are not built-in.)

The rest of the article is organized as follows. Section 2presents the main principles of FASE functional and config-uration architecture. Section 3 addresses the issues involvedin reconfiguration and presents a typical design flow. InSection 4, two applications requiring a high level of secu-rity are presented. Finally, Section 5 draws the conclusion.

2. FASE Architecture

2.1. FASE Overall Architecture and Princi-ples

As an embedded FPGA, FASE is designed to be con-nectable to a system bus. It thus features a VCI [11] in-terface. The general architecture of FASE comprises of afunctional array (FASE ARRAY) and of a configuration con-troller (FASE CONF), as shown in figure 1.

FASE has a generic architecture described in the sequelas per the VPR (Versatile Place-and-Route tool [12, 13])nomenclature. However, for the sake of illustration, fixedvalued are given to some structural parameters. The FASE

RSTMASK CLB CBOX3 OUTCBOX3 INCBOX1 OUT CBOX4OUTCBOX4 INCBOX2OUT CBOX2IN

CBOX1 INmatrix(SBOX)swit h

Figure 2. The configurable tile (CT) and itscomponents.

array (FASE ARRAY) is a reconfigurable embedded archi-tecture based on four hierarchical objects:

1. The logic element (LE) is composed of a look-uptable (LUT) and a D-flip-flop (DFF). A reset maskRST MASK indicates whether the DFF reset line is ac-tive or not.

2. The compound logic block (CLB) is composed of sev-eral LEs (only one in the sequel.)

3. The configurable tile (CT), depicted in figure 2, is com-posed of one CLB plus, at its periphery, the followingswitching components:

• The connection box CBOX IN (resp.CBOX OUT) permits the CLB input (resp.output) connections.

• The switch box (SBOX) allows the routing be-tween CLBs.

4. And finally, the array FASE ARRAY is an N × Nsquare set of CTs surrounded by 4×N CTs dedicatedto the I/Os (IOBs.)

The configuration controller (FASE CONF) is in chargeof configuring and initializing any area of the FPGA.The RTR in FASE is based on two configuration levels:

1. first of all, the selection of a specific set of CTs or IOBsamongst the array, and

2. secondly, the CT internal components: CLB (with theRST MASK), CBOX IN, CBOX OUT and SBOX.

...

learsetDFFLUTCLKRST 4a(3..0) M0 | M15 set y1RST MASK

SEQ/COMBSET/CLEAR lear

Figure 3. CLB comprised of (only) one 4 → 1LE with maskable reset.

A configuration zone corresponds to a set of CT, notnecessarily rectangular. The RTR can be applied by re-configuring subsets of objects inside a subset of CT. Forinstance, only the RST MASK of the configured area iscleared (so that it is properly initialized) while the rest of theFASE ARRAY remains unaffected by the global reset (be-cause the RST MASK is set.) Detailed examples are givenin Sec. 3.

2.2. Functional Architecture

The FASE architecture presentation does not insist onany particular performance improvement. The reason is thatmost optimizations and trade-offs published in the literaturecan be transposed in a straightforward way to FASE simpleand generic structure.

2.2.1. CLB. In addition to the LUT mask, a configurationpoint SET/CLEAR selects whether the flip-flop should beset or cleared when RST is active. The configuration pointSEQ/COMB selects between the “LUT only” or the “LUT+ DFF” functionality. The RST MASK is added to selec-tively initialize CLBs in FASE. This configuration point isaddressable independently of the CLB configuration chain.Figure 3 illustrates a CLB composed of one 4 → 1 LE withmaskable reset. In all the figures, a solid dot (•) representsa configuration memory point.

2.2.2. Routing Resources. To simplify this section, allthe routing tracks are segments of unity length and use auniform channel width W. We design the input and outputconnection box flexibilities to be 50% (i.e. the CLB inputsand output connect to 50% of the routing tracks) and we usea Wilton switch box [14] to achieve greater routability. TheIOB flexibility is unitary. The global signals RST and CLKare routed separately on dedicated tracks.

Dual-port RAMVCIinterfa e

CLKRSTRAMENWEADDRDIDO

CMDEOCRAMENWEADDRDIDO FASE ARRAYFigure 4. VCI interface of the FASE ARRAYwith functional IO pads.

2.2.3. Functional Interface. FASE ARRAY is linked tothe external world via the VCI interface which contains adual-port RAM accessible by both FASE ARRAY and VCI.Four IOBs are dedicated to control signals:

• CMD is used by the VCI interface to start an operation.

• EOC is set by FASE ARRAY to signal the operationend.

• RAMEN indicates that FASE ARRAY currently ac-cesses the RAM.

• WE indicates that FASE ARRAY writes into the RAM.

4×N−4 IOBs are available as address and data lines toaccess the dual-port RAM. For instance if N = 8, 12 IOBspads could compose the address word and 16 could be thedata (8 inputs and 8 outputs). The details of the functionalinterface is depicted in figure 4.

2.3. Configuration

The configurable memory points are programmed via aset of shift registers inside each CT. From a configurationviewpoint, an IOB is considered as being a CT subset. Thisis because the IOB has no CLB and the number of CBOX andSBOX depends on the IOB location. At power up, the poweron reset signal (denoted PO RST) permits to start with allthe configuration points inactive.

2.3.1. Configuration Architecture. In FASE, each CTand IOB is addressable by the ADDR ROW and ADDR COLlines, as illustrated by figure 5.

Inside a CT, there are four configuration chains selectedby the signals ADDR INTRA CT[1:0]. Each chain corre-sponds to specific CT components:

4

4

COLUMN DECODE

ROWDECODE

CONF CLKCONF DATA

ADDR INTRA CT[1:0℄

ADDR COL

ADDRROW

Figure 5. Address lines and global configura-tion signals.CONF DATA

ADDR INTRA CT[1:0℄SBOXRST MASKChain 1:Chain 2:CBOX1 OUT+CBOX2 OUT+CBOX3 OUT+CBOX4 OUTCBOX1 IN+CBOX2 IN+CBOX3 IN+CBOX4 IN+CLBCONF CLKADDR ROWADDR COL Chain 0:

Figure 6. Separately addressable configura-tion chains of FASE.

1. CBOX OUT,

2. CBOX IN + CLB,

3. SBOX and

4. RST MASK.

To avoid electrical conflicts due to shifting of configura-tion bits along the chain, the CBOX OUT is disabled duringthe CT configuration period, except if the RST MASK is be-ing configured. This will allow the designer to split dynam-ically active blocks and inactive blocks without any conflictor operation interrupt.

The chain input is CONF DATA and the chain clock isCONF CLK.

Figure 6 depicts the architecture of the four configurationchains.

The configuration points drive logic directly inside theCLB or drive pass-transistors for the connection boxes and

W ......CLB(i, j)interrupting�gured w/oCan be re on-CLB(i+1, j)...

...CLB(i, j)A tiveA tive. Conne tions(i+1, j). Can bere on�gured w/o interrupting onne tions(i, j)Conne tions(i, j)

Figure 7. Input connection box: granularity ofconfiguration (W=4, fc in=fc out= 1

2 ).

the switch box. To save a few configuration bits, the con-nexion boxes use multiplexer switches. The output connec-tion boxes use tri-state buffers rather than pass-transistorsto allow high fan-out drive. Figure 7 shows the connectionbox configuration points.

If we consider one LE per CLB, the number of configura-tion points as in figure 3, the number of configuration pointsis as follows:

• CLB: 18 (M0 – M15, SEQ/COMB, SET/CLEAR),

• RST MASK: 1,

• CBOX IN: (W× Fc in)× number of inputs,

• CBOX OUT: (W× Fc out)× number of outputs,

• SBOX: 6×W,

where: W is the number of tracks per row or column, Fc inand Fc out are respectively the flexibilities of the CBOX INand CBOX OUT.

2.3.2. Configuration Interface. FASE CONF is incharge of the configuration and of the delivery of globalsignals that are CLK and RST. Like FASE ARRAY, itis connected to the external world via a VCI interface.FASE CONF generates the signals described in table 1:

All the signals are global, except ADDR ROW andADDR COL that are decoded and associated with respec-tively a specific row and column as shown in figure 5.

The FASE CONF reads the instructions and configura-tion data from the RAM and sends a serial bitstream to theproper address in FASE ARRAY. The basic instruction setis given in table 2.

3. Run-Time Reconfiguration

RTR soft IPs or DHPs [7] can be called any time intoFASE at the presence of already active blocks. This can be

Table 1. Interface between FASE CONF andFASE ARRAY.

Signal FunctionRST Global reset. It can be

masked for each the CT bythe RST MASK bit.

CLK Global clock. The clock fre-quency can be adjusted inFASE CONF to satisfy thetimings.

ADDR ROW Row address. Selects a rowamong N + 2 for configura-tion.

ADDR COL Column address. Selects acolumn among N + 2 forconfiguration.

ADDR INTRA CT[1:0] 2 bits CT component ad-dress. Selects a specificcomponent set inside a CT.

CONF DATA Configuration Data. One bitdata to enter the configura-tion chains.

CONF CLK Configuration clock.

Table 2. Instruction set for FASE CONF.

Instructions FunctionSET ROW <ROW ADDR> Selects cell ad-

dress.SET COLUMN <COL ADDR> Selects cell ad-

dress.CONFIG C OUT <CONFIG DATA> Configures input

connections.CONFIG C IN <CONFIG DATA> Configures out-

put connections.CONFIG SBOX <CONFIG DATA> Configures

switch-boxconnections.

ENABLE RESET Enables/Masksthe RST MASKregister.

DESELECT Deselects every-thing.

START Generates a reset.

CLB CLB CLB CLBCLB CLB CLB CLBCLB CLB

CLBCLBCLBCLBCLBCLBCLBCLBCLBCLBCLBCLB

CLB CLB CLB CLBCLB CLB

a(0)a(1)b(0)b(1)b(2)b(3)a(0)a(1)b(0)b(1)b(2)b(3)

RTLBlo k 1....................................RTLBlo k 2....................................

Blo k 1 a(0..1)internal pad outBlo k 1 b(0..3)internal pad inBlo k 2 b(0..3)internal pad outBlo k 2 a(0..1)internal pad in

SYNTHESIS

Figure 8. Design flow outline.

achieved by meeting specific RTR rules and methods at 3hierarchical levels: application, circuit and block.

3.1. RTR at Application Level

Dynamic resource management [15] is necessary to effi-ciently use RTR. RTR modules should be “allocated” beforetheir configuration and “freed” once they are no more in use.This alloc/free information is passed on to the FPGA com-pilation tool during run-time. This step is necessary as newincoming block depends on the present occupation statusof the FPGA. Incidentally the synthesis/place/route tool isanalogous to the compiler/linker for microprocessor basedsystems.

3.2. RTR at Circuit Level

The circuit design flow needs to integrate specific inter-faces between blocks in order to allow flexibility for theRTR. For this purpose, dedicated CT have to be used as in-ternal IO pads. At the RTL level, they correspond to theentity inputs and outputs as shown in figure 8.

This netlist is then placed/routed with VPR. The simu-lated annealing algorithm in VPR [16] may generate an ar-bitrary shaped placement in order to minimize the routingresources. However, we constrain the placement such thatthe CLBs configured as internal pads are always placed atthe frontier and the placement avoids the cells already inuse as depicted in figure 9.

Synchronization issues at initialization between activesoft IPs and a newly loaded module is left to the top levelRTL designers, for the sake of flexibility. Whether the newincoming block is “ready” or “not ready” can be commu-

Figure 9. Block 1 (black) active, CLBs con-figured as internal pads are placed at theboundary.

nicated to the active blocks by many protocols. For exam-ple, it can consist in polling the status of the new IP blockwritten into RAM, or one of the active IPs may initiate theconfiguration of this new block.

An overview of the RTR design flow is described in thefollowing sequence:

1. RTL code is synthesized to generate soft IP cores con-nected by CTs configured as internal pads.

2. Block 1 is configured into FASE and initialized, all theinternal pads are constrained to be placed at the bound-ary of Block 1.

3. The placer/router loads the current occupation statusof the FPGA and then Block 2 is placed and routed.It is constrained to avoid the already occupied CTs.This can be done in many ways in VPR. One simplemethod is to set the cost functions of already occupiedCLBs equal to infinity. During the placement/routingof Block 2 the router takes into account the positionsof the internal pads.

4. Block 2 is configured into FASE and the internal padsare configured to connect it to Block 1.

5. Block 2 is selectively initialized.

Figure 10 shows the floorplan result.

Figure 10. Block 2 (gray) is configured, in-ternal pads are configured to connect toBlock 1.

3.3. RTR Rules at Block Level

3.3.1. Timing closure. For timing closure place-ment/routing, a simple strategy consists in considering asafety margin greater than the worst case clock period forthe entire system. This basic approach will no more be nec-essary for future FASE release which will use asynchronousCLBs. The self-timed property of asynchronous calculationwill remove this constraint intrinsic to synchronous circuits.

3.3.2. Initialization. Soft IPs have be selectively initial-ized in FASE without interrupting others. The way to sendthe RST only to the block which has to be initialized is touse the RST MASK configuration point. While configuringnew RTR blocks into FASE, the RST MASK of all activeCLBs is masked so that only new configured blocks are ini-tialized.

3.3.3. RTR Sequence. To avoid conflicts during theshifting of the bitstream, each time one of the four chainsis selected for configuration, the outputs of the configuredCT are disabled. Only the RST MASK configuration pointcan be programmed without disabling the outputs. Let usassume that Block 1 is active and Block 2 is being pro-grammed.

The sequence of reconfiguration of Block 2 is illustratedin figure 11.

Block 2 could have a greater or smaller size or even be at

Con�guration of Blo k 2 CBOX IN + CLB + SBOXDea tivation of Blo k 2 CBOX OUTCon�guration of Blo k 2 CBOX OUTMasking of Blo k 1 RSTUnmasking of Blo k 2 RSTA tivation of Blo k 2 RST to start

Figure 11. RTR sequence.

a new location. In this case the CBOX OUT of the old loca-tion have to be disabled before configuring the new block.

Each time a RTR soft IP is freed from the system, allconfiguration bits in the CT belonging to the freed block areset to 0.

4. FASE Architecture Suitability for SecurityApplications

The key feature of FASE is that it enables the designof robust implementations, which indeed demand an unre-stricted access to configuration resources.

4.1. Security Requirements on Hardware

The security applications are encountering the problemof the proliferation of cryptographic algorithms. Until theyears 2000, the smartcards could perform all the securityfunctions (authentication and encryption) thanks to DESand RSA. The security of those two algorithms is currentlyquestioned, and many alternatives are put forward. Since2001, DES is officially superseded by the AES, but othercandidates are promoted (for instance KHAZAD in Europe.)The same applies to asymmetric encryption primitives: theregional variants of the digital signature algorithms are nu-merous.

The smartcard industry is thus facing a dilemma: the de-vices are either cost-efficient or interoperable. The most vi-able solution thus consists in enabling an applicative agilitywithin the smartcard, using an ad hoc e-FPGA. This way,virtually any algorithm can be implemented with hardwareacceleration support: only the credentials (key, seed, etc.material) need to be resident into the smartcard, the algo-rithms being either downloaded or programmed on-the-flyfrom an internal ROM. The FASE architecture enables per-vasive reconfigurability by the use of hardware acceleratedmobile code.

In addition, security hardware must also protect itselffrom implementation-level malicious attacks. The securityenvironment is indeed harsh for embedded systems. Em-bedded system cannot afford tamper protection used other-wise for critical equipments. It must thus be assumed thatinvasive attacks [17] are likely to be used against those sys-tems. The security requirements are becoming very strin-gent: the two examples of sub-sections 4.2 and 4.3 illustratehow RTR can provide an elegant solution to the otherwisedifficult problem of mixed passive/active threats [18].

4.2. FASE Usage for DPA-proof HardwareAccelerators

The side-channel attacks [19] consist in monitoring theinstant power or electromagnetical emissions of a device inorder to extract information from the computation internals.The typical protections against those attacks basically boildown to doubling either the execution time (in the case ofsoftware) or the implementation area (in the case of hard-ware) [20]. We propose to use FASE random-access RTRcapability to modify the algorithm implementation at ev-ery invocation. This strategy makes it impossible for an at-tacker to collect consistent traces, thus discarding the DPAfundamental hypothesis that execution symptoms can be ac-cumulated for statistical treatments. The implementationmutations can be, in this example of DPA protection, con-trolled by a random number generator (RNG.) A snapshotsof an example DPA protected applications is depicted in fig-ure 12: the fitting function (RNG) is constant and alwaysactive and the evolving portion (DPA-proof cryproproces-sor) is reconfigured continuously.

4.3. FASE Usage for FA-proof HardwareAccelerators

Fault attacks (FA) [21] intentionally disturb a crypto-graphic algorithm so as to extract information from thefaulty executions. Usual counter-measures against this classof attack consist in adding redundant hardware to detect andpossibly correct the faults. However, the main drawback ofthis approach is that the additional hardware is useless if no

Figure 12. Example of the use of RTR toachieve a DPA-proof logic block.

fault or light attack occurs. We propose to take advantage ofFASE RTR to implement a graded and adaptative faults de-tection capability. This strategy allows for a cost-effectivesurvivability strategy: as the environment becomes moreaggressive, the algorithm implemented in FASE improvesits detection codes. In figure 13, a memory managementunit (MMU) interfaces a FA-resistant core with the rest ofthe SoC. The MMU is always active whereas RTR soft IPcores (e.g. DES, RSA using a Montgomery Modular Multi-plier) can be loaded into the sytem on demand.

5. Conclusions and Future Research

FASE is a different approach towards implementing run-time reconfigurability in FPGAs. In FASE the soft IP coresare not constrained to fit in rows/columns, and there is nonecessity of explicit reset signals in the RTL design otherthan the global reset. However, such explicit initializationcould also be done and, in that way, FASE is compatiblewith applications developed for existing RTR platforms.

Although this high granularity of reconfiguration maybe used for better utilisation of resources, it may also re-sult in fragmentation, and increases the reconfiguration la-tency. Possible enhancements could solve the issue of de-fragmentation and reducing the reconfiguration latency.

A FASE planned improvement is to replace synchronousCLB by asynchronous ones in order to cancel the timing clo-

zz

MEMORY

MULTIP

LIER

UNIT

MA

NA

GE

ME

NT

DES

MONTGOM

ERY

Figure 13. Example of the use of RTR toachieve a FA-proof logic block.

sure constraints. Moreover, with regard to security aspect,asynchronous logic coupled with RTR capability wouldgreatly improve the robustness.

References

[1] R. Sidhu, A. Mei, S. Wadhwa, and V. Prasanna. A self-reconfigurable gate array architecture. 10th InternationalWorkshop FPL 2000, August 2000.

[2] S. Hauck, T. Fry, M. Hosler, and J. Kao. The Chimaera Re-configurable Functional Unit. IEEE Symposium on FPGAsfor Custom Computing Machines, 1997.

[3] E. Tau, I. Eslick, D. Chen, J. Brown, and A. DeHon. A firstgeneration DPGA implementation. In In Proceedings of theThird Canadian Workshop on Field-Programmable Devices,May 1995.

[4] Xilinx. Development System Reference Guide.http://toolbox.xilinx.com/, 2005.

[5] Atmel. Programmable Logic and microcontroller products,2005. http://www.atmel.com/.

[6] B. Donlin and H. Singh. A Dynamic Reconfiguration RunTime System. Proc. 5th Annual IEEE Symposium on CustomComputing Machines, IEEE Computer Society Press, pages66–75, 1997.

[7] E. L. Horta, J. W. Lockwood, D. E. Taylor, and D. Parlour.Dynamic Hardware Plugins in an FPGA with Partial Run-time Reconfiguration. In Design Automation Conference(DAC), New Orleans, LA, June 2002.

[8] K. Nasi, T. Karouhalis, M. Danek, and Z. Pohl. FIGARO– an automatic tool flow for designs with dynamic reconfig-uration. International Conference on Field ProgrammableLogic and Applications, pages 590–593, Aug 24-26 2005.

[9] Secured Asynchronous FPGA for Embedded systems.http://www.comelec.enst.fr/recherche/safe/.

[10] N. Huot, H. Dubreuil, L. Fesquet, and M. Renaudin. FPGAArchitecture for Multi-Style Asynchronous Logic. In De-sign, Automation and Test in Europe (DATE’05), volume 1,pages 32–33, 2005.

[11] Virtual Socket Interface Alliance – VCI Standard. http://www.vsia.org/.

[12] V. Betz and J. Rose. VPR: A New Packing, Placement andRouting Tool for FPGA Research. Int’l Workshop on FPL,pages 213–222, 1997.

[13] V. Betz, J. Rose, and A. Marquardt. Architecture and CADfor Deep-Submicron FPGAs. Kluwer Academic Publishers,1999.

[14] S. Wilton. Architectures and Algorithms for Field-Programmble gate Arrays with Embedded Memories. PhDthesis, University of Toronto, 1997.

[15] G. Wigley and D. Kearney. The Development of an Oper-ating System for Reconfigurable Computing. In IEEE Sym-posium on FPGAs for Custom Computing Machines, NapaValley, volume , 2001.

[16] A. Marquardt, V. Betz, and J. Rose. Timing-Driven Place-ment for FPGAs. Int’l Workshop on FPL, pages 213–222,1997.

[17] R. J. Anderson and M. G. Kuhn. Tamper Resistance – a Cau-tionary Note. In The Second USENIX Workshop on Elec-tronic Commerce, November 18–21 1996. Oakland, Cali-fornia; ISBN 1-880446-83-9. (Online HTML version).

[18] MARS project website. http://www.comelec.enst.fr/recherche/mars/.

[19] P. Kocher, J. Jaffe, and B. Jun. Differential Power Analysis:Leaking Secrets. Advances in Cryptology: Proceedings ofCRYPTO’99, LNCS 1666:388–397, august 1999. Cryptol-ogy Conference, Santa Barbara, California, USA. (PDF).

[20] L. Goubin and J. Patarin. DES and Differential Power Anal-ysis (The ”Duplication” Method). In Proc. of CHES, volumeLNCS 1717, pages 158–172, 1999.

[21] H. Bar-El, H. Choukri, D. Naccache, M. Tunstall, andC. Whelan. The Sorcerer’s Apprentice Guide to Fault At-tacks. Cryptology ePrint Archive, report 2004/100.