Transaction processing method, device, equipment and product based on hybrid simulation platform

Abstract

The present application discloses a transaction processing method, apparatus, equipment and product based on a hybrid simulation platform, which relates to the field of computer technology. The method comprises receiving a transaction-level request initiated by an upper-level module through a master device, and obtaining a request slice identifier and corresponding request slice content of the transaction-level request; sending a corresponding transaction-level start request message to a slave device based on the request slice identifier; obtaining a response to a transaction end request fed back by the slave device based on the transaction-level start request message; and sending a request slice content corresponding to the request slice identifier to the slave device based on the response to the transaction end request, so that the slave device forwards the received request slice content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module. The method solves the technical problem of resource utilization of the hybrid simulation platform when performing multi-module transaction processing, and achieves the technical effect of improving the accuracy and efficiency of transaction processing.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to transaction processing methods, devices, equipment, and products based on a hybrid simulation platform. Background Art

[0002] With the rapid development of information technology, hybrid simulation platforms are playing an increasingly important role in the design and testing of transmission systems. In related technologies, in transaction-level modeling (TLM) processing, the resource utilization of hybrid simulation platforms is low because the request or response must be fully received before it can be forwarded to the next level. For example, in a multi-module processing scenario, when the transaction initiator initiates a multi-cycle write transaction-level request to the transaction receiver, the transaction receiver must wait until all write transaction data is fully received before it can proceed with subsequent processing. This process undoubtedly extends the latency of the entire processing flow. If the bandwidth configuration of the transaction initiator and the transaction receiver is different during this process, more waiting time and resource consumption may be generated. Summary of the Invention

[0003] The present application provides a transaction processing method, apparatus, device and product based on a hybrid simulation platform to at least solve the problem of low resource utilization of the hybrid simulation platform in the related art.

[0004] The present application provides a transaction processing method based on a hybrid simulation platform, which is applied to a transaction-level processing module. The transaction-level processing module includes a master device and a slave device, including:

[0005] Receive the transaction-level request initiated by the upper module through the main device, and obtain the request fragment identifier and corresponding request fragment content of the transaction-level request;

[0006] Sending a corresponding transaction-level start request message to the slave device based on the request fragment identifier;

[0007] Obtain a response to the transaction end request fed back by the slave device based on the transaction-level start request message;

[0008] Based on the response to the transaction end request, the request fragment content corresponding to the request fragment identifier is sent to the slave device, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module.

[0009] In an optional implementation, sending a transaction-level start request message to a slave device based on the request fragment identifier includes:

[0010] If the request fragment identifier indicates that the transaction-level request needs to send multiple request fragments, and the request fragment currently being sent is not the last fragment, then the current request phase of the master device is determined to be the fragment start request phase;

[0011] Based on the current request phase of the master device, a corresponding shard start request message is sent to the slave device, where the transaction-level start request message includes a shard start request message.

[0012] In an optional implementation, sending a transaction-level start request message to the slave device based on the request fragment identifier further includes:

[0013] If the request fragment identifier indicates that the request fragment content required to be sent for the transaction-level request is one fragment, or if the request fragment content required to be sent is multiple fragments but the request fragment content currently being sent is the last fragment, then the current request phase of the master device is determined to be the transaction start request phase;

[0014] A transaction start request is sent to the slave device based on a current request phase of the master device, where the transaction-level start request message includes a transaction start request message.

[0015] In an optional implementation, obtaining a response to a transaction end request fed back by a slave device based on a transaction-level start request message includes:

[0016] If the slave device cannot immediately receive the request fragment content corresponding to the request fragment identifier, it determines that the current request stage of the slave device is the fragment response request stage, and generates a fragment response request message for the transaction-level start request message based on the current request stage of the slave device, and the response to the transaction end request includes the fragment response request message;

[0017] If the slave device can immediately receive the request fragment content corresponding to the request fragment identifier, it is determined that the current request stage of the slave device is the fragment end request stage, and a fragment end request message is generated for the transaction-level start request message based on the current request stage of the slave device. The response to the transaction end request includes the fragment end request message.

[0018] In an optional implementation, obtaining a response to a transaction end request fed back by a slave device based on a transaction-level start request message includes:

[0019] If the slave device cannot immediately receive the request fragment content corresponding to the request fragment identifier, it determines that the current request stage of the slave device is a transaction response request stage, and generates a transaction response request message for the transaction-level start request message based on the current request stage of the slave device, and the response to the transaction end request includes the transaction response request message;

[0020] If the slave device can immediately receive the request fragment content corresponding to the request fragment identifier, it is determined that the current request stage of the slave device is the transaction end stage, and a transaction end request message is generated for the transaction-level start request message based on the current request stage of the slave device. The response to the transaction end request includes the transaction end request message.

[0021] In an optional embodiment, based on the response to the transaction end request, sending the request fragment content corresponding to the request fragment identifier to the slave device, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module, including:

[0022] If the response to the transaction end request is a fragment response request message, then after receiving the fragment end request message fed back by the slave device in response to the transaction-level start request message, the request fragment content corresponding to the request fragment identifier is sent to the slave device, so that the slave device forwards the received request fragment content to the corresponding lower-level module, and after receiving the transaction end request message fed back by the slave device in response to the transaction-level start request message, the transaction-level request initiated by the upper-level module is ended.

[0023] In an optional embodiment, the above method further includes:

[0024] By receiving the transaction-level response initiated by the lower-level module for the transaction-level request from the device, and obtaining the response fragment identifier and corresponding response fragment content of the transaction-level response;

[0025] Sending a corresponding transaction-level start response message to the master device based on the response fragment identifier;

[0026] Obtaining a transaction end response from the master device based on the transaction-level start response message;

[0027] Based on the response of the transaction end response, the response fragment content corresponding to the response fragment identifier is sent to the main device, so that the main device forwards the received response fragment content to the corresponding upper module and ends the transaction-level response initiated by the lower module.

[0028] In an optional implementation, sending a corresponding transaction-level start response message to the master device based on the response fragment identifier includes:

[0029] If the response fragment identifier indicates that the transaction-level response requires multiple fragments to be sent, and the response fragment currently being sent is not the last fragment, the current response phase of the slave device is determined to be the fragment start response phase;

[0030] Based on the current response phase of the slave device, a corresponding fragment start response message is sent to the master device, where the transaction-level start response message includes a fragment start response message.

[0031] In an optional implementation, sending a corresponding transaction-level start response message to the master device based on the response fragment identifier further includes:

[0032] If the response fragment identifier indicates that the response fragment content required to be sent for the transaction-level response is one fragment, or if the response fragment content required to be sent is multiple fragments but the response fragment content currently being sent is the last fragment, then the current response phase of the slave device is determined to be the transaction start response phase;

[0033] Based on the current response phase of the slave device, a corresponding transaction level start response message is sent to the master device, where the transaction level start response message includes a transaction level start response message.

[0034] In an optional implementation, obtaining a response of a transaction end response fed back by the master device based on the transaction-level start response message includes:

[0035] If the master device cannot immediately receive the response fragment content corresponding to the response fragment identifier, it determines that the current response phase of the master device is the fragment acknowledgment response phase, and generates a fragment acknowledgment response message for the transaction-level start response message based on the current request phase of the master device, and the response of the transaction end response includes the fragment acknowledgment response message;

[0036] If the slave device can immediately receive the response fragment content corresponding to the response fragment identifier, it is determined that the current response stage of the master device is the fragment end response stage, and a fragment end response message is generated for the transaction-level start response message based on the current response stage of the master device. The response to the transaction end response includes the fragment end response message.

[0037] In an optional implementation, obtaining a response of a transaction end response fed back by the master device based on the transaction-level start response message further includes:

[0038] If the master device cannot immediately receive the response fragment identifier and the corresponding response fragment content, it determines that the current response phase of the master device is the transaction acknowledgement response phase, and generates a transaction acknowledgement response message for the transaction-level start response message based on the current request phase of the master device, and the response to the transaction end response includes the transaction acknowledgement response message;

[0039] If the master device can immediately receive the response fragment identifier and the corresponding response fragment content, it is determined that the current request stage of the master device is the transaction end response stage, and a transaction end response message is generated for the transaction-level start response message based on the current request stage of the master device. The reply to the transaction end response includes the transaction end response message.

[0040] In an optional embodiment, based on the response of the transaction end response, sending the response fragment content corresponding to the response fragment identifier to the master device, so that the master device forwards the received response fragment content to the corresponding upper-level module and ends the transaction-level response initiated by the lower-level module, including:

[0041] If the response to the transaction end request is a fragment response message, then after receiving the fragment end response message fed back by the master device in response to the transaction level start response message, the response fragment content corresponding to the response fragment identifier is sent to the master device, so that the master device forwards the received response fragment content to the corresponding upper module, and after receiving the transaction end response message fed back by the master device in response to the transaction level start response message, the transaction level response initiated by the lower module is ended.

[0042] The present application also provides a transaction processing device based on a hybrid simulation platform, comprising:

[0043] The transaction request receiving module is used to receive the transaction-level request initiated by the upper module through the master device, and obtain the request fragment identifier and corresponding request fragment content of the transaction-level request;

[0044] A request message sending module, configured to send a corresponding transaction-level start request message to the slave device based on the request fragment identifier;

[0045] An end request response module is used to obtain a response to the transaction end request fed back by the slave device based on the transaction-level start request message;

[0046] The transaction request processing module is used to send the request fragment content corresponding to the request fragment identifier to the slave device based on the response to the transaction end request, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module.

[0047] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing any of the steps of the above-mentioned transaction processing method based on the hybrid simulation platform when executing the computer program.

[0048] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned transaction processing methods based on the hybrid simulation platform are implemented.

[0049] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned transaction processing methods based on the hybrid simulation platform when executed by a processor.

[0050] Through this application, after receiving the transaction-level request initiated by the upper module, the master device can obtain the fragment identifier and content in the request, and send a start request message to the slave device accordingly. After the slave device feeds back the response to the transaction end request, the master device then sends the request fragment content corresponding to the request fragment identifier. In this way, the slave device can instantly forward the received request fragment content to the lower module without waiting for all write transaction data to be completely received before processing, thereby improving the resource utilization of the hybrid simulation platform and shortening the delay of the processing flow. In addition, since the communication between the lower module and the upper module is carried out through transaction-level requests and transaction-level responses, and the processing content is reasonably fragmented, the efficiency and reliability of transaction processing are further improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0052] Figure 1 An application scenario diagram of the transaction processing method based on the hybrid simulation platform provided in an embodiment of the present application;

[0053] Figure 2 A flowchart of a transaction processing method based on a hybrid simulation platform provided in an embodiment of the present application;

[0054] Figure 3 An example diagram of a transaction processing method based on a hybrid simulation platform provided in an embodiment of the present application;

[0055] Figure 4 Another example diagram of the transaction processing method based on the hybrid simulation platform provided in an embodiment of the present application;

[0056] Figure 5 A flowchart of another transaction processing method based on a hybrid simulation platform provided in an embodiment of the present application;

[0057] Figure 6 An example diagram of a transaction processing method based on a hybrid simulation platform provided in an embodiment of the present application;

[0058] Figure 7 Another example diagram of the transaction processing method based on the hybrid simulation platform provided in an embodiment of the present application;

[0059] Figure 8 A structural block diagram of a transaction processing device based on a hybrid simulation platform provided in an embodiment of the present application;

[0060] Figure 9 A schematic structural diagram of an electronic device is provided for an embodiment of the present application. DETAILED DESCRIPTION

[0061] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0062] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0063] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0064] See also Figure 1 , Figure 1 This is a schematic diagram of an application environment provided by an embodiment of the present invention, which includes an upper-level module and a lower-level module that communicates with the upper-level module through a transaction-level module.

[0065] As an example, in the related art, upper-level module A, such as a module using a register transfer level (RTL) model, transaction-level module B, such as a module using a transaction level model (TLM, specifically including a master device B1 and a slave device B2 of the transaction level model), and lower-level module C, such as a module using a register transfer level (RTL) model, perform transaction processing. If upper-level module A, as the transaction initiator, initiates a multi-cycle write transaction to lower-level module C, the transaction receiver, as the transaction initiator, For example, if the interface width of upper-level module A is 32 bits, and the RTL model corresponding to upper-level module A performs a 16-byte write request, which requires four cycles to complete. In this case, according to the four general phases of the transaction-level model (TLM) corresponding to transaction-level module B, transaction-level module B cannot issue the BEGIN_REQ request before the start of the fourth cycle. This is because transaction-level module B must prepare all data bytes before initiating the BEGIN_REQ request. When transaction-level module B sends the request to lower-level module C, lower-level module C does not receive the complete 16-byte request until the eighth cycle. Therefore, the write request from upper-level module A to lower-level module C takes eight cycles to transmit due to the limitations of the intermediate transaction-level model processing. Lower-level module C will accept the request (i.e., send the END_REQ response) after it has transmitted the last word of the request. This occurs in the eighth cycle, or even later if lower-level module C is performing downstream flow control operations. Before this happens, the upper-level module A will be unable to send the next read or write request, ultimately halving the peak available bandwidth. If the bandwidth configurations (bit width or frequency) at both ends of the transaction-level module B are different, further waste will occur.

[0066] Based on this, according to an embodiment of the present invention, an embodiment of a transaction processing method based on a hybrid simulation platform is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0067] The present disclosure provides a transaction processing method based on a hybrid simulation platform, which can transmit the transaction-level request fragments initiated by the upper module to the lower module, and can also transmit the transaction-level response fragments fed back by the lower module to the upper module for the transaction-level request initiated by the upper module, so as to achieve efficient and accurate transaction-level processing between different simulation models and improve the transaction processing resource utilization of the hybrid simulation platform. The transaction processing method based on the hybrid simulation platform can be applied to Figure 1 The transaction-level processing module in the transaction processing system based on the hybrid simulation platform includes a master device and a slave device, or an electronic device used to run the transaction processing system based on the hybrid simulation platform. The electronic device may include but is not limited to a tablet computer, a laptop computer, a desktop computer, a server, a controller, etc. Figure 2 , which is a flow chart of a transaction processing method based on a hybrid simulation platform provided in some embodiments of the present disclosure. Figure 2 In the present invention, the transaction processing method based on the hybrid simulation platform may include the following steps:

[0068] Step 210: Receive the transaction-level request initiated by the upper module through the master device, and obtain the request fragment identifier of the transaction-level request and the corresponding request fragment content.

[0069] Among them, the model corresponding to the upper module can be a register transfer level model RTL or a transaction level model TLM, which is not limited here. The main device receives the transaction level request initiated by the upper module and obtains the request slice identifier and corresponding request slice content of the transaction level request, which can provide a basis for subsequent slice transmission and processing.

[0070] In some optional embodiments, when a master device receives a transaction-level request initiated by a superior module and obtains the request fragment identifier and corresponding request fragment content of the transaction-level request, the master device can receive the transaction-level request from the superior module via a preset transmission interface / communication interface, wherein the transaction-level request is embedded with the request fragment identifier and corresponding request fragment content. After receiving the message, the master device can parse the message content to obtain the request fragment identifier and corresponding request fragment content, providing a basis for subsequent processing.

[0071] Furthermore, to effectively manage and process the requested fragments, the master device can also store the obtained requested fragments in a pre-set storage area and, when storing, tag the requested fragments with the requested fragment identifier. This allows the master device to quickly locate and read the corresponding requested fragments based on the requested fragment identifier when sending them to the slave device, improving processing efficiency.

[0072] Furthermore, to ensure transaction accuracy and reliability, the master device can verify the transaction-level request message upon receipt. For example, it can calculate the message's checksum and compare it with a preset checksum to determine whether an error occurred during transmission. If the message verification fails, the master device can discard the message and send an error message to the higher-level module, prompting it to resend the transaction-level request message.

[0073] Step 220: Send a corresponding transaction-level start request message to the slave device based on the request fragment identifier.

[0074] As mentioned above, by sending the corresponding transaction-level start request message to the slave device based on the request shard identifier, the formal start of the transaction-level processing is marked, and the slave device is notified to prepare to receive subsequent request shard contents, so as to ensure that the slave device can timely understand the transaction processing intention of the master device and prepare for subsequent data processing.

[0075] In some optional embodiments, when a transaction-level start request message is sent to a slave device based on a request fragment identifier, if the request fragment identifier indicates that the request fragment content required to be sent for the transaction-level request is multiple fragments, and the request fragment content currently being sent is not the last fragment, then the current request stage of the master device is determined to be the fragment start request stage; based on the current request stage of the master device, a corresponding fragment start request message is sent to the slave device, and the transaction-level start request message includes a fragment start request message.

[0076] Specifically, during the shard start request phase, specific identification information can be embedded in the shard start request message to clearly indicate that the content of the currently sent request shard is part of a multi-shard transaction-level process and is not the final shard of the transaction-level process. This helps the slave device accurately identify and prepare to receive subsequent shard content, while understanding the status of the entire transaction processing process. In addition, the function of attaching verification information to the shard start request message can be used to ensure the integrity and correctness of the shard start request message received from the device. If the slave device successfully verifies and confirms that the received shard start request message is correct, it will enter the waiting state and prepare to receive subsequent shard content, thereby ensuring the smoothness and efficiency of the entire transaction-level processing process.

[0077] In other optional implementations, when a transaction-level start request message is sent to a slave device based on a request slice identifier, if the request slice identifier indicates that the request slice content required to be sent for the transaction-level request is one slice, or the request slice content required to be sent is multiple slices but the request slice content currently being sent is the last slice, then the current request stage of the master device is determined to be the transaction start request stage; based on the current request stage of the master device, a transaction start request is sent to the slave device, and the transaction-level start request message includes a transaction start request message.

[0078] Specifically, in addition to the necessary request segment identification information, this transaction start request message may also contain summary information about the entire transaction-level request, such as the transaction type and data length. This helps the slave device quickly understand the core content of the current transaction processing request and prepare for corresponding data reception or processing in advance. Furthermore, the transaction start request message also includes verification information to ensure the integrity and correctness of the message, further enhancing the reliability and stability of transaction processing.

[0079] In some optional implementations, when the master device sends a transaction-level start request message to the slave device, it may also transmit the request fragment identifier as part of the message. This allows the slave device to parse the message content after receiving the message to obtain the request fragment identifier, thereby understanding the specific request fragment involved in the current transmission. This helps the slave device accurately identify and process the received processing data.

[0080] In addition, to ensure smooth transmission, the master device can also send a transmission establishment request message to the slave device before sending the transaction-level start request message to establish a transmission connection with the slave device. After the slave device successfully responds to the transmission establishment request message, the master device will send the transaction-level start request message again. This ensures that the transmission connection between the master and slave devices is stable and reliable, further improving the accuracy and reliability of transaction processing. At the same time, when sending the transaction-level start request message, the master device can also set the priority of the message to ensure that high-priority processing requests are given priority in resource-constrained situations, thereby improving processing efficiency. After the slave device receives the transaction-level start request message, it can prepare to receive and process the subsequent request fragment content based on the request fragment identifier in the message.

[0081] Step 230: Obtain a response to the transaction end request fed back by the slave device based on the transaction-level start request message.

[0082] As shown above, by obtaining the slave's response to the transaction-level start request message, the slave device confirms that it has successfully received the transaction-level start request message and is ready to enter the phase of receiving the requested fragment content. This response signal is important feedback in the transaction processing process, ensuring the synchronization of the processing status between the master and slave devices and providing the foundation for subsequent data processing.

[0083] In some optional embodiments, when obtaining a response to a transaction end request fed back by the slave device based on a transaction-level start request message, if the slave device cannot immediately receive the request fragment content corresponding to the request fragment identifier, it is determined that the current request stage of the slave device is a fragment response request stage, and a fragment response request message for the transaction-level start request message is generated based on the current request stage of the slave device, and the response to the transaction end request includes the fragment response request message; if the slave device can immediately receive the request fragment content corresponding to the request fragment identifier, it is determined that the current request stage of the slave device is a fragment end request stage, and a fragment end request message for the transaction-level start request message is generated based on the current request stage of the slave device, and the response to the transaction end request includes the fragment end request message.

[0084] Specifically, during the fragment response request phase, the fragment response request message can include the current status information of the slave device, such as its busy status and expected reception time, so that the master device can understand the actual situation of the slave device and adjust its strategy for sending the request fragment accordingly. For example, if the slave device is busy, the master device can choose to suspend sending the request fragment content and wait until the slave device is ready before continuing to send it, thereby avoiding loss or misordering of transaction processing data. In addition, the fragment response request message also includes verification information to ensure the integrity and correctness of the message, further enhancing the reliability and stability of transaction processing.

[0085] During the Segment End Request phase, the Segment End Request message signals the successful transmission and reception of a request segment within the current transaction-level processing. At this point, the slave device is ready to receive the next request segment (if one exists), or the entire transaction-level request has been completely transmitted and received. Upon receiving the Segment End Request message, the master device can decide whether to continue sending the next request segment or terminate the entire transaction-level processing based on the current transaction-level processing status.

[0086] In other optional embodiments, when obtaining a response to a transaction end request fed back by the slave device based on a transaction-level start request message, if the slave device cannot immediately receive the request fragment content corresponding to the request fragment identifier, then the current request stage of the slave device is determined to be a transaction response request stage, and a transaction response request message is generated for the transaction-level start request message based on the current request stage of the slave device, and the response to the transaction end request includes the transaction response request message; if the slave device can immediately receive the request fragment content corresponding to the request fragment identifier, then the current request stage of the slave device is determined to be a transaction end stage, and a transaction end request message is generated for the transaction-level start request message based on the current request stage of the slave device, and the response to the transaction end request includes the transaction end request message.

[0087] Specifically, during the transaction response request phase, the transaction response request message can include the slave device's confirmation of the current transaction-level request, as well as the estimated time when the slave device will begin receiving the request fragment content, so that the master device can understand the slave device's response and adjust subsequent processing strategies accordingly. For example, if the slave device expects it will take some time to receive the request fragment content, the master device can choose to wait until the slave device is ready before continuing to send the request fragment content, or take other measures to optimize processing efficiency. In addition, the transaction response request message also contains verification information to ensure the integrity and correctness of the message.

[0088] During the transaction completion phase, a transaction completion request message signals the successful completion of the entire transaction-level request. At this point, the slave device has successfully received and processed all requested shards, and the master device has received confirmation from the slave device. The transaction completion request message can include a summary of the entire transaction-level processing, such as processing status and data integrity check results. Upon receiving the transaction completion request message, the master device confirms the successful completion of the entire processing and performs subsequent processing or operations as needed, such as updating the processing status, releasing related resources, or triggering other related tasks.

[0089] Furthermore, to ensure processing continuity and stability, the master device can continue to monitor the processing status and send subsequent transaction-level requests as needed after receiving a response to the transaction end request from the slave device. Furthermore, the master device can dynamically adjust processing parameters or strategies based on the actual processing situation, such as adjusting the data transmission rate, retransmission strategy, or the use of error correction codes, to adapt to different network environments and processing requirements, thereby optimizing processing efficiency and resource utilization, and further ensuring processing continuity and stability.

[0090] Step 240, based on the response to the transaction end request, sends the request fragment content corresponding to the request fragment identifier to the slave device, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module.

[0091] As mentioned above, by responding to the transaction end request, the request fragment content corresponding to the request fragment identifier is sent to the slave device, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module, thereby ensuring the correct execution of the transaction-level request and the accurate processing of the data.

[0092] In some optional embodiments, based on the response to the transaction end request, the request fragment content corresponding to the request fragment identifier is sent to the slave device, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module. If the response to the transaction end request is a fragment response request message, then after receiving the fragment end request message fed back by the slave device for the transaction-level start request message, the request fragment content corresponding to the request fragment identifier is sent to the slave device, so that the slave device forwards the received request fragment content to the corresponding lower-level module to ensure that the slave device is ready to receive the request fragment content, thereby avoiding data loss or processing errors, and ending the transaction-level request initiated by the upper-level module after receiving the transaction end request message fed back by the slave device for the transaction-level start request message. If the response to the transaction end request is a transaction response request message, then after receiving the transaction end request message fed back by the slave device for the transaction-level start request message, the request fragment content corresponding to the request fragment identifier is sent to the slave device. At this point, after receiving the request fragment, the slave device forwards it to the corresponding lower-level module. After processing, it sends a transaction completion confirmation message to the upper-level module, marking the complete completion of the transaction-level request initiated by the upper-level module. After receiving this confirmation message, the master device releases related resources and prepares to process the next transaction-level request, thus ensuring the continuity and efficiency of the entire transaction processing process.

[0093] In other optional implementations, when the request fragment content corresponding to the request fragment identifier is sent to the slave device based on the response to the transaction end request, if the response to the transaction end request is a transaction response request message, the master device can arrange the sending plan of the request fragment content according to the expected receiving time fed back by the slave device. For example, the master device can choose to send the request fragment content in advance before the time point when the slave device is expected to start receiving, so as to ensure that the slave device can receive the data immediately after it is ready. Alternatively, the master device can also choose to send the request fragment content on time at the expected receiving time point fed back by the slave device, so as to avoid waste of resources caused by sending too early or transaction processing delay caused by sending too late.

[0094] Furthermore, to ensure the accuracy and integrity of the request fragment content, the master device can also perform a checksum calculation on the request fragment content before sending it, and use the checksum as part of the request fragment content for transaction processing. After receiving the request fragment content, the slave device can also perform a checksum calculation and compare it with the received checksum to determine whether the request fragment content has any errors during the transaction processing. If the checksum fails, the slave device can send an error message to the master device, requesting that the master device resend the request fragment content, thereby ensuring data accuracy and reliability.

[0095] Once the master successfully sends all request segments and receives confirmation from the slave for each, the transaction-level request is declared complete. At this point, the master can update the transaction status, release related resources, and prepare to receive the next transaction-level request. Simultaneously, the slave forwards the received request segments to the corresponding lower-level modules for subsequent data processing or operations, ensuring the normal operation and efficiency of the entire transaction processing system.

[0096] Figure 3 An example of a transaction processing method based on a hybrid simulation platform of the present invention is shown, comprising step a1: a master device initiates a transaction-level request. If the current transaction-level request needs to be divided into multiple request segments, i.e., multiple operations are required to send the request, and the non-last data, i.e., the last request segment, is currently being sent, then the master device's current request phase is determined to be the segment start request phase SEGMENT_BEGIN_REQ, and the process goes to step a2.

[0097] If the current transaction-level request only requires one operation to be sent, or requires multiple operations to be sent and the last data is currently being sent, then the current request phase of the master device is determined to be the transaction start request phase BEGIN_REQ; go to step a4;

[0098] Step a2: If the slave device receives a request that is not the last operation and can receive data immediately, it determines that the current request phase of the slave device is the segment end request phase SEGMENT_END_REQ and responds to the master device. The slave device can continue to process the transaction request data to the next-level module (for example, an RTL model or a TLM model) and returns to step a1. Otherwise, if the slave device cannot receive data immediately, go to step a3.

[0099] Step a3: If the slave receives a request that is not the last one and the slave cannot receive data immediately, it determines that the current request phase of the slave is the segment acknowledgment request phase SEGMENT_ACK_REQ and responds to the master. At this time, both the master and the slave are blocked until the slave can receive data. Then, it determines that the current request phase of the slave is the segment end request phase SEGMENT_END_REQ and responds to the master. Go to step a1.

[0100] Step a4: If the slave device receives the request for the last operation and can immediately receive data, it determines that the current request phase of the slave device is the transaction response request phase END_REQ and responds to the master device. The slave device can then continue to process the transaction request data to the next-level module (e.g., an RTL model or a TLM model), and the request phase execution ends. Otherwise, if the slave device cannot immediately receive data, go to step a5.

[0101] Step a5: When the slave receives the last request and cannot receive data immediately, the slave determines that the current request phase of the slave is the transaction end phase ACK_REQ and responds to the master. At this point, both the master and slave are blocked until the slave is able to receive data. At this point, the slave determines that the current request phase of the slave is the transaction response request phase END_REQ and responds to the master. The request phase execution ends.

[0102] Figure 4 Another example of the transaction processing method based on the hybrid simulation platform of the present invention is shown. At time t0, the master device initiates a request for the first data item of the slave device (the request requires sending a total of four data items). During the sending, the master device's current request phase is the shard start request phase, and the phase is shard start request ①. After the slave device receives the first data item, the slave device currently has no back pressure and can immediately receive it. The slave device's current request phase is the shard end request phase, and the phase is shard end request ③. The slave device immediately sends a response to the master device. It then begins to receive request data 0. After receiving the data, it forwards it to the next-level module (which can be a TLM model or an RTL model).

[0103] At time t1, the master device initiates a request for the second data entry from the slave device. The master device is in the Shard Start Request phase, with a phase of Shard Start Request ①. After the slave device receives the second data entry, back pressure may occur. The slave device is in the Shard Reply Request phase, with a phase of Shard Reply Request ②. The slave device immediately sends a response to the master device. At this point, both the master and the slave are blocked.

[0104] At time t2, the slave device is awakened from its blocked state and can receive data (perhaps because it has finished processing other processes or there is space in its internal request buffer). The slave device is currently in the fragment end request phase, with the fragment end request phase being ③. It immediately sends a response to the master device and then begins receiving request data 1. After receiving the data, it forwards it to the next-level module (which can be a TLM model or an RTL model).

[0105] At time t3, the master device initiates a request for the third piece of data to the slave device. When sending, the master device sets the current request phase to the fragment start request phase and the phase to fragment start request ①. After the slave device receives the third piece of data, if there is no back pressure on the current slave device and it can receive it immediately, the slave device sets the current request phase to the fragment end request phase and the phase to fragment end request ③, and immediately sends a response to the master device. It then starts to receive request data 3. After receiving the data, it can forward it to the next level module (which can be a TLM model or RTL model).

[0106] At time t4, the master device initiates a request for the fourth data entry (also the last data entry of the current request) to the slave device. When sending the data entry, the master device sets the current request phase to the transaction start request phase and the phase to transaction start request ④. After the slave device receives the fourth data entry, in this example, it is assumed that the slave device cannot receive the data immediately due to back pressure (perhaps the slave device is processing other processes or the internal request buffer is full). The slave device sets the current request phase to the transaction reply request phase and the phase to transaction reply request ⑤ and immediately sends a reply to the master device. At this point, both the master and the slave device are blocked.

[0107] At t5, the slave device wakes up from its blocked state and can receive data (perhaps because it has finished processing other processes or because there is space in its internal request buffer). The slave device is currently in the transaction end request phase, with phase 6 of the transaction end request. It immediately sends a response to the master device and then begins receiving request data 3.

[0108] At time t6, the slave device completes receiving the request data 3. After receiving the request data 3, it can be forwarded to the next-level module (which can be a TLM model or an RTL model). The entire request phase processing is completed.

[0109] In summary, the transaction processing method based on the hybrid simulation platform provided by the present invention can efficiently support transaction-level processing between the master device and the slave device, ensuring the accuracy of data processing and the efficiency of processing. By introducing the request fragmentation identifier and the start request message of the transaction-level processing, the transaction-level request is processed in the form of a word stream or a byte stream, ensuring the bandwidth utilization of the platform communication. When the bandwidth configurations at both ends of the transaction-level processing module are different (including different bus bit widths or different clocks), the back pressure of the path is responded to through the phase phase transmitted in the TLM interface, thereby supporting communication behaviors when the master device sends requests quickly and the slave device receives requests slowly, or when the slave device sends responses quickly and the master device receives responses slowly. In addition, by using mechanisms such as fragment response request messages and transaction response request messages according to the actual situation of the slave device and the transaction processing status, efficient collaboration between the master device and the slave device is achieved, ensuring the continuity and stability of transaction processing.

[0110] Figure 5 FIG. 1 shows a flow chart of another embodiment of a transaction processing method based on a hybrid simulation platform of the present invention. Figure 5 As shown, the method includes the following steps:

[0111] Step 510: Receive a transaction-level response initiated by a lower-level module for a transaction-level request from the device, and obtain a response fragment identifier and corresponding response fragment content of the transaction-level response.

[0112] The model corresponding to the lower-level module can be a register transfer level model (RTL) or a transaction level model (TLM), without limitation. The response fragment received by the slave device can be the processing result or related data of the transaction-level request initiated by the upper-level module. After receiving the response from the lower-level module, the slave device will parse the response fragment identifier and the corresponding request fragment content to provide a basis for subsequent fragment transmission and processing.

[0113] In some optional embodiments, when a slave device receives a transaction-level response initiated by a lower-level module for a transaction-level request and obtains a response fragment identifier and corresponding response fragment content of the transaction-level response, the response fragment content from the lower-level module can be received through a preset communication interface. The preset communication interface can be a serial communication interface, such as UART, SPI, or I2C, or a parallel communication interface, or data processing can be performed through a network communication interface. The transaction-level response is embedded with a response fragment identifier and corresponding request fragment content. After receiving the message, the slave device can parse the message content to obtain the response fragment identifier and corresponding response fragment content, providing a basis for subsequent processing.

[0114] Furthermore, after receiving the response fragment content from the lower-level module, the slave device can also perform verification and validation on the response fragment content to ensure the accuracy and integrity of the data. The verification process can include calculating a checksum on the response fragment content and comparing it with the checksum received from the slave device. If the verification fails, the slave device can send an error message to the corresponding upper-level module, requesting the response fragment content to be resent, thereby ensuring reliable data transmission and processing.

[0115] Step 520: Send a corresponding transaction-level start response message to the master device based on the response fragment identifier.

[0116] As described above, by sending the corresponding transaction-level start response message to the master device based on the response fragment identifier, the master device can promptly learn that the slave device has received the response from the lower-level module and prepare for subsequent data processing or operation.

[0117] In some optional embodiments, when a corresponding transaction-level start response message is sent to the master device based on the response fragment identifier, if the response fragment identifier indicates that the response fragment content required to be sent for the transaction-level response is multiple fragments, and the response fragment content currently being sent is not the last fragment, then the current response stage of the slave device is determined to be the fragment start response stage; based on the current response stage of the slave device, a corresponding fragment start response message is sent to the master device, and the transaction-level start response message includes a fragment start response message.

[0118] Specifically, when a slave device is in the fragment start response phase, the message can be specifically marked as fragment start to distinguish it from other types of response messages. Such marking can help the master device identify that the currently received response message is part of a fragment and not the final fragment. In addition, the fragment start response message can also include some information about subsequent fragments, such as the expected total number of fragments, the sequence number of the current fragment, etc., so that the master device can better manage and reorganize these fragments, thereby enabling more efficient transaction-level processing between the master and slave devices, especially when processing large amounts of data or complex tasks, to ensure data integrity and transaction accuracy.

[0119] In other optional embodiments, when a corresponding transaction-level start response message is sent to the master device based on the response fragment identifier, if the response fragment identifier indicates that the response fragment content required to be sent for the transaction-level response is one piece, or the response fragment content required to be sent is multiple pieces but the response fragment content currently being sent is the last piece, then the current response stage of the slave device is determined to be the transaction start response stage; based on the current response stage of the slave device, a corresponding transaction-level start response message is sent to the master device, and the transaction-level start response message includes a transaction-level start response message.

[0120] Specifically, when a slave device is in the transaction start response phase, the message can be specifically marked as a transaction start, distinguishing it from a fragment start response message or other types of response messages. This marking is crucial for the master device, as it allows it to immediately identify whether the currently received response message is the beginning or end of the entire transaction, especially when the transaction consists of only one response fragment or the current fragment is the last fragment. Furthermore, the transaction start response message can also contain key information about the entire transaction, such as the transaction identifier, transaction type, and data integrity checksum. This information is crucial for the master device, as it helps it verify data accuracy, reassemble data (if the transaction consists of multiple fragments), and perform subsequent operations based on the transaction type. This enables more efficient and accurate transaction-level processing between the master and slave devices, ensuring data integrity and transaction accuracy, especially when processing large amounts of data or executing complex tasks.

[0121] In some optional implementations, when a slave device sends a transaction-level start response message to the master device, it may also include message priority information. This priority information can be set based on the urgency of the transaction, the importance of the data, or other relevant factors. By including priority information, the slave device can inform the master device of the priority of the current transaction, allowing the master device to rationally allocate resources and time when processing multiple transactions, giving priority to high-priority transactions, thereby further improving transaction processing efficiency and overall system performance.

[0122] Step 530: Obtain a transaction end response response fed back by the master device based on the transaction-level start response message.

[0123] As above, by obtaining the response of the transaction end response fed back by the master device based on the transaction level start response message, it can be confirmed that the master device has successfully received the transaction level start response message sent by the slave device and has completed the corresponding transaction level transmission / communication processing.

[0124] In some optional embodiments, when obtaining a response to a transaction end response fed back by the master device based on a transaction-level start response message, if the master device cannot immediately receive the response fragment content corresponding to the response fragment identifier, it is determined that the current response stage of the master device is the fragment response stage, and a fragment response response message is generated for the transaction-level start response message based on the current request stage of the master device, and the response to the transaction end response includes the fragment response response message; if the slave device can immediately receive the response fragment content corresponding to the response fragment identifier, it is determined that the current response stage of the master device is the fragment end response stage, and a fragment end response message is generated for the transaction-level start response message based on the current response stage of the master device, and the response to the transaction end response includes the fragment end response message.

[0125] Specifically, during the fragmented acknowledgment response phase, the fragment information of the response fragments that the master device failed to immediately receive can be recorded and stored in internal memory. When the master device is ready to receive the fragmented content, the corresponding response fragmented content is resent to the master device based on the stored fragment information. In addition, to ensure data integrity and accuracy, a checksum is calculated and appended before sending each response fragment. After receiving the response fragmented content, the master device verifies the checksum and confirms receipt of the fragmented content only if the verification passes.

[0126] During the fragment completion response phase, the master device can send an acknowledgment signal to the slave device, indicating that all response fragments have been successfully received and processed. At this point, the slave device marks the transaction as completed and clears all temporary data and status information related to the transaction from its internal memory, preparing for the next transaction.

[0127] In other optional embodiments, when obtaining a response to the transaction end response fed back by the master device based on the transaction-level start response message, if the master device cannot immediately receive the response fragment identifier and the corresponding response fragment content, it is determined that the current response stage of the master device is the transaction response response stage, and a transaction response response message is generated for the transaction-level start response message based on the current request stage of the master device, and the response to the transaction end response includes the transaction response response message; if the master device can immediately receive the response fragment identifier and the corresponding response fragment content, it is determined that the current request stage of the master device is the transaction end response stage, and a transaction end response message is generated for the transaction-level start response message based on the current request stage of the master device, and the response to the transaction end response includes the transaction end response message.

[0128] Specifically, during the transaction acknowledgement response phase, the slave device records the relevant information of the response segments that the master device failed to immediately receive and waits for the master device to be ready to receive the data. Once the master device is ready, the slave device resends the unreceived response segments to ensure complete data transmission. During this process, the slave device can transmit data with the master device through a preset transmission interface, which can be a serial transmission interface such as UART, SPI, or I2C, or a parallel transmission interface or network transmission interface. To ensure data accuracy, each response segment is appended with a checksum before being sent, and the master device verifies the checksum after receiving the response segment.

[0129] During the transaction end response phase, the master device sends an acknowledgment signal to the slave device, indicating that all response fragments have been successfully received and processed. At this point, the slave device marks the transaction-level processing as completed and clears the temporary data and status information associated with the transaction-level processing, preparing for the next processing. This mechanism ensures the continuity and stability of transmission between the master and slave devices, improving transaction processing efficiency. Furthermore, by introducing request fragment identifiers and transaction-level processing start request messages, it can flexibly adapt to transaction processing requirements of varying scale and complexity. Furthermore, by verifying information, transmitting establishment request messages, and setting message priorities, the reliability and stability of transaction processing are further improved.

[0130] Step 540, based on the response of the transaction end response, sends the response fragment content corresponding to the response fragment identifier to the master device, so that the master device forwards the received response fragment content to the corresponding upper module and ends the transaction-level response initiated by the lower module.

[0131] As described above, by responding based on the transaction end response, the response fragment content corresponding to the response fragment identifier is sent to the main device, so that the main device forwards the received response fragment content to the corresponding upper module and ends the transaction-level response initiated by the lower module, thereby ensuring the correct execution of the transaction end response and accurate processing of the data.

[0132] In some optional embodiments, based on the response to the transaction end response, the response fragment content corresponding to the response fragment identifier is sent to the master device so that the master device forwards the received response fragment content to the corresponding upper module and ends the transaction-level response initiated by the lower module. If the response to the transaction end request is a fragment response response message, then after receiving the fragment end response message fed back by the master device for the transaction-level start response message, the response fragment content corresponding to the response fragment identifier is sent to the master device so that the master device forwards the received response fragment content to the corresponding upper module and ends the transaction-level response initiated by the lower module after receiving the transaction end response message fed back by the master device for the transaction-level start response message. If the response to the transaction end request is a transaction end response message, the response fragment content corresponding to the response fragment identifier is directly read from the internal memory and sent to the master device. After sending all response fragments, the slave device waits for the transaction end response message from the master device. Once this message is received, the slave device marks the transaction-level processing as completed and clears all temporary data and status information related to the transaction-level processing, ensuring the continuity and stability of the transaction-level response while also improving the efficiency and accuracy of data processing. By introducing the request fragment identifier and the start request message for transaction-level processing, transaction-level requests are processed in a word stream or byte stream manner, improving the bandwidth utilization of platform communications. At the same time, through mechanisms such as fragment response request messages and transaction response request messages, efficient collaboration between the master and slave devices is achieved, ensuring the continuity and stability of transaction processing.

[0133] Furthermore, to ensure the reliability and stability of transaction processing, the slave device performs multiple checksums and verifications before sending each response fragment to ensure data accuracy and integrity. Furthermore, the slave device dynamically adjusts the sending rate based on feedback from the master device and current network conditions to optimize processing performance.

[0134] Figure 6Another example of the transaction processing method based on the hybrid simulation platform of the present invention is shown, including step b1: initiating a transaction-level response from the device. If the current transaction-level response needs to be divided into multiple response fragments, that is, multiple operations are required to complete the transmission and the non-last data, that is, the last response fragment, is currently being sent, then the current response stage of the slave device is determined to be the segment start response stage SEGMENT_BEGIN_RESP; go to step b2; if the current response only requires one operation to complete the transmission, or requires multiple operations to complete the transmission and the last data is currently being sent, then the current response stage of the slave device is determined to be the transaction start response stage BEGIN_RESP; go to step b4;

[0135] Step b2: If the master device receives a response that is not the last one and can immediately receive data, it determines that the current response phase of the master device is the segment end response phase SEGMENT_END_RESP and responds to the slave device. The master device can continue to transmit the response request data to the upper-level module (for example, an RTL model or a TLM model). The process returns to step b1. Otherwise, if the master device cannot immediately receive data, the process goes to step b3.

[0136] Step b3: If the master device receives a response that is not the last one and cannot receive data immediately, it determines that the current response phase of the master device is the segment acknowledgment phase SEGMENT_ACK_RESP and responds to the slave device. At this time, both the master device and the slave device are blocked until the master device can receive data. Then, it determines that the current response phase of the master device is the segment end response phase SEGMENT_END_RESP and responds to the slave device; then go to step b4;

[0137] Step b4: If the master device receives the last response and can immediately receive data, it determines that the current request phase of the master device is the transaction end response phase END_RESP and responds to the slave device. The master device can continue to transmit the response request data to the upper-level module (for example, an RTL model or a TLM model). The response phase is completed. Otherwise, if the master device cannot immediately receive data, go to step b5.

[0138] Step b5: When the master device receives the last request and cannot receive data immediately, the master device sets the current response phase of the master device to the transaction acknowledgement phase ACK_RESP and responds to the slave device. At this time, both the slave device and the master device are blocked until the master device can receive data. The current request phase of the master device is set to the transaction end response phase END_RESP and responds to the slave device. The response phase execution ends.

[0139] Figure 7Another example of the transaction processing method based on the hybrid simulation platform of the present invention is shown. At time t0', the slave device initiates the first data of a response to the master device (a total of four data items need to be sent in this response). When sending, the current response phase of the slave device is the fragment start response phase, and the phase is fragment start response ⑦. After the master device receives the first data, the master device is not under back pressure and can receive it immediately. The master device then sets the current response phase to the fragment end response phase and the phase to fragment end response 9, and immediately sends a response to the slave device. Then, the master device begins to receive response data 0. After receiving the response data, the master device forwards it to the upper-level module (which can be a TLM model or an RTL model).

[0140] At time t1`, the slave device initiates a second response to the master device. When sending, the slave device's current response phase is the fragment end response phase, and the phase is fragment start response ⑦. After receiving the second data, the master device cannot receive it immediately, which causes back pressure (perhaps the master device is processing other processes; or the internal response buffer is full, etc.). The master device's current response phase is the fragment acknowledge response phase, and the phase is fragment acknowledge response ⑧. It immediately sends a response to the slave device. At this point, both the master and the slave device are blocked.

[0141] At time t2, the master device is awakened from the blocked state and can receive data (perhaps because the master device has finished processing other processes or there is space in the internal response buffer). The master device's current response phase is the fragment end response phase, and the fragment end response phase is 9. It immediately sends a response to the slave device and then begins to receive response data 1. After receiving the response data, the master device forwards it to the upper-level module (which can be a TLM model or RTL model).

[0142] At time t3`, the slave device initiates a response of the third piece of data to the master device. When sending, the slave device sets the phase of the current response stage to Slice Start Response ⑦. After the master device receives the third piece of data, if there is no back pressure on the current master device and it can receive it immediately, the master device sets the current response stage to Slice End Response stage and the phase to Slice End Response ⑨, and immediately sends a response to the slave device. It then starts to receive response data 3. After receiving the data, the master device can forward it to the upper-level module (which can be a TLM model or RTL model).

[0143] At time t4`, the slave device initiates a response of the fourth data (also the last data of the current response) to the master device. When sending, the current response phase of the slave device is the transaction start response phase, and the phase is transaction start response ⑩. After receiving the fourth data, the master device cannot receive it immediately, which may cause back pressure (the master device may be processing other processes; or the internal response buffer is full, etc.). The master device sets the current response phase to the transaction acknowledge response phase and the phase to transaction acknowledge response ⑪, and immediately sends a response to the slave device. At this time, both the master device and the slave device are blocked;

[0144] At time t5, the master device is awakened from its blocked state and can receive data (perhaps because it has finished processing other processes or has free space in its internal response buffer). The master device is in the transaction end response phase, with phase 10, and immediately sends a response to the slave device. It then begins receiving response data 3.

[0145] At time t6', the master device receives the response data 3; after receiving the response data 3, the master device can forward it to the upper-level module (which can be a TLM model or an RTL model); the entire response phase processing is completed.

[0146] In summary, the transaction processing method based on the hybrid simulation platform provided by the present invention can efficiently support transaction-level processing between the master device and the slave device, ensuring the accuracy of data processing and the efficiency of processing. By introducing the response fragment identifier and the start response message of the transaction-level processing, the transaction-level request is transmitted and processed in the form of a word stream or a byte stream, ensuring the bandwidth utilization of the platform communication. When the bandwidth configurations at both ends of the transaction-level processing module are different (including different bus bit widths or different clocks), the phase phase transmitted in the TLM interface responds to the back pressure of the path, thereby supporting communication behaviors when the master device sends requests quickly and the slave device receives requests slowly, or when the slave device sends responses quickly and the master device receives responses slowly. Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0147] Figure 8 FIG1 shows a schematic diagram of a transaction processing device based on a hybrid simulation platform according to an embodiment of the present invention. Figure 8 As shown, the device includes:

[0148] The transaction request receiving module 810 is configured to receive a transaction-level request initiated by an upper-level module through a master device, and obtain a request fragment identifier and corresponding request fragment content of the transaction-level request;

[0149] A request message sending module 820 is configured to send a corresponding transaction-level start request message to the slave device based on the request fragment identifier;

[0150] The end request response module 830 is used to obtain a response to the transaction end request fed back by the slave device based on the transaction-level start request message;

[0151] The transaction request processing module 840 is used to send the request fragment content corresponding to the request fragment identifier to the slave device based on the response to the transaction end request, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module.

[0152] In an optional implementation, the request message sending module 820 includes:

[0153] A fragment start request determination submodule is configured to determine that the current request phase of the master device is a fragment start request phase if the request fragment identifier indicates that the request fragment content required to be sent for the transaction-level request is multiple fragments, and the request fragment content currently being sent is not the last fragment;

[0154] The fragment start request message sending submodule is used to send the corresponding fragment start request message to the slave device based on the current request stage of the master device. The transaction-level start request message includes the fragment start request message.

[0155] In an optional implementation, the request message sending module 820 further includes:

[0156] A transaction start request determination submodule is configured to determine that the current request phase of the master device is a transaction start request phase if the request slice identifier indicates that the request slice content required to be sent for the transaction-level request is one slice, or that the request slice content required to be sent is multiple slices but the request slice content currently being sent is the last slice;

[0157] The transaction start request message sending submodule is used to send a transaction start request to the slave device based on the current request stage of the master device. The transaction-level start request message includes a transaction start request message.

[0158] In an optional implementation, the end request response module 830 includes:

[0159] A fragment response request determination submodule is configured to determine, if the slave device cannot immediately receive the request fragment content corresponding to the request fragment identifier, that the current request phase of the slave device is the fragment response request phase, and generate a fragment response request message for the transaction-level start request message based on the current request phase of the slave device, wherein the response to the transaction end request includes the fragment response request message;

[0160] The fragment end request determination submodule is used to determine that the current request stage of the slave device is the fragment end request stage if the slave device can immediately receive the request fragment content corresponding to the request fragment identifier, and generate a fragment end request message for the transaction-level start request message based on the current request stage of the slave device. The response to the transaction end request includes the fragment end request message.

[0161] In an optional implementation, the end request response module 830 includes:

[0162] a transaction response request determination submodule, configured to determine that the current request phase of the slave device is a transaction response request phase if the slave device cannot immediately receive the request fragment content corresponding to the request fragment identifier, and generate a transaction response request message for the transaction-level start request message based on the current request phase of the slave device, wherein the response to the transaction end request includes the transaction response request message;

[0163] The transaction end request determination submodule is used to determine that the current request stage of the slave device is the transaction end stage if the slave device can immediately receive the request fragment content corresponding to the request fragment identifier, and generate a transaction end request message for the transaction-level start request message based on the current request stage of the slave device. The response to the transaction end request includes the transaction end request message.

[0164] In an optional embodiment, the transaction request processing module 840 is specifically used to send the request fragment content corresponding to the request fragment identifier to the slave device after receiving the fragment end request message fed back by the slave device for the transaction-level start request message if the response to the transaction end request is a fragment response request message, so that the slave device forwards the received request fragment content to the corresponding lower-level module, and ends the transaction-level request initiated by the upper-level module after receiving the transaction end request message fed back by the slave device for the transaction-level start request message.

[0165] In an optional embodiment, the above device further includes:

[0166] The transaction response receiving module 850 is further configured to receive a transaction-level response initiated by a lower-level module for a transaction-level request from a slave device, and obtain a response fragment identifier and corresponding response fragment content of the transaction-level response;

[0167] The response message sending module 860 is further configured to send a corresponding transaction-level start response message to the master device based on the response fragment identifier;

[0168] The end response answering module 870 is further configured to obtain a transaction end response answer fed back by the master device based on the transaction-level start response message;

[0169] The transaction response processing module 880 is also used to send the response fragment content corresponding to the response fragment identifier to the main device based on the response of the transaction end response, so that the main device forwards the received response fragment content to the corresponding upper module and ends the transaction-level response initiated by the lower module.

[0170] In an optional implementation, the response message sending module 860 includes:

[0171] The fragment start response determination submodule is used to determine that the current response phase of the slave device is the fragment start response phase if the response fragment identifier indicates that the response fragment content required to be sent for the transaction-level response is multiple fragments and the response fragment content currently being sent is not the last fragment;

[0172] The fragment start response message sending submodule is used to send the corresponding fragment start response message to the master device based on the current response stage of the slave device. The transaction level start response message includes the fragment start response message.

[0173] In an optional implementation, the response message sending module 860 further includes:

[0174] The transaction start response determination submodule is used to determine that the current response phase of the slave device is the transaction start response phase if the response fragment identifier indicates that the content of the response fragment required to be sent for the transaction-level response is one fragment, or that the content of the response fragment required to be sent is multiple fragments but the content of the response fragment currently being sent is the last fragment;

[0175] The transaction-level start response message sending submodule is used to send a corresponding transaction-level start response message to the master device based on the current response phase of the slave device. The transaction-level start response message includes a transaction-level start response message.

[0176] In an optional implementation, the end response answering module 870 includes:

[0177] A fragment acknowledgment response determination submodule, configured to determine that the current response phase of the master device is a fragment acknowledgment response phase if the master device cannot immediately receive the response fragment content corresponding to the response fragment identifier, and generate a fragment acknowledgment response message for the transaction-level start response message based on the current request phase of the master device, wherein the response to the transaction end response includes the fragment acknowledgment response message;

[0178] The fragment end response determination submodule is used to determine that the current response stage of the master device is the fragment end response stage if the slave device can immediately receive the response fragment content corresponding to the response fragment identifier, and generate a fragment end response message for the transaction-level start response message based on the current response stage of the master device. The response to the transaction end response includes the fragment end response message.

[0179] In an optional implementation, the end response answering module 870 further includes:

[0180] a transaction acknowledgement response determination submodule, configured to determine that the current response phase of the master device is a transaction acknowledgement response phase if the master device cannot immediately receive the response fragment identifier and the corresponding response fragment content, and generate a transaction acknowledgement response message for the transaction-level start response message based on the current request phase of the master device, wherein the response to the transaction end response includes a transaction acknowledgement response message;

[0181] The transaction end response determination submodule is used to determine that the current request stage of the master device is the transaction end response stage if the master device can immediately receive the response fragment identifier and the corresponding response fragment content, and generate a transaction end response message for the transaction-level start response message based on the current request stage of the master device. The reply to the transaction end response includes the transaction end response message.

[0182] In an optional embodiment, the transaction response processing module 880 is specifically used to send the response fragment content corresponding to the response fragment identifier to the master device after receiving the fragment end response message fed back by the master device for the transaction level start response message if the response to the transaction end request is a fragment response message, so that the master device forwards the received response fragment content to the corresponding upper module, and ends the transaction level response initiated by the lower module after receiving the transaction end response message fed back by the master device for the transaction level start response message.

[0183] For the description of the features in the embodiments corresponding to the transaction processing device based on the hybrid simulation platform, please refer to the relevant description of the embodiments corresponding to the transaction processing method based on the hybrid simulation platform, which will not be repeated here.

[0184] The embodiment of the present application also provides an electronic device, such as Figure 9 As shown, it includes a memory 910 and a processor 920, wherein the memory 910 stores a computer program, and the processor 920 is configured to run the computer program to execute the steps in any of the above-mentioned transaction processing method embodiments based on the hybrid simulation platform.

[0185] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned transaction processing method embodiments based on the hybrid simulation platform when running.

[0186] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0187] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned transaction processing method embodiments based on the hybrid simulation platform are implemented.

[0188] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps in any of the above-mentioned transaction processing method embodiments based on a hybrid simulation platform.

[0189] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0190] The transaction processing method, device, equipment and product based on a hybrid simulation platform provided by the present application are introduced in detail above. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A transaction processing method based on a hybrid simulation platform, characterized in that: Applied to a transaction-level processing module, the transaction-level processing module includes a master device and a slave device, including: Receiving, through the master device, a transaction-level request initiated by an upper-level module, and obtaining a request fragment identifier and corresponding request fragment content of the transaction-level request; Sending a corresponding transaction-level start request message to the slave device based on the request fragment identifier; Obtaining a response to a transaction end request fed back by the slave device based on the transaction-level start request message; Based on the response to the transaction end request, sending the request fragment content corresponding to the request fragment identifier to the slave device, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module; The sending a transaction-level start request message to the slave device based on the request fragment identifier includes: If the request fragment identifier indicates that the transaction-level request needs to send multiple request fragments, and the request fragment currently being sent is not the last fragment, determining that the current request phase of the master device is a fragment start request phase; Sending a corresponding slice start request message to the slave device based on the current request phase of the master device, the transaction-level start request message including the slice start request message; The obtaining a response to the transaction end request fed back by the slave device based on the transaction-level start request message includes: If the slave device cannot immediately receive the request fragment content corresponding to the request fragment identifier, determining that the current request stage of the slave device is a fragment response request stage, and generating a fragment response request message for the transaction-level start request message based on the current request stage of the slave device, wherein the response to the transaction end request includes the fragment response request message; If the slave device can immediately receive the request fragment content corresponding to the request fragment identifier, it is determined that the current request stage of the slave device is the fragment end request stage, and a fragment end request message is generated for the transaction-level start request message based on the current request stage of the slave device. The response to the transaction end request includes the fragment end request message.

2. The method according to claim 1, characterized in that The sending of a transaction-level start request message to the slave device based on the request fragment identifier further includes: If the request slice identifier indicates that the request slice content required to be sent for the transaction-level request is one slice, or that the request slice content required to be sent is multiple slices but the request slice content currently being sent is the last slice, determining that the current request phase of the master device is a transaction start request phase; A transaction start request is sent to the slave device based on a current request phase of the master device, wherein the transaction-level start request message includes the transaction start request message.

3. The method according to claim 2, characterized in that The obtaining a response to the transaction end request fed back by the slave device based on the transaction-level start request message includes: If the slave device cannot immediately receive the request fragment content corresponding to the request fragment identifier, determining that the current request stage of the slave device is a transaction response request stage, and generating a transaction response request message for the transaction-level start request message based on the current request stage of the slave device, wherein the response to the transaction end request includes the transaction response request message; If the slave device can immediately receive the request fragment content corresponding to the request fragment identifier, it is determined that the current request stage of the slave device is the transaction end request stage, and a transaction end request message is generated for the transaction-level start request message based on the current request stage of the slave device, and the response to the transaction end request includes the transaction end request message.

4. The method according to claim 1, wherein The step of sending, based on the response to the transaction end request, the request fragment content corresponding to the request fragment identifier to the slave device, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module, including: If the response to the transaction end request is the slice response request message, then after receiving the slice end request message fed back by the slave device in response to the transaction level start request message, the request slice content corresponding to the request slice identifier is sent to the slave device, so that the slave device forwards the received request slice content to the corresponding lower-level module, and after receiving the transaction end request message fed back by the slave device in response to the transaction level start request message, the transaction-level request initiated by the upper-level module is ended.

5. The method according to claim 1, wherein The method further comprises: Receiving, by the slave device, a transaction-level response initiated by a lower-level module in response to the transaction-level request, and obtaining a response fragment identifier and corresponding response fragment content of the transaction-level response; Sending a corresponding transaction-level start response message to the master device based on the response fragment identifier; Obtaining a response of a transaction end response fed back by the master device based on the transaction-level start response message; Based on the response to the transaction end response, the response fragment content corresponding to the response fragment identifier is sent to the main device, so that the main device forwards the received response fragment content to the corresponding upper module and ends the transaction-level response initiated by the lower module.

6. The method according to claim 5, characterized in that The sending a corresponding transaction-level start response message to the master device based on the response fragment identifier includes: If the response fragment identifier indicates that the response fragment content required to be sent for the transaction-level response is multiple fragments, and the response fragment content currently being sent is not the last fragment, determining that the current response phase of the slave device is a fragment start response phase; Based on the current response phase of the slave device, a corresponding fragment start response message is sent to the master device, where the transaction-level start response message includes the fragment start response message.

7. The method according to claim 5, characterized in that The sending of a corresponding transaction-level start response message to the master device based on the response fragment identifier further includes: If the response fragment identifier indicates that the content of the response fragment required to be sent for the transaction-level response is one fragment, or that the content of the response fragment required to be sent is multiple fragments but the content of the response fragment currently being sent is the last fragment, determining that the current response phase of the slave device is the transaction start response phase; A corresponding transaction level start response message is sent to the master device based on the current response phase of the slave device, wherein the transaction level start response message includes the transaction level start response message.

8. The method according to claim 6, characterized in that The obtaining of a response of a transaction end response fed back by the master device based on the transaction-level start response message includes: If the master device cannot immediately receive the response fragment content corresponding to the response fragment identifier, determining that the current response phase of the master device is the fragment acknowledgment response phase, and generating a fragment acknowledgment response message for the transaction-level start response message based on the current request phase of the master device, wherein the response of the transaction end response includes the fragment acknowledgment response message; If the slave device can immediately receive the response fragment content corresponding to the response fragment identifier, it is determined that the current response stage of the master device is the fragment end response stage, and a fragment end response message is generated for the transaction-level start response message based on the current response stage of the master device. The response to the transaction end response includes the fragment end response message.

9. The method according to claim 7, characterized in that The step of obtaining a response of a transaction end response fed back by the master device based on the transaction-level start response message further includes: If the master device cannot immediately receive the response fragment identifier and the corresponding response fragment content, determining that the current response phase of the master device is a transaction acknowledgement response phase, and generating a transaction acknowledgement response message for the transaction-level start response message based on the current request phase of the master device, wherein the response of the transaction end response includes the transaction acknowledgement response message; If the master device can immediately receive the response fragment identifier and the corresponding response fragment content, it is determined that the current request stage of the master device is the transaction end response stage, and a transaction end response message is generated for the transaction-level start response message based on the current request stage of the master device. The reply to the transaction end response includes the transaction end response message.

10. The method according to claim 8, characterized in that The response based on the transaction end response, sending the response fragment content corresponding to the response fragment identifier to the master device, so that the master device forwards the received response fragment content to the corresponding upper-level module and ends the transaction-level response initiated by the lower-level module, including: If the response to the transaction end request is the fragment response message, then after receiving the fragment end response message fed back by the master device in response to the transaction level start response message, the response fragment content corresponding to the response fragment identifier is sent to the master device, so that the master device forwards the received response fragment content to the corresponding upper module, and after receiving the transaction end response message fed back by the master device in response to the transaction level start response message, the transaction level response initiated by the lower module is ended.

11. A transaction processing device based on a hybrid simulation platform, characterized in that: include: A transaction request receiving module, configured to receive a transaction-level request initiated by an upper-level module through a master device, and obtain a request fragment identifier and corresponding request fragment content of the transaction-level request; a request message sending module, configured to send a corresponding transaction-level start request message to the slave device based on the request fragment identifier, including determining that the current request phase of the master device is a fragment start request phase if the request fragment identifier indicates that the request fragment content required to be sent for the transaction-level request is multiple fragments and the request fragment content currently being sent is not the last fragment; Sending a corresponding slice start request message to the slave device based on the current request phase of the master device, the transaction-level start request message including the slice start request message; an end request response module, configured to obtain a response to the transaction end request fed back by the slave device based on the transaction-level start request message, including determining, if the slave device cannot immediately receive the request fragment content corresponding to the request fragment identifier, that the current request stage of the slave device is a fragment reply request stage, and generating, based on the current request stage of the slave device, a fragment reply request message for the transaction-level start request message, wherein the response to the transaction end request includes the fragment reply request message; If the slave device can immediately receive the request fragment content corresponding to the request fragment identifier, determining that the current request stage of the slave device is a fragment end request stage, generating a fragment end request message for the transaction-level start request message based on the current request stage of the slave device, and the response to the transaction end request includes the fragment end request message; A transaction request processing module is used to send the request fragment content corresponding to the request fragment identifier to the slave device based on the response to the transaction end request, so that the slave device forwards the received request fragment content to the corresponding lower-level module and ends the transaction-level request initiated by the upper-level module.

12. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the transaction processing method based on the hybrid simulation platform as claimed in any one of claims 1 to 10 when executing the computer program.

13. A computer program product, characterized in that The method comprises computer instructions for causing a computer to execute the steps of the transaction processing method based on the hybrid simulation platform according to any one of claims 1 to 10.

Images