A transaction processing method, apparatus, device, and storage medium

Abstract

The application discloses a transaction processing method and device, equipment and storage medium, and relates to the technical field of computers, which comprises the following steps: receiving a current request transaction sent by an initiator, and judging whether a transaction storage queue reaches a limit value; if the transaction storage queue does not reach the limit value, storing the current request transaction to the transaction storage queue, and triggering a request response event; reading a target request transaction from the transaction storage queue, and performing a preset request transaction forwarding operation to forward the target request transaction to a target end. The application adds a transaction storage queue and a response process in a simulation kernel, determines the execution of each process and determines the next operation according to the execution, guarantees that multiple phases can be supported in communication, subdivides each stage of communication, improves the concurrent processing capability when multiple transactions are concurrent, and makes the performance modeling and evaluation more accurate.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a transaction processing method, apparatus, device, and storage medium. Background Technology

[0002] In terms of hardware, requests from the Initiator can be sent continuously until they are pushed back by the processing capacity of the receiver. Therefore, transmission delays can cause the port bandwidth and other characteristics of the Target to not reach their maximum processing capacity, resulting in a decrease in the processing performance of both the receiver and the sender. This leads to inaccurate simulation of the performance model. Furthermore, traditional methods require modification of the Initiator's processing flow, changing the four phases specified by the protocol to three phases, which reduces compatibility with other general models that conform to the protocol. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a transaction processing method, apparatus, device, and storage medium that can improve compatibility, enhance concurrent processing capabilities in the event of multiple concurrent transactions, and make performance modeling and evaluation more accurate. The specific solution is as follows:

[0004] In a first aspect, this application discloses a transaction processing method applied to a simulation kernel, comprising:

[0005] Receive the current request transaction sent by the initiator and determine whether the transaction storage queue has reached its limit.

[0006] If the transaction storage queue has not reached the limit value, the current request transaction is stored in the transaction storage queue, and a request response event is triggered.

[0007] The target request transaction is read from the transaction storage queue, and a preset request transaction forwarding operation is executed to forward the target request transaction to the target end.

[0008] Optionally, after receiving the current request transaction sent by the initiating end, the process further includes:

[0009] Determine whether the current request transaction was sent from the non-blocking communication port of the initiating end;

[0010] If the current request transaction is a transaction sent from the non-blocking communication port of the initiating end, then determine whether the port communication type of the target end is a blocking communication type;

[0011] If the port communication type of the target terminal is the blocking communication type, then the current communication type is determined to be a mixed communication type;

[0012] Accordingly, determining whether the transaction storage queue has reached its limit includes:

[0013] When the current communication type is the mixed communication type, determine whether the transaction storage queue has reached the limit value.

[0014] Optionally, after determining whether the transaction storage queue has reached its limit, the method further includes:

[0015] If the transaction storage queue has reached the limit value, then the current request transaction sent through the non-blocking communication port of the initiating end is blocked;

[0016] After waiting for a preset clock cycle, the process re-enters the step of determining whether the transaction storage queue has reached its limit.

[0017] Optionally, the triggering of the request-response event includes:

[0018] Obtain the current request transaction and initial transmission phase sent by the initiating end;

[0019] Trigger the current request response event corresponding to the current request transaction;

[0020] A first current transmission phase is set, and the first current transmission phase is sent to the initiating end through the reverse interface, so that the initiating end can send a new current request transaction to the simulation kernel after receiving the first current transmission phase.

[0021] Optionally, the step of storing the current request transaction in the transaction storage queue if the transaction storage queue has not reached the limit value includes:

[0022] If the transaction storage queue has not reached the limit value, the current request transaction is stored at the tail of the transaction storage queue.

[0023] Optionally, the step of performing a preset request transaction forwarding operation to forward the target request transaction to the target end includes:

[0024] The target request transaction is forwarded to the blocking communication port of the target end, and then blocked and waited.

[0025] The blocking stops when the target terminal returns status information indicating that the target requested transaction has been completed.

[0026] Set a second current transmission phase and send the second current transmission phase to the initiating end through the reverse interface.

[0027] Optionally, before reading the target request transaction from the transaction storage queue, the method further includes:

[0028] Determine whether this is the first time the preset request transaction forwarding operation has been executed;

[0029] If this is the first time the preset request transaction forwarding operation is executed, it is determined that there is currently no preset request transaction forwarding operation being executed.

[0030] If this is not the first time the preset request transaction forwarding operation has been executed, then determine whether the status information of the previous preset request transaction forwarding operation returned by the target end has been received;

[0031] If the status information of the previous preset request transaction forwarding operation has been received, it is determined that there is currently no preset request transaction forwarding operation being executed.

[0032] If the status information of the previous preset request transaction forwarding operation is not received, it is determined that there is currently a preset request transaction forwarding operation being executed.

[0033] If there is currently an ongoing preset request transaction forwarding operation, then block and wait;

[0034] Accordingly, reading the target request transaction from the transaction storage queue includes:

[0035] If there is no currently executing preset request transaction forwarding operation, the target request transaction is read from the head of the transaction storage queue.

[0036] Secondly, this application discloses a transaction processing apparatus applied to an emulation kernel, comprising:

[0037] The transaction receiving module is used to receive the current request transaction sent by the initiating end;

[0038] The queue judgment module is used to determine whether the transaction storage queue has reached its limit.

[0039] A transaction storage module is used to store the current request transaction in the transaction storage queue if the transaction storage queue has not reached the limit value.

[0040] The event triggering module is used to trigger request and response events;

[0041] The request transaction forwarding module is used to read the target request transaction from the transaction storage queue and execute a preset request transaction forwarding operation to forward the target request transaction to the target end.

[0042] Thirdly, this application discloses an electronic device, including:

[0043] Memory, used to store computer programs;

[0044] A processor for executing the computer program to implement the steps of the transaction processing method disclosed above.

[0045] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the transaction processing method disclosed above.

[0046] As can be seen, this application provides a transaction processing method, including: receiving a current request transaction sent by the initiating end, and determining whether the transaction storage queue has reached its limit; if the transaction storage queue has not reached the limit, storing the current request transaction in the transaction storage queue and triggering a request-response event; reading a target request transaction from the transaction storage queue, and executing a preset request transaction forwarding operation to forward the target request transaction to the target end. Therefore, this application, by adding a transaction storage queue and a response process to the simulation kernel, determines the execution status of each process and determines the next operation based on the execution status, while ensuring that multiple phases can be supported in communication, and subdividing each stage of communication, improves concurrent processing capabilities when multiple transactions are concurrent, making performance modeling and evaluation more accurate, and improving compatibility. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0048] Figure 1 This is a flowchart of a transaction processing method disclosed in this application;

[0049] Figure 2 This is a schematic diagram of a specific transaction processing method disclosed in this application;

[0050] Figure 3 This is a schematic diagram of a transaction processing method that uses a blocking communication method as disclosed in this application.

[0051] Figure 4 This is a schematic diagram of a transaction processing method that uses a non-blocking communication method, as disclosed in this application.

[0052] Figure 5 This is a schematic diagram of transaction processing when the simulation kernel disclosed in this application is not optimized;

[0053] Figure 6 This is a flowchart of a specific transaction processing method disclosed in this application;

[0054] Figure 7 This is a flowchart of a specific transaction processing method disclosed in this application;

[0055] Figure 8 This is a schematic diagram illustrating the division of the delay phases disclosed in this application;

[0056] Figure 9 This is a schematic diagram illustrating the execution delay of the two events disclosed in this application;

[0057] Figure 10 This is a schematic diagram illustrating the execution delay of each request during concurrent multi-request scenarios disclosed in this application.

[0058] Figure 11 A schematic diagram of the transaction processing device provided in this application;

[0059] Figure 12 This application provides a structural diagram of an electronic device. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] Currently, hardware-initiated requests can be continuously sent until they are counter-pressured by the receiving end's processing capacity. Transmission latency can cause the target end's port bandwidth and other characteristics to fall below maximum processing capacity, thus lowering the processing performance of both the receiving and sending ends. This results in inaccurate performance model simulations. Furthermore, traditional methods require modification of the initiating end's processing flow, changing the protocol's four phases to three phases, leading to decreased compatibility with other protocol-compliant general models. Therefore, this application provides a transaction processing method that can improve concurrent processing capabilities when multiple transactions are running concurrently, making performance modeling and evaluation more accurate.

[0062] This invention discloses a transaction processing method, see [link to relevant documentation]. Figure 1 As shown, applied to the simulation kernel, the method includes:

[0063] Step S11: Receive the current request transaction sent by the initiator and determine whether the transaction storage queue has reached its limit.

[0064] In this embodiment, the current request transaction sent by the initiating end is received, and it is determined whether the transaction storage queue has reached its limit. Specifically, the current request transaction and initial transmission phase sent by the initiating end are obtained; a current request response event corresponding to the current request transaction is triggered; a first current transmission phase (such as END REQ) is set, and the first current transmission phase is sent to the initiating end through the reverse interface, so that the initiating end sends a new current request transaction to the simulation kernel after receiving the first current transmission phase. It can be understood that, as Figure 2 As shown, the response process for the design request inside the SystemC simulation kernel, denoted as end_req_process_thread(), is triggered by the req_resp_event. Then, it sets the current transmission phase to END REQ and transmits the response to the Initiator through the reverse interface.

[0065] Step S12: If the transaction storage queue has not reached the limit value, the current request transaction is stored in the transaction storage queue, and a request response event is triggered.

[0066] In this embodiment, after receiving the current request transaction sent by the initiator and determining whether the transaction storage queue has reached its limit, if the transaction storage queue has not reached its limit, the current request transaction is stored in the transaction storage queue. If the transaction storage queue has not reached its limit, the current request transaction is stored at the tail of the transaction storage queue. It is understood that after determining whether the transaction storage queue has reached its limit, if the transaction storage queue has reached its limit, the current request transaction sent through the non-blocking communication port of the initiator is blocked; after waiting for a preset clock cycle, the step of determining whether the transaction storage queue has reached its limit is re-entered. It is understood that when the transaction storage queue nb_trans_queue is full, the request service from the initiator to the non-blocking communication port is blocked, and the process waits; when the transaction storage queue nb_trans_queue is not full, the transaction is stored in the transaction storage queue, and a request response event, denoted as req_resp_event, is triggered; simultaneously, a dynamic process is automatically generated to handle the request forwarding operation.

[0067] Step S13: Read the target request transaction from the transaction storage queue and execute a preset request transaction forwarding operation to forward the target request transaction to the target end.

[0068] In this embodiment, after storing the current request transaction in the transaction storage queue, the target request transaction is read from the transaction storage queue, and a preset request transaction forwarding operation is executed to forward the target request transaction to the target end. Specifically, the target request transaction is forwarded to the blocking communication port of the target end and blocked while waiting; when the target end returns status information indicating that the target request transaction has been completed, the blocking stops; a second current transmission phase (such as END RESP) is set, and the second current transmission phase is sent to the initiating end through the reverse interface.

[0069] Understandably, the SystemC emulation kernel internally designs a request forwarding process. This process reads the pending transactions in nb_trans_queue, then forwards the request event to the blocking communication port of the Target, and blocks and waits for the port to complete its execution and return a status. After blocking and waiting for the return status of the Target port, it sets the current transmission phase to BEGIN_RESP and transmits the response to the Initiator through the reverse interface.

[0070] System-on-a-Chip (SoC) is complex, which has given rise to SystemC and Electronic System Level (ESL) methodologies. Transaction Level Modeling (TLM) is crucial for ESL. For complex SoCs, in-depth system-level simulation is required before RTL (Registry Transfer Level) design to confirm the appropriateness of the architecture, the bus's ability to meet throughput and real-time requirements, and the avoidance of memory waste. To shorten the design cycle of critical SoC IPs and assist the design process, and to bridge the gap between system architecture design and hardware RTL circuit implementation, an ESL (Electronic System Level) modeling methodology is adopted to describe the functionality and architecture of the entire circuit system without getting bogged down in the complex signal timing and gate circuits of the hardware. The ESL methodology describes the system at an appropriate level of abstraction, constructs a virtual hardware prototype platform, explores the hardware architecture, and develops software programs, enabling rapid system modeling and simulation analysis. The core of ESL is TLM.

[0071] With the increasing computational complexity of future communication terminals and devices, the demand for integrated, large-scale real-time system-on-a-chip (SoC) architectures will grow rapidly. A single chip may integrate dozens or even hundreds or thousands of processing units, making multi-core signal processing platforms a development trend for software-defined radio. In such integrated systems, designing reliable, high-speed, and low-power high-performance on-chip communication architectures presents both a challenge and an opportunity for SoC development. Key performance indicators for memory-based systems include response latency, throughput, maximum concurrent connections, and system reliability. Therefore, quickly and accurately building performance models and quantitatively evaluating and analyzing the performance indicators of the architecture design is crucial.

[0072] In the process of building performance models, the most widely used approach is to build transaction-level models. Transaction-level models have a higher level of abstraction than RTL models, allowing for the rapid establishment of executable hardware specifications and the quick creation of system models based on the initial functional specifications of the system. By incorporating timing details, system performance can be evaluated, and system structure can be explored. Transaction-level models offer faster modeling and more efficient simulation. Generally, the communication method between the transaction initiator (Initiator) and the transaction receiver (Target) in a transaction-level model is consistent, such as... Figure 3 As shown, both the transaction initiator and the transaction receiver use blocking communication methods, or as... Figure 4 As shown, both the transaction initiator and the transaction receiver use non-blocking communication. Blocking communication uses b_transport, and the transaction transmission only has a start and an end. Non-blocking communication uses nb_transport_fw and nb_transport_bw, and the communication process generally includes four phases according to the protocol: BEGIN_REQ, END_REQ, BEGIN_RESP, and END_RESP.

[0073] If the communication types between the Initiator and Target are inconsistent, there are two scenarios: the Initiator uses blocking communication and the Target uses non-blocking communication; or the Initiator uses non-blocking communication and the Target uses blocking communication. This invention uses the example of the Initiator using non-blocking communication and the Target using blocking communication for specific details. Before the simulation kernel is optimized, such as... Figure 5As shown, when the Initiator communicates in non-blocking mode and the Target communicates in blocking mode, the Initiator sets the current phase to BEGIN_REQ and sends a transaction. When the SystemC simulation kernel receives this transaction and checks that the Target's port type is currently blocking, it sends the transaction to the blocking target port. After receiving a completion return status from that port, the kernel configures the current phase to BEGIN_RESP and sends it back to the Initiator. Upon receiving the BEGIN_RESP phase, the Initiator processes it internally and then sends END_RESP, ending the current transaction communication. In this communication mode, the Initiator sends and receives a total of BEGIN_REQ, BEGIN_RESP, and END_RESP phases; the Initiator does not receive the END_REQ phase. Traditional methods for handling this situation typically modify the Initiator's processing flow: the Initiator is modified to only send the next BEGIN_REQ when it receives either ENG_REQ or BEGIN_RESP. This method ensures that the Initiator does not freeze and communication proceeds normally. However, this method has the following problems: Hardware-wise, requests from the Initiator should be continuously sent until they are pushed back by the receiving end's processing capacity. Furthermore, the transmission delays in the BEGIN_REQ and BEGINRESP phases can cause the Target end's port bandwidth and other characteristics to fall below maximum processing capacity, thus lowering the processing performance of both the receiving and sending ends. This results in inaccurate simulation of the performance model. Additionally, using this traditional method requires modifying the Initiator's processing flow, changing the protocol's four phases to three, which reduces compatibility with other protocol-compliant general models.

[0074] This invention optimizes the handling of inconsistent communication methods at both ends, solving the problems existing in the traditional methods. This invention mainly applies to the modeling field of the architecture design stage of chip design. After the architecture is clearly defined, transaction-level chip modeling and simulation are performed, so that the simulation of chip hardware behavior can be completed as soon as possible before RTL design. This allows for the evaluation of whether the system's functions or performance indicators meet the requirements, providing feedback and iteration on the chip architecture design, and ultimately increasing the likelihood that the chip design is functionally correct and meets the performance requirements.

[0075] As can be seen, this application provides a transaction processing method, including: receiving a current request transaction sent by the initiating end, and determining whether the transaction storage queue has reached its limit; if the transaction storage queue has not reached the limit, storing the current request transaction in the transaction storage queue and triggering a request-response event; reading a target request transaction from the transaction storage queue, and executing a preset request transaction forwarding operation to forward the target request transaction to the target end. Therefore, this application, by adding a transaction storage queue and a response process to the simulation kernel, determines the execution status of each process and determines the next operation based on the execution status, while ensuring that multiple phases can be supported in communication, and subdividing each stage of communication, improves concurrent processing capabilities when multiple transactions are concurrent, making performance modeling and evaluation more accurate, and improving compatibility.

[0076] See Figure 6 As shown, this embodiment of the invention discloses a transaction processing method. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution.

[0077] Step S21: Receive the current request transaction sent by the initiating end, and determine whether the current request transaction is a transaction sent from the non-blocking communication port of the initiating end.

[0078] In this embodiment, the system receives a current request transaction sent by the initiator and determines whether the current request transaction was sent from the non-blocking communication port of the initiator. It is understood that the optimization simulation is for a hybrid communication path where the transaction initiator uses non-blocking communication and the transaction target uses blocking communication.

[0079] Step S22: If the current request transaction is a transaction sent from the non-blocking communication port of the initiating end, then determine whether the port communication type of the target end is a blocking communication type.

[0080] In this embodiment, after determining whether the current request transaction was sent from the non-blocking communication port of the initiating end, if... Figure 7As shown, if the current request transaction is sent from the non-blocking communication port of the initiating end, it is determined whether the port communication type of the target end is a blocking communication type. If the port communication type of the target end is a blocking communication type, the current communication type is determined to be a mixed communication type. It can be understood that the SystemC simulation kernel internally stores a transaction storage queue from the non-blocking communication port, denoted as nb_trans_queue. When a request transaction is received from the initiator end from the non-blocking communication port, the port communication type of the target end is determined. If the target end's communication port is a blocking communication type, then the communication path is a mixed communication type.

[0081] Step S23: When the current communication type is the mixed communication type, determine whether the transaction storage queue has reached the limit value.

[0082] In this embodiment, after determining whether the port communication type of the target end is a blocking communication type, if the current communication type is the mixed communication type, it is determined whether the transaction storage queue has reached the limit value. If the transaction storage queue has not reached the limit value, the current request transaction is stored at the tail of the transaction storage queue. The depth of the transaction storage queue can be customized to store multiple transactions.

[0083] Step S24: Trigger the request-response event.

[0084] Step S25: Read the target request transaction from the transaction storage queue and execute a preset request transaction forwarding operation to forward the target request transaction to the target end.

[0085] In this embodiment, the target request transaction is read from the transaction storage queue, and a preset request transaction forwarding operation is performed to forward the target request transaction to the target end. Understandably, before reading the target request transaction from the transaction storage queue, it is determined whether this is the first time the preset request transaction forwarding operation has been executed. If it is the first time the preset request transaction forwarding operation has been executed, it is determined that there is currently no preset request transaction forwarding operation being executed. If it is not the first time the preset request transaction forwarding operation has been executed, it is determined whether the status information of the previous preset request transaction forwarding operation returned by the target end has been received. If the status information of the previous preset request transaction forwarding operation has been received, it is determined that there is currently no preset request transaction forwarding operation being executed. If the status information of the previous preset request transaction forwarding operation has not been received, it is determined that there is currently a preset request transaction forwarding operation being executed. If there is currently a preset request transaction forwarding operation being executed, it is blocked and waited. If there is currently no preset request transaction forwarding operation being executed, the target request transaction is read from the head of the transaction storage queue, and the preset request transaction forwarding operation is executed to forward the target request transaction to the target end.

[0086] The division of the delay phase is as follows: Figure 8 As shown, for example, the transmission delay of BEGIN_ERQ from the Initiator to the SystemC emulation kernel is denoted as latency1, the transmission delay of the event request from the SystemC emulation kernel to the Target is denoted as latency2, the transmission delay of the event response from the Target to the SystemC emulation kernel is denoted as latency3, the transmission delay of the END_REQ phase from the SystemC emulation kernel to the Initiator is denoted as latency5, and the transmission delay of the BEGIN_RESP phase from the SystemC emulation kernel to the Initiator is denoted as latency4.

[0087] Taking the transmission of two events as an example, the improved SystemC emulation kernel, when the Initiator configures the first request phase as BEGIN REQ, waits after sending the first request, and immediately sends the next request upon receiving the END REQ phase (i.e., as shown in the example). Figure 9As shown: the start time of latency 1 in trans(event) 1 is the end time of latency 5 in trans0. It can be understood that latency 1 and latency 5 in the diagram represent the response process. When the initiating end receives the END REQ phase, the latency is latency 5. At this time, the initiating end can immediately send the next request, entering the latency 1 of event 1. Latency 2, latency 3, and latency 4 in the diagram represent the forwarding process. When the initiating end receives latency 3, it can immediately enter the next forwarding process (the start time of latency 2 in trans1 is the end time of latency 3 in trans0). The forwarding process and the response process can execute concurrently without affecting each other. When multiple requests are concurrent, the execution latency of each request is as follows... Figure 10 As shown, before the improvement, event 1 could only proceed after all latency 1 to latency 4 of event 0 had been executed. After the improvement, event 1's latency 1 can proceed immediately after event 0's latency 2 has been executed, and event 1's latency 2 can proceed immediately after event 0's latency 3 has been executed. Compared to the previous execution flow, the concurrent processing capability of events has been significantly improved. The optimized SystemC simulation kernel supports mixed communication between non-blocking and blocking communication ports. The non-blocking communication module supports four phases: BEGIN_REQ, END_REQ, BEGIN_RESP, and END_RESP. The conditions for non-blocking communication module requests conform to the protocol, and the next request is sent only after receiving END_REQ, requiring no additional modification.

[0088] The optimized SystemC simulation kernel in this invention supports hybrid communication between non-blocking and blocking communication ports. The simulation kernel adds a transaction storage queue and response process for the non-blocking communication port, ensuring that the non-blocking communication module can support four phases: BEGIN_REQ, END_REQ, BEGIN_RESP, and END_RESP. Therefore, regardless of whether it communicates with other non-blocking or blocking communication modules, the internal processing flow of the non-blocking communication module does not need to be modified, resulting in better compatibility. The optimized SystemC simulation kernel further subdivides the latency of each stage of communication, improving concurrent processing capabilities and making performance modeling and evaluation more accurate when multiple transactions are running concurrently.

[0089] This invention optimizes the SystemC emulation kernel to support mixed communication scenarios by adding a transaction storage queue. Furthermore, it evaluates the memory buffer size of the transaction storage queue under different application scenarios and designs a transaction storage queue with the smallest memory buffer size while ensuring communication performance.

[0090] For details regarding step S24, please refer to the corresponding content disclosed in the foregoing embodiments, which will not be repeated here.

[0091] As can be seen, this embodiment of the application receives a current request transaction sent by the initiating end, determines whether the current request transaction is sent from the non-blocking communication port of the initiating end; if the current request transaction is sent from the non-blocking communication port of the initiating end, it determines whether the port communication type of the target end is a blocking communication type; when the current communication type is the mixed communication type, it determines whether the transaction storage queue has reached the limit value; triggers a request response event; reads the target request transaction from the transaction storage queue, and executes a preset request transaction forwarding operation to forward the target request transaction to the target end, thereby improving the concurrent processing capability when multiple transactions are concurrent, making performance modeling and evaluation more accurate, and improving compatibility.

[0092] In one specific implementation, as described above Figure 7As shown, for a hybrid communication path where the initiator (transaction initiator) uses non-blocking communication and the target (transaction target) uses blocking communication, the execution steps on the initiator side are as follows: the internal request sending process prepares the request event, configures the current transmission phase as BEGIN_REQ, and then sends the event to the simulation kernel through the forward port; only after receiving the END_REQ phase returned by the simulation kernel will the next request event be sent; the internal response processing process is triggered when it receives the BEGIN_RESP phase, configures the current phase as END_RESP, and then sends it through the forward port. The execution steps on the target side are as follows: the internal blocking port receives the request transaction, processes it, and then returns the execution status through the blocking port; and the above steps are executed in a blocking manner, only one request transaction can be processed at a time. The execution steps of the SystemC simulation kernel are as follows: Upon receiving a request transaction from the Initiator's non-blocking communication port, the Initiator queries the communication type of the Target's port. If it is not non-blocking, normal communication proceeds. If it is not blocking, the Initiator queries the transaction storage queue `nb_trans_queue`. If it is full, the Initiator blocks and waits. If it is not full, the Initiator stores the event in `nb_trans_queue`. When the `req_resp_event` event occurs, the SystemC simulation kernel's internal design request response process, denoted as `end_req_process_thread()`, is triggered by the `req_resp_event` event. Then, the Initiator sets the current transmission phase to END. The system executes a REQ and then transmits the response to the Initiator via the reverse interface. Simultaneously, a dynamic process is generated to handle the request forwarding operation. This process executes the request forwarding process designed within the SystemC simulation kernel. This process reads the pending transactions in nb_trans_queue and then forwards the request event to the blocking communication port of the Target. It then blocks and waits for the return status after the port completes its execution. Once the return status from the Target port is received, the current transmission phase is set to BEGIN_RESP, and the response is transmitted to the Initiator via the reverse interface.

[0093] See Figure 11 As shown in the illustration, this application also discloses a transaction processing apparatus applied to an emulation kernel, comprising:

[0094] The transaction receiving module 11 is used to receive the current request transaction sent by the initiating end;

[0095] Queue judgment module 12 is used to determine whether the transaction storage queue has reached its limit value;

[0096] The transaction storage module 13 is used to store the current request transaction in the transaction storage queue if the transaction storage queue has not reached the limit value.

[0097] Event triggering module 14 is used to trigger request-response events;

[0098] The request transaction forwarding module 15 is used to read the target request transaction from the transaction storage queue and execute a preset request transaction forwarding operation to forward the target request transaction to the target end.

[0099] As can be seen, this application includes: receiving a current request transaction sent by the initiating end and triggering a request response event; determining whether the transaction storage queue has reached its limit value; if the transaction storage queue has not reached the limit value, storing the current request transaction in the transaction storage queue; reading the target request transaction from the transaction storage queue and executing a preset request transaction forwarding operation to forward the target request transaction to the target end. Therefore, this application, by adding a transaction storage queue and a response process to the simulation kernel, determines the execution status of each process and determines the next operation based on the execution status, while ensuring that multiple phases can be supported in communication. It subdivides each stage of communication to improve concurrent processing capabilities when multiple transactions are concurrent, making performance modeling and evaluation more accurate and improving compatibility.

[0100] In some specific embodiments, the transaction receiving module 11 specifically includes:

[0101] The information acquisition unit is used to acquire the current request transaction and the initial transmission phase sent by the initiating end;

[0102] A response event triggering unit is used to trigger a current request response event corresponding to the current request transaction.

[0103] The first current transmission phase setting unit is used to set the first current transmission phase;

[0104] The first current transmission phase sending unit is used to send the first current transmission phase to the initiating end through the reverse interface, so that the initiating end can send a new current request transaction to the simulation kernel after receiving the first current transmission phase.

[0105] The current request transaction determination unit is used to determine whether the current request transaction is a transaction sent from the non-blocking communication port of the initiating end;

[0106] The port communication type determination unit is used to determine whether the port communication type of the target end is a blocking communication type if the current request transaction is sent from the non-blocking communication port of the initiating end.

[0107] The blocking communication type determination unit is used to determine that the current communication type is a mixed communication type if the port communication type of the target end is the blocking communication type.

[0108] In some specific embodiments, the queue determination module 12 specifically includes:

[0109] The first limit value judgment unit is used to determine whether the transaction storage queue has reached the limit value when the current communication type is the mixed communication type.

[0110] A blocking unit is used to block the current request transaction sent through the non-blocking communication port of the initiating end if the transaction storage queue has reached the limit value.

[0111] The second limit value judgment unit is used to wait for a preset clock cycle and then re-enter the step of judging whether the transaction storage queue has reached the limit value.

[0112] In some specific embodiments, the transaction storage module 13 specifically includes:

[0113] A transaction storage unit is used to store the current request transaction at the tail of the transaction storage queue if the transaction storage queue has not reached the limit value.

[0114] In some specific embodiments, the event triggering module 14 specifically includes:

[0115] The response event triggering unit is used to trigger request response events.

[0116] In some specific embodiments, the request transaction forwarding module 15 specifically includes:

[0117] The initial judgment unit is used to determine whether the preset request transaction forwarding operation is being executed for the first time.

[0118] The first determination unit is used to determine, if it is the first time the preset request transaction forwarding operation is executed, that there is currently no preset request transaction forwarding operation being executed.

[0119] The status information receiving and judging unit is used to determine whether the status information of the previous preset request transaction forwarding operation returned by the target end has been received if it is not the first time the preset request transaction forwarding operation has been executed.

[0120] The second determination unit is used to determine that there is currently no preset request transaction forwarding operation being executed if the status information of the previous preset request transaction forwarding operation has been received.

[0121] The third determination unit is used to determine that there is currently an execution of the preset request transaction forwarding operation if the status information of the previous preset request transaction forwarding operation is not received.

[0122] The first waiting unit is used to block and wait if there is a preset request transaction forwarding operation currently being executed;

[0123] The target request transaction reading unit is used to read the target request transaction from the head of the transaction storage queue if there is no currently executing preset request transaction forwarding operation.

[0124] The second waiting unit is used to forward the target request transaction to the blocking communication port of the target end and block and wait;

[0125] The blocking stop unit is used to stop blocking when it receives status information from the target end indicating that the target requested transaction has been completed.

[0126] The second current transmission phase setting unit is used to set the second current transmission phase;

[0127] The second current transmission phase sending unit is used to send the second current transmission phase to the initiating end through the reverse interface.

[0128] Furthermore, embodiments of this application also provide an electronic device. Figure 12 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0129] Figure 12 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the transaction processing method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0130] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0131] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0132] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including computer programs capable of performing the transaction processing methods executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0133] Furthermore, embodiments of this application also disclose a storage medium storing a computer program, which, when loaded and executed by a processor, implements the transaction processing method steps disclosed in any of the foregoing embodiments.

[0134] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0135] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0136] The present invention has provided a detailed description of a transaction processing method, apparatus, device, and storage medium. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A transaction processing method, characterized in that, Applied to emulation kernels, including: Receive the current request transaction sent by the initiator and determine whether the transaction storage queue has reached its limit. If the transaction storage queue has not reached the limit value, the current request transaction is stored in the transaction storage queue, and a request response event is triggered. The target request transaction is read from the transaction storage queue, and a preset request transaction forwarding operation is executed to forward the target request transaction to the target end; After receiving the current request transaction sent by the initiating end, the method further includes: determining whether the current request transaction was sent from the non-blocking communication port of the initiating end; if the current request transaction was sent from the non-blocking communication port of the initiating end, then determining whether the port communication type of the target end is a blocking communication type; if the port communication type of the target end is a blocking communication type, then determining that the current communication type is a mixed communication type; correspondingly, determining whether the transaction storage queue has reached its limit includes: when the current communication type is the mixed communication type, determining whether the transaction storage queue has reached its limit value; The trigger request-response event includes: obtaining the current request transaction and initial transmission phase sent by the initiating end; triggering the current request-response event corresponding to the current request transaction; setting a first current transmission phase and sending the first current transmission phase to the initiating end through the reverse interface, so that the initiating end can send a new current request transaction to the simulation kernel after receiving the first current transmission phase; The step of performing a preset request transaction forwarding operation to forward the target request transaction to the target end includes: forwarding the target request transaction to the blocking communication port of the target end and blocking and waiting; stopping the blocking when receiving status information from the target end indicating that the target request transaction has been completed; setting a second current transmission phase and sending the second current transmission phase to the initiating end through the reverse interface.

2. The transaction processing method according to claim 1, characterized in that, After determining whether the transaction storage queue has reached its limit, the method further includes: If the transaction storage queue has reached the limit value, then the current request transaction sent through the non-blocking communication port of the initiating end is blocked; After waiting for a preset clock cycle, the process re-enters the step of determining whether the transaction storage queue has reached its limit.

3. The transaction processing method according to any one of claims 1 to 2, characterized in that, The step of storing the current request transaction in the transaction storage queue if the transaction storage queue has not reached the limit value includes: If the transaction storage queue has not reached the limit value, the current request transaction is stored at the tail of the transaction storage queue.

4. The transaction processing method according to claim 1, characterized in that, Before reading the target request transaction from the transaction storage queue, the method further includes: Determine whether this is the first time the preset request transaction forwarding operation has been executed; If this is the first time the preset request transaction forwarding operation is executed, it is determined that there is currently no preset request transaction forwarding operation being executed. If this is not the first time the preset request transaction forwarding operation has been executed, then determine whether the status information of the previous preset request transaction forwarding operation returned by the target end has been received; If the status information of the previous preset request transaction forwarding operation has been received, it is determined that there is currently no preset request transaction forwarding operation being executed. If the status information of the previous preset request transaction forwarding operation is not received, it is determined that there is currently a preset request transaction forwarding operation being executed. If there is currently an ongoing preset request transaction forwarding operation, then block and wait; Accordingly, reading the target request transaction from the transaction storage queue includes: If there is no currently executing preset request transaction forwarding operation, the target request transaction is read from the head of the transaction storage queue.

5. A transaction processing apparatus, characterized in that, Applied to emulation kernels, including: The transaction receiving module is used to receive the current request transaction sent by the initiating end; The queue judgment module is used to determine whether the transaction storage queue has reached its limit. A transaction storage module is used to store the current request transaction in the transaction storage queue if the transaction storage queue has not reached the limit value. The event triggering module is used to trigger request and response events; The request transaction forwarding module is used to read the target request transaction from the transaction storage queue and execute a preset request transaction forwarding operation to forward the target request transaction to the target end; After receiving the current request transaction sent by the initiating end, the method further includes: determining whether the current request transaction was sent from the non-blocking communication port of the initiating end; if the current request transaction was sent from the non-blocking communication port of the initiating end, then determining whether the port communication type of the target end is a blocking communication type; if the port communication type of the target end is a blocking communication type, then determining that the current communication type is a mixed communication type; correspondingly, determining whether the transaction storage queue has reached its limit includes: when the current communication type is the mixed communication type, determining whether the transaction storage queue has reached its limit value; The trigger request-response event includes: obtaining the current request transaction and initial transmission phase sent by the initiating end; triggering the current request-response event corresponding to the current request transaction; setting a first current transmission phase and sending the first current transmission phase to the initiating end through the reverse interface, so that the initiating end can send a new current request transaction to the simulation kernel after receiving the first current transmission phase; The step of performing a preset request transaction forwarding operation to forward the target request transaction to the target end includes: forwarding the target request transaction to the blocking communication port of the target end and blocking and waiting; stopping the blocking when receiving status information from the target end indicating that the target request transaction has been completed; setting a second current transmission phase and sending the second current transmission phase to the initiating end through the reverse interface.

6. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the transaction processing method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the transaction processing method as described in any one of claims 1 to 4.

Images