Master-slave core communication method and system for master-slave architecture chip

Abstract

The present invention discloses a master-slave core communication method and system for a master-slave architecture chip, and relates to the technical field of integrated circuit design. The method comprises the following steps: a module application thread of a master core sends a request, a module driver adapter unit obtains the aforementioned request data and puts it into the sending memory corresponding to the master core C2C controller; the master core C2C controller sends an interrupt signal to the slave core; after receiving the interrupt information, the slave core extracts the request data from the shared receiving memory and notifies the module daemon process, the module daemon process sends the request data to the module driver unit for processing, and after the module driver unit completes the processing, the request data processing result is returned to the module daemon process, and then written into the sending memory of the slave core through the slave core C2C controller, and the request data processing result is returned along the original path. The present invention uses the master core adapter driver combined with the slave core daemon process to enable the master core to control the same module of the slave core to realize application functions without changing the module kernel driver.

Description

Technical Field

[0001] The present invention relates to the technical field of integrated circuit design, and in particular to a master-slave core communication method and system for a master-slave architecture chip. Background Art

[0002] High-performance edge processor chips, due to the complex nature of applications and the high real-time requirements of tasks, typically utilize a multi-core processor architecture combining a main processor (MP) and co-processors (CP). The MP, with its higher performance, typically handles more complex computing tasks, typically processing modules with large data volumes, frequent interrupts, and long processing times, such as high-speed peripherals like Ethernet, DDR, SATA, and PCIe. These processing often places a heavy load on the main CPU core, potentially preventing some modules with high real-time requirements from responding promptly, thus impacting overall system performance. To improve system real-time performance and overall performance, existing technologies typically place the drivers of these modules under the control of the co-processors (CP). In other words, the co-processors handle simpler, transactional, and high-real-time computing tasks.

[0003] Currently, there are two main implementation methods for controlling the master core (MP) and slave core (CP) in system-on-chips (SoCs) using a master-slave architecture. In the first implementation, the master core (MP) and slave core (CP) operate independently, each with its own operating system (OS) and graphical user interface (GUI). The modules responsible for each are independently controlled. In the second implementation, the master core (MP) and slave core (CP) each run their own OS, but the GUI runs only on the master core (MP). Service requests are transmitted from the master core (MP) to the slave core (CP) in kernel space.

[0004] However, the above control implementation methods of the master core MP and the slave core CP generally have the problem that the master core MP is heavily loaded while the slave core CP is not fully utilized. The load imbalance between the master core MP and the slave core CP will obviously affect the overall CPU utilization. Summary of the Invention

[0005] The present invention aims to overcome the shortcomings of the prior art by providing a master-slave core communication method and system for a master-slave architecture chip. The present invention implements communication between the master core (MP) and the slave core (CP) by establishing a master-slave core communication system. By combining a master core adapter driver with a slave core daemon process, data communication between the master and slave cores is achieved without changing the module kernel driver. This allows the master core (MP) to control the same module of the slave core (CP) to implement application functions, thereby balancing the load between the master core (MP) and the slave core (CP).

[0006] To achieve the above objectives, the present invention provides the following technical solutions:

[0007] A master-slave core communication method for a master-slave architecture chip includes the following steps:

[0008] The module application thread of the master core sends a request to the module driver adaptation unit. The module driver adaptation unit corresponds to the kernel driver setting of the module application thread and is used to obtain the request data sent by the module application thread and put the request data into the sending memory corresponding to the master core C2C controller. The master core and the slave core share memory, the sending memory of the master core is the receiving memory of the slave core, and the sending memory of the slave core is the receiving memory of the master core.

[0009] The master core C2C controller sends an interrupt signal to the slave core C2C controller of the slave core;

[0010] The slave core C2C controller reads the request data from the shared receiving memory and notifies the module daemon process in the slave core; the module daemon process resides in the memory and is used to monitor the request data read by the slave core C2C controller, parse the request data, and send the request data to the module driver unit of the slave core for processing;

[0011] After the processing is completed, the module driver unit returns the request data processing result to the module daemon process, and then writes the request data processing result into the send memory of the slave core through the slave core C2C controller;

[0012] The module daemon process sends the aforementioned request data processing result to the master core C2C controller through the slave core C2C controller, and the master core C2C controller returns the received request data processing result to the module application thread through the module driver adapter unit.

[0013] Furthermore, N hardware interrupt lines are set between the master core and the slave core to support the master core to simultaneously control N physical modules for processing in the slave core. Each hardware interrupt line corresponds to a module, and each module is configured with two memories, a sending memory and a receiving memory. The sending memory is used to send module data, and the receiving memory is used to receive module data.

[0014] Furthermore, the master core and the slave core send interrupt signals to each other through the master core C2C controller and the slave core C2C controller. The master core C2C controller can send interrupt signals to the slave core and receive interrupt signals sent by the slave core. The slave core C2C controller can receive interrupt signals sent by the master core and send response messages returned by the module daemon process in the slave core to the master core C2C controller.

[0015] Corresponding to the aforementioned N physical modules, the master core C2C controller and the slave core C2C controller each include N PORT ports, each PORT port can support 128 NODE nodes, and each NODE node can support 8 SLOT slots.

[0016] Furthermore, the value of N is 16.

[0017] Furthermore, the module driver adaptation unit is configured to encapsulate the request data sent by the module application thread into a request message packet in a predetermined data format and then send it to the slave core via the master core C2C controller; wherein each message packet corresponding to the request operation data is a blocking request, and the blocking request is used to trigger a wait until the master core C2C controller receives a response message packet returned to the module application thread, and the response data packet includes a request data processing result;

[0018] The slave core includes multiple module daemons, which run when the system starts. Each module daemon includes a first thread and a second thread. The first thread is used to process non-blocking events, and the second thread is used to process blocking events.

[0019] Further, the data format of the request message packet is configured to include a PORT field, a SLOT field, a NODE field, an OPS_TYPE field, a CMD field, a PARAM_NUM field, a RESPONSE_SIZE field and a DATA field;

[0020] in,

[0021] The PORT field is used to record the hardware channel PORT information corresponding to the hardware;

[0022] The SLOT field is used to record the slot information used to send the message packet. SLOT represents different thread information of the same module and the same file descriptor.

[0023] The NODE field is used to record the node NODE information assigned to the file descriptor. NODE represents the file descriptor of the same module and is used to support the thread information of multi-threaded operations of the same module.

[0024] The OPS_TYPE field is used to record the operation type corresponding to the request, which includes OPEN, IOCTL, SELECT, and CLOSE types;

[0025] The CMD field is used to record the command of the ioctl function;

[0026] The PARAM_NUM field is used to record the number of parameters of the ioctl function;

[0027] The RESPONSE_SIZE field is used to record the result size that the request message packet needs to return;

[0028] The DATA field is used to record the specific parameters of ioctl.

[0029] Furthermore, the data format of the response message packet is configured to include a PORT field, a SLOT field, a NODE field, an OPS_TYPE field, a CMD field, a RESULT field, and a DATA field;

[0030] in,

[0031] The PORT field is used to record the hardware channel PORT information corresponding to the hardware;

[0032] The SLOT field is used to record the slot information used to send the message packet. SLOT represents different thread information of the same module and the same file descriptor.

[0033] The NODE field is used to record the node NODE information assigned to the file descriptor. NODE represents the file descriptor of the same module and is used to support the thread information of multi-threaded operations of the same module.

[0034] The OPS_TYPE field is used to record the operation type corresponding to the request, which includes OPEN, IOCTL, SELECT, and CLOSE types; the CMD field is used to record the command of the ioctl function;

[0035] The RESULT field is used to record the processing result of the returned request data;

[0036] The DATA field is the specific data returned in the response message.

[0037] Furthermore, the main core operation includes an OPEN operation, an IOCTL operation, a SELECT operation, and a CLOSE operation, wherein the IOCTL operation, the SELECT operation, and the CLOSE operation are performed based on the OPEN operation;

[0038] When the module application thread executes the OPEN operation, the module driver adapter unit allocates the data structure storage space required for communication, applies for a NODE node number from the corresponding module PORT number, records the PORT number and NODE node number to the data structure of the corresponding file descriptor, and finds an idle SLOT slot to send an OPEN type request message packet information to the slave core, and then waits until the slave core completes the processing and returns the processing result to the module application thread;

[0039] When the module application thread executes an IOCTL operation, the module driver adapter unit determines whether there are parameters and the number of parameters based on the IOCTL command, updates the CMD field, PARAM_NUM field, DATA field, and RESPONSE_SIZE field of the request message packet, and finds an idle SLOT slot to send the IOCTL type request message packet to the slave core, and then waits for the slave core to complete the processing and return the processing result to the module application thread;

[0040] When the module application thread executes a SELECT operation, the SELECT operation corresponds to a blocking event. The module driver adapter unit occupies a SLOT slot, finds other idle SLOT slots to send a SELECT type request message packet to the slave core, waits for the slave core to complete the processing and return the processing result to the module application thread;

[0041] When the module application thread executes the CLOSE operation, the module driver adapter unit sends a CLOSE type request message packet to the slave core, waits for the slave core to complete the processing and return the processing result to the module application thread; then, it releases the data structure memory space allocated during the OPEN operation and reclaims the NODE node information applied for during the OPEN operation.

[0042] Furthermore, the slave core is configured as follows:

[0043] After the slave core C2C controller receives the interrupt signal from the master core C2C controller, it extracts a request message packet from the sending memory space of the master core corresponding to the PORT, and notifies the module daemon process to read the aforementioned request message packet; after the module daemon process reads the request message packet, it finds the corresponding module according to the PORT number and triggers the module driver unit to execute the operation type of the request message packet; after the module driver unit completes the operation, it returns the processing result and specific data to the module daemon process. The module daemon process writes the response data packet into the sending memory of the slave core through the slave core C2C controller according to the NODE and SLOT information of the request message packet, and notifies the master core to read the aforementioned response data packet information.

[0044] The present invention also provides a master-slave core communication system of a master-slave architecture chip, comprising a master core and a slave core, wherein the master core and the slave core share a memory, the sending memory of the master core is the receiving memory of the slave core, and the sending memory of the slave core is the receiving memory of the master core;

[0045] The master core includes a module application thread, a module driver adaptation unit, and a master core C2C controller; the slave core includes a module daemon process, a module driver unit, and a slave core C2C controller; interrupt signals are sent between the master core and the slave core via the master core C2C controller and the slave core C2C controller;

[0046] The module driver adaptation unit corresponds to the kernel driver setting of the module application thread, and is used to obtain the request data sent by the module application thread and put the request data into the sending memory corresponding to the aforementioned main core C2C controller;

[0047] The master core C2C controller is configured to send an interrupt signal to the slave core C2C controller of the slave core when acquiring the aforementioned request data;

[0048] The slave core C2C controller is configured to receive an interrupt signal sent by the master core C2C controller, and after receiving the interrupt signal, read the aforementioned request data from the shared receiving memory and notify the module daemon process at the same time;

[0049] The module daemon process resides in the memory and is used to monitor the request data read by the slave core C2C controller, parse the request data, and send the request data to the module driver unit of the slave core for processing;

[0050] The module driver unit returns the request data processing result to the module daemon after the processing is completed, and then writes the request data processing result into the sending memory of the slave core through the slave core C2C controller;

[0051] The module daemon process can send the received request data processing result to the master core C2C controller through the slave core C2C controller, and the master core C2C controller returns the received request data processing result to the module application thread through the module driver adapter unit.

[0052] Due to the adoption of the above technical solution, the present invention has the following advantages and positive effects compared with the prior art, as an example: by setting up a master-slave core communication system to realize the communication function between the master core MP and the slave core CP, the application requirements of the master core MP are transmitted to the slave core CP module drive control unit, and the master core adaptation driver is combined with the slave core daemon process. Without changing the module kernel driver, data communication between the master core and the slave core is realized, so that the master core MP can control the same module of the slave core CP to realize the application function, and can balance the load of the master core MP and the slave core CP. Specifically, the master core MP forwards the application thread request through the module driver adaptation unit, and the driver is completely controlled by the slave core CP. The slave core CP creates a daemon process at the user layer to realize the real-time reception and distribution of the master core MP request and control the driving functions of different modules. It has the advantages of high module driver code reusability, flexibility and good portability. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 A diagram showing the connection structure of the master and slave cores provided in an embodiment of the present invention.

[0054] Figure 2 This is a module structure diagram of the master-slave core provided by an embodiment of the present invention.

[0055] Figure 3 A data control flow diagram for communication between the master and slave cores provided by an embodiment of the present invention.

[0056] Figure 4 A schematic diagram of a typical logical structure of a C2C controller provided in an embodiment of the present invention.

[0057] Figure 5 This is a flowchart of the operation of the master core MP provided by an embodiment of the present invention.

[0058] Figure 6 This is a flowchart of the slave core CP operation provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0059] The following is a further detailed description of the master-slave core communication method and system of the master-slave architecture chip disclosed in the present invention in conjunction with the accompanying drawings and specific embodiments. It should be noted that the technical features or combinations of technical features described in the following embodiments should not be considered isolated, and they can be combined with each other to achieve better technical effects. In the drawings of the following embodiments, the same reference numerals appearing in each drawing represent the same features or components, which can be applied to different embodiments. Therefore, once an item is defined in one drawing, it does not need to be further discussed in subsequent drawings.

[0060] It should be noted that the structures, proportions, sizes, etc. illustrated in the drawings of this specification are only used to match the contents disclosed in the specification for people familiar with this technology to understand and read, and are not intended to limit the conditions under which the invention can be implemented. Any structural modification, change in proportional relationship, or adjustment of size should fall within the scope of the technical content disclosed in the invention without affecting the efficacy and purpose of the invention. The scope of the preferred embodiments of the present invention includes alternative implementations, in which the functions can be performed in a non-described or discussed order, including performing the functions in a substantially simultaneous manner or in a reverse order according to the functions involved, which should be understood by those skilled in the art of the art to which the embodiments of the present invention belong.

[0061] Techniques, methods, and apparatus known to persons of ordinary skill in the relevant art may not be discussed in detail, but where appropriate, such techniques, methods, and apparatus should be considered part of the specification. In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not limiting. Therefore, other examples of the exemplary embodiments may have different values. Example

[0062] See also Figure 1 and Figure 2 As shown, a master-slave core communication system of a master-slave architecture chip provided by the present invention.

[0063] The master-slave core communication system includes a master core MP and a slave core CP in communication connection. The data of the master core MP and the slave core CP are realized in a shared memory manner, that is, the sending memory of the master core is the receiving memory of the slave core, and the sending memory of the slave core is the receiving memory of the master core.

[0064] N hardware interrupt lines can be provided between the master core MP and the slave core CP to support the master core's simultaneous control of N physical modules for processing on the slave cores. N is typically set to 16. In this case, there are 16 hardware interrupt lines between the master core MP and the slave core CP, supporting the simultaneous control of 16 modules on the slave core CP. Each hardware interrupt line corresponds to a module, and each interrupt line also corresponds to two physical memories: transmit memory and receive memory. The transmit memory is used to send module data, and the receive memory is used to receive module data.

[0065] See also Figure 2 The master core may specifically include a module application thread, a module driver adaptation unit, and a master core C2C controller; the slave core may specifically include a module daemon process, a module driver unit, and a slave core C2C controller; and interrupt signals are sent between the master core and the slave core via the master core C2C controller and the slave core C2C controller.

[0066] The data control flow between the master and slave cores can be found in Figure 3 As shown. First, the module application thread sends request data to the module driver adapter unit. The module driver adapter unit places the request data into the transmit memory space corresponding to the master core C2C (core to core) controller of the master core MP. The master core C2C controller then sends an interrupt signal (or interrupt notification) to the slave core CP. After receiving the interrupt signal, the slave core CP extracts the request data from the shared receive memory and notifies the module daemon. The module daemon then sends the request data to the module driver unit of the slave core CP. The module driver unit processes the request data and returns the result of the request data processing to the module daemon. The slave core C2C controller then writes the result of the request data processing to the transmit memory of the slave core CP. The result of the request data processing can then be returned in sequence along the original path.

[0067] Specifically, the master-slave core communication method of the master-slave architecture chip includes the following steps:

[0068] S100: The module application thread of the main core sends a request to the module driver adaptation unit.

[0069] The module driver adaptation unit corresponds to the kernel driver setting of the module application thread, and is used to obtain the request data sent by the module application thread and put the request data into the sending memory corresponding to the aforementioned main core C2C controller.

[0070] In this embodiment, the C2C controller is the hardware implementation of the communication between the master core MP and the slave core CP. The C2C controllers of the master core MP and the slave core CP can be configured in the same way. The master core and the slave core send interrupt signals to each other through the master core C2C controller and the slave core C2C controller.

[0071] Specifically, the master core C2C controller in the master core enables the master core MP to send interrupt signals to the slave cores and receives interrupt signals from the slave core CP. The slave core C2C controller in the slave core receives interrupt signals from the master core and sends response messages returned by the slave core's module daemon thread to the master core C2C controller.

[0072] Corresponding to the aforementioned 16 physical modules, the C2C controller can have 16 PORTs. Each hardware channel of the C2C controller can be called a PORT, and each PORT channel can correspond to a physical module.

[0073] See also Figure 4 As shown, each port supports up to 128 NODE nodes. NODE is an abstract concept that corresponds to the file descriptor of the same module and is used to support multi-threaded operation of the same module. A port supports 128 NODE nodes, and the corresponding module supports up to 128 threads operating simultaneously. Each NODE node supports up to 8 SLOT slots. SLOTs correspond to different threads of the same module and the same file descriptor.

[0074] In this embodiment, the module driver adapter unit implements the kernel driver portion of the module application thread. However, it does not operate the specific physical hardware. It simply encapsulates hardware operation requests (such as OPEN, CLOSE, IOCTL, and SELECT) into request message packets in a predetermined data format and sends them to the slave core. Each message packet corresponding to a request operation data received by the module driver adapter unit from the module application thread is a blocking request (sent by the master core C2C controller). The module driver adapter unit waits until the master core C2C controller receives the request data and processes it, then returns the result to the master core module application thread.

[0075] Specifically, the module driver adaptation unit is configured to: encapsulate the request data sent by the module application thread into a request message packet in a predetermined data format and then send it to the slave core through the master core C2C controller; wherein, each message packet corresponding to the request operation data is a blocking request, and the blocking request is used to trigger waiting until the master core C2C controller receives a response message packet returned to the module application thread, and the response data packet includes the request data processing result.

[0076] The slave core includes multiple module daemons, which run when the system starts. Each module daemon includes a first thread and a second thread. The first thread is used to process non-blocking events, and the second thread is used to process blocking events.

[0077] The predetermined data format of the request message packet is preferably shown in the following table.

[0078]

[0079] At this time, the data format of the request message packet includes a PORT field, a SLOT field, a NODE field, an OPS_TYPE field, a CMD field, a PARAM_NUM field, a RESPONSE_SIZE field, and a DATA field.

[0080] Among them, the PORT field is used to record the hardware channel PORT information corresponding to the hardware. The SLOT field is used to record the slot SLOT information used to send the message packet. SLOT represents the different thread information of the same file descriptor of the same module. The NODE field is used to record the node NODE information assigned to the file descriptor. NODE represents the file descriptor of the same module, which is used to support the thread information of multi-threaded operations of the same module. The OPS_TYPE field is used to record the operation type corresponding to the request, and the operation type includes OPEN, IOCTL, SELECT and CLOSE types. The CMD field is used to record the command of the ioctl function. The PARAM_NUM field is used to record the number of parameters of the ioctl function. The RESPONSE_SIZE field is used to record the result size that the request message packet needs to return. The DATA field is used to record the specific parameters of ioctl.

[0081] The predetermined data format of the response message packet is preferably shown in the following table.

[0082]

[0083] At this time, the data format of the response message packet includes a PORT field, a SLOT field, a NODE field, an OPS_TYPE field, a CMD field, a RESULT field, and a DATA field.

[0084] The PORT, SLOT, NODE, OPS_TYPE, and CMD fields contain the same information as the corresponding fields in the request message packet. The RESULT field in the response message packet records the processing result of the returned request data. The DATA field in the response message packet contains the specific data returned in the response message.

[0085] S200 , the master core C2C controller sends an interrupt signal to the slave core C2C controller of the slave core.

[0086] The master core C2C controller is configured to send an interrupt signal to the slave core C2C controller of the slave core when acquiring the aforementioned request data.

[0087] S300 , the slave core C2C controller reads the aforementioned request data from the shared receiving memory and notifies the module daemon process in the slave core.

[0088] The slave core C2C controller is used to receive the interrupt signal sent by the master core C2C controller, and read the aforementioned request data from the shared receiving memory after receiving the interrupt signal, and notify the module daemon process at the same time.

[0089] The module daemon process resides in the memory and is used to monitor the request data read from the slave core C2C controller, parse the request data, and send the request data to the module driver unit of the slave core for processing.

[0090] S400, after the processing is completed, the module driving unit returns the request data processing result to the module daemon process, and then writes the request data processing result into the sending memory of the slave core through the slave core C2C controller.

[0091] S500: The module daemon process sends the request data processing result to the master core C2C controller via the slave core C2C controller. The master core C2C controller returns the received request data processing result to the module application thread via the module driver adapter unit.

[0092] In this embodiment, the operation type (OPS) of the main core operation may include an OPEN operation, an IOCTL operation, a SELECT operation, and a CLOSE operation, and the IOCTL operation, the SELECT operation, and the CLOSE operation are performed based on the OPEN operation.

[0093] The following combination Figure 5 Describe in detail the specific process of main core operation.

[0094] First, when the module application thread executes the OPEN operation, the module driver adapter unit allocates the data structure storage space required for communication, applies for a NODE node number from the corresponding module PORT number, records the PORT number and NODE node number to the data structure of the corresponding file descriptor, and searches for an idle SLOT slot - for example, SLOT 0, sends an OPEN type request message packet information to the slave core, and then waits until the slave core completes the processing and returns the processing result to the module application thread.

[0095] IOCTL, SELECT, and CLOSE are based on OPEN. When the module application thread executes an IOCTL operation, the module driver adapter unit determines the presence and number of parameters based on the IOCTL command, and then updates the CMD, PARAM_NUM, DATA, and RESPONSE_SIZE fields of the request message packet. It then searches for an available SLOT slot and sends the IOCTL request message packet to the slave core. The slave core then waits for the slave core to complete processing and return the result to the module application thread. The module driver adapter unit then changes the data in the PARAM_NUM and DATA fields of the request message packet based on the presence and number of parameters, and then adjusts the value of the RESPONSE_SIZE field based on the required result.

[0096] When the module application thread executes a SELECT operation, the SELECT operation corresponds to a blocking event. The module driver adapter unit occupies a SLOT slot and finds other idle SLOT slots - such as SLOT 1 to send a SELECT type request message packet to the slave core, waiting for the slave core to complete the processing and return the processing result to the module application thread.

[0097] When the module application thread executes the CLOSE operation, the module driver adapter unit sends a CLOSE type request message packet to the slave core, waits for the slave core to complete the processing and return the processing result to the module application thread; then, it releases the data structure memory space allocated during the OPEN operation and reclaims the NODE node information applied for during the OPEN operation.

[0098] For the detailed operation process of the kernel, see Figure 6 shown.

[0099] After receiving the interrupt signal from the master core C2C controller, the slave core C2C controller in the slave core extracts a request message packet from the sending memory space of the master core corresponding to the PORT, and notifies the module daemon process to read the aforementioned request message packet.

[0100] After the module daemon process reads the request message packet, it searches out the corresponding module according to the PORT number.

[0101] Then, the module daemon process triggers the module driver unit to execute the corresponding operation type according to the operation type (OPS) and CMD field information of the request message packet.

[0102] After the module driving unit completes the operation, it returns the processing result and specific data to the module daemon process.

[0103] The module daemon process writes the response data packet into the sending memory of the slave core through the slave core C2C controller according to the NODE and SLOT information of the request message packet, and notifies the master core to read the aforementioned response data packet information.

[0104] The technical solution provided by the present invention utilizes a master core adapter driver combined with a slave core daemon process to achieve data communication between the master and slave cores without changing the module core drivers. Furthermore, by employing a port, node, and slot method, it solves the problem of different application threads in the same module operating simultaneously on the same slave core driver through the master core.

[0105] In the above description, the disclosure of the present invention is not intended to limit itself to these aspects. Rather, within the scope of the intended protection of the present disclosure, the components can be selectively and operationally combined in any number. In addition, terms such as "including", "encompassing" and "having" should be interpreted as inclusive or open by default, rather than exclusive or closed, unless they are explicitly defined to the contrary. All technical, scientific or other terms have the meaning understood by those skilled in the art unless they are defined to the contrary. Common terms found in dictionaries should not be interpreted too idealistically or too impractically in the context of relevant technical documents, unless the present disclosure explicitly defines them as such. Any changes and modifications made by a person of ordinary skill in the field of the present invention based on the above disclosure are within the scope of protection of the claims.

Claims

1. A master-slave core communication method for a master-slave architecture chip, characterized in that Including steps: The module application thread of the master core sends a request to the module driver adaptation unit. The module driver adaptation unit corresponds to the kernel driver setting of the module application thread and is used to obtain the request data sent by the module application thread and put the request data into the sending memory corresponding to the master core C2C controller. The master core and the slave core share memory, the sending memory of the master core is the receiving memory of the slave core, and the sending memory of the slave core is the receiving memory of the master core. The master core C2C controller sends an interrupt signal to the slave core C2C controller of the slave core; The slave core C2C controller reads the request data from the shared receiving memory and notifies the module daemon process in the slave core; the module daemon process resides in the memory and is used to monitor the request data read by the slave core C2C controller, parse the request data, and send the request data to the module driver unit of the slave core for processing; After the processing is completed, the module driver unit returns the request data processing result to the module daemon process, and then writes the request data processing result into the send memory of the slave core through the slave core C2C controller; The module daemon process sends the aforementioned request data processing result to the master core C2C controller through the slave core C2C controller, and the master core C2C controller returns the received request data processing result to the module application thread through the module driver adapter unit.

2. The master-slave core communication method according to claim 1, characterized in that: N hardware interrupt lines are set between the master core and the slave core to support the master core to simultaneously control N physical modules for processing in the slave core. Each hardware interrupt line corresponds to a module, and each module is configured with two memories, a sending memory and a receiving memory. The sending memory is used to send module data, and the receiving memory is used to receive module data.

3. The master-slave core communication method according to claim 2, characterized in that: The master core and the slave core send interrupt signals to each other through the master core C2C controller and the slave core C2C controller. The master core C2C controller can send interrupt signals to the slave core and receive interrupt signals sent by the slave core. The slave core C2C controller can receive interrupt signals sent by the master core and send the response message returned by the module daemon process in the slave core to the master core C2C controller. Corresponding to the aforementioned N physical modules, the master core C2C controller and the slave core C2C controller each include N PORT ports, each PORT port can support 128 NODE nodes, and each NODE node can support 8 SLOT slots.

4. The master-slave core communication method according to claim 3, characterized in that: The value of N is 16.

5. The master-slave core communication method according to claim 2, wherein: The module driver adaptation unit is configured to encapsulate the request data sent by the module application thread into a request message packet in a predetermined data format and then send it to the slave core via the master core C2C controller; wherein each message packet corresponding to the request operation data is a blocking request, and the blocking request is used to trigger a wait until the master core C2C controller receives a response message packet returned to the module application thread, and the response data packet includes a request data processing result; The slave core includes multiple module daemons, which run when the system starts. Each module daemon includes a first thread and a second thread. The first thread is used to process non-blocking events, and the second thread is used to process blocking events.

6. The master-slave core communication method according to claim 5, characterized in that: The data format of the request message packet is configured to include a PORT field, a SLOT field, a NODE field, an OPS_TYPE field, a CMD field, a PARAM_NUM field, a RESPONSE_SIZE field and a DATA field; in, The PORT field is used to record the hardware channel PORT information corresponding to the hardware; The SLOT field is used to record the slot information used to send the message packet. SLOT represents different thread information of the same module and the same file descriptor. The NODE field is used to record the node NODE information assigned to the file descriptor. NODE represents the file descriptor of the same module and is used to support the thread information of multi-threaded operations of the same module. The OPS_TYPE field is used to record the operation type corresponding to the request, which includes OPEN, IOCTL, SELECT, and CLOSE types; The CMD field is used to record the command of the ioctl function; The PARAM_NUM field is used to record the number of parameters of the ioctl function; The RESPONSE_SIZE field is used to record the result size that the request message packet needs to return; The DATA field is used to record the specific parameters of ioctl.

7. The master-slave core communication method according to claim 6, characterized in that: The data format of the response message packet is configured to include a PORT field, a SLOT field, a NODE field, an OPS_TYPE field, a CMD field, a RESULT field, and a DATA field; in, The PORT field is used to record the hardware channel PORT information corresponding to the hardware; The SLOT field is used to record the slot information used to send the message packet. SLOT represents different thread information of the same module and the same file descriptor. The NODE field is used to record the node NODE information assigned to the file descriptor. NODE represents the file descriptor of the same module and is used to support the thread information of multi-threaded operations of the same module. The OPS_TYPE field is used to record the operation type corresponding to the request, which includes OPEN, IOCTL, SELECT, and CLOSE types; the CMD field is used to record the command of the ioctl function; The RESULT field is used to record the processing result of the returned request data; The DATA field is the specific data returned in the response message.

8. The master-slave core communication method according to claim 6, characterized in that: The main core operation includes OPEN operation, IOCTL operation, SELECT operation and CLOSE operation, and the IOCTL operation, SELECT operation and CLOSE operation are performed based on the OPEN operation; When the module application thread executes the OPEN operation, the module driver adapter unit allocates the data structure storage space required for communication, applies for a NODE node number from the corresponding module PORT number, records the PORT number and NODE node number to the data structure of the corresponding file descriptor, and finds an idle SLOT slot to send an OPEN type request message packet information to the slave core, and then waits until the slave core completes the processing and returns the processing result to the module application thread; When the module application thread executes an IOCTL operation, the module driver adapter unit determines whether there are parameters and the number of parameters based on the IOCTL command, updates the CMD field, PARAM_NUM field, DATA field, and RESPONSE_SIZE field of the request message packet, and finds an idle SLOT slot to send the IOCTL type request message packet to the slave core, and then waits for the slave core to complete the processing and return the processing result to the module application thread; When the module application thread executes a SELECT operation, the SELECT operation corresponds to a blocking event. The module driver adapter unit occupies a SLOT slot, finds other idle SLOT slots to send a SELECT type request message packet to the slave core, waits for the slave core to complete the processing and return the processing result to the module application thread; When the module application thread executes the CLOSE operation, the module driver adapter unit sends a CLOSE type request message packet to the slave core, waits for the slave core to complete the processing and return the processing result to the module application thread; then, it releases the data structure memory space allocated during the OPEN operation and reclaims the NODE node information applied for during the OPEN operation.

9. The master-slave core communication method according to claim 8, characterized in that: The slave core is configured as follows: After the slave core C2C controller receives the interrupt signal from the master core C2C controller, it extracts a request message packet from the sending memory space of the master core corresponding to the PORT, and notifies the module daemon process to read the aforementioned request message packet; after the module daemon process reads the request message packet, it finds the corresponding module according to the PORT number and triggers the module driver unit to execute the operation type of the request message packet; after the module driver unit completes the operation, it returns the processing result and specific data to the module daemon process. The module daemon process writes the response data packet into the sending memory of the slave core through the slave core C2C controller according to the NODE and SLOT information of the request message packet, and notifies the master core to read the aforementioned response data packet information.

10. A master-slave core communication system of a master-slave architecture chip, characterized by: The system comprises a master core and a slave core, wherein the master core and the slave core share a memory, the sending memory of the master core is the receiving memory of the slave core, and the sending memory of the slave core is the receiving memory of the master core; The master core includes a module application thread, a module driver adaptation unit, and a master core C2C controller; the slave core includes a module daemon process, a module driver unit, and a slave core C2C controller; interrupt signals are sent between the master core and the slave core via the master core C2C controller and the slave core C2C controller; The module driver adaptation unit corresponds to the kernel driver setting of the module application thread, and is used to obtain the request data sent by the module application thread and put the request data into the sending memory corresponding to the aforementioned main core C2C controller; The master core C2C controller is configured to send an interrupt signal to the slave core C2C controller of the slave core when acquiring the aforementioned request data; The slave core C2C controller is configured to receive an interrupt signal sent by the master core C2C controller, and after receiving the interrupt signal, read the aforementioned request data from the shared receiving memory and notify the module daemon process at the same time; The module daemon process resides in the memory and is used to monitor the request data read by the slave core C2C controller, parse the request data, and send the request data to the module driver unit of the slave core for processing; The module driver unit returns the request data processing result to the module daemon after the processing is completed, and then writes the request data processing result into the sending memory of the slave core through the slave core C2C controller; The module daemon process can send the received request data processing result to the master core C2C controller through the slave core C2C controller, and the master core C2C controller returns the received request data processing result to the module application thread through the module driver adapter unit.

Images