EP1949234A1 - Procede et systeme de calcul intensif multitache et multiflot en temps reel - Google Patents

Procede et systeme de calcul intensif multitache et multiflot en temps reel

Info

Publication number
EP1949234A1
EP1949234A1 EP06764855A EP06764855A EP1949234A1 EP 1949234 A1 EP1949234 A1 EP 1949234A1 EP 06764855 A EP06764855 A EP 06764855A EP 06764855 A EP06764855 A EP 06764855A EP 1949234 A1 EP1949234 A1 EP 1949234A1
Authority
EP
European Patent Office
Prior art keywords
auxiliary
unit
apun
apuo
spp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06764855A
Other languages
German (de)
English (en)
Inventor
Raphaël DAVID
Vincent David
Nicolas Ventroux
Thierry Collette
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat a lEnergie Atomique CEA filed Critical Commissariat a lEnergie Atomique CEA
Publication of EP1949234A1 publication Critical patent/EP1949234A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes

Definitions

  • the present invention relates to a method and a multitasking and multiflot intensive computing system in real time.
  • the invention applies more particularly to embedded multiprocessor architectures.
  • the aim of the invention is to provide a processing solution for systems having the following properties:
  • High computing power the complexity of embedded applications is constantly growing. This is mainly due to the desire to integrate more and more functionalities into embedded systems (combination of multimedia, gaming, telecommunication and positioning functions in a mobile phone) and to increase the volumes of data to be processed. (video sensor capabilities, fast converters, ). Embedded systems must also be able to "digest" concurrently several streams of information. It is therefore essential to collect, distribute and effectively process all the information of the organs distributed in the system. This need to concurrently handle multiple streams of information combined with the opening of systems also results in multitasking execution environments.
  • targeted embedded systems have strong capabilities to handle heterogeneous data flows, strong opportunities for dynamic adaptation to the environment and good demand-responsive communication capabilities. They are also strongly constrained by the external environment (consumption, real-time, ...) and want to be open, that is to say that the same product can be intended for several uses.
  • tasks can be dynamically (ie at runtime) created, suspended, destroyed, etc.
  • the object of this invention is to provide a calculation structure in which the integration of dynamic control solutions is not at the expense of performance.
  • the exploitation of parallelism has historically been tied to the solutions allowing to benefit from the parallelism at the level of operations or instructions within the applications.
  • the complexity of applications embedded makes extremely difficult or inefficient modeling in the form of a single control flow.
  • users and architects agree to favor parallelism at the task level. Consequently, a strong trend currently observed is the integration on the same silicon substrate of several cores of processors, allowing the parallel execution of tasks on the same circuit.
  • SMFT Simultaneous MultiThreading
  • CMP Multiprocessing
  • CMP Multiprocessing
  • CMT Multiprocessing
  • simultaneous multiflot or SMT is for example implemented in the latest generations of processors Intel, IBM or HP Alpha. It consists in using several program counters, in order to supply the computing units with instructions from several instruction streams. The dependencies between tasks are limited, the parallel level of instructions or ILP (Instruction Level Parallelism) seen by the processor is increased and consequently the performance of the processor are too.
  • ILP Instruction Level Parallelism
  • Figure IA is a block diagram illustrating the principle of a SMT architecture of the simultaneous multiflot type.
  • Functional units or calculation units FU are supplied with processing by a single control resource CP associated with a task allocator TD.
  • the control block CP associated with the task allocator TD concurrently assigns instructions to the functional units FU as a function of the availability of the data and any operational hazards.
  • Functional units cooperate with shared SMS memory space.
  • Figure 1B illustrates an example of operation for a structure having four FU functional units. In this figure, each square 1 represents an instruction and the vertical black lines 2 represent the control and assignment tasks of the instructions.
  • the squares 3 marked with a cross correspond to time slots not used by the functional units because of dependencies of data or resources.
  • the multiprocess-based component or CMP solution is generally preferred in embedded systems because of its relative simplicity of implementation.
  • the principle of this solution is to concurrently distribute tasks to computing resources according to their availability. Each calculation resource then executes the tasks assigned to it one after the other.
  • These architectures are divided into two families, homogeneous structures and heterogeneous structures:
  • Heterogeneous structures these structures integrate heterogeneous computation units optimized for a given application domain, the distribution of tasks on these resources being identified beforehand at the time of compilation. Software partitioning done at compile time simplifies the distribution mechanisms (dynamic) of tasks at run time.
  • These application-oriented solutions include the OMAP, VIPER, PNX or Nomadik platforms.
  • Homogeneous structures are based on the integration of homogeneous calculation units. These units can be general-purpose, as in IBM's CeIIs or ARM's MPCore platforms, or optimized for a given application domain, such as the Craddle Technologies CT3400, optimized for MPEG4-AVC encoding / decoding.
  • the first solutions make it possible to target very large ranges of problems, whereas the second is optimized for a clearly identified application domain.
  • Figure 2A is a block diagram illustrating the principle of an architecture of the multiprocess type on component or CMP.
  • the functional units or calculation units FU which cooperate with an SMS shared memory space are supplied with processing by a single control resource CP associated with a task allocator TD.
  • the CP control unit associated with the TD task allocator is responsible for determining which tasks are ready for execution. As soon as a computing resource frees, it is assigned a task that will be processed as soon as the data is finished loading.
  • These zones 4 are hatched in FIG. 2B which illustrates an example of operation for a structure having four functional units FU, with squares 1 representing instructions and vertical black lines 2 representing control and assignment tasks of the instructions. .
  • Processor architectures of the multiprocess and multiflow type on component or CMT are a combination of the two previous models.
  • the CMP multiprocess concept is extended to allow multiple tasks to be performed on compute primitives.
  • This technology is considered mainly in the context of server-type solutions.
  • Figure 3A illustrates a generic architecture model of the CMT type.
  • a set of functional units or calculation units FU are fed into processing by a single control resource CP associated with a task allocator TD.
  • FU functional units cooperate with shared SMS memory space.
  • Figure 3B illustrates an example of operation of a functional unit FU.
  • the CP control unit associated with the TD task allocator is responsible for determining which tasks are ready for execution. As soon as a computing resource is released, it is assigned a task that will be processed as soon as the data is loaded. This is represented by the striped areas 4 in FIG. 3B, while the squares 1 represent instructions and the vertical black lines 2 represent control and assignment tasks of the instructions.
  • Each compute resource can concurrently handle multiple tasks. As soon as a job is blocked, for example because of a cache fault, the FU functional unit replaces it with a new one. In this case, task switching within the functional unit does not result in context loading penalties.
  • Some CMP-type solutions lead to the distinction between regular and irregular treatments. These architectures integrate therefore computing resources dedicated to the implementation of intensive treatments. Irregular processing is then processed with the system software on a general purpose processor. If the integration of computing resources dedicated to intensive processing allows the implementation of optimizations to improve the performance or the energy efficiency of these architectures, the inefficiency of the communications between the processing tasks and between processing tasks and system software or control processing lose the benefit of these optimizations at the system level.
  • the communications between the different elements of the architecture are made by means of bus systems, accompanied by strong penalties, both latency and bandwidth. As a result, these systems are penalized by the latency accompanying the transmission of control information and the throughput that disrupts the data transfers. These penalties result in a lower responsiveness of the architecture and an inability of the system software to optimize the use of computing resources.
  • the document US2Q04 / 0Q88519A1 proposes a solution to the management of a parallelism of task in the context of high performance processors but the proposed solution can not apply to embedded systems, especially for reasons of cost and determinism.
  • SMT type solutions are typically based on standard general purpose processors on which an additional control stage has been grafted.
  • these solutions do not solve the problems of consumption and determinism inherent in current general-purpose processors and, on the other hand, they add an additional complexity for managing several instruction streams concurrently.
  • CMP type architectures Despite the variety of implementation of CMP type architectures, it is also difficult to retain a solution that addresses embedded issues. On the one hand, application-oriented solutions do not have sufficient flexibility, and on the other hand the more general architectures do not offer calculation solutions and remain based on expensive solutions developed for general purpose processors. Similarly, CMT solutions, while extending the parallelism of the architectures, still do not meet the requirements of consumption and still face the problems of managing the consistency of data and communications in the circuit.
  • the present invention aims to remedy the aforementioned drawbacks and in particular to allow a very strong integration of computing resources in a processor.
  • a multitasking and multiflux intensive computing system in real time, characterized in that it comprises at least one central processor core, responsible for the support of the system software, and comprising a control unit responsible for the allocating an application's light processes (threads), the non-critical lightweight processes being executed by the core processor core, while the intensive or specialized thin processes are allocated to an auxiliary processing part, comprising a set of N Auxiliary computation optimized for the fast processing of some operations, a memory space shared by the auxiliary computing units via a network and a unit for control and allocation of auxiliary resources, responsible on the one hand for the allocation of elementary instruction streams, corresponding to intensive or specialized light processes, parallel auxiliary computing units, and responsible for on the other hand, the control of the execution and the synchronization of these instruction flows and the management of the execution contexts of the instruction flows, and in that the various constituent elements of the system are arranged in such a way that the communication of at least a portion of the data between the different auxiliary calculation units or between these auxiliary computing
  • the system may include a system bus connected to the core of the central processor.
  • system further comprises a mass memory for storing all the data and programs manipulated by the auxiliary calculation units.
  • a main memory controller can be associated with the mass memory.
  • the system may further include input-output controllers connected to at least one input-output device.
  • the input-output signals are made available for the other system elements via the SMS shared memory space and can thus be processed in a critical time by the system.
  • Auxiliary computing units may include units selected from programmable units, reconfigurable units, and dedicated units.
  • the shared memory space may include multiple storage resources and an interconnection network to aggregate all of these resources and this shared memory space stores all the data handled within the auxiliary computing units.
  • the shared memory space may further include a memory space controller responsible for establishing a link between the computing resources and the memory resources of the shared memory space.
  • the central processor core may further include a computing unit, a storage unit and a loading unit.
  • the control unit may have additional instructions for controlling the auxiliary processing part.
  • the loading unit can integrate a queue of additional registers allowing data exchanges between the central processor core and the auxiliary processing part.
  • the number N of auxiliary calculation units which at a time each processes a stream of elementary instructions forming part of a task is optimized according to the application and can be for example between 2 and 100.
  • L The auxiliary resource control and allocation unit may also be responsible for at least one management function selected from the dynamic power management, fault management and crisis management functions.
  • the system comprises a bus arbiter for managing the communication between the system bus on the one hand and the central processor core on the one hand and, as the case may be, the input-output and the memory on the other hand. massive.
  • the system comprises a set of processors connected to a system bus, each processor comprising a central processor core, a set of N auxiliary computing units, a shared memory space and a control and allocation unit. auxiliary resources.
  • the system may include a system bus arbitrator shared between multiple processors to link to the system bus.
  • the system may further include mass memory shared between multiple processors.
  • the subject of the invention is also a multitasking and multiflot intensive computing method in real time using at least one processor comprising at least one central processor core, a control unit, a set of N auxiliary calculation units. , a memory space shared by the auxiliary computing units via an internal network, a control unit and auxiliary resource allocation, characterized in that the central processor core is responsible for the support of the system software, and in that the control unit is responsible for allocating the light threads of an application, the non-critical lightweight processes being executed by the central processor core, while the intensive or specialized light processes are allocated to an auxiliary processing part, through the control unit and auxiliary resource allocation which is responsible for the allocation of the parallel flow of elementary instructions , corresponding to the intensive or specialized tasks, on the auxiliary computing units optimized for the fast processing of certain operations, and on the other hand the control of the execution and the synchronization of these instruction flows and the management of the contexts executing these instruction flows, and in that the communication of at least part of the data between the different auxiliary calculating units or between these auxiliary
  • the control unit can control the control of the auxiliary resource control and allocation unit by means of standard read / write instructions or standard exceptions.
  • the control unit can still control the control of the control unit and the allocation of auxiliary resources by means of specialized instructions dedicated to communication and synchronization operations.
  • an auxiliary calculating unit processes only a stream of elementary instructions forming part of a task and each stream of elementary instructions is executed only on a single auxiliary calculating unit.
  • all the data and programs manipulated by the auxiliary calculation units are stored in a mass memory.
  • input-output signals can be transmitted in critical time to the auxiliary calculation units, via the shared memory space.
  • the processor can be connected to a system bus.
  • the communication between the system bus on the one hand and the central processor core on the other, and the input / output controllers or the mass memory, if appropriate, can be managed by a controller.
  • bus referee.
  • a task allocated to the central processor core constituting the standard processing part is processed cycle by cycle on this same central processor core until it reaches a specialized instruction that is decoded and generates a command to the control and allocation unit so as to cause the creation of a flow of instructions that is executed on one computation units under the control and allocation unit management whereas, once the decoded specialized instruction and the corresponding command generated, the execution of the current task continues in the central processor core, without intervention in the management of the flow of instructions initiated and executed on an auxiliary calculation unit.
  • a strong synchronization in which all the components of the processor are synchronized can be selectively triggered depending on the type of trap.
  • a local synchronization is selectively triggered whereby the auxiliary computing unit concerned manages the trap alone and is synchronized independently of the rest of the processor. .
  • the invention incorporates a new coupling mechanism allowing a very strong integration of computing resources in the processor.
  • the architecture of the system according to the invention integrates a first subset or part of standard processing (SPP) which constitutes a central processor core and a second subset or part of auxiliary processing (APP) which incorporates in particular the units of Auxiliary calculation as well as the control unit and auxiliary resource allocation and the shared memory space.
  • SPP standard processing
  • APP auxiliary processing
  • FIGS. 1A and 1B respectively represent a generic model of SMT architecture and an example of operation
  • FIGS. 2A and 2B respectively represent a generic model of CMP architecture and an example of operation
  • FIGS. 3A and 3B respectively represent a generic model of CMT architecture and an example of operation
  • FIG. 4 symbolically represents the decomposition of a system into applications, then into tasks and finally into flows of instructions or threads;
  • FIG. 5 is a block diagram showing the main elements of the architecture of a processor according to FIG. the invention.
  • FIG. 6 is a block diagram showing a coupling mechanism between an auxiliary processing part and a standard processing part
  • FIG. 7 is a diagram showing a mechanism for accessing the data in an auxiliary processing part
  • FIG. 8 is a diagram showing a data transfer mechanism between an auxiliary processing part and a standard processing part
  • FIG. 9 is a diagram showing a data transfer mechanism between a standard processing part and a part auxiliary treatment
  • FIG. 10 is a block diagram of an example of a shared memory multiprocessor system embodying the invention. It will first be pointed out with reference to FIG. 4 the decomposition of a system 10 into applications 11, 12, then into tasks 21 to 25, and finally into streams of instructions or "threads" 31 to 33, again referred to as “processes”. light. "
  • An embedded system 10 is typically capable of handling several applications 11, 12 concurrently.
  • An application refers to a feature, a service offered by a system embedded. Any application 11, 12 processed on an embedded system can then be decomposed in the form of tasks 21 to 25 which are linked to each other following control dependencies expressed in the application. These tasks 21 to 25 can in turn be decomposed into operations executed sequentially or in parallel threads 31 to 33 for which concurrent executions are possible.
  • FIG. 5 shows an example of a processor architecture according to the invention, with a first subset constituted by a standard processing part SPP forming a central processor core, and a second subset constituted by a auxiliary processing part APP.
  • the standard processing part SPP takes care of the execution of the tasks. This includes on the one hand the processing of the instructions constituting the program to be processed but also the system software. Unlike a conventional processor, however, it is able to use APUO, APU1, ..., APUN-2, APUN-I auxiliary execution units included in the auxiliary processing part APP to process some application portions requiring very high computing power.
  • the invention implements a specific method in the way of using the auxiliary calculation units.
  • SPP standard processing part
  • SPP processes non-specialized calculations within the applications. It also processes system software that manages resource sharing and job control. It is built on the basis of a generalist processor. It is therefore classically based on four units:
  • ESCU control unit this unit is responsible for reading and decoding instructions.
  • the complexity of this unit is variable.
  • This unit can also incorporate a number of mechanisms to predict branch direction. Depending on the instruction, this unit sends commands to the other units of the architecture.
  • SPU calculation unit this unit is responsible for performing the standard calculations identified by the instructions. This unit can optionally integrate several calculation resources if the ESCU control unit can handle several instructions simultaneously.
  • Storage unit This unit is responsible for storing the data and instructions related to the program. This unit can be built on the basis of two levels of cache hierarchies according to a Harvard execution model and with a unified level 2 cache.
  • This storage unit then comprises cache memories L1 D-Cache and L1 I-Cache level 1 and a L2 Cache level 2 cache.
  • LSU loading unit The loading unit is responsible for linking the data stored in the memory and the units handled by the SPU calculation unit. This link is materialized by a queue of registers whose number of ports varies according to the number of instructions processed per cycle within the standard processing part
  • the ESCU control unit may include additional instructions for controlling the auxiliary processing part APP. These instructions allow for example to request the execution of a critical treatment. However, more standard mechanisms can also be implemented, not requiring the introduction of new instructions (for example coupling method with memory mapping called "m ⁇ mory mapped").
  • the LSU load unit can integrate an additional queue of registers. In addition to the conventional general register queue, a second register queue is thus integrated into the LSU load unit. This allows data exchange between the two subsets SPP and APP.
  • the processor distinguishes the general registers from the auxiliary registers by their address. It should be noted that this mode of communication between the two subsets SPP and APP is particularly suitable for small data transfers.
  • the auxiliary part APP supports the specialized and / or intensive calculations of the application. It integrates several APUO, APUl, ... APUN-2, APUN-I auxiliary computing units sharing a single SMS memory space. The number N of auxiliary calculation elements APUO, ... APUN-I is not subject to any particular limitation.
  • auxiliary processing part APP is therefore particularly suitable for setting up GALS (Globally Asynchronous and Locally Synchronous) type structures.
  • GALS Globally Asynchronous and Locally Synchronous
  • An APP auxiliary portion will typically contain from 4 to 8 APU calculation elements.
  • an auxiliary calculating unit APU processes only one thread and a thread is executed only on an auxiliary computing unit APU.
  • a set of lightweight processes or threads is assigned to the auxiliary calculation units APU by the allocation and control unit ACU included in the auxiliary part APP following execution requests from the control unit ESCU.
  • the physical allocation of the threads to the APU auxiliary computing units as well as the management of their execution and the synchronization between different threads are the responsibility of this allocation and control unit ACU.
  • the auxiliary processing part APP also integrates IO input-output controllers known as critical times. These are directly related to time-critical input-output devices. These can for example correspond to fast Analog-Digital converters, to Radio Frequency interfaces, video sensors ... These M input-output controllers IOO to IOM-1 are considered by the control and allocation unit ACU as auxiliary calculating units APU. The control and allocation unit ACU must then assign a task to the input / output controller to load it to manage access to the input / output. The data sent or received is from or to the shared SMS memory space.
  • the less critical inputs, such as those corresponding to a keyboard or a mouse are however connected by more standard means, such as the system bus SB, to the standard processing part SPP.
  • the auxiliary processing part APP can still contain a mass memory MM in order to store all the data and programs handled by the auxiliary calculating units APU.
  • This memory MM also has its own MMC controller on which the control unit and allocation ACU allocates data transfer threads between the system (shown in Figure 5 by the system bus SB) and the calculation threads intensive.
  • This MMC controller is also involved in data transfers between the SMS shared memory space and the mass memory MM.
  • APU auxiliary computing units are optimized for fast processing of certain operations. They can offer different tradeoffs between performance, flexibility, cost or consumption depending on their type. The selection of this or that type of computing unit is then strongly influenced by the application context.
  • Auxiliary computing units may include programmable units, reconfigurable units, or dedicated units.
  • Programmable units this type of unit corresponds to cores of general processors (MIPS, ARM, etc.) or optimized (DSP, ST2xx, etc.) cores for embedded computing. As these units are optimized for computation, they see their control structures simplified, for example by eliminating the mechanisms of branch prediction, interrupt management or data virtualization. These units can also integrate specialized computing units such as floating units and / or vector units.
  • Reconfigurable units can also be used as a calculation accelerator. Large grain structures are favored because of their ability to be reconfigured quickly, and the good performance / flexibility tradeoff they can offer. Thin grain structures can also be integrated if great flexibility of use is required or if operations working on very small data (1 to 4 bits) are likely to be processed. Because of their very low reactivity, that is to say very long reconfiguration times, these fine grain resources are likely to be managed differently, for example in order to avoid their pre-emption.
  • Dedicated Units Units that are optimized for certain critical processes can ultimately be integrated into the component. These dedicated accelerators support critical processes, for which programmable or reconfigurable solutions do not offer sufficient computing power. For example, cryptographic processing or management of very high-speed input / output flows are good candidates for such implementations.
  • APU auxiliary calculation units may also contain private storage resources. These can be used either to store intermediate data to facilitate their access and to minimize bandwidth on the shared memory space, or to store the instructions of the running program. Programs that might be run could also be stored locally to speed up the task allocation phases.
  • Two elements may require access to the system bus in the auxiliary processing part APP, the main memory and the input-output controllers 10. From the point of view of the standard processing part SPP, this access to the system bus SB is used to loading the L2-Cache cache with data or instructions from the mass memory MM or peripheral elements. In case of requests for simultaneous access of several elements of the processor, the bus arbitrator
  • the standard processing part SPP continues the execution of the program, without intervening in the management of the thread initiated on the auxiliary processing part APP.
  • the execution of the program therefore continues until its end or the processing of new specialized instructions, which can cause among other things the creation or the destruction of threads, the reading of data generated in the auxiliary processing part APP,.
  • the ACU allocation and control unit is responsible for executing specialized instructions from the ESCU control unit.
  • the detail of this coupling allowing the ESCU control unit to communicate with the allocation and control unit ACU is modeled in Figure 6.
  • FIG. 6 shows the ESCU control unit, the LSU loading unit and the SPU calculation unit of the standard processing part SPP, as well as a part of the storage unit Ll I-Cache. .
  • Figure 6 also shows the control and allocation unit ACU forming part of the auxiliary processing part APP.
  • the standard instructions of the standard processing part SPP are read and then decoded, respectively in the reading and decoding stages of the control unit ESCU, in order to control the loading unit LSU and the calculation unit SPU. Conversely, in the case of specialized instructions, the ESCU control unit redirects the command stream to the allocation and control unit ACU.
  • These specialized instructions can be of different natures and concern for example:
  • the system software realizes a virtual allocation of the threads to the auxiliary calculation units APU. It is then up to the control and allocation unit ACU to physically perform this allocation and to take into account all the parameters making it possible to determine the best possible allocation.
  • the ACU control and allocation unit also manages synchronization between threads as well as access to shared critical resources. This control and allocation unit ACU can also be responsible for providing support for the system software, for example by managing only the pre-emptions or by updating the task lists.
  • control and allocation unit ACU must have the execution context of each of the threads running on the auxiliary processing part APP. Indeed, during a weak synchronization, the unit of control and allocation ACU is only responsible for the evolution of the threads. As a result, when the task is reallocated to the standard SPP processing part, it is necessary to inform it about the progress of the calculation threads. This makes it possible for the standard processing part SPP not to reactivate unfinished threads, but running on the auxiliary processing part APP.
  • the availability of a local context in the control and allocation unit ACU makes it possible to guarantee a coherent state when a task is allocated on the processor. This is especially true if the tasks are executed in the disorder on the standard SPP processing part.
  • the ACU control and allocation unit will also be able to support functions more specific to the application domains. dynamic power management, fault management or the management of "crisis modes".
  • SMS shared memory space is made up of multiple storage resources and an interconnection network that brings all of these resources together in a single space.
  • a memory controller MSC is responsible for establishing a link between the computing resources and the storage resources.
  • the control and allocation unit ACU is also used to provide certain information making it possible to link the virtual addresses in the shared memory space, manipulated by the auxiliary control units APU, (corresponding to the name of a variable as well as a position in this variable, eg image name and pixel index) and the physical address to be propagated to the storage resource used.
  • the data access mechanism is illustrated in FIG.
  • auxiliary processing part APP for a data transfer operating between a producer APU auxiliary computing unit denoted APUp and a consumer APU auxiliary computing unit denoted APUc.
  • This data access mechanism in the auxiliary processing part APP is broken down into two steps, identified by circles 1 and 2 in this Figure 7.
  • the first phase of a data access is only performed when an auxiliary computing unit APU accesses a variable for the first time. In this case, there is no link between the data and the memory that contains it.
  • the auxiliary computing unit APU queries the control and allocation unit ACU. This integrates a memory management unit MSMU performing this function by associating the name of a variable memory that stores it. When the data is identified in this unit, the MSMU management unit returns to the unit the identifier of the memory storing the variable. Conversely, when an auxiliary calculating unit APU attempts to write data which is not referenced (at the time of the first writing of this variable for example), the MSMU management unit is responsible for allocating a memory among the storage elements available in the shared memory space SMS.
  • the unit associating on the name of a variable the memory that stores it is updated. and the memory identifier is returned to the APU auxiliary computing unit.
  • the MSMU management unit is responsible for repatriating it (in connection with the data controller).
  • main memory MMC main memory MMC and allocate a memory among the storage elements available in the shared memory space SMS.
  • a data item is definitively written (final result)
  • the corresponding entry in the unit associating on the name of a variable the memory that stores it is released and a request is transmitted to the main memory controller MMC to repatriate this data item.
  • the second phase of data access is systematically performed since it makes it possible to make the link between the auxiliary computing unit APU and the memory containing the data.
  • the auxiliary computing unit APU knows the memory to which it wishes to access, it transfers this information to the controller of the shared memory space SMS, in the same cycle time as the address of the searched data and the control signals. of memory.
  • the memory controller MSC is then responsible for routing these signals (and then the data back) to the appropriate memory.
  • this service may be different.
  • this memory space controller MSC will be used to "packetize" the data, that is to say to add to the data the routing information. in the network.
  • the memory controller MSC will be responsible for the hardware configuration of the path to be taken.
  • auxiliary calculation units APU the management of the data addresses at the level of the auxiliary calculation units APU is ensured by specific input-output blocks, possibly capable of handling more complex data flows and burst communications for example .
  • these data management elements take care of recovering the data manipulated by the APU auxiliary calculation units. If data access is impossible or slowed down, these control modules can freeze the execution of the thread on the auxiliary calculation unit APU, in order to prevent the latter from attempting to manipulate an unstable data item.
  • T access Tmem x SuA - ⁇ ⁇ ⁇ - (1)
  • Nbac ⁇ ss is the number of accesses
  • Nbport is the number of ports in the SMS shared memory space or a node in the network
  • Tmem represents the minimum memory access time.
  • the memory structure used is interesting because the data are linked to a memory structure and not to a computing element. Preemption can therefore be achieved very quickly because a change of context does not necessarily imply data transfer between computing resources.
  • reading the LOAD instruction Rx, Ty, Rz from the example illustrated in FIG. 8 makes it possible to load in the register Rx of the standard processing part SPP the variable Rz of the thread Ty executed on the auxiliary processing part.
  • APP When the ESCU control unit decodes this instruction, it must generate three commands:
  • This command is sent to the control and allocation unit ACU to identify the auxiliary computing unit APU which executes the thread Ty. This identification is carried out by means of a page table or Translation Look-aside Buffer (TLB) associating each active thread on the control and allocation unit.
  • TLB Translation Look-aside Buffer
  • the APU auxiliary computing unit that executes it. If this TLB does not return an APU calculation unit identifier, the thread is not running and the task running on the standard processing part SPP is pending. If the thread is running, the TLB returns the identifier of the APU compute unit that executes it. This identifier is used at the level of the standard processing part SPP to select the data to be sent to the auxiliary register queue of this auxiliary processing part SPP. This identifier can also be used at the level of the auxiliary calculation units APU to validate. or not reading the data in the SRF shared register queue.
  • FIG. 9 is similar to Figure 8, but with the substitution of STORE statements Rx, Ty, Rz, Write (Rz) and Read (Rx) respectively to LOAD statements Rx, Ty, Rz, Read (Rz) and Write (Rx).
  • the main memory controller MMC, the allocation and control unit ACU and the memory space controller MSC can intervene in the control of these communications, depending on the type of communication implemented.
  • the main memory MM intervenes in four types of communications:
  • System bus SB to main memory MM This first type of transfer makes it possible to repatriate data from outside the system to the main memory MM of the auxiliary processing part APP. These transfers occur following the decoding of a special instruction in the ESCU control unit. This special instruction causes the creation of a data transfer operation that will be assigned by the control and allocation unit ACU to the main memory controller MMC. The behavior of this one will then be comparable to that of a DMA controller (of direct access to the memory). At the same time, the main memory controller MMC informs a table that will allow it to link the loaded data and its position in the main memory MM.
  • Main memory MM to SB system bus In a symmetrical manner, the data is transferred from the main memory MM to the rest of the system following the arrival of a transfer operation identified by special instructions at the ESCU control unit. Sendings from the main memory MM may also result in the destruction of an entry in the correspondence table if this data was a final result. This assumes that special instructions decoded by the ESCU control unit allow the distinction between destructive and non-destructive
  • Main memory MM to shared memory space SMS If an auxiliary calculation unit APU attempts to access data not present in the shared memory space SMS, a transfer request is transmitted by the control unit and ACU allocation to the MMC to route this data to the shared SMS memory space. The auxiliary computing unit APU is then blocked the transfer time.
  • Shared memory space SMS to main memory MM These transfers follow special data transfers of APU auxiliary calculation units which specify the writing of a final result, that is to say which is not intended to be replayed in the auxiliary processing part APP, in the shared memory space SMS. These transfers can also intervene in case of strong synchronization as part of a context backup. In this case, the SMS shared memory space sends a transfer request through the control and allocation unit ACU to the main memory controller MMC.
  • the performance of the architecture is subject to some degradation when the number of auxiliary calculating units APU is too large, for example of the order of several hundred.
  • FIG. 10 shows by way of example that the combination of two processors according to the invention, but could naturally include a larger number of associated processors which all cores have of the same organization, centered on the coupling of a standard processing part SPP and an auxiliary calculation part APP, as described previously, in particular with reference to FIG. 5.
  • the invention essentially relates to a device and a method for controlling and allocating threads on an embedded architecture, advantageously integrating multiple processing resources, dedicated to multi-tasking and multi-tasking intensive computing in real-time.
  • the real-time parallel computer architecture comprises:
  • a central processor core SPP responsible for executing the non-critical processing of the tasks and the support of the system software
  • an ACU unit for controlling and allocating auxiliary resources, which manages the execution of the intensive processing of the APUi auxiliary calculating units in parallel.
  • the communication between the different auxiliary calculation units APU, between the calculation units APU auxiliary and SPP core processor core is through the shared SMS memory space and an internal network.
  • the method of allocating and processing tasks makes it possible to separate the control tasks executed by the central processor core SPP from the intensive calculation tasks performed by the specialized APU calculation units.
  • the control and allocation unit ACU manages the allocation of the intensive computing tasks for the different APU auxiliary computing units working in parallel.
  • This auxiliary controller ACU allows the implementation of so-called weak synchronization mechanisms by which auxiliary calculation units APU can process threads of a task different from that performed on the core of the central processor SPP.
  • the state of the system is no longer represented by a single context, unlike a Von Neuman architecture.
  • the time-critical input inputs are directly connected to the shared memory space by the auxiliary computing units APU.
  • This architecture and allocation method allow optimized real-time multitask processing, that is to say with a decrease in data loading times, and adaptable to different applications.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Advance Control (AREA)
  • Multi Processors (AREA)

Abstract

Le système de calcul intensif multitâche et multiflot en temps réel comprend au moins un cœur de processeur central (SPP), chargé du support du logiciel système et comprenant une unité de contrôle (ESCU) chargée de l'allocation des processus légers d'une application, les processus légers non critiques étant exécutés par le cœur du processeur central (SPP), tandis que les processus légers intensifs ou spécialisés sont alloués à une partie de traitement auxiliaire (APP), comprenant un ensemble de N unités de calcul auxiliaires (APUO, ..., APUN-1) optimisées pour le traitement rapide de certaines opérations, un espace mémoire (SMS) partagé par les unités de calcul auxiliaires (APUO, ..., APUN-1) via un réseau interne et une unité (ACU) de contrôle et d'allocation des ressources auxiliaires. Les différents éléments constitutifs du système sont agencés de telle manière que la communication entre les différentes unités de calcul auxiliaires (APUO,..., APUN-I) ou entre ces unités de calcul auxiliaires (APUO,..., APUN-1) et le cœur de processeur central (SPP), s'effectue par l'intermédiaire de l'espace mémoire partagé (SMS) et du réseau interne.

Description

Procédé et système de calcul intensif multitâche et multiflot en temps réel
La présente invention a pour objet un procédé et un système de calcul intensif multitâche et multiflot en temps réel. L'invention s'applique plus particulièrement aux architectures embarquées multiprocesseurs.
L'invention vise à proposer une solution de traitement pour des systèmes disposant des propriétés suivantes :
• Forte puissance de calcul : la complexité des applications embarquées n'a de cesse de croître. Ceci s'explique notamment par la volonté d'intégrer toujours plus de fonctionnalités au sein des systèmes embarqués (association de fonctions multimédia, de jeu, de télécommunication et de positionnement dans un téléphone mobile) et à l'accroissement des volumes de données à traiter (capacités des capteurs vidéos, convertisseurs rapides, ...). Les systèmes embarqués se doivent en outre de pouvoir « digérer » concurremment plusieurs flots d'informations. Il est ainsi indispensable de collecter, distribuer et traiter efficacement toutes les informations des organes distribués dans le système. Cette nécessité de traiter concurremment plusieurs flots d'informations combinée à l'ouverture des systèmes se traduit également par des environnements d'exécution multitâches.
• Flexibilité : Les systèmes visés se veulent ouverts. Ainsi, tout utilisateur du système est libre de l'utiliser à sa guise. L'architecture doit donc être suffisamment flexible pour supporter des scénarii d'utilisation très différents. Cette ouverture interdit des optimisations globales hors-ligne de l'architecture puisque le contexte applicatif ne peut être entièrement déterminé au moment de la phase de conception. D'autre part, si certaines classes d'algorithmes favorisent un découpage statique des traitements avec un contrôle simple du parallélisme (défini hors ligne), d'autres nécessitent un flot de contrôle dynamique, et cette tendance devrait aller en croissant avec Ia montée en complexité des applications embarquées. B Intégration poussée dans l'environnement : Les systèmes développés se doivent par ailleurs d'être profondément intégrés dans leur environnement. Cette intégration se traduit par des contraintes sévères de temps-réel, de consommation, de coût et de sûreté de fonctionnement
• Hétérogénéité des traitements : Du fait de la diversité des applications ainsi que de la complication des flots de contrôle dans les systèmes embarqués, une très grande variété de types de traitements se doivent de cohabiter au sein des architectures embarquées. Ainsi, des tâches de calculs intensifs côtoient des tâches dominées par le contrôle, avec des interactions très fortes entre ces différents éléments des applications.
En résumé, les systèmes embarqués ciblés disposent de fortes capacités à traiter les flux de données hétérogènes, de fortes possibilités d'adaptation dynamique à l'environnement et de bonnes capacités de communication adaptées à la demande. Ils sont par ailleurs fortement contraints par l'environnement extérieur (consommation, temps-réel, ...) et se veulent ouverts, c'est-à-dire qu'un même produit peut être destiné à plusieurs usages. Ceci inclut notamment les systèmes multiapplication au sein desquels des tâches peuvent être dynamiquement (c'est-à-dire lors de l'exécution) créées, suspendues, détruites, .... Dans de tels systèmes, il est problématique d'envisager une optimisation hors-ligne de l'architecture puisque l'impossibilité de déterminer précisément les scénarii d'utilisation induit une sous-utilisation des ressources. A l'inverse, il est préférable de privilégier une optimisation en-ligne de la structure de calcul éliminant la nécessité de prévoir l'ensemble des scénarii d'utilisation. L'impossibilité d'optimiser hors-ligne l'architecture impose cependant la mise en place de mécanismes de contrôle très coûteux en performance. L'objet de cette invention consiste à proposer une structure de calcul dans laquelle l'intégration des solutions de contrôle dynamique ne se fait pas au détriment des performances. Dans le cadre de la course à la performance, l'exploitation du parallélisme s'est historiquement attachée aux solutions permettant de bénéficier du parallélisme au niveau opérations ou instructions au sein des applications. Malgré l'activité intense de la recherche autour de Ia définition d'architectures capables de gérer efficacement un fort degré de parallélisme au niveau instructions, on ne peut que constater les limites de ces approches. Dans le même temps, la complexité des applications embarquées rend extrêmement difficile ou peu efficace leur modélisation sous la forme d'un flot de contrôle unique. Ainsi, utilisateurs et concepteurs d'architecture s'accordent pour privilégier un parallélisme au niveau tâche. En conséquence, une tendance forte observée actuellement est l'intégration sur un même substrat silicium de plusieurs cœurs de processeurs, permettant l'exécution parallèle de tâches sur un même circuit.
Dans cette course à la performance, plusieurs solutions sont envisagées, classées selon la méthode employée pour exploiter le parallélisme. Les principaux modèles sont le multiflot simultané ou SMT (Simultaneous MultiThreading), le multiprocessus sur composant ou CMP (Chip MultiProcessing), et le multiprocessus et multiflot sur composant ou CMT (Chip MultiThreading).
La technique du multiflot simultané ou SMT est par exemple mise en œuvre dans les dernières générations de processeurs Intel, IBM ou HP Alpha. Elle consiste à utiliser plusieurs compteurs de programmes, afin d'approvisionner les unités de calcul en instructions issues de plusieurs flots d'instructions. Les dépendances entre tâches étant limitées, le parallélisme au niveau des instructions ou ILP (Instruction Level Parallelism) vu par le processeur est accru et par voie de conséquence les performances du processeur le sont aussi. La mise en œuvre de ces solutions est toutefois un exercice délicat et la complexité des étages de lecture et de distribution des instructions de ces solutions est très élevée. En conséquence, ces architectures conduisent à de très gros circuits, incompatibles avec les contraintes des systèmes embarqués, en terme de coût et de consommation notamment.
La Figure IA est un schéma bloc illustrant le principe d'une architecture SMT du type multiflot simultané. Des unités fonctionnelles ou unités de calcul FU sont alimentées en traitement par une ressource de contrôle unique CP associée à un allocateur de tâches TD. A chaque cycle, Ie bloc de contrôle CP associé à l'allocateur de tâches TD assigne concurremment des instructions aux unités fonctionnelles FU en fonction de la disponibilité des données et des éventuels aléas de fonctionnement. Les unités fonctionnelles coopèrent avec un espace mémoire partagé SMS. La Figure IB illustre un exemple de fonctionnement pour une structure disposant de quatre unités fonctionnelles FU. Sur cette figure, chaque carré 1 représente une instruction et les traits noirs verticaux 2 représentent les tâches de contrôle et d'assignation des instructions.
Les carrés 3 marqués d'une croix correspondent à des tranches de temps non utilisées par les unités fonctionnelles pour cause de dépendances de données ou de ressources.
La solution de type multiprocessus sur composant ou CMP est généralement privilégiée dans les systèmes embarqués en raison de sa relative simplicité de mise en œuvre.
Le principe de cette solution est de distribuer concurremment des tâches aux ressources de calcul suivant leur disponibilité. Chaque ressource de calcul exécute alors les tâches qui lui sont assignées les unes à la suite des autres. Ces architectures se répartissent en deux familles, les structures homogènes et les structures hétérogènes :
• Structures hétérogènes: ces structures intègrent des unités de calcul hétérogènes et optimisées pour un domaine applicatif donné, la distribution des tâches sur ces ressources étant préalablement identifiée au moment de la compilation. Le partitionnement logiciel réalisé à la compilation permet de simplifier les mécanismes de distribution (dynamique) des tâches au moment de l'exécution. Parmi ces solutions orientées application, se trouvent notamment les plateformes OMAP, VIPER, PNX ou Nomadik.
• Structures homogènes: ces structures sont basées sur l'intégration d'unités de calcul homogènes. Ces unités peuvent être généralistes, comme dans les plateformes CeIIs de IBM ou MPCore de ARM, ou optimisées pour un domaine applicatif donné, à l'image du CT3400 de Craddle Technologies, optimisé pour le codage/décodage MPEG4-AVC. Les premières solutions permettent de cibler de très larges gammes de problématiques, alors que la seconde est optimisée pour un domaine applicatif bien identifié. La Figure 2A est un schéma-bloc illustrant le principe d'une architecture du type multiprocessus sur composant ou CMP. Les unités fonctionnelles ou unités de calcul FU qui coopèrent avec un espace mémoire partagé SMS sont alimentées en traitements par une ressource de contrôle unique CP associée à un allocateur de tâche TD. L'unité de contrôle CP associée à l'allocateur de tâche TD se charge de déterminer les tâches prêtes à être exécutées. Dès qu'une ressource de calcul se libère, elle se voit assigner une tâche qui sera traitée dès la fin du chargement des données. Ces zones 4 figurent en hachures sur la Figure 2B qui illustre un exemple de fonctionnement pour une structure disposant de quatre unités fonctionnelles FU, avec des carrés 1 représentant des instructions et des traits noirs verticaux 2 représentant des tâches de contrôle et d'assignation des instructions.
Les architectures de processeurs du type multiprocessus et multiflot sur composant ou CMT sont une combinaison des deux précédents modèles. Le concept des multiprocessus sur composant CMP est étendu afin d'autoriser l'exécution de plusieurs tâches sur les primitives de calcul.
Cette technologie est envisagée essentiellement dans le cadre de solutions de type serveur.
La Figure 3A illustre un modèle générique d'architecture du type CMT. Un ensemble d'unités fonctionnelles ou unités de calcul FU sont alimentées en traitement par une ressource de contrôle unique CP associée à un allocateur de tâche TD. Les unités fonctionnelles FU coopèrent avec un espace mémoire partagé SMS.
La Figure 3B illustre un exemple de fonctionnement d'une unité fonctionnelle FU.
L'unité de contrôle CP associée à l'allocateur de tâche TD se charge de déterminer les tâches prêtes à être exécutées. Dès lors qu'une ressource de calcul se libère, elle se voit assigner une tâche qui sera traitée dès le chargement des données réalisé. Ceci est représenté par les zones rayées 4 sur la Figure 3B, tandis que les carrés 1 représentent des instructions et les traits noirs verticaux 2 représentent des tâches de contrôle et d'assignation des instructions.
Chaque ressource de calcul peut gérer concurremment plusieurs tâches. Dès qu'une tâche est bloquée, par exemple à cause d'un défaut de cache, l'unité fonctionnelle FU la remplace par une nouvelle. Dans ce cas, la commutation de tâche au sein de l'unité fonctionnelle ne se traduit pas par des pénalités de chargement de contexte.
Malgré l'émulation autour de ces architectures misant sur le parallélisme de flots d'instructions (threads) pour accroître les performances, ces architectures, qu'elles soient de type SMT, CMP ou
CMT, ne répondent que partiellement à la problématique des systèmes embarqués. La principale cause à cet état de fait est l'absence de distinction entre les différentes classes de traitement cohabitant au sein d'une application. Ainsi, les traitements fortement dominés par le contrôle sont traités de manière équivalente, sur une même ressource de traitement, qu'un traitement régulier et critique du point de vue de son temps d'exécution. Les ressources de calcul devant alors supporter les traitements réguliers tout autant que les traitements très irréguliers, il en découle des systèmes construits sur des primitives de calcul non optimisées, et de ce fait en inadéquation avec les besoins applicatifs suivant trois aspects de la consommation électrique, du rapport coût/performance et de la sûreté de fonctionnement.
Quelques solutions de type CMP conduisent toutefois à faire la distinction entre les traitements réguliers et irréguliers. Ces architectures intègrent dès lors des ressources de calcul dédiées à la mise en œuvre des traitements intensifs. Les traitement irréguliers sont alors traités avec le logiciel système sur un processeur généraliste. Si l'intégration de ressources de calcul dédiées aux traitements intensifs autorise la mise en œuvre d'optimisations permettant d'améliorer les performances ou encore l'efficacité énergétique de ces architectures, l'inefficacité des communications entre les tâches de traitement ainsi qu'entre les tâches de traitement et le logiciel système ou les traitement de contrôle fait perdre le bénéfice de ces optimisations au niveau système. Les communications entre les différents éléments de l'architecture se font en effet par l'intermédiaire de bus systèmes, s'accompagnant de fortes pénalités, tant au niveau des latences que des bandes passantes. De ce fait ces systèmes sont pénalisés par la latence accompagnant la transmission d'informations de contrôle et par le débit perturbant les transferts de données. Ces pénalités se traduisent par une réactivité plus faible de l'architecture et par une incapacité du logiciel système à optimiser l'utilisation des ressources de calcul.
Pour minimiser ce surcoût selon le document US2005/0149937A1, les mécanismes de synchronisation entre les ressources de calcul sont pris en charge par le biais d'une structure dédiée, mais il n'est plus apporté de solutions au problème de transfert de donnée entre ces tâches, Le document US2Q04/0Q88519A1, propose quant à lui une solution à la gestion d'un parallélisme de tâche dans le contexte des processeurs hautes performances mais la solution proposée ne peut pas s'appliquer aux systèmes embarqués, notamment pour des raisons de coût et de déterminisme.
Les solutions développées actuellement pour exploiter un parallélisme au niveau tâche ne permettent donc pas de répondre à l'ensemble des contraintes mentionnées ci-dessus. Les solutions de type SMT sont par exemple typiquement basées sur des processeurs généralistes standard sur lesquels un étage de contrôle supplémentaire a été greffé. D'une part ces solutions ne résolvent pas les problèmes de consommation et de déterminisme inhérents aux processeurs généralistes actuels et d'autre part, elles ajoutent une complexité supplémentaire pour gérer concurremment plusieurs flots d'instructions.
Malgré la variété de mise en oeuvre des architectures de type CMP, il est également difficile de retenir une solution répondant aux problématiques embarquées. D'une part, les solutions orientées application ne disposent pas d'une flexibilité suffisante, et d'autre part les architectures plus généralistes ne proposent pas de solutions de calcul et restent basées sur des solutions coûteuses, développées pour les processeurs généralistes. De manière similaire, les solutions CMT, bien qu'étendant le parallélisme des architectures, ne permettent toujours pas de répondre aux exigences de consommation et demeurent confrontées aux problèmes de gestion de la cohérence des données et des communications dans le circuit.
La présente invention vise à remédier aux inconvénients précités et notamment à permettre une très forte intégration des ressources de calcul dans un processeur.
Ces buts sont atteints grâce à un système de calcul intensif multitâche et multiflot en temps réel, caractérisé en ce qu'il comprend au moins un cœur de processeur central, chargé du support du logiciel système, et comprenant une unité de contrôle chargée de l'allocation des processus légers (threads) d'une application, les processus légers non critiques étant exécutés par le cœur de processeur central, tandis que les processus légers intensifs ou spécialisés sont alloués à une partie de traitement auxiliaire, comprenant un ensemble de N unités de calcul auxiliaires optimisées pour Ie traitement rapide de certaines opérations, un espace mémoire partagé par les unités de calcul auxiliaires via un réseau interne et une unité de contrôle et d'allocation des ressources auxiliaires, chargée d'une part de l'allocation des flots d'instructions élémentaires, correspondant aux processus légers intensifs ou spécialisés, aux unités de calcul auxiliaires en parallèle, et chargée d'autre part du contrôle de l'exécution et de la synchronisation de ces flots d'instructions et de la gestion des contextes d'exécution des flots d'instructions, et en ce que les différents éléments constitutifs du système sont agencés de telle manière que la communication d'au moins une partie des données entre les différentes unités de calcul auxiliaires ou entre ces unités de calcul auxiliaires et le cœur de processeur central, s'effectue par l'intermédiaire de l'espace mémoire partagé et du réseau interne.
Le système peut comprendre un bus système relié au cœur du processeur central.
Avantageusement, le système comprend en outre une mémoire de masse pour le stockage de l'ensemble des données et des programmes manipulés par les unités de calcul auxiliaires.
Un contrôleur de mémoire principale peut être associé à la mémoire de masse.
Le système peut comprendre en outre des contrôleurs d'entrées sorties, reliés à au moins un périphérique d'entrées sorties. Les signaux d'entrées sorties sont rendus disponibles pour les autres éléments du système par l'intermédiaire de l'espace mémoire partagé SMS et peuvent ainsi être traités en temps critique par le système.
Les unités de calcul auxiliaires peuvent comprendre des unités choisies parmi des unités programmables, des unités reconfigurables et des unités dédiées.
L'espace mémoire partagé peut comprendre de multiples ressources de mémorisation et un réseau d'interconnexion permettant de réunir toutes ces ressources et cet espace mémoire partagé stocke toutes les données manipulées au sein des unités de calcul auxiliaires.
L'espace mémoire partagé peut en outre comprendre un contrôleur d'espace mémoire chargé d'établir un lien entre les ressources de calcul et les ressources de mémorisation de l'espace mémoire partagé.
Le cœur de processeur central peut en outre comprendre une unité de calcul, une unité de mémorisation et une unité de chargement. L'unité de contrôle peut comporter des instructions supplémentaires pour le contrôle de la partie de traitement auxiliaire.
L'unité de chargement peut intégrer une file de registres supplémentaires permettant des échanges de données entre le cœur de processeur central et la partie de traitement auxiliaire.
Le nombre N d'unités de calcul auxiliaires qui à un instant ne traitent chacune qu'un flot d'instructions élémentaires faisant partie d'une tâche est optimisé en fonction de l'application et peut être compris par exemple entre 2 et 100. L'unité de contrôle et d'allocation des ressources auxiliaires peut en outre être chargée d'au moins une fonction de gestion choisie parmi les fonctions de gestion dynamique de la puissance, de gestion des pannes et de gestion des modes de crise.
Selon un mode particulier de réalisation, le système comprend un arbitre de bus pour gérer la communication entre d'une part le bus système et d'autre part le cœur de processeur central ainsi que, le cas échéant, les entrées-sorties et la mémoire de masse.
Selon une application particulière, le système comprend un ensemble de processeurs reliés à un bus système, chaque processeur comprenant un cœur de processeur central, un ensemble de N unités de calcul auxiliaires, un espace mémoire partagé et une unité de contrôle et d'allocation des ressources auxiliaires.
Le système peut comprendre un arbitre de bus système partagé entre plusieurs processeurs pour effectuer la liaison avec le bus système. Le système peut encore comprendre une mémoire de masse partagée entre plusieurs processeurs.
L'invention a encore pour objet un procédé de calcul intensif multitâche et multiflot en temps réel à l'aide d'au moins un processeur comprenant au moins un cœur de processeur central, une unité de contrôle, un ensemble de N unités de calcul auxiliaires, un espace mémoire partagé par les unités de calcul auxiliaires via un réseau interne, une unité de contrôle et d'allocation des ressources auxiliaires, caractérisé en ce que le cœur de processeur central est chargé du support du logiciel système, et en ce que l'unité de contrôle est chargée de l'allocation des processus légers (threads) d'une application, les processus légers non critiques étant exécutés par le cœur de processeur central, tandis que les processus légers intensifs ou spécialisés sont alloués à une partie de traitement auxiliaire, par l'intermédiaire de l'unité de contrôle et d'allocation des ressources auxiliaires qui est chargée d'une part de l'allocation en parallèle des flots d'instructions élémentaires, correspondant aux tâches intensives ou spécialisées, sur les unités de calcul auxiliaires optimisées pour le traitement rapide de certaines opérations, et d'autre part du contrôle de l'exécution et de la synchronisation de ces flots d'instructions et de la gestion des contextes d'exécution de ces flots d'instructions, et en ce que la communication d'au moins une partie des données entre les différentes unités de calcul auxiliaires ou entre ces unités de calcul auxiliaires et le cœur de processeur central s'effectue par l'intermédiaire de l'espace mémoire partagé et du réseau interne.
L'unité de contrôle peut contrôler le pilotage de l'unité de contrôle et d'allocation des ressources auxiliaires au moyen d'instructions standard de lecture/écriture ou d'exceptions standard.
L'unité de contrôle peut encore contrôler le pilotage de l'unité de contrôle et d'allocation des ressources auxiliaires au moyen d'instructions spécialisées dédiées aux opérations de communication et de synchronisation. A un instant donné une unité de calcul auxiliaire ne traite qu'un flot d'instructions élémentaires faisant partie d'une tâche et chaque flot d'instructions élémentaires n'est exécuté que sur une seule unité de calcul auxiliaire.
Avantageusement, l'ensemble des données et des programmes manipulés par les unités de calcul auxiliaires sont stockés dans une mémoire de masse.
Selon une caractéristique particulière, des signaux d'entrées sorties peuvent être transmis en temps critique aux unités de calcul auxiliaires, par l'intermédiaire de l'espace mémoire partagé. Le processeur peut être relié à un bus système.
Dans ce cas, selon une caractéristique particulière, la communication entre d'une part le bus système et d'autre part le cœur du processeur central, et Ie cas échéant les contrôleurs d'entrées sorties ou la mémoire de masse peut être gérée par un arbitre de bus. Une tâche allouée au cœur de processeur central constituant la partie de traitement standard est traitée cycle par cycle sur ce même cœur de processeur central jusqu'à atteindre une instruction spécialisée qui est décodée et génère une commande en direction de l'unité de contrôle et d'allocation de manière à provoquer la création d'un flot d'instructions qui est exécuté sur l'une des unités de calcul sous la gestion de l'unité de contrôle et d'allocation tandis que, une fois l'instruction spécialisée décodée et la commande correspondante générée, l'exécution de la tâche en cours se poursuit dans le cœur de processeur central, sans intervention dans la gestion du flot d'instructions initié et exécuté sur une unité de calcul auxiliaire. En cas de déroutement pouvant intervenir suite à une exception, une interruption ou encore une trappe, on peut provoquer de façon sélective en fonction du type de déroutement, une synchronisation forte dans laquelle tous les composants du processeur sont synchronisés.
En cas de déroutement pouvant intervenir suite à une exception, une interruption ou encore une trappe, on peut provoquer de façon sélective en fonction du type de déroutement, une synchronisation faible selon laquelle seul le contexte correspondant à la partie de traitement standard est synchronisé tandis que l'unité de contrôle et d'allocation de ressources auxiliaires continue de façon autonome une exécution des flots d'instructions sur les unités de calcul auxiliaires.
En cas de déroutement pouvant intervenir suite à un événement local au niveau d'une unité de calcul auxiliaire, on provoque de façon sélective une synchronisation locale selon laquelle l'unité de calcul auxiliaire concernée gère seule le déroutement et est synchronisée indépendamment du reste du processeur.
A la différence des solutions existantes, l'invention intègre un nouveau mécanisme de couplage permettant une très forte intégration des ressources de calcul dans le processeur.
L'architecture du système selon l'invention intègre un premier sous-ensemble ou partie de traitement standard (SPP) qui constitue un cœur de processeur central et un deuxième sous-ensemble ou partie de traitement auxiliaire (APP) qui incorpore notamment les unités de calcul auxiliaires ainsi que l'unité de contrôle et d'allocation des ressources auxiliaires et l'espace mémoire partagé. Ces deux sous-ensembles ont des propriétés et des fonctionnalités radicalement différentes mais pour autant participent à un même objectif, l'exécution d'une tâche. En conséquence, ces fonctionnalités sont très fortement couplées, tant au niveau des données que du contrôle.
D'autres caractéristiques et avantages de l'invention ressortiront de la description suivante de modes particuliers de réalisation, faite en référence aux dessins annexés, sur lesquels :
- les Figures IA et IB représentent respectivement un modèle générique d'architecture SMT et un exemple de fonctionnement,
- les Figures 2A et 2B représentent respectivement un modèle générique d'architecture CMP et un exemple de fonctionnement, - les Figures 3A et 3B représentent respectivement un modèle générique d'architecture CMT et un exemple de fonctionnement,
- la Figure 4 représente symboliquement la décomposition d'un système en applications, puis en tâches et finalement en flots d'instructions ou threads, - la Figure 5 est un schéma-bloc montrant les éléments principaux de l'architecture d'un processeur selon l'invention,
- la Figure 6 est un schéma bloc montrant un mécanisme de couplage entre une partie de traitement auxiliaire et une partie de traitement standard, - la Figure 7 est un schéma montrant un mécanisme d'accès aux données dans une partie de traitement auxiliaire,
- la Figure 8 est un schéma montrant un mécanisme de transfert de données entre une partie de traitement auxiliaire et une partie de traitement standard, - la Figure 9 est un schéma montrant un mécanisme de transfert de données entre une partie de traitement standard et une partie de traitement auxiliaire, et
- la Figure 10 est un schéma-bloc d'un exemple de système multiprocesseur à mémoire partagée mettant en œuvre l'invention. On précisera d'abord en référence à la Figure 4 la décomposition d'un système 10 en applications 11, 12, puis en tâches 21 à 25, et finalement en flots d'instructions ou "threads" 31 à 33, encore dénommés "processus légers".
Un système embarqué 10 est typiquement susceptible de traiter plusieurs applications 11, 12 de manière concurrente. Une application fait référence à une fonctionnalité, un service offert par un système embarqué. Toute application 11, 12 traitée sur un système embarqué peut alors se décomposer sous la forme de tâches 21 à 25 qui s'enchaînent les unes aux autres suivant des dépendances de contrôle exprimées dans l'application. Ces tâches 21 à 25 peuvent à leur tour être décomposées en opérations exécutées séquentiellement ou en threads parallèles 31 à 33 pour lesquels des exécutions concurrentes sont possibles.
Dans la suite de la description, on utilisera ainsi le terme threads pour désigner un processus léger qui est un flot d'exécution partageant éventuellement l'intégralité de son espace d'adressage avec d'autres processus.
On a représenté sur la Figure 5 un exemple d'architecture de processeur conforme à l'invention, avec un premier sous-ensemble constitué par une partie de traitement standard SPP formant un cœur de processeur central, et un deuxième sous-ensemble constitué par une partie de traitement auxiliaire APP.
D'une manière générale, la partie de traitement standard SPP se charge de l'exécution des tâches. Ceci inclut d'une part le traitement des instructions constituant le programme à traiter mais également le logiciel système. A la différence d'un processeur conventionnel, celui-ci est cependant capable de faire appel à des unités d'exécution auxiliaires APUO, APUl,..., APUN-2, APUN-I incluses dans la partie de traitement auxiliaire APP pour traiter certaines portions applicatives nécessitant de très fortes puissances de calcul.
L'invention met en œuvre un procédé spécifique dans la façon de faire appel aux unités de calcul auxiliaires.
La partie de traitement standard SPP se charge des calculs non spécialisés au sein des applications. Elle traite également le logiciel système gérant le partage des ressources et le contrôle des tâches. Elle est construite sur la base d'un processeur généraliste. Elle est donc classiquement basée sur quatre unités :
1. Unité de contrôle ESCU ; cette unité se charge de la lecture et du décodage des instructions. La complexité de cette unité est variable.
Elle est en effet susceptible de pouvoir gérer plusieurs instructions simultanément et de choisir les instructions prêtes à être exécutées, pour une exécution dite dans le désordre de l'application. Cette unité peut également intégrer un certain nombre de mécanismes permettant de prédire la direction des branchements. En fonction de l'instruction, cette unité envoie des commandes vers les autres unités de l'architecture.
2. Unité de calcul SPU : cette unité se charge de la réalisation des calculs standards identifiés par les instructions. Cette unité peut éventuellement intégrer plusieurs ressources de calculs si l'unité de contrôle ESCU peut gérer plusieurs instructions simultanément.
3. Unité de mémorisation : cette unité se charge du stockage des données et des instructions liées au programme. Cette unité peut être bâtie sur la base de deux niveaux de hiérarchies de mémoires cache suivant un modèle d'exécution Harvard et avec un cache de niveau 2 unifié.
Cette unité de mémorisation comprend alors des mémoires caches Ll D-Cache et Ll I-Cache de niveau 1 et une mémoire cache L2- Cache de niveau 2.
4. Unité de chargement LSU : L'unité de chargement se charge de faire le lien entre les données stockées dans la mémoire et les unités manipulées par l'unité de calcul SPU. Ce lien est matérialisé par une file de registres dont le nombre de ports varie en fonction du nombre d'instructions traitées par cycle au sein de la partie de traitement standard
SPP.
Pour fournir un couplage très étroit entre la partie de traitement standard SPP et la partie de traitement auxiliaire APP, quelques particularités peuvent être apportées à l'unité de contrôle ESCU et à l'unité de chargement LSU par rapport à un cœur de processeur central classique.
Ainsi, l'unité de contrôle ESCU peut comprendre des instructions supplémentaires pour contrôler la partie de traitement auxiliaire APP. Ces instructions permettent par exemple de demander l'exécution d'un traitement critique. Toutefois, des mécanismes plus standard peuvent également être mis en œuvre, ne nécessitant pas l'introduction de nouvelles instructions (par exemple méthode de couplage avec mappage en mémoire dite "mβmory mapped").
L'unité de chargement LSU peut intégrer une file de registres supplémentaire. En plus de la file de registre générale classique, une seconde file de registres est ainsi intégrée à l'unité de chargement LSU. Celle-ci permet des échanges de données entre les deux sous-ensembles SPP et APP.
D'un point de vue structurel, il n'existe pas de différence, au niveau de l'unité de chargement LSU entre cette file de registres auxiliaire ARF et la file de registres générale GPRF (voir Figures 8 et 9). Le processeur distingue les registres généraux des registres auxiliaires grâce à leur adresse. Il est à noter que ce mode de communication entre les deux sous-ensembles SPP et APP convient particulièrement bien aux transferts de données peu volumineuses. La partie auxiliaire APP prend en charge les calculs spécialisés et/ou intensifs de l'application. Elle intègre plusieurs unités APUO, APUl,... APUN-2, APUN-I de calcul auxiliaire partageant un unique espace mémoire SMS. Le nombre N d'éléments de calcul auxiliaires APUO,... APUN-I ne fait l'objet d'aucune limitation particulière. De même, ces éléments de calcul qui, dans la suite, ne seront pas distingués les uns des autres et seront simplement notés APU, pourront indifféremment être construits sur la base d'une logique synchrone ou asynchrone. La partie de traitement auxiliaire APP se prête donc particulièrement bien à la mise en place de structures du type GALS (Globalement Asynchrone et Localement Synchrone). Une partie auxiliaire APP contiendra typiquement de 4 à 8 éléments de calcul APU. A un instant donné, une unité de calcul auxiliaire APU ne traite qu'un thread et un thread n'est exécuté que sur une unité de calcul auxiliaire APU.
Un ensemble de processus légers ou threads est assigné aux unités de calcul auxiliaires APU par l'unité d'allocation et de contrôle ACU incluse dans la partie auxiliaire APP suite à des demandes d'exécution issues de l'unité de contrôle ESCU. L'allocation physique des threads aux unités de calcul auxiliaires APU ainsi que la gestion de leur exécution et la synchronisation entre différents threads sont à la charge de cette unité d'allocation et de contrôle ACU.
La partie de traitement auxiliaire APP intègre également des contrôleurs d'entrées sorties IO dits temps critiques. Ceux-ci sont directement liés aux périphériques d'entrées sorties temps-critiques. Ces derniers peuvent par exemple correspondre à des convertisseurs Analogique-Numérique rapides, à des interfaces Radio Fréquence, des capteurs vidéo ... Ces M contrôleurs d'entrées sorties IOO à IOM-1 sont considérés par l'unité de contrôle et d'allocation ACU comme des unités de calcul auxiliaires APU. L'unité de contrôle et d'allocation ACU se doit alors d'assigner une tâche au contrôleur d'entrées sorties pour charger celui-ci de gérer l'accès à l'entrée/sortie. Les données émises ou reçues sont en provenance ou à destination de l'espace mémoire partagé SMS. Les entrées sorties moins critiques, comme par exemple celles correspondant à un clavier ou une souris, sont en revanche connectées par des moyens plus standards, tels que le bus système SB, à la partie de traitement standard SPP. La partie de traitement auxiliaire APP peut encore contenir une mémoire de masse MM afin de stocker l'ensemble des données et des programmes manipulés par les unités de calcul auxiliaires APU. Cette mémoire MM dispose par ailleurs de son propre contrôleur MMC sur lequel l'unité de contrôle et d'allocation ACU alloue des threads de transfert de données entre le système (matérialisé sur la Figure 5 par le bus système SB) et les threads de calcul intensif. Ce contrôleur MMC intervient également lors des transferts de données entre l'espace mémoire partagé SMS et la mémoire de masse MM.
Les unités de calcul auxiliaires APU sont optimisées pour le traitement rapide de certaines opérations. Elles peuvent offrir différents compromis entre performance, flexibilité, coût ou consommation en fonction de leur type. La sélection de tel ou tel type d'unité de calcul est alors fortement influencée par le contexte applicatif.
Les unités de calcul auxiliaires peuvent comprendre des unités programmables, des unités reconfigurables ou des unités dédiées.
• Unités programmables : ce type d'unité correspond à des cœurs de processeurs généralistes (MIPS, ARM, etc..) ou optimisés (DSP, ST2xx, etc..) pour le calcul embarqué. Ces unités étant optimisées pour le calcul, elles voient leurs structures de contrôle simplifiées, par exemple en éliminant les mécanismes de prédiction de branchement, de gestion d'interruptions ou de virtualisation des données. Ces unités peuvent par ailleurs intégrer des unités de calcul spécialisées comme des unités flottantes et/ou vectorielles.
• Unités reconfigurables : des unités reconfigurables sont également susceptibles d'être utilisées en tant qu'accélérateur de calcul. Des structures de gros grain sont privilégiées du fait de leur capacité à être reconfigurées rapidement, et du bon compromis performance/flexibilité qu'elles peuvent offrir. Des structures de grain fin peuvent également être intégrées si une grande souplesse d'utilisation est nécessaire ou si des opérations travaillant sur des données de très petites tailles (1 à 4 bits) sont susceptibles d'être traitées. En raison de leur très faible réactivité, c'est-à-dire des très longs temps de reconfiguration, ces ressources de grain fin sont susceptibles d'être gérées différemment, par exemple afin d'éviter leur préemption.
• Unités dédiées : des unités optimisées pour certains traitements critiques peuvent finalement être intégrées au composant. Ces accélérateurs dédiés prennent en charge les traitements critiques, pour lesquels des solutions programmables ou reconfigurables n'offrent pas de puissance de calcul suffisante. Des traitements de cryptographie ou de gestion de flux d'entrées/sorties à très fortes cadences sont par exemple de bons candidats à de telles implémentations.
Quel que soit leur type, les unités de calcul auxiliaires APU sont par ailleurs susceptibles de contenir des ressources de stockage privées. Celles-ci peuvent être utilisées soit pour stocker des données intermédiaires afin de faciliter leur accès et de minimiser la bande passante sur l'espace mémoire partagé, soit pour stocker les instructions du programme en cours d'exécution. Les programmes susceptibles d'être exécutés pourraient par ailleurs également être stockés localement afin d'accélérer les phases d'allocation de tâches.
Les deux sous-ensembles SPP et APP se partagent un accès au reste du système. Le médium de communication est alors le bus système
SB et le partage de cette ressource est géré par un arbitre de bus SBA.
Deux éléments peuvent nécessiter un accès au bus système dans la partie de traitement auxiliaire APP, la mémoire principale et les contrôleurs d'entrées sorties 10, Du point de vue de la partie de traitement standard SPP, cet accès au bus système SB est utilisé pour charger la mémoire cache L2-Cache par des données ou des instructions provenant de Ia mémoire de masse MM ou d'éléments périphériques. En cas de demandes d'accès simultanées de plusieurs éléments du processeur, l'arbitre de bus
SBA séquence les demandes d'accès afin de garantir l'unicité des communications sur Ie bus système SB, En fonction du contexte applicatif, la bande passante requise pour chacun de ces éléments va significativement changer. Ainsi différentes variantes de ce schéma peuvent être envisagées pour des domaines applicatifs dans lesquels plusieurs éléments sont simultanément susceptibles de requérir une forte bande passante. Il est ainsi possible d'envisager d'autres schémas dans lesquels un second (voire un troisième) bus système serait ajouté afin d'offrir une bande passante suffisante à tous les éléments du système.
Un mode de réalisation particulier est détaillé ci-dessous. Lorsqu'une tâche est allouée à la partie de traitement standard
SPP, par le logiciel système exécuté sur cette même partie SPP, celle-ci déroule son programme de manière tout à fait conventionnelle pour un processeur programmable. Le traitement des instructions se réalise cycle après cycle jusqu'à atteindre une instruction spécialisée. Lorsque celle-ci est décodée par l'unité de contrôle ESCU, une commande est générée en direction de l'unité de contrôle et d'allocation ACU, provoquant éventuellement la création d'un thread devant être exécuté sur l'une des unités de calcul auxiliaires APU. Dans un tel cas de figure, l'unité de contrôle et d'allocation ACU se chargera alors de la gestion de l'exécution de celui-ci. Il est à noter que ce modèle d'exécution est adapté à un modèle de programmation dans lequel l'activation de threads de calcul se fait par appel à des fonctions optimisées dans une bibliothèque. Cette approche, déjà largement employée dans le domaine du logiciel embarqué, correspond par exemple à l'utilisation d'instructions AltiVec ou MMX dans les processeurs généralistes.
Une fois l'instruction spécialisée traitée par l'unité de contrôle ESCU, la partie de traitement standard SPP poursuit l'exécution du programme, sans intervenir dans la gestion du thread initié sur la partie de traitement auxiliaire APP. L'exécution du programme se poursuit donc jusqu'à son terme ou le traitement de nouvelles instructions spécialisées, pouvant provoquer entre autre la création ou la destruction de threads, la lecture de données générées dans la partie de traitement auxiliaire APP, .,,
En cas de déroutement, pouvant intervenir suite à une exception, une interruption ou encore une trappe, trois comportements sont envisageables : 1. Synchronisation forte : tous les composants du processeur sont synchronisés (pour les deux sous-ensembles APP et SPP). Cette phase de synchronisation pouvant être longue, des mécanismes de synchronisation partielle pourront être définis afin de réduire ces pénalités dans le cadre d'un fonctionnement multitâche. Le contenu de la mémoire de masse pourrait par exemple être maintenu quelques temps afin d'accélérer le prochain changement de contexte, à la manière d'un cache de victime.
2. Synchronisation faible : Seul le contexte correspondant à la partie de traitement standard SPP est synchronisé. Dans ce cas de figure, les fonctions actives sur les unités de calcul auxiliaires APU sont maintenues sur la partie de traitement auxiliaire APP. L'unité ACU de contrôle et d'allocation de ressources auxiliaires se charge seule de leur exécution. Ce fonctionnement autonome peut ainsi perdurer tant que le thread ne fait pas appel à des informations produites ou maintenues par la partie standard de la tâche (celle traitée par la partie de traitement standard SPP).
3. Synchronisation locale : En cas de déroutement intervenant suite à un événement local à une unité de calcul auxiliaire APU, par exemple, division par zéro, celle-ci peut gérer seule le déroutement et ainsi être synchronisée indépendamment du reste du processeur.
L'unité d'allocation et de contrôle ACU se charge d'exécuter les instructions spécialisées issues de l'unité de contrôle ESCU. Le détail de ce couplage permettant à l'unité de contrôle ESCU de communiquer avec l'unité d'allocation et de contrôle ACU est modélisé sur la Figure 6.
On voit ainsi sur la Figure 6 l'unité de contrôle ESCU, l'unité de chargement LSU et l'unité de calcul SPU de la partie de traitement standard SPP, ainsi qu'une partie de l'unité de mémorisation Ll I-Cache.
La Figure 6 montre également l'unité de contrôle et d'allocation ACU faisant partie de la partie de traitement auxiliaire APP.
Les instructions standards de Ia partie de traitement standard SPP sont lues puis décodées, respectivement dans les étages de lecture et de décodage de l'unité de contrôle ESCU, afin de commander l'unité de chargement LSU et l'unité de calcul SPU. A l'inverse, dans Ie cas d'instructions spécialisées, l'unité de contrôle ESCU redirige Ie flot de commandes vers l'unité d'allocation et de contrôle ACU. Ces instructions spécialisées peuvent être de différentes natures et concerner par exemple :
- la création/suppression de threads,
- la suppression des threads associés à une tâche, - le transfert de données de la mémoire principale MM vers le bus système SB ou vice-versa,
- le transfert de données entre les sous-ensembles SPP et APP. En allouant une tâche à la partie de traitement standard SPP, le logiciel système réalise une allocation virtuelle des threads aux unités de calcul auxiliaires APU. C'est ensuite à l'unité de contrôle et d'allocation ACU de réaliser physiquement cette allocation et de prendre en compte l'ensemble des paramètres permettant de déterminer la meilleure allocation possible. Outre l'allocation, l'unité de contrôle et d'allocation ACU gère également les synchronisations entre les threads ainsi que les accès aux ressources critiques partagées. Cette unité de contrôle et d'allocation ACU peut également se charger de fournir un support au logiciel système, par exemple en gérant seule les préemptions ou en se chargeant de la mise à jour des listes des tâches.
De par ces fonctions, l'unité de contrôle et d'allocation ACU se doit de disposer du contexte d'exécution de chacun des threads en cours d'exécution sur la partie de traitement auxiliaire APP. En effet, lors d'une synchronisation faible, l'unité de contrôle et d'allocation ACU est seule responsable de l'évolution des threads. En conséquence, lorsque la tâche est réallouée à la partie de traitement standard SPP, il est nécessaire de l'informer sur l'état d'avancement des threads de calcul. Ceci permet en effet à la partie de traitement standard SPP de ne pas réactiver des threads non terminés, mais en cours d'exécution sur la partie de traitement auxiliaire APP. La disponibilité d'un contexte local dans l'unité de contrôle et d'allocation ACU permet de garantir un état cohérent lorsqu'une tâche est allouée sur le processeur. Ceci est d'autant plus vrai si les tâches sont exécutées dans le désordre sur la partie de traitement standard SPP.
En dehors de ces services de base, l'unité de contrôle et d'allocation ACU pourra également prendre en charge des fonctions plus spécifiques aux domaines applicatifs, Parmi ces fonctions on peut citer la gestion dynamique de la puissance, Ia gestion des pannes ou encore la gestion des « modes de crise ».
Toutes les données manipulées au sein des unités de calcul auxiliaires APU sont stockées dans un espace mémoire partagé SMS. Cet espace mémoire partagé SMS est constitué de multiples ressources de mémorisation et d'un réseau d'interconnexion permettant de réunir toutes ces ressources au sein d'un seul et même espace. Un contrôleur d'espace mémoire MSC se charge d'établir un lien entre les ressources de calcul et les ressources de mémorisation. L'unité de contrôle et d'allocation ACU est par ailleurs utilisée pour fournir certaines informations permettant de faire le lien entre les adresses virtuelles dans l'espace mémoire partagé, manipulées par les unités de contrôle auxiliaires APU, (correspondant au nom d'une variable ainsi qu'à une position dans cette variable, par exemple nom d'image et indice de pixel) et l'adresse physique devant être propagée jusqu'à la ressource de mémorisation utilisée. Le mécanisme d'accès aux données est illustré par la Figure 7 pour un transfert de données opérant entre une unité de calcul auxiliaire APU producteur notée APUp et une unité de calcul auxiliaire APU consommateur notée APUc. Ce mécanisme d'accès aux données dans la partie de traitement auxiliaire APP se décompose en deux étapes, identifiées par les cercles 1 et 2 sur cette Figure 7.
La première phase d'un accès à une donnée n'est réalisée que lorsqu'une unité de calcul auxiliaire APU accède pour la première fois à une variable. Dans ce cas de figure, il n'existe pas de lien entre la donnée et la mémoire qui la contient. Pour obtenir cette information, l'unité de calcul auxiliaire APU interroge l'unité de contrôle et d'allocation ACU. Celle- ci intègre une unité de gestion d'espace mémoire MSMU réalisant cette fonction en associant au nom d'une variable la mémoire qui la stocke. Lorsque la donnée est identifiée dans cette unité, l'unité de gestion MSMU renvoie vers l'unité l'identifiant de la mémoire stockant la variable. A l'inverse, lorsqu'une unité de calcul auxiliaire ÂPU tente d'écrire une donnée qui n'est pas référencée (lors de Ia première écriture de cette variable par exemple), l'unité de gestion MSMU se charge de lui allouer une mémoire parmi les éléments de mémorisation disponibles dans l'espace mémoire partagé SMS. Une fois la mémoire allouée, l'unité associant au nom d'une variable la mémoire qui Ia stocke est mise à jour et l'identifiant de la mémoire est renvoyé vers l'unité de calcul auxiliaire APU. Lorsqu'une unité de calcul auxiliaire APU tente de lire une donnée qui n'est pas référencée (lors de la première écriture de cette variable par exemple), l'unité de gestion MSMU se charge de la rapatrier (en lien avec le contrôleur de mémoire principale MMC) et de lui allouer une mémoire parmi les éléments de mémorisation disponibles dans l'espace mémoire partagé SMS. Lorsqu'une donnée est écrite définitivement (résultat final), l'entrée correspondante dans l'unité associant au nom d'une variable la mémoire qui la stocke est libérée et une requête est transmise au contrôleur de mémoire principale MMC pour rapatrier cette donnée dans la mémoire de masse.
La seconde phase de l'accès aux données est quant à elle systématiquement réalisée puisqu'elle permet de faire le lien entre l'unité de calcul auxiliaire APU et la mémoire contenant la donnée. Lorsque l'unité de calcul auxiliaire APU connaît la mémoire à laquelle elle souhaite accéder, elle transfère cette information au contrôleur de l'espace mémoire partagé SMS, dans le même temps de cycle que l'adresse de la donnée recherchée et les signaux de contrôle de la mémoire. Le contrôleur d'espace mémoire MSC se charge alors d'acheminer ces signaux (puis les données en retour) vers la mémoire adéquate. En fonction du type de structure retenue pour interconnecter les ressources de mémorisation, ce service peut être différent. Dans le cadre d'un réseau sur puce tel que celui modélisé sur la Figure 7, ce contrôleur d'espace mémoire MSC servira à « mettre en paquet » les données, c'est-à-dire à rajouter aux données les informations de routage dans le réseau. Dans le cadre d'un réseau point à point de type crossbar, le contrôleur d'espace mémoire MSC se chargera de la configuration matérielle du chemin à emprunter.
Il est à noter que la gestion des adresses de données au niveau des unités de calcul auxiliaires APU est assurée par des blocs d'entrées sorties spécifiques, éventuellement capables de gérer des flux de données plus complexes et des communications par rafales (burst) par exemple. Ainsi, ces éléments de gestion de données se chargent d'aller récupérer les données manipulées par les unités de calcul auxiliaires APU. Si l'accès aux données est impossible ou ralenti, ces modules de contrôle peuvent geler l'exécution du thread sur l'unité de calcul auxiliaire APU, afin d'éviter que celle-ci tente de manipuler une donnée non stable.
En fonction du domaine applicatif et de l'espace mémoire partagé SMS qui en découle, il est possible que des conflits apparaissent en cours d'exécution, suite à un nombre de demandes d'accès à une donnée NbaCœss supérieur au nombre Nbp0rts de ports de la mémoire ou d'un nœud du réseau. Ce ralentissement possible doit alors être pris en compte lors du dimensionnement du système sachant que le temps d'accès à la mémoire TaCœss devant être considéré sera donné par l'équation (1) :
T accès = Tmem x SuA — ^≡^- ( 1 )
où Nbacœss représente le nombre d'accès, Nbport représente le nombre de ports de l'espace mémoire partagé SMS ou d'un nœud du réseau,
Tmem représente le temps d'accès mémoire minimum.
Afin de minimiser ce surcoût, il est possible d'accroître virtuellement le nombre de ports de lecture de la mémoire en dupliquant les données dans différents bancs mémoire et ainsi permettre plusieurs accès simultanés. Un compromis entre temps d'écriture et temps de lecture des données devra alors être déterminé par l'utilisateur afin d'optimiser les performances globales du système. Il est à noter que lors d'un tel conflit, aucune politique de priorité particulière des accès n'est mise en œuvre. Une solution simple de type FIFO remplira par exemple très bien cette fonction de gestion des conflits et permettra de garantir un temps d'accès maximum aux mémoires.
On notera que la structure mémoire utilisée est intéressante car les données sont liées à une structure mémoire et non à un élément de calcul. La préemption peut donc être réalisée très rapidement car un changement de contexte n'implique pas nécessairement de transfert de données entre ressources de calcul.
Des données de faible volume peuvent être échangées entre la partie de traitement auxiliaire APP et la partie de traitement standard SPP, comme illustré sur la Figure 5. Ces transferts de données sont explicités directement dans le programme source qui intègre des instructions permettant d'identifier :
- la direction du transfert de la partie de traitement auxiliaire APP vers la partie de traitement standard SPP ou vice versa, - le registre ciblé dans la partie standard,
- le thread ciblé dans la partie de traitement auxiliaire,
- la donnée du thread.
Ainsi la lecture de l'instruction LOAD Rx, Ty, Rz de l'exemple illustré sur la Figure 8 permet de charger dans le registre Rx de la partie de traitement standard SPP, la variable Rz du thread Ty exécuté sur la partie de traitement auxiliaire APP. Lorsque l'unité de contrôle ESCU décode cette instruction, elle se doit de générer trois commandes :
1. Read(Rz) : cette commande conduit la lecture dans chacune des unités de calcul auxiliaires APU de la variable Rz de l'unité de calcul auxiliaire APU.
2. Search(Ty) : cette commande est envoyée à l'unité de contrôle et d'allocation ACU pour identifier l'unité de calcul auxiliaire APU qui exécute le thread Ty. Cette identification est réalisée au moyen d'une table de pages ou TLB (Translation Look-aside Buffer) associant à chaque thread actif sur l'unité de contrôle et d'allocation
ACU, l'unité de calcul auxiliaire APU qui l'exécute. Si ce TLB ne renvoie pas d'identifiant d'unité de calcul APU, le thread n'est pas en cours d'exécution et la tâche en cours d'exécution sur la partie de traitement standard SPP est en attente. Si le thread est en cours d'exécution, le TLB renvoie l'identifiant de l'unité de calcul APU qui l'exécute. Cet identifiant est utilisé au niveau de la partie de traitement standard SPP pour sélectionner la donnée devant être envoyée vers la file de registre auxiliaire de cette partie de traitement auxiliaire SPP, Cet identifiant peut également être utilisé au niveau des unités de calcul auxiliaires APU pour valider ou non la lecture des données dans Ia file de registre partagé SRF.
3. Write(Rx) : cette commande conduit l'écriture dans le registre Rx de la file de registre auxiliaire de la donnée renvoyée par la partie de traitement auxiliaire APP. On notera que l'envoi de la commande APUi aux unités de calcul auxiliaires APUO, APUl,..., APUN-2, APUN-I est facultatif et peut être éliminé sans perturber le mode de transfert. Il permet cependant d'éviter des accès aux files de registres inutiles.
Un mécanisme dual permet bien entendu de transférer des données depuis la partie de traitement standard SPP jusqu'à la partie de traitement auxiliaire APP. Ce mécanisme est représenté sur la Figure 9, qui est similaire à la Figure 8, mais avec la substitution des instructions STORE Rx, Ty, Rz, Write(Rz) et Read(Rx) respectivement aux instructions LOAD Rx, Ty, Rz, Read(Rz) et Write(Rx).
On décrit ci-dessous un exemple de réalisation dans lequel les accès au bus système se font par le biais de la mémoire principale MM. Le contrôleur de mémoire principale MMC, l'unité d'allocation et de contrôle ACU et le contrôleur d'espace mémoire MSC peuvent intervenir dans le contrôle de ces communications, en fonction du type de communication mis en œuvre. Ainsi la mémoire principale MM intervient dans quatre types de communications :
1. Bus système SB vers mémoire principale MM : Ce premier type de transfert permet de rapatrier des données depuis l'extérieur du système vers la mémoire principale MM de la partie de traitement auxiliaire APP. Ces transferts interviennent suite au décodage d'une instruction spéciale dans l'unité de contrôle ESCU. Cette instruction spéciale provoque la création d'une opération de transfert de données qui sera assignée par l'unité de contrôle et d'allocation ACU au contrôleur de mémoire principale MMC. Le comportement de celui-ci sera alors comparable à celui d'un contrôleur DMA (d'accès direct à la mémoire). Dans le même temps, le contrôleur de mémoire principale MMC renseigne une table qui lui permettra de faire le lien entre la donnée chargée et sa position dans la mémoire principale MM.
2. Mémoire principale MM vers bus système SB ; D'une manière symétrique, les données sont transférées depuis la mémoire principale MM vers le reste du système suite à l'arrivée d'une opération de transfert identifiée par des instructions spéciales au niveau de l'unité de contrôle ESCU. Les envois depuis la mémoire principale MM peuvent par ailleurs se traduire par une destruction d'une entrée dans la table de correspondance si cette donnée était un résultat final. Ceci suppose que les instructions spéciales décodées par l'unité de contrôle ESCU autorisent la distinction entre transfert destructif et non destructif.
3. Mémoire principale MM vers espace mémoire partagé SMS : Si une unité de calcul auxiliaire APU tente d'accéder à une donnée non présente dans l'espace mémoire partagé SMS, une requête de transfert est transmise par l'unité de contrôle et d'allocation ACU au contrôleur MMC, afin d'acheminer cette donnée dans l'espace mémoire partagé SMS. L'unité de calcul auxiliaire APU est alors bloquée le temps du transfert. 4. Espace mémoire partagé SMS vers mémoire principale MM : Ces transferts font suite à des transferts de données spéciaux des unités de calcul auxiliaires APU qui spécifient l'écriture d'un résultat final, c'est-à-dire qui n'est pas voué à être relu dans la partie de traitement auxiliaire APP, dans l'espace mémoire partagé SMS. Ces transferts peuvent également intervenir en cas de synchronisation forte dans le cadre d'une sauvegarde de contexte. Dans ce cas de figure, l'espace mémoire partagé SMS envoie une requête de transfert par l'intermédiaire de l'unité de contrôle et d'allocation ACU au contrôleur de mémoire principale MMC. En fonction des domaines applicatifs ciblés, il est possible que l'intégration d'une mémoire de masse soit inutile. Ce cas de figure correspond au cas où la mémoire de masse MM est intégrée dans l'espace mémoire partagé SMS au même titre que n'importe quelle ressource de mémorisation. Dans ce cas de figure, les données sont échangées directement entre l'espace mémoire partagé SMS et le bus système. La gestion de ces échanges se fait une fois encore sous la forme de threads de communication, pouvant être exécutés sur n'importe laquelle des unités de calcul auxiliaires APU de la structure ou de préférence sur une unité dédiée telle que le contrôleur de mémoire principale MMC. Le procédé selon la présente invention, de même que l'architecture qui permet sa mise en œuvre sont extensibles, c'est-à-dire qu'ils peuvent supporter un nombre variable d'unités de calcul auxiliaires ÂPU.
Dans la pratique, les performances de l'architecture sont cependant susceptibles de subir une certaine dégradation lorsque le nombre d'unités de calcul auxiliaires APU est trop grand, par exemple de l'ordre de plusieurs centaines.
Une façon de résoudre ce problème consiste à adopter l'architecture d'un système multiprocesseur à mémoire partagée. Un exemple d'une telle réalisation est représenté sur la Figure 10 qui ne montre à titre d'exemple que l'association de deux processeurs conformes à l'invention, mais pourrait naturellement comprendre un plus grand nombre de processeurs associés dont tous les cœurs disposent de la même organisation, centrée sur le couplage d'une partie de traitement standard SPP et d'une partie auxiliaire de calcul APP, comme décrit précédemment, notamment en référence à la Figure 5.
Toutefois, dans le cas d'un système multiprocesseur à mémoire partagée, il est avantageux de partager certains éléments tels que l'arbitre du bus système SBA ou la mémoire de masse MM des parties de traitement auxiliaires APP, comme représenté sur la Figure 10, ou encore des contrôleurs d'entrée/sortie rapides, ceux-ci pouvant également être partagés entre les cœurs par l'intermédiaire de bus dédiés.
En résumé, l'invention concerne essentiellement un dispositif et un procédé de contrôle et d'allocation de threads sur une architecture embarquée, intégrant avantageusement de multiples ressources de traitement, dédiées au calcul intensif multitâche et multiflot en temps-réel.
De façon plus particulière, l'architecture de calculateur parallèle temps-réel comprend :
- un cœur de processeur central SPP chargé de l'exécution des traitements non critiques des tâches et du support du logiciel système,
- des unités de calcul auxiliaires APU programmables, reconfigurables ou dédiées optimisées pour le traitement rapide de certaines opérations,
- un espace mémoire partagé SMS par les unités de calcul auxiliaires APU via un réseau interne,
- une unité ACU de contrôle et d'allocation des ressources auxiliaires, qui gère l'exécution des traitements intensifs des unités de calcul auxiliaire APUi en parallèle.
De façon plus particulière, la communication entre les différentes unités de calcul auxiliaire APU, entre les unités de calcul auxiliaires APU et le cœur de processeur central SPP se fait par l'intermédiaire de l'espace mémoire partagé SMS et d'un réseau interne.
Le procédé d'allocation et de traitement des tâches permet de séparer les tâches de contrôle exécutées par le cœur de processeur central SPP, des tâches de calcul intensif, exécutées par les unités de calcul APU spécialisées. L'unité de contrôle et d'allocation ACU gère l'allocation des tâches de calcul intensif pour les différentes unités de calcul auxiliaires APU travaillant en parallèle. Ce contrôleur auxiliaire ACU permet la mise en œuvre de mécanismes de synchronisation dits faibles grâce auxquels les unités de calcul auxiliaires APU peuvent traiter des threads d'une tâche différente de celle exécutée sur le cœur du processeur central SPP. L'état du système n'est alors plus représenté par un contexte unique, à l'inverse d'une architecture Von Neuman. Les entrées sorties temps-critiques sont directement reliées à l'espace mémoire partagé par les unités de calcul auxiliaires APU. Cette architecture et ce procédé d'allocation permettent un traitement multitâche temps réel optimisé, c'est-à-dire avec une diminution des temps de chargement de données, et adaptable à différentes applications.

Claims

REVENDICATIONS
1. Système de calcul intensif multitâche et multiflot en temps réel, caractérisé en ce qu'il comprend au moins un cœur de processeur central (SPP), chargé du support du logiciel système, et comprenant une unité de contrôle (ESCU) chargée de l'allocation des processus légers d'une application, les processus légers non critiques étant exécutés par le cœur de processeur central (SPP), tandis que les processus légers intensifs ou spécialisés sont alloués à une partie de traitement auxiliaire (APP), comprenant un ensemble de N unités de calcul auxiliaires (APUO, ..., APUN-I) optimisées pour le traitement rapide de certaines opérations, un espace mémoire (SMS) partagé par les unités de calcul auxiliaires (APUO, ..., APUN-I) via un réseau interne et une unité (ACU) de contrôle et d'allocation des ressources auxiliaires, chargée d'une part de l'allocation des flots d'instructions élémentaires, correspondant aux processus légers intensifs ou spécialisés, aux unités de calcul auxiliaires (APUO, ..., APUN-I) en parallèle, et chargée d'autre part du contrôle de l'exécution et de la synchronisation de ces flots d'instructions et de la gestion des contextes d'exécution des flots d'instructions, et en ce que les différents éléments constitutifs du système sont agencés de telle manière que la communication d'au moins une partie des données entre les différentes unités de calcul auxiliaires (APUO,..., APUN-I) ou entre ces unités de calcul auxiliaires (APUO,..., APUN-I) et le cœur de processeur central (SPP), s'effectue par l'intermédiaire de l'espace mémoire partagé (SMS) et du réseau interne.
2. Système selon la revendication 1, caractérisé en ce qu'il comprend un bus système (SB) relié au cœur de processeur central (SPP).
3. Système selon la revendication 1 ou la revendication 2, caractérisé en ce qu'il comprend en outre une mémoire de masse (MM) pour le stockage de l'ensemble des données et des programmes manipulés par les unités de calcul auxiliaires (APUO,..., APUN-I).
4. Système selon la revendication 3 caractérisé en ce qu'il comprend un contrôleur de mémoire principale (MMC) associé à la mémoire de masse (MM).
5. Système selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend dans la partie de traitement auxiliaire (APP) des contrôleurs d'entrées sorties temps critique interfaces aux unités de calcul auxiliaires (APUO,..., APUN-I) par l'intermédiaire de l'espace mémoire partagé (SMS).
6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce que l'espace mémoire partagé (SMS) comprend de multiples ressources de mémorisation et un réseau d'interconnexion permettant de réunir toutes ces ressources, et en ce que cet espace mémoire partagé (SMS) stocke toutes les données manipulées au sein des unités de calcul auxiliaires (APUO,..., APUN-I).
7. Système selon l'une quelconque des revendications 1 à 6, caractérisé en ce que l'espace mémoire partagé (SMS) comprend en outre un contrôleur d'espace mémoire (MSC) chargé d'établir un lien entre les ressources de calcul et les ressources de mémorisation de l'espace mémoire partagé (SMS).
8. Système selon l'une quelconque des revendications 1 à 6, caractérisé en ce que les unités de calcul auxiliaires (APUO,..., APUN-I) comprennent des unités choisies parmi des unités programmables, des unités reconfigurables et des unités dédiées.
9. Système selon l'une quelconque des revendications 1 à 8, caractérisé en ce que le cœur de processeur central (SPP) comprend en outre une unité de calcul (SPU), une unité de mémorisation (Ll D-Cachβ, Ll 1-Cache, L2-Cache) et une unité de chargement (LSU).
10. Système selon l'une quelconque des revendications 1 à 9, caractérisé en ce que l'unité de contrôle (ESCU) comporte des instructions supplémentaires pour Ie contrôle de la partie de traitement auxiliaire (APP).
11. Système selon la revendication 9, caractérisé en ce que l'unité de chargement (LSU) intègre une file de registres supplémentaire permettant des échanges de données entre le cœur de processeur central (SPP) et la partie de traitement auxiliaire (APP).
12. Système selon l'une quelconque des revendications 1 à 11, caractérisé en ce que le nombre N d'unités de calcul auxiliaires (APUO,...
APUN-I) qui à un instant ne traitent chacune qu'un flot d'instructions élémentaires faisant partie d'une tâche, est optimisé en fonction de l'application et est compris entre 2 et 100.
13. Système selon l'une quelconque des revendications 1 à 12, caractérisé en ce que l'unité (ACU) de contrôle et d'allocation des ressources auxiliaires est en outre chargée d'au moins une fonction de gestion choisie parmi les fonctions de gestion dynamique de la puissance, de gestion des pannes, et de gestion des modes de crise.
14. Système selon la revendication 2, caractérisé en ce qu'il comprend un arbitre de bus (SBA) pour gérer la communication entre d'une part le bus système (SB) et d'autre part le cœur de processeur central (SPP)
15. Système selon la revendication 2 et l'une des revendications 3 et 4, caractérisé en ce qu'il comprend un arbitre de bus (SBA) pour gérer la communication entre d'une part le bus système (SB) et d'autre part le cœur de processeur central (SPP) et la mémoire de masse (MM).
16. Système selon les revendications 2 et 5, caractérisé en ce qu'il comprend un arbitre de bus (SBA) pour gérer la communication entre d'une part le bus système (SB) et d'autre part le cœur de processeur central (SPP) et les entrées sorties (10).
17. Système selon l'une quelconque des revendications 1 à 16, caractérisé en ce qu'il comprend un ensemble de processeurs reliés à un bus système (SB), chaque processeur comprenant un cœur de processeur central (SPP), un ensemble de N unités de calcul auxiliaires (APUO,..., APUN-I), un espace mémoire partagé (SMS) et une unité (ACU) de contrôle et d'allocation des ressources auxiliaires.
18. Système selon la revendication 17, caractérisé en ce qu'il comprend un arbitre de bus système (SBA) partagé entre plusieurs processeurs pour effectuer la liaison avec le bus système (SB).
19. Système selon la revendication 17 ou la revendication 18, caractérisé en ce qu'il comprend une mémoire de masse (MM) partagée entre plusieurs processeurs.
20. Procédé de calcul intensif multitâche et multiflot en temps réel à l'aide d'au moins un processeur comprenant au moins un cœur de processeur central (SPP), une unité de contrôle (ESCU), un ensemble de N unités de calcul auxiliaires (APUO,... APUN-I), un espace mémoire (SMS) partagé par les unités de calcul auxiliaires (APUO,... APUN-I) via un réseau interne, une unité (ACU) de contrôle et d'allocation des ressources auxiliaires, caractérisé en ce que le cœur de processeur central (SPP) est chargé du support du logiciel système, et en ce que l'unité de contrôle (ESCU) est chargée de l'allocation des processus légers d'une application, les processus légers non critiques étant exécutés par le cœur de processeur central (SPP), tandis que les processus légers intensifs ou spécialisés sont alloués à une partie de traitement auxiliaire (APP), par l'intermédiaire de l'unité (ACU) de contrôle et d'allocation des ressources auxiliaires qui est chargée d'une part de l'allocation en parallèle des flots d'instructions élémentaires, correspondant aux tâches intensives ou spécialisées, sur les unités de calcul auxiliaires (APUO,..., APUN-I) optimisées pour le traitement rapide de certaines opérations, et d'autre part du contrôle de l'exécution et de la synchronisation de ces flots d'instructions et de la gestion des contextes d'exécution de ces flots d'instructions, et en ce que la communication d'au moins une partie des données entre les différentes unités de calcul auxiliaires (APUO,..., APUN- 1) ou entre ces unités de calcul auxiliaires (APUO,..., APUN-I) et le cœur de processeur central (SPP) s'effectue par l'intermédiaire de l'espace mémoire partagé (SMS) et du réseau interne.
21. Procédé selon la revendication 20 caractérisé en ce que l'unité de contrôle (ESCU) contrôle le pilotage de l'unité (ACU) de contrôle et d'allocation des ressources auxiliaires au moyen d'instructions standard de lecture/écriture ou d'exceptions standard.
22. Procédé selon la revendication 20, caractérisé en ce que l'unité de contrôle (ESCU) contrôle le pilotage de l'unité (ACU) de contrôle et d'allocation de ressources auxiliaires au moyen d'instructions spécialisées dédiées aux opérations de communication et de synchronisation.
23. Procédé selon la revendication 20, caractérisé en ce que, à un instant donné, une unité de calcul auxiliaire (APUO,..., APUN-I) ne traite qu'un flot d'instructions élémentaires faisant partie d'une tâche et chaque flot d'instructions élémentaires n'est exécuté que sur une seule unité de calcul auxiliaire (APUO,..., APUN-I).
24. Procédé selon la revendication 20, caractérisé en ce que l'ensemble des données et des programmes manipulés par les unités de calcul auxiliaires (APUO,..., APUN-I) sont stockés dans une mémoire de masse (MM).
25. Procédé selon l'une quelconque des revendications 20 à 24, caractérisé en ce que des signaux d'entrées sorties sont transmis en temps critique aux unités de calcul auxiliaires (APUO,...,APUN-I) par l'intermédiaire de l'espace mémoire partagé.
26. Procédé selon l'une quelconque des revendications 20 à 25, caractérisé en ce que le processeur est relié à un bus système (SB).
27. Procédé selon la revendication 26, caractérisé en ce que la communication entre d'une part Ie bus système (SB) et d'autre part le cœur du processeur central (SPP), et le cas échéant les contrôleurs d'entrées-sorties (10) ou la mémoire de masse (MM) est gérée par un arbitre de bus (SBA).
28. Procédé selon l'une quelconque des revendications 20 à 23, caractérisé en ce qu'une tâche allouée au cœur de processeur central (SPP) est traitée cycle par cycle sur ce même cœur de processeur central (SPP) jusqu'à atteindre une instruction spécialisée qui est décodée et génère une commande en direction de l'unité de contrôle et d'allocation (ACU) de manière à provoquer la création d'un flot d'instructions qui est exécuté sur l'une des unités de calcul (APUO,..., APUN-I) sous la gestion de l'unité de contrôle et d'allocation (ACU) tandis que, une fois l'instruction spécialisée décodée et la commande correspondante générée, l'exécution de la tâche en cours se poursuit dans le cœur de processeur central (SPP), sans intervention dans la gestion du flot d'instructions initié et exécuté sur une unité de calcul auxiliaire.
29. Procédé selon la revendication 28, caractérisé en ce que en cas de déroutement pouvant intervenir suite à une exception, une interruption ou encore une trappe, on provoque de façon sélective en fonction du type de déroutement, une synchronisation forte dans laquelle tous les composants du processeur sont synchronisés.
30. Procédé selon la revendication 28, caractérisé en ce que en cas de déroutement pouvant intervenir suite à une exception, une interruption ou encore une trappe, on provoque de façon sélective en fonction du type de déroutement, une synchronisation faible selon laquelle seul le contexte correspondant à la partie de traitement standard est synchronisé tandis que l'unité (ACU) de contrôle et d'allocation de ressources auxiliaires continue de façon autonome une exécution des flots d'instructions sur les unités de calcul auxiliaires.
31. Procédé selon la revendication 28, caractérisé en ce que en cas de déroutement pouvant intervenir suite à un événement local au niveau d'une unité de calcul auxiliaire, on provoque de façon sélective une synchronisation locale selon laquelle l'unité de calcul auxiliaire concernée gère seule le déroutement et est synchronisée indépendamment du reste du processeur.
EP06764855A 2005-11-04 2006-06-08 Procede et systeme de calcul intensif multitache et multiflot en temps reel Withdrawn EP1949234A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0511266A FR2893156B1 (fr) 2005-11-04 2005-11-04 Procede et systeme de calcul intensif multitache et multiflot en temps reel.
PCT/FR2006/050535 WO2007051935A1 (fr) 2005-11-04 2006-06-08 Procede et systeme de calcul intensif multitache et multiflot en temps reel

Publications (1)

Publication Number Publication Date
EP1949234A1 true EP1949234A1 (fr) 2008-07-30

Family

ID=36588738

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06764855A Withdrawn EP1949234A1 (fr) 2005-11-04 2006-06-08 Procede et systeme de calcul intensif multitache et multiflot en temps reel

Country Status (5)

Country Link
US (1) US9052957B2 (fr)
EP (1) EP1949234A1 (fr)
JP (1) JP5366552B2 (fr)
FR (1) FR2893156B1 (fr)
WO (1) WO2007051935A1 (fr)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2937439B1 (fr) * 2008-10-17 2012-04-20 Commissariat Energie Atomique Procede d'execution deterministe et de synchronisation d'un systeme de traitement de l'information comportant plusieurs coeurs de traitement executant des taches systemes.
FR2942556B1 (fr) 2009-02-24 2011-03-25 Commissariat Energie Atomique Unite d'allocation et de controle
US9459941B2 (en) * 2009-07-28 2016-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Apparatus and method for synchronizing the processing of events associated with application sessions in a telecommunications network
CN101872317B (zh) * 2010-07-16 2012-12-26 山东中创软件工程股份有限公司 VxWorks多任务同步与通信方法
US9055069B2 (en) * 2012-03-19 2015-06-09 Xcelemor, Inc. Hardware computing system with software mediation and method of operation thereof
FR3004274A1 (fr) * 2013-04-09 2014-10-10 Krono Safe Procede d'execution de taches dans un systeme temps-reel critique
CN103618942B (zh) * 2013-12-16 2016-09-28 乐视致新电子科技（天津）有限公司 智能电视及其浏览器网页视频的播放方法和装置
JP5949977B1 (ja) * 2015-02-19 2016-07-13 日本電気株式会社 情報処理装置、情報処理方法、メインプロセッサコア、プログラム、情報処理方法、サブプロセッサコア
US9904580B2 (en) 2015-05-29 2018-02-27 International Business Machines Corporation Efficient critical thread scheduling for non-privileged thread requests
JP6432450B2 (ja) * 2015-06-04 2018-12-05 富士通株式会社 並列計算装置、コンパイル装置、並列処理方法、コンパイル方法、並列処理プログラムおよびコンパイルプログラム
US11599383B2 (en) * 2016-08-30 2023-03-07 Microsoft Technology Licensing, Llc Concurrent execution of task instances relating to a plurality of applications
US10284501B2 (en) * 2016-12-08 2019-05-07 Intel IP Corporation Technologies for multi-core wireless network data transmission
US10871998B2 (en) * 2018-01-18 2020-12-22 Red Hat, Inc. Usage instrumented workload scheduling
US11900156B2 (en) * 2019-09-24 2024-02-13 Speedata Ltd. Inter-thread communication in multi-threaded reconfigurable coarse-grain arrays
WO2022056828A1 (fr) * 2020-09-18 2022-03-24 Alibaba Group Holding Limited Architecture de traitement configurable
US20220276914A1 (en) * 2021-03-01 2022-09-01 Nvidia Corporation Interface for multiple processors
US11836527B2 (en) 2021-08-02 2023-12-05 Nvidia Corporation Accelerating table lookups using a decoupled lookup table accelerator in a system on a chip
US11704067B2 (en) * 2021-08-02 2023-07-18 Nvidia Corporation Performing multiple point table lookups in a single cycle in a system on chip
TWI802302B (zh) * 2022-03-01 2023-05-11 正大光明有限公司 光明燈顯示同步系統與方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5001624A (en) * 1987-02-13 1991-03-19 Harrell Hoffman Processor controlled DMA controller for transferring instruction and data from memory to coprocessor
US4862407A (en) * 1987-10-05 1989-08-29 Motorola, Inc. Digital signal processing apparatus
US5056000A (en) * 1988-06-21 1991-10-08 International Parallel Machines, Inc. Synchronized parallel processing with shared memory
US5239654A (en) * 1989-11-17 1993-08-24 Texas Instruments Incorporated Dual mode SIMD/MIMD processor providing reuse of MIMD instruction memories as data memories when operating in SIMD mode
US5682512A (en) * 1995-06-30 1997-10-28 Intel Corporation Use of deferred bus access for address translation in a shared memory clustered computer system
US5706514A (en) * 1996-03-04 1998-01-06 Compaq Computer Corporation Distributed execution of mode mismatched commands in multiprocessor computer systems
US5822553A (en) * 1996-03-13 1998-10-13 Diamond Multimedia Systems, Inc. Multiple parallel digital data stream channel controller architecture
KR100308618B1 (ko) * 1999-02-27 2001-09-26 윤종용 단일 칩 상의 마이크로프로세서-코프로세서 시스템을 구비한 파이프라인 데이터 처리 시스템 및 호스트 마이크로프로세서와 코프로세서 사이의 인터페이스 방법
JP2002041489A (ja) * 2000-07-25 2002-02-08 Mitsubishi Electric Corp 同期信号生成回路、それを用いたプロセッサシステムおよび同期信号生成方法
GB2378271B (en) * 2001-07-30 2004-12-29 Advanced Risc Mach Ltd Handling of coprocessor instructions in a data processing apparatus
JP4647307B2 (ja) * 2002-04-25 2011-03-09 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ スケーラブルプロセッサにおける自動タスク分散
US7533382B2 (en) * 2002-10-30 2009-05-12 Stmicroelectronics, Inc. Hyperprocessor
US6944747B2 (en) * 2002-12-09 2005-09-13 Gemtech Systems, Llc Apparatus and method for matrix data processing

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2007051935A1 *

Also Published As

Publication number Publication date
US20090327610A1 (en) 2009-12-31
WO2007051935A1 (fr) 2007-05-10
US9052957B2 (en) 2015-06-09
FR2893156A1 (fr) 2007-05-11
FR2893156B1 (fr) 2008-02-15
JP5366552B2 (ja) 2013-12-11
JP2009515246A (ja) 2009-04-09

Similar Documents

Publication Publication Date Title
EP1949234A1 (fr) Procede et systeme de calcul intensif multitache et multiflot en temps reel
US11734179B2 (en) Efficient work unit processing in a multicore system
EP2232368B1 (fr) Systeme comportant une pluralite d'unites de traitement permettant d'executer des taches en parallele, en mixant le mode d'execution de type controle et le mode d'execution de type flot de donnees
US10671557B2 (en) Dynamic component communication using general purpose links between respectively pooled together of like typed devices in disaggregated datacenters
EP2350836B1 (fr) Dispositif pour gerer des tampons de donnees dans un espace memoire reparti sur une pluralite d'elements de memoire
KR20090018068A (ko) 컴퓨팅 장치 및 컴퓨팅 장치 상에서 가상 머신을 구현하기 위한 컴퓨터 실행 가능 명령들을 저장한 컴퓨터 판독 가능 매체
CN114424172B (zh) 虚拟存储器元数据管理
JP2023538938A (ja) 共用可能なアプリケーションスナップショットの為のコンパイル化戦略
Healy et al. Single system image: A survey
US10802988B2 (en) Dynamic memory-based communication in disaggregated datacenters
Pemberton et al. Kernel-as-a-service: A serverless interface to gpus
US10409762B2 (en) Remote direct memory access-based on static analysis of asynchronous blocks
Wrede et al. Simultaneous CPU–GPU execution of data parallel algorithmic skeletons
US11650849B2 (en) Efficient component communication through accelerator switching in disaggregated datacenters
US11163713B2 (en) Efficient component communication through protocol switching in disaggregated datacenters
US10915493B2 (en) Component building blocks and optimized compositions thereof in disaggregated datacenters
JP2022531452A (ja) コンテナ画像の動的分散
Brodowicz et al. A non von neumann continuum computer architecture for scalability beyond Moore's law
US20240134698A1 (en) Serverless computing using resource multiplexing
US20240231925A9 (en) Serverless computing using resource multiplexing
Hong GPU-enabled Functional-as-a-Service
Henry et al. SOCL: An OpenCL Implementation with Automatic Multi-Device Adaptation Support
Schirmer Parallel Architecture Hardware and General Purpose Operating System Co-design
Vergilio et al. Non-Functional Requirements for Real World Big Data Systems
Krzyzanowski A taxonomy of distributed systems

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080526

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: DAVID, RAPHAEL

Inventor name: DAVID, VINCENT

Inventor name: VENTROUX, NICOLAS

Inventor name: COLLETTE, THIERRY

17Q First examination report despatched

Effective date: 20090409

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: COMMISSARIAT A L'ENERGIE ATOMIQUE ET AUX ENERGIES

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180424