Method, apparatus, device and storage medium for transmitting transactions in a circuit design file

Abstract

The present application provides a method, apparatus, electronic device, and readable storage medium for transmitting transactions in a circuit design file, including: obtaining a first transaction constructed by assembly language in a verification platform, analyzing the first transaction to obtain corresponding first transaction attributes, based on the first transaction attributes, converting the first transaction into a byte stream, constructing target language transaction attributes and interface files, calling the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform, and calling the communication interface of the verification platform to transmit the target language transaction attributes and interface files to the target platform, parsing the received byte stream into second transaction attributes through the target platform according to the interface files and the target language transaction attributes, importing the second transaction attributes into a transaction template to obtain a second transaction corresponding to the target language, and displaying it. Using the target language for verification can reduce the language learning difficulty and broaden the applicable scenarios of the verification platform.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a method, an apparatus, an electronic device, and a computer-readable storage medium for transmitting transactions in a circuit design file. Background Art

[0002] Chip verification plays a crucial role in integrated circuit design, aiming to confirm that the chip design meets the specification requirements and can work properly under various conditions.

[0003] The Universal Verification Methodology (UVM) provides an object-oriented method to organize the test environment, generate test data, control simulation, and collect and analyze simulation results. Related technologies use UVM to build a verification environment to ensure the modularity and reusability of the verification environment.

[0004] However, UVM is based on the SystemVerilog language, and the language learning threshold is high. Currently, there is UVMC that can realize the connection between the SystemC language and the UVM environment, but its function is limited to supporting the SystemC language, and the applicable scenarios are few. Summary of the Invention

[0005] Embodiments of this application provide a method, an apparatus, an electronic device, and a computer-readable storage medium for transmitting transactions in a circuit design file to solve the problems in related technologies.

[0006] In a first aspect, embodiments of this application provide a method for transmitting transactions in a circuit design file, the method including:

[0007] Obtain a first transaction constructed by an assembly language in a verification platform, and analyze the first transaction to obtain a corresponding first transaction attribute;

[0008] Based on the first transaction attribute, convert the first transaction into a byte stream, and construct a target language transaction attribute and an interface file; the target language transaction attribute defines a transaction template corresponding to a transaction in the target language, and the target language is any one of multiple languages different from the assembly language;

[0009] Call the transaction-level modeling interface of the verification platform to transmit the byte stream to a target platform, and call the communication interface of the verification platform to transmit the target language transaction attribute and the interface file to the target platform; the interface file defines a method for parsing the byte stream into transaction attributes;

[0010] According to the interface file and the target language transaction attributes, the received byte stream is parsed into second transaction attributes by the target platform, and the second transaction attributes are imported into the transaction template to obtain the second transaction corresponding to the target language, and then it is displayed.

[0011] In a second aspect, an embodiment of the present application provides a device for transmitting transactions in a circuit design file. The device includes:

[0012] A first analysis module, configured to obtain a first transaction constructed by an assembly language in a verification platform, and analyze the first transaction to obtain corresponding first transaction attributes;

[0013] A processing module, configured to convert the first transaction into a byte stream based on the first transaction attributes, and construct target language transaction attributes and an interface file; the target language transaction attributes define a transaction template corresponding to a transaction in the target language, and the target language is any one of multiple languages different from the assembly language;

[0014] A first transmission module, configured to call a transaction-level modeling interface of the verification platform to transmit the byte stream to a target platform, and call a communication interface of the verification platform to transmit the target language transaction attributes and the interface file to the target platform; the interface file defines a method for parsing a byte stream into transaction attributes;

[0015] A first parsing module, configured to parse the received byte stream into second transaction attributes by the target platform according to the interface file and the target language transaction attributes, import the second transaction attributes into the transaction template to obtain the second transaction corresponding to the target language, and then display it.

[0016] In a third aspect, an embodiment of the present application further provides an electronic device, including a processor;

[0017] A memory for storing executable instructions of the processor;

[0018] Wherein, the processor is configured to execute the instructions to implement the method of the first aspect.

[0019] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device can execute the method of the first aspect.

[0020] In the embodiments of the present application, first, analyze the first transaction constructed by assembly language in the verification platform to obtain the corresponding transaction attributes. Based on the transaction attributes, convert the first transaction into a byte stream, and call the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform. Then, construct the target language transaction attributes and interface files based on the transaction attributes, and call the communication interface of the verification platform to transmit the target language transaction attributes and interface files to the target platform. According to the interface files and the target language transaction attributes, the byte stream is parsed into the second transaction corresponding to the target language by the target platform for display. In the development environment of the target language, transaction information can be intuitively viewed and analyzed, which can lower the learning threshold of the language, eliminate the need for frequent switching between different language environments, achieve cross-language interaction between the verification platform and the target platform, increase the applicable scenarios of the verification platform, and enhance the flexibility and scalability of the system.

[0021] The above description is only an overview of the technical solution of the present application. In order to be able to understand the technical means of the present application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of the present application more obvious and understandable, the specific embodiments of the present application are hereinafter specifically exemplified. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0023] Figure 1 It is a flowchart of the steps of a method for transmitting transactions in a circuit design file provided by the embodiments of the present application;

[0024] Figure 2 It is a specific flowchart of the steps of a method for transmitting transactions in a circuit design file provided by the embodiments of the present application;

[0025] Figure 3 It is a schematic diagram of the processing flow from the hardware level to the multi-language level provided by the embodiments of the present application;

[0026] Figure 4 It is a schematic diagram of the system architecture and data flow of hardware verification and multi-language interaction provided by the embodiments of the present application;

[0027] Figure 5 It is a block diagram of a device for transmitting transactions in a circuit design file provided by the embodiments of the present application;

[0028] Figure 6 It is a block diagram of an electronic device provided by the embodiments of the present application;

[0029] Figure 7 It is a block diagram of another electronic device provided by an embodiment of the present application. Specific implementation manners

[0030] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the scope of protection of the present application.

[0031] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, rather than to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments of the present application can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are usually of the same type, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the specification and claims is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after. The term "a plurality" in the embodiments of the present application refers to two or more, and other quantifiers are similar.

[0032] Figure 1 It is a step flowchart of a method for transmitting transactions in a circuit design file provided by an embodiment of the present application. As Figure 1 shown, the method may include:

[0033] Step 101, obtain a first transaction constructed by assembly language in a verification platform, and analyze the first transaction to obtain a corresponding first transaction attribute.

[0034] Exemplarily, a verification platform is a software environment for verifying the correctness of a hardware design. It provides a series of tools and mechanisms for generating stimuli, monitoring the responses of the design, and checking whether the design meets the expected functional specifications. A verification platform usually includes a transaction-level modeling interface, a communication interface, etc., and can simulate the behavior of a hardware system to comprehensively verify the design. For example, when verifying the design of a central processing unit (CPU), the verification platform can simulate different instruction sequences as stimuli, send them to the CPU for execution, and at the same time monitor the output results of the CPU and compare them with the expected results to ensure the correct function of the CPU.

[0035] By way of example, assembly language refers to the language used to construct transactions in a verification platform. The assembly language can be SystemVerilog, and each assembly instruction corresponds to one or more machine instructions. In a verification platform, assembly language may be used to write some specific transactions to more precisely control the behavior of the hardware.

[0036] By way of example, a transaction refers to a transaction constructed by assembly language in a verification platform. A transaction is a basic concept in a verification platform, which represents a sequence of operations with specific functions or behaviors. In hardware verification, a transaction can be a memory read / write operation, an instruction execution, etc. For example, when verifying a memory controller, a transaction can be a sequence of memory read operations written in assembly language.

[0037] By way of example, transaction attributes are a set of parameters that describe the characteristics and behaviors of a transaction. These attributes can include the transaction type, e.g., read transaction, write transaction, etc., transaction address, transaction data, etc. By analyzing the transaction attributes, the behavior and intention of the transaction can be better understood, thus enabling more effective verification. For example, the transaction attributes can include: transaction type: read transaction, transaction address: 0x1000, transaction data: 0x12345678.

[0038] By way of example, by parsing a user-specified UVM transaction file, the corresponding transaction attributes are obtained. For example, a tool is used to read the UVM transaction file, and a syntax analyzer is used to parse it to extract information such as the name of the transaction class, transaction type, transaction address, transaction data, etc. Specifically, the tool will parse out that the name of the transaction class is my_transaction, the transaction type is cmd, the transaction address is addr, and the transaction data is data.

[0039] Step 102, based on the first transaction attributes, convert the first transaction into a byte stream, and construct a target language transaction attribute and an interface file; the target language transaction attribute defines the transaction template corresponding to the transaction in the target language, and the target language is any one of multiple languages different from the assembly language.

[0040] For example, in chip verification, a byte stream refers to the representation and transmission of data in the form of a continuous sequence of bytes. Each byte consists of 8 bits of binary data, and a byte stream can represent any type of data, such as integers, floating-point numbers, strings, images, audio, etc. A byte stream is the basic form of data transmission and storage between hardware and software. For example, a memory write transaction is as follows: transaction type: write operation (1 byte), transaction address: 0x1000 (4 bytes), transaction data: 0x12345678 (4 bytes). Convert the transaction type to 0x01, the transaction address 0x1000 to 0x00 0x10 0x00 0x00, and the transaction data 0x12345678 to 0x12 0x34 0x56 0x78. Then this memory write transaction is converted to a byte stream as: 0x01 0x00 0x10 0x00 0x00 0x12 0x34 0x56 0x78. By parsing the transaction into a byte stream, the data flow in the actual hardware can be simulated, and efficient system-level verification can be supported.

[0041] For example, the target language refers to the language to be used after the first transaction is converted. It can be any one of multiple programming languages, such as Python, Java, C++, etc. Different target languages have different grammars and data structures, so it is necessary to construct corresponding transaction attributes and interface files according to the characteristics of the target language. For example, if Python is selected as the target language, then subsequent transaction attributes and interface files need to be written according to the grammar and specifications of Python.

[0042] For example, the target language transaction attributes define the attribute template corresponding to the transaction in the target language. It describes the data structure and attribute types of the transaction in the target language, similar to the definition of a class. Through this template, transaction objects can be created in the target language and their attributes can be operated on.

[0043] For example, the interface file defines the mapping relationship between transaction attributes and byte streams across different platforms. The interface file ensures that the verification platform and the target platform can correctly perform cross-language interactions and is the key to achieving accurate data transmission and processing.

[0044] Step 103, call the transaction-level modeling interface of the verification platform to transfer the byte stream to the target platform, and call the communication interface of the verification platform to transfer the target language transaction attributes and the interface file to the target platform; the interface file defines the method for parsing the byte stream into transaction attributes.

[0045] For example, the Transaction Level Modeling (TLM) interface originated from a transaction-level communication standard in SystemC. The so-called transaction level is relative to the signal-level communication between various modules in the Design under Test (DUT). Simply put, a transaction is a class formed by encapsulating a group of information with a specific function. In this way, the communication frequency can be reduced to minimize the resource consumption caused by synchronization between different processes. Through the transaction-level modeling interface, transactions such as byte streams can be transferred from one component to another to achieve communication and collaboration between different modules.

[0046] For example, the communication interface is an interface in the verification platform for data transfer with the target platform. It is responsible for sending information such as target language transaction attributes and interface files from the verification platform to the target platform. The communication interface can be a socket interface, which can be used to transfer transaction information between different transaction-level components. For example, a UVM verification platform written in SystemVerilog can send the generated transaction data to a target platform written in Python through the socket interface for processing, and the processing results are then returned to the UVM verification platform through the socket interface for verification.

[0047] Step 104: According to the interface file and the target language transaction attributes, the target platform parses the received byte stream into second transaction attributes, imports the second transaction attributes into the transaction template to obtain the second transaction corresponding to the target language, and displays it.

[0048] For example, taking the Python platform as the target platform, after the Python platform receives the interface file and the target language transaction attributes, it reads the interface file and parses it into a Python dictionary. Then, according to the rules of the interface file, the values of each field are extracted from the byte stream and converted into the corresponding data types to obtain the second transaction attributes. Finally, the attribute values in the second transaction attributes are assigned to an instance of the transaction template class to create the second transaction.

[0049] In summary, in the embodiments of the present application, first, analyze the first transaction constructed by assembly language in the verification platform to obtain the corresponding transaction attributes. Based on the transaction attributes, convert the first transaction into a byte stream, and call the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform. Then, construct the target language transaction attributes and interface files based on the transaction attributes, and call the communication interface of the verification platform to transmit the target language transaction attributes and interface files to the target platform. According to the interface files and the target language transaction attributes, the byte stream is parsed into the second transaction corresponding to the target language for display on the target platform. In the development environment of the target language, transaction information can be intuitively viewed and analyzed, which can reduce the learning threshold of the language, eliminate the need for frequent switching between different language environments, achieve cross-language interaction between the verification platform and the target platform, increase the applicable scenarios of the verification platform, and enhance the flexibility and scalability of the system.

[0050] Figure 2 is a specific step flowchart of a method for transmitting transactions in a circuit design file provided by an embodiment of the present application. As Figure 2 shown, the method may include:

[0051] Step 201, obtain the first transaction constructed by assembly language in the verification platform, and analyze the first transaction to obtain the corresponding first transaction attributes; the transaction attributes include: a transaction type field, a transaction address field, and a transaction data field.

[0052] This step may specifically refer to the above step 101 and will not be elaborated here.

[0053] Step 202, obtain the syntax tree corresponding to the first transaction.

[0054] Exemplarily, a syntax tree, also known as an abstract syntax tree, is an abstract representation of the syntax structure of assembly language code. It presents the syntax structure of the code in the form of a tree structure, where each node represents a syntax element in the source code, and the relationships between the nodes reflect the hierarchical and logical relationships between these syntax elements.

[0055] Exemplarily, obtaining the syntax tree of a transaction can help us perform operations such as code analysis and automated testing.

[0056] Step 203, traverse the syntax tree to obtain the first value corresponding to the transaction type field, the second value corresponding to the transaction address field, and the third value corresponding to the transaction data field.

[0057] Exemplarily, the transaction type field is used to identify the specific type of the transaction. In chip verification, database operations, or other systems involving transaction processing, different types of transactions may have different behaviors and processing logics. For example, in a memory access transaction, the transaction type may include read transactions, write transactions, etc.; in database operations, the transaction type may include insert, delete, update, etc. The transaction type field usually exists in the transaction data in the form of a certain encoding or identifier. The first numerical value refers to the value corresponding to the transaction type field parsed from the syntax tree. This value can be an integer, a string, or other data types, depending on the encoding method of the transaction type. For example, if the transaction type uses integer encoding, a read transaction is represented by 0 and a write transaction is represented by 1, then the first numerical value may be 0 or 1.

[0058] Exemplarily, the transaction address field is used to specify the address involved in the transaction operation. In a memory access transaction, the transaction address field represents the memory address to be accessed; in a network communication transaction, the transaction address field may represent the port number of the target device. The transaction address field is an important part of the transaction data, which determines the target location of the transaction operation. The second numerical value refers to the value corresponding to the transaction address field parsed from the syntax tree. This value is usually an integer or a string, depending on the representation method of the address. For example, in a memory access transaction, the second numerical value may be a hexadecimal memory address.

[0059] Exemplarily, the transaction data field contains the specific data involved in the transaction operation. In a memory write transaction, the transaction data field is the data to be written into the memory; in a database insert transaction, the transaction data field is the record to be inserted into the database. The content and format of the transaction data field depend on the type of the transaction and specific requirements. The transaction data field contains the specific data involved in the transaction operation. In a memory write transaction, the transaction data field is the data to be written into the memory; in a database insert transaction, the transaction data field is the record to be inserted into the database. The content and format of the transaction data field depend on the type of the transaction and specific requirements.

[0060] Optionally, step 203 may specifically include:

[0061] Sub-step 2031, traverse the syntax tree to find the nodes representing the transaction type, transaction address, and transaction data. Use the data corresponding to the transaction type node as the first numerical value, the data corresponding to the transaction address node as the second numerical value, and the data corresponding to the transaction data node as the third numerical value.

[0062] Exemplarily, traversing the syntax tree aims to accurately locate the nodes representing the transaction type, transaction address, and transaction data respectively. Once these key nodes are found, the data corresponding to each node is extracted and used as the first value, the second value, and the third value in sequence. These values are of great significance in transaction processing and analysis and can be used for subsequent logical judgments, data processing, and other operations.

[0063] Step 204: Convert the first value into the corresponding byte stream, convert the second value into the corresponding byte stream, and convert the third value into the corresponding byte stream.

[0064] Exemplarily, a memory write transaction is as follows: Transaction type: Write operation (1 byte); Transaction address: 0x1000 (4 bytes); Transaction data: 0x12345678 (4 bytes). Convert the transaction type to 0x01, the transaction address 0x1000 to 0x00 0x10 0x00 0x00, and the transaction data 0x12345678 to 0x12 0x34 0x56 0x78.

[0065] Step 205: Concatenate the byte stream corresponding to the first value, the byte stream corresponding to the second value, and the byte stream corresponding to the third value in the order of the transaction type field, the transaction address field, and the transaction data field to generate the byte stream.

[0066] Exemplarily, after generating the byte stream corresponding to the first value, the byte stream corresponding to the second value, and the byte stream corresponding to the third value, concatenate the byte stream corresponding to the first value, the byte stream corresponding to the second value, and the byte stream corresponding to the third value in the order of the transaction type field, the transaction address field, and the transaction data field to obtain the byte stream of this memory write transaction: 0x01 0x00 0x10 0x00 0x00 0x12 0x34 0x56 0x78.

[0067] Step 206: Based on the first transaction attribute, construct a target language transaction attribute and an interface file; the target language transaction attribute defines the transaction template corresponding to the transactions in the target language, and the target language is any one of multiple languages different from the assembly language.

[0068] This step can specifically refer to the above-mentioned step 102 and will not be elaborated here.

[0069] Optionally, the transaction attribute includes: a transaction type field, a transaction address field, and a transaction data field. Step 206 can specifically include:

[0070] Sub-step 2061: Construct a transaction class corresponding to the target language according to the target language.

[0071] Sub-step 2062: In the transaction class corresponding to the target language, generate a target transaction type field corresponding to the target language based on the transaction type field, generate a target transaction address field corresponding to the target language based on the transaction address field, and generate a target transaction data field corresponding to the target language based on the transaction data field;

[0072] Sub-step 2063: Construct a transaction template corresponding to the transaction in the target language based on the target transaction type field, the target transaction address field, and the target transaction data field, so as to obtain the transaction attributes of the target language.

[0073] Regarding Sub-steps 2061 - 2063, taking Python as the target language as an example, in the UVM transaction class, it includes: a transaction type field cmd, a transaction address field addr, and a transaction data field data. Generate the transaction attributes corresponding to Python based on the transaction type field cmd, the transaction address field addr, and the transaction data field data, that is, self.cmd, self.addr, and self.data.

[0074] Optionally, Step 206 may specifically further include:

[0075] Sub-step 2064: Obtain the byte stream corresponding to the transaction type field, the byte stream corresponding to the transaction address field, and the byte stream corresponding to the transaction data field from the byte stream;

[0076] Sub-step 2065: According to the method of parsing the byte stream into transaction attributes defined in the interface file, parse the byte stream corresponding to the transaction type field into the value corresponding to the target transaction type field, parse the byte stream corresponding to the transaction address field into the value corresponding to the target transaction address field, and parse the byte stream corresponding to the transaction data field into the value corresponding to the target transaction data field;

[0077] Sub-step 2066: After the parsing is completed, obtain the second transaction attribute corresponding to the target language.

[0078] For sub-step 2064 - sub-step 2066, taking the byte stream 0x01 0x00 0x10 0x00 0x00 0x12 0x34 0x56 0x78 as an example, the byte stream corresponding to the transaction type field is obtained as 0x01, the byte stream corresponding to the transaction address field is 0x00 0x10 0x00 0x00, and the byte stream corresponding to the transaction data field is 0x12 0x34 0x56 0x78. According to the method of parsing the byte stream into transaction attributes, the byte stream corresponding to the transaction type field, the byte stream corresponding to the transaction data field, and the byte stream corresponding to the transaction data field are parsed into the second transaction attributes corresponding to the target language.

[0079] Optionally, the transaction attributes include: a transaction type field, a transaction address field, and a transaction data field; the target platforms include: a compilation language platform and a target language platform; the first template file includes: a transaction class item; Step 206 may specifically further include:

[0080] Sub-step 2067, generating a compilation language transaction class corresponding to the compilation language platform according to the transaction type field, the transaction address field, and the transaction data field;

[0081] Sub-step 2068, obtaining a first template file that defines the basic structure of the interface file, and the compilation language transaction class name corresponding to the compilation language transaction class;

[0082] Sub-step 2069, replacing the placeholder corresponding to the transaction class item in the first template file with the compilation language transaction class name to generate the interface file.

[0083] For sub-step 2067 - sub-step 2069, taking the compilation language platform as the SystemC platform as an example, a compilation language transaction class corresponding to the SystemC platform is generated according to the transaction type field, the transaction address field, and the transaction data field included in the first transaction attribute in the UVM platform. An interface file is generated according to the first template file. Specifically, the placeholder class_name corresponding to the transaction class item in the first template file is replaced with the compilation language transaction class name my_transaction to obtain the interface file.

[0084] Optionally, Step 206 may specifically further include:

[0085] Sub-step 20610, obtaining the byte stream corresponding to the transaction type field, the byte stream corresponding to the transaction address field, and the byte stream corresponding to the transaction data field from the byte stream;

[0086] Sub-step 20611: Parse the byte streams corresponding to the transaction type field, the transaction address field, and the transaction data field respectively into transaction attributes according to the method of parsing the byte stream defined in the interface file, to obtain the second transaction attribute in the target language.

[0087] For sub-steps 20610 - 20611, taking the byte stream 0x01 0x00 0x10 0x00 0x00 0x12 0x34 0x56 0x78 as an example, the byte stream corresponding to the transaction type field is obtained as 0x01, the byte stream corresponding to the transaction address field is 0x00 0x10 0x00 0x00, and the byte stream corresponding to the transaction data field is 0x12 0x34 0x56 0x78. Parse the byte streams corresponding to the transaction type field, the transaction data field, and the transaction data field into the second transaction attribute in the target language according to the method of parsing the byte stream into transaction attributes.

[0088] Step 207: Call the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform, and call the communication interface of the verification platform to transmit the transaction attribute in the target language and the interface file to the target platform; the interface file defines the method of parsing the byte stream into transaction attributes.

[0089] This step can specifically refer to the above step 103 and will not be elaborated here.

[0090] Optionally, before step 207, the method further includes:

[0091] Step A1: Encapsulate the byte stream into a general transaction object.

[0092] Step 207 can specifically include:

[0093] Sub-step 2071: Call the transaction-level modeling interface of the verification platform to transmit the general transaction object to the target platform.

[0094] For step A1 and sub-step 2071, the general transaction object can be Generic Payload. As can be seen from the UVM source code, wherever the transaction type is involved in the interface and socket interface, the default type uvm_tlm_generic_payload is used. The base class of Generic payload is uvm_sequence_item, which can be regarded as a predefined transaction template that can be directly used for bus system modeling. Since the transaction is created for bus system modeling, the fields included in Generic Payload are basically related to the bus, such as address m_address, data, read / write m_command, burst length m_stream_width, byte mask m_byte_enable, response type m_response_status, etc. If there are more fields, such as memory attributes, security attributes, ID numbers, and other signals, they can be added by extending the m_extensions data structure.

[0095] Exemplarily, the transaction is parsed into a byte stream, encapsulated into Generic Payload, and transmitted through TLM, which can achieve transaction-level communication, and at the same time improve the reliability and efficiency of transmission.

[0096] Optionally, before step 207, the method further includes:

[0097] Step B1, generating a configuration file according to the first transaction attribute, and the communication interface is stored in the configuration file;

[0098] Step 207 may specifically further include:

[0099] Sub-step 2072, obtaining the socket interface of the verification platform from the configuration file, and calling the socket interface of the verification platform to transmit the target language transaction attribute and the interface file to the target platform.

[0100] For step B1 and sub-step 2072, a configuration file is generated according to the first transaction attribute. The socket interface information of the verification platform, including the IP address and port number, is extracted from the configuration file. The socket interface of the verification platform is called to transmit the target language transaction attribute and the interface file to the target platform. By storing the socket interface information in the configuration file, these information can be flexibly modified according to actual needs without modifying the code, which can improve the flexibility and configurability of the system.

[0101] Optionally, the configuration file includes: transaction name, verification platform interface, and compilation language platform interface; step B1 may specifically include:

[0102] Sub-step B11: Obtain a second template file that defines the basic structure of the configuration file;

[0103] Sub-step B12: Obtain the name of the class to which the first transaction attribute belongs, and verify the socket interfaces corresponding to the platform and the socket interfaces corresponding to the compilation language platform;

[0104] Sub-step B13: Replace the placeholder corresponding to the transaction name in the second template file with the name of the class to which the first transaction attribute belongs, replace the placeholder corresponding to the verification platform interface with the socket interface corresponding to the verification platform, and replace the placeholder corresponding to the compilation language platform interface with the socket interface corresponding to the compilation language platform;

[0105] Sub-step B14: After the replacement is completed, generate the configuration file.

[0106] For sub-steps B11 - B14, generate a configuration file according to the first transaction attribute and the second template file. Specifically, replace the placeholder class_name corresponding to the transaction name in the second template file with the name of the class my_transaction to which the first transaction attribute belongs, replace the placeholder corresponding to the verification platform interface with the socket interface uvm_tlm_port corresponding to the verification platform, and replace the placeholder corresponding to the compilation language platform interface with the socket interface systemc_tlm_port corresponding to the compilation language platform.

[0107] Step 208: According to the interface file and the target language transaction attribute, parse the received byte stream into a second transaction attribute through the target platform, import the second transaction attribute into the transaction template to obtain the second transaction corresponding to the target language, and display it.

[0108] This step can specifically refer to the above step 104 and will not be elaborated here.

[0109] Optionally, the method further includes:

[0110] Step 209: Generate target language wrapper code according to the interface file;

[0111] Step 2010: Use a compilation language compiler to compile the interface file and the target language wrapper code into a target language extension module to generate an extended interface file;

[0112] Step 208 may specifically include:

[0113] Sub-step 2081: According to the extended interface file and the target language transaction attributes, parse the received byte stream into second transaction attributes through the target platform.

[0114] Regarding steps 209 - 2010 and sub-step 2081, SWIG is a tool used to expose C / C++ code to other high-level languages such as Python, Java, etc. Taking the target language as Python and the compilation language as C / C++ as an example, SWIG tool is used to generate Python wrapper code, which is responsible for calling underlying C / C++ functions. Then, use the C / C++ compiler to compile the Python wrapper code and the interface file into a Python extension module, so that when importing the generated module in the Python language, the C / C++ functions can be directly called.

[0115] Exemplarily, through the SWIG tool, the interfaces of the compilation language platform can be exposed to high-level languages, so that SystemC modules can be used in a higher-level programming environment.

[0116] Optionally, the method further includes:

[0117] Step 211: In response to the processing operation of the target platform on the second transaction; obtain the third transaction obtained after processing, and analyze the third transaction to obtain the corresponding third transaction attributes;

[0118] Step 212: Based on the third transaction attributes, convert the third transaction into a byte stream;

[0119] Step 213: Call the transaction-level modeling interface of the target platform to transmit the byte stream to the verification platform, and call the communication interface of the target platform to transmit the interface file to the verification platform;

[0120] Step 214: According to the interface file, parse the byte stream into a fourth transaction corresponding to assembly language through the verification platform for display.

[0121] For steps 211 - 214, the processing operations of the target platform can be diverse, depending on the specific application scenario. For example, in a memory read / write simulation scenario, the target platform may perform corresponding read / write operations on the simulated memory according to the read / write requests in the second transaction and generate a third transaction containing the operation results. Analyze the third transaction in detail and extract its key attributes, such as transaction type, transaction address, transaction data, etc. Encode the attributes of the third transaction into a byte stream according to certain rules for transmission between different platforms. After the verification platform receives the interface file and the byte stream, parse the byte stream into the fourth transaction corresponding to the assembly language according to the rules of the interface file and display the parsing result. The transaction object in the target language can be converted into a byte stream, transmitted to the UVM environment via SystemC and UVMC, and restored to the original transaction object. Cross-language transaction transmission between UVM and high-level languages can be achieved.

[0122] In summary, in the embodiment of the present application, first, analyze the first transaction constructed by the assembly language in the verification platform to obtain the corresponding transaction attributes. Based on the transaction attributes, convert the first transaction into a byte stream, and call the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform. Then, construct the target language transaction attributes and the interface file based on the transaction attributes, and call the communication interface of the verification platform to transmit the target language transaction attributes and the interface file to the target platform, so as to parse the byte stream into the second transaction corresponding to the target language through the target platform according to the interface file and the target language transaction attributes for display. In the development environment of the target language, transaction information can be intuitively viewed and analyzed, which can lower the learning threshold of the language, eliminate the need for frequent switching between different language environments, achieve cross-language interaction between the verification platform and the target platform, increase the applicable scenarios of the verification platform, and enhance the flexibility and scalability of the system.

[0123] Figure 3 It is a schematic diagram of a processing flow from the hardware level to the multi-language level provided by the embodiment of the present application. The schematic diagram includes: the hardware level, the compiled language level, and the multi-language level. There are three input sources at the hardware level, namely the Universal Verification Methodology file, the Universal Verification Methodology compiled language header file, and the template file. Automatically parse the Universal Verification Methodology file to generate transactions, and generate a simplified wrapper interface generator through a code generator according to the transactions, the Universal Verification Methodology compiled language header file, and the template file. At the compiled language level, the transactions and the simplified wrapper interface generator are processed through a compiled language wrapper and then passed through a compiled language compiler to generate a wrapper library. At the multi-language level, expand the compiled language wrapper to obtain a language wrapper, and generate a software package from the language wrapper and the wrapper library. It presents a process that starts from hardware-related files, undergoes a series of processing and conversions, and finally generates a software package and realizes multi-language support.

[0124] Figure 4 It is a schematic diagram of the system architecture and data flow of a hardware verification and multi - language interaction provided by an embodiment of the present application, including two parts: component - to - component interaction and data flow. Among them, the main components in the component interaction part are the verification platform, the compilation language platform, and the target language platform. The verification platform and the compilation language platform communicate through the transaction - level modeling interface. The target language platform is obtained by extending the compilation language platform through a simplified encapsulation interface generator. Specifically, the compilation language platform generates wrappers for different languages through the simplified encapsulation interface generator, including Python wrappers, Java wrappers, and Go wrappers, corresponding to the Python language, the Java language, and the Go language respectively, so as to realize the interaction between different high - level languages and the underlying hardware verification module. In the data flow part, first, the first transaction is converted into a byte stream, and then the byte stream is encapsulated into a "general transaction object tlm_generic_payload". After parsing and reconstruction, the second transaction corresponding to the target language is generated. This process demonstrates the conversion of data between different formats to meet the processing requirements of different modules in the system. The purpose of this architecture diagram is to realize the interaction between the hardware verification module and multiple high - level programming languages through transaction - level modeling and multi - language wrappers, and details the flow and processing method of data in the system, which helps to improve the flexibility and efficiency of hardware design and verification.

[0125] Figure 5 It is a block diagram of a transaction transmission device 30 in a circuit design file provided by an embodiment of the present application. The device includes:

[0126] A first analysis module 301, configured to obtain a first transaction constructed by an assembly language in the verification platform, and analyze the first transaction to obtain the corresponding first transaction attribute;

[0127] A processing module 302, configured to convert the first transaction into a byte stream based on the first transaction attribute, and construct a target - language transaction attribute and an interface file; the target - language transaction attribute defines a transaction template corresponding to the transaction of the target language, and the target language is any one of multiple languages different from the assembly language;

[0128] A first transmission module 303, configured to call the transaction - level modeling interface of the verification platform to transmit the byte stream to the target platform, and call the communication interface of the verification platform to transmit the target - language transaction attribute and the interface file to the target platform; the interface file defines a method for parsing the byte stream into transaction attributes;

[0129] The first parsing module 304 is configured to parse the received byte stream into second transaction attributes through the target platform according to the interface file and the target language transaction attributes, import the second transaction attributes into the transaction template to obtain the second transaction corresponding to the target language, and perform display.

[0130] Optionally, the transaction attributes include: a transaction type field, a transaction address field, and a transaction data field;

[0131] The processing module includes:

[0132] The first acquisition sub-module is configured to acquire the syntax tree corresponding to the first transaction;

[0133] The second acquisition sub-module is configured to traverse the syntax tree to acquire a first value corresponding to the transaction type field, a second value corresponding to the transaction address field, and a third value corresponding to the transaction data field;

[0134] The conversion sub-module is configured to convert the first value into a corresponding byte stream, the second value into a corresponding byte stream, and the third value into a corresponding byte stream;

[0135] The first generation sub-module is configured to splice the byte stream corresponding to the first value, the byte stream corresponding to the second value, and the byte stream corresponding to the third value in the order of the transaction type field, the transaction address field, and the transaction data field to generate the byte stream.

[0136] Optionally, the second acquisition sub-module includes:

[0137] The determination unit is configured to traverse the syntax tree to find the nodes representing the transaction type node, the transaction address node, and the transaction data node, and use the data corresponding to the transaction type node as the first value, the data corresponding to the transaction address node as the second value, and the data corresponding to the transaction data node as the third value.

[0138] Optionally, the device further includes:

[0139] The encapsulation module is configured to encapsulate the byte stream into a general transaction object;

[0140] The first transmission module includes:

[0141] The first transmission sub-module is configured to call the transaction-level modeling interface of the verification platform to transmit the general transaction object to the target platform.

[0142] Optionally, the transaction attributes include: a transaction type field, a transaction address field, and a transaction data field;

[0143] The processing module includes:

[0144] A first construction sub-module for constructing a transaction class corresponding to the target language according to the target language;

[0145] A second generation sub-module for generating a target transaction type field corresponding to the target language, a target transaction address field corresponding to the target language, and a target transaction data field corresponding to the target language in the transaction class corresponding to the target language according to the transaction type field, the transaction address field, and the transaction data field;

[0146] A second construction sub-module for constructing a transaction template corresponding to the transaction in the target language according to the target transaction type field, the target transaction address field, and the target transaction data field, so as to obtain the target language transaction attribute.

[0147] Optionally, the first parsing module includes:

[0148] A third acquisition sub-module for acquiring the byte stream corresponding to the transaction type field, the byte stream corresponding to the transaction address field, and the byte stream corresponding to the transaction data field from the byte stream;

[0149] A first parsing sub-module for parsing the byte stream corresponding to the transaction type field into the value corresponding to the target transaction type field, the byte stream corresponding to the transaction address field into the value corresponding to the target transaction address field, and the byte stream corresponding to the transaction data field into the value corresponding to the target transaction data field according to the method of parsing the byte stream defined in the interface file into transaction attributes;

[0150] A third generation sub-module for obtaining the second transaction attribute corresponding to the target language after the parsing is completed.

[0151] Optionally, the transaction attribute includes: a transaction type field, a transaction address field, and a transaction data field; the target platform includes: a compilation language platform and a target language platform; the first template file includes: transaction class items;

[0152] The processing module includes:

[0153] A fourth generation sub-module for generating a compilation language transaction class corresponding to the compilation language platform according to the transaction type field, the transaction address field, and the transaction data field;

[0154] A fourth acquisition sub-module for acquiring a first template file defining the basic structure of the interface file, and the name of the compilation language transaction class corresponding to the compilation language transaction class;

[0155] A first generation sub-module, configured to replace placeholders corresponding to transaction items in the first template file with the compiled language transaction class names, and generate the interface file.

[0156] Optionally, the first parsing module includes:

[0157] A fifth acquisition sub-module, configured to acquire the byte stream corresponding to the transaction type field, the byte stream corresponding to the transaction address field, and the byte stream corresponding to the transaction data field from the byte stream;

[0158] A second parsing sub-module, configured to parse the byte stream corresponding to the transaction type field, the byte stream corresponding to the transaction address field, and the byte stream corresponding to the transaction data field respectively according to the method of parsing the byte stream defined in the interface file into transaction attributes, and obtain the second transaction attributes in the target language.

[0159] Optionally, the apparatus further includes:

[0160] A first generation module, configured to generate a configuration file according to the first transaction attributes, and the communication interface is stored in the configuration file;

[0161] The first transmission module includes:

[0162] A second transmission sub-module, configured to acquire the socket interface of the verification platform from the configuration file, and call the socket interface of the verification platform to transmit the target language transaction attributes and the interface file to the target platform.

[0163] Optionally, the configuration file includes: transaction name, verification platform interface, and compiled language platform interface; the generation module includes:

[0164] A sixth acquisition sub-module, configured to acquire a second template file that defines the basic structure of the configuration file;

[0165] A seventh acquisition sub-module, configured to acquire the name of the class to which the first transaction attributes belong, the socket interface corresponding to the verification platform, and the socket interface corresponding to the compiled language platform;

[0166] A replacement sub-module, configured to replace the placeholder corresponding to the transaction name in the second template file with the name of the class to which the first transaction attributes belong, replace the placeholder corresponding to the verification platform interface with the socket interface corresponding to the verification platform, and replace the placeholder corresponding to the compiled language platform interface with the socket interface corresponding to the compiled language platform;

[0167] A second generation sub-module, configured to generate the configuration file after the replacement is completed.

[0168] Optionally, the device further includes:

[0169] A second generation module, configured to generate target language wrapper code according to the interface file;

[0170] A third generation module, configured to use a compiled language compiler to compile the interface file and the target language wrapper code into a target language extension module, and generate an extended interface file;

[0171] The first parsing module includes:

[0172] A third parsing sub-module, configured to parse the received byte stream into a second transaction attribute through the target platform according to the extended interface file and the target language transaction attribute.

[0173] Optionally, the device further includes:

[0174] A second analysis module, configured to respond to a processing operation of the target platform on the second transaction; obtain a third transaction obtained after processing, and analyze the third transaction to obtain a corresponding third transaction attribute;

[0175] A conversion module, configured to convert the third transaction into a byte stream based on the third transaction attribute;

[0176] A second transmission module, configured to call a transaction-level modeling interface of the target platform to transmit the byte stream to the verification platform, and call a communication interface of the target platform to transmit the interface file to the verification platform;

[0177] A second parsing module, configured to parse the byte stream into a fourth transaction corresponding to an assembly language through the verification platform according to the interface file for display.

[0178] In summary, in the embodiment of the present application, first, analyze the first transaction constructed by the assembly language in the verification platform to obtain the corresponding transaction attribute, based on the transaction attribute, convert the first transaction into a byte stream, and call the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform. Then, construct the target language transaction attribute and the interface file based on the transaction attribute, and call the communication interface of the verification platform to transmit the target language transaction attribute and the interface file to the target platform, so as to parse the byte stream into a second transaction corresponding to the target language through the target platform for display. In the development environment of the target language, transaction information can be intuitively viewed and analyzed, the learning threshold of the language can be reduced, there is no need to frequently switch between different language environments, cross-language interaction between the verification platform and the target platform can be realized, the applicable scenarios of the verification platform are increased, and the flexibility and scalability of the system are enhanced.

[0179] For the apparatus embodiments, since they are basically similar to the method embodiments, the description is relatively simple. For related parts, please refer to the corresponding descriptions in the method embodiments.

[0180] Each embodiment in this specification is described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the embodiments, reference can be made to each other.

[0181] Regarding the apparatus in the above embodiments, the specific manners in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0182] The embodiments of the present application provide a transmission apparatus for transactions in a circuit design file, including a memory and more than one program. The more than one program is stored in the memory and is configured to be executed by more than one processor. The more than one program includes instructions for performing the methods described in the above one or more embodiments.

[0183] Figure 6 FIG. is a block diagram of an electronic device 400 provided by an embodiment of the present application. For example, the electronic device 400 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0184] Referring to Figure 6 , the electronic device 400 may include one or more of the following components: a processing component 402, a memory 404, a power component 406, a multimedia component 408, an audio component 410, an input / output (I / O) interface 412, a sensor component 414, and a communication component 416.

[0185] The processing component 402 generally controls the overall operation of the electronic device 400, such as operations associated with display, telephone calls, data communication, camera operations, and recording operations. The processing component 402 may include one or more processors 420 to execute instructions to complete all or part of the steps of the above methods. In addition, the processing component 402 may include one or more modules to facilitate the interaction between the processing component 402 and other components. For example, the processing component 402 may include a multimedia module to facilitate the interaction between the multimedia component 408 and the processing component 402.

[0186] The memory 404 is used to store various types of data to support the operation of the electronic device 400. Examples of such data include instructions for any application or method operating on the electronic device 400, contact data, phone book data, messages, pictures, multimedia, and the like. The memory 404 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0187] The power supply component 406 provides power to various components of the electronic device 400. The power supply component 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the electronic device 400.

[0188] The multimedia component 408 includes a screen that provides an output interface between the electronic device 400 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can not only sense the boundaries of touch or swipe actions but also detect the duration and pressure associated with the touch or swipe operation. In some embodiments, the multimedia component 408 includes a front camera and / or a rear camera. When the electronic device 400 is in an operating mode, such as a shooting mode or a multimedia mode, the front camera and / or the rear camera can receive external multimedia data. Each of the front camera and the rear camera can be a fixed optical lens system or have a focal length and optical zoom capabilities.

[0189] The audio component 410 is used to output and / or input audio signals. For example, the audio component 410 includes a microphone (MIC) that is used to receive external audio signals when the electronic device 400 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory 404 or transmitted via the communication component 416. In some embodiments, the audio component 410 further includes a speaker for outputting audio signals.

[0190] The input / output interface 412 provides an interface between the processing component 402 and a peripheral interface module, which can be a keyboard, a click wheel, buttons, etc. These buttons can include, but are not limited to: a home button, a volume button, a power-on button, and a lock button.

[0191] The sensor assembly 414 includes one or more sensors for providing an assessment of various aspects of the status of the electronic device 400. For example, the sensor assembly 414 can detect the on / off state of the electronic device 400, the relative positioning of components, such as the display and keypad of the electronic device 400. The sensor assembly 414 can also detect a change in the position of the electronic device 400 or a component of the electronic device 400, the presence or absence of user contact with the electronic device 400, the orientation or acceleration / deceleration of the electronic device 400, and the temperature change of the electronic device 400. The sensor assembly 414 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 414 can also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 414 can also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0192] The communication component 416 is used to facilitate communication between the electronic device 400 and other devices in a wired or wireless manner. The electronic device 400 can access a wireless network based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or a combination thereof. In an exemplary embodiment, the communication component 416 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 416 further includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0193] In an exemplary embodiment, the electronic device 400 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for implementing the methods provided in the embodiments of the present application.

[0194] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 404 including instructions, and the above instructions can be executed by a processor 420 of the electronic device 400 to complete the above methods. For example, the non-transitory storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device, etc.

[0195] Figure 7It is a block diagram of another electronic device 500 provided by an embodiment of the present application. For example, the electronic device 500 may be provided as a server. Referring to Figure 7 , the electronic device 500 includes a processing component 522, which further includes one or more processors, and memory resources represented by a memory 532 for storing instructions executable by the processing component 522, such as application programs. The application programs stored in the memory 532 may include one or more modules each corresponding to a set of instructions. In addition, the processing component 522 is configured to execute instructions to perform the method provided by the embodiments of the present application.

[0196] The electronic device 500 may also include a power component 526 configured to perform power management of the electronic device 500, a wired or wireless network interface 550 configured to connect the electronic device 500 to a network, and an input / output interface 558. The electronic device 500 may operate based on an operating system stored in the memory 532, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSD TM or the like.

[0197] The embodiments of the present application also provide a computer program product, including a computer program, which when executed by a processor implements the method described in the above embodiments.

[0198] Those skilled in the art will readily conceive of other implementations of the present application after considering the specification and practicing the application disclosed herein. The present application is intended to cover any variations, uses, or adaptations of the present application, which follow the general principles of the present application and include known common knowledge or conventional technical means in the technical field not disclosed in the present disclosure. The specification and embodiments are only to be considered as exemplary, and the true scope and spirit of the present application are pointed out by the following claims.

[0199] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present application is only limited by the appended claims.

Claims

1. A method for transmitting transactions in a circuit design file, characterized in that: The method comprises: Acquire a first transaction constructed in an assembly language in a verification platform, and analyze the first transaction to obtain a corresponding first transaction attribute; Based on the first transaction attribute, convert the first transaction into a byte stream, and construct a target language transaction attribute and an interface file; the target language transaction attribute defines a transaction template corresponding to a transaction in a target language, and the target language is any one of a plurality of languages ​​different from the assembly language; Calling the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform, and calling the communication interface of the verification platform to transmit the target language transaction attributes and the interface file to the target platform; the interface file defines a method for parsing the byte stream into transaction attributes; According to the interface file and the target language transaction attribute, the received byte stream is parsed into a second transaction attribute through the target platform, and the second transaction attribute is imported into the transaction template to obtain a second transaction corresponding to the target language and display it.

2. The method according to claim 1, characterized in that The transaction attributes include: a transaction type field, a transaction address field, and a transaction data field; The converting the first transaction into a byte stream based on the first transaction attribute includes: Obtaining a syntax tree corresponding to the first transaction; Traversing the syntax tree, obtaining a first value corresponding to the transaction type field, a second value corresponding to the transaction address field, and a third value corresponding to the transaction data field; Convert the first value into a corresponding byte stream, convert the second value into a corresponding byte stream, and convert the third value into a corresponding byte stream; In the order of the transaction type field, the transaction address field and the transaction data field, the byte stream corresponding to the first value, the byte stream corresponding to the second value and the byte stream corresponding to the third value are concatenated to generate the byte stream.

3. The method according to claim 2, characterized in that The traversing the syntax tree to obtain a first value corresponding to the transaction type field, a second value corresponding to the transaction address field, and a third value corresponding to the transaction data field includes: Traverse the syntax tree to find nodes representing transaction types, transaction address nodes, and transaction data nodes, and use data corresponding to the transaction type nodes as the first value, data corresponding to the transaction address nodes as the second value, and data corresponding to the transaction data nodes as the third value.

4. The method according to claim 1, characterized in that: Before calling the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform, the method further includes: Encapsulating the byte stream into a general transaction object; The calling of the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform includes: The transaction level modeling interface of the verification platform is called to transmit the general transaction object to the target platform.

5. The method according to claim 1, characterized in that The transaction attributes include: a transaction type field, a transaction address field, and a transaction data field; The step of constructing a target language transaction attribute based on the first transaction attribute includes: Constructing a transaction class corresponding to the target language according to the target language; In the transaction class corresponding to the target language, a target transaction type field corresponding to the target language is generated according to the transaction type field, a target transaction address field corresponding to the target language is generated according to the transaction address field, and a target transaction data field corresponding to the target language is generated according to the transaction data field; A transaction template corresponding to the transaction in the target language is constructed according to the target transaction type field, the target transaction address field, and the target transaction data field, thereby obtaining the target language transaction attribute.

6. The method according to claim 5, characterized in that The step of parsing the received byte stream into a second transaction attribute through the target platform according to the interface file and the target language transaction attribute includes: Acquire from the byte stream a byte stream corresponding to the transaction type field, a byte stream corresponding to the transaction address field, and a byte stream corresponding to the transaction data field; According to the method of parsing byte streams into transaction attributes defined in the interface file, the byte stream corresponding to the transaction type field is parsed into a value corresponding to the target transaction type field, the byte stream corresponding to the transaction address field is parsed into a value corresponding to the target transaction address field, and the byte stream corresponding to the transaction data field is parsed into a value corresponding to the target transaction data field; After the parsing is completed, the second transaction attribute corresponding to the target language is obtained.

7. The method according to claim 1, characterized in that The transaction attributes include: a transaction type field, a transaction address field, and a transaction data field; the target platform includes: a compiled language platform and a target language platform; the first template file includes: a transaction class item; The constructing an interface file based on the first transaction attribute includes: Generate a compiled language transaction class corresponding to the compiled language platform according to the transaction type field, the transaction address field, and the transaction data field; Acquire a first template file defining a basic structure of an interface file and a compiled language transaction class name corresponding to the compiled language transaction class; The placeholder corresponding to the transaction class item in the first template file is replaced with the compiled language transaction class name to generate the interface file.

8. The method according to claim 7, characterized in that The step of parsing the received byte stream into a second transaction attribute through the target platform according to the interface file and the target language transaction attribute includes: Acquire from the byte stream a byte stream corresponding to the transaction type field, a byte stream corresponding to the transaction address field, and a byte stream corresponding to the transaction data field; According to the method of parsing the byte stream into transaction attributes defined in the interface file, the byte stream corresponding to the transaction type field, the byte stream corresponding to the transaction address field, and the byte stream corresponding to the transaction data field are parsed respectively to obtain the second transaction attributes corresponding to the target language.

9. The method according to claim 1, characterized in that: Before calling the communication interface of the verification platform to transmit the target language transaction attribute and the interface file to the target platform, the method further includes: Generate a configuration file according to the first transaction attribute, wherein the communication interface is stored in the configuration file; The calling of the communication interface of the verification platform to transmit the target language transaction attribute and the interface file to the target platform includes: The socket interface of the verification platform is obtained from the configuration file, and the socket interface of the verification platform is called to transmit the target language transaction attribute and the interface file to the target platform.

10. The method according to claim 9, characterized in that The configuration file includes: a transaction name, a verification platform interface, and a compilation language platform interface; the configuration file is generated according to the first transaction attribute, including: Obtaining a second template file defining a basic structure of a configuration file; Obtaining the name of the class to which the first transaction attribute belongs, and verifying the socket interface corresponding to the platform and the socket interface corresponding to the compiled language platform; Replace the placeholder corresponding to the transaction name in the second template file with the name of the class to which the first transaction attribute belongs, replace the placeholder corresponding to the verification platform interface with the socket interface corresponding to the verification platform, and replace the placeholder corresponding to the compilation language platform interface with the socket interface corresponding to the compilation language platform; After the replacement is completed, the configuration file is generated.

11. The method according to claim 1, characterized in that: The method further comprises: Generate target language packaging code according to the interface file; Compile the interface file and the target language packaging code into a target language extension module using a compiled language compiler to generate an extended interface file; The step of parsing the received byte stream into a second transaction attribute through the target platform according to the interface file and the target language transaction attribute includes: According to the extended interface file and the target language transaction attribute, the received byte stream is parsed into a second transaction attribute through the target platform.

12. The method according to claim 1, characterized in that The method further comprises: In response to the target platform's processing operation on the second transaction, obtaining a third transaction obtained after the processing, and analyzing the third transaction to obtain a corresponding third transaction attribute; Based on the third transaction attribute, converting the third transaction into a byte stream; Calling the transaction-level modeling interface of the target platform to transmit the byte stream to the verification platform, and calling the communication interface of the target platform to transmit the interface file to the verification platform; According to the interface file, the verification platform parses the byte stream into a fourth transaction corresponding to the assembly language for display.

13. A device for transmitting transactions in a circuit design file, characterized in that: The device comprises: A first analysis module, configured to obtain a first transaction constructed in an assembly language in a verification platform, and analyze the first transaction to obtain a corresponding first transaction attribute; a processing module, configured to convert the first transaction into a byte stream based on the first transaction attribute, and construct a target language transaction attribute and an interface file; the target language transaction attribute defines a transaction template corresponding to a transaction in a target language, and the target language is any one of a plurality of languages ​​different from the assembly language; A first transmission module is used to call the transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform, and to call the communication interface of the verification platform to transmit the target language transaction attributes and the interface file to the target platform; the interface file defines a method for parsing a byte stream into transaction attributes; The first parsing module is used to parse the received byte stream into a second transaction attribute through the target platform according to the interface file and the target language transaction attribute, and import the second transaction attribute into the transaction template to obtain a second transaction corresponding to the target language and display it.

14. An electronic device, characterized in that: The invention comprises a processor, a memory and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements the steps of the method for transmitting a transaction in a circuit design file as described in any one of claims 1 to 12.

15. A readable storage medium, characterized in that: The readable storage medium stores a program or an instruction, and when the program or the instruction is executed by a processor, the steps of the method for transmitting a transaction in a circuit design file according to any one of claims 1 to 12 are implemented.

Images