WO2010097514A1

WO2010097514A1 - A method for secure remote reconfiguration of the programmable low-cost fpga hardware

Info

Publication number: WO2010097514A1
Application number: PCT/FI2010/050135
Authority: WO
Inventors: Tommi Parkkila; Juhani Latvakoski
Original assignee: Valtion Teknillinen Tutkimuskeskus
Priority date: 2009-02-27
Filing date: 2010-02-24
Publication date: 2010-09-02
Also published as: FI20095195A0

Abstract

The invention relates to a configuration method for configurating an FPGA (20) in a client device. The invention also relates to an FPGA module (212) capable of utilizing the method. The processing system in the client device is divided into two distinct functional blocks; a non critical domain (21 ) and a critical domain (22). The system processor (210) in the non-critical domain handles the configuration changes in the critical domain.

Description

A method for secure remote reconfiguration of the programmable low-cost FPGA hardware

Technical field of the invention

The invention relates to a method to execute secure remote reconfiguration of the programmable FPGA (Field Programmable Gate Array) based hardware. The method provides a safe downloading of new FPGA module to the asset devices, execution of specified validation tests and switching to use new FGPA module without causing problems to the continuous operation of the critical control functions.

Background of the invention The origin of the problem is a contradiction between the life-cycle of automation devices (e.g. in buildings, machines, processes) and rapidly evolving ICT technologies. The life-cycle of the automation devices is usually quite long e.g. 5-50 years. However, the state of the art ICT technologies are evolving more quickly e.g. 0.5 - 5 years. Therefore, the technologies of automation devices may become old and all the possibilities of new technologies are not properly taken into use, or even not at all. Today, only updates of software in automation devices may be possible even if it may be difficult in critical systems. The hardware updates happen only when it is not possible anymore to live with the current devices, the maintenance costs have increased too high, and therefore replacement of the complete automation device is required which is usually very expensive for a product/service provider.

The FPGA system vendors provide some tools for making configuration change in the FPGA system. However, they do not provide any means to make it during the life cycle of the asset products in a secure manner.

SRAM (Static Random Access Memory) based FPGA systems with processors and digital clue logic (hardware) can be reconfigured and reprogrammed as many times as needed. SRAM based FPGAs could be reconfigured locally via special JTAG (Joint Test Action Group) programming cable or through internal programming software using whatever communication media. The latter option enables FPGA systems to be reconfigurable remotely through Internet.

In contrast to microprocessor based embedded system FPGA system reconfiguration could be done by software upgrade, digital soft-hardware upgrade or both. In addition some of commercial FPGA devices allow both software and digital soft- hardware reconfigurations to be done while a part of the system is running. Then the procedure is called either dynamic or run-time reconfiguration. There are two approaches to run-time reconfiguration - partial reconfiguration (PR) and software programmable reconfiguration (SPR). Partial reconfiguration is a design flow that attempts to create reconfiguration regions in an FPGA device. Software programmable reconfiguration is a modification procedure of digital logic flows through internal or external software commands.

As an example of the prior art devices Altera's Cyclone III FPGA device family has support tools for remote reconfiguration. It has a special remote system upgrade dedicated circuitry, which is implemented in hard logic. The remote reconfiguration process can be described in four steps:

1 ) Nios Il soft-core processor (or digital hardware user logic) receives new configuration data from a remote location. Communication media used between the Cyclone III device and the remote location could be TCP/IP, UDP/IP, UART or a proprietary interface.

2) The Nios Il processor (or digital hardware user logic) writes received new configuration data into non-volatile configuration memory.

3) The Nios Il processor (or digital hardware user logic) initiates a reconfiguration cycle with the new or updated configuration data. 4) The dedicated remote system upgrade circuitry of the Cyclone III FPGA device detects and recovers from any error that might occur during or after the reconfiguration cycle, and provides error status information to the user design. Recovery capability dedicated system upgrade circuitry reverts the system back to a safe configuration image.

The remote system upgrade circuitry includes also a watchdog timer, which can be used as periodical functionality checker of a running user application. If the watchdog timer is not reset in certain time periods the dedicated system remote upgrade circuitry revert the system back to a safe configuration image.

Even though SRAM FPGA devices support remote reconfiguration and have spe- cial built-in circuitry for troubleshooting and recovering from malicious configuration errors, system reconfiguration on the field without a support and presence of a human inspector is not common. Critical system parts must achieve its requirements in every situation and usually then there must be some person on the field checking the functionality of the system. At its best the SRAM FPGA systems known in the art can be used for shortening design cycles and increasing life cycles of embedded products. The first benefit was achieved with FPGAs already in late 1990's, but the latter is still under development and without the proof. At the moment there is no method or procedure how to add new functionalities into existing embedded system remotely without harming the functionality of the existing running application. To achieve this there must be a strict procedure for secure remote communication, reliable reconfiguration and modular based system architecture with its self-testing feature.

Summary of Some Examples of the Invention

An aspect of the present invention is to provide a method and device arrangement by which a secure reconfiguration of FPGA system can be accomplished.

The aspects of the invention are achieved by a new method for secure reconfiguration of the multidomain FPGA architecture. The multidomain FPGA architecture is applied with the new secure reconfiguration method to enable software and hardware updates during the system life cycle of an asset device. The invention consist of safe downloading ofnew FPGA module file to the asset devices, execution of specified validation tests and switching to use new FGPA module without causing problems to the continuous operation of the critical control functions.

The secure reconfiguration method is realized by two functional building blocks: a reconfiguration server and a reconfiguration module in an asset device. The reconfiguration server is located in the network infrastructure side e.g. in the product service provider site, and the reconfiguration module is embedded into the automation device hardware in the asset side. The reconfiguration server is configured to manage remotely the products in general and more specifically their software and hardware configurations in a secure way. The reconfiguration module in the asset device may be a software component or even a separate processor in the automation device (asset device), which purpose is to manage the reconfiguration process of the asset device in a secure way.

The invention has an advantage that the asset device hardware can be smoothly and automatically updated which saves the product/service provider costs.

Furthermore, the invention has the advantage that it is possible to execute reconfiguration process remotely without any human in the remote asset site. Furthermore, the invention has the advantage that replacement of a physical hardware may not be needed at all.

Furthermore, the invention has the advantage that keeping the asset product technology up to date becomes easier which lowers the barrier to take latest tech- nologies into use.

The method according to the invention to reconfigurate a multi-domain platform comprising a non-critical domain and a critical domain is characterized in that in the method the reconfiguration module of the non-critical domain controls the configuration process in a processor module of both domains.

A programmable apparatus according to the invention comprising a reconfigurable multidomain platform is characterized in that the multidomain platform comprises at least one non-critical processor module, at least one critical processor module and external non-volatile memories.

A field programmable gate array according to the invention comprising several processor modules is characterized in that the field programmable gate array comprises:

- at least one system processor module which is configured to execute only non- critical tasks; and

- at least one processor module which is configured to execute only critical tasks.

Some advantageous embodiments of the invention are presented in the dependent claims. The basic idea of the invention is the following: The reconfiguration method comprises the following procedures executed between the reconfiguration server and reconfiguration module: authentication, initialization, self-test, reconfiguration and status check.

The purpose of the authentication procedure is to ensure that both of the commu- nication ends are who they claim to be. In the asset side, it is essential to know that the reconfiguration server is the correct one. On the other side, the product management shall be sure which of the reconfiguration modules they are interacting with. The system may use any available method for mutual authentication.

The mutual authentication is executed between reconfiguration server and asset system/reconfiguration module using any legacy authentication means to ensure that both ends of the communication have rights to do the aimed operation. If authentication procedure is OK, then the other procedures belonging to the configuration process may be accomplished. Otherwise, they are not possible to be executed at all. An enabler for the secure reconfiguration is a new multidomain FPGA architecture, which divides the computing platform into two different domains. The domains are called a non-critical domain and critical domain. Each domain comprises processor modules and special FPGA logic modules. The non-critical domain comprises also multiplexer/pulse width counter logic modules for time behavior testing of crit- ical domain's processor modules. The critical domain's functionality is controlled by system control logic called system trigger logic. The domains and processor modules are able to communicate in a specific way to enable a secure reconfiguration of a FPGA module. In this context a reconfiguration may mean configuration changes in either of the domains either in the utilized software of a processor module or in FPGA digital soft-hardware.

Further scope of applicability of the present invention will become apparent from the detailed description given hereafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only, since various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art from this detailed description.

Brief description of the drawings

The present invention will become more fully understood from the detailed description given herein below and accompanying drawings which are given by way of N- lustration only, and thus are not limitative of the present invention and wherein

Fig. 1 shows as an example main procedures of the configuration process according to the invention; Fig. 2a shows an example of a reconfigurable computing platform according to the invention;

Fig. 2b shows an example of a reconfigurable processor module according to the invention;

Fig. 3a shows as an example one software structure of a processor module;

Fig. 3b shows as an example another software structure of a processor module;

Fig. 4 shows an example of the FPGA configuration memory architecture;

Fig. 5. shows, as an exemplary flow chart, the main steps of software update in a module of the non-critical domain;

Fig. 6. shows, as an exemplary flow chart, the main steps of software update in a module of the critical domain; and

Fig. 7. shows, as an exemplary flow chart, the main steps of hardware update of the system configuration.

Detailed description

In the following description, considered embodiments are merely exemplary, and one skilled in the art may find other ways to implement the invention. Although the specification may refer to "an", "one; or "some" embodiment(s) in several locations, this does not necessarily mean that each such reference is made to the same em- bodiment(s), or that the feature only applies to a single embodiment. Single feature of different embodiments may also be combined to provide other embodiments.

The secure reconfiguration method is realized by two functional building blocks: reconfiguration server 1 1 , and reconfiguration module 12 in Fig. 2. The reconfigu- ration server 1 1 is located in the network infrastructure side e.g. in the product service provider site, and the reconfiguration module 12 is embedded for example into an automation device hardware in the asset side. The purpose of the reconfiguration server 1 1 is to manage remotely the products in general and more specifically their software and hardware configurations in a secure way. The reconfigura- tion module 12 may be a software component or a separate processor in the automation device (asset device), purpose of which is to manage the reconfiguration process of the asset device in a secure way. Before the reconfiguration can happen, successful authentication shall be executed.

Fig. 1 shows the main steps of the procedure according to the invention as an exemplary signal flow diagram. The reconfiguration method includes the following procedures executed between the reconfiguration server 1 1 and reconfiguration module 12: authentication 13, initialization 14, self-test 15, reconfiguration 16 and status check 17.

The purpose of the authentication procedure is to ensure that both of the communication ends are who they claim to be. In the asset side 12, it is essential to know that the reconfiguration server 1 1 is the correct one. On the other side, the product management shall be sure which of the reconfiguration modules 12 they are interacting with. The system may use any available method for mutual authentication.

Mutual authentication 13 is executed between reconfiguration server 1 1 and asset system/reconfiguration module 12 using any legacy authentication means to en- sure that both ends of the communication have rights to do the aimed operation.

If authentication procedure 13 succeeds, then the other procedures of the configuration according to the invention may be accomplished. If the authentication 13 does not succeed then the configuration process is advantageously interrupted.

After successful authentication in the initialization phase 14 new configuration data may advantageously be transferred from the reconfiguration server 1 1 to the reconfiguration module 12. The reconfiguration module 12 makes a self-test 15 to the received configuration data.

If the self-test 15 succeeds, then reconfiguration 16 may be accomplished. After reconfiguration a notification 17 about the result of the configuration change is transferred between reconfiguration module 12 and reconfiguration server 1 1.

Fig. 2a depicts an example of a reconfigurable computing platform 20 according to the invention. The exemplary platform 20 comprises an FPGA based computing system. Internal functionality of FPGA system 20 is divided into two independent domains; to a critical domain 22 (or domains) and to a non-critical domain 21 (or domains). Communication between depicted domains 21 and 22 is advantageously implemented by using full-duplex register or memory based data signals 213. Each data signal 213 is a non-blocking one way communication link either from non-critical domain processor module(s) 210 to critical domain's processor mod- ule(s) 224, 226 or 228 or in reverse direction. Amount of data signals and their widths varies according to current application.

There are also control signals 21 1 from the non-critical domain processor module 210 to digital logic modules 222 and other processor modules 224, 226 and 228 on FPGA system. These control signals 21 1 are used to control adjustments of digital logic modules and forcing processor modules 224, 226 and 228 of the critical domain 22 into different executing modes, i.e. normal, test, and reconfigurate. The critical domain 22 is responsible for time accurate functions and safety critical functions of the system. Less critical functions as user interface, networking and different other service interfaces can be implemented in non-critical domain 21. The core function of the invention is implemented into system processor module 210 in the non-critical domain 21 as a software task called reconfiguration module 212.

The non-critical domain 21 comprises multiplexer module 218 and pulse width counter logic module 216 for time behavior testing of critical domain's 22 processor modules 224, 226 and 228. Critical domain's functionality is controlled by system control logic called system trigger logic 222. The critical domain 22 and non- critical domain 21 and their processor modules are able to communicate in specific way to enable the secure reconfiguration method. In this context the reconfiguration means configuration changes on the field after system installation in either the non-critical domain 21 or in the critical domain 22. The reconfiguration may relate either to the software of a processor module or hardware reconfiguration in FPGA.

Disclosed below there is an exemplary description of the core architecture ele- ments of the new multidomain FPGA architecture according to the invention.

The non-critical domain 21 comprises a system processor module (System PM) 210 which is capable of running a multitasking operating system (e.g. uClinux). This system processor module 210 controls reconfiguration procedures and system self test functions by utilizing reconfiguration module 212.

Reconfigurable computing platform 20 comprises also system trigger logic 222. It may be an adjustable compare counter logic with reset interface. Advantageously its output may be used as a source of internal trigger 221 in the multidomain system 20. The non-critical domain 21 comprises also a multiplexer logic module 218 for selecting a set of two trigger signals 221 for counter logic module 216.

The non-critical domain 21 comprises also counter logic module 216 for measuring duty-cycles of the selected trigger signals 221 and time difference between high edges of the signals.

Non-critical domain 21 may be a compound of Altera's 32-bit Nios Il softcore processor module 210 and logic modules for internal verification and validation. The processor module 210 is executing a core of a multi-threading capable operating system, for example uClinux, uC/OS-ll or eCos. The processor module 210 advan- tageously uses an external non-volatile memory (parallel flash) for an application software reset memory 26 via a data bus 261. Furthermore the processor module 210 advantageously uses an external non-volatile memory (serial flash) for a configuration memory 24 via a second data bus 241. Furthermore the processor module 210 advantageously uses external volatile memory (RAM) 28 for an execution memory partitions (for example .text, .rdata, .rwdata, heap and stack) via a third data bus 281.

The critical domain 22 is implemented following a new modular architecture according to the invention. Modules i.e. components of the architecture can be either small Altera's Nios Il softcore based processor module or pure FPGA logic module or both which are responsible for controlling small time or safety-critical functions of the system. Every processor module 210, 224, 226 or 228 has its own block of FPGA internal memory (RAM) for execution memory (reference 2243 in Fig. 2b). They also may have own external volatile memory (not shown in Fig. 2a) for data saving and for execution of memory extensions.

Likewise in the non-critical domain 21 , external non-volatile application memory 26 (flash) is used for reset memory for processor modules 224, 226 and 228 in the critical domain 22. The modular architecture implementation according to the invention ensures minimal dependency between utilized processor modules. Advantageously a trigger reset signal 213a (trigger_reset) from the system processor module 210 may be used to reset system trigger input logic 222.

Also every processor module in critical domain 22 has a trigger input signal (trigger in) to wake up the processor module. The trigger signal may come either from external trigger source (reference 221 ) or from another processor module as a trigger output signal (references 221 a, 221 b and 221 c) (trigger_out). Trigger output signals 221 a, 221 b, 221 c are also used in executing tests for system's internal non-functional verification and validation. In the Fig. 2a this is depicted by an arrow 221. The trigger output signals 221 are fed in parallel to the multiplexer 218. The counter logic 216 uses outputs of the multiplexer 218 in the reconfiguration method according to the invention.

Altera's performance counter unit can also be used in system non-functional testing. With performance counter unit user can embed counter logic into application code to measure time spent in certain part of the code or number of times that some certain part of the code has been executed. In addition and depending on current application, modules can also have various numbers of different widths data input and data output signals.

Each of the processor modules 224, 226 and 228 may have also a measurement input. These are depicted in Fig. 2a by measure inputs 224a and 226a. Also a data input 224b from another processor module is possible. Advantageously the pro- cessor modules utilize these measures and data inputs for outputting a control signal 226b and/or 228b for controlling a process (not depicted in Fig. 2a).

In Fig. 2b there is depicted an exemplary processor module. The example depicts the processor module 224 of Fig. 2a. The processor module 224 comprises a softcore processor 2241. Measurement data may be inputted to the processor module 224 from other processor modules or sensors, reference 224a. System data input 213 may be inputted via data input register(s) 2245. The data input register 2245 outputs system data_in signal(s) 213a which may be fed to the softcore processor 2241. System control input 21 1 may be fed via PM control register 2244 as a control signal 21 1 a to the softcore processor 2241.

The softcore processor 2241 may output data_out signals 224b via data output register 2242 to the system processor module 210 or to other processor modules of the critical domain. The softcore processor 2241 may also output trigger_out signal(s) 221 a to other processor modules in the critical domain or to actuators.

The softcore processor 2241 may get a system trigger signal 221 via module trig- ger logic 2246. The module trigger logic may output a trigger in signal 2246a to the softcore processor 2241. On the other hand the softcore processor 2241 may output a trigger reset signal 2246b to the module trigger logic 2246.

Outputs of a performance counter unit 2247 are utilized by the softcore processor during various processes. The softcore processor 2241 may also utilize external volatile RAM memory 28 and external non-volatile application memory 26 when it executes defined process routines.

Software, which is executed by a processor module, for example processor mod- ule 224 in the critical domain, has a modular structure. The modular structure is depicted in Figures 3a and 3b. In Fig. 3a is depicted a prior art structure. It has two kinds of main states IDLE state 310 and EXECUTE state 320. In IDLE state 310 processor module is polling trigger_in signal 221 for launching actual defined function of the processor module. After trigger_in signal 221 has been set, the proces- sor module state is changed from IDLE state 310 to EXECUTE state 320. A change from the IDLE state 310 to the EXECUTE state 320 is depicted by reference 31 1.

Then in the EXECUTE state 320 the processor module 224 reads the control register 2244. How the processor continues execution depends on which run-mode is stated in the control register. Possible run-modes are normal, test or reconfigurate.

If the run-mode is reconfigurated, then the processor module 224 resets itself from the external non-volatile application memory 26. If the run-mode is normal or test then the processor module reads all application specific data in values, either incoming data_in_signals 224a in normal mode or data values from data input regis- ters 213a in test mode, executes all defined calculations, sets all application specific data_out signals 224b, sets trigger_out signal 221 a, resets 2246b internal module trigger logic 2246 to be ready for next trigger, resets trigger_out signal, and returns to IDLE state 310. After accomplishing these tasks it outputs Done signal 321.

Fig. 3b depicts as an example an updated software version of the existing and running software of Fig. 3a. In the updated software of Fig. 3b a new similar EXECUTE state II, reference 330, is added into software structure of Fig. 3a. It is also possible to add new application specific data_in, data_out and trigger_out signals into the processor module 224 hardware configuration. After executing defined commands the processor module 224 returns, references Done 321 a and Done 331 , to the IDLE state 310.

With the software structure of Fig. 3b and its updating procedure total software execution time of a processor module 224 will be increased, but the initial functionali- ty and time behavior of the processor module 224 remains the same compared to the software structure of Fig. 3a.

In the new multi-domain system architecture it is possible to make three kinds of functionality reconfigurations of the computing platform 20. If the computing plat- form is FPGA based single chip embedded system, then the possible reconfigurations are: software update in a module of the non-critical domain 21 , software update in a module of the critical domain 22 and hardware update of the system configuration.

The secure remote configuration procedure according to the invention, with a sup- port of the special multi-domain system architecture according to the invention, allows system upgrading and updating remotely without a presence of a service man. The main procedure flow for all configuration functions remains almost the same. Difference may be in the actual system reconfiguration phases of the procedure in question.

The main phases of the reconfiguration process are depicted in Figures 1 and 4. The reconfiguration process starts with an initialization phase, reference 14 in Fig.1. The reconfiguration server 1 1 takes secure connection (a secure channel) with asset product reconfiguration module manager 12. If in the reconfiguration module 12 there is already running reconfiguration mode, then the product infor- mation is exchanged via secure channel. If the reconfiguration module 12 is not running, then the initial FPGA configuration is updated into the place I, reference 24a of used non-volatile (Flash) configuration memory 24 in Fig. 4. If the reconfiguration module 12 is running, then the new FPGA configuration is updated into the memory place II, reference 24b, or memory place III, reference 24c. Next the reconfiguration server 1 1 asks the reconfiguration module 12 in the asset device to execute self-tests 15. After self tests the reconfiguration module announces the results to the reconfiguration server 1 1. The self tests may also optionally be activated by a local user of the asset device. In that case also the results of the self tests may be provided for the user. After self tests follows the reconfiguration phase 16. The reconfiguration server 1 1 knows the currently active configuration of the asset device. In addition it knows especially the architecture i.e. which parts of the system are critical and which are non-critical. The reconfiguration module 12 comprises also control of the tests, which are needed to be executed in a reconfiguration situation. Fig. 5 shows the main steps of the procedure according to the invention when a software update is accomplished in the non-critical domain 21 in an FPGA environment.

In step 500 the reconfiguration server 1 1 gives a software update to the reconfigu- ration module 12. In step 505 the reconfiguration module 12 saves downloaded new software into an external non-volatile application memory 26. Next in step 510 the reconfiguration module 12 executes predefined file tests for the received software file.

If the predefined file tests are not passed in step 525, the reconfiguration module 12 announces that the new software or software update was incompatible, step 530.

If the predefined file tests are passed in step 525, then in step 540 it is checked if the software is an update of a particular software or new software.

If the software is an update, then the reconfiguration module 12 takes a copy of an executable code of currently active software task and saves it to a software backup storage in external non-volatile application memory 26 in step 560.

In step 565 the reconfiguration module 12 copies the new saved software into the place of old software in the non-volatile application memory 26.

In step 570 the reconfiguration module 12 disables currently active software task and in step 575 the reconfiguration module 12 copies saved new software into the execution memory (i.e. external volatile RAM memory 28).

In step 580 the reconfiguration module 12 starts the downloaded new version of the software task from the execution memory 28.

In step 585 the reconfiguration module executes the predefined configuration tests for the new software. If the tests are successful then in step 599 the reconfiguration module 12 announces to reconfiguration server 11 or local user (if the user has been the activator of the reconfiguration procedure) that everything is in order.

If the tests are not successful in step 585 then in step 590 the reconfiguration module 12 disables currently active software task.

In step 592 the reconfiguration module 12 copies the old software from the software backup to the place of the new software in the external non-volatile applica- tion memory 26.

In step 594 the reconfiguration module 12 copies the backup software into the execution memory (external volatile RAM memory) 28. In step 596 the reconfiguration module 12 starts the backup software task from the execution memory 28. In step 598 the reconfiguration module 12 announces to the reconfiguration server 1 1 or local user that former software task has been returned into running.

Fig. 6 shows the main steps of the procedure according to the invention when a software update is accomplished in the critical domain 22.

In step 600 the reconfiguration server 1 1 gives a new software update to the re- configuration module 12. In step 605 the reconfiguration module 12 saves the downloaded new software into an external non-volatile application memory 26. Next in step 610 the reconfiguration module 12 executes predefined file tests for the software file.

If the predefined file tests are not passed in step 625, the reconfiguration module 12 announces that the software update was incompatible, step 630.

If the predefined file tests are passed in step 625 then in step 640 the reconfiguration module 12 backups a copy of the software in the external non-volatile application memory 26.

In step 645 the reconfiguration module 212 copies the new saved software into the place of old software in the non-volatile application memory 26.

In step 650 the reconfiguration module 212 stops the processor module under update, for example processor module 224.

In step 655 the reconfiguration module 212 downloads the new version of the software into the internal volatile execution memory part 2243 of the processor module 224 under update.

In step 660 the reconfiguration module 212 starts again the processor module under update, for example processor module 224.

In step 665 the reconfiguration module 212 executes the predefined configuration tests for the novel software. If the tests are successful then in step 680 the recon- figuration module 12 announces that everything is in order to reconfiguration server 1 1 or local user.

If the tests are not successful in step 665 then in step 670 the reconfiguration module 12 copies the old software from the software backup memory to the place of the new software in the external non-volatile application memory 26.

In step 672 the reconfiguration module 212 stops the processor module under update, for example processor module 224.

In step 674 the reconfiguration module 212 copies the old software from the software backup from the external non-volatile application memory 26 to the internal volatile execution memory part 2243 of the processor module 224 under update.

In step 676 the reconfiguration module 212 starts the processor module under update, for example processor module 224.

In step 690 the reconfiguration module 212 announces to the reconfiguration server 1 1 or local user that former software has been returned into running.

Fig. 7 shows the main steps of the procedure according to the invention when a configuration change is accomplished in the reconfigurable computing platform 20. A configuration change may be for example to disconnect one particular processor module in the reconfigurable computing platform 20. Another example of a configuration change may be an addition of a new processor module in the reconfigur- able computing platform 20.

In step 700 the reconfiguration server 1 1 gives a new configuration file to the reconfiguration module 12. The system processor module 210 receives the new configuration in reconfiguration module 212.

In step 705 the reconfiguration module 212 saves the downloaded configuration file into available memory location in the external non-volatile configuration memory 24. The configuration file may be saved either in place Il or place III depending on which one is currently in use for running configuration in the external nonvolatile configuration memory 24 (Fig. 2 and Fig. 4).

Next in step 710 the reconfiguration module 212 executes predefined configuration file tests for the new configuration file.

If the predefined configuration file tests are not passed in step 725, the reconfigu- ration module 12 announces that the new configuration file was incompatible, step 730.

If the predefined file tests are passed in step 725 then in step 740 the reconfiguration module 212 stops the old configuration of the reconfigurable computing plat- form 20.

In step 745 the reconfiguration module 212 initiates a system reconfiguration cycle, starting from the beginning of the memory location which was used for the new configuration file.

In step 750 the reconfiguration module 212 executes the predefined configuration tests for the new active configuration.

In step 780 the reconfiguration module 212 announces to the configuration server 11 that the reconfiguration has succeed.

If the tests are not successful in step 750 then in step 760 the reconfiguration module 212 stops the new configuration of the reconfigurable computing platform 20.

In step 762 the reconfiguration module 212 initiates a system reconfiguration cycle, starting from the beginning of the memory location of the previously used system configuration. The memory location may be either memory place I or memory place Il in the external non-volatile configuration memory 24 (Fig. 4).

In step 770 the reconfiguration module 12 of the asset device announces to the reconfiguration server 1 1 or local user that former system configuration has been returned into running.

In Figures 5, 6 and 7 and in corresponding description there are disclosed several self tests which the reconfiguration module is capable to accomplish. Some exam- pies of those tests are software file tests, configuration file tests and configuration tests. The configuration test may advantageously comprise performance measurements of processor modules for both domains using embedded performance counter unit in modules, dynamic system verification for critical domain through buffer interfaces, internal measurement signals and special internal test logic, and fault injection system validation for critical domain through buffer interfaces internal measurement signals and internal special test logic.

Furthermore there is a watchdog timer on a FPGA which can be used as periodi- cal functionality checker of a running user application configuration. If the watchdog timer is not reset in certain time periods the dedicated system remote upgrade circuitry reverts the system back to a safe configuration image.

Any of the method steps described or illustrated herein may be implemented using executable instructions in a general-purpose or special-purpose processor and stored on a computer-readable storage medium (e.g., disk, memory, or the like) to be executed by such a processor. References to 'computer-readable storage medium' and 'computer' should be understood to encompass specialized circuits such as field-programmable gate arrays, application-specific integrated circuits (ASICs), USB flash drives, signal processing devices and other devices.

The invention being thus described, it will be obvious that the same may be varied in many ways. Such variations are not to be regarded as a departure from the spirit and scope of the invention, and all such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the following claims.

Claims

1. A configuration method for a reconfigurable multi-domain platform (20) comprising a non-critical domain (21 ) and a critical domain (22), the method comprising: - authentication (13) of a reconfiguration server (1 1 ) and a reconfiguration module (12, 212) of a non-critical domain (21 ); and

- initialization (14) of the configuration by sending a configuration file to the reconfiguration module (12, 212), characterized in that in the method the reconfiguration module (12, 212) of the non-critical domain (21 ) controls the configuration process (16) in a processor module (224, 226, 228) of both domains.

2. A configuration method according to claim 1 , characterized in that the control of a hardware reconfiguration process comprises: - a step (705) where the reconfiguration module (12, 212) saves the received configuration file in a non-volatile configuration memory (24);

- a step (710) where the reconfiguration module (12, 212) executes self-tests to the received configuration file, and if the self-tests are passed, then;

- a step (740) where the reconfiguration module (12, 212) stops an old confi- guration of the reconfigurable computing platform (20);

- a step (745) where the reconfiguration module (12, 212) starts a reconfiguration cycle utilizing the saved configuration file;

- a step (750) where the reconfiguration module (12, 212) executes predefined configuration tests to received configuration file and after tests decides if configuration tests were passed or not; and

- a step (770, 780) where the reconfiguration module (12, 212) announces to the reconfiguration server (1 1 ) the result of the configuration cycle.

3. A configuration method according to claim 2 characterized in that when the predefined configuration tests are not passed then the control of the configuration process further comprises:

- a step (760) where the reconfiguration module (12, 212) stops the new configuration of the reconfigurable computing platform (20);

- a step (762) where the reconfiguration module (12, 212) starts a reconfiguration cycle utilizing the previous configuration file from the external non-volatile configuration memory (24).

4. A configuration method according to claim 1 , characterized in that the control of a software reconfiguration process in a processor module of the critical domain comprises:

- a step (605) where the reconfiguration module (12, 212) saves a received soft- ware file in a non-volatile application memory (26);

- a step (610) where the reconfiguration module (12, 212) executes self-tests to the received software file, and if the self-tests are passed, then;

- a step (640) where the reconfiguration module backups the current software in an external non-volatile application memory (26) - a step (645) where the system processor module (210) copies the new software into the place of the backuped software in the external non-volatile application memory (26);

- a step (650) where the system processor module (210) stops a processor module (224, 226, 228) of the critical domain; - a step (655) where a system processor module (210) downloads the received software into an internal volatile execution memory (2243) of the processor module under reconfiguration;

- a step (660) where the system processor module (210) starts the stopped processor module (224, 226, 228) utilizing the new software; - a step (665) where the system processor module (210) executes predefined software tests to received software; and

- a step (680, 690) where the reconfiguration module announces to the reconfiguration server (1 1 ) the result of the configuration cycle.

5. A configuration method according to claim 4, characterized in that when the predefined software tests are not passed then the control of the configuration process further comprises:

- a step (670) where the system processor module (210) copies the backuped software in to the place of the new software in the external non-volatile application memory (26)

- a step (672) where the system processor module (210) stops the processor module (224, 226, 228) in the critical domain;

- a step (674) where the system processor module (210) downloads the backed up software into an internal volatile execution memory (2243) of the processor module under reconfiguration; and

- a step (674) where the system processor module (210) starts the processor module (224, 226, 228) under reconfiguration in the critical domain.

6. A programmable apparatus comprising a reconfigurable multidomain platform (20), characterized in that the multidomain platform (20) comprises at least one non-critical processor module (210), at least one critical processor module (224, 226, 228) and external non-volatile memories (24, 26).

7. The programmable apparatus according to claim 6, characterized in that the non-critical system processor (210) comprises a reconfiguration module (212) which is configured to control a reconfiguration process of a critical processor module (224, 226, 228).

8. The programmable apparatus according to claim 7, characterized in that the non-critical system processor (210) is configured to utilize in the reconfiguration process triggering information from a multiplexer (218) where to triggering signals from all critical processor modules (224, 226, 228) are connected.

9. The programmable apparatus according to claim 8, characterized in that the non-critical system processor (210) is configured to also utilize timing information from a counter logic (216) during the reconfiguration process.

10. The programmable apparatus according to claim 7, characterized in that the system processor module (210) is configured to receive a configuration file from a reconfiguration server (1 1 ) which configuration file is configured to be saved in an external non-volatile memory (24, 26).

11. The programmable apparatus according to claim 10, characterized in that the system processor module (210) is configured to utilize in reconfiguration the configuration file saved in the non-volatile memory (24, 26).

12. A field programmable gate array (20) comprising several processor modules (210, 224, 226, 228), characterized in that the field programmable gate array (20) comprises:

- at least one system processor module (210) which is configured to execute only non-critical tasks; and

- at least one processor module (224, 226, 228) which is configured to execute only critical tasks.

13. The field programmable gate array (20) according to claim 12, characterized in that the system processor module (210) comprises also a reconfiguration mod- ule (212) for controlling a configuration process in a processor module (224, 226, 228) executing critical tasks.

14. The field programmable gate array (20) according to claim 13, characterized in that the system processor module (210) comprises also a counter logic (216) and a multiplexer (218) for giving timing information to the reconfiguration module (212) of a current state of the processor module (224, 226, 228) under reconfiguration.