FR3045866A1 - COMPUTER COMPRISING A MULTI-HEART PROCESSOR AND A CONTROL METHOD - Google Patents

Abstract

The computer comprises common hardware resources (12) accessible to the cores (10) according to a sequence of time windows and according to predefined access rules stored in at least one memory of the computer (6) and implemented by the computer ( 6) in operation, according to which in each time window, each core (10) has, for each common resource (12), a guaranteed access, an on-demand access or a forbidden access to the common resource (12), the sequence including at least one time window during which at least one core (10) has guaranteed access to at least one common resource (12) and at least one time window during which a plurality of cores (10) have on demand access to the same common resource (12), access to said same common resource (12) being attributable to one or more cores (10) among said plurality of cores (10) having access on demand, according to the access rules and according to the access requests issued by said plurality of cores (10).

Description

COMPUTER COMPRISING A MULTI-HEART PROCESSOR AND

CONTROL METHOD

The present invention relates to the field of multi-core processor computers, comprising several physically distinct cores sharing common hardware resources.

Each core of a multi-core processor is a computing unit that is physically distinct from other cores. The presence of multiple cores allows the parallel execution of several software applications, in order to offer better overall performance.

For running software applications, cores use common hardware resources. These common resources are for example memories, in particular a main memory, an interconnection network, input / output interfaces (or I / O interface) of the computer (PCIe fast bus or Ethernet network for example) or an interface of interconnection between the hearts and these different common resources.

Hearts compete for the use of these common resources. This competition causes uncertainty in the processing time of the data by the multi-core processor.

However, on-board electronic systems such as those used in the avionics field, the space domain or the railway domain, need determinism in the duration of the processing to satisfy certification constraints.

It is possible to organize the computer codes of the software applications executed by the cores so as to ensure a scheduling of the tasks such that at a given moment, only one heart has the right to access the common resources. However, this design of software applications is very restrictive and difficult to adapt to embedded electronic systems, especially those that are developed without knowledge of the software applications they will have to perform, as is the case of an integrated modular avionics system (or "IMA" for "Integrated Modular Avionics").

It is possible to deploy a software controller implementing a common resource access policy based on the allocation of time windows to the cores, each core having exclusive access to the common resources during the time slots allocated to it. The allocation of time windows is predetermined and static. However, access to common resources is not optimized and the processing time is affected, which can be detrimental in embedded electronic systems.

One of the aims of the invention is to propose a multi-core processor computer implementing an effective control method, making it possible to improve the use of common resources while ensuring a good level of determinism in the duration of data processing. For this purpose, the invention proposes a computer comprising a multi-core processor having several physically distinct cores and common hardware resources shared by the cores and accessible to the cores according to a sequence of time windows and according to predefined registered access rules. in at least one memory of the computer and implemented by the computer during operation, according to which in each time window, each core has, for each common resource, guaranteed access, on-demand access or forbidden access to the resource common, the sequence including at least one time window during which at least one core has a guaranteed access to at least one common resource and at least one time window during which several cores have on-demand access to the same common resource, the access to the same common resource being attributable to one or more cores parm i said multiple cores having access on demand, according to the access rules and according to the access requests issued by said multiple cores.

The calculator optionally includes one or more of the following characteristics, taken separately or in any technically possible combination: the sequence comprises at least one time window during which access to a common resource or to each common resource is reserved exclusively for a or multiple cores with guaranteed access to this common resource or common resource; the sequence comprises at least one time window during which access to a common resource or to each common resource is reserved exclusively for a single and unique core having a guaranteed access to this common resource or to each common resource; the sequence comprises at least one time window during which the access to a common resource or to each common resource is attributable exclusively to one or more cores among several cores having access on request to this common resource or to each common resource; the sequence comprises at least one time window during which access to a common resource or to each common resource is attributable exclusively to one and only one of several cores having access on request to this common resource or to each common resource; the sequence comprises at least one time window during which access to first common resources is attributable to at least one heart of a first group of cores according to a first set of access rules and access to the second common resources distinct first common resources is attributable to at least one heart of a second group of cores disjoined from the first group of cores according to a second set of access rules independent of those of the first set of access rules; the sequence comprises a first phase having time windows having the same first duration and a second phase having time windows having the same second duration different from the first duration; it is configured so that each core executes an access controller applying the access rules to determine, for each time window, whether this heart is at a guaranteed access or on-demand access to a common resource or to each resource common during this time window; the access controllers of the different cores are synchronized from a reference clock common to the cores; the access controller of each heart is executed by the heart from a memory cache of the heart physically integrated into the core, without accessing the common resources; each time window during which several cores have on-demand access to at least one common resource, includes a notification period during which each heart indicates to the other cores whether or not it wishes to reserve the time window, a decision period during wherein each core determines whether it is allowed to access the shared resources during the time window, based on requests from the other cores, and a usage period during which each authorized heart can access the shared resources. The invention also relates to a method of controlling a multi-core processor having a plurality of physically distinct cores having access to common hardware resources shared by the cores and accessible to the cores in a sequence of time windows and according to access rules defined in at least one memory of the computer and according to which, in each time window, each core has, for each common resource, a guaranteed access, access on request or a forbidden access to the common resource, the sequence including at least one time window during which at least one core has guaranteed access to at least one common resource, and at least one time window during which several cores have on-demand access to the same common resource, the method comprising, during operation of the processor , assigning access to the same common resource to an o u more than one of said plurality of cores having access on demand, depending on the access requests issued by said multiple cores. The invention and its advantages will be better understood on reading the description which will follow, given solely by way of example, and with reference to the appended drawings, in which: FIG. 1 is a schematic view of a calculator an onboard avionics system, the computer comprising a multi-core processor having several cores sharing common resources; FIGS. 2 to 5 are temporal friezes illustrating temporal partitions for sharing common resources; FIG. 6 is a temporal frieze illustrating different phases of a temporal window of a temporal partition of sharing of common resources; FIG. 7 represents graphs illustrating different phases of acquisition, execution and rendering by two cores of a multi-core processor.

In FIG. 1, an avionics system 2 embedded in an aircraft 4 has a computer 6 having a multi-core processor 8 comprising several cores 10, common resources 12 shared by the cores 10, and an electronic interconnection 14 via which hearts access the common resources 12.

Hearts 10 are physically distinct. Each core 10 is an individual computing unit comprising its own electronic components, distinct from those of the other cores 10.

The common resources 12 are hardware resources shared by the cores 10. The common resources 12 are, for example, memories, such as a main memory, a shared cache memory (for example a level 2 memory called Cache L2 or level 3 so-called L3 Cache), or input / output interfaces (or I / O interface). An input / output interface makes it possible to transmit or receive signals on a communication bus (not shown), for example an avionics communication bus for communication between several computers or between the computers and measuring probes or sensors. actuators. The interconnection 14 is for example an interconnection bus. Preferably, all the cores 10 of the processor 8 are connected to the common resources 12 via the same and only means formed by the interconnection 14.

Each core 10 is able to execute one or more useful software applications, preferably under the control of a computer operating system (or "OS" for "Operating System" in English), which is a particular software application executed by the core 10 and which controls the use of software or hardware resources accessible to this core 10 (including common resources 12) by the useful software applications. Each core 10 can have its own individual operating system, but also have an operating system shared between several cores 10. In the following, the term "AP application" refers to useful software applications or the operating system performed by a heart 10.

At its execution, an AP application executed by a heart 10 issues requests that are processed by the heart 10. A request generally corresponds to a request to read or write to a specific address of the addressable memory space.

To respond to a request from an application AP executed by a heart 10, the core 10 uses in particular the common resources 12. In the following, a "transaction" refers to an exchange of data between a determined core 10 and a common resource 12 determined.

When executing the AP applications by the cores 10, the cores 10 compete for the use of the common resources 12. However, each transaction between a determined core 10 and a common resource 12 determined must be performed with a time cost thick headed.

The sharing of common resources 12 by several cores 10 therefore requires defining a common resource sharing policy 12, that is to say a set of rules restricting the concurrent activity of the different cores 10 in the common resources 12.

As illustrated in FIG. 2, the computer 6 is configured to implement a common resource sharing policy 12 based on a sequence of time windows F1, F2 including at least one time window during which at least one core 10 has one access. guaranteed to at least one common resource 12 without having to request a prior authorization, and at least one time window during which several cores 10 have access on request to at least one common resource 12, each core 10 being authorized or not to access the common resource 12 according to the access requests made by the other cores 10 and predefined access rules.

The window sequence is periodic. The guaranteed or on request access of each core 10 to each common resource 12 during each time window F1, F2, is predefined during the design and configuration of the computer 6.

In each time window, for each common resource 12, each core 10 selectively has a guaranteed access to this common resource 12, on-demand access to this common resource 12 or forbidden access to this common resource 12.

The access rules define, for each time window F1, F2, each core 10 and each common resource 12, if, during the time window F1, F2, the core 10 has a guaranteed access to the common resource 12, an access on request to the common resource 12 or a forbidden access to the common resource 12.

In one embodiment, during at least one time slot, several cores 10 have guaranteed access to the same common resource 12 and / or during at least one time slot, at least one core 10 has guaranteed access to a common resource 12 and several other cores 10 have on-demand access to this same common resource 12. In both cases, cores 10 compete for access to the same common resource 12.

Preferably, in each time window for which a core 10 has a guaranteed access to a common resource 12 determined, this core 10 is the one and only heart to have access to this common resource 12 determined. This core 10 has exclusive access to this common resource 12. No other core 10 has guaranteed access or on-demand access to this common resource 12. All other cores 10 have forbidden access to this common resource 12.

In one embodiment, at least one time window, at least one core 10 has guaranteed access to at least one first common resource 12 and several other cores 10 have access on request to at least one second common resource 12, each first common resource 12 being distinct from each second common resource 12.

In one embodiment, at least in a time window, and especially in a phase comprising a plurality of successive time windows, a first group of cores 10 with a guaranteed or on request access to a first group of common resources 12 according to a first set of access rules specific to this first group of cores 10, and a second group of cores 10, distinct from those of the first group of cores 10, has a guaranteed or on request access to a second group of common resources 12 distinct from those of the first group of common resources 12, according to a second set of access rules specific to this second group of cores 10 and independent of those of the first set of access rules. Such access rules are acceptable when access to common resources 12 does not cause interference in the interconnection 14.

In general, each core 10 has, for each common resource 12, at least one time window during which it has a guaranteed access or access on request to this common resource 12.

In a general manner, in the same time window, the access rules of each core 10 to the common resources 12 are different from a common resource 12 to the other, or identical for all the common resources 12. In a time window, a heart 10 may have guaranteed access to a common resource and on-demand access to another common resource 12.

In one embodiment, in each time window, the access rules of each core 10 to the common resources 12 are identical for all the common resources 12. Thus, in each time window, each core 10 selectively has a guaranteed access to each common resources 12, on-demand access to each common resource 12 or forbidden access to each common resource 12.

In the embodiment of FIG. 2, in each time window, the access rules of each core 10 to the common resources 12 are identical for all the common resources 12.

The time windows include time slots with guaranteed access F1 and time slots with controlled access F2.

Preferably, in each guaranteed access time window F1, a single core 10 to which this window is said to be "allocated" has guaranteed access to common resources 12. All other cores 10 have forbidden access to common resources 12.

In each time slot with controlled access F2, several cores 10 to which this window is said to be "allocated", have on request access to the common resources 12, the access of each heart 10 having requested access to the common resources 12 being authorized or prohibited in depending on the access requests made by the other cores 10 and predefined access rules.

A heart 10 to which the F2 time slot is not allocated, has forbidden access to common resources 12.

When a heart 10, after request, has an authorized access to the common resources 12 in a time-controlled access window F2, this time-controlled access window F2 is said to be "allocated" to this heart 10.

Preferably, each controlled access time window F2 is allocated based on the access requests made by the cores 10 and predefined access rules, to a single and only one of the cores 10 requesting access to the common resources 12 during this time window with controlled access F2. The access authorization in a guaranteed access time window F1 is invariable during the operation of the computer 6. It can not be modified during the operation of the computer 6. Only the core 10 at which this time window with guaranteed access F1 is allocated is allowed to access common resources 12 during this guaranteed access time window F1. The allocation of a time-controlled access window F2 is obtained on request from one or more core (s) to which the controlled access time window F2 has been allocated, during the operation of the computer 6. The sequence is periodic and the access request must be reiterated at each occurrence of the time-controlled access window F2.

Optionally, the sequence comprises at least one forbidden access time window F3, during which each core 10 has a forbidden access to the common resources 12. This allows, for example, to allow access to the common resources 12 to an external software or hardware component. supported by the sharing policy.

Returning to FIG. 1, the application of the rules for access to common resources 12 during the time windows is advantageously performed in a manner distributed by the cores 10.

Each core 10 has a private cache memory 16, which is used exclusively by this core 10, and which is physically integrated in the core 10.

Each core 10 includes a software access controller 18 to control the access of this core 10 to the common resources 12. The access controller 18 is a software layer interposed between the applications executed by the core 10 (including a system of access control). operation performed by the heart 10) and the heart 10 itself. Access controller 18 is a computer program that includes code instructions specific to that program.

Each core 10 executes its own access controller 18 locally, without using the common resources 12. The access controller 18 includes code instructions that are fully stored in the private cache 16 of the core 10 and executable using only the private cache 16 of this heart 10.

The private cache 16 of the core 10 has sufficient capacity for the execution of the access controller 18. The execution of the access controller 18 by the core 10 does not therefore require the issuance of transactions to the common resources 12 , likely to interfere with the activity of other hearts 10 in common resources 12.

The access controller 18 of each core 10 is configured to intercept requests addressed to the core 10 by the AP applications executed by this core 10, before the corresponding transactions are sent by the core 10 to the common resources 12, and to command the transmission by the heart 10 of at least one transaction associated with each intercepted request, in a time slot allocated to the heart 10.

The access controller 18 of each core 10 is configured to implement the common resource sharing policy with respect to the core 10 executing the access controller 18. Each access controller 18 applies access rules stored by example in the RAM 16 of the heart 10.

The access controllers 18 are synchronized to a common clock 22. This makes it possible to ensure that each access controller 18 is in the same time window of the sequence at each instant.

For each guaranteed access time window F1, the access controller 18 of each core 10 to which this guaranteed access time window F1 is allocated, authorizes the access of this core 10 to the common resources 12.

The time slots with controlled access F2 are attributable to one or more heart (s) 10, on request made by this (these) heart (s) 10. The attribution made on request makes it possible to attribute the time window to a heart 10 only on request of this heart 10, if an application AP executed by this heart 10 has issued a request requiring the issuance of a transaction.

The access controller 18 of each core 10 requests the allocation of each regulated access time window F2 allocated to this core 10 if an application AP executed by this core 10 needs access to the common resources 12.

For the assignment of a time-controlled access window F2, each access controller 18 having intercepted a request, sends a visible access request from the access controllers 18 of the other cores 10, and each access controller 18 determines locally whether the controlled access time window F2 is allocated to the corresponding core 10 by application of access rules 20. If the controlled access time window F2 is allocated to the heart 10, the access controller 18 transmits the transaction corresponding to the intercepted request.

It is possible for several cores 10 to request the allocation of the same access controlled time window F2 which is attributable to a limited number of cores strictly less than the total number of cores of the processor 8.

To adjust these cases, the access rules 20 include, for example, a priority order associated with each core 10 for each time slot with controlled access F2. If two cores 10 request access to the same access controlled time window F2, the heart 10 having the highest priority order will be assigned priority time window F2 access priority. Even if each core 10 executes an access controller 18 which locally applies the access rules 20 adapted to this core 10, the access rules applied by the access controllers 18 of the different cores 10 are of course defined so consistent.

For example, for a given time window: - if the access to common resources 12 must be authorized to a single core 10 identified at design (ie it is a guaranteed access time window F1 allocated exclusively to this heart 10), the access rules define a guaranteed access for this core 10 and a forbidden access for all the other cores 10; - if the access to the common resources must be authorized to several cores only identified at the design (ie it is a guaranteed access time window F1 allocated to several cores 10), the access rules define for example a guaranteed access to the cores in question and forbidden access for all other cores 10; if the access to the common resources 12 must be authorized to a single heart among several cores that can make the request, the access rules define for example an access on demand for some cores 10 and a forbidden access for all the other cores 10, the cores 10 having an authorized access on request having different priorities; if the access to the common resources must be allowed to a particular core and only one other core on demand, the access rules define for example that the particular core has a guaranteed access and that all the other cores have on-demand access or forbidden access, cores 10 having on-demand access having different priorities, - if access to common resources must be allowed to no more than two cores 10 access rules define for example that all cores 10 have on-demand access or forbidden access, the same priority not being shared by more than two cores 10 having on-demand access or that all cores 10 have on-demand access or forbidden access, the cores 10 having on demand access with different priorities.

The sequence of time windows and the access rules can be defined during the design, as a function, for example, of the AP applications executed by the cores 10 and of the electronic architecture of the computer 6, and in particular of its interconnection 14 and of its common resources 12.

A sequence may comprise, for example, for each common resource 12 or for the common resources 12 as a whole, at least one guaranteed access time slot allocated exclusively to a single core, at least one guaranteed access time slot allocated to several cores, at least one controlled access time slot attributable to a single core at a time and / or at least one time controlled access slot attributable to multiple cores at a time.

In the embodiment of Figure 3, the sequence of time windows comprises several phases in which the time window configurations differ.

More particularly, the sequence of time windows comprises a first phase PH1 comprising a first series of cyclic time windows SE1 repeated several times during the first phase PH1, and a second phase PH2 comprising a second series SE2 of cyclic time windows repeated several times during the first phase. second phase PH2.

The first series SE1 and the second series SE2 differ in order and number of time windows. The first series SE1 here comprises two time-controlled access windows F2 followed by a guaranteed access time window F1. The time windows of the first series SE1 and the second series SE2 have the same duration.

In the variant of FIG. 4, the time windows of the first series SE1 have a first equal duration for all the windows of the first series SE1, and the time windows of the second series SE2 have a second duration equal for all the time windows. of the second series SE2, the first duration being different from the second duration.

In the embodiment illustrated in FIG. 5, the sequence comprises a first phase PH1 during which access to the common resources 12 is determined according to a first set of access rules determined for a first group G1 of cores 10 and according to a second set of access rules for the cores 10 of a second group G2 of cores 10 disjoint from the first group G1 of cores, the access rules of the first game being independent of those of the second game, and a second phase PH2 during which access to common resources 12 is determined for all cores 10 according to common interdependent access rules.

Such an embodiment is possible especially if, because of the electronic architecture and / or the configuration of the applications AP executed by the cores 10, it is possible to determine that the cores 10 of the first group G1 and the cores of the second group G2 will not attempt to access the same common resources during the first phase PH1.

For each access controlled time window F2, each core 10 that can request access to the common resources 12 must first request access to the common resources 12 and determined whether the time slot with controlled access F2 is allocated to it according to the possible requests of the other cores 10 and access rules.

As illustrated in FIG. 6, each time slot with controlled access F2 comprises a notification / reception period P1 in which the access controller 18 of each core 10 notifies the access controllers 16 of each other core 10 whether it wishes to use the time window and receive the notifications of the access controllers 18 of the other cores 10, a decision period P2, in which the access controller 18 of each core 10 applies the access rules to determine if the time window is effectively allocated to this heart 10, and a useful period P3 during which each heart 10 authorized to use the time window issues transactions.

Advantageously, the access controller 18 of each core 10 to which a guaranteed access time slot is allocated does not implement the notification / reception period for this time window.

In one embodiment, the access controller 18 of each core 10 is configured to control the requests of each AP application executed by each core 10 as follows: the access controller 18 intercepts the request and plans the transaction (ie it determines how the transaction will be performed); the access controller 18 puts itself in active waiting for the next time slot allocated to the heart 10, independently of the guaranteed or regulated character of the accesses; when the time slot allocated to the heart 10 is active, the access controller 18 performs the planned transaction; • The access controller 18 completes the transaction by verifying that the transaction has proceeded correctly, optionally, collects usage statistics, and then prepares the resumption of the execution of the application AP.

During the active wait, the access controller 18 by performing the following routine: - search for the next time window; if the next time window is a guaranteed access time window for this core without any necessary request, execution of the transaction in this time window; if the next time window is a time slot with controlled access for this core, and the access controller has been configured to use this time window, request for reservation of the time window, if the reservation has succeeded, issue of the transaction in the time window, - otherwise, return to search for the next time window.

The operation of the cores 10 has been described previously for time windows F1, F2 with identical access rules for all the common resources 12. As a variant, it is possible to provide in each time window specific access rules for each common resource 12, with similar operation of the cores 10 and in particular their access controllers 18. The access of the cores 10 according to a sequence comprising guaranteed access time windows allocated in a predefined manner to one or more cores ( s) 10 and time-controlled access windows assignable to one or more core (s), these cores 10 performing these requests only if necessary and / or only during certain phases of execution, can preserve the determinism by improving the access to the common resources 12 for each core 10 according to the needs of this core 10, also called "bandwidth". on demand ".

For example, in a calculator compliant with the ARINC 653 standard, each core 10 executes an operating system in charge of scheduling the useful applications executed by the heart 10. The useful applications are distributed in containers called partitions, each partition embedding a or several processes.

The operating system is responsible for scheduling partitions and processes within partitions. It must guarantee strict spatial and temporal partitioning between partitions. The partitions are sequentially executed according to a periodic sequence of time windows.

The operating system regularly changes partitions and successively performs the following operations when the partition is changed: - the outgoing partition is completed and its context is saved; the cache memory is flushed out of the content belonging to the outgoing partition; the inter-process and inter-partition communications are carried out in ports provided for this purpose, for example in a main memory; and - the execution of the incoming partition is prepared.

The change of partition must be realized in a limited time, as short as possible. It is therefore advantageous to offer a high guarantee on the bandwidth available to each core during the partition change. The bandwidth requirement is highest for the flush phases of the cache and inter-partition communication.

The guaranteed bandwidth of the cores 10 is improved by shifting the high bandwidth demand phases of the cores 10, i.e. by shifting in particular the flush phases of the cache memory and inter-partition communication of the different cores.

With the proposed shared resource sharing, this guaranteed bandwidth can be improved during cache flush and cross-partition communication, where bandwidth requirements are high.

Moreover, to ensure the determinism of a computer comprising a multi-core processor, it is possible to configure the software applications AP executed by each core 10 according to an execution model in which each software application AP is decomposed into phases of operation. execution, during which the heart 10 will not perform a transaction and in communication phases, during which the heart 10 will perform transactions, and configure a global scheduling AP software applications executed by the different cores 10 ensuring that at least a heart 10 is in communication phase at any time.

In one possible embodiment, each task to be executed by an AP software application is divided into three phases: acquisition A, execution E and restoration R.

During acquisition A, each task repatriates locally all the data necessary for the calculation. During the execution phase E, each task is authorized only to access private resources of the heart 10, without transaction issuing. During rendering R, each task provides the results of the calculations to other tasks that may need them. The transactions (and therefore the potential interferences between the cores 10) are therefore restricted to the acquisition A and reproduction R phases.

This division makes it possible to define scheduling tasks at the level of the processor 8 so that at a given moment, a single communication phase (acquisition A or reproduction R) is in progress, together with one or more execution phases. If it is possible to obtain a scheduling of tasks which ensures the separation of the communication phases (acquisition A and reproduction R) and execution (execution E), during these tasks, it is possible to optimize the rate of access to common resources 12 (or "bandwidth") while preserving a portion of this bandwidth for the cores 10 that execute an execution phase.

As illustrated in Figure 8, in which each graph represents the bandwidth requirement of a respective core over time, the bandwidth requirements are higher in the communication periods (acquisition A or return R).

It is possible to provide a plurality of cores 10, each core 10 performing its communication phases in bandwidth on demand, ie in time slots with controlled access allocated to this core 10, and guaranteed bandwidth execution phases, ie in guaranteed access time windows allocated to this core 10.

During a communication phase of a heart 10, the sequence of time windows comprises several time windows including one or more time-controlled access window (s) allocated to this heart 10.

During a heart execution phase, the sequence of time windows includes several time windows including one or more guaranteed access time window (s) F1 allocated to this heart 10.

To optimize the bandwidth, cores 10 perform communication phases that partially overlap in time (here acquisition phases A). This does not require reconfiguration of an access controller 18 installed on the cores 10.

Thanks to a task-driven execution model, it is possible to adapt existing software applications to obtain optimized software applications for setting up access control as proposed.

Controlling access from cores of a multi-core processor to shared resources through static allocation time windows and dynamic allocation time windows improves cores' access to common resources. This reduces the latency of performing certain tasks. Time windows not used by some cores can be used by other cores. In addition, this access control allows a greater flexibility of allocation of bandwidth to certain cores, in a variable manner over time. This access control makes it possible to migrate applications to optimized computer code structuring for execution on a multi-core processor by supporting a relaxation of the strict separation constraint between the different phases (acquisition, execution, restitution) by guaranteeing minimum traffic for access that may occur during an execution phase.

Claims (12)

1calculator comprising a multi-core processor having several cores (10) physically separate and common hardware resources (12) shared by the cores (10) and accessible to the cores (10) according to a sequence of time windows and according to rules d predefined accesses stored in at least one memory of the computer (6) and implemented by the computer (6) during operation, according to which in each time window, each core (10) has, for each common resource (12) , guaranteed access, on-demand access or forbidden access to the common resource (12), the sequence including at least one time window during which at least one core (10) has guaranteed access to at least one common resource (12). ) and at least one time window during which several cores (10) have on-demand access to the same common resource (12), access to said same common resource (12) and attributable to one or more cores (10) among said plurality of cores (10) having on-demand access, according to the access rules and according to the access requests issued by said plurality of cores (10). 2, - computer according to claim 1, wherein the sequence comprises at least one time window (F1) during which access to a common resource (12) or each common resource (12) is reserved exclusively for one or more cores (10) having guaranteed access to this common resource (12) or to each common resource (12). 3. - Calculator according to claim 1 or 2, wherein the sequence comprises at least one time window (F1) during which access to a common resource (12) or to each common resource (12) is reserved exclusively to a single and single cores (10) having guaranteed access to that common resource (12) or each common resource (12). 4, - calculator according to any one of the preceding claims, wherein the sequence comprises at least one time window (F2) during which access to a common resource (12) or to each common resource (12) is attributable exclusively to one or more cores (10) among a plurality of cores (10) having on demand access to that common resource (12) or each common resource (12). 5. - computer according to any one of the preceding claims, wherein the sequence comprises at least one time window (F2) during which access to a common resource (12) or to each common resource (12) is attributable exclusively to a single heart (10) among a plurality of cores (10) having on demand access to that common resource (12) or each common resource (12). 6. - computer according to any one of the preceding claims, wherein the sequence comprises at least one time window during which the access to first common resources (12) is attributable to at least one core (10) of a first group of cores according to a first set of access rules and the access of the second common resources (12) distinct from the first common resources (12) is attributable to at least one core of a second group of cores disjoined from the first group of cores according to a second set of access rules independent of those of the first set of access rules. 7. - computer according to any one of the preceding claims, wherein the sequence comprises a first phase having time windows having the same first duration and a second phase having time windows having the same second duration different from the first duration. 8. - computer according to any one of the preceding claims, configured so that each core executes an access controller (18) applying the access rules to determine, for each time window, if the heart is at a guaranteed access or on-demand access to a common resource or each common resource during this time window. 9. - Calculator according to claim 8, wherein the access controllers (18) of the different cores (10) are synchronized from a reference clock common to the cores. The computer of claim 9, wherein the access controller (18) of each heart (10) is executed by the heart (10) from a cache memory (16) of the heart physically integrated with the heart, without access common resources (12). The calculator of claim 10, wherein each time window during which plural cores (10) have on-demand access to at least one common resource (12) includes a notification period during which each heart indicates to the other cores. whether or not it wishes to reserve the time window, a decision period during which each core determines whether it is authorized to access the shared resources during the time window, according to the requests made by the other cores, and a period of time. use during which each authorized heart can access the shared resources. 12. - Method for controlling a multi-core processor having several physically distinct cores (10) having access to common hardware resources (12) shared by the cores (10) and accessible to the cores (10) in a sequence of windows time and according to predefined access rules stored in at least one memory of the computer (6) and according to which, in each time slot, each core (10) has, for each common resource (12), a guaranteed access, a on-demand access or forbidden access to the common resource (12), the sequence including at least one time window during which at least one core (10) has guaranteed access to at least one common resource (12), and at least one a time window during which a plurality of cores (10) have on-demand access to the same common resource (12), the method comprising, during the operation of the processor (8), allocating access to said same common resource (12) to one or more cores (10) among said plurality of cores (10) having on-demand access as a function of access requests from said plurality of cores (10).