EP3598315B1 - Accès direct en mémoire - Google Patents

Accès direct en mémoire Download PDF

Info

Publication number
EP3598315B1
EP3598315B1 EP19186868.6A EP19186868A EP3598315B1 EP 3598315 B1 EP3598315 B1 EP 3598315B1 EP 19186868 A EP19186868 A EP 19186868A EP 3598315 B1 EP3598315 B1 EP 3598315B1
Authority
EP
European Patent Office
Prior art keywords
transfer
ctrl
data
lli
record
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.)
Active
Application number
EP19186868.6A
Other languages
German (de)
English (en)
Other versions
EP3598315A1 (fr
Inventor
François CLOUTE
Sandrine Lendre
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.)
STMicroelectronics Rousset SAS
STMicroelectronics Grenoble 2 SAS
Original Assignee
STMicroelectronics Rousset SAS
STMicroelectronics Grenoble 2 SAS
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
Priority claimed from FR1856705A external-priority patent/FR3084179A1/fr
Application filed by STMicroelectronics Rousset SAS, STMicroelectronics Grenoble 2 SAS filed Critical STMicroelectronics Rousset SAS
Publication of EP3598315A1 publication Critical patent/EP3598315A1/fr
Application granted granted Critical
Publication of EP3598315B1 publication Critical patent/EP3598315B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28—Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal

Definitions

  • the present description generally relates to the field of electronic systems, and more particularly to electronic systems in which the execution of tasks, for example data transfers by direct memory access (DMA - "Direct Memory Access”), are parameterized by a linked list of records stored in memory.
  • DMA direct memory access
  • Direct memory access is a process allowing, in an electronic system, data transfers between a peripheral and a memory, between two peripherals or between two memories without the intervention of a central processing unit (CPU - "Central Processing Unit ”) except to initiate and complete the transfer.
  • CPU central processing unit
  • Direct memory access is generally implemented by a direct memory access control circuit.
  • the circuit reads in a memory a record of a linked list of records ("Linked List Item" - LLI) in order to obtain the parameters of the transfer. These read parameters are temporarily stored in a set of registers, or bank of registers, of the circuit. The circuit then performs the transfer according to the stored parameters.
  • Linked List Item a linked list of records
  • the document WO 01/29656 describes a linked-list DMA descriptor architecture.
  • the memory of the invention is defined by claim 1 and particular embodiments of this memory by dependent claims 2 to 5.
  • a data transfer method of the invention is defined by claim 6 and embodiments particulars of this method by the dependent claims 7 to 8.
  • An electronic system of the invention is defined by claim 9.
  • the figure 1 represents, very schematically and in the form of blocks, an embodiment of an electronic circuit or system 1 of the type to which the embodiments which will be described apply, by way of example.
  • system 1 can integrate other functions, symbolized by a block 16 (FCT), depending on the application, for example a processor dedicated to image processing, other interfaces, other memories, etc.
  • FCT a block 16
  • System 1 is configured to execute various applications such as image processing, video encoding and/or decoding, data processing from a sensor, etc. These applications require data transfers, via the bus 15, between elements internal to the system 1. In order to streamline the operation of the system 1 and to reduce the load on the central unit 11, these data transfers are carried out by direct memory access, under the control of circuit 14.
  • circuit 14 comprises several data transfer channels. Each channel of circuit 14 makes it possible to carry out data transfers between two elements (circuit and/or memory) of system 1. Each channel is associated with a bank of registers storing, for each transfer of data on the channel, the parameters of the transfer .
  • the central unit 11 configures the circuit 14 so that the circuit 14 reserves one of these channels for the application. All data transfers of the application then take place via the channel reserved for the application.
  • the source element and/or the destination element of the data to be transferred can change during the execution of the application.
  • the picture 2 is a flowchart illustrating, in the form of blocks, an embodiment of a method for transferring data by direct memory access. More specifically, the picture 2 illustrates, for a given application, a method of successive updates of a bank of registers associated with a channel of circuit 14 of the figure 1 , from a linked list of records representative of the application's data transfers.
  • a channel is allocated to an application by programming the bank of registers associated with this channel with the parameters of a first data transfer of this application. This step amounts to indicating to the circuit 14 which linked list of records it must use to parameterize the transfers to take place on this channel. Each record in the list determines the memory address of the next record.
  • Each record further determines the parameters of a corresponding data transfer, for example the indication that the transfer concerns data or blocks of data, the start address of a range of addresses of a source where stored the data or blocks of data to be transferred, the start address of a range of addresses of a destination where the transferred data or blocks of data are to be copied, the number of data or blocks of data to be transfer, the size of the data, the number of data per block, address offsets between two successive data or between two successive blocks to be transferred, etc.
  • Each record can therefore correspond to the transfer of one data item, several data items, a data block or several blocks between a source and a destination.
  • the bank of registers is programmed by reading in memory 12, at a memory address supplied by the central unit 11, the first record of a list and by programming the bank of registers from this recording.
  • step 200 the bank of registers is programmed directly, without reading a record in memory 12, for example on initialization of system 1 or by central unit 11.
  • the address of the first record of a list is then programmed in the bank of registers.
  • the central unit 11 indicates to the circuit 14 that it can begin to execute the data transfers of the application.
  • step 202 EXECUTE TRANSFER
  • the circuit 14 performs, on the channel reserved for the application, the transfer of data parameterized by the contents of the bank of registers of the channel, it being understood that this transfer may concern several data or multiple blocks of data.
  • a test 203 (REPEAT?) is then performed to determine, from the contents of the register bank, whether the data transfer executed in the previous step 202, and whose parameters are stored in the register bank, must or not be repeated.
  • step 202 If this transfer must be repeated (output Y of block 203), the method continues at step 202. It is understood that, since the content of the bank of registers is then not modified, this transfer is then executed endlessly.
  • test 204 determines, from the current content of the bank of registers, if there is a next record in the list, in other words if there remains at least one transfer to be performed for this application.
  • test 204 is followed by a step 206 (END) where the channel is released and can then be assigned to a new application .
  • test 204 is followed by a step 208 (LOAD NEXT LLI) where this next record is read from memory 12 by circuit 14 and the register bank is updated with the parameters of the application's next data transfer. The method then continues at step 202.
  • step 208 LOAD NEXT LLI
  • tests 203 and 204 can be performed simultaneously.
  • the picture 3 represents, schematically and in the form of blocks, an embodiment of a bank of registers associated with a data transfer channel of circuit 14.
  • the bank of registers comprises five registers R1, R2, R3, R4 and R5 making it possible to temporarily store the parameters of a data transfer.
  • the registers R1, R2, R3, R4 and R5 are intended here to respectively store the start address S@ of a range of addresses of a source of data to be transferred, the start address D@ of a range of addresses of a destination of the data to be transferred, the number NB of data to be transferred, the size BL of the data to be transferred and the address NLLI@ of the next record in the memory 12.
  • the linked list register or LLR (Linked List Register) register is the register intended to store the information on the linked list of records, and in particular the address NLLI@.
  • the LLR register is the last register of the bank of registers, in this example the R5 register.
  • one of the registers is also intended to store information on the next record in the list. This information determines the number of fields for the next record in the list.
  • Each field of a record is for example representative of a content to be programmed in a corresponding register, during the next update of the bank of registers. Preferably, each field is copied directly into a corresponding register during this update.
  • the information about the next record in the list further determines which register each field of the next record is assigned to. This information is stored by bits of the LLR register R5, for example five bits U1, U2, U3, U4 and U5.
  • bits U1, U2, U3, U4 and U5 are assigned respectively to registers R1, R2, R3, R4 and R5, the value of each bit U1, U2, U3, U4, U5 determining whether the next record comprises a field representative of a content to be programmed in the register, respectively R1, R2, R3, R4, R5. For example, if bit U1 is at a first binary value, for example '1', the following record includes a field representing content to be programmed in register R1, and if the bit is at the second binary value, for example '0', the following record does not include such a field.
  • test 203 described in relation to the figure 2 consists in checking if all bits U1 to U5 are at '0' and if the @NLLI address is not zero. If so, this means that the register bank should not be updated and the last executed transfer should be repeated.
  • test 204 described in relation to the picture 2 is to check if the @NLLI address is null. If so, it means there is no next record and all application transfers have been completed.
  • the information relating to the number of fields of the following record and to the register to which each of these fields is assigned, the indication that a transfer must be repeated and/or the indication that the list no longer contains following record may be represented in a different form than that described above by way of example.
  • the figure 4 schematically represents a memory, for example the memory 12 of the figure 1 , containing an embodiment of a linked list of records for programming the registers of the picture 3 .
  • Memory 12 is divided into several memory words 41 of fixed size, for example 4 bytes, each being associated with an address 43 of the memory.
  • Memory 12 contains a linked list of records consisting, in this example, of three records LLI-1, LLI-2 and LLI-3.
  • the fields of the same record are recorded one after the other in the memory 12, here from the memory address of the first field of this record.
  • each field occupies a memory word 41.
  • each field may require more than one memory word for its memory storage or a memory word may contain more than one field.
  • the fields of each record follow one another in the same order as the corresponding registers of the bank of registers.
  • the memory address of a record corresponds to the address at which the first field of this record is saved.
  • this first LLI-1 record then comprises as many fields as there are registers, five in this example, so that each register can be programmed with a field of the record. More particularly, the LLI-1 record comprises successive fields C1, C2, C3, C4 and C5 representative of a content to be programmed in the registers R1, R2, R3, R4 and R5 respectively.
  • fields C1, C2, C3 and C4 of the LLI-1 record are respectively representative of an address S1@, an address D1@, a number NB-1 and a size BL -1.
  • the field C5 of the record is representative of the address @k2 of the record following LLI-2 in the memory 12, and of information on this record following LLI-2.
  • the information relating to the following record is in the form of five bits of values '1', '0', '1', '0' and '1' corresponding respectively to bits U1, U2, U3, U4 and U5 of register R5.
  • the first field C1 of the LLI-1 record is stored in the address memory word @k1 and the following fields C2, C3, C4 and C5 are stored in the following memory words with respective addresses @k1 +4, @k1+8, @k1+12 and @k1+16, each memory word here occupying four bytes.
  • the second record LLI-2 comprises successive fields C1, C3 and C5 representative of a content to be programmed in the registers R1, R3 and R5 respectively.
  • Fields C1 and C2 are respectively representative of an address S2@ and of a number NB-2, field C5 being representative of the address @k3 of the following record LLI-3 and of five bits of values '0 ', '1', '1', '1' and '1' corresponding respectively to bits U1, U2, U3, U4 and U5 of the register R5.
  • the first field C1 of the LLI-2 record is recorded in the address memory word @k2 and the following fields C3 and C5 are recorded in the following memory words with respective addresses @k2+4 and @ k2+8.
  • the third record LLI-3 comprises successive fields C2, C3, C4 and C5 representative of a content to be programmed in the registers R2, R3, R4 and R5 respectively.
  • the fields C2, C3 and C4 are respectively representative of an address D3@, of a number NB-3 and of a size BL-3.
  • the C5 field is representative of a null address @NULL and five bits U1 to U5 with a value of '0', which indicates that the LLI-3 record is the last in the list and that the transfer corresponding to this record does not have to be repeated.
  • the first field C2 of the LLI-3 record is recorded in the address memory word @k3 and the following fields C3, C4 and C5 are recorded in the following memory words with respective addresses @k3+4 , @k3+8 and @k3+12.
  • At least certain records stored in the memory contain a number of fields lower than the number of registers of the bank of registers updated from these records.
  • the storage capacity of memory 12 can be reduced compared to that of a memory in which each record of a linked list would have as many fields as there are registers in the bank of registers.
  • the reduction in the storage capacity of the memory 12 leads to a reduction in its surface area and in its static consumption.
  • the figure 5 illustrates, in the form of a flowchart, the step 208 of the method of the figure 2 described above, i.e. updating the register store from of a record from a linked list of records stored in memory.
  • a loop variable i is initialized, to 1 in this example.
  • circuit 14 tests the current value of bit Ui of LLR register R5 to determine whether the next record contains a field Ci representative of content to be programmed in register Ri .
  • the method described above makes it possible, when the bank of registers associated with a channel is updated from a record of a linked list of the type described in figure 4 , to update only certain registers of this bank of registers, preferably only the registers whose content is modified between two successive transfers. This results in a reduction in the number of accesses to the memory 12 compared to the case where all the registers of the bank would be updated. This reduction in the number of accesses to memory 12 leads to a reduction in the dynamic consumption of memory 12, and more generally of system 1 of the figure 1 . Advantage is taken here of the fact that two successive data transfers on a channel reserved for an application generally have certain identical parameters.
  • the circuit 14 performs all these transfers autonomously, without intervention of the central unit 11. Once all the transfers have been carried out , the circuit 14 warns the central unit 11 which can then assign this channel to another application.
  • a synchronization between two applications, executed on two different channels of the circuit 14 can only be performed by the central unit 11, either at the start of the execution of one of the two applications, or at the end of the execution of one of the two applications, when all records corresponding to this application's data transfers have been read and the corresponding transfers completed.
  • the figure 6 represents, schematically and in the form of blocks, an example of another embodiment of a bank of registers of a data transfer channel of circuit 14.
  • the bank of registers of the figure 6 here includes six registers R1, R2, R3, R4, R5 and R6, the registers R1, R2, R3 and R4 of the figure 6 being, in this example, similar to the registers R1, R2, R3 and R4 of the picture 3 .
  • Register R5 is here intended to store a transfer start ctrl-in condition and a transfer end ctrl-out event.
  • the R6 register constitutes the linked list register (LLR) of the bank of registers and is, as in picture 3 , intended to store the NLLI@ address of a following record and the information relating to this following record, in particular the number of fields of the record and to which register is assigned each field of the following record. This information is stored here in the form of six bits U1, U2, U3, U4, U5 and U6 respectively associated with registers R1, R2, R3, R4, R5 and R6.
  • each record can include an additional field C6 (not shown) representing content to be programmed in register R6.
  • field C6 of the record can then comprise six bits corresponding to six bits U1 to U6 of register R6.
  • the ctrl-in condition and the ctrl-out event are stored in one of the registers R1 to R4 and R6, the ctrl-in condition possibly being stored in a register other than that storing the ctrl-out event. out.
  • This variant is for example implemented when one or more of the registers R1 to R4 and R6 contain unused bits then making it possible to store this ctrl-in and ctrl-out information. This makes it possible to delete the register R5, the register LLR R6 then being renumbered R5.
  • the figure 7 is a flowchart illustrating one embodiment of a direct memory access data transfer method. More specifically, the figure 7 illustrates in more detail step 202 of the method of the picture 2 .
  • Step 801 (ctrl-in?) implemented by circuit 14, all the parameters of the data transfer to be executed are stored in the registers of the register bank.
  • Step 801 consists of detecting the ctrl-in condition for the start of transfer, stored in register R5 in this example.
  • Step 801 is repeated (exit N from block 801) as long as this ctrl-in condition is not detected.
  • step 802 MAKE TRANSFER
  • step 804 GENERAL ctrl-out
  • the second transfer can start only after the generation of the ctrl-out event of the first transfer.
  • the first and second transfers therefore the first and second applications, can be synchronized with respect to each other, directly at the level of the circuit 14, without intervention of the central unit 11 and while these applications are in being executed.
  • a ctrl-in condition and a ctrl-out event for at least certain data transfers of several applications executed by the system 1 makes it possible to synchronize these applications with each other, without resorting to the central processing unit. which can be put to sleep, or even turned off, while these applications are running.
  • an additional parameter is provided indicating at what moment the ctrl-in condition must be detected during a transfer of several data items, for example before the transfer of the first data item or before the transfer of each data item.
  • an additional parameter is provided indicating when the ctrl-out event must be generated during a transfer of several data items, for example after the transfer of the last data item or after the transfer of each data item.
  • step 801 For example, during a transfer of several data, if the ctrl-in condition is detected before each data transfer and the ctrl-out event is generated after each data transfer, the steps 801, 802 and 804 are implemented for each datum transferred, step 802 then corresponding to the transfer of the datum.
  • the ctrl-in condition of a transfer on a channel can correspond to the detection of an event other than a ctrl-out event generated during a transfer to another channel, for example the detection of an event generated in system 1, for example from block 13 (I/O) of system 1.
  • each ctrl-in condition can correspond to the detection of a change in level, for example the passage from a high level to a low level or vice versa, of a signal corresponding to this condition.
  • Each ctrl-out event consists for example of changing the level of a signal corresponding to this event.
  • each record of the linked list contains as many fields as there are registers.
  • the registers and records described in relation to the figures 3 to 7 can integrate one or more additional parameters so as to manage transfers by blocks of data and/or, in a range of source and/or destination addresses, address offsets between two data or two blocks of data to be transferred successive.
  • the registers and recordings are adapted so as to manage transfers by blocks of data
  • the parameter(s) indicating at which times to detect the ctrl-in condition and/or generate the ctrl-out event will then be adapted accordingly, as will the process described in relation to the figure 7 .
  • the figure 8 represents, schematically and in the form of blocks, an example of a bank of registers of a direct memory access control circuit, according to the embodiment of the figure 6 .
  • the register R5 is represented, the registers R1 to R4 and R6 being for example identical to those described in relation to the figure 6 .
  • the ctrl-in condition described in relation to the figure 6 includes a parameter ctrl-in-req representative of the identification of the client of the transfer parameterized by the contents of the registers of the bank of registers associated with the channel of the transfer.
  • the parameter ctrl-in-req is representative of the identification of the element of system 1, for example the functional block 16 (FTC), which requests the transfer of data.
  • FTC functional block 16
  • the identification of the client of a transfer amounts to identifying which is the request signal which will cause this transfer.
  • this transfer can only begin after the emission of a request by the client of the transfer, or, in other words, the beginning of the transfer is conditioned by this request.
  • the circuit 14 therefore directly receives the memory access requests coming from the clients of the data transfers taking place on the channels of the circuit 14.
  • the requests are processed directly in the circuit 14, the circuit 14 being in measuring, on the basis of the information contained in the register banks associated with the transfer channels, to know to which channel each request must be transmitted, or in other words, to know for each request on which channel the start of a planned transfer is conditional on receipt of this request.
  • each potential client of a data transfer i.e., that is to say each element of the system 1 capable of requesting a transfer of data
  • the system 1 then comprises, outside the DMA circuit 14, a request routing circuit configured to receive all the data transfer requests and to transmit, in accordance with the static client/channel allocation, each request received at each channel with which the requesting client is associated.
  • Embodiments that include the ctrl-in-req parameter have advantages over those that don't.
  • the provision of the ctrl-in-req parameter makes it possible to avoid having recourse to an additional circuit for routing data transfer requests, from which it results that the system 1 consumes less and occupies a reduced area compared to the case where such a routing circuit is provided.
  • the implementation of the example execution above can be done by means of a single application comprising the first and second transfers, therefore the first and second clients.
  • the same linked list of records can be used to configure the first and second transfers on the same channel.
  • a first transfer is configured by programming the parameters, and in particular the parameter ctrl-in-req, of this first transfer into the registers of the channel's register bank.
  • the transmission of a request by the first client then leads to the implementation of this first transfer on this channel, then a second transfer is configured, on this same channel, by programming the parameters, and in particular the ctrl-in parameter -req, of this second transfer into the registers of the channel's register bank.
  • the transmission of a request by the second client then causes the implementation of this second transfer on this channel. Execution continues by repeating, for this channel, the steps of programming the registers with the parameters of a first transfer, receiving a request from the first client, implementing the first transfer on the channel, programming registers with the parameters of a second transfer, reception of a request from the second client and implementation of the second transfer on the channel.
  • the implementation of this example of execution is made by means of a first application corresponding to the first transfers, that is to say to the first customer, and a second application corresponding to the second transfers, therefore to the second customer.
  • a first linked list of records is used to configure the first transfers on a first channel to which the first client is statically associated
  • a second linked list of records is used to configure the second transfers on a second channel to which the second client is statically associated.
  • the second channel is reserved by the second application but is not used.
  • the provision of the ctrl-in-req parameter allows an association dynamics of customers to channels of circuit 14, resulting in a reduction in the time a channel is reserved but not used and/or a reduction in the number of channels required.
  • the reduction in the number of circuit channels 14 leads to a reduction in the consumption and in the surface of the circuit 14, and more generally of the system 1.
  • the figure 9 represents, schematically and in the form of blocks, an alternative embodiment of the bank of registers of the figure 8 .
  • the ctrl-in condition includes a ctrl-in-req-mode parameter indicating, for the transfer parameterized by the contents of the register bank, at least one moment of the transfer where the request from the client identified by the ctrl-in-req parameter must be received.
  • the transfer parameterized by the contents of the register bank corresponds to several similar transfers, for example several transfers of data or blocks of data
  • the parameter ctrl-in-req-mode indicates which of these similar transfers are conditioned by the receipt of a request from the client of the transfer.
  • the parameter ctrl-in-req-mode indicates that a request from the client must be received before each transfer of data, before each transfer of blocks of data, or only before the transfer of the first data or the first block of data.
  • the transfers of data or of blocks of data following the transfer of the first data item or of the first block of data can be carried out without a request having been sent by the client of the transfer.
  • the embodiment variant described in relation to the figure 9 therefore makes it possible to reduce the number of records of a list, which can make it possible to reduce the size of the memory 12.
  • This variant also makes it possible to reduce the number of accesses to the memory 12 and of updates of the banks of registers associated with the channels of the circuit 14.
  • the figure 10 represents, schematically and in the form of blocks, another example of a bank of registers of a direct memory access control circuit, according to the embodiment of the figure 6 .
  • the register R5 is represented, the registers R1 to R4 and R6 being for example identical to those described in relation to the figure 6 .
  • the ctrl-in condition for the start of transfer to include, in addition to the ctrl-in-req parameter, a ctrl-in-trig parameter representative of an identification of a signal conditioning the start of the transfer, a parameter ctrl-in-trig-mode representative of the moment or times when a modification of this signal must be detected, and an optional parameter ctrl-in-trig-pol representative of the type of modification , namely rising edge, falling edge or level change, of the signal conditioning the start of the transfer.
  • the parameter ctrl-in-trig-mode indicates which of these similar transfers are conditioned by the detection of a modification of the signal identified by the parameter ctrl-in-trig, the type (or polarity) of this modification being indicated here by the parameter ctrl-in-trig-pol.
  • the parameter ctrl-in-trig-mode indicates that a modification of the signal identified by the parameter ctrl-in-trig must be detected before each transfer of data, before each transfer of blocks of data, or only before the transfer of the first data item or of the first block of data.
  • the ctrl-in-trig-mode parameter can also indicate that, for the current transfer configured by the contents of the bank of registers associated with the channel of the transfer, the transfer is not conditioned by the detection of a modification of a signal identified by the ctrl-in-trig parameter.
  • a data transfer parameterized by the contents of the bank of registers associated with the transfer channel can only begin after the receipt of the transfer client's request by the circuit 14 and, if necessary, the detection, by the circuit 14, of a modification of the signal identified by the parameter ctrl-in-trig, the type of this modification being, in this example, indicated by the ctrl-in-trig-pol parameter.
  • the start of each of these similar transfers may or may not be conditioned, in accordance with the ctrl-in-trig-mode and/or ctrl-in-req-mode parameters, upon receipt a request from the transfer client and/or the detection of a modification of a signal identified by the ctrl-in-trig parameter.
  • the end of transfer ctrl-out event is a modification of an end of transfer signal associated with this channel.
  • the ctrl-out event here includes a ctrl-out-mode parameter representative of the time(s) when the end of channel transfer signal must be modified, and an optional ctrl-out-pol parameter representative of the signal modification polarity , that is to say whether the end of transfer event is a rising edge, a falling edge or a change in level of the end of transfer signal associated with the channel considered.
  • the ctrl-out-mode parameter indicates that the moment when the ctrl-out condition must be generated, i.e. the moment when the end of transfer signal associated with the channel must be modified, is only after the transfer of the last data or the last block of data, after the transfer of each data or each block of data, or at no time during this transfer.
  • the signal identified by the ctrl-in-trig parameter can be the end of transfer signal of a channel or any other internal signal of system 1, for example an event signal supplied by an element of the system 1, for example a system 1 counter.
  • a ctrl-in-trig-pol parameter in the same way that a ctrl-in-trig-pol parameter can be provided to indicate what type of modification of the signal identified by the ctrl-in-trig parameter conditions transfers of data, a ctrl-in-req-pol parameter may be provided to indicate what type of modification of a request signal constitutes a request from a client associated with that request signal.
  • each of the ctrl-in-trig-pol and ctrl-in-req-pol parameters can be representative not only of a given type of modification (rising edge, falling edge or level change) but also of a level high or low to be detected on the corresponding signal or request. Note that, in the absence of the ctrl-in-trig-pol parameter and/or the ctrl-in-req-pol parameter, the polarity can be defined by default.
  • some of the parameters ctrl-in-trig, ctrl-in-trig-mode, ctrl-in-trig-pol, ctrl-in-req, ctrl-in-req-mode, ctrl -in-req-pol, ctrl-out-mode and ctrl-out-pol can be omitted.
  • the ctrl-in-trig, ctrl-in-trig-mode, ctrl-in-trig-pol, ctrl-out-mode and/or ctrl-out-pol parameters may be provided independently of the ctrl- in-req, ctrl-in-req-mode, ctrl-in-req-pol, and vice versa.
  • ctrl-in-trig ctrl-in-trig-mode
  • ctrl-in-trig-pol ctrl-in-req
  • ctrl-in-req-mode ctrl-in-req-pol
  • ctrl-out-pol ctrl-pol out-mode and/or ctrl-out-pol are preferably stored in the same register, or in other words come from the same field of a list record chain of records, these parameters can be stored in different registers.
  • each record of the linked list contains as many fields as there are registers.
  • the ctrl-in condition is in fact at least partly determined by the ctrl-in-req parameter and/or at least partly determined by the ctrl-in-trig parameter. Furthermore, the moment or moments of detection of a ctrl-in condition, in particular during a transfer corresponding to several similar transfers, are at least partly determined by the parameter ctrl-in-req-mode and/or at least partly determined by the ctrl-in-trig-mode setting.
  • the number of registers, the number of parameters stored by the bank of registers and/or the number of parameters stored by each register can vary.
  • a parameter can indicate whether the data and/or the data blocks of the transfer corresponding to a recording must be transferred step by step or by burst.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

    Domaine technique
  • La présente description concerne de façon générale le domaine des systèmes électroniques, et plus particulièrement des systèmes électroniques dans lesquels des exécutions de tâches, par exemple des transferts de données par accès direct en mémoire (DMA - "Direct Memory Access"), sont paramétrées par une liste chaînée d'enregistrements stockée dans une mémoire.
    • Technique antérieure
  • L'accès direct en mémoire est un procédé permettant, dans un système électronique, des transferts de données entre un périphérique et une mémoire, entre deux périphériques ou entre deux mémoires sans intervention d'une unité centrale de traitement (CPU - "Central Processing Unit") si ce n'est pour lancer et conclure le transfert.
  • L'accès direct en mémoire est généralement mis en oeuvre par un circuit de contrôle d'accès direct en mémoire. Pour effectuer un transfert de données, le circuit lit dans une mémoire un enregistrement d'une liste chaînée d'enregistrements ("Linked List Item" - LLI) afin d'obtenir les paramètres du transfert. Ces paramètres lus sont stockés temporairement dans un ensemble de registres, ou banque de registres, du circuit. Le circuit effectue ensuite le transfert en fonction des paramètres stockés.
  • Le document WO 01/29656 décrit une architecture de descripteurs de DMA à listes liées.
    • Résumé de l'invention
  • La mémoire de l'invention est définie par la revendication 1 et des modes de réalisation particuliers de cette mémoire par les revendications dépendantes 2 à 5. Un procédé de transfert de données de l'invention est défini par la revendication 6 et des modes de réalisation particuliers de ce procédé par les revendications dépendantes 7 à 8. Un système électronique de l'invention est défini par la revendication 9.
    • Brève description des dessins
  • Ces caractéristiques et avantages, ainsi que d'autres, seront exposés en détail dans la description suivante de modes de réalisation particuliers en relation avec les figures jointes parmi lesquelles :
    • la figure 1 représente, de façon très schématique et sous forme de blocs, un mode de réalisation d'un circuit électronique 1
    • la figure 2 est un organigramme illustrant, sous forme de blocs, un mode de réalisation d'un procédé de transfert de données par accès direct en mémoire ;
    • la figure 3 représente, schématiquement et sous forme de blocs, un mode de réalisation d'une banque de registres d'un circuit de contrôle d'accès direct en mémoire ;
    • la figure 4 représente schématiquement une mémoire contenant un mode de réalisation d'une liste chainée d'enregistrements pour programmer les registres de la figure 3 ;
    • la figure 5 est un organigramme illustrant plus en détail un mode de réalisation d'une étape du procédé de la figure 2 ;
    • la figure 6 illustre, schématiquement et sous forme de blocs, un autre mode de réalisation d'une banque de registres d'un circuit de contrôle d'accès direct en mémoire ;
    • la figure 7 est un organigramme illustrant un mode de réalisation d'un procédé de transfert de données par accès direct en mémoire ;
    • la figure 8 représente, schématiquement et sous forme de blocs, un exemple d'une banque de registres d'un circuit de contrôle d'accès direct en mémoire, selon le mode de réalisation de la figure 6 ;
    • la figure 9 représente, schématiquement et sous forme de blocs, une variante de réalisation de la banque de registres de la figure 8 ; et
    • la figure 10 représente, schématiquement et sous forme de blocs, un autre exemple d'une banque de registres d'un circuit de contrôle d'accès direct en mémoire, selon le mode de réalisation de la figure 6.
    Description des modes de réalisation
  • De mêmes éléments ont été désignés par de mêmes références dans les différentes figures. En particulier, les éléments structurels et/ou fonctionnels communs aux différents modes de réalisation peuvent présenter les mêmes références et peuvent disposer de propriétés structurelles, dimensionnelles et matérielles identiques.
  • Par souci de clarté, seuls les étapes et éléments utiles à la compréhension des modes de réalisation décrits ont été représentés et sont détaillés. En particulier, les divers paramètres couramment utilisés pour des transferts de données par accès direct en mémoire n'ont pas été détaillés, les modes de réalisation décrits étant compatibles avec ces paramètres usuels. En outre, les divers systèmes électroniques dans lesquels un contrôleur d'accès direct en mémoire est prévu n'ont pas été détaillés, les modes de réalisation décrits étant compatibles avec la plupart de ces systèmes électroniques usuels.
  • Sauf précision contraire, lorsque l'on fait référence à deux éléments connectés entre eux, cela signifie directement connectés sans éléments intermédiaires autres que des conducteurs, et lorsque l'on fait référence à deux éléments reliés ou couplés entre eux, cela signifie que ces deux éléments peuvent être connectés ou être reliés ou couplés par l'intermédiaire d'un ou plusieurs autres éléments.
  • Dans la description qui suit, lorsque l'on fait référence à des qualificatifs de position absolue, tels que les termes "avant", "arrière", "haut", "bas", "gauche", "droite", etc., ou relative, tels que les termes "dessus", "dessous", "supérieur", "inférieur", etc., ou à des qualificatifs d'orientation, tels que les termes "horizontal", "vertical", etc., il est fait référence sauf précision contraire à l'orientation des figures.
  • Sauf précision contraire, les expressions "environ", "approximativement", "sensiblement", et "de l'ordre de" signifient à 10 % près, de préférence à 5 % près.
  • La figure 1 représente, de façon très schématique et sous forme de blocs, un mode de réalisation d'un circuit ou système électronique 1 du type auquel s'appliquent, à titre d'exemple, les modes de réalisation qui vont être décrits.
  • Le système électronique 1 comporte :
    • une unité centrale de traitement 11 (CPU), par exemple une machine d'états, un microprocesseur, un circuit logique programmable, etc. ;
    • une ou plusieurs mémoires parmi lesquelles au moins une mémoire vive 12 (MEM), par exemple de type SRAM ;
    • au moins une interface d'entrée-sortie 13 (I/O) de communication, par exemple de type bus série, avec l'extérieur du système 1 ;
    • un circuit de contrôle d'accès direct en mémoire 14 (DMA) ; et
    • un ou plusieurs bus de données, d'adresses et/ou de commandes entre les différents éléments internes au système 1, représentés ici sous la forme d'un unique bus 15.
  • Par ailleurs, le système 1 peut intégrer d'autres fonctions, symbolisées par un bloc 16 (FCT), selon l'application, par exemple un processeur dédié au traitement d'images, d'autres interfaces, d'autres mémoires, etc.
  • Le système 1 est configuré pour exécuter diverses applications telles que du traitement d'images, de l'encodage et/ou du décodage vidéo, du traitement de données provenant d'un capteur, etc... Ces applications requièrent des transferts de données, par l'intermédiaire du bus 15, entre des éléments internes au système 1. Afin de fluidifier le fonctionnement du système 1 et de réduire la charge de l'unité centrale 11, ces transferts de données sont effectués par accès direct en mémoire, sous le contrôle du circuit 14. Dans ce mode de réalisation, le circuit 14 comprend plusieurs canaux de transfert de données. Chaque canal du circuit 14 permet de réaliser des transferts de données entre deux éléments (circuit et/ou mémoire) du système 1. Chaque canal est associé à une banque de registres stockant, pour chaque transfert de données sur le canal, les paramètres du transfert.
  • Lorsqu'une application doit être exécutée par le système 1, l'unité centrale 11 configure le circuit 14 de sorte que le circuit 14 réserve l'un de ces canaux à l'application. Tous les transferts de données de l'application s'effectuent alors via le canal réservé à l'application. Dans les modes de réalisation décrits, l'élément de source et/ou l'élément de destination des données à transférer peuvent changer pendant l'exécution de l'application.
  • La figure 2 est un organigramme illustrant, sous forme de blocs, un mode de réalisation d'un procédé de transfert de données par accès direct en mémoire. Plus particulièrement, la figure 2 illustre, pour une application donnée, un procédé de mises à jour successives d'une banque de registres associée à un canal du circuit 14 de la figure 1, à partir d'une liste chaînée d'enregistrements représentative des transferts de données de l'application.
  • A une étape initiale 200 (ALLOCATE CHANNEL), un canal est attribué à une application en programmant la banque de registres associée à ce canal avec les paramètres d'un premier transfert de données de cette application. Cette étape revient à indiquer au circuit 14 quelle liste chaînée d'enregistrements il doit utiliser pour paramétrer les transferts devant avoir lieu sur ce canal. Chaque enregistrement de la liste détermine l'adresse en mémoire de l'enregistrement suivant. Chaque enregistrement détermine en outre les paramètres d'un transfert de données correspondant, par exemple l'indication que le transfert concerne des données ou des blocs de données, l'adresse de début d'une plage d'adresses d'une source où sont stockés les données ou les blocs de données à transférer, l'adresse de début d'une plage d'adresses d'une destination où doivent être copiés les données ou les blocs de données transférés, le nombre de données ou de blocs de données à transférer, la taille des données, le nombre de données par blocs, des décalages d'adresses entre deux données successives ou entre deux blocs successifs à transférer, etc. Chaque enregistrement peut donc correspondre au transfert d'une donnée, de plusieurs données, d'un bloc de données ou de plusieurs blocs entre une source et une destination.
  • Selon un mode de réalisation, à l'étape 200, la banque de registres est programmée en lisant en mémoire 12, à une adresse mémoire fournie par l'unité centrale 11, le premier enregistrement d'une liste et en programmant la banque de registres à partir de cet enregistrement.
  • Selon un autre mode de réalisation, à l'étape 200, la banque de registres est programmée directement, sans lecture d'un enregistrement en mémoire 12, par exemple à l'initialisation du système 1 ou par l'unité centrale 11. En particulier, l'adresse du premier enregistrement d'une liste est alors programmée dans la banque de registres.
  • Une fois que la banque de registres a été programmée pour attribuer le canal à l'application, l'unité centrale 11 indique au circuit 14 qu'il peut commencer à exécuter les transferts de données de l'application.
  • A une étape 202 suivante (EXECUTE TRANSFER), le circuit 14 effectue, sur le canal réservé à l'application, le transfert de données paramétré par le contenu de la banque de registres du canal, étant entendu que ce transfert peut concerner plusieurs données ou plusieurs blocs de données.
  • Un test 203 (REPEAT?) est ensuite réalisé pour déterminer, à partir du contenu de la banque de registres, si le transfert de données exécuté à l'étape 202 précédente, et dont les paramètres sont stockés dans la banque de registres, doit ou non être répété.
  • Si ce transfert doit être répété (sortie Y du bloc 203), le procédé se poursuit à l'étape 202. On comprend que, du fait que le contenu de la banque de registres n'est alors pas modifié, ce transfert est ensuite exécuté en boucle.
  • Si ce dernier transfert n'a pas à être répété (sortie N du bloc 203), le procédé se poursuit par un test 204 (NEXT LLI?). Ce test détermine, à partir du contenu courant de la banque de registres, s'il y a un enregistrement suivant dans la liste, autrement dit s'il reste au moins un transfert à effectuer pour cette application.
  • S'il n'y a pas d'enregistrement suivant dans la liste (sortie N du bloc 204), le test 204 est suivi d'une étape 206 (END) où le canal est libéré et peut ensuite être attribué à une nouvelle application.
  • S'il y a un enregistrement suivant (sortie Y du bloc 204), le test 204 est suivi d'une étape 208 (LOAD NEXT LLI) où cet enregistrement suivant est lu en mémoire 12 par le circuit 14 et la banque de registres est mise à jour avec les paramètres du transfert de données suivant de l'application. Le procédé se poursuit alors à l'étape 202.
  • On notera que l'ordre et/ou le nombre des étapes du procédé de la figure 2 peuvent être modifiés. En particulier, les tests 203 et 204 peuvent être effectués simultanément.
  • A titre d'exemple, on considère dans la suite de la description le cas où les transferts devant avoir lieu sur un canal ne s'effectuent pas au niveau bloc de données, mais uniquement au niveau donnée. On considère également que lorsqu'un transfert correspond au transfert de plusieurs données, ces données sont stockées les unes à la suite des autres dans une plage d'adresses de source et copiées les unes à la suite des autres dans une plage d'adresses de destination.
  • La figure 3 représente, schématiquement et sous forme de blocs, un mode de réalisation d'une banque de registres associée à un canal de transfert de données du circuit 14.
  • Dans cet exemple, la banque de registres comprend cinq registres R1, R2, R3, R4 et R5 permettant de stocker temporairement les paramètres d'un transfert de données. Les registres R1, R2, R3, R4 et R5 sont ici destinés à stocker respectivement l'adresse S@ de début d'une plage d'adresses d'une source des données à transférer, l'adresse D@ de début d'une plage d'adresses d'une destination des données à transférer, le nombre NB de données à transférer, la taille BL des données à transférer et l'adresse NLLI@ de l'enregistrement suivant dans la mémoire 12. Dans la suite de la description, on appelle registre de liste chaînée ou registre LLR (Linked List Register) le registre destiné à stocker les informations sur la liste chaînée d'enregistrements, et en particulier l'adresse NLLI@. De préférence, le registre LLR est le dernier registre de la banque de registres, dans cet exemple le registre R5.
  • Dans ce mode de réalisation, un des registres, de préférence le registre LLR, est également destiné à stocker des informations sur l'enregistrement suivant de la liste. Ces informations déterminent le nombre de champs de l'enregistrement suivant de la liste. Chaque champ d'un enregistrement est par exemple représentatif d'un contenu à programmer dans un registre correspondant, lors de la mise à jour suivante de la banque de registres. De préférence, chaque champ est directement recopié dans un registre correspondant lors de cette mise à jour. Les informations sur l'enregistrement suivant de la liste déterminent en outre à quel registre est affecté chaque champ de l'enregistrement suivant. Ces informations sont stockées par des bits du registre LLR R5, par exemple cinq bits U1, U2, U3, U4 et U5. Dans ce mode de réalisation, les bits U1, U2, U3, U4 et U5 sont affectés respectivement aux registres R1, R2, R3, R4 et R5, la valeur de chaque bit U1, U2, U3, U4, U5 déterminant si l'enregistrement suivant comprend un champ représentatif d'un contenu à programmer dans le registre, respectivement R1, R2, R3, R4, R5. Par exemple, si le bit U1 est à une première valeur binaire, par exemple '1', l'enregistrement suivant comprend un champ représentatif d'un contenu à programmer dans le registre R1, et si le bit est à la deuxième valeur binaire, par exemple '0', l'enregistrement suivant ne comprend pas de tel champ.
  • A titre d'exemple, le test 203 décrit en relation avec la figure 2 consiste à vérifier si tous les bits U1 à U5 sont à '0' et si l'adresse @NLLI n'est pas nulle. Si c'est le cas, cela signifie que la banque de registres ne doit pas être mise à jour et que le dernier transfert exécuté doit être répété.
  • A titre d'exemple encore, le test 204 décrit en relation avec la figure 2 consiste à vérifier si l'adresse @NLLI est nulle. Si c'est le cas, cela signifie qu'il n'y a pas d'enregistrement suivant et que tous les transferts de l'application ont été effectués.
  • On notera que les informations relatives au nombre de champs de l'enregistrement suivant et au registre auquel est affecté chacun de ces champs, l'indication selon laquelle un transfert doit être répété et/ou l'indication selon laquelle la liste ne contient plus d'enregistrement suivant peuvent être représentées sous une forme différente de celle décrite ci-dessus à titre d'exemple.
  • La figure 4 représente schématiquement une mémoire, par exemple la mémoire 12 de la figure 1, contenant un mode de réalisation d'une liste chaînée d'enregistrements pour programmer les registres de la figure 3.
  • La mémoire 12 est divisée en plusieurs mots mémoire 41 de taille fixe, par exemple 4 octets, étant chacun associé à une adresse 43 de la mémoire. La mémoire 12 contient une liste chaînée d'enregistrements constituée, dans cet exemple, de trois enregistrements LLI-1, LLI-2 et LLI-3. Les champs d'un même enregistrement sont enregistrés les uns à la suite des autres dans la mémoire 12, ici à partir de l'adresse en mémoire du premier champ de cet enregistrement. Dans cet exemple, chaque champ occupe un mot mémoire 41. En variante, chaque champ peut nécessiter plus d'un mot mémoire pour son stockage mémoire ou un mot mémoire peut contenir plus d'un champ. De préférence, les champs de chaque enregistrement se succèdent dans le même ordre que les registres correspondants de la banque de registres. Dans cet exemple, l'adresse en mémoire d'un enregistrement correspond à l'adresse à laquelle est enregistré le premier champ de cet enregistrement.
  • Dans cet exemple, on considère le cas où, à l'étape 200 de la figure 2, la banque de registres est programmée à partir du premier enregistrement LLI-1 de la liste. Comme cela est illustré en figure 4, ce premier enregistrement LLI-1 comprend alors autant de champs qu'il y a de registres, cinq dans cet exemple, de sorte que chaque registre puisse être programmé avec un champ de l'enregistrement. Plus particulièrement, l'enregistrement LLI-1 comprend des champs successifs C1, C2, C3, C4 et C5 représentatifs d'un contenu à programmer dans les registres respectivement R1, R2, R3, R4 et R5. Dans cet exemple, les champs C1, C2, C3 et C4 de l'enregistrement LLI-1 sont représentatifs respectivement d'une adresse S1@, d'une adresse D1@, d'un nombre NB-1 et d'une taille BL-1. Le champ C5 de l'enregistrement est représentatif de l'adresse @k2 de l'enregistrement suivant LLI-2 dans la mémoire 12, et d'informations sur cet enregistrement suivant LLI-2. Dans cet exemple, les informations relatives à l'enregistrement suivant sont sous la forme de cinq bits de valeurs '1', '0', '1', '0' et '1' correspondant respectivement aux bits U1, U2, U3, U4 et U5 du registre R5. Dans cet exemple, le premier champ C1 de l'enregistrement LLI-1 est enregistré dans le mot mémoire d'adresse @k1 et les champs suivants C2, C3, C4 et C5 sont enregistrés dans les mots mémoire suivants d'adresses respectives @k1+4, @k1+8, @k1+12 et @k1+16, chaque mot mémoire occupant ici quatre octets.
  • Le deuxième enregistrement LLI-2 comprend des champs successifs C1, C3 et C5 représentatifs d'un contenu à programmer dans les registres respectivement R1, R3 et R5. Les champs C1 et C2 sont représentatifs respectivement d'une adresse S2@ et d'un nombre NB-2, le champ C5 étant représentatif de l'adresse @k3 de l'enregistrement suivant LLI-3 et de cinq bits de valeurs '0', '1', '1', '1' et '1' correspondant respectivement aux bits U1, U2, U3, U4 et U5 du registre R5. Dans cet exemple, le premier champ C1 de l'enregistrement LLI-2 est enregistré dans le mot mémoire d'adresse @k2 et les champs suivants C3 et C5 sont enregistrés dans les mots mémoire suivants d'adresses respectives @k2+4 et @k2+8.
  • Le troisième enregistrement LLI-3 comprend des champs successifs C2, C3, C4 et C5 représentatifs d'un contenu à programmer dans les registres respectivement R2, R3, R4 et R5. Les champs C2, C3 et C4 sont représentatifs respectivement d'une adresse D3@, d'un nombre NB-3 et d'une taille BL-3. Dans l'exemple représenté, le champ C5 est représentatif d'une adresse nulle @NULL et de cinq bits U1 à U5 de valeur '0', ce qui indique que l'enregistrement LLI-3 est le dernier de la liste et que le transfert correspondant à cet enregistrement n'a pas à être répété. Dans cet exemple, le premier champ C2 de l'enregistrement LLI-3 est enregistré dans le mot mémoire d'adresse @k3 et les champs suivants C3, C4 et C5 sont enregistrés dans les mots mémoire suivants d'adresses respectives @k3+4, @k3+8 et @k3+12.
  • Dans la liste décrite ci-dessus, au moins certains enregistrements stockés dans la mémoire contiennent un nombre de champs inférieur au nombre de registres de la banque de registres mise à jour à partir de ces enregistrements. Ainsi, la capacité de stockage de la mémoire 12 peut être réduite par rapport à celle d'une mémoire dans laquelle chaque enregistrement d'une liste chaînée aurait autant de champs qu'il y a de registres dans la banque de registres. La diminution de la capacité de stockage de la mémoire 12 entraîne une diminution de sa surface et de sa consommation statique.
  • La figure 5 illustre, sous la forme d'un organigramme, l'étape 208 du procédé de la figure 2 décrite ci-dessus, c'est-à-dire la mise à jour de la banque de registres à partir d'un enregistrement d'une liste chaînée d'enregistrements stockée en mémoire.
  • A une étape d'initialisation 500 (i=1), une variable de boucle i, avec i entier, est initialisée, à 1 dans cet exemple.
  • A une étape de test 502 suivante (Ui=1 ?), le circuit 14 teste la valeur courante du bit Ui du registre LLR R5 pour déterminer si l'enregistrement suivant contient un champ Ci représentatif d'un contenu à programmer dans le registre Ri.
  • Si, lors du test 502, la valeur courante du bit Ui du registre LLR R5 est '1' (sortie Y du bloc 502), cela signifie que l'enregistrement suivant comprend un champ Ci représentatif d'un contenu à programmer dans le registre Ri. Le test est alors suivi d'une étape 504 (Ri<=Ci) de programmation du registre Ri avec ce contenu. L'étape 504 est suivie d'un test 508 (i=5 ?) au cours duquel on vérifie si la valeur courante de chaque bit Ui du registre R5 a été testée. Si c'est le cas (sortie Y du bloc 508), la mise à jour de la banque de registres à partir de l'enregistrement suivant est terminée (bloc END, 510). Sinon (sortie N du bloc 508), le procédé se poursuit à une étape 512 (i=i+1) où la variable i est incrémentée, puis le procédé reboucle sur l'étape 502.
  • Si, lors du test 502, la valeur courante du bit Ui du registre LLR R5 est '0' (sortie N du bloc 502), cela signifie que l'enregistrement suivant ne comprend pas de champ Ci représentatif d'un contenu à programmer dans le registre Ri. Le procédé se poursuit alors directement à l'étape 508 et le contenu du registre Ri est laissé inchangé.
  • Le procédé décrit ci-dessus permet, lorsque la banque de registres associée à un canal est mise à jour à partir d'un enregistrement d'une liste chaînée du type décrit en figure 4, de ne mettre à jour que certains registres de cette banque de registres, de préférence uniquement les registres dont le contenu est modifié entre deux transferts successifs. Il en résulte une réduction du nombre d'accès à la mémoire 12 par rapport au cas où tous les registres de la banque seraient mis à jour. Cette diminution du nombre d'accès en mémoire 12 entraîne une diminution de la consommation dynamique de la mémoire 12, et plus généralement du système 1 de la figure 1. On tire ici profit du fait que deux transferts de données successifs sur un canal réservé à une application ont généralement certains paramètres identiques.
  • On notera que l'ordre et/ou le nombre des étapes du procédé ci-dessus peuvent être modifiés. Par exemple, tous les bits Ui peuvent d'abord être lus, puis toutes les mises à jour des registres sont effectuées en fonction des valeurs des bits lus.
  • En outre, les modes de réalisation décrits en relation avec les figures 1 à 5 s'appliquent à des banques de registres d'autres circuits qu'un contrôleur d'accès direct en mémoire, pour paramétrer l'exécution d'une tâche par ce circuit.
  • Dans les modes de réalisation décrits ci-dessus, comme c'est généralement le cas dans un circuit de contrôle d'accès direct en mémoire, une fois qu'un canal a été attribué à une application (étape 200, figure 2) et que l'unité centrale 11 a autorisé le circuit 14 à exécuter les transferts de cette application, le circuit 14 effectue tous ces transferts de manière autonome, sans intervention de l'unité centrale 11. Une fois que tous les transferts ont été réalisés, le circuit 14 prévient l'unité centrale 11 qui peut alors attribuer ce canal à une autre application. Ainsi, une synchronisation entre deux applications, exécutées sur deux canaux différents du circuit 14, ne peut être effectuée que par l'unité centrale 11, soit au début de l'exécution d'une des deux applications, soit à la fin de l'exécution d'une des deux applications, quand tous les enregistrements correspondant aux transferts de données de cette application ont été lus et les transferts correspondants effectués.
  • La figure 6 représente, schématiquement et sous forme de blocs, un exemple d'un autre mode de réalisation d'une banque de registres d'un canal de transfert de données du circuit 14.
  • La banque de registres de la figure 6 comprend ici six registres R1, R2, R3, R4, R5 et R6, les registres R1, R2, R3 et R4 de la figure 6 étant, dans cet exemple, similaires aux registres R1, R2, R3 et R4 de la figure 3. Le registre R5 est ici destiné à stocker une condition ctrl-in de début de transfert et un événement ctrl-out de fin de transfert. Le registre R6 constitue le registre de liste chaînée (LLR) de la banque de registres et est, comme en figure 3, destiné à stocker l'adresse NLLI@ d'un enregistrement suivant et les informations relatives à cet enregistrement suivant, notamment le nombre de champs de l'enregistrement et à quel registre est affecté chaque champ de l'enregistrement suivant. Ces informations sont ici stockées sous la forme de six bits U1, U2, U3, U4, U5 et U6 respectivement associés aux registres R1, R2, R3, R4, R5 et R6.
  • La mise à jour de la banque de registres de la figure 6 à partir d'un enregistrement d'une liste chaînée d'enregistrements s'effectue de manière similaire à ce qui a été décrit en relation avec les figures 1 à 5, les enregistrements de la liste étant adaptés en conséquence. En particulier, chaque enregistrement peut comprendre un champ supplémentaire C6 (non illustré) représentatif d'un contenu à programmer dans le registre R6. En outre, pour chaque enregistrement, le champ C6 de l'enregistrement peut alors comprendre six bits correspondant aux six bits U1 à U6 du registre R6.
  • Dans une variante de réalisation, la condition ctrl-in et l'événement ctrl-out sont stockés dans un des registres R1 à R4 et R6, la condition ctrl-in pouvant être stockée dans un autre registre que celui stockant l'événement ctrl-out. Cette variante est par exemple mise en oeuvre quand un ou plusieurs des registres R1 à R4 et R6 contiennent des bits inutilisés permettant alors de stocker ces informations ctrl-in et ctrl-out. Cela permet de supprimer le registre R5, le registre LLR R6 étant alors renuméroté R5.
  • La figure 7 est un organigramme illustrant un mode de réalisation d'un procédé de transfert de données par accès direct en mémoire. Plus particulièrement, la figure 7 illustre plus en détail l'étape 202 du procédé de la figure 2.
  • A une étape 801 (ctrl-in ?) mise en oeuvre par le circuit 14, tous les paramètres du transfert de données à exécuter sont stockés dans les registres de la banque de registres. L'étape 801 consiste en la détection de la condition ctrl-in de début de transfert, stockée dans le registre R5 dans cet exemple. L'étape 801 est répétée (sortie N du bloc 801) tant que cette condition ctrl-in n'est pas détectée. Lorsque la condition ctrl-in est détectée (sortie Y du bloc 801), le procédé se poursuit à une étape 802 (MAKE TRANSFER) au cours de laquelle le transfert de données paramétré par le contenu de la banque de registres est effectué, puis, une fois ce transfert terminé, par une étape 804 (GENERATE ctrl-out) au cours de laquelle l'événement ctrl-out est généré par le circuit 14.
  • Dans ce mode de réalisation, lorsqu'un événement ctrl-out est généré à la fin d'un premier transfert de données sur un premier canal réservé à une première application, et que la condition ctrl-in de début d'un deuxième transfert sur un deuxième canal réservé à une deuxième application correspond à la détection de cet événement ctrl-out, le deuxième transfert ne peut débuter qu'après la génération de l'événement ctrl-out du premier transfert. Ainsi, les premier et deuxième transferts, donc les première et deuxième applications, peuvent être synchronisés l'un par rapport à l'autre, directement au niveau du circuit 14, sans intervention de l'unité centrale 11 et alors que ces applications sont en train d'être exécutées. Plus généralement, la prévision d'une condition ctrl-in et d'un événement ctrl-out pour au moins certains transferts de données de plusieurs applications exécutées par le système 1 permet de synchroniser ces applications entre elles, sans recourir à l'unité centrale qui peut être mise en veille, voire éteinte, pendant l'exécution de ces applications.
  • Dans une variante de réalisation, on prévoit un paramètre supplémentaire indiquant à quel moment doit être détectée la condition ctrl-in lors d'un transfert de plusieurs données, par exemple avant le transfert de la première donnée ou avant le transfert de chaque donnée. De manière similaire, on prévoit un paramètre supplémentaire indiquant à quel moment doit être généré l'événement ctrl-out lors d'un transfert de plusieurs données, par exemple après le transfert de la dernière donnée ou après le transfert de chaque donnée. Les registres et les enregistrements de la liste sont alors adaptés pour intégrer ces paramètres supplémentaires. Le procédé de la figure 7 est également adapté en conséquence. Par exemple, lors d'un transfert de plusieurs données, si la condition ctrl-in est détectée avant chaque transfert d'une donnée et que l'événement ctrl-out est généré après chaque transfert d'une donnée, les étapes 801, 802 et 804 sont mises en oeuvre pour chaque donnée transférée, l'étape 802 correspondant alors au transfert de la donnée.
  • La prévision d'un ou plusieurs paramètres supplémentaires pour indiquer le ou les moments d'un transfert où une condition ctrl-in doit être détectée et le ou les moments où un événement ctrl-out doit être généré permet de contrôler la granularité à laquelle s'effectue la synchronisation entre des applications exécutées en parallèle par le système 1.
  • On notera que la condition ctrl-in d'un transfert sur un canal peut correspondre à la détection d'un événement autre qu'un événement ctrl-out généré lors d'un transfert sur un autre canal, par exemple à la détection d'un événement généré dans le système 1, par exemple issu du bloc 13 (I/O) du système 1.
  • A titre d'exemple, chaque condition ctrl-in peut correspondre à la détection d'un changement de niveau, par exemple le passage d'un niveau haut à un niveau bas ou inversement, d'un signal correspondant à cette condition. Chaque événement ctrl-out consiste par exemple à changer le niveau d'un signal correspondant à cet événement.
  • On notera que le mode de réalisation des figures 6 et 7 peut être mis en oeuvre sans les bits U1 à U6. Dans ce cas, comme il n'y a pas de mise à jour conditionnelle des registres, chaque enregistrement de la liste chaînée contient autant de champs qu'il y a de registres.
  • Dans des variantes de réalisation, les registres et les enregistrements décrits en relation avec les figures 3 à 7 peuvent intégrer un ou plusieurs paramètres supplémentaires de manière à gérer des transferts par blocs de données et/ou, dans une plage d'adresses de source et/ou de destination, des décalages d'adresses entre deux données ou deux blocs de données à transférer successifs.
  • En outre, dans le cas où les registres et les enregistrements sont adaptés de manière à gérer des transferts par blocs de données, on peut prévoir que, lors d'un transfert de plusieurs blocs de données, la condition ctrl-in soit détectée avant le transfert de chaque bloc et/ou que l'événement ctrl-out soit généré après le transfert de chaque bloc. Le ou les paramètres indiquant à quels moments détecter la condition ctrl-in et/ou générer l'événement ctrl-out seront alors adaptés en conséquence, de même que le procédé décrit en relation avec la figure 7.
  • La figure 8 représente, schématiquement et sous forme de blocs, un exemple d'une banque de registres d'un circuit de contrôle d'accès direct en mémoire, selon le mode de réalisation de la figure 6. Dans cette figure 8, seul le registre R5 est représenté, les registres R1 à R4 et R6 étant par exemple identiques à ceux décrits en relation avec la figure 6.
  • Dans ce mode de réalisation, la condition ctrl-in décrite en relation avec la figure 6 comprend un paramètre ctrl-in-req représentatif de l'identification du client du transfert paramétré par le contenu des registres de la banque de registres associée au canal du transfert. Autrement dit, le paramètre ctrl-in-req est représentatif de l'identification de l'élément du système 1, par exemple le bloc fonctionnel 16 (FTC), qui demande le transfert de données. Ainsi, pour chaque transfert correspondant à un enregistrement d'une liste chaînée d'enregistrements, le client du transfert est associé de manière dynamique au canal sur lequel doit avoir lieu le transfert.
  • Plus précisément, l'identification du client d'un transfert revient à identifier quel est le signal de requête qui va provoquer ce transfert. Ainsi, lorsqu'un transfert de données a été paramétré en programmant, à partir d'un enregistrement correspondant d'une liste chaînée d'enregistrements, la banque de registres associée au canal du transfert, ce transfert ne peut débuter qu'après l'émission d'une requête par le client du transfert, ou, autrement dit, le début du transfert est conditionné par cette requête.
  • Dans ce mode de réalisation, le circuit 14 reçoit donc directement les requêtes d'accès en mémoire provenant des clients des transferts de données ayant lieu sur des canaux du circuit 14. Les requêtes sont traitées directement dans le circuit 14, le circuit 14 étant en mesure, sur la base des informations contenues dans les banques de registres associées aux canaux de transfert, de savoir à quel canal doit être transmis chaque requête, ou autrement dit, de savoir pour chaque requête quel est le canal sur lequel le début d'un transfert prévu est conditionné par la réception de cette requête.
  • En comparaison, dans des modes de réalisation dépourvus du paramètre ctrl-in-req, pour qu'un canal du circuit 14 connaisse le client d'un transfert sur ce canal, chaque client potentiel d'un transfert de données, c'est-à-dire chaque élément du système 1 susceptible de demander un transfert de données, est associé de manière statique, par exemple à l'initialisation du système 1, à au moins un canal donné du circuit 14, plusieurs clients pouvant être associés à un même canal. Le système 1 comprend alors, à l'extérieur du circuit DMA 14, un circuit de routage de requêtes configuré pour recevoir toutes les requêtes de transfert de données et pour transmettre, conformément à l'allocation statique client/canal, chaque requête reçue à chaque canal auquel est associé le client ayant émis la requête.
  • Les modes de réalisation comprenant le paramètre ctrl-in-req présentent des avantages par rapport à ceux qui en sont dépourvus.
  • En particulier, la prévision du paramètre ctrl-in-req permet d'éviter le recours à un circuit supplémentaire de routage des requêtes de transfert de données, d'où il résulte que le système 1 consomme moins et occupe une surface réduite par rapport au cas où un tel circuit de routage est prévu.
  • En outre, dans des modes de réalisation comprenant le paramètre ctrl-in-req, une application peut comprendre plusieurs clients, associés de manière dynamique au canal réservé par l'application. En revanche, dans des modes de réalisation sans le paramètre ctrl-in-req, une application ne peut comprendre qu'un seul client du fait de l'allocation statique client/canal. Cette différence, et les avantages qui en découlent, vont être illustrés plus en détail ci-après, en se référant à l'exemple d'exécution suivant où l'on considère que :
    • un premier client effectue des premiers transferts de données avec la mémoire 12, chaque premier transfert correspondant à une écriture, en mémoire, d'une donnée provenant du premier client ;
    • un deuxième client effectue des deuxièmes transferts de données avec la mémoire 12, chaque deuxième transfert correspondant à une lecture, par le deuxième client, d'une donnée stockée dans la mémoire ; et
    • après chaque écriture d'une donnée en mémoire lors d'un premier transfert, cette donnée est lue en mémoire lors d'un deuxième transfert, de sorte qu'un deuxième transfert ne peut avoir lieu qu'après un premier transfert correspondant.
  • Dans un mode de réalisation comprenant le paramètre ctrl-in-req, la mise en oeuvre de l'exemple d'exécution ci-dessus peut être faite au moyen d'une unique application comprenant les premiers et deuxièmes transferts, donc les premier et deuxième clients. Autrement dit, une même liste chaînée d'enregistrements peut être utilisée pour configurer les premiers et deuxièmes transferts sur un même canal. Plus précisément, un premier transfert est configuré en programmant les paramètres, et en particulier le paramètre ctrl-in-req, de ce premier transfert dans les registres de la banque de registres du canal. L'émission d'une requête par le premier client entraîne alors la mise en oeuvre de ce premier transfert sur ce canal, puis un deuxième transfert est configuré, sur ce même canal, en programmant les paramètres, et en particulier le paramètre ctrl-in-req, de ce deuxième transfert dans les registres de la banque de registres du canal. L'émission d'une requête par le deuxième client entraîne alors la mise en oeuvre de ce deuxième transfert sur ce canal. L'exécution se poursuit en répétant, pour ce canal, les étapes de programmation des registres avec les paramètres d'un premier transfert, de réception d'une requête du premier client, de mise en oeuvre du premier transfert sur le canal, de programmation des registres avec les paramètres d'un deuxième transfert, de réception d'une requête du deuxième client et de mise en oeuvre du deuxième transfert sur le canal.
  • En revanche, dans un mode de réalisation ne comprenant pas le paramètre ctrl-in-req, la mise en oeuvre de cet exemple d'exécution est faite au moyen d'une première application correspondant aux premiers transferts, c'est-à-dire au premier client, et d'une deuxième application correspondant aux deuxièmes transferts, donc au deuxième client. Autrement dit, une première liste chaînée d'enregistrements est utilisée pour configurer les premiers transferts sur un premier canal auquel le premier client est associé de manière statique, une deuxième liste chaînée d'enregistrements étant utilisée pour configurer les deuxièmes transferts sur un deuxième canal auquel le deuxième client est associé de manière statique. Il en résulte que, lors d'un premier transfert sur le premier canal, le deuxième canal est réservé par la deuxième application mais n'est pas utilisé.
  • On comprend de l'exemple d'exécution ci-dessus que la prévision du paramètre ctrl-in-req permet une association dynamique des clients à des canaux du circuit 14, d'où il résulte une diminution du temps où un canal est réservé mais n'est pas utilisé et/ou une diminution du nombre de canaux nécessaires. En particulier, la diminution du nombre de canaux de circuit 14 entraîne une diminution de la consommation et de la surface du circuit 14, et plus généralement du système 1.
  • La figure 9 représente, schématiquement et sous forme de blocs, une variante de réalisation de la banque de registres de la figure 8.
  • Dans cette variante, en plus du paramètre ctrl-in-req, la condition ctrl-in comprend un paramètre ctrl-in-req-mode indiquant, pour le transfert paramétré par le contenu de la banque de registres, au moins un moment du transfert où doit être reçue la requête du client identifié par le paramètre ctrl-in-req. Autrement dit, lorsque le transfert paramétré par le contenu de la banque de registres correspond à plusieurs transferts similaires, par exemple plusieurs transferts de données ou de blocs de données, le paramètre ctrl-in-req-mode indique lequel ou lesquels de ces transferts similaires sont conditionnés par la réception d'une requête en provenance du client du transfert. Par exemple, pour un transfert comprenant le transfert de plusieurs données ou de plusieurs blocs de données, le paramètre ctrl-in-req-mode indique qu'une requête du client doit être reçue avant chaque transfert de données, avant chaque transfert de blocs de données, ou uniquement avant le transfert de la première donnée ou du premier bloc de données. Dans ce dernier cas, les transferts de données ou de blocs de données suivant le transfert de la première donnée ou du premier bloc de données peuvent être réalisés sans qu'une requête n'ait été émise par le client du transfert.
  • On considère à titre d'exemple plusieurs transferts similaires, par exemple plusieurs transferts d'une donnée ou d'un bloc de données, ayant le même client, et, en outre, que chacun de ces transferts similaires ne doit débuter qu'une fois qu'une requête du client a été reçue par le circuit 14, ou, autrement dit, que chacun de ces transferts est conditionné par l'émission d'une requête par le client. La prévision du paramètre ctrl-in-req-mode permet que ces transferts similaires soient regroupés sous la forme d'un seul enregistrement d'une liste chaînée d'enregistrements, une seule mise à jour de la banque de registres associée au canal du transfert étant alors effectuée pour paramétrer l'ensemble de ces transferts similaires. Sans le paramètre ctrl-in-req-mode, il aurait fallu que chacun des transferts similaires corresponde à un enregistrement différent de la liste.
  • La variante de réalisation décrite en relation avec la figure 9 permet donc de réduire le nombre d'enregistrements d'une liste, ce qui peut permettre de diminuer la taille de la mémoire 12. Cette variante permet également de réduire le nombre d'accès à la mémoire 12 et de mises à jour des banques de registres associées aux canaux du circuit 14.
  • La figure 10 représente, schématiquement et sous forme de blocs, un autre exemple d'une banque de registres d'un circuit de contrôle d'accès direct en mémoire, selon le mode de réalisation de la figure 6. Dans cette figure 10, seul le registre R5 est représenté, les registres R1 à R4 et R6 étant par exemple identiques à ceux décrits en relation avec la figure 6.
  • Par rapport au mode de réalisation décrit en relation avec la figure 8, on prévoit que la condition ctrl-in de début de transfert comprenne, en plus du paramètre ctrl-in-req, un paramètre ctrl-in-trig représentatif d'une identification d'un signal conditionnant le début du transfert, un paramètre ctrl-in-trig-mode représentatif du ou des moments où doit être détectée une modification de ce signal, et un paramètre ctrl-in-trig-pol optionnel représentatif du type de modification, à savoir front montant, front descendant ou changement de niveau, du signal conditionnant le début du transfert. Autrement dit, lorsque le transfert paramétré par le contenu de la banque de registres correspond à plusieurs transferts similaires, par exemple plusieurs transferts de données ou de blocs de données, le paramètre ctrl-in-trig-mode indique lequel ou lesquels de ces transferts similaires sont conditionnés par la détection d'une modification du signal identifié par le paramètre ctrl-in-trig, le type (ou polarité) de cette modification étant ici indiqué par le paramètre ctrl-in-trig-pol. Par exemple, pour un transfert comprenant le transfert de plusieurs données ou de plusieurs blocs de données, le paramètre ctrl-in-trig-mode indique qu'une modification du signal identifié par le paramètre ctrl-in-trig doit être détectée avant chaque transfert de données, avant chaque transfert de blocs de données, ou uniquement avant le transfert de la première donnée ou du premier bloc de données. Par ailleurs, le paramètre ctrl-in-trig-mode peut également indiquer que, pour le transfert courant paramétré par le contenu de la banque de registres associée au canal du transfert, le transfert n'est pas conditionné par la détection d'une modification d'un signal identifié par le paramètre ctrl-in-trig.
  • Dans ce mode de réalisation, un transfert de données paramétré par le contenu de la banque de registres associée au canal du transfert ne peut débuter qu'après la réception de la requête du client du transfert par le circuit 14 et, le cas échéant, la détection, par le circuit 14, d'une modification du signal identifié par le paramètre ctrl-in-trig, le type de cette modification étant, dans cet exemple, indiqué par le paramètre ctrl-in-trig-pol. En outre, lorsque ce transfert correspond à plusieurs transferts similaires, le début de chacun de ces transferts similaires peut ou non être conditionné, conformément aux paramètres ctrl-in-trig-mode et/ou ctrl-in-req-mode, à la réception d'une requête provenant du client du transfert et/ou à la détection d'une modification d'un signal identifié par le paramètre ctrl-in-trig.
  • Dans ce mode de réalisation, on considère par ailleurs que, pour chaque canal, l'événement ctrl-out de fin de transfert est une modification d'un signal de fin de transfert associé à ce canal. L'événement ctrl-out comprend ici un paramètre ctrl-out-mode représentatif du ou des moments où le signal de fin de transfert du canal doit être modifié, et un paramètre ctrl-out-pol optionnel représentatif de la polarité de modification du signal, c'est-à-dire si l'événement de fin de transfert est un front montant, un front descendant ou un changement de niveau du signal de fin de transfert associé au canal considéré.
  • A titre d'exemple, le paramètre ctrl-out-mode indique que le moment où doit être générée la condition ctrl-out, c'est-à-dire le moment où doit être modifié le signal de fin de transfert associé au canal, est uniquement après le transfert de la dernière donnée ou du dernier bloc de données, après le transfert de chaque donnée ou de chaque bloc de données, ou à aucun moment de ce transfert.
  • A titre d'exemple, le signal identifié par le paramètre ctrl-in-trig peut être le signal de fin de transfert d'un canal ou tout autre signal interne du système 1, par exemple un signal d'événement fourni par un élément du système 1, par exemple un compteur du système 1.
  • La variante de réalisation décrite en relation avec la figure 9 s'applique à l'exemple de mode de réalisation décrit en relation avec la figure 10.
  • Dans d'autres variantes de réalisation, de la même façon qu'un paramètre ctrl-in-trig-pol peut être prévu pour indiquer quel est le type de modification du signal identifié par le paramètre ctrl-in-trig qui conditionne des transferts de données, un paramètre ctrl-in-req-pol peut être prévu pour indiquer quel type de modification d'un signal de requête constitue une requête de la part d'un client associé à ce signal de requête. De plus, chacun des paramètres ctrl-in-trig-pol et ctrl-in-req-pol peut être représentatif non seulement d'un type donné de modification (front montant, front descendant ou changement de niveau) mais également d'un niveau haut ou bas à détecter sur le signal ou la requête correspondante. On notera que, en l'absence du paramètre ctrl-in-trig-pol et/ou du paramètre ctrl-in-req-pol, la polarité peut être définie par défaut.
  • Dans d'autres variantes de réalisation non détaillées, certains des paramètres ctrl-in-trig, ctrl-in-trig-mode, ctrl-in-trig-pol, ctrl-in-req, ctrl-in-req-mode, ctrl-in-req-pol, ctrl-out-mode et ctrl-out-pol peuvent être omis. En particulier, les paramètres ctrl-in-trig, ctrl-in-trig-mode, ctrl-in-trig-pol, ctrl-out-mode et/ou ctrl-out-pol peuvent être prévus indépendamment du ou des paramètres ctrl-in-req, ctrl-in-req-mode, ctrl-in-req-pol, et inversement.
  • Bien que les paramètres ctrl-in-trig, ctrl-in-trig-mode, ctrl-in-trig-pol, ctrl-in-req, ctrl-in-req-mode, ctrl-in-req-pol, ctrl-out-mode et/ou ctrl-out-pol sont de préférence stockés dans un même registre, ou autrement dit proviennent d'un même champ d'un enregistrement d'une liste chaînée d'enregistrements, ces paramètres peuvent être stockés dans des registres différents.
  • Les modes de réalisation des figures 8, 9 et 10 peuvent être mis en oeuvre sans les bits U1 à U6. Dans ce cas, comme il n'y a pas de mise à jour conditionnelle des registres, chaque enregistrement de la liste chaînée contient autant de champs qu'il y a de registres.
  • On comprend de la description ci-dessus faite en relation avec les figures 7 à 10 que la condition ctrl-in est en fait au moins en partie déterminée par le paramètre ctrl-in-req et/ou au moins en partie déterminée par le paramètre ctrl-in-trig. En outre, le moment ou les moments de détection d'une condition ctrl-in, en particulier lors d'un transfert correspondant à plusieurs transferts similaires, sont au moins en partie déterminés par le paramètre ctrl-in-req-mode et/ou au moins en partie déterminés par le paramètre ctrl-in-trig-mode.
  • Le procédé de la figure 7 et les enregistrements décrits en relation avec les figures 1 à 5 peuvent être adaptés aux modes de réalisation et variantes décrits en relation avec les figures 8, 9 et 10, à partir des indications fonctionnelles données ci-dessus.
  • Le nombre de registres, le nombre de paramètres stockés par la banque de registres et/ou le nombre de paramètres stockés par chaque registre peuvent varier.
  • Par ailleurs, d'autres paramètres peuvent être prévus. Par exemple, dans le cas d'un transfert de données par accès direct en mémoire, un paramètre peut indiquer si les données et/ou les blocs de données du transfert correspondant à un enregistrement doivent être transférés au coup par coup ou par salve ("burst").

Claims (9)

  1. Mémoire (12) contenant au moins une liste chaînée d'enregistrements représentative de plusieurs transferts de données par un circuit (14) de contrôle d'accès direct en mémoire, chaque enregistrement (LLI-1, LLI-2, LLI-3) étant représentatif de paramètres (S@, D@, NB, BL, NLLI@, ctrl-in, ctrl-in-req, ctrl-in-trig, ctrl-in-trig-mode, ctrl-in-req-mode, ctrl-in-trig-pol, ctrl-out, ctrl-out-mode, ctrl-out-pol) d'un transfert de données correspondant parmi lesdits plusieurs transferts, les paramètres dudit transfert de données comprenant une condition de début (ctrl-in, ctrl-out, ctrl-in-req, ctrl-in-trig, ctrl-in-req-mode, ctrl-in-trig-mode, ctrl-in-trig-pol) dudit transfert de données et un événement de fin (ctrl-out, ctrl-out-mode, ctrl-out-pol) dudit transfert de données, dans laquelle la condition de début dudit transfert comprend et est au moins en partie déterminée par :
    une identification (ctrl-in-req) d'un client dudit transfert identifiant un signal de requête provoquant ledit transfert ;
    une indication (ctrl-in-req-mode) d'au moins un moment dudit transfert où une réception du signal de requête (ctrl-in-req) conditionne ledit transfert ;
    une identification (ctrl-in-trig) d'un signal de début de transfert ; et
    une indication (ctrl-in-trig-mode) soit que le transfert n'est pas conditionné par la détection d'une modification du signal de début de transfert, soit d'au moins un moment dudit transfert où une détection d'une modification du signal de début de transfert conditionne ledit transfert, et dans laquelle l'événement de fin de transfert (ctrl-out) comprend une indication (ctrl-out-mode) soit d'au moins un moment dudit transfert où l'événement doit être généré, soit que ledit événement n'est pas généré pendant ledit transfert, ledit événement étant une modification d'un signal de fin dudit transfert.
  2. Mémoire selon la revendication 1, dans laquelle chaque enregistrement (LLI-1, LLI-2, LLI-3) contient un premier champ (C5) déterminant le nombre de champs (C1, C2, C3, C4, C5) de l'enregistrement suivant, chaque champ d'un enregistrement étant représentatif d'un contenu à programmer dans un registre (R1, R2, R3, R4, R5) d'une banque de registres du circuit (14) de contrôle d'accès direct en mémoire.
  3. Mémoire selon la revendication 2, dans laquelle le premier champ (C5) détermine dans quels registres (R1, R2, R3, R4, R5) doivent être programmés lesdits contenus, le premier champ (C5) comprenant de préférence des bits (U1, U2, U3, U4, U5) dont chacun identifie un registre, les valeurs desdits bits déterminant les champs (C1, C2, C3, C4, C5) de l'enregistrement à programmer.
  4. Mémoire selon l'une quelconque des revendications 1 à 3, dans laquelle, pour chaque enregistrement (LLI-1, LLI-2, LLI-3), les paramètres comprennent une indication que ledit transfert de données correspondant est un transfert d'une donnée, de plusieurs données, d'un bloc de données ou de plusieurs blocs de données.
  5. Mémoire selon la revendication 4, dans laquelle ledit au moins un moment où une réception du signal de requête (ctrl-in-req) conditionne ledit transfert est sélectionné parmi : avant chaque transfert d'une donnée, uniquement avant le transfert de la première donnée, avant le transfert de chaque bloc de données et uniquement avant le transfert du premier bloc de données.
  6. Procédé de transfert de données par accès direct en mémoire dans lequel des transferts de données sont effectués sur un canal d'un circuit (14) de contrôle d'accès direct en mémoire, chaque transfert de données sur ce canal étant paramétré par un enregistrement (LLI-1, LLI-2, LLI-3) correspondant d'une liste d'une mémoire (12) selon l'une quelconque des revendications 1 à 5.
  7. Procédé selon la revendication 6, dans lequel chaque enregistrement (LLI-1, LLI-2, LLI-3) de la liste correspond à une mise à jour d'une banque de registres (R1, R2, R3, R4, R5) associée au canal.
  8. Procédé selon la revendication 7, dans lequel un contenu courant de la banque de registres (R1, R2, R3, R4, R5) paramètre ledit transfert de données correspondant sur le canal.
  9. Système électronique comprenant une mémoire (12) selon l'une quelconque des revendications 1 à 5, et un circuit de contrôle d'accès direct en mémoire (14) muni de plusieurs canaux dont chacun est associé à une banque de registres, le circuit étant configuré pour mettre en oeuvre le procédé selon l'une quelconque des revendications 6 à 8.
EP19186868.6A 2018-07-19 2019-07-17 Accès direct en mémoire Active EP3598315B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1856705A FR3084179A1 (fr) 2018-07-19 2018-07-19 Acces direct en memoire
FR1871349A FR3084178A1 (fr) 2018-07-19 2018-11-02 Acces direct en memoire

Publications (2)

Publication Number Publication Date
EP3598315A1 EP3598315A1 (fr) 2020-01-22
EP3598315B1 true EP3598315B1 (fr) 2022-12-28

Family

ID=67226198

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19186868.6A Active EP3598315B1 (fr) 2018-07-19 2019-07-17 Accès direct en mémoire

Country Status (2)

Country Link
US (1) US11593289B2 (fr)
EP (1) EP3598315B1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080228896A1 (en) * 2007-03-15 2008-09-18 Broadcom Corporation Pipelined buffer interconnect with trigger core controller

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3268591B2 (ja) 1995-11-22 2002-03-25 株式会社日立製作所 グラフィックスプロセッサでの並列処理方法
JPH1040211A (ja) * 1996-04-30 1998-02-13 Texas Instr Inc <Ti> パケット化されたデータ通信インタフェース機器内での直接メモリアクセス優先順位を割り当てるための方法ならびにｄｍａチャンネル回路
US6092116A (en) * 1996-12-11 2000-07-18 Lsi Logic Corporation DMA controller with response message and receive frame action tables
US6700588B1 (en) * 1998-11-09 2004-03-02 Broadcom Corporation Apparatus and method for blending graphics and video surfaces
US6573905B1 (en) * 1999-11-09 2003-06-03 Broadcom Corporation Video and graphics system with parallel processing of graphics windows
US7446774B1 (en) * 1998-11-09 2008-11-04 Broadcom Corporation Video and graphics system with an integrated system bridge controller
US6782465B1 (en) 1999-10-20 2004-08-24 Infineon Technologies North America Corporation Linked list DMA descriptor architecture
US7065628B2 (en) * 2002-05-29 2006-06-20 Intel Corporation Increasing memory access efficiency for packet applications
CN1826611A (zh) * 2003-07-01 2006-08-30 夸德拉特公司 电子预约安排
US8112618B2 (en) * 2004-04-08 2012-02-07 Texas Instruments Incorporated Less-secure processors, integrated circuits, wireless communications apparatus, methods and processes of making
US20060050693A1 (en) * 2004-09-03 2006-03-09 James Bury Building data packets for an advanced switching fabric
CN101160825B (zh) * 2005-02-01 2011-04-27 香港应用科技研究院有限公司 有效处理通信流量的系统和方法
US20060259657A1 (en) * 2005-05-10 2006-11-16 Telairity Semiconductor, Inc. Direct memory access (DMA) method and apparatus and DMA for video processing
US20070162647A1 (en) * 2005-12-19 2007-07-12 Via Technologies, Inc. System and Method for Performing Scatter/Gather Direct Memory Access Transfers
JP5423483B2 (ja) 2010-03-04 2014-02-19 株式会社リコー データ転送制御装置
WO2013048986A1 (fr) * 2011-09-26 2013-04-04 Knoa Software, Inc. Procédé, système et progiciel d'affectation et/ou d'établissements des priorités applicables à des ressources électroniques
US8990177B2 (en) * 2011-10-27 2015-03-24 Yahoo! Inc. Lock-free transactional support for large-scale storage systems
KR101693174B1 (ko) * 2011-12-29 2017-01-17 인텔 코포레이션 바이오메트릭 클라우드 통신 및 데이터 이동
AU2014280856A1 (en) * 2013-06-14 2016-04-21 Ensemble Partners Pty Limited Creating and displaying a work sequence
US20150186068A1 (en) 2013-12-27 2015-07-02 Sandisk Technologies Inc. Command queuing using linked list queues
US10417364B2 (en) * 2017-01-04 2019-09-17 Stmicroelectronics International N.V. Tool to create a reconfigurable interconnect framework
US10191871B2 (en) 2017-06-20 2019-01-29 Infineon Technologies Ag Safe double buffering using DMA safe linked lists
US10621163B2 (en) * 2017-12-07 2020-04-14 Facebook, Inc. Tracking and reusing function results
FR3084179A1 (fr) 2018-07-19 2020-01-24 Stmicroelectronics (Grenoble 2) Sas Acces direct en memoire

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080228896A1 (en) * 2007-03-15 2008-09-18 Broadcom Corporation Pipelined buffer interconnect with trigger core controller

Also Published As

Publication number Publication date
US20200026672A1 (en) 2020-01-23
US11593289B2 (en) 2023-02-28
EP3598315A1 (fr) 2020-01-22

Similar Documents

Publication Publication Date Title
FR2844613A1 (fr) Systeme pour le transfert rapide des donnees
EP0434483B1 (fr) Processeur à plusieurs unités de traitement microprogrammées
CH616252A5 (fr)
FR2881540A1 (fr) Procede et systeme destines a empecher que des lignes de memoire cache soient videes jusqu&#39;a ce que les donnees stockees dans celles-ci ne soient utilisees.
EP0020983A1 (fr) Système de mémoire comportant un dispositif d&#39;emmagasinage sérié
FR2697663A1 (fr) Circuit de test de mémoire.
FR3089649A1 (fr) Procédé et dispositif de détermination de la taille mémoire globale d’une zone mémoire globale allouée aux données d’un réseau de neurones
FR3045183A1 (fr) Procede de prediction d&#39;une donnee a precharger dans une memoire cache
EP3598315B1 (fr) Accès direct en mémoire
FR3084178A1 (fr) Acces direct en memoire
EP3805947A1 (fr) Procédé de gestion d&#39;une base de données partagée par un groupe d&#39;applications, produit programme d&#39;ordinateur et système embarqué associés
EP1594065A1 (fr) Système sur une puce avec unité d&#39;arbitrage, et clé de stockage l&#39;incorporant
CA2352420A1 (fr) Dispositif de gestion de memoire permettant l&#39;inscription de blocs de donnees par substitution
EP3716086B1 (fr) Accès direct en mémoire
EP2726985B1 (fr) Dispositif et procede de synchronisation de taches executees en parallele sur une plateforme comprenant plusieurs unites de calcul
CA2297276C (fr) Procede et dispositif de reception et pretraitement de messages
EP2666092B1 (fr) Systeme multi-coeurs et procede de coherence de donnees
EP3611623B1 (fr) Contrôleur mémoire comprenant deux buffers et un selecteur d&#39;un mode de remplissage desdits buffers
EP0733977B1 (fr) Système informatique avec mémoires hiérarchisées
FR3033420A1 (fr) Procede de gestion de donnees relatives a une mission d&#39;aeronefs et module de gestion de donnees correspondant
WO2014135770A1 (fr) Procede de gestion de donnees relatives a des vehicules automobiles en vue de la generation graphique ulterieure de schemas electriques de systemes electriques
CN109871355A (zh) 一种快照元数据存储方法、装置及设备、介质
CA2067890A1 (fr) Procede et dispositif de selection d&#39;informations utilisables par une unite locale reliee a un systeme de transmission numerique
FR3100907A1 (fr) Test de programme
EP4055485A1 (fr) Procédé pour exécuter une transaction

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

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20190717

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210121

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20220309

GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTC Intention to grant announced (deleted)
INTG Intention to grant announced

Effective date: 20220729

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

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

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602019023601

Country of ref document: DE

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1540929

Country of ref document: AT

Kind code of ref document: T

Effective date: 20230115

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230328

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20221228

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1540929

Country of ref document: AT

Kind code of ref document: T

Effective date: 20221228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230329

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230428

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230428

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602019023601

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20230620

Year of fee payment: 5

26N No opposition filed

Effective date: 20230929

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221228

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20230731

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230717

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20230717

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230717

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230731

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230717