KR20210051325A - Device and method for sharing data on an asymmetric multi-processing system - Google Patents

Abstract

The present invention relates to a device and a method for sharing data on an asymmetric multi-processing system, capable of improving a system response by connecting predetermined information of a shared memory to a communication framework. The device for sharing the data on the asymmetric multi-processing system includes; a plurality of cores employing mutually different operating systems (OS); and the shared memory shared between the plurality of cores. Shared data are transmitted or received by the communication framework of each of the plurality of cores. The plurality of cores further include a shared data processing framework that allocates an area for storing the shared memory in addition to the communication frame, and allocates an area for storing a memory map having information on a storage address and a size of the shared data. A core performing a receive process may read and use the shared data, based on the memory map.

Description

Device and method for sharing data on an asymmetric multi-processing system

The present invention relates to an apparatus and method for sharing data in an asymmetric multiprocessing system, and more particularly, to an apparatus and method for sharing repetitive and fixed data at high speed.

Multi-Processing System (Multi-Processing System) is a system that processes one task in parallel using multiple processors.

Multi-processing systems are faster than single processing systems because multiple processors share peripheral devices and process tasks in parallel, and even if an error occurs in one processor, work can be performed without stopping the system, increasing reliability. There are features that can be used.

Multi-processing systems are divided into symmetric multi-processing (SMP) and asymmetric multi-processing (AMP).

Symmetrical multi-processing is that multiple processors execute a single program, and all processors are managed by one operating system (OS).

On the other hand, asymmetric multiprocessing is configured to perform a specific task assigned to each of a plurality of processors, and the main processor controls the entire system, and other processors are configured to follow the control of the main processor or perform a specified task. In other words, the processors form a master-slave system.

In particular, recently, asymmetric multi-processing systems are designed to exhibit high overall performance in various systems by integrating different types of processor cores. System responsiveness and compatibility and data processing efficiency can be optimized by applying different OS for each processor.

For example, for functions that prioritize responsiveness, non-OS or Real Time OS (RTOS)-based systems are assigned to specific processors, and for functions that prioritize compatibility and efficiency, a high-level operating system such as Linux is assigned to the rest of the processors. Can be applied.

As such, the asymmetric multiprocessing system in which different operating systems are allocated requires a special inter-process communication (IPC) framework due to differences in operating systems. These inter-process communication frameworks include Hypervisor, Multicore Communication API (MCAPI), and OpenAMP, an open source developed by Mento Graphics, and shared memory and message queues. Use a method of sharing data using.

Hereinafter, a conventional asymmetric multiprocessing system using OpenAMP will be described in detail.

1 is a block diagram of a general asymmetric multiprocessing system.

FIG. 1 shows an example of an asymmetric multiprocessing system including first and second cores Core1 and Core2 using a specific operating system OS1 such as Linux and an RT Core using an RTOS.

The first and second cores Core1 and Core2 implement symmetric multiprocessing (SMP), and comprise an RT core, forming an asymmetric multiprocessing system.

One processor includes at least one core and a cache memory, and the first and second cores Core1 and Core2 of FIG. 1 may be understood as being of a single or two processors.

Since the first and second cores Core1 and Core2 use OS1, which is the same operating system, memory and various devices can be recognized as a single object and can be easily shared and used.

However, since the first and second cores Core1 and Core2 and the RT core use different OSs, they do not share an independent memory space and a device with each other, making it difficult to share data and manage resources.

The first and second cores (Core1, Core2) and the RT core (RT Core) share a shared memory 10, and perform data communication between cores using different operating systems through the shared memory 10 For this, the OpenAMP framework has been proposed.

2 is a block diagram of the OpenAMP framework.

Referring to FIG. 2, a master application is a process performed in a first core (Core1) or a second core (Core2), and a remote application is a process performed in an RT core.

The above two processes share data by sending and receiving messages through the shared memory 10 using the OpenAMP framework 20.

The OpenAMP framework can be expressed as a protocol layer divided into three areas.

3 is a layer block diagram of the OpenAMP framework.

The OpenAMP framework layer is a transport layer (Transport Layer, 21) in which an API (RPMsg) for message transmission in a master or remote application is defined, a media access layer (MAC Layer, 22) for message queue management, and data transmission. It is divided into a physical layer (23) in which the medium of is defined.

The OpenAMP framework makes it possible to share messages (data) between processors using the shared memory 10.

The core of the transmitting processor copies and records the transmission message in the shared memory 10, and generates an interrupt in the core of the receiving processor to notify that the message has been transmitted. The receiving process core recognizing the interrupt copies the message of the transmitting processor core stored in the shared memory 10 to the memory space of the receiving process through the OpenAMP framework.

4 is an exemplary diagram of message exchange between a first core (Core 1) and an RT core (RT Core) in FIG. 1.

When the first core (Core 1) is the transmitting side and the RT core is the receiving side, the first core (Core 1) stores the transmission message in the allocated area of the shared memory 10, and the RT core By generating an interrupt in the shared memory 10, the RT core can recognize that there is a transmission message.

Then, the RT core calls the transmission message stored in the shared memory 10 and stores it in the processor internal memory (RAM in FIG. 1).

On the contrary, when the RT Core is the transmitting side and the first core is the receiving side, the RT Core stores the transmission message in the shared memory 10, and the first core (Core 1) The first core (Core 1) calls the transmission message of the RT core (RT Core) from the shared memory 10 and stores it in the cache memory shown in FIG.

In this way, message transmission/reception between cores using different OSes is possible using the OpenAMP framework.

The shared memory 10 is used through the physical layer 23 of the OpenAMP framework.

5 is a configuration diagram of the media access layer 22 of the OpenAMP framework 20.

The media access layer 22 is defined for efficient use of the shared memory 10, and a ring buffer type message queue technique is applied.

The process of allocating and releasing memory buffers for message transmission and reception between cores described above is involved.

The media access layer 22 is a core part of the entire OpenAMP framework, and synchronization between cores is not required by the media access layer 22. This is achieved by a technique called single writer-single reader circular buffering.

This technique provides a structure in which multiple asynchronous contexts can exchange data.

In FIG. 5, the VRING element consists of three basic configurations: “buffer descriptor”, “usable ring buffer”, and “used ring buffer”, and these three elements are physically stored in the shared memory 10.

The buffer descriptor includes a 64-bit buffer address, which is composed of an address for a buffer of up to 32 bits stored in the shared memory 10, a flag field of 16 bits, and a link with the next buffer script of 16 bits.

The input ring buffer contains its own flag field in which only the 0th bit is used, and when its own flag field is set, the transmitter does not notify the input or available ring buffer.

Basically, since the bit is not set, the sending side must generate an interrupt and notify the receiving side.

The structure of the transport layer 21 defining a message protocol applied to the OpenAMP framework is as shown in FIG. 6.

A source address represents a transmission process, a destination address represents a reception process, and data shared between the two processes is shared through a payload area.

The message is transmitted through an area of the shared memory 10 allocated through the media access layer 22 in the transmission process, and is implemented so that the receiving processor releases the allocated memory after receiving the message.

That is, in order to share data between two processors, data located in the memory area of the transmitting processor must be copied to the payload area, and the receiving side must copy the data stored in the payload to the memory area of the receiving processor.

In this way, the OpenAMP framework divides the shared memory area and allocates a buffer when transmitting a message, and provides the allocation location to the receiver, thereby improving memory reuse efficiency.

However, a process for allocating and releasing a partial area of the shared memory 10 is required, and a system overhead is required to repeatedly copy to the shared memory several times for message transmission.

In addition, in order to increase memory efficiency, the size of the message queue is limited to a certain size or less, so when transmitting a large amount of information, it must be divided and transmitted several times, and the overhead due to such divided transmission increases.

In particular, in implementing a product that requires a fast system response, the overhead acts as a constraint on the application of an asymmetric multi-process system, and there is a problem in that it is not possible to construct the system structurally or the complexity of the implementation is rapidly increased.

The problem to be solved by the present invention in consideration of the above problems is to provide a data sharing apparatus and method of an asymmetric multiprocessing system capable of minimizing the occurrence of overhead in an asymmetric multiprocessor system operated by heterogeneous operating systems. have.

In more detail, the present invention is to provide an apparatus and method for sharing data of an asymmetric multiprocessing system capable of improving system responsiveness by combining information of a predetermined shared memory with a communication framework.

In particular, to provide a data sharing apparatus and method of an asymmetric multiprocessing system capable of remarkably improving response performance when shared data between transmission and reception processors is in a fixed form, and is repeatedly transmitted or when data is large.

A data sharing apparatus of an asymmetric multiprocessing system according to an aspect of the present invention for solving the above technical problems includes a plurality of cores using different operating systems, and a shared memory shared by the plurality of cores. In the data sharing apparatus of an asymmetric multiprocessing system for transmitting and receiving shared data by a communication framework of each of a plurality of cores, the plurality of cores allocate an area in which shared data is stored in the shared memory in addition to the communication framework And a shared data processing framework for allocating an area for storing a memory map, which is information on a storage address and size of shared data, and reads the shared data by referring to the memory map in a core performing a receiving process. Can be used.

In an embodiment of the present invention, the shared memory includes areas each storing processes of the cores, a communication memory area in which the communication framework is executed, and a shared data memory area in which the shared data processing framework is executed. Can be distinguished.

In an embodiment of the present invention, the shared data memory area may be divided into a memory map information area for storing the memory map and a shared data area for storing shared data when performing processes by the cores.

In an embodiment of the present invention, when the shared memory is not a single port RAM or a double port RAM, the shared data memory area may further include an access control area in which access restriction information of the memory is stored.

In an embodiment of the present invention, the address of the memory map may be an index or an offset address.

In an embodiment of the present invention, a method of reading shared data in the shared data area in the transmission process can be read through a hardware direct memory access, a cached memory access, or a direct memory access.

In addition, a data sharing method of an asymmetric multiprocessing system according to another aspect of the present invention is a method of sharing data using a data sharing device of the asymmetric multiprocessing system, a) sharing in a shared data area set in a transmission process. Storing data; b) creating a memory map including address and size information of the stored shared data and storing it in the memory map information area; c) making the receiving process aware that the data is stored; and , d) reading and receiving the shared data at the receiving process side.

In an embodiment of the present invention, in the data sharing processing framework of the transmission process, it may further include the step of restricting access to the shared data stored in the shared data area, thereby preventing a plurality of processes from accessing the same shared data at the same time. Can be

In an embodiment of the present invention, the step of restricting access to shared data may use a shared resource protection scheme such as a mutex, a semaphore, or a flag.

In an embodiment of the present invention, the address of the memory map may use an index or an offset address.

In an embodiment of the present invention, step d) may use a hardware direct memory access, a cached memory access, or a direct memory access.

The present invention reduces the frequency of setting and canceling memory buffers by combining a communication framework for data sharing and a framework for providing information on a predefined shared memory in a system including processors operated by heterogeneous operating systems. By reducing the occurrence of overhead, there is an effect of improving system responsiveness.

1 is a block diagram of a general asymmetric multiprocessing system.
2 is a block diagram of the OpenAMP framework.
3 is a layer block diagram of the OpenAMP framework.
4 is an exemplary diagram of message exchange between cores using a heterogeneous OS.
5 is a configuration diagram of a media access layer of the OpenAMP framework.
6 is a configuration diagram of a transport layer of the OpenAMP framework.
7 is a block diagram of an apparatus for sharing data in an asymmetric multiprocessing system according to the present invention.
8 is a layer configuration diagram of a first shared data processing framework of a first core.
9 is a block diagram of a shared memory area according to an exemplary embodiment of the present invention.
10 is an explanatory diagram showing a relationship between shared data stored in a shared data area and a memory map stored in a memory map information area.
11 is an explanatory diagram showing the function of a transmission/reception area.

In order to fully understand the configuration and effects of the present invention, preferred embodiments of the present invention will be described with reference to the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various forms and various modifications may be made. However, the description of the present embodiment is provided to complete the disclosure of the present invention, and to fully inform the scope of the invention to those of ordinary skill in the art to which the present invention pertains. In the accompanying drawings, for convenience of explanation, the size of the components is enlarged compared to the actual one, and the ratio of each component may be exaggerated or reduced.

Terms such as'first' and'second' may be used to describe various elements, but the elements should not be limited by the above terms. The above terms can be used only for the purpose of distinguishing one component from another component. For example, without departing from the scope of the rights of the present invention, the'first element' may be referred to as the'second element', and similarly, the'second element' may also be named as the'first element'. I can. In addition, expressions in the singular include plural expressions unless clearly expressed otherwise in the context. Terms used in the embodiments of the present invention may be interpreted as meanings commonly known to those of ordinary skill in the art, unless otherwise defined.

Hereinafter, an error tracking method of a motion controller according to an embodiment of the present invention will be described in detail with reference to the drawings.

7 is a block diagram of an apparatus for sharing data in an asymmetric multiprocessing system according to the present invention.

Referring to FIG. 7, the data sharing apparatus of the asymmetric multiprocessing system of the present invention performs a first process 110 by a first type of OS (OS-1), and the first communication framework 120 and the first The second process 210 is performed by a first core 100 including a shared data processing framework 130 and a second type of OS (OS-2), which is a different type from the first type of OS, and , A second core 200 including a second communication framework 220 and a second shared data processing framework 230, and a first process for storing the first process 110 and the second process 210, respectively. Communication data using the first and second regions 310 and 320 and the first communication framework 120 or the second communication framework 220 of the first and second cores 100 and 200 A shared memory 300 including a communication memory area 330 for storing data and a shared data memory area 240 for storing data of the first shared data processing framework 230 and the second shared data processing framework 230. ).

Hereinafter, the configuration and operation of the data sharing device of the asymmetric multiprocessing system of the present invention configured as described above will be described in more detail.

First, the asymmetric multi-processing system referred to in the present invention includes a processor (referring to a core, which is a core element of the processor, if necessary) that performs processes determined by different OSs.

The processor is driven by the OS, not in a narrow sense, such as CPU or MPU, and should be broadly interpreted as a concept of a device that performs a process through an operation.

The first core 100 has the same meaning as the first processor, and the second core 200 may also have the same meaning as the second processor.

In the configuration of the drawings, the configuration of the hardware and the configuration of software (or data) may be displayed at the same time, and it should be understood that the configuration of such software or data is executed on or stored in the corresponding hardware.

The first core 100 is operated by a first type of OS (OS-1). In this case, the first type of OS may be Linux, and the second type of OS used by the second core 200 ( OS-2) may be to use an RTOS.

OpenAMP may be used as the first communication framework 120 and the second communication framework 220 for communication between the first core 100 and the second core 200, but the present invention is not limited thereto.

It is possible to use a hypervisor or MCAPI (Multicore Communication API) known as a communication framework that can be used in an asymmetric multiprocessing system.

The first process 110 and the second process 210 of the first core 100 and the second core 200 are stored in one shared memory 300, and at this time, the first process 110 and the second process 210 is characterized in that they are respectively stored in the first area 310 and the second area 320, which are different areas.

It is assumed that the first core 100 and the second core 200 respectively perform a shared data processing framework for processing shared data in addition to the communication framework.

8 is a layer configuration diagram of the first shared data processing framework 130 of the first core 100.

The first shared data processing framework 130 is composed of a management area 131, a control area 132, and a transmission/reception area 133, and the second shared data processing framework 230 of the second core 200 is also Although not shown in a separate drawing, the first shared data processing framework 130 includes a management area, a control area, and a transmission/reception area.

A detailed configuration and operation of the first shared data processing framework 130 will be described in more detail later.

9 is a block diagram of a shared memory 300 according to an exemplary embodiment of the present invention.

Referring to FIG. 9, the shared data memory area 340 is further divided into a memory map information area 341, an access control area 342, and a shared data area 343.

It is assumed that the shared data memory area 340 is processed by the first shared data processing framework 130 of the first core 100 and the second shared data processing framework 230 of the second core 200. .

As described above, the first shared data processing framework 130 includes a management area 131, a control area 132, and a transmission/reception area 133, and the management area 131 is the shared data of the shared memory 300. It serves to store shared data information in the memory map information area 341 of the memory area 340.

In addition, the control area 132 sets access control for the shared memory 300 by recording data in the access control area 342.

In addition, the transmission/reception area 133 serves to store shared data in the shared data area 343.

10 is an explanatory diagram showing a relationship between shared data stored in the shared data area 343 and a memory map stored in the memory map information area 341.

Referring to FIG. 10, a memory map is designated and stored in the management area 131 according to a compilation input of data obtained by executing a program in the first core 100 and a runtime input defined by an external input.

The input of the runtime relates to a processing sequence of a process, and a change in the runtime input may be processed as an update of shared data.

The memory map stored in the memory map information area 341 has information on a storage area address and data size of data stored in the shared data area 343.

11 is an explanatory diagram showing the function of the transmission/reception area 133. As shown in FIG.

The transmission/reception area 133 writes shared data to the shared data area 343 of the shared memory 300 when the process is transmitting, transmits memory information, and reads the data of the shared data area 343 when the process is receiving Do it.

In this case, the memory information means that the receiving process side transmits information that the data has been written to the shared data area 343 to the receiving process side.

In this case, the memory information may be transmitted to the second communication framework 220 of the receiving process side through the first communication framework 120 and the communication memory area 330 of the shared memory 300.

In addition, reading the data in the shared data area 343 in the receiving process means reading the shared data through hardware direct memory access, cached memory, or direct memory access, not through a memory copy method as in the prior art. do.

Using this read method, no release process is required.

Referring back to FIG. 7, the operation of the present invention will be described by limiting the case where the transmitting side transmitting data is the first core 100 and the receiving side receiving the data is the second core 200.

That is, it is assumed that the first process 110 of the first core 100 is a transmission process, and the second process 210 of the second core 200 is a reception process that receives data.

When performing the first process 110 in the first core 100, the management area 131 of the first shared data processing framework 130 stores address and size information in which shared data is stored through memory map management. It is stored in the map information area 341.

The memory map stored in the memory map information area 431 is shared by the first process 110 performed in the first core 100 and the second process 210 performed in the second core 200, and No memory allocation and deallocation is required.

Therefore, overhead that occurs due to frequent allocation and deallocation of memory does not occur.

In addition, the shared data shared (transmitted) by the first process 110 is stored in the shared data area 343 of the shared memory 300, and is read and shared by the second process 210 by referring to the memory map. Therefore, there is no memory copy overhead for data transmission and reception.

In this case, since the shared data area 343 is variably set according to the size of the shared data and the information is included in the memory map, processing such as partitioning according to the data size is unnecessary.

In the past, since it is an asymmetric multi-process system using different OS, the process memory of each of the two cores is not shared with each other, and data cannot reside in the communication memory area due to memory allocation and release operations of the message queue. The memory copy process for this is essential.

That is, in the past, overhead is incurred because data is stored in memory through a communication framework without allocating shared memory, and the receiving side reads and releases data so that the stored data does not reside. In the present invention, since the shared data memory area 340 is placed in addition to the communication memory area to store shared data and can be used without a release process, there is no fear of overhead.

In particular, when the shared data is continuously used without updating, the writing process can be omitted, thereby further enhancing the efficiency.

As described above, the present invention can maximize the effect when data sharing occurs frequently between the first process 110 and the second process 210 or the size of the data is large, and a system requiring a fast system response due to minimization of overhead. Applicable to implementation.

In addition, the control area 132 of the first shared data processing framework 130 may limit processes that can access shared data. In the example of the present invention, an example of a process performed by two processors (or cores) is described, but it may be performed by three or more processors having different types of OS, and at this time, information on a processor that can access shared data is controlled. It can be restricted by storing in the access control area 342 of the shared memory 300 in the area 132.

That is, it is possible to prevent two or more accesses to the shared memory 300 from occurring at the same time.

In particular, the control area 132 performs shared resource management that prevents two or more accesses in order to prevent a problem in which information is damaged by updating data in the transmitting process while reading data stored in the shared memory 300 in the receiving process. And, for example, a shared resource protection technique such as a mutex, a semaphore, and a flag may be used.

In addition, after the use of the shared memory 300 is completed, the control area 132 may release the restriction so that other processes can update the shared data.

When the shared memory 300 is a single ported RAM or a dual ported RAM capable of reading and writing a plurality of reads and writes, the control region 132 may be omitted.

In the above description, as previously assumed, the transmission process of the first core 100 and the reception process of the second core 200 are described, and the second core 200 performs the transmission process, and the first core ( When 100) performs the reception process, the second shared data processing framework 230 of the second core 200 is used to write shared data together with memory information in the shared memory 300, and the first core ( The shared data is read and used by the first shared data processing framework 130 of 100).

Although the embodiments according to the present invention have been described above, these are merely exemplary, and those of ordinary skill in the art will understand that various modifications and equivalent ranges of embodiments are possible therefrom. Therefore, the true technical protection scope of the present invention should be determined by the following claims.

100: first core 110: first process
120: first communication framework 130: first shared data processing framework
200: second core 210: second process
220: second communication framework 230: second shared data processing framework
300: shared memory 310: first area
320: second area 330: communication memory area
340: shared data memory area

Claims (11)

A data sharing device of an asymmetric multiprocessing system that transmits and receives shared data by a communication framework of each of the plurality of cores, including a plurality of cores using different operating systems and a shared memory shared by the plurality of cores. In,
The plurality of cores further include a shared data processing framework for allocating an area for storing shared data in the shared memory in addition to the communication framework, and for allocating an area for storing a memory map, which is a storage address and size information of the shared data. and,
A data sharing apparatus of an asymmetric multiprocessing system, characterized in that a core performing a reception process refers to the memory map and reads and uses the shared data. The method of claim 1,
The shared memory,
Regions each storing the processes of the cores,
A communication memory area in which the communication framework is performed,
A data sharing apparatus of an asymmetric multiprocessing system, characterized in that divided into a shared data memory area in which the shared data processing framework is performed. The method of claim 2,
The shared data memory area,
A memory map information area storing the memory map,
The data sharing apparatus of an asymmetric multiprocessing system, characterized in that the cores are divided into a shared data area in which shared data is stored in process execution. The method of claim 3,
The shared data memory area,
If the shared memory is not single port RAM or double port RAM,
A data sharing device of an asymmetric multiprocessing system further comprising an access control area in which access restriction information of a memory is stored. The method of claim 3,
The data sharing apparatus of an asymmetric multiprocessing system, characterized in that the address of the memory map is an index or an offset address. The method of claim 3,
The method of reading shared data in the shared data area in the transmission process is a data sharing apparatus of an asymmetric multiprocessing system, characterized in that reading through a hardware direct memory access, a cached memory access, or a direct memory access. As a method of sharing data using the data sharing device of the asymmetric multiprocessing system of claim 1,
a) storing shared data in the shared data area set in the transmission process;
b) creating a memory map including address and size information of the stored shared data and storing it in a memory map information area;
c) notifying the receiving process side that the data is stored; And
d) A data sharing method of an asymmetric multiprocessing system comprising the step of reading and receiving the shared data at a receiving process side. The method of claim 7,
In the data sharing processing framework of the transmission process, data sharing of an asymmetric multiprocessing system further comprises the step of restricting access to shared data stored in the shared data area, thereby preventing a plurality of processes from accessing the same shared data at the same time. Way. The method of claim 8,
Restricting access to the shared data,
A method of sharing data in an asymmetric multiprocessing system using a shared resource protection technique such as Mutex, Semaphore, or Flag. The method of claim 8,
The address of the memory map is,
Data sharing method of an asymmetric multiprocessing system, characterized in that the index or offset address. The method of claim 8,
Step d),
A method of sharing data in asymmetric multiprocessing systems using hardware direct memory access, cached memory access, or direct memory access.

Images