The present invention relates to methods to extract in-memory data for debugging a multi-core system and a computing apparatus using the same. In particular, methods and computing apparatus using the same are provided to extract, by a processor, in-memory data directly related to binary file(s) being operated in another processor for debugging or troubleshooting the multi-core system.

BACKGROUND

Current wireless communication platforms such as eNodeBs or base stations are moving towards adopting system architecture having a control processor and multiple application processors integrated on the same platform. For example, a System on Chip (SoC) DSP cores platform from Texas Instruments® (TI) may include an ARM® processor as a control plane processor and multi-core DSP processors as application processors/user plane processors. Debugging compiled computer program(s) or binary file(s) running on the DSP core processor(s) usually require extraction of debugging data via an external Joint Test Action Group (JTAG) port, which itself needs contact pins on the board. The debugging environment through JTAG port may be useful in the development laboratory, but in a field deployment it may be cumbersome to use and difficult to access. For example, when an eNodeB implemented with such type of multi-core DSP platform, the eNodeB has no external interface for the field technician or engineer to plug in a JTAG module.

Conventional approach for accessing in-memory data for DSP processor(s) may require an inter-processor communication (IPC) between the control plane processor and the DSP core processor(s). The approach involved with IPC may sacrifice computing performance of the DSP core processor(s), where the DSP core processor(s) may be user plane processor(s) configured to execute computationally intensive operations such as encoding or decoding forward error correction (FEC) in messages or user plane packets. Other conventional art may use different approaches but still consume some computational resources of DSP core processor(s) while accessing the in-memory data of the DSP core processor(s).

As such, it is desirable to find solutions which may provide a method, a computing apparatus or a multi-core SoC system to extract in-memory data related to binary file(s) being operated by the user plane processor/application processor in the multi-core SoC system, so as to enable the debugging or troubleshooting the system without impacting the user plane processor/application processor being monitored.

SUMMARY

According to an exemplary embodiment of the invention, there is provided a computing apparatus, comprising:
a first processor;
a second processor;
a shared memory connected to both the first processor and second processor, wherein the first processor and the second processor respectively operate a first portion and a second portion of the shared memory; and
wherein the first processor operates an operating system, and comprises:
a memory access unit, configured to enable the operating system to access the second portion of the shared memory; and
an address assignment unit, connected to the memory access driver, configured to receive a memory address of the shared memory, and instruct the operating system to retrieve a value of a variable from the shared memory only operated by the second processor, according to the memory address.

According to an embodiment of the invention, the memory access unit is activated to extend a virtual memory of the user space program, running on an operating system on the first processor, to a second portion of the shared memory, so as to enable the user space program to access the second portion of the shared memory.

According to an embodiment of the invention, the retrieved value of the variable is output to an external output device or an external computing apparatus.

According to an embodiment of the invention, the user space program of the operating system is only able to access the first portion of the shared memory, when the memory access unit is deactivated.

According to an embodiment of the invention, the address assignment unit is the user space program; the variable is operated by the second processor on the second portion of the shared memory; the first processor is a control plane processor; and the second processor is a user plane processor.

According to another embodiment of the invention, the computing apparatus further comprises a third processor, connected to the shared memory, and configured to operate a third portion of the shared memory; wherein when the memory access unit is activated, the memory access unit is further configured to extend a virtual memory of the user space program, running on the operating system on the first processor, to the third portion of the shared memory, so as to enable the user space program to access the second portion of the shared memory; and the address assignment unit is further configured to receive another memory address of the shared memory from the operating user, and instruct the operating system to retrieve a value of a variable from the shared memory only operated by the third processor, according to the another memory address.

According to yet another embodiment of the invention, the computing apparatus is connected to another computing apparatus, wherein the address assignment unit is configured to receive the memory address of the shared memory from the operating user through the another computing apparatus.

According to yet another embodiment of the invention, the address assignment unit is connected with an input unit external to the computing apparatus, and the input unit is configured to translate a variable name input by the operating user to the memory address.

According to another embodiment of the invention, a method to extract in-memory data for debugging a multi-core system, wherein the multi-core system comprises at least a first processor and a second processor, the method comprising:
activating a memory access unit by the first processor which only operates on a first portion of shared memory to extend a virtual memory of a user space program of an operating system operated on the first processor to a second portion of the shared memory, so as to enable a user space program running on the operating system to access the second portion of the shared memory;
receiving, by the user space program, a memory address of the second portion of the shared memory; and
instructing the operating system, by the user space program, to retrieve a value of a variable from the shared memory only operated by the second processor, according to the memory address.

According to another embodiment of the invention, the method further comprises: outputting the retrieved value of the variable to an external computing apparatus.

According to another embodiment of the invention, the method further comprises: receiving, by the user space program, the memory address of the shared memory from an operating user.

According to another embodiment of the invention, wherein the multi-core system is connected to another computing apparatus, and the method further comprises: receiving, by the user space program, the memory address of the shared memory from the another computing apparatus.

According to an embodiment of the invention, the method further comprises: deactivating the memory access unit by the first processor to make the user space program of the operating system only access the first portion of the shared memory.

According to an embodiment of the invention, wherein the multi-core system further comprises a third processor operating a third portion of the shared memory, and the method further comprises:
activating the memory access unit, by the first processor, to extend a virtual memory of the user space program of the operating system operated on the first processor to the third portion of the shared memory, so as to enable the user space program to access the third portion of the shared memory;
receiving, by the user space program, another memory address of the third portion of the shared memory from an operating user; and
instructing the operating system, by the user space program, to retrieve a value of another variable from the shared memory only operated by the third processor, according to the received another address.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments of the invention will now be described by way of example only with reference to the accompanying drawings, in which:
Figure 1 illustrates physical elements of a computing apparatus according to a first exemplary embodiment;
Figure 2 illustrates a schematic diagram illustrating virtual memory space of the system memory according to the first exemplary embodiment;
Figure 3 illustrates physical elements of another computing apparatus according to a second exemplary embodiment;
Figure 4 is a flowchart illustrating a method to extract in-memory data for debugging the multi-core system according to a third exemplary embodiment;
Figure 5 illustrates physical elements of another computing apparatus according to a fourth exemplary embodiment;
Figure 6 illustrates physical elements of another computing apparatus according to a fifth exemplary embodiment; and
Figure 7 is a flowchart illustrating another method to extract in-memory data for debugging the multi-core system according to the fifth exemplary embodiment.

DETAILED DESCRIPTIONS OF EXEMPLARY EMBODIMENTS

In the following description, numerous specific details are set forth in order to provide a thorough understanding of various illustrative embodiments of the invention. It will be understood, however, to one skilled in the art, that embodiments of the invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure pertinent aspects of embodiments being described. In the drawings, like reference numerals refer to same or similar functionalities or features throughout the several views.

In order to address the problems or challenges faced by wireless communication industry, the present disclosure provides a method to extract in-memory data in the multi-core system. The in-memory data extraction can be performed by a processor without consuming any computational resource of other processor(s) while the in-memory data related to binary file(s) or compiled computer program being run by the other processor(s). The proposed method of extracting in-memory data of user plane processor(s)/application processor(s) on the multi-core system can be applied to a multi-core SoC platform where some of all processors share the same physical memory device. The conventional approach such as IPC or master-slave software is not required for the extraction of in-memory data, which leads to simplified debugging system architecture and allows remotely debugging or troubleshooting the multi-core system when the system is deployed in field such as eNodeBs, base stations or small cell devices in wireless communication systems.

Figure 1 illustrates physical elements of a computing apparatus 10 according to a first exemplary embodiment. The computing apparatus 10 may include a multi-core system (or a multi-core SoC system), and the computing apparatus 10 may be, for example, a base station, an eNodeB, a remote radio head unit (RHU) or a small cell broadband data access point device, and so forth. In some embodiments, the computing apparatus 10 may be network equipment in a communication network, where the network equipment may be, for example, a router, a switch, a firewall, a server, a traffic aggregator and so forth.

In the first embodiment, the computing apparatus 10 may include an input device 101, a network interface 102, a multi-core system 103 and a system memory 104. The multi-core system may be a SoC system which includes a processor 21 and a processor 23. The processor 21 may be connected to the input interface 101 and both the processor 21 and processor 23 may share the system memory 104 for performing configured operations or computations.

In a simplified form, the processor 21 may include an operating system 211, a memory access unit 213 and an address assignment unit 215 for enabling extracting in-memory data directly related to binary file(s) or compiled computer program(s) being run by the processor 23. The processor 21 may be an ARM® processor, and the processor 23 may be a DSP core processor.

The operating system 211 may be a Linux operating system, which may be configured to provide Internet protocol (IP) processing functionality for receiving IP packet(s) from a computer apparatus 12 or transmitting IP packet(s) to the computing apparatus 12 via the network interface 102. Also, the operating system 211 may be configured to receive input command and related parameters from an input device 11 via the input interface 101 or from the computing apparatus 12, or output data to an output device 12 via an output interface 105 or to the computing apparatus 12.

Figure 2 illustrates a schematic diagram illustrating virtual memory space of the system memory 104 according to the first exemplary embodiment. In Figure 2, it is illustrated that the system memory 104 may include at least a memory block 1031 and a memory block 1032. The memory block 1031 may be a first portion of the shared system memory 104 which is operated by the processor 21, and address range of the memory block 1031 may be from A000 to AFFF, for instance. When the operating system 211 boots up, without assistance from the memory access unit 213, a user space program of the operating system 211 can only access a virtual memory of the memory block 1031. In the invention, it is assumed that a kernel space of the operating system 211 is configured to access all the shared memory but the user space program of the operating system 211 is configured to only access the first portion of the shared system memory 104 when the operating system 211 boots up.

On the other hand, the memory block 1032 (a second portion of the shared system memory 104) may be configured to be only operated by the processor 23, and the
address range of the memory block 1032 may be from B000 to BFFF, for instance. The objective of the invention is to extract in-memory data (which refers to value(s) of variable(s)) related to binary file(s) or compiled computer program(s) run by the processor 23 without consuming computation resource of the processor 23 being monitored.

In order to extract the in-memory data from the second portion of the shared system memory 104, an operating user may configure the processor 21 to activate the memory access unit 213 such that the virtual memory accessible by the user space program on the operating system 211 is extended (or mapped) to include the memory block 1032. For example, in an embodiment derived from the first embodiment, when the memory access unit 213 is implemented as a driver program, and the address assignment unit 215 is implemented as a script, the operating user may configure the operating system 211 to load the memory access unit 213 being run on the processor 21 to extract the in-memory data of variable(s) being run by the processor 23. Then, the operating user may determine the memory address of a variable of interest, via a software tool such as readelf provided by the operating system 211. The readelf provides a memory address in response to a variable name input by the operating user to the user space program on the operating system 211.

Further, the operating user may input the memory address related to the variable of interest to the address assignment unit 215, and the address assignment unit 215 requests or instructs the operating system 211 via the memory access unit 213 to extract value of the variable of interest from the memory address of the shared system memory 104. The extracted value from the second portion of the shared system memory 104 may be output to the output device 15 via the output interface 105, and the operating user can read the output value for further determinating how to debug or troubleshoot the multi-core system 103. Alternatively, the extracted value from the second portion of the shared system memory 104 may be output to the computing apparatus 12 for the operating user view the extracted value for further actions related to troubleshooting the multi-core system 103.

The invention is not limited to the first embodiment. A person skilled in the art will appreciate that one or more of the functional components executed by the processor 21 could alternatively be implemented in some other way, for example, by one or more dedicated electronic circuits. For example, in other embodiment of the invention, the memory access unit 213 may be implemented as a dedicated electronic circuit in the processor 21.

The address assignment unit 215 in another embodiment may be implemented as a graphical user interface (GUI) computer program or a server program for receiving input of memory address from the operating user (via an external computing device) and providing the operating system 211 with the received memory address for the operating system 211 to extract the value of the variable whose memory address is provided to the address assignment unit 215 by the operating user.

Furthermore, the address assignment unit 215 can perform translation of a variable name to a corresponding memory address for the operating user. The address assignment unit 215 can even be split into separate server and client programs, where the client program may reside in the input device 15 (or the computing apparatus 12) and the server program is operated by the processor 21. Additionally, the client program can perform a variable-name-to-memory-address translation for a variable name input by the operating user and/or the GUI implementation. After performing the variable-name-to-memory-address translation, the client program may forward memory addresses of the variable to the server program implemented in the address assignment unit 215, thereby reducing processing load on the processor 21.

In another embodiment of the invention, the input device 11 and the output device 15 may be integrated such as a computing apparatus which may include a keyboard for the operating user to input parameter(s) and command(s) to the computing apparatus 10 and also include a display device for presenting the extracted value of the variable of interest to the operating user.

In order to restore security of the configured operations and computations of the processor, in another embodiment derived from the first embodiment, the memory address unit 213 may be deactivated in the operating system 211 by the operating user, so as to disable the user space program on the operating system 211 to access the second portion of the shared system memory 104, until next time it is necessary to debug or troubleshoot the multi-core system 103. Further, the memory address unit 213 may even be deleted by the operating user, when it is not required, and then restored at a later time when debugging or troubleshooting is required.

A person skilled in the art will also appreciate that the multi-core processor(s) may use local memory for computations and configured operations. Figure 3 illustrates physical elements of a computing apparatus 30 according to a second exemplary embodiment. The computing apparatus 30 is similar to the computing apparatus 10 in most components except that the processor 23 includes a local memory 231, which is not shared memory and may be an embedded memory local to the processor 23 similar to that shown in Figure 3. Also the local memory 231 is used by the processor 23 for running the binary file(s) or the compiled computer program(s).

In the present disclosure, kernel space of the operating system 211 run by the processor 21 is allowed to access the local memory 231 in the multi-core SoC platform, but the user space program of the operating system 211 is not initially enabled to access when the operating system 211 boots up. Similar to the approaches illustrated in the first embodiment, the memory access unit 213 in the second embodiment may be activated by processor 21 to extend (or map) virtual memory of a user space program on the operating system 211 to the local memory 231. Then, the operating user may input the memory address related to the variable of interest to the address assignment unit 215. Further, according to the input memory address, the address assignment unit 215 may request or instruct the operating system 211 to extract a value of the variable of interest, via the memory access unit 213, from the shared system memory 104. The extracted value from the second portion of the shared system memory 104 may be output to the output device 15 via the output interface 105, and the operating user can read the output value for further determinatiing how to debug or troubleshoot the multi-core system 103.

Figure 4 is a flowchart illustrating a method to extract by a first processor in-memory data directly related to binary file(s) being operated in a second processor for debugging the multi-core system 103 according to a third exemplary embodiment. The proposed procedures illustrated in the third embodiment can be applied to the above-mentioned computing apparatus 10, 30 in the first and second embodiment.

Referring to Figure 1 to Figure 4, the method to extract by a first processor in-memory data directly related to operations or computations of a second processor for debugging or troubleshooting the multi-core system 103 may include following steps A-2 to A-8.

At step A-2, the memory access unit 213 is activated by a first processor (the processor 21) which is only operating on a first portion of shared memory (referring to the memory block 1031 of the shared system memory 104) to extend (or map) virtual memory of a user space program running on an operating system on the first processor, to the second portion of the shared memory (referring to the memory block 1032 of the shared system memory 104) to be accessible by an operating system (referring to the operating system 211) being operated on the first processor, so as to enable a user space program running on the operating system to access the second portion of the shared memory.

At step A-4, a memory address of the shared memory is received by the address assignment unit 213 from an operating user either from an input device 11 via the input interface 101, or from an external computing apparatus 12 via the network interface 102. Alternatively, the memory address may be provided by a client program on the input interface 101 or the external computing apparatus 12 after the client program performs the variable-name-to-memory-address translation for the variable name input by the operating user.

It can be envisaged by a person skilled in the art that a memory address of the local memory 231 running by the second processor (referring to the processor 23) can also be received by the address assignment unit 213 from the operating user. It can also be envisaged that more than one memory address of the memory (either shared memory or the local memory) running by the second processor can also be received by the address assignment unit 213 from the operating user.

At step A-6, the operating system 211 (via the memory access unit 213) is requested or instructed by the address assignment unit 215 to retrieve via the memory access unit 213 a value of a variable from the shared memory only operated by the second processor, according to the memory address. It can be envisaged by a person skilled in the art that a value of a variable from a memory address of the local memory 231 running by the second processor (referring to the processor 23) can also be received by the address assignment unit 213. It can also be envisaged that debugging data can be retrieved by the operating system 211 (or the memory access unit 213) from multiple memory addresses of the memory (either shared memory or the local memory) at the same time when the memory addresses are input to the address assignment unit 213 from the operating user. The debugging data including debugging messages, debugging counters, snapshots of certain memory contents, state variables, and so forth may also be extracted from the second portion of the shared memory.

At step A-8, the retrieved value of the variable is output by the operating system 211 to the operating user. The retrieved value can be output to the output device 15 or the computing apparatus 12. The extracted debugging data can be saved locally or output to an external device for presenting the debugging data to the operating user.

Figure 5 illustrates physical elements of a computing apparatus 50 according to a fourth exemplary embodiment. The fourth embodiment is derived from the first embodiment. The computing apparatus 50 in the fifth embodiment may include all functional elements in the first embodiment but it further includes a processor 25 as a third processor. Also, the processor 21 may adopt similar approach as shown in the first and third embodiment to extract in-memory data of variable(s) in the files compiled computer programs run by the processor 25.

For example, the processor 25 is configured to operate a third portion of the shared system memory 103. The memory access unit 213 is further configured to enable the operating system 211 to access the third portion of the shared system memory 103 by extending a virtual memory of the user space program running on the operating system 211 on the processor 21, to the third portion of the shared system memory 103. The address assignment unit 215 is further configured to receive another memory address of the shared system memory 103 from the operating user, and to request or instruct the operating system 211 to retrieve debugging data via the memory access unit 213 from the shared memory only operated by the processor 25, according to the another memory address.

Figure 6 illustrates physical elements of a computing apparatus 60 according to a fifth exemplary embodiment. The computing apparatus 60 in the fifth embodiment is derived from the first embodiment and contains all functional elements in the computing apparatus 10 except that the address assignment unit 215 may not receive memory address(es) directly from the operating user. In the fifth embodiment, the address assignment unit 215 of the computing apparatus 60 is connected to either an input unit 111 of the input device 11 via an input interface 101 or an input unit 121 of the computing apparatus 12. The input unit 111 or the input unit 121 can be configured to receive a variable name or multiple variable names and then translate the variable name(s) into corresponding memory address(es) by using software tool such as previously mentioned readelf provided by the operating system 211. In the fifth embodiment, the input unit 111 or the input unit 121 may be connected to the operating system 211 respectively for using the readelf provided by the operating system 211 to obtain the memory address(es) for the variable name(s) input by the operating user.

The input unit 111 or the input unit 121 may be configured as client program, and the address assignment unit 215 may be configured as a corresponding sever program running on the processor 21. When the input unit 111 or the input unit 121 obtains, from the operating system 211, the corresponding memory address(es) of the variable name(s), the input unit 111 or the input unit 121 may be configured to provide the address assignment unit 215 with the obtained memory address(es) for subsequent retrieval of value(s) of the variable(s) from the shared system memory 104.

Figure 7 is a flowchart illustrating a method to extract by a first processor in-memory data directly related to binary file(s) being operated in a second processor for debugging or troubleshooting the multi-core system 103 according to the fifth exemplary embodiment. The flowchart shown in Figure 7 contains step B-2 to B-10, and the step B-2, B-6, B-8 and B-10 are similar to the step A-2, A-4, A-6 and A-8 respectively.

The method in the fifth embodiment can be applied in the computing apparatus 60 shown in Figure 6. When the memory access unit 213 is activated by the processor 21 after the step B-2, the step B-4 is executed.

At the step B-4, the input unit 111 or the input unit 121 is configured to receive variable name(s) from an operating user and translate the variable name(s) into corresponding memory address(es) by using software tools provided by the operating system 211. Then the translated memory address(es) are provided to the address assignment unit 215 at the step B-6 for subsequent retrieval of the debugging data according to the translated memory address(es). The technical details of the rest steps B-6, B-8 and B-10 should be referring to the steps A-4, A-6 and A-8 respectively.

It can be envisaged that more than 2 processors can be accessed by the first processor, and thus in-memory debugging data of respective processors apart from the first processor can be extracted according to the proposed method in above-mentioned embodiments. Also it can be envisaged that some of processors in the multi-core SoC system may use shared memory, while the rest may use only local memory for configured operations or computations. Additionally, debugging data at multiple memory addresses from the shared memory or the local memory can be extracted at the same time by the address assignment unit 215 in combination with the memory access unit 213.

In the above-mentioned embodiments in the present invention, the in-memory data extracted by a control plane processor may be debugging data of any processor including that of the control plane processor, and that of the DSP core processor(s) in the multi-core system. The debugging data may include, but not limited to, debugging messages, debugging counters, snapshots of certain memory contents, state variables, and so forth. The above-mentioned debugging data may be extracted by the control plane processor for output to display device/output device, such that the operating user can use the debugging data for troubleshooting the multi-core SoC system.

The control plane processor in the multi-core SoC system is used as a debugging processor in the invention, when the operating user configures the control plane processor for accessing in-memory debugging data of other processor(s) in the multi-core SoC system. The debugging data can be saved locally in the multi-core system or exported/presented in an external computing device. The debugging user interface tool provided by hardware platform vendor(s) can also be configured to access the debugging data extracted by the debugging processor.

As shown in the above-mentioned embodiments, no JTAG module/port is required, no IPC between the multi-core is required, and no computational resource on user plane processor(s)/application processor(s) being monitored by the debugging processor implemented by the control plane processor, which may be idle most of times. The in-memory debugging data can be real-time extracted while the multi-core system is still running as there is spare processing capacity in the control plane processor. As such, the performance of the multi-core system is maintained while a technician or a software engineer as the operating user can easily access the debugging data for troubleshooting the multi-core system.

Further aspects of the computing apparatus 10, 30, 50, 60 will be apparent from the above description of the computing apparatuses. A person skilled in the art will appreciate that any of the methods described above could be embodied in program code. The program code could be supplied in a number of ways, for example on a tangible computer readable medium, such as a disc or a memory or as a data signal. The proposed method and the computing apparatus provide more efficient access to the in-memory data/debugging data of processors in a multi-core system. Also the proposed method can enable simple implementation of CLI based system operation and maintenance as well as graphical user interface with efficient and effective access to the in-memory data of multi-core processor(s) for debugging or troubleshooting. Additionally the invention can be beneficial to communication systems where remote access to the debugging data is required.

It is to be understood that, if any prior art is referred to herein, such reference does not constitute an admission that the prior art forms a part of the common general knowledge in the art in any country. In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, that is to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

CLAIMS:
1. A computing apparatus, comprising:
a first processor;
a second processor;
a shared memory connected to both the first processor and the second processor, wherein the first processor and the second processor respectively operate a first portion and a second portion of the shared memory; and
wherein the first processor operates an operating system, and comprises:
a memory access unit, configured to enable the operating system to access the second portion of the shared memory; and
an address assignment unit, connected to the memory access driver, configured to receive a memory address of the shared memory, and instruct the operating system to retrieve a value of a variable from the shared memory only operated by the second processor, according to the memory address.

2. The computing apparatus of claim 1, wherein the memory access unit is activated to extend a virtual memory of a user space program, running on the operating system on the first processor, to the second portion of the shared memory, so as to enable the user space program to access the second portion of the shared memory.

3. The computing apparatus of claim 2, further comprising:
a third processor, connected to the shared memory, and configured to operate a third portion of the shared memory;
wherein when the memory access unit is activated, the memory access unit is further configured to extend the virtual memory of the user space program, running on the operating system on the first processor, to the third portion of the shared memory, so as to enable the user space program to access the third portion of the shared memory; and
the address assignment unit is further configured to receive another memory address of the shared memory from the operating user, and instruct the operating system to retrieve a value of a variable from the shared memory only operated by the third processor, according to the another memory address.

4. The computing apparatus of claim 1, wherein the computing apparatus is connected to another computing apparatus, wherein the address assignment unit is configured to receive the memory address of the shared memory from the operating user through the another computing apparatus.

5. The computing apparatus of claim 1, wherein the address assignment unit is connected with an input unit external to the computing apparatus, and the input unit is configured to translate a variable name input by the operating user to the memory address.

6. A method to extract in-memory data for debugging a multi-core system, wherein the multi-core system comprises at least a first processor and a second processor, the method comprising:
activating a memory access unit by the first processor which only operates on a first portion of shared memory to extend a virtual memory of a user space program of an operating system operated on the first processor to a second portion of the shared memory, so as to enable a user space program running on the operating system to access the second portion of the shared memory;
receiving, by the user space program, a memory address of the second portion of the shared memory; and
instructing the operating system, by the user space program, to retrieve a value of a variable from the shared memory only operated by the second processor, according to the memory address.

7. The method of claim 6, wherein the multi-core system further comprises a third processor operating a third portion of the shared memory, the method further comprising:
activating the memory access unit, by the first processor, to extend the virtual memory of the user space program of the operating system operated on the first processor to the third portion of the shared memory, so as to enable the user space program to access the third portion of the shared memory;
receiving, by the user space program, another address of the third portion of the shared memory from an operating user; and
instructing the operating system, by the user space program, to retrieve a value of another variable from the shared memory only operated by the third processor, according to the another memory address.