• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention proposes a method for transferring at least one piece of data between a real-time task producing a datum (20) and a real-time consuming task (21) of said datum, each datum being associated with a date of visibility, the method being implemented in a computer (10) comprising a central memory (4), at least one processor (2) and at least one DMA direct access controller (3), each DMA controller (3) ) being configured to support data transfers between different areas of the main memory (4) under the control of an operating system (200) executed on the processors (2), characterized in that it comprises the following steps, in response to the initiation of the transfer of data by the current instance k of an initiating task (20, 21): - the creation (301) by the operating system (200) of minus a DMA descriptor to describe the expected DMA transfer for ladit e given after the execution of a given instance (k-1 or k) of the task; the insertion (302) by said operating system (200) of the DMA descriptors in a list of descriptors (26) awaiting processing by said DMA controller (3), said DMA descriptors being inserted in a sorted manner according to a sorting criterion relating to the date of visibility of the data and / or the temporal behavior of the tasks; Processing the descriptors of the DMA descriptor list (26) by executing DMA requests (303) by the DMA controller (3); and executing the following instance (k or k + 1) of the initiating task by the operating system (200) according to the termination of the processing of a predefined set of DMA descriptors of the descriptor list .
    公开号:FR3019339A1
    申请号:FR1452497
    申请日:2014-03-25
    公开日:2015-10-02
    发明作者:Mathieu Jan；Olivier Debicki
    申请人:Commissariat a lEnergie Atomique CEA；Commissariat a lEnergie Atomique et aux Energies Alternatives CEA；
    IPC主号:
    专利说明:

    [0001] BACKGROUND OF THE INVENTION The present invention generally relates to real-time systems and in particular to a method for transferring data between real-time tasks using a direct memory access controller. . Prior art Real-time systems, such as embedded or distributed systems, support applications that depend on the respect of the temporal constraints of the environment. In particular, in so-called "strict" real-time systems where the satisfaction of these time constraints is critical, the processes are grouped into different execution units that communicate with each other. The implementation of these communications between execution units (or tasks) is the responsibility of the underlying real-time operating system (designated by the acronym RTOS for the English expression "Realtime Operating System") , which is used for running multi-tasking applications. Two approaches exist to implement such an implementation of inter-task communications: - In a first approach, the RTOS explicitly implements the zo copies of necessary data through the use of memory copy functions (for example "memcpy" ); In a second approach, the RTOS delegates to a direct memory access controller (DMA) the implementation of the necessary data transfers and is informed only of the termination. transfers. The second approach allows to unload the processor from the execution of the data transfers and to release additional processor time to execute application processes. However, the delegation of data copies to the DMA controller has a fixed initial cost independent of the size of the data to be copied and the sequence of DMA requests required, which is a function of the memory organization of the executed application. For example, if using a DMA controller to transfer data is efficient from small or medium data sizes, this is not the case for very small data sizes. Moreover, the use of such a solution requires the establishment of a "contract" between the DMA controller responsible for copying the data and the designer of an application to ensure that the memory areas source and destination movements memories can no longer be modified by an application processing during the implementation of the transfer by the DMA controller. Various solutions are known for controlling interference due to the use in a strict real-time system of a DMA by a task to communicate with a device. Thus, some solutions are interested in the impact of the use of a task operating an input / output (I / O) via a DMA on the execution times "worst case" tasks running on a resource processor (eg in Tai-Yi Huang and Chih-Chieh Chou and Po-Yuan Chen.) Bounding the Execution Times of DMA I / O Tasks on Hard-Real-Time Embedded Systems 9th International Conference on Real-Time & Embedded Computing Systems and Applications, RTCSA 2003, Taiwan, February 2003). In a strict real-time system, these "worst-case" execution times must be known. However, a DMA can be programmed in CPU cycle flight mode (acronym for "Central Processing Unit", meaning literally "CPU") for the use of the memory bus, which can cause conflicts of access to the memory by the processor and thus delay the execution of application processes. Other solutions include the use of a DMA controller in strict real-time task scheduling tests, either explicitly through the inclusion of an additional task or by increasing worst case execution times. of each task (C. Pitter and M. Schoeber, Time Predictable CPU and DMA Shared Memory Access, International Conference on Field Programmable Logic and Applications, pp.317-322, August 2007). However, these solutions do not relate to the use of a DMA controller to operate between communicating real-time tasks data transfers having time constraints. Other solutions relating to optimizing the order of DMA requests with respect to their termination deadline are known. For example, US Pat. No. 7,917,667 B2 describes a method for calculating the priority of the different DMA requests and therefore of their order of execution by the DMA controller. The calculation of the priority of a DMA request is done physically and / or logicially relying in particular on the time initially estimated, the time taken and an arbitrary margin. This patent relates in particular to the DMA requests in which a termination deadline is specified. Such a method makes it possible to modify the priority of a DMA request according to its urgency (i.e. its actual progress with respect to its due date) compared to other current DMA requests. However, this document does not discuss data transfers between communicating real-time tasks implemented by DMA requests. Another solution proposed in US Pat. No. 3,925,766 relates to a DMA controller comprising a mechanism for periodically monitoring the use of a shared bus between computing resources and peripherals. This shared bus usage monitoring allows to allow or deny bus access for DMA requests from or to devices so as to share the bus proportionally with respect to the priority of the different requests. DMA. Famine situations that may exist in a conventional DMA controller where the priority of transfers is fixed statically and used to define the order of execution of transfers are thus avoided. This bus utilization monitoring mechanism is also used to detect whether the transfer is part of a real-time or non-real-time processing and accordingly to adjust the granularity of the data copied by a DMA request. Other solutions relating to DMA data transfer optimization relate to hardware extensions at the DMA level for linking the triggering of DMA requests to an event or dates. For example, WO 2007003986 proposes a method for programming temporally cyclic DMA tasks in order to carry out data transfers (DMA transfer process in a constant cycle). A temporally cyclic DMA task is a DMA task having a defined periodicity and each instance of this periodic task consists of a set of DMA requests, the number of DMA requests being dependent on the total size of the data to be transferred and the number of DMA requests. amount of data transferable in a DMA request. Using such types of DMA tasks to transfer data does not require interaction to program the DMA controller for each cycle. The priority of a DMA request can be dynamically adapted according to the deadlines associated with the transfers, if an arbitration policy taking into account the deadlines of the transfers is used. This document notably describes the use of three dates including the value of the current time, the departure date for the initialization of the transfer and a deadline. The deadline violation can be used by the DMA controller or a compute resource to implement different strategies, such as increasing the priority of a DMA request, stopping a DMA task, forcing the execution of DMA requests, etc. . Like the US Pat. No. 7,717,667 B2, this method makes it possible in principle to construct a system in which it can be demonstrated that DMA requests will be completed before a certain deadline. However, this solution does not solve the problem of data transfer between communicating real-time tasks implemented by DMA requests. Another solution proposed in US Pat. No. 8,266,340 B2 describes a hardware extension at the DMA controller to include a hardware time counter, a time counter value comparator and a state comparator with respect to the time counter. acquiring the state of a device using the DMA. On the basis of this information, after obtaining a correspondence between the time counter and the value entered in the time counter value comparator, the triggering of one or more DMA requests by the DMA controller is conditioned by obtaining a correspondence between the state of the device and the value entered in the status comparator. Such a method makes it possible to trigger DMA requests without requiring polling-type software operations ("polling" in the English language), and therefore the intervention of a computing resource, thus avoiding an additional load on this level. computing resource. Other solutions relating to the optimization of data transfers by DMA relate to hardware extensions to secure the execution of DMA requests. For example, US Pat. No. 7,523,229 B2 describes a solution in which a hardware extension for access control is associated with an input / output controller, provided with a DMA controller, and is programmable via two types of registers. . The first type of register is accessible by any application process to specify the destination or source address in a DMA request between the input / output device and the system memory (memory-device transfer). The second type of register describes the memory rights applicable to the memory zone specified in the first type of register. This second type of register is usable only in "privileged" execution mode, by a computing resource, that is to say by a code of confidence. The thus extended I / O controller can then detect any unauthorized memory access attempt during a DMA request and stop its execution. In yet another approach, described in patent US2005 / 0165783 A1, a hardware extension is proposed in which the logic for controlling access to the memory by the different masters of a bus (thus potentially including DMA controllers) is located at bus access level (and not at the input / output controller as in US Pat. No. 7,523,229 B2). The description table of the memory access rights is the responsibility of a privileged process, typically the operating system, and is filled during system startup. Similarly, the patent application WO 2009138928 A1 describes another organization of the necessary hardware extension via the use of the conventional mechanism of memory protection in an architecture not only for computing resources but for all the masters connected to the system. memory. Thus any memory access, whether from a computing resource or a DMA controller is controlled before being allowed or denied. Thus, there are a number of solutions to take into account the use of a DMA in the sizing and scheduling of real-time systems, and / or to ensure that data transfers by a DMA controller does not occur. do not alter the real-time constraints of the data, and / or secure data transfers by DMA. In the case where the approach used to implement inter-task communications relies on DMA controller, there is considerable latitude to transfer the data between the activation and the expiry of communicating tasks, which can lead to limited real-time system performance, over-provision of necessary resources, or system compromise if DMA requests are not executed appropriately and securely.
    [0002] GENERAL DEFINITION OF THE INVENTION The invention improves the situation by proposing a method for transferring at least one piece of data between a real time task producing a piece of data and a real time task consuming the piece of data, each item being associated with a date. of visibility. The method is implemented in a computer comprising a central memory, at least one processor and at least one DMA direct access controller, each DMA controller being configured to support data transfers between different areas. central memory under the control of an operating system running on said processors. The method comprises the following steps, in response to the initiation of the transfer of data by the current instance k of an initiating task: the creation by the operating system of at least one DMA descriptor to describe the expected DMA transfer for the data, after execution of a given instance (k-1 or k) of the task; the insertion by the operating system of the DMA descriptors into a list of descriptors waiting for processing by the DMA controller, the DMA descriptors being inserted in a sorted manner according to a sorting criterion relative to the visibility date of the DMA descriptors; data and / or temporal behavior of tasks; - Handling descriptors from the list of DMA descriptors by executing DMA requests by the DMA controller; and executing the following instance (k or k + 1) of the initiating task by the operating system according to the termination of the processing of a predefined set of DMA descriptors of the descriptor list.
    [0003] In some embodiments, the method may include a step of verifying by the operating system the termination of the processing of the predefined set of DMA descriptors in the list. In a first embodiment, the initiating task may be a data producing task, the step of creating the DMA descriptors being triggered in response to the termination of the execution of the current instance k of the initiating task.
    [0004] The sorting criterion can then be the visibility date associated with the data to be transferred. In this first embodiment, the set of descriptors may comprise the DMA descriptors that have a visibility date less than or equal to the activation date of the next instance of the initiating task, and that the step verification is carried out by determining whether the descriptors of said set are associated with end of processing information. In a second embodiment, the initiating task is a data consuming task, the DMA descriptor creating step then being triggered in response to the termination of the execution of the previous instance (k-1) of the task initiator. The sorting criterion can then be the expiry date of the current instance k of the initiating task. In the second embodiment, the set of descriptors comprises all the DMA descriptors created at the creation stage, while the verification step is implemented by determining whether the descriptors of the set are associated with the set of descriptors. end of treatment information. The insertion step may further include temporarily suspending the DMA requests being executed by the DMA controller, wherein the suspend time is used by the operating system to update the list of DMA descriptors. The method may further include a termination step in which the status bits of the DMA descriptors processed in the execution step by the DMA controller are set to indicate the end of processing of the DMA descriptors. The method may also comprise a notification step in which the DMA controller notifies the operating system of the end of the data transfers within the central memory, the operating system being able to store the information of the end of transfers in a memory. data structure in the form of a list of completed data transfers.
    [0005] According to another characteristic of the invention, the verification step on a datum can be delayed until the first moment of use by the task of the memory zone storing the datum.
    [0006] In one embodiment, the computer may comprise at least one hardware memory protection mechanism associated with the DMA controller for securing the data transfers by programming via hardware registers accessible by the processor, the method comprising: at the step of insertion of the DMA descriptors, the programming of the hardware registers with the memory rights necessary to carry out the transfer of the data; or - during the detection of an invalid access by the memory protection hardware mechanism, verifying that the corresponding memory access belongs to one of the DMA descriptors created in the creation stage for the transfer of the data and the programming of the data. memory protection equipment registers with the memory rights necessary to carry out the transfer of the data. In another embodiment, the computer may comprise at least one hardware memory protection mechanism associated with the DMA controller for securing data transfers and using memory descriptors provided to it by means of extensions in the data format. a DMA descriptor for including the description of the authorized memory rights for the DMA requests associated with the DMA descriptor, said memory rights being used at the execution step by the DMA controller to program the memory protection hardware mechanism with the necessary memory rights of to carry out the transfer of the data. The invention also provides a calculator comprising a central memory, at least one processor and at least one DMA direct access controller, each DMA controller being configured to support data transfers between different areas of the memory. central memory under the control of an operating system executed on said processors, the computer being configured to transfer at least one piece of data between a real time task producing a piece of data and a real time task consuming the piece of data, each piece of data being associated with a visibility date. In response to the initiation of the transfer of data by the current instance k of an initiating task: the operating system is able to create at least one DMA descriptor to describe the expected DMA transfer for the data, after executing a given instance of the task (k-1, k) and inserting DMA descriptors into a list of descriptors waiting for processing by the DMA controller, the DMA descriptors being sorted in accordance with a sorting criterion relating to the date of visibility of the data and / or the temporal behavior of the tasks; - The DMA controller is configured to handle the descriptors of the DMA descriptor list by executing DMA requests; the operating system being further configured to execute the next instance (k, k + 1) of the initiating task according to the termination of the processing of a predefined set of DMA descriptors of the descriptor list. The proposed embodiments thus make it possible to schedule and optimize the transfer of data, between communicating real-time tasks, relying on a DMA controller, from a temporal behavior model of the tasks, while ensuring the respect of the deadlines associated with the system. In addition, the proposed embodiments can secure data transfers. The various processors are thus relieved of the explicit management of the memory transfers, which makes it possible to release additional processor time for executing application processes. This results in an optimization of the use of the execution resources for the design of real-time systems and in particular of "strict" real-time systems. BRIEF DESCRIPTION OF THE DRAWINGS Other features and advantages of the invention will become apparent with the aid of the description which follows and the figures of the appended drawings in which: FIG. 1 is a diagram showing the architecture of a calculator, according to some embodiments; FIG. 2 is a diagram representing the interactions between real communicating tasks; FIG. 3 is a flowchart of the data transfer method, according to some embodiments of the invention; FIG. 4 illustrates the transfer method for a real-time task producing a datum, according to an exemplary embodiment of the invention; and FIG. 5 illustrates the transfer method for a real-time task consuming a piece of data, according to another exemplary embodiment of the invention. FIG. 1 schematically represents the elements of the architecture of a computer 10 according to some embodiments. The computer 10 comprises one or more processors 2, one or more DMA controllers 3 and a central memory 4. The processors 2 and the DMA controllers 3 are connected by an interconnection network 5 in order to communicate with each other. The processors 2 and the DMA controllers 3 constitute controllers that can act as masters on the interconnection network 5 of the architecture, that is to say initiate requests on this network. Conversely, the central memory 4 and the input / output peripherals (not shown) are considered to be slaves of the interconnection network 5 that can not be the source of requests on this network. The following description will be made with reference to a computer comprising a single processor 2 executing a multi-tasking system and a DMA (Direct Memory Access) controller, by way of non-limiting example and to facilitate the understanding of the invention. . It should be noted that Figure 1 is a simplified representation of the calculator 10 on which appear only the elements 2, 3, 4 and 5 to facilitate understanding of the invention. However, those skilled in the art will readily understand that the computer 10 may comprise other conventional elements such as input / output devices, a memory hierarchy (cache) and that the invention is not limited to a computer comprising a single processor 2 and a single DMA controller 3. Each DMA controller 3 is configured to support data transfers between different areas of the main memory 4 (these data transfers are still called memory-to-memory transfers), under control. an operating system run on the processors 2. For each data item, the operating system has the particular function of preparing one or more transfer requests by filling in one or more DMA descriptors. Each DMA descriptor is then inserted into the list of DMA descriptors of the DMA controller 3 to be processed by the DMA controller 3. The DMA controller then processes the DMA descriptors by executing for each DMA descriptor one or more DMA requests, the number of requests. DMA depending on the functionality of the controller 3. The architecture of the computer 10 may include in particular one or more hardware protection mechanisms 6, MMU type (acronym for "Memory Management Unit" meaning literally Memory Management Unit) or MPU ( an acronym for "Memory Protection Unit" meaning literally Memory Protection Unit), to protect access to the interconnection network 5 that can be realized by one or more masters of such an architecture. Such mechanisms make it possible, for example, to guard against erroneous or malicious behavior of a master vis-à-vis access to the central memory 4. The appropriate use of such memory protection mechanisms can in particular guarantee the Isolation between the different processes that masters can perform on an interconnection network 5. In some embodiments, the data transfer method can rely on the appropriate programming of such a hardware memory protection mechanism. associated with a DMA controller 3 to isolate the memory transfers necessary for transferring data between communicating real-time tasks. Figure 2 illustrates the data transfer in a multi-tasking system composed of communicating real-time tasks. A communicating real-time task is a task that has time constraints, that is, activation dates and deadlines, and that exchanges one or more data with one or more other communicating real-time tasks. The transfer of data between communicating real-time tasks can be initiated either by the task producing the data 20 or by a task consuming the same data 21. There may be several consuming tasks 21. However, it is advantageous to have a single producer task for data to avoid data consistency problems. Each instance of a real-time task is associated with an activation date 23 and a deadline 25. Activation date 23 corresponds to the date from which the task instance is eligible for access to a job. processor 2 to be executed by the operating system. Deadline 25 is the date by which the task instance must be completed. The temporal behavior of a given real-time task thus designates all the activation dates and deadlines for all its instances. Furthermore, each datum 22 can be associated with a visibility date 24 corresponding to the date from which this datum is made visible to the consuming tasks 21 to be used in application processes. The visibility date 24 of a datum is generally greater than or equal to the deadline 25 of the task producing this datum.
    [0007] When an instance of a data producing task terminates its execution, the data can no longer be changed by the producer task 20 and one or more DMA descriptors 26 are created by the operating system 200 to describe the data. data transfers to be performed by the DMA controller 3. The manner in which the list of DMA descriptors 26 is stored may depend on the underlying implementation (hardware and RTOS). The data transfer method may be initiated by a data producing task or alternatively by a data consuming task 21 (the producing or consuming task 21 which initiates the transfer may be commonly referred to hereinafter as " initiating task ").
    [0008] According to a characteristic of the invention, when the transfer is initiated by a producer task 20, the DMA descriptors 26 are inserted in a sorted manner according to the deadline associated with the instance of the producer task 20 by the system. 200 in a list of DMA descriptors for processing by the DMA controller. The DMA controller then generates the DMA requests to be executed from the descriptor list to transfer the data. Before executing the next instance of the producing task 20, the operating system 200 checks whether the DMA controller 3 has processed the different DMA requests of the DMA descriptors created by the producing task 20 whose visibility date 24 is less than the activation date 23 of the current instance of the producing task 20 (the activation corresponds to the instant from which the instance of the task can potentially execute). If the various DMA requests are not all completed, an error can be notified to the system. Moreover, according to the temporal behavior of the tasks, several instances of the producing task can be activated / executed before reaching the date of visibility of a piece of data: the identification of the state of the DMA requests associated with this datum (in running or waiting for execution) then makes it possible to optimize the transfer of the data by potentially avoiding the execution of unnecessary DMA requests. It should be noted that if the DMA 3 controller is configured to verify that the execution of a DMA request is completed by a certain date, this feature can optionally be used with the DMA request dates as the visibility dates for the DMA requests. associated data. The verification step of the DMA request termination can then: - either consist in verifying that no violation of deadline has been detected during the execution of the DMA requests, if the DMA controller is configured to inform only the state DMA requests by setting status bits provided for this purpose, or - not to be implemented, if the DMA controller is configured to notify an error via an interrupt to the processor when a time violation is detected during of performing a DMA query. A data consuming task can also be initiating DMA data transfers. In this case, the DMA descriptors 26 are created at the end of the execution of the preceding instance k-1 of the consuming task by the operating system 200. The DMA descriptors created are inserted in a sorted manner according to the 25 expiry associated with the current instance k of the consumer task 21 initiating transfers, by the operating system 200 on the activation date 23 of the consumer task (or "release date" in English language) for be processed by the DMA controller 3 and thus generate the DMA requests needed to transfer the data. This deadline 25 of the task does not correspond to the date of visibility of the data but makes it possible to specify an order between the different DMA requests resulting from the processing of the DMA descriptors 26 by the DMA controller 3 in a multi-tasking system. Before the actual execution of the current instance k of the consuming task 21, the operating system 200 verifies the termination of the set of initiated DMA requests. This ensures in particular that the DMA transfers are completed before any use of the data by an application. In some embodiments, regardless of the nature of the initiating task of the DMA transfers (producer or consumer), the verification of the termination of the DMA requests can be delayed until the moment when the data is modified by the instance routine of the initiating task, for example by using a suitable programming interface. This makes it possible to extend the length of the time interval during which the execution of DMA requests is possible to transfer data by DMA. On the other hand, in particular embodiments, the information that DMA requests requested by the instance of the initiating task are not completed can be used by the scheduler of an operating system 200 as additional information for delay the execution of the instance of this task (initially equal priority between two tasks), regardless of the nature of the initiating task of transfers by DMA (producer or consumer).
    [0009] In an alternative embodiment of the transfer method and when the initiating task is a consuming task, the insertion step of a DMA descriptor can be anticipated on the date of visibility 24 of the data, which also makes it possible to extend the length of the time interval during which the execution of the DMA requests is possible if the activation date 23 of the consuming task is strictly subsequent to the date of visibility 24 of the data. It should be noted that the different embodiments of the execution method implemented by the producing task and the consuming task can be combined in order to obtain a multi-tasking system based on a DMA controller 3 for the transfer. data between real-time tasks. Advantageously, if the data transfer is carried out in several stages requiring a transfer initiated by a producer task and then a transfer initiated by a consuming task, the step of inserting a DMA descriptor by a consuming task can be anticipated at the moment. the termination of the DMA transfer initiated by the producing task to extend the length of the time interval during which the execution of DMA requests initiated by the consuming task is possible.
    [0010] It should also be noted that the various embodiments of the execution method can be applied alternatively to a subset of the different data that can be exchanged different tasks of an application. Such a subset may be selected according to different selection criteria, for example depending on the size of the data.
    [0011] Optionally and independently of the nature of the initiating task of the DMA transfers (producer or consumer), the static knowledge of the various inter-task data exchanges makes it possible to program a memory protection hardware device associated with the DMA controller 3. According to the capabilities of such a hardware memory protection device 6 associated with the DMA controller 3, securing data transfers between communicating tasks can be achieved in different ways. In one embodiment, the computer 10 may use a memory protection device 6 which is programmable via registers accessible by the processors 2. For each transfer, one or more registers of the memory protection hardware 6 associated with the DMA controller may be indicated. by the initiating task of the DMA transfer to describe the memory rights applicable for the transfer of data between a source memory zone and a destination memory zone. It should be noted that, in such an embodiment, the insertion of a DMA descriptor in the list of DMA descriptors DMA 3 is then dependent on the number of registers of the memory protection equipment 6 that are available (their number being limited). If this number is insufficient to describe the memory rights applicable to the data transfer, the DMA descriptor is put on hold. When the processing of all the DMA requests linked to a DMA descriptor is completed, the registers of the memory protection hardware 6 used are considered as free, that is to say they can be reused to describe the memory rights for other transfers of data. If one or more DMA descriptors are waiting for processing, it is checked whether they can be inserted in the list of DMA descriptors according to the release of registers of the memory protection equipment 6. In another embodiment, Instead of performing memory rights changes when inserting a DMA descriptor (as the embodiment described above), memory rights changes may occur when invalid memory access is detected by the mechanism. memory protection hardware 6 during the execution of DMA requests. In such an embodiment, the operating system 200 then checks whether the executed DMA request and initiator of the invalid memory access corresponds to a valid DMA descriptor.
    [0012] If the memory rights of this DMA descriptor are not already entered at the level of the memory protection mechanism 6, registers of the memory protection equipment 6 are indicated by the operating system 200, if a sufficient number of these registers of the hardware of 6 memory protection are available. Otherwise, the DMA descriptor is put on hold for further processing when the necessary number of registers of the memory protection hardware 6 is reached. If the memory rights of the DMA descriptor are already filled in the memory protection mechanism 6, the memory access is then considered to be really invalid. In yet another embodiment, the values to be applied to the memory protection hardware registers 6 used by the DMA controller 3 may be provided to the memory protection hardware 6, by means of extensions in the format of a DMA descriptor. . Thus, a DMA descriptor further comprises, for example source and destination memory addresses and the size of the memory area to be transferred, the memory rights associated with these memory areas.
    [0013] The DMA controller 3 can then initiate memory rights changes associated with a DMA descriptor without requiring the intervention of the operating system 200, unlike conventional solutions for securing transfers by DMA. The processors 2 are thus discharged from the implementation of this secure transfer by DMA. The memory rights associated with the DMA requests can be previously calculated by an application-independent device and implemented using a confidence code, such as for example when editing the application links by analyzing the application requirements. relative to the different memory areas of the binary of the application. Thus, the application is not able to appropriate additional memory rights. The following description of some embodiments may thus be based on some of the following assumptions: - according to a first hypothesis, it can be assumed that the temporal behavior of the tasks constituting an application, that is to say the dates activation 23 (also called "release date" in English language) and the deadlines 25 of the different instances of the tasks, is known in advance (knowledge offline). Generally, most strict real-time systems satisfy such an assumption because of the certification constraints that apply in their areas of use and that require the provision of a work scheduling demonstration to prove compliance with the requirements. real-time tasks of their temporal constraints, for example by analyzing the "worst case" response times; According to a second hypothesis, it can be assumed that a mechanism of the DMA type is able to implement interruptible memory transfers with stop in a coherent state and allowing a subsequent recovery from this coherent state, as is the case for the most DMA controllers; In a very optional way, according to a third hypothesis, it may be considered that the DMA controller 3, by definition able to act as master on the interconnection infrastructure of the components of a hardware card, is associated with a memory protection mechanism. dedicated, having a limited number of memory descriptors potentially active at a given time and to describe the memory rights (reading, writing, etc.) of memory areas. Programming such a memory protection mechanism makes it possible to control and prohibit certain memory accesses to the DMA controller, so as to avoid the propagation of errors from the DMA controller to the system memory. However, those skilled in the art will understand that the proposed embodiments do not depend on such memory protection mechanisms that can be used in particular to ensure a property of non-propagation of errors of an erroneous use or a material defect of the device. DMA controller, and therefore to ensure the security of data transfers implemented by a DMA controller; According to a fourth hypothesis, it can be considered that the configuration of the different memory descriptors necessary to authorize the data transfers between the tasks of an application are calculable before the execution of the system. Such an assumption is generally satisfied in the strict real-time systems because of the certification constraints which impose a static knowledge of the behavior of the tasks, notably the exchanges of data between tasks. FIG. 3 is a flow chart showing in more detail the data transfer execution method (hereinafter also called "data transfer method") between communicating real-time tasks implemented within the central memory of the computer 10 according to some embodiments. The method for executing DMA data transfers is based in particular on the use of the temporal behavior of the tasks for the transfer of data between real-time tasks based on a DMA controller, which makes it possible to improve the performances of the real-time system in which it is implemented or conversely to decrease the resources necessary for equal performance. In step 301, one or more DMA descriptors are created by the operating system 200. The descriptors are used to specify the data transfers to be performed by DMA. They include the source and destination memory addresses and the size of the memory area to be transferred. The general format of the DMA descriptors may depend on the type of controller 3 used. Moreover, the number of DMA descriptors created may depend on various parameters or criteria, such as, for example, the capacity of the DMA controller 3, the size of the data, etc.
    [0014] The data transfer method may be initiated by a data producing task or alternatively by a data consuming task 21. If the initiating task is a data producing task 20, creating DMA descriptors at step 301 is performed once the application code of the current instance k of the producing task 20 is executed. If the initiating task is a data consuming task 21, the creation of DMA descriptors in step 301 is performed after the application code of the previous instance k-1 of the consuming task 21 is executed. In step 302, the DMA descriptors describing the data transfers to be performed Io are inserted by the operating system 200 into the list of DMA requests to be processed by the DMA controller 3, thus transferring the responsibility of the DMA descriptors between the processor 2 and the DMA controller 3. If the initiator task is a producer task 20, step 302 is performed immediately after step 301. If the initiator task is a consuming task 21, step 302 is performed at the activation date of the instance k of the consuming task 21. Advantageously, the DMA descriptors are inserted in a sorted manner, according to a sorting criterion relating to the date of visibility 24 of the data and / or the temporal behavior of the data. tasks. In particular, the DMA descriptors are inserted in a sorted manner, depending on the date of visibility 24 of the data (ie the list of DMA requests is thus ordered according to an order chosen according to the date of visibility of the data) if the process is performed at the initiative of a data-generating task 20. Alternatively, if the method is executed on the initiative of a data-consuming task 21, the DMA descriptors are inserted sorted according to the expiry date. of the consuming task. Depending on the capabilities of the DMA controller, step 302 may be implemented by hardware elements of the DMA controller or by software elements or a combination of both. The DMA request being executed by the DMA controller 3 may be temporarily suspended if updating the DMA descriptor list determines that another DMA descriptor has a higher priority than the descriptor currently being processed. The implementation of such a suspension of DMA requests depends in particular on the specificities of the DMA controller used. In embodiments where this step is implemented at the software level, the DMA controller may be temporarily suspended, i.e. DMA descriptor responsibility is transferred to a processor 2, when the operating system 200 begins executing the processing code to update the list of DMA descriptors. Such an update is intended to allow the execution of this code on a frozen state of the different DMA descriptors waiting for processing by the DMA controller 3. It should be noted that the criterion used to sort the DMA descriptors can also be advantageously used in a method for detecting the violation of a deadline by a DMA request resulting from the processing of the DMA descriptors. In the embodiments where the transfer method is at the initiative of a consuming task 21, the order of execution of the DMA requests is a function of the expiry of the real-time tasks consuming data. In the embodiments in which a hardware memory protection mechanism 6 associated with the DMA controller 3 is used by the computer 10 to secure the DMA transfers and that it is programmed during the insertion of the DMA descriptors into the step 302, the number of inserted DMA descriptors is also a function of the number of registers available in the memory protection hardware mechanism 6 associated with the DMA controller. The descriptors not inserted in step 302 can then be put on hold by the DMA controller controller 3. In the embodiment where the values for the registers of the memory protection mechanism 6 are provided to it by means of extensions in the format of a DMA descriptor, the format of a DMA descriptor is extended with the description of the memory rights on the space memory areas accessible by the DMA controller to process this DMA descriptor. In addition, if the number of DMA descriptors inserted is less than the number of DMA descriptors created in step 301 (the list of DMA descriptors DMA controller being of bounded size), steps 302, 303 and 304 can be repeated until that enough entries in the list of DMA descriptors DMA 26 are released to process the DMA descriptors put on hold.
    [0015] In step 303, the DMA descriptors are processed by the DMA controller 3 by executing DMA requests. In the embodiment where a hardware memory protection mechanism 6 associated with the DMA controller 3 is used to secure the data, and receives the values for the memory protection mechanism registers 6 by means of extensions in the format of a DMA descriptor, the execution of a DMA request in step 303 may optionally include a positioning on the memory protection mechanism 6 memory rights described in the DMA descriptor. Alternatively, if a hardware memory protection mechanism 6 is used to secure the DMA transfers so as to change the memory rights only when the memory protection mechanism 6 detects an invalid memory access, the execution of a DMA request can thus result in invalid access detection. In this case, the operating system 200 checks whether the DMA request corresponds to an authorized DMA descriptor and reprograms the memory rights of the memory protection hardware mechanism 6 with the memory rights of this DMA descriptor, if these rights are not already specified. at the level of the memory protection mechanism 6, so that the DMA request (s) can take place. If they were already filled in, the memory access is really invalid. In step 304, the DMA controller 3 sets a status bit in each DMA descriptor to indicate that a DMA descriptor has been processed in step 303, i.e., the set of DMA requests. from this DMA descriptor are executed. In addition, it can notify the operating system 200, in step 304, of the end of the data transfers within the main memory 4. If it is not intended to program the behavior of the DMA controller for notifying the end of processing of each DMA descriptor in an implementation of this method, the released entries in the DMA descriptor list of the DMA controller can not be used immediately for other data transfers. DMA descriptors can then only be used after the verification step 305 of their processing. In the embodiment where DMA descriptor completion notifications are issued in step 304, a data structure may be used by the operating system 200 to store a list of the transfers of the processed descriptors. In particular, the notification of step 304 can be triggered according to a predetermined number of DMA descriptors processed by the DMA controller and / or as a function of a delay from the processing of a descriptor before the sending of the notification (with reset at the end of processing of the DMA descriptor). In step 305, the operating system 200 verifies the termination of the DMA transfers of the data, before triggering the execution of the next instance of the initiating task (next instance k + 1 for a type initiator task). producer or current instance k for a consumer-type initiator task). For this, the operating system 200 can check, in the embodiment where the DMA controller is not programmed to notify the end of processing DMA descriptors: - for an initiator task of type producing task 20, if the descriptors DMAs used for the transfer of data having a visibility date 24 less than or equal to the activation date of the producing task 20 have status bits indicating the end of processing, in which case the execution of the next instance k + 1 can be initiated, or - for an initiator task of consuming task 21, if all the DMA descriptors created in step 301, for a consuming task 21, have status bits indicating the end of processing, in which case the execution of the current instance k can be initiated. Alternatively, in the embodiment where the DMA controller is programmed to notify the end of processing of the DMA descriptors, the operating system 200 can check: - for a producer task type initiator task 20, whether the DMA descriptors used for data transfers having a visibility date 24 less than or equal to the activation date of the producing task 20 are fully present in the data structure of the processed descriptors, in which case the execution of the next instance k + 1 can be initiated, or - for an initiator task of consuming task type 21, if all the DMA descriptors created in step 301, for a consuming task 21, are integrally present in the data structure of the descriptors processed, in which case the execution of the current instance k can be initiated. According to yet another variant of the embodiment where the DMA controller is configured to monitor the respect of the deadlines associated with the DMA descriptors, the step 305 can: - either consist in checking, for a producer-type initiator task, that no violation deadline has been detected, if the DMA controller is configured to fill only the state of the DMA requests by setting status bits for this purpose, or - not to be implemented, if the DMA controller is configured to notify an error via an interrupt to processor 2 when a time violation is detected. In a particular embodiment, the verification of step 305 on a datum can be delayed until the first moment of use by the application code of the task of the memory area storing this datum, whether for a production task 20 or consumer 21. In another embodiment, the information that DMA requests associated with DMA descriptors requested by a consuming or producing task are uncompleted (such information being determined if the condition of step 305 is not verified for certain DMA descriptors) can be passed in addition to the scheduler of the tasks of the operating system 200. The task scheduler can then use this information on uncompleted transfers as an additional decision criterion to determine the order of the tasks to be performed.
    [0016] If the condition of step 305 is not satisfied, an error is detected. The additional steps that can be executed in this case depend on the field of origin of the application. Such complementary steps may include, for example, the execution of the tasks, despite the detected error, with well-defined values, the stopping of these tasks, etc. The date of visibility 24 of each datum, which is a function of the execution model of the real-time tasks, can be provided beforehand and stored in memory for later use when a transfer by DMA is implemented. Embodiments of the invention thus provide an optimal solution for transferring data between real-time tasks based on a DMA controller. Such a solution may also be adapted to secure data transfers between communicating tasks so as to identify and / or contain any operating anomalies of a DMA controller, when the computer 10 comprises at least one associated memory protection mechanism 6 To the DMA controller 3. Although not limited to such applications, the computer 10 and the data transfer method according to the various embodiments of the invention are particularly suitable for use in "hard" real-time systems where it is necessary to provide the ability to demonstrate the proper functioning of the DMA memory controller for the implementation of data transfers. The execution method thus makes it possible to unload the processor of the copies of said data by using the DMA controller to execute the real-time tasks while allowing to check the respect or not of temporal constraints applicable to these exchanges and, optionally , by securing these exchanges. It should be noted that the flowchart of Fig. 3 is a simplified view of the execution method and that some additional steps may be provided depending on the pattern of task execution and inter-task communications. Although the method of Figure 3 is described for transferring data between real-time tasks of an application, it applies similarly to any subset of data to be transferred between such tasks. The set of data to which the execution method applies may be previously defined by the application designer according to various parameters such as, for example, the quantity and frequency of production of the different data, and / or the capacity DMA controllers in terms of the number of possible transfers. The above description of some embodiments of the data transfer execution method has been made with reference to a single communication channel of a DMA controller shared between all the tasks of a given application. However, the invention applies similarly regardless of the implementation-dependent capabilities of multiplexing different DMA requests by a DMA controller via the notion of communication channels.
    [0017] In particular, the method of executing data transfers applies similarly by distributing the data transfers on all the communication channels offered by a DMA controller or part of these channels. Figure 4 is an exemplary implementation of the data transfer execution method, in an embodiment where the instance k of a producer real time task initiates the method for transferring data A. As shown in FIG. In the example of FIG. 4, the producing task 20 is associated with: an activation date 23 for the instance k of the task; A timeout 25 for the instance k of the task corresponding to the activation date 23 for the instance k + 1 of the task and the date of visibility 24 of the data item A. The data transfer is carried out according to the following steps: - The operating system 200 creates a DMA descriptor for the data item A after the instance k is executed (301) and inserts it in a sorted manner according to the date of visibility 24 of the data item A in the list of DMA descriptors (302); - The operating system 200 may possibly ask to suspend a DMA request associated with a DMA descriptor whose deadline 25 is greater than the date of visibility 24 of the data A; The DMA controller executes the DMA requests (303) according to the list of updated DMA descriptors; - The DMA controller notifies the completion of the execution of DMA requests (304) to the operating system 200 and the possibly suspended DMA request can be resumed; The operating system 200 verifies that the DMA descriptors have been processed (305) before initiating the execution of the k + 1 instance of the task. FIG. 5 is another example of implementation of the data transfer execution method, in an embodiment where the instance k of a consuming real time task initiates the method for transferring data A. As shown in FIG. 5, the consuming task 21 is associated with: an activation date 23 for the instance k of the task corresponding to the visibility date 24 of a data item C; - A deadline 25 for the instance k of the task. The transfer of the data is carried out according to the following steps: the operating system 200 creates a DMA descriptor for the data C once the k-1 instance of the consuming task is executed (301) and inserts it sorted, according to the expiry 25 of the instance k of the consuming task, in the sorted list of DMA descriptors (302) at the activation of the instance k; - The operating system 200 may possibly suspend another DMA transfer whose associated deadline is greater than the expiry of the instance k of the task consuming the data C; - The DMA controller executes the DMA requests (303) according to the list of updated DMA descriptors; - The DMA controller notifies the completion of the execution of DMA requests (304) to the operating system 200 and the possibly suspended DMA request can be resumed; The operating system 200 verifies that the DMA descriptors have been processed (305) before initiating the execution of the current instance k of the consuming task.
    [0018] Thus, in the embodiments where the transfer is initiated by a consuming task 21, the DMA transfer takes place between the activation and the execution of the instance k whereas in the embodiments where the transfer is initiated by a producing task 20, the transfer by DMA takes place between the expiry of the instance k and the execution of the instance k + 1. Embodiments of the invention thus make it possible to schedule and optimize data transfers between communicating real-time tasks, relying on a DMA controller, based on the temporal behavior model of the tasks, while ensuring the meeting the deadlines associated with the system and, if necessary, securing their transfer. The different processors 2 can therefore be unloaded from the explicit management of the memory transfers. The additional processor time that is thus released can be devoted to the execution of various application processes. The use of runtime resources is therefore optimized for strict real-time system design. Those skilled in the art will understand that the data transfer execution method can be implemented in a variety of hardware or software or hardware and software combinations. The invention is not limited to the embodiments described above by way of non-limiting example. It encompasses all the embodiments that may be envisaged by those skilled in the art. In particular, the invention is not limited to a particular type of DMA processor or controller, nor to particular multiplexing capabilities of different DMA requests by a DMA controller via communication channels.
    权利要求:
    Claims (15)
    [0001]
    REVENDICATIONS1. Method for transferring at least one datum between a real time task producing a datum (20) and a real time consuming task (21) of said datum, each datum being associated with a date of visibility, said method being implemented in a computer (10) comprising a central memory (4), at least one processor (2) and at least one DMA direct access controller (3), each DMA controller (3) being configured to take supports data transfers between different areas of the main memory (4) under the control of an operating system (200) executed on said processors (2), characterized in that it comprises the following steps, in response at the initiation of the transfer of data by the current instance (k) of an initiating task (20, 21): the creation (301) by the operating system (200) of at least one descriptor DMA to describe the expected DMA transfer for said datum, after at the execution of a given instance (k-1, k) of the task; the insertion (302) by said operating system (200) of the DMA descriptors in a list of descriptors (26) awaiting processing by said DMA controller (3), said DMA descriptors being inserted in a sorted manner according to a sorting criterion relating to the date of visibility of the data and / or the temporal behavior of the tasks; Processing the descriptors of said list of DMA descriptors (26) by executing DMA requests (303) by the DMA controller (3); and executing the following instance (k, k + 1) of the initiating task by the operating system (200) according to the termination of the processing of a predefined set of DMA descriptors of said list of descriptors .
    [0002]
    2. Method according to claim 1, characterized in that it comprises a step of verification (305) by the operating system (200) of the termination of the processing of said predefined set of DMA descriptors of said list.
    [0003]
    3. Method according to one of the preceding claims, characterized in that the initiating task is a data producing task (20), in that the step of creating the DMA descriptors (301) is triggered in response to the termination of the execution of the current instance (k) of the initiating task (20).
    [0004]
    4. Method according to claim 3, characterized in that said sorting criterion is the visibility date (24) associated with the data to be transferred.
    [0005]
    5. Method according to one of claims 2 to 4, characterized in that said set of descriptors comprises the DMA descriptors which have a visibility date (24) less than or equal to the date of activation of the next instance of the initiating task (20), and in that the verification step (305) is implemented by determining whether the descriptors of said set are associated with the end of processing information.
    [0006]
    6. Method according to one of claims 1 and 2, characterized in that the initiating task is a data consuming task (20), in that the step of creating the DMA descriptors (301) is triggered in response to the terminating the execution of the previous instance (k-1) of the initiating task (21). 15
    [0007]
    7. Method according to claim 6, characterized in that the sorting criterion is the due date (25) of the current instance (k) of the initiating task (21).
    [0008]
    8. Method according to one of claims 6 and 7, characterized in that said set of descriptors comprises all DMA descriptors created in the creation step (301), and in that the verification step (305) ) is implemented by determining whether the descriptors of said set are associated with end of processing information.
    [0009]
    9. Method according to one of the preceding claims, characterized in that said insertion step (302) further comprises the temporary suspension of the DMA requests being executed by the DMA controller (3), said suspension time. being used by the operating system (200) to update the list of DMA descriptors.
    [0010]
    Method according to one of claims 2 to 9, characterized in that it further comprises a termination step (304) in which the status bits of the DMA descriptors processed in the execution step (303) by the controller DMA (3) are set to indicate the end of DMA descriptor processing.
    [0011]
    11. Method according to one of claims 1 to 9, characterized in that it further comprises a step (304) of notification in which the DMA controller (3) notifies the operating system (200) the end of transfers in the central memory (4) and in that the operating system (200) is able to store end of transfer information in a data structure in the form of a list of completed data transfers .
    [0012]
    12. Method according to one of the preceding claims 2 to 11, characterized in that the verification step (305) on a data is delayed until the first moment of use by the task of the memory area storing the data.
    [0013]
    13. Method according to one of the preceding claims, characterized in that the computer (10) comprises at least one memory protection hardware mechanism (6) associated with the DMA controller for securing the data transfer by programming via hardware registers accessible by said processor (2), said method comprising: - in the step of inserting the DMA descriptors (302), programming the hardware registers with the memory rights necessary to carry out the transfer of said data; or - when detecting an invalid access by the memory protection hardware mechanism (6), verifying that the corresponding memory access belongs to one of the DMA descriptors created in the creation step (301) for the transfer of memory said data and the programming of the memory protection hardware registers with the memory rights necessary to carry out the transfer of said data.
    [0014]
    14. Method according to one of claims 1 to 12, characterized in that the computer (10) comprises at least one memory protection hardware mechanism (6) associated with the DMA controller for securing transfers of data and using descriptors memories provided to it by means of extensions in the format of a DMA descriptor to include the description of the authorized memory rights for the DMA requests associated with the DMA descriptor, said memory rights being used in the execution step (303) by the DMA controller to program the memory protection hardware mechanism (6) with the necessary memory rights so as to carry out the transfer of said data.
    [0015]
    A computer (10) comprising a central memory (4), at least one processor (2) and at least one DMA direct access controller (3), each DMA controller (3) configured to take supports data transfers between different areas of the main memory (4) under the control of an operating system (200) executed on said processors (2), the computer being configured to transfer at least one piece of data between a task real time producing a datum (20) and a consuming real time task (21) of said datum, each datum being associated with a visibility date, characterized in that, in response to the initiation of the transfer of a datum, given by the current instance (k) of an initiator task (20, 21): the operating system (200) is able to create at least one DMA descriptor to describe the expected DMA transfer for said datum, after the execution of a given instance of the task (k-1 , k) and for inserting (302) DMA descriptors in a list of descriptors (26) awaiting processing by said DMA controller (3), said DMA descriptors being inserted sorted in accordance with a relative sorting criterion at the date of visibility of the data and / or the temporal behavior of the tasks; The DMA controller (3) is configured to process the descriptors of said list of DMA descriptors (26) by executing DMA requests (303); and in that the operating system (200) is further configured to execute the next instance (k, k + 1) of the initiator task according to the termination of the processing of a predefined set of DMA descriptors of said list of descriptors.
    类似技术:
    公开号 | 公开日 | 专利标题
    US8959484B2|2015-02-17|System for hosted, shared, source control build
    EP3123344B1|2017-12-13|Method for data transfer between real-time tasks using a dma memory controller
    US8458688B2|2013-06-04|Virtual machine maintenance with mapped snapshots
    US10325078B2|2019-06-18|Software license management impact analysis
    US9128773B2|2015-09-08|Data processing environment event correlation
    US8321558B1|2012-11-27|Dynamically monitoring and modifying distributed execution of programs
    EP1337919B1|2007-04-11|Security method making deterministic real time execution of multitask applications of control and command type with error confinement
    US8424007B1|2013-04-16|Prioritizing tasks from virtual machines
    JP6715356B2|2020-07-01|Memory Allocation Techniques in Partially Offloaded Virtualization Managers
    JP6845264B2|2021-03-17|Reducing performance variability with an opportunistic hypervisor
    EP3295293B1|2021-07-28|Thread safe lock-free concurrent write operations for use with multi-threaded in-line logging
    US8006254B2|2011-08-23|Bequeathing privilege to a dynamically loaded module
    TWI460659B|2014-11-11|Lock windows for reducing contention
    WO2011135567A1|2011-11-03|System and method for efficient inspection of content
    US9823857B1|2017-11-21|Systems and methods for end-to-end quality of service control in distributed systems
    US9798584B1|2017-10-24|Methods and apparatus for IO sizing based task throttling
    US10394591B2|2019-08-27|Sanitizing virtualized composite services
    US9864532B2|2018-01-09|Performing preprocessing operations in anticipation of log file writes
    US10579416B2|2020-03-03|Thread interrupt offload re-prioritization
    FR3054902B1|2019-06-21|METHOD AND DEVICE FOR DISTRIBUTING SHEET MUSIC ON A MULTI-HEART PROCESSOR
    US20210149726A1|2021-05-20|Scheduling device, scheduling system, scheduling method, and non-transitory computer-readable medium
    EP3663953A1|2020-06-10|Method and device for access control to a resource shared between software tasks in a predetermined implementation context
    JP7007425B2|2022-01-24|Memory allocation technology for partially offloaded virtualization managers
    US10684895B1|2020-06-16|Systems and methods for managing containerized applications in a flexible appliance platform
    EP1410178B1|2006-05-24|Time management method and system in a real-time system
    同族专利:
    公开号 | 公开日
    FR3019339B1|2016-04-01|
    WO2015144488A1|2015-10-01|
    EP3123344B1|2017-12-13|
    US10229077B2|2019-03-12|
    US20170083465A1|2017-03-23|
    EP3123344A1|2017-02-01|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    WO2007003986A1|2005-06-30|2007-01-11|Freescale Semiconductor, Inc.|Device and method for controlling an execution of a dma task|
    US20080126601A1|2006-09-22|2008-05-29|Sony Computer Entertainment Inc.|Methods and apparatus for allocating DMA activity between a plurality of entities|
    IT971304B|1972-11-29|1974-04-30|Honeywell Inf Systems|DYNAMICALLY VARIABLE PRIORITY ACCESS SYSTEM|
    US5644784A|1995-03-03|1997-07-01|Intel Corporation|Linear list based DMA control structure|
    US7454787B2|2004-01-13|2008-11-18|Hewlett-Packard Development Company, L.P.|Secure direct memory access through system controllers and similar hardware devices|
    US7930422B2|2004-07-14|2011-04-19|International Business Machines Corporation|Apparatus and method for supporting memory management in an offload of network protocol processing|
    JP4533713B2|2004-09-30|2010-09-01|株式会社東芝|Information processing apparatus and data transfer control method|
    US8831024B2|2006-12-29|2014-09-09|Broadcom Corporation|Dynamic header creation and flow control for a programmable communications processor, and applications thereof|
    JP5085178B2|2007-04-11|2012-11-28|ルネサスエレクトロニクス株式会社|DMA controller and DMA transfer method|
    US8037213B2|2007-05-30|2011-10-11|International Business Machines Corporation|Replenishing data descriptors in a DMA injection FIFO buffer|
    US8271700B1|2007-11-23|2012-09-18|Pmc-Sierra Us, Inc.|Logical address direct memory access with multiple concurrent physical ports and internal switching|
    WO2009138928A1|2008-05-13|2009-11-19|Nxp B.V.|Secure direct memory access|
    CN102693198B|2012-05-12|2015-03-25|北京忆恒创源科技有限公司|DMA transmission method and system|
    FR2993070B1|2012-07-09|2014-07-18|Commissariat Energie Atomique|METHOD OF EXECUTING, WITHIN A MULTITASTIC INBOARD SYSTEM, AN APPLICATION CADATED BY SEVERAL DIFFERENT TIME DOMAINS INCLUDING AN INTERRUPTION MANAGEMENT|
    US9148819B2|2012-11-06|2015-09-29|Peraso Technologies, Inc.|In-place A-MSDU aggregation for wireless systems|US10552619B2|2015-07-20|2020-02-04|Intel Corporation|Technologies for secure trusted I/O access control|
    FR3057969B1|2016-10-25|2019-11-01|Thales|DETERMINISTIC DRIVER SYSTEM FOR DETERMINING THE OPERATION OF MEANS FOR TRANSFERRING DATA BY DIRECT ACCESS TO MEMORY MEANS|
    FR3101460B1|2019-09-27|2021-09-03|Continental Automotive|Method and calculator for managing data exchanges between a plurality of tasks|
    US11023400B1|2020-01-20|2021-06-01|International Business Machines Corporation|High performance DMA transfers in host bus adapters|
    法律状态:
    2015-03-31| PLFP| Fee payment|Year of fee payment: 2 |
    2016-03-31| PLFP| Fee payment|Year of fee payment: 3 |
    2017-03-31| PLFP| Fee payment|Year of fee payment: 4 |
    2018-03-29| PLFP| Fee payment|Year of fee payment: 5 |
    2019-11-29| ST| Notification of lapse|Effective date: 20191106 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1452497A|FR3019339B1|2014-03-25|2014-03-25|METHOD OF TRANSFERRING DATA BETWEEN REAL-TIME TASKS USING A MEMORY DMA CONTROLLER|FR1452497A| FR3019339B1|2014-03-25|2014-03-25|METHOD OF TRANSFERRING DATA BETWEEN REAL-TIME TASKS USING A MEMORY DMA CONTROLLER|
    US15/125,942| US10229077B2|2014-03-25|2015-03-17|Method for data transfer between real-time tasks using a DMA memory controller|
    PCT/EP2015/055512| WO2015144488A1|2014-03-25|2015-03-17|Method for data transfer between real-time tasks using a dma memory controller|
    EP15711708.6A| EP3123344B1|2014-03-25|2015-03-17|Method for data transfer between real-time tasks using a dma memory controller|
    [返回顶部]