A transaction processing method and electronic device

Abstract

The application discloses a transaction processing method and an electronic device, and relates to the technical field of computer system simulation, wherein the method comprises the following steps: obtaining a transaction structure corresponding to a to-be-processed transaction, the to-be-processed transaction being a transaction that needs to be processed by a second process; writing the transaction structure in a target memory; and sending a first processing signal corresponding to the to-be-processed transaction to the second process, the first processing signal being used for instructing reading the transaction structure from the target memory, and the transaction structure being used for processing the to-be-processed transaction. According to the application, the original transaction data is completely reserved in the target memory, the serialization and deserialization operations of the transaction object are omitted, and the resource consumption generated by the transaction processing is effectively reduced; the transaction data is uniformly stored in the target memory, and only the signal transmission notification instruction is used, so that the multi-layer data forwarding process of the traditional IPC channel is omitted. In this way, the overall processing time of the cross-process transaction can be shortened, and the overall simulation running speed can be significantly improved.

Description

Technical Field

[0001] This application relates to the field of computer system simulation technology, and in particular to a transaction processing method and electronic device. Background Technology

[0002] Electronic System Level (ESL) hardware modeling commonly uses the Hardware System Modeling Standard Library (SystemC) to build a System on Chip (SoC) virtual simulation platform. It relies on the Discrete Event Simulation (DES) kernel to complete hardware behavior simulation, which can simultaneously support hardware verification and embedded software development.

[0003] The standard SystemC simulation kernel is based on a single-threaded, lightweight user-space coroutine scheduling mechanism (quick-thread). The platform incorporates multiple standardized hardware computing cores (Intellectual Property, IP), buses, memory controllers, Direct Memory Access (DMA), and peripherals, all executed serially within a single process address space. However, when targeting large-scale System-on-Chips (SoC) virtual platforms, existing single-process simulation capabilities suffer from significant bottlenecks in computing power and memory resource contention, resulting in low simulation efficiency. The industry urgently needs multi-process parallel simulation acceleration solutions.

[0004] Current mainstream multi-process SystemC transaction-level modeling (TLM) parallel simulation solutions mostly decompose the simulation topology using transaction-level modeling sockets as boundaries, deploying each decomposed module to an independent simulation process. Inter-process transaction forwarding is accomplished through inter-process communication (IPC) channels such as Unix domain sockets (UDS), message queues, and pipes. This type of solution requires serialization and deserialization operations on transaction objects when transmitting cross-process transactions, resulting in high resource overhead. Furthermore, the serialization data transmission via the aforementioned IPC channels generates multiple kernel-mode data copies, further increasing transaction transmission overhead and reducing overall simulation speed. Summary of the Invention

[0005] In view of this, this application provides a transaction processing method and an electronic device, the main purpose of which is to solve the technical problems of high overhead in transaction object serialization and deserialization in existing multi-process TLM parallel simulation schemes, and multiple kernel-mode data copies in inter-process communication, which leads to low simulation running efficiency.

[0006] In a first aspect, this application provides a transaction processing method applied to a first process, comprising: Obtain the transaction structure corresponding to the transaction to be processed. The transaction to be processed is the transaction that needs to be processed by the second process.

[0007] Write the basic fields, transaction data, and transaction extended data from the transaction structure to the basic structure partition, data buffer partition, and extended structure partition of the target memory, respectively.

[0008] Send a first processing signal corresponding to the pending transaction to the second process. The first processing signal is used to instruct the reading of the transaction structure from the target memory. The transaction structure is used to process the pending transaction.

[0009] Secondly, this application provides a transaction processing method applied to a second process, comprising: The first processing signal corresponding to the pending transaction of the first process is received. The first processing signal is generated when the basic fields, transaction data and transaction extended data in the transaction structure corresponding to the pending transaction are written to the basic structure partition, data buffer partition and extended structure partition of the target memory respectively.

[0010] Read the transaction structure from the target memory.

[0011] Transaction processing is performed based on the transaction structure.

[0012] Thirdly, this application provides a transaction processing system, which includes a first process and a second process.

[0013] The first process is used to execute the transaction processing method as described in the first aspect above.

[0014] The second process is used to execute the transaction processing method as described in the second aspect above.

[0015] Fourthly, this application provides a transaction processing apparatus applied to a first process, comprising: The acquisition module is configured to acquire the transaction structure corresponding to the transaction to be processed, which is a transaction that needs to be processed by a second process.

[0016] The write module is configured to write the basic fields, transaction data, and transaction extended data in the transaction structure to the basic structure partition, data buffer partition, and extended structure partition of the target memory, respectively.

[0017] The sending module is configured to send a first processing signal corresponding to the pending transaction to the second process. The first processing signal is used to instruct the reading of the transaction structure from the target memory. The transaction structure is used to perform transaction processing on the pending transaction.

[0018] Fifthly, this application provides a transaction processing apparatus applied to a second process, comprising: The receiving module is configured to receive the first processing signal corresponding to the pending transaction of the first process. The first processing signal is generated when the basic fields, transaction data and transaction extended data in the transaction structure corresponding to the pending transaction are written to the basic structure partition, data buffer partition and extended structure partition of the target memory, respectively.

[0019] The read module is configured to read the transaction structure from the target memory.

[0020] The processing module is configured to perform transaction processing on the transactions to be processed based on the transaction structure.

[0021] In a sixth aspect, this application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the transaction processing method described in the first or second aspect.

[0022] By employing the above technical solution, this application provides a transaction processing method and electronic device. Compared with existing technologies, this application first obtains the transaction structure corresponding to the cross-process transaction to be processed and directly writes it into the target memory. Then, it sends a first processing signal, used only for wake-up prompts, to the second process. After the second process receives the signal, it reads the complete transaction structure from the target memory to complete the transaction processing. This application relies on the target memory to completely preserve the original transaction data, eliminating the need for transaction object serialization and deserialization operations, effectively reducing the resource overhead generated by transaction processing. Transaction data is uniformly stored in the target memory, and notification instructions are transmitted only through signals, eliminating the multi-layer data forwarding process of traditional IPC channels. Thus, the overall processing time of cross-process transactions can be shortened, significantly improving the overall simulation running speed. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a transaction processing method provided in an embodiment of this application is shown; Figure 2A flowchart illustrating another transaction processing method provided in an embodiment of this application is shown; Figure 3 This illustration shows a schematic diagram of a multi-process TLM simulation structure provided in an embodiment of this application; Figure 4 This paper shows a schematic diagram of the structure of a transaction processing apparatus provided in an embodiment of the present application; Figure 5 A schematic diagram of another transaction processing apparatus provided in an embodiment of this application is shown; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0026] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0027] This application applies to electronic system-level simulation scenarios, which rely on SystemC to build a SoC virtual simulation platform for hardware verification and embedded software development. The native SystemC kernel is based on quick-thread serial scheduling, and large SoC platforms exhibit significant computing power and memory bottlenecks. This has led to the development of three parallel simulation optimization approaches in the industry: The first type modifies the underlying SystemC scheduling kernel to support multi-threaded concurrency, which requires changes to the kernel code and has significant limitations on model compatibility and IP reusability.

[0028] The second type divides parallel tasks by analyzing the event dependencies of modules, which requires the model to be adapted to a specific interface and lacks versatility.

[0029] The third type represents the current mainstream implementation solution, which uses TLM sockets to split the simulation topology and deploys the hardware model to an independent process. It relies on IPC channels such as UDS, message queues, and pipes to forward cross-process transaction objects. This solution requires serialization and deserialization of transaction objects, resulting in high computational overhead and severe cache pollution in high-bandwidth scenarios. The additional compression and decompression logic also increases latency. Furthermore, traditional IPC transmission generates multiple kernel-mode data copies, limiting the overall simulation speed.

[0030] To address the technical issues of high overhead in transaction object serialization and deserialization, and multiple kernel-mode data copies involved in inter-process communication, leading to low simulation efficiency in existing multi-process TLM parallel simulation schemes, this application completely preserves native transaction data in the target memory, eliminating the need for transaction object serialization and deserialization operations and effectively reducing resource overhead from transaction processing. Transaction data is uniformly stored in the target memory, with instructions only transmitted via signals, eliminating the multi-layered data forwarding process of traditional IPC channels. This shortens the overall processing time of cross-process transactions and significantly improves the overall simulation speed.

[0031] This embodiment provides a transaction processing method applied to a first process, which is a simulation process that initiates bus transactions after TLM simulation topology splitting, and internally carries an initiating end bridging module and a TLM initiation component.

[0032] like Figure 1 The flowchart shown illustrates a transaction processing method, which includes: S101. Obtain the transaction structure corresponding to the transaction to be processed. The transaction to be processed is a transaction that needs to be processed by the second process.

[0033] Among them, pending transactions refer to bus interaction transactions in SoC simulation, covering various hardware interaction requests such as memory read / write and peripheral access. The transaction structure corresponding to pending transactions is a data carrier that fully carries all information of the bus transaction, including native information such as transaction address, operation instructions, transmitted data, and extended attributes, corresponding to the standard TLM transaction object.

[0034] In one implementation, the initiating bridging module within the first process intercepts local transaction calls, extracts all parameters of the current transaction to be processed, and assembles them into a complete transaction structure.

[0035] For example, during simulation, when the TLM initiating component initiates various bus interaction requests such as memory read / write, peripheral register access, and DMA batch transfer, the initiating-end bridging module captures the native transaction object, sequentially extracts basic scalar fields such as operation address, read / write instruction, data length, byte enable, and transmission status, synchronously associates them with the corresponding business data buffer, and simultaneously intercepts extended attributes such as on-chip interconnect routes, caching strategies, quality of service, and logical addresses of the link storage. The initiating-end bridging module encapsulates all the above native information into a transaction structure, in which: The local transaction call is b_transport, which is the standard bus transaction interface defined by the SystemCTLM specification. It is the standard function called when the TLM initiating component initiates data interaction with the target component.

[0036] The initiating bridge module is deployed within the TLM transaction initiation process. It is a relay component that can capture local bus transactions, write transaction information to shared memory, and send process notification signals (first processing signals). It is compatible with the original TLM model interface.

[0037] The native transaction object is tlm_generic_payload, which is the TLM standard general transaction carrier used to carry all the basic information of a single bus interaction.

[0038] The business data buffer is pointed to by the data_ptr pointer inside the transaction object and is used to store the actual interaction data corresponding to read and write operations.

[0039] The link is a tlm_extension extended attribute linked list, used to mount bus-related service information such as on-chip routing, cache control, transmission priority, and logical address.

[0040] S102. Write the basic fields, transaction data, and transaction extended data in the transaction structure to the basic structure partition, data buffer partition, and extended structure partition of the target memory, respectively.

[0041] The target memory is a shared memory transaction area shared by multiple processes, which can be directly read and written by the first process and the second process.

[0042] In one implementation, the initiating bridging module writes the basic fields, transmitted data, and extended attributes contained in the transaction structure into the target memory in place according to the memory partitioning mapping rules, thus fully preserving the original data format of the transaction.

[0043] S103. Send a first processing signal corresponding to the pending transaction to the second process. The first processing signal is used to instruct the reading of the transaction structure from the target memory. The transaction structure is used to process the pending transaction.

[0044] The first processing signal is used only for lightweight wake-up notification of inter-process transaction readiness, and only transmits the transaction readiness identifier without carrying any transaction data.

[0045] In one implementation, after the transaction structure is completely written to the target memory, the initiating bridging module sends a first processing signal to the second process through the system signal interface, informing the second process that there is a transaction to be processed in the target memory.

[0046] This embodiment also provides a transaction processing method applied to a second process, which is a simulation process responsible for receiving and executing transactions to be processed after the TLM simulation topology is split, and internally deploys a target-end bridging module and a TLM target component.

[0047] like Figure 2The flowchart shown represents another transaction processing method, which includes: S201. Receive the first processing signal corresponding to the pending transaction of the first process. The first processing signal is generated when the basic field, transaction data and transaction extended data in the transaction structure corresponding to the pending transaction are respectively written to the basic structure partition, data buffer partition and extended structure partition of the target memory.

[0048] In one implementation, the second process has a dedicated signal waiting thread that continuously and synchronously blocks and listens for process signals. Once the first processing signal is captured, it can be determined that the target memory has been completely written with the pending transaction. For example, when the second process starts, a dedicated signal waiting thread is created synchronously. This thread calls the synchronous waiting interface to remain suspended, without consuming the simulation's main thread's computing power. The thread is only awakened when the operating system pushes the first processing signal initiated by the first process, triggering the subsequent transaction reading process.

[0049] S202. Read the transaction structure from the target memory.

[0050] In one implementation, the target-side bridging module directly accesses the target memory, reads the complete, unformatted transaction structure, and generates a local transaction view without performing deserialization parsing. For example, the target-side bridging module reads all original fields, data cache, and extended attributes of the transaction based on a preset shared memory partition offset address, and generates a transaction view that can be called by the local TLM target component based on the in-situ data in memory, eliminating the need for byte stream parsing and deserialization related operations.

[0051] S203. Perform transaction processing on the transaction to be processed based on the transaction structure.

[0052] In one implementation, the target-side bridging module transmits the read transaction view to the local TLM target component and executes the corresponding hardware simulation logic such as memory read / write, DMA transfer, and peripheral access. After the transaction is completed, the bridging module writes the response status, returned data, and extended response fields back to the target memory in place and sends a response signal (second processing signal) to notify the first process of the read result, thus forming a complete transaction loop.

[0053] like Figure 3 The diagram shows a multi-process TLM simulation structure, which includes a first process, a second process, and shared memory (target memory). The first process and the second process rely on the shared memory to carry complete transaction data and complete control notification through inter-process lightweight signals. The two work together to realize cross-process TLM transaction interaction.

[0054] The first process internally includes a dedicated signal waiting thread A, a SystemC simulation main thread A, an initiating bridge module, and a TLM initiating component. The initiating bridge module and the TLM initiating component are attached to the SystemC simulation main thread A. The second process internally includes a dedicated signal waiting thread B, a SystemC simulation main thread B, a target bridge module, and a TLM target component. The target bridge module and the TLM target component are attached to the SystemC simulation main thread B.

[0055] In one implementation, relying on the original serial SystemC simulation topology, the split boundary is set at the TLM socket connection. During the simulation initialization phase, the hardware models on both sides of the boundary (i.e., the TLM initiating component and the TLM target component) are respectively mounted to the SystemC simulation main threads of the first process and the second process. Each thread is equipped with an independent SystemC kernel and a local event queue, which are scheduled by the operating system to be processed in parallel on different CPU cores. At the same time, bridging modules (initiating-end bridging module and target-end bridging module) are added at both ends of the TLM socket split boundary. The initiating-end bridging module is mounted to the SystemC simulation main thread of the first process, and the target-end bridging module is mounted to the SystemC simulation main thread of the second process. All cross-process bus transactions generated at the boundary are uniformly transmitted using shared memory in-situ storage combined with inter-process signal notification, replacing the traditional IPC byte stream transmission path.

[0056] For example, the processor, DMA, and bus initiation components in the original serial SystemC simulation topology are classified as the first process; the DDR memory controller and peripheral target components are classified as the second process. The socket connection position of the two is used as a fixed split boundary. All read, write, and batch transfer transactions generated by this boundary are completed through shared memory and process signals.

[0057] Compared with existing technologies, this application first obtains the transaction structure corresponding to the cross-process transaction to be processed and writes it directly into the target memory. Then, it sends a first processing signal, which is only used for wake-up prompts, to the second process. After the second process receives the signal, it reads the complete transaction structure from the target memory to complete the transaction processing. This application relies on the target memory to completely preserve the original transaction data, eliminating the serialization and deserialization operations of transaction objects, effectively reducing the resource overhead generated by transaction processing. Transaction data is uniformly stored in the target memory, and notification instructions are transmitted only through signals, eliminating the multi-layer data forwarding process of traditional IPC channels. In this way, the overall processing time of cross-process transactions can be shortened, significantly improving the overall simulation running speed.

[0058] The following is a detailed description of an embodiment of the transaction processing method provided in this application, executed on the first process side.

[0059] Optionally, this application also provides an embodiment for obtaining the transaction structure corresponding to the transaction to be processed. In this embodiment, the initiating bridge module in the first process listens to the transaction interface, which is used to generate the transaction call instruction for the transaction to be processed; when the transaction call instruction is heard, the native transaction object corresponding to the transaction call instruction is extracted, and the native transaction object contains basic fields, transaction data and transaction extended attributes; based on the basic fields, transaction data and transaction extended attributes, the transaction structure corresponding to the transaction to be processed is obtained.

[0060] Among them, the transaction call instruction, namely b_transport mentioned above, is a standard function for the TLM initiating component to initiate data interaction with the TLM target component, and is generated by the TLM initiating component such as the processor and DMA.

[0061] In one implementation, the initiating bridging module is mounted at the TLM initiating component exit, continuously intercepting local b_transport calls. Once a transaction call instruction is captured, it directly intercepts the complete native transaction object bound to the current instruction, without any data transcoding. For example, during simulation of DMA batch writes to DDR and peripheral register read operations, the bridging module intercepts the transaction call instruction corresponding to this bus interaction, captures the tlm_generic_payload native transaction object, extracts all internal information of the object, and integrates and encapsulates it into a transaction structure. The basic fields are various scalar parameters built into the native transaction object, including basic bus interaction information such as operation address, read / write instructions, data length, byte enable, and transmission status; the transaction data is the actual read / write data stored in the buffer pointed to by the pointer within the native transaction object; and the transaction extended attributes are custom additional business information such as on-chip interconnect routing, caching strategy, quality of service, and logical address mounted on the extended linked list.

[0062] In this embodiment, the module directly reuses all the original information of the native transaction object to encapsulate the transaction structure without performing byte stream packaging conversion. This eliminates the need for serialization encoding operations, significantly reduces CPU computational overhead, and avoids additional cache pollution caused by packaging.

[0063] Optionally, this application also provides an embodiment for writing a transaction structure to the target memory. In this embodiment, the initiating bridging module writes the basic fields of the original transaction object to the basic structure partition of the target memory; writes the transaction data of the original transaction object to the data buffer partition of the target memory; and writes the transaction extended attributes of the original transaction object to the extended structure partition of the target memory; wherein, the basic structure partition, the data buffer partition, and the extended structure partition constitute the storage carrier for storing the transaction structure.

[0064] The target memory is a shared memory transaction area used by multiple processes, which can be directly read and written by the first process and the second process; the basic structure partition is dedicated to storing various basic scalar parameters; the data buffer partition is dedicated to storing the actual read and write data corresponding to this interaction; and the extended structure partition is dedicated to storing bus-attached business attributes.

[0065] In one implementation, the initiating bridging module writes the three types of information contained in the transaction structure to the corresponding partition in the target memory in their original location, according to the memory partition mapping rules, thus fully preserving the original data format of the transaction. These memory partition mapping rules are pre-configured in both the initiating and target bridging modules.

[0066] For example, when the TLM initiating component in the first process calls the transaction interface to initiate a 64-bit memory write transaction, the initiating end bridging module fills in the corresponding content in sequence according to the preset fixed byte length and memory offset address of each partition, filling the basic fields into the basic structure partition, filling the 64-byte transmission data into the data buffer partition, and filling additional attributes such as routing and QoS into the extended structure partition.

[0067] This embodiment divides the shared memory into fixed functional partitions and unifies the memory mapping rules at both ends. The original transaction data is stored directly in place without serialization encoding or byte stream packaging and conversion, saving a lot of CPU computing overhead. At the same time, multiple processes share the same shared memory carrier, avoiding multiple user-mode and kernel-mode data copies in traditional inter-process communication and reducing interaction latency.

[0068] Optionally, this application also provides an embodiment of sending a first processing signal corresponding to a pending transaction to a second process. In this embodiment, the initiating bridging module sends the first processing signal through the target communication line between the first process and the second process. The first processing signal is a wake-up signal for inter-process status notification and does not contain the data of the pending transaction.

[0069] The target communication line is the operating system's native process signal channel, which does not require heavy transmission components such as sockets and message queues; the first processing signal only serves as a transaction readiness reminder and only transmits identification information. The complete transaction data is stored in the target memory, thus achieving separation of the control plane and the data plane.

[0070] In one implementation, after all three partitions of the target memory have completed the filling and writing of transaction information, the initiating bridge module calls the system signal interface to push the first processing signal to the dedicated signal waiting thread resident in the second process. For example, after the TLM initiating component initiates a 64-byte DMA batch write transaction and writes it completely to the shared memory, the initiating bridge module sends a system signal as the first processing signal. The signal only carries the process identity identifier and does not carry any bus service data such as address, transmitted data, or extended attributes.

[0071] This embodiment uses lightweight signals to carry control commands, and all big data transaction data is stored in shared memory, which greatly reduces the amount of data transmitted across processes, reduces the bandwidth usage of inter-process communication, and decouples control logic from business data.

[0072] Optionally, this application also provides an embodiment for receiving transaction processing results. In this embodiment, a second processing signal corresponding to the transaction to be processed is received, the second processing signal being generated when the transaction processing result corresponding to the transaction to be processed is written to the target memory; the corresponding transaction processing result is read from the target memory.

[0073] The second processing signal is a transaction completion notification wake-up signal issued by the second process. It is only used to inform the first process that the transaction return result has been written into the target memory, and does not carry any processing result data. The first process has a dedicated signal waiting thread that is always resident inside it to capture cross-process signals and avoid blocking the simulation main thread.

[0074] In one implementation, a dedicated signal waiting thread blocks and listens for cross-process signals. After capturing the second processing signal, it maps the operating system native signal to a SystemC asynchronous event, waking up the initiating bridge module. The bridge module, based on a preset memory partition offset, directly reads the transaction return status, read data, and response extended attributes stored in the target memory, and fills them back into the local TLM initiating component to complete the closed loop of this cross-process transaction. For example, after the second process completes the DDR read transaction and writes the read data (transaction processing result) to shared memory, it sends the second processing signal. The first process's dedicated signal waiting thread captures the signal and converts it to a SystemC asynchronous event, waking up the initiating bridge module. The initiating bridge module reads the read content stored in the data buffer partition, fills it back into the local DMA cache, and ends the memory read interaction.

[0075] For example, after receiving the second processing signal, the dedicated signal waiting thread on the first process side submits an asynchronous update request by calling `async_request_update`. This request is then uniformly scheduled by the SystemC emulation main thread on the local side (i.e., the first process side) to execute the TLM transaction backfill operation by the initiating bridge module. This scheduling method separates the signal notification action of the dedicated signal waiting thread from the business processing action of the SystemC emulation main thread. All bridge module accesses and TLM transaction backfill operations are executed serially only on the SystemC emulation main thread. By isolating the concurrent operations of the dedicated signal waiting thread and the SystemC emulation main thread, thread safety of the SystemC kernel and TLM transaction operations is guaranteed.

[0076] This embodiment reuses the same shared memory to carry request and response data, eliminating the need for a new independent data transmission channel; a dedicated signal waiting thread completes the mapping and conversion of cross-process signals to SystemC asynchronous events, which does not consume the computing power of the simulation main thread, avoids the thread safety risks caused by directly calling the SystemC interface, and ensures the timing stability of the SoC simulation main thread.

[0077] The following is a detailed description of an embodiment of the transaction processing method provided in this application, in which the transaction processing method is executed on the second process side.

[0078] Optionally, this application also provides an embodiment for reading a transaction structure from a target memory. In this embodiment, the basic fields of the native transaction object carried by the transaction structure are read from the basic structure partition; the transaction data of the native transaction object carried by the transaction structure is read from the data buffer partition; and the transaction extended attributes of the native transaction object carried by the transaction structure are read from the extended structure partition.

[0079] In one implementation, after the dedicated signal waiting thread captures the first processing signal and maps it to a SystemC asynchronous event, the target-side bridging module sequentially reads the raw transaction information (without format conversion) from the three major partitions according to a unified preset memory offset address, generating a local transaction view without performing deserialization parsing or byte stream restoration operations. For example, after the first processing signal sent by the first process is captured, the target-side bridging module sequentially reads the address and read / write instructions of the infrastructure partition according to the preset partition offset, reads the data to be written from the data buffer partition, and reads the routing and QoS permission parameters of the extended structure partition, generating a transaction view that can be called by the local TLM target component.

[0080] For example, after capturing the first processing signal, the dedicated signal-waiting thread on the second process side submits an asynchronous update request by calling `async_request_update`. The target-side bridge module is then scheduled by the local SystemC emulation main thread on the second process side to perform the shared memory transaction structure read operation. This scheduling method separates the signal notification action of the dedicated signal-waiting thread from the business processing action of the SystemC emulation main thread. All bridge module access and transaction structure read / parsing operations are executed serially only on the SystemC emulation main thread. By isolating the concurrent operations of the dedicated signal-waiting thread and the SystemC emulation main thread, thread safety of the SystemC kernel and TLM transaction operations is guaranteed.

[0081] This embodiment reuses the original data in the shared memory, eliminating the need for deserialization and decoding operations, reducing CPU computing power consumption and cache jitter in high-volume DMA batch transfer scenarios, and achieving near-zero copy data reading and access.

[0082] Optionally, this application also provides an embodiment for transaction processing based on a transaction structure. In this embodiment, the simulation resources and simulation processing logic corresponding to the transaction to be processed are determined according to the basic fields; simulation constraints are obtained according to the transaction extended attributes, and the simulation constraints include at least one of simulation timing, parameter constraints, data verification, and permission configuration; and the read transaction data is processed according to the simulation resources and simulation constraints and the simulation processing logic.

[0083] The simulation resources correspond to the TLM target components within the second process, including the DDR memory controller and various peripheral modules. The simulation processing logic is a hardware native read / write and data transfer simulation process; the simulation constraints are carried by the transaction extension attributes and are used to manage the hardware simulation cycle time, transmission access permissions, and data validity verification rules.

[0084] In one implementation, the target-side bridging module transmits the generated local transaction view to the local TLM target component. It then matches the corresponding hardware simulation resources based on the basic fields, extracts the timing and permission constraints carried by the extended attributes, and completes the data interaction simulation according to the hardware standard process. For example, after reading the write transaction structure from shared memory, it matches the DDR controller simulation resources based on the address basic fields, adjusts the simulation cycle time according to the transmission priority and timing constraints within the extended attributes, performs the memory write operation, and simultaneously completes data verification.

[0085] This embodiment reuses all the parameters and constraints that come with the native transaction, without the need for additional configuration logic conversion. It conforms to the native simulation scheduling timing of SystemC, ensuring the simulation execution order and model accuracy in multi-process parallel scenarios.

[0086] Optionally, this application also provides an embodiment for sending a second processing signal. In this embodiment, the transaction processing result of the transaction to be processed is written to the target memory; a second processing signal corresponding to the transaction to be processed is sent to the first process, the second processing signal being used to instruct the reading of the transaction processing result from the target memory.

[0087] The transaction processing result includes information such as transmission return data, execution status, and exception flags, and is written to the corresponding partition of the target memory in place according to the partitioning rules; the second processing signal is a lightweight transaction completion notification wake-up signal, which is only used to trigger the first process signal waiting thread, and the signal itself does not carry any transaction return data.

[0088] In one implementation, after the local hardware simulation logic is completed, the target-side bridging module fills all processing results back into the target memory according to the partition offset. After the memory write operation is completed, a second processing signal is sent to the first process via the system signal channel. This signal is captured by the first process's dedicated signal waiting thread and converted into a SystemC asynchronous event, completing the request-response transaction loop.

[0089] In this embodiment, requests and responses reuse the same shared memory carrier, eliminating the need for an additional data transmission channel; control commands are transmitted using only lightweight signals, achieving complete separation between the control plane and the data plane, thus improving the efficiency of multi-process concurrent transaction processing.

[0090] Compared with existing technologies, this application first obtains the transaction structure corresponding to the cross-process transaction to be processed and writes it directly into the target memory. Then, it sends a first processing signal, which is only used for wake-up prompts, to the second process. After the second process receives the signal, it reads the complete transaction structure from the target memory to complete the transaction processing. This application relies on the target memory to completely preserve the original transaction data, eliminating the serialization and deserialization operations of transaction objects, effectively reducing the resource overhead generated by transaction processing. Transaction data is uniformly stored in the target memory, and notification instructions are transmitted only through signals, eliminating the multi-layer data forwarding process of traditional IPC channels. In this way, the overall processing time of cross-process transactions can be shortened, significantly improving the overall simulation running speed.

[0091] Furthermore, as Figure 1 or Figure 2 The specific implementation of the method shown in this embodiment provides a transaction processing system, which includes a first process and a second process. The first process executes as described above. Figure 1 The transaction processing method shown above, the second process executes as described above. Figure 2 The transaction processing method shown.

[0092] Furthermore, as Figure 1 The specific implementation of the method shown in this embodiment provides a transaction processing device, such as... Figure 4 The diagram shows a structural schematic of a transaction processing device 400, which includes an acquisition module 410, a writing module 420, and a sending module 430; wherein: The acquisition module 410 is configured to acquire the transaction structure corresponding to the transaction to be processed, wherein the transaction to be processed is a transaction that needs to be processed by a second process.

[0093] The write module 420 is configured to write the basic fields, transaction data, and transaction extended data in the transaction structure to the basic structure partition, data buffer partition, and extended structure partition of the target memory, respectively.

[0094] The sending module 430 is configured to send a first processing signal corresponding to the pending transaction to the second process. The first processing signal is used to instruct the reading of the transaction structure from the target memory. The transaction structure is used to perform transaction processing on the pending transaction.

[0095] Optionally, the acquisition module 410 is configured to listen to a transaction interface, which is used to generate a transaction invocation instruction for the transaction to be processed.

[0096] Upon detecting the transaction call instruction, the native transaction object corresponding to the transaction call instruction is extracted. The native transaction object contains basic fields, transaction data, and transaction extended attributes.

[0097] Based on the basic fields, transaction data, and transaction extended attributes, the transaction structure corresponding to the transaction to be processed is obtained.

[0098] Optionally, the write module 420 is configured to write the basic fields in the native transaction object to the infrastructure partition of the target memory.

[0099] Write the transaction data in the native transaction object to the data buffer partition of the target memory.

[0100] Write the transaction extension attributes from the native transaction object into the extended structure partition of the target memory. The basic structure partition, data buffer partition, and extended structure partition constitute the storage carrier for storing the transaction structure.

[0101] Optionally, the sending module 430 is configured to send a first processing signal through a target communication line between the first process and the second process. The first processing signal is a wake-up signal for inter-process status notification and does not contain the data of the transaction to be processed.

[0102] Optionally, the device further includes a second reading module configured to receive a second processing signal corresponding to the transaction to be processed, the second processing signal being generated when the transaction processing result corresponding to the transaction to be processed is written to the target memory.

[0103] Read the corresponding transaction processing result from the target memory.

[0104] Furthermore, as Figure 2 To provide a specific implementation of the method shown, this embodiment offers another transaction processing device, such as... Figure 5 The schematic diagram of another transaction processing device shown shows that the transaction processing device 500 includes a receiving module 510, a reading module 520, and a processing module 530; wherein: The receiving module 510 is configured to receive the first processing signal corresponding to the pending transaction of the first process. The first processing signal is generated when the basic fields, transaction data and transaction extended data in the transaction structure corresponding to the pending transaction are respectively written to the basic structure partition, data buffer partition and extended structure partition of the target memory.

[0105] The read module 520 is configured to read the transaction structure from the target memory.

[0106] Processing module 530 is configured to perform transaction processing on the transaction to be processed based on the transaction structure.

[0107] Optionally, the read module 520 is configured to read the base fields of the native transaction object carried by the transaction structure from the infrastructure partition.

[0108] Read transaction data from the native transaction object carried by the transaction structure from the data buffer partition.

[0109] Read the transaction extension properties of the native transaction object carried by the transaction structure from the extended structure partition.

[0110] Optionally, the processing module 530 is configured to determine the simulation resources and simulation processing logic corresponding to the transaction to be processed based on the basic fields.

[0111] Based on the transaction extension attributes, obtain the simulation constraints, which include at least one of the following: simulation timing, parameter constraints, data validation, and permission configuration.

[0112] Based on simulation resources and constraints, the read transaction data is processed according to the simulation processing logic.

[0113] Optionally, the device further includes a second sending module configured to write the transaction processing result of the transaction to be processed to the target memory.

[0114] Send a second processing signal corresponding to the pending transaction to the first process. The second processing signal is used to instruct the reading of the transaction processing result from the target memory.

[0115] It should be noted that other corresponding descriptions of the functional units involved in the transaction processing apparatus provided in this embodiment can be found in [reference needed]. Figure 1 or Figure 2 The corresponding descriptions in [the document] will not be repeated here.

[0116] Based on the above, Figure 1 or Figure 2 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 or Figure 2 The method shown.

[0117] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0118] like Figure 6 The diagram shown is a structural schematic of an electronic device according to this application, comprising: At least one processor 601; and, A memory 602 is communicatively connected to at least one of the processors 601; wherein, The memory 602 stores instructions that can be executed by at least one of the processors to enable at least one of the processors to perform the transaction processing method as described above.

[0119] Figure 6 Take the 601 processor as an example.

[0120] The electronic device may also include an input device 603 and a display device 604.

[0121] The processor 601, memory 602, input device 603, and display device 604 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0122] The memory 602, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the transaction processing method in the embodiments of this application, for example, Figure 1 or Figure 2 The method flow is shown. The processor 601 executes various functional applications and data processing by running non-volatile software programs, instructions, and modules stored in the memory 602, thereby implementing the transaction processing method in the above embodiments.

[0123] Memory 602 may include a stored program area and a stored data area, wherein the stored program area may store the operating system and application programs required for at least one function; the stored data area may store data created according to the use of the transaction processing method, etc. Furthermore, memory 602 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 602 may optionally include memory remotely located relative to processor 601, and these remote memories may be connected to the apparatus performing the transaction processing method via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0124] The input device 603 can receive user clicks and generate signal inputs related to user settings and function control for transaction processing methods. The display device 604 may include a display screen or other display device.

[0125] When one or more modules are stored in the memory 602, and are run by one or more processors 601, the transaction processing method in any of the above method embodiments is executed.

[0126] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0127] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0128] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0129] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented in hardware. By applying the scheme of this embodiment, compared with the prior art, this application first obtains the transaction structure corresponding to the cross-process transaction to be processed and directly writes it into the target memory, then sends a first processing signal, used only for wake-up prompts, to the second process. After the second process receives the signal, it reads the complete transaction structure in the target memory to complete the transaction processing. This application relies on the target memory to completely retain the original transaction data, eliminating the serialization and deserialization operations of transaction objects, effectively reducing the resource overhead generated by transaction processing; the transaction data is uniformly stored in the target memory, relying only on signal transmission to notify instructions, eliminating the multi-layer data forwarding process of traditional IPC channels. Thus, the overall processing time of cross-process transactions can be shortened, significantly improving the overall simulation running speed.

[0130] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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.

[0131] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A transaction processing method, characterized in that, Applied to the first process, including: According to the memory partitioning mapping rules pre-configured in the first process and the second process, the transaction structure corresponding to the transaction to be processed is obtained by in-situ writing in a way that fully preserves the original data format of the transaction structure. The transaction to be processed is the transaction that needs to be processed by the second process. The basic fields, transaction data, and transaction extended data in the transaction structure are respectively written into the storage areas corresponding to the preset fixed byte lengths and memory offset addresses in the basic structure partition, data buffer partition, and extended structure partition of the target memory. Send a first processing signal corresponding to the pending transaction to the second process. The first processing signal is used to instruct the reading of the transaction structure from the target memory. The transaction structure is used to perform transaction processing on the pending transaction. The first processing signal is sent through the operating system's native process signal channel, without the need for sockets, message queues, or other heavy-duty transmission components. It only carries the process identity identifier and does not carry any bus service data such as address, transmission data, or extended attributes. The first process has a dedicated signal waiting thread that resides within it to capture cross-process signals and avoid blocking the simulation main thread. After capturing the second processing signal, the dedicated signal waiting thread maps the native operating system signal to a SystemC asynchronous event and wakes up the initiating bridge module. The bridge module directly reads the transaction return status, reads the data, and responds to the extended attributes stored in the target memory according to the preset memory partition offset, and fills it back to the local TLM initiating component to complete the closed loop of this cross-process transaction. The second processing signal is a transaction completion notification wake-up signal issued by the second process. It is only used to inform the first process that the transaction return result has been written into the target memory, and does not carry any processing result data. The step of obtaining the transaction structure corresponding to the transaction to be processed includes: Listen to the transaction interface, which is used to generate the transaction invocation instruction for the transaction to be processed; Upon detecting the transaction invocation instruction, extract the native transaction object corresponding to the transaction invocation instruction; Based on the basic fields, transaction data, and transaction extended attributes of the original transaction object, the transaction structure corresponding to the transaction to be processed is obtained.

2. The method according to claim 1, characterized in that, Sending the first processing signal corresponding to the pending transaction to the second process includes: A first processing signal is sent through the target communication line between the first process and the second process. The first processing signal is a wake-up signal for inter-process status notification and does not contain the data of the transaction to be processed.

3. The method according to any one of claims 1-2, characterized in that, The method further includes: Receive a second processing signal corresponding to the pending transaction, wherein the second processing signal is generated when the transaction processing result corresponding to the pending transaction is written to the target memory; Read the corresponding transaction processing result from the target memory.

4. A transaction processing method, characterized in that, Applied to the second process, including: The first processing signal is received from the first process corresponding to the pending transaction. The first processing signal is generated when the basic fields, transaction data and transaction extended data in the transaction structure corresponding to the pending transaction are written to the storage areas corresponding to the basic structure partition, data buffer partition and extended structure partition of the target memory respectively according to the memory partition mapping rules pre-configured between the first process and the second process, in an in-situ writing manner that completely preserves the original data format of the transaction structure. Read the transaction structure from the target memory; The transaction to be processed is performed based on the transaction structure. The step of reading the transaction structure from the target memory includes: Read the basic fields of the native transaction object carried by the transaction structure from the infrastructure partition; Read the transaction data of the native transaction object carried by the transaction structure from the data buffer partition; Read the transaction extension attributes of the native transaction object carried by the transaction structure from the extended structure partition; The first processing signal is sent through the operating system's native process signal channel, without the need for sockets, message queues, or other heavy-duty transmission components. It only carries the process identity identifier and does not carry any bus service data such as address, transmission data, or extended attributes. The second process writes the transaction processing result of the pending transaction into the target memory; and sends a second processing signal corresponding to the pending transaction to the first process. The second processing signal is a transaction completion notification wake-up signal issued by the second process, which is only used to inform the first process that the transaction return result has been written into the target memory and does not carry any processing result data. The second processing signal is used to trigger a dedicated signal waiting thread that is permanently stationed in the first process to capture the cross-process signal after being sent to the first process, so as to avoid blocking the simulation main thread and to map the native operating system signal into a SystemC asynchronous event, thereby waking up the initiating bridge module. The bridge module directly reads the transaction return status, reads the data, and responds to the extended attributes stored in the target memory according to the preset memory partition offset, and fills it back to the local TLM initiating component to complete the closed loop of this cross-process transaction.

5. The method according to claim 4, characterized in that, The transaction processing based on the transaction structure includes: Based on the aforementioned basic fields, determine the simulation resources and simulation processing logic corresponding to the transaction to be processed; Based on the transaction extension attributes, simulation constraints are obtained, including at least one of simulation timing, parameter constraints, data verification, and permission configuration. Based on the simulation resources and the simulation constraints, the read transaction data is processed according to the simulation processing logic.

6. The method according to any one of claims 4-5, characterized in that, The method further includes: The second processing signal is used to instruct the reader to read the transaction processing result from the target memory.

7. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 3, or the method of any one of claims 4 to 6.

Images