A method and device for transaction-level modeling remote method call

Abstract

The present invention discloses a method and apparatus for transaction-level modeling of remote method calls. The present invention uses an interface class, a stub unit, and a proxy unit to complete TLM-based inter-module communication that is independent of the business, and based on this communication, implements the transfer of call parameters and the return of call results for remote method calls, thereby realizing remote method calls. The architecture provided by the present invention can realize the automatic generation of code that is independent of the business, reducing the workload of code writing. After the remote method is modified, it is only necessary to automatically regenerate the code of the above three classes without manual modification, thereby reducing the possibility of manual modification errors. The present invention allows developers to focus on the implementation of specific business functions in the service module without having to worry about the details of TLM, greatly reducing the difficulty of programming.

Description

Technical Field

[0001] The present invention relates to the technical field of chip simulation verification, and in particular to a method and device for transaction-level modeling remote method calling. Background Art

[0002] Transaction Level Modeling (TLM) is a set of C++ library codes based on SystemC for transaction level modeling of chips. Its core idea is to use a memory-mapped bus to interconnect various modules on the chip. This is very consistent with the current system on chip (SoC) structure. Figure 1 As shown, TLM can be used to model SoC at the transaction level. The TLM model structure corresponding to SoC is as follows Figure 2 As shown in Figure 1, the initiator can initiate access to the target, and data is transmitted on the memory-mapped bus. The interconnect component transfers the transmitted data for arbitration or routing, etc.

[0003] In addition to the core features described above, TLM also has the advantages of fast simulation speed and the ability to provide prototypes for software, allowing software to be developed in parallel before the chip is developed, thus gaining widespread application.

[0004] The Initiator and Target in TLM are connected via sockets. Before the Initiator can access the Target, it must first instantiate its respective sockets and bind them using the bind function. The Initiator can then access the Target using functions such as b_transport. The Target receives the tlm_generic_payload (a generic payload class abstracted from TLM that carries information such as commands, addresses, data, and access types) and parses it to perform operations such as memory reads and writes.

[0005] TLM is not only applicable to modeling this type of memory access, but also to modeling the interconnection of modules in a chip that does not have memory access. Figure 3Taking the network packet processing simulation model shown in the figure as an example, when the serial-to-parallel converter (SerDes) (Ser stands for serializer and des stands for deserializer) receives data that needs to be handed over to the media access control (MAC) device for further processing, the SerDes acts as the initiator and the MAC acts as the target. The SerDes encapsulates the received data packet in the generic payload tlm_generic_payload class and then calls the b_transport function to send it to the MAC for further processing. Conversely, when the MAC has data to send from the SerDes, the process is similar, except the data direction is reversed. Obviously, the MAC in this case is not a memory device.

[0006] To maximize compatibility with the complex interface requirements of various IP vendors (IP refers to internal chip modules such as SerDes and MAC in the example above), the tlm_generic_payload class is designed to be universal, allowing interconnection between IP modules developed by various vendors. However, this also makes the tlm_generic_payload class relatively complex. Before each call to the b_transport function for transmission, the various members of the tlm_generic_payload class must be set up. This increases the difficulty of writing code on the calling side, especially when using modules provided by other IP vendors (because detailed knowledge of how to correctly construct the tlm_generic_payload object is required for successful parsing by the other party). For example, when a SerDes receives a packet and wants to hand it off to the MAC for further processing, the SerDes must first instantiate its own socket, bind it to the MAC's socket, set up the various members of the tlm_generic_payload class according to the MAC's requirements, and finally call the b_transport function to hand the packet off to the MAC for further processing. This requires a lot of code and increases the potential for errors. Summary of the Invention

[0007] In view of this, the present invention provides a method and apparatus for transaction-level modeling remote method call, which are used to improve the simulation verification efficiency of module interconnection modeling in a chip.

[0008] According to one aspect of an embodiment of the present invention, the present invention provides a method for transaction-level modeling remote method call, the method comprising:

[0009] The client module calls the local method provided by the stub unit Stub in the service module to provide data to the stub unit, and the local method of the Stub overrides the virtual interface method in the base class Interface;

[0010] The local method of the Stub packages the remote method name and call parameters into a transaction-level modeling general payload class tlm_generic_payload, and transmits tlm_generic_payload to the proxy unit Proxy in the service module;

[0011] The proxy unit Proxy parses the tlm_generic_payload sent by Stub and calls the remote method for actually processing data in the service module according to the parsing result. The remote method also rewrites the virtual interface method in the base class Interface.

[0012] Furthermore, the method further includes: the Proxy packages the result information of calling the remote method in the service module and returns it to the Stub; the local method in the Stub unpacks the result information and returns the calling result to the client module.

[0013] Furthermore, the method further comprises:

[0014] The pre-processing module identifies the remote method through the macro definition identifier RMC_API;

[0015] The preprocessing module reads each source file and scans the code line with RMC_API. If the code line with RMC_API is scanned, the method definition information of the remote method identified by RMC_API is extracted according to the grammatical rules. The definition information includes the return value type, method name, and each parameter type and parameter name of the method;

[0016] The pre-processing module automatically generates the base class Interface according to the scanning result, and automatically generates the virtual interface method according to the method definition information of the remote method;

[0017] The pre-processing module automatically generates a stub unit Stub class derived from the base class Interface, and generates the local method in the Stub class according to the method definition information of the remote method;

[0018] The pre-processing module automatically generates a Proxy class derived from the base class Interface, and generates in the Proxy class the code for parsing the tlm_generic_payload and calling the remote method in the service module;

[0019] The pre-processing module automatically generates the initialization method rmc_init and the exit method rmc_exit of the service module, and generates the code for instantiating the Stub class and the Proxy class and the code for binding the two in rmc_init.

[0020] Furthermore, the Stub serves as an initiator in transaction-level modeling, and the Proxy serves as a target in transaction-level modeling. Both parties establish a session connection for transmitting the tlm_generic_payload and the return result of the remote method.

[0021] Furthermore, the initiator in the Stub and the target in the Proxy establish a session connection through a socket to exchange information.

[0022] Based on another method of the present invention, the present invention also provides a device for transaction-level modeling remote method call, the device comprising: a client module, a service module, the service module comprising: a stub unit, a proxy unit;

[0023] The client module is used to call the local method provided by the stub unit in the service module and provide data to the stub unit, wherein the local method of the stub unit overrides the virtual interface method in the base class Interface;

[0024] The stub unit is used to package the remote method name and call parameters into a transaction-level modeling general payload class through a local method, and transmit the transaction-level modeling general payload class to the proxy unit;

[0025] The proxy unit is used to parse the transaction-level modeling general load class transmitted by the stub unit, and call the remote method for actually processing data in the service module according to the parsing result. The remote method also rewrites the virtual interface method in the base class Interface.

[0026] Furthermore, the proxy unit is further configured to package the result information of calling the remote method in the service module and return it to the stub unit; the stub unit is further configured to unpack the result information through a local method and return the call result to the client module.

[0027] Furthermore, the device further comprises:

[0028] a preprocessing unit, configured to read each source file, scan a code line containing RMC_API, and if a code line containing RMC_API is found, extract method definition information of the remote method identified by RMC_API according to grammatical rules, wherein the definition information includes a return value type, a method name, and a type and name of each parameter of the method; wherein the remote method is identified by the macro definition identifier RMC_API;

[0029] The pre-processing unit is further used to automatically generate the base class Interface according to the scanning result, and automatically generate the virtual interface method according to the method definition information of the remote method;

[0030] The pre-processing unit is further used to automatically generate a stub unit Stub class derived from the base class Interface, and generate the local method in the Stub class according to the method definition information of the remote method;

[0031] The pre-processing unit is further used to automatically generate a proxy class derived from the base class Interface, and generate code in the Proxy class to parse the transaction-level modeling general load class and call the remote method in the service module;

[0032] The pre-processing unit is further configured to automatically generate an initialization method rmc_init and an exit method rmc_exit of the service module, and generate, in rmc_init, codes for instantiating the Stub class and the Proxy class and codes for binding the two.

[0033] Furthermore, the stub unit acts as an initiator in transaction-level modeling, and the proxy unit acts as a target in transaction-level modeling. Both parties establish a session connection for transmitting the transaction-level modeling universal load class and the return result of the remote method.

[0034] Furthermore, the initiator in the stub unit and the target in the proxy unit establish a session connection through a socket to exchange information.

[0035] The present invention implements business-independent TLM-based inter-module communication based on the interface class Interface, the stub unit Stub, and the proxy unit Proxy. Based on this communication, it implements the passing of call parameters and the return of call results for remote method calls, thereby realizing remote method calls. The architecture provided by the present invention can automatically generate business-independent code, reducing the workload of code writing. Furthermore, after the remote method is modified, only the code of the above three classes needs to be automatically regenerated, eliminating the need for manual modification, thus reducing the possibility of errors in manual modification. The present invention allows developers to focus on the implementation of specific business functions in the service module without having to worry about the details of the TLM, greatly reducing the difficulty of programming. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments of the present invention or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings of the embodiments of the present invention.

[0037] Figure 1 This is a schematic diagram of the SoC system structure;

[0038] Figure 2 Schematic diagram of the TLM model structure corresponding to SoC;

[0039] Figure 3 Schematic diagram of the TLM method of interconnecting the client module and the service module through sockets;

[0040] Figure 4 A schematic diagram of implementing data interaction between client modules and service modules in a remote method call manner based on TLM;

[0041] Figure 5 A flowchart of a method for transaction-level modeling remote method call provided by one embodiment of the present invention;

[0042] Figure 6 A schematic diagram of a device structure for transaction-level modeling remote method call provided by one embodiment of the present invention;

[0043] Figure 7 A schematic diagram of the processing steps of a preprocessing module provided in one embodiment of the present invention. DETAILED DESCRIPTION

[0044] The terms used in the embodiments of the present invention are only for the purpose of describing specific embodiments, and are not intended to limit the embodiments of the present invention. The singular forms "a," "an," "the," and "the" used in the embodiments of the present invention and the claims are also intended to include plural forms, unless the context clearly indicates otherwise. The term "and / or" used in the present invention refers to any or all possible combinations of one or more of the associated listed items.

[0045] It should be understood that although the terms "first," "second," "third," etc. may be used to describe various information in embodiments of the present invention, such information should not be limited to these terms. These terms are merely used to distinguish information of the same type from one another. For example, without departing from the scope of embodiments of the present invention, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the term "if" may also be interpreted as "when," "when," or "in response to determining."

[0046] In the application scenario of chip functional verification using transaction-level modeling, TLM modules are interconnected through sockets. In order to reduce the number of data transmission initiators (such as Figure 3 The amount of code in Serdes) can be Figure 3 The Initiator in the Serdes is moved to the data receiver (such as Figure 3 This is achieved by implementing the MAC in Figure 4 Because there is no Initiator in Serdes, if you want to initiate data transmission on the Serdes side, you need to Figure 4 Implement a MAC in Figure 4 The Serdes in the local call interface is as follows:

[0047] int rx_packet(int length,unsigned char*packet);

[0048] Thus, when the SerDes needs to pass data to the MAC for further processing, it bypasses the previous steps of constructing the Initiator, binding the socket, constructing the tlm_generic_payload, and calling the b_transport function. Instead, it simply calls the native call interface rx_packet provided by the MAC. This native call interface rx_packet completes the Initiator construction, socket binding, constructing the tlm_generic_payload, and calling the b_transport function, significantly streamlining the SerDes code. Figure 4After receiving the tlm_generic_payload sent by the Initiator, the Target in the MAC parses it and further processes the transmitted data.

[0049] While the above solution offers some optimizations, it also has some significant drawbacks. For example, the tlm_generic_payload parsing code and data processing code are intermixed, making the functional categorization unclear and hindering code modification and maintenance. Furthermore, while reducing the SerDes code size and complexity, it also increases the MAC code. If the code for the local call interface rx_packet needs to be modified, the tlm_generic_payload encapsulation and parsing code may also need to be modified. This means that the amount of manually written and modified code can be quite large.

[0050] In order to improve the development efficiency and verification efficiency of chip simulation verification programs that include inter-module data communication modules, an embodiment of the present invention provides a method for transaction-level modeling remote method calls, which can reduce the coupling between business code and non-business code and realize the reuse and automatic generation of basic communication function codes. Figure 5 The method is applied to a chip function simulation and verification device including a client module and a service module, wherein the service module includes a stub unit and a proxy unit. The method includes:

[0051] Step 501: The client module calls the local method provided by the stub unit Stub in the service module to provide data to the stub unit. The local method of the Stub overrides the virtual interface method in the base class Interface.

[0052] Step 502: The local method of the Stub packages the remote method name and call parameters into a transaction-level modeling generic payload class tlm_generic_payload, and transmits tlm_generic_payload to the proxy unit;

[0053] Step 503: The proxy unit Proxy parses the tlm_generic_payload sent by the Stub, and calls the remote method in the service module that actually processes the data according to the parsing result. The remote method also overrides the virtual interface method in the base class Interface.

[0054] In the embodiment of the present invention, the stub unit and the service module both inherit an interface class that declares a data processing virtual interface method. Both the stub unit and the service module implement their respective data processing methods based on the interface data processing virtual interface method. However, the data processing method provided by the stub and the data processing method provided by the service module are functionally different. The data processing method provided by the service module is used to perform actual business processing on received data, while the data processing method implemented in the stub is intended to provide a local call method for the client module. The client module locally calls the data processing method provided by the stub and provides the data to be transmitted to the stub. In its own data processing method (i.e., the local method), the stub packages the method name of the remote method and the parameters input for calling the remote method into a transaction-level modeling generic payload tlm_generic_payload and transmits the tlm_generic_payload to the proxy.

[0055] Since the data processing methods of the Stub and service module are inherited from the interface class, they have the same data processing method name, parameters and return type. Therefore, after the proxy parses the remote method name and call parameters in tlm_generic_payload, it can directly call the remote method of the service module (that is, the actual data processing method) according to the remote method name, and the data processing method of the service module performs actual business processing on the data.

[0056] Based on remote method calls based on TLM inter-module communication, this invention abstracts three business-independent classes: Interface, Stub, and Proxy. These three classes implement the specific implementation details of TLM communication, remote method call parameter packaging, parameter unpacking, parameter parsing, and the packaging and unpacking of returned result information. Because they are independent of specific business operations and primarily focus on TLM communication and remote methods, they exhibit strong regularity and are easily generated automatically.

[0057] Figure 6 This is a structural diagram of a device 600 for transaction-level modeling remote method call provided by an embodiment of the present invention. The device 600 includes a client module 610 and a service module 620. The service module 620 includes a stub unit 621 and a proxy unit 622.

[0058] Client module 610 is used to call the local method provided by stub unit 621 in service module 620 and provide data to stub unit 621. The local method of stub unit 621 overrides the virtual interface method in the base class Interface. Stub unit 621 uses the local method to package the remote method name and call parameters into a transaction-level modeling universal payload class and transmits the transaction-level modeling universal payload class to proxy unit 622. Proxy unit 622 parses the transaction-level modeling universal payload class transmitted from stub unit 621 and, based on the parsed results, calls the remote method in service module 620 that actually processes the data. This remote method also overrides the virtual interface method in the base class Interface.

[0059] The following description takes the client module as Serdes and the service module as MAC as an example. In this embodiment, the stub unit Stub in the service module MAC provides a local method rx_packet, and the service module MAC also provides a packet processing method rx_packet for final processing of the data packet. These two methods not only have the same name, but also have the same parameter and return value types. In this way, a separate interface class can be abstracted out, such as Figure 6 The Interface class in the Proxy class declares a pure virtual interface method, rx_packet. Both the Stub and the MAC inherit from the Interface class and implement the rx_packet method. Although both implement the rx_packet method, they perform different functions. The rx_packet method in the Stub is called by the client Serdes module. Its main function is to package the method name and call parameters to be remotely called and transmit them to the Proxy via the Socket. Conversely, after the remote call is completed, the Proxy packages the call result information and returns it to the Stub. The rx_packet method in the Stub needs to unpack this result information and ultimately return the call result to the Serdes. The rx_packet method implemented in the MAC actually processes the received data packets.

[0060] The abstracted proxy unit, Proxy, is responsible for parsing the tlm_generic_payload passed by the Stub and, based on the parsing result, calling the rx_packet remote method of the MAC implementation that actually processes the packet. The Proxy then encapsulates the call result and returns it to the Stub. If the MAC contains more than one remote method, the Proxy can also register these remote methods, allowing different methods to be called based on the parsing results.

[0061] With the unified code format above, we can then write another preprocessing module to automatically generate the relevant code. This preprocessing module can be implemented in many programming languages, such as scripting language, C / C++ language or Java language. The specific implementation methods of each language are different, so the following mainly describes the code that the preprocessing module needs to automatically generate and the steps to generate the code, such as Figure 7 shown.

[0062] For ease of description, the following takes Serdes and MAC as examples to explain in detail Figure 7 The steps and sample code in .

[0063] Step 1. The MAC module author will first identify an interface method that can be called remotely, such as the packet processing method rx_packet mentioned earlier. To allow the code preprocessor to recognize this interface method and generate the necessary interface, stub, and proxy code around it, an identifier must be added to the method. However, this identifier must not violate the syntax. This can be achieved using the following format (shown here in C / C++, as TLM itself was developed in C++).

[0064] #define RMC_API

[0065] RMC_API int rx_packet(int length,unsigned char*packet);

[0066] The RMC_API macro is used here as the identifier. In actual programming, any grammatically correct macro can be used. The RMC_API macro is defined as empty and added before the function declaration. When expanded by the compiler's preprocessor, it is equivalent to not having this macro, which means that the grammatical rules are not violated, and the compilation will not fail due to the introduction of this macro.

[0067] The definition of this macro is automatically generated in the rmc.h file. The example code is as follows:

[0068] #ifndef_RMC_H_

[0069] #define_RMC_H_

[0070] #define RMC_API

[0071] #endif

[0072] Step 2. The implementer of MAC manually writes the code of the MAC class and adds the RMC_API macro before the declaration of the remote method. To better explain the meaning of automatically generated code, the code example of the MAC class will be given and explained in the following step 2a. Figure 7 This step is not marked separately.

[0073] Step 3. The preprocessing module reads each source file and scans for code lines containing RMC_API. If a code line containing RMC_API is found, the module extracts the method definition information according to the syntax rules, including the return value type, method name, and each parameter type and name of the method.

[0074] Step 4a. The preprocessing module creates an interface file that defines the Interface class, such as mac_if.h. Based on the method definition information of the packet processing method extracted in step 3, write code similar to the following into the file.

[0075]

[0076] The code above mainly defines an abstract mac_if interface class. The packet processing method rx_packet is a pure virtual method (or pure virtual interface method), which requires derived classes that inherit this class to implement this virtual interface method. For example, the Stub and MAC classes mentioned later.

[0077] 4b. The preprocessing module creates a new file that defines the Stub class, such as mac_stub.h. Based on the function information extracted in step 3, write code similar to the following into the file.

[0078]

[0079]

[0080] As an Initiator, mac_stub needs a simple_initiator_socket socket to communicate with the socket on the Target side. In addition, the mac_stub class needs to inherit the mac_if class and implement the rx_packet method. This method will be called by Serdes, but this method in the Stub does not perform specific processing on the received data packet. Instead, it forwards it to the Proxy through the TLM's Socket, and then the Proxy forwards it to the MAC for specific processing. In order to complete this operation, that is, to complete the remote call to the rx_packet method in the MAC, the call parameters need to be packaged into an object, such as xxx in the code above. This object contains the name of the remote call method, the parameter values ​​of the call, and other information. It can be implemented through the archive::binary_oarchive class in the boost library in C++. After packaging the call information into the xxx object, set the data pointer for this transmission through the following code:

[0081] trans->set_data_ptr(reinterpret_cast<unsigned char*> (&xxx));

[0082] Then call the socket's b_transport method to pass it to the Proxy.

[0083] socket->b_transport(*trans,delay);

[0084] The proxy parses the packaged call parameters it receives and then calls the corresponding remote method. After the remote call returns, the proxy packages the return information into an object (such as yyy in the example code) and sets it in the trans object. The stub retrieves the packaged return information from trans, unpacks it, and returns the return value. Unpacking the return information can be accomplished using archive::binary_iarchive from the Boost library.

[0085] 4c. In the preprocessing module, create a new file that defines the Proxy class, such as mac_proxy.h. Based on the method definition information of the packet processing method obtained in step 3, write code similar to the following into the file.

[0086]

[0087]

[0088] As a target, the mac_proxy class requires a simple_target_socket socket to communicate with the initiator's socket and implement the b_transport method to receive data packets from the initiator. In the b_transport method, the call information packaged in trans (such as func_name, length, and packet in the sample code) is parsed to obtain the method name and parameters to be remotely called, and then the corresponding remote method is called. After the remote call is completed, the return value is saved in the yyy object (yyy must be accessible through trans for the stub to obtain the return value from trans). The mac_proxy class also provides a set_mac method, which primarily retrieves a MAC object and calls its provided rx_packet method.

[0089] Step 2a. The implementer of MAC needs to write code similar to the following. This code is not automatically generated.

[0090]

[0091] The mac class needs to inherit the interface class mac_if and implement the rx_packet method. This method is called after parsing by the Proxy and performs specific processing on the received packet. As previously mentioned, when declaring this method, you need to include a macro such as RMC_API so that the preprocessing module can recognize it and automatically generate the corresponding code. The mac class also contains two pointers, s and p, which hold Stub and Proxy objects, respectively. To minimize the need for MAC programmers to be aware of the existence of Stub and Proxy, you can create a common base class that defines these two pointers and holds Stub and Proxy objects, and then inherit from this base class. The mac class also needs to declare the service module class initialization method rmc_init and the exit method rmc_exit. These methods are generated by the preprocessing module and do not require implementation by the mac class implementor. These methods are primarily used to instantiate the Stub and Proxy and perform the binding between them, as described later. These methods must be called in the mac class constructor and destructor, respectively. The mac class also defines a get_if method to provide the Stub-side Interface to Serdes. The code is described later.

[0092] Step 4d. Create a new file in the preprocessing module to define the implementation of the rmc_init, rmc_exit, and get_if functions of the mac class, such as mac_impl.cpp, and write code similar to the following into it.

[0093]

[0094]

[0095] rmc_init instantiates a Stub and Proxy object, respectively, and calls Proxy's set_mac method to pass the mac object pointer to Proxy. This allows Proxy to parse the call parameters and then call the rx_packet method in the mac class through this object. The socket's bind method is called to bind the Initiator and Target sockets together so that the two sockets can communicate. Finally, the pointers to the Stub and Proxy objects are saved, making it easier to release the memory occupied by the two objects in the rmc_exit function. The get_if method converts mac_stub to mac_if, returning the mac_if object on the Stub side to Serdes. Serdes then calls the rx_packet interface method on the Stub side through this object pointer.

[0096] The foregoing is merely an embodiment of the present invention and is not intended to limit the present invention. It will be apparent to those skilled in the art that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention are intended to be included within the scope of the claims of the present invention.

Claims

1. A method for transaction-level modeling of remote method calls, characterized in that: The method includes: The client module calls the local method provided by the stub unit Stub in the service module to provide data to the stub unit, and the local method of the Stub overrides the virtual interface method in the base class Interface; The local method of the Stub packages the remote method name and call parameters into a transaction-level modeling general payload class tlm_generic_payload, and transmits tlm_generic_payload to the proxy unit Proxy in the service module, wherein the service module includes a stub unit Stub and a proxy unit Proxy; The proxy unit Proxy parses the tlm_generic_payload sent by Stub and calls the remote method for actually processing data in the service module according to the parsing result. The remote method also rewrites the virtual interface method in the base class Interface.

2. The method according to claim 1, characterized in that The method further comprises: The Proxy packages the result information of calling the remote method in the service module and returns it to the Stub; The local method in the Stub unpacks the result information and returns the call result to the client module.

3. The method according to claim 2, characterized in that The method further comprises: The pre-processing module identifies the remote method through the macro definition identifier RMC_API; The preprocessing module reads each source file and scans the code line with RMC_API. If the code line with RMC_API is scanned, the method definition information of the remote method identified by RMC_API is extracted according to the grammatical rules. The definition information includes the return value type, method name, and each parameter type and parameter name of the method; The pre-processing module automatically generates the base class Interface according to the scanning result, and automatically generates the virtual interface method according to the method definition information of the remote method; The pre-processing module automatically generates a stub unit Stub class derived from the base class Interface, and generates the local method in the Stub class according to the method definition information of the remote method; The pre-processing module automatically generates a Proxy class derived from the base class Interface, and generates in the Proxy class the code for parsing the tlm_generic_payload and calling the remote method in the service module; The pre-processing module automatically generates the initialization method rmc_init and the exit method rmc_exit of the service module, and generates the code for instantiating the Stub class and the Proxy class and the code for binding the two in rmc_init.

4. The method according to claim 3, characterized in that The Stub serves as the initiator in transaction-level modeling, and the Proxy serves as the target in transaction-level modeling. Both parties establish a session connection for transmitting the tlm_generic_payload and the return result of the remote method.

5. The method according to claim 4, characterized in that The initiator in the Stub and the target in the Proxy establish a session connection through a socket to exchange information.

6. A device for transaction-level modeling remote method call, characterized in that: The device comprises: a client module and a service module, wherein the service module comprises: a stub unit and an agent unit; The client module is used to call the local method provided by the stub unit in the service module and provide data to the stub unit, wherein the local method of the stub unit overrides the virtual interface method in the base class Interface; The stub unit is used to package the remote method name and call parameters into a transaction-level modeling general payload class through a local method, and transmit the transaction-level modeling general payload class to the proxy unit; The proxy unit is used to parse the transaction-level modeling general load class transmitted by the stub unit, and call the remote method for actually processing data in the service module according to the parsing result. The remote method also rewrites the virtual interface method in the base class Interface.

7. The device according to claim 6, characterized in that The proxy unit is further configured to package the result information of calling the remote method in the service module and return it to the stub unit; The stub unit is further configured to unpack the result information through a local method and return the call result to the client module.

8. The device according to claim 7, characterized in that The device further comprises: a preprocessing unit, configured to read each source file, scan a code line containing RMC_API, and if a code line containing RMC_API is found, extract method definition information of the remote method identified by RMC_API according to grammatical rules, wherein the definition information includes a return value type, a method name, and a type and name of each parameter of the method; wherein the remote method is identified by the macro definition identifier RMC_API; The pre-processing unit is further used to automatically generate the base class Interface according to the scanning result, and automatically generate the virtual interface method according to the method definition information of the remote method; The pre-processing unit is further used to automatically generate a stub unit Stub class derived from the base class Interface, and generate the local method in the Stub class according to the method definition information of the remote method; The pre-processing unit is further used to automatically generate a proxy class derived from the base class Interface, and generate code in the Proxy class to parse the transaction-level modeling general load class and call the remote method in the service module; The pre-processing unit is further configured to automatically generate an initialization method rmc_init and an exit method rmc_exit of the service module, and generate, in rmc_init, codes for instantiating the Stub class and the Proxy class and codes for binding the two.

9. The device according to claim 8, characterized in that The stub unit serves as the initiator in transaction-level modeling, and the proxy unit serves as the target in transaction-level modeling. Both parties establish a session connection for transmitting the transaction-level modeling universal load class and the return result of the remote method.

10. The device according to claim 9, characterized in that The initiator in the stub unit and the target in the proxy unit establish a session connection through a socket to exchange information.

Images