Transaction transmission method and device in circuit design file, equipment and storage medium

Abstract

The invention provides a transmission method and device for transactions in a circuit design file, electronic equipment and a readable storage medium, and the method comprises the steps: obtaining a first transaction constructed by an assembly language in a verification platform, analyzing the first transaction to obtain a corresponding first transaction attribute, converting the first transaction into a byte stream based on the first transaction attribute, and storing the byte stream in a verification platform; constructing a target language transaction attribute and an interface file, calling a transaction-level modeling interface of the verification platform to transmit the byte stream to the target platform, calling a communication interface of the verification platform to transmit the target language transaction attribute and the interface file to the target platform, and verifying the target language transaction attribute according to the interface file and the target language transaction attribute. The received byte stream is analyzed into the second transaction attribute through the target platform, the second transaction attribute is imported into the transaction template, the second transaction corresponding to the target language is obtained and displayed, the target language is used for verification, the language learning difficulty can be reduced, and the application scene of the verification platform is widened.

Description

Technical Field

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

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

[0003] 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 the verification environment to ensure that the verification environment is modular and reusable.

[0004] However, UVM is based on SystemVerilog language, which has a high learning threshold. Currently, there is UVMC that can connect SystemC language with UVM environment, but its function is limited to supporting SystemC language and has few applicable scenarios. Summary of the invention

[0005] The embodiments of the present application provide a method, device, electronic device and computer-readable storage medium for transmitting transactions in a circuit design file to solve the problems in the related art.

[0006] In a first aspect, an embodiment of the present application provides a method for transmitting a transaction in a circuit design file, the method comprising: 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.

[0007] In a second aspect, an embodiment of the present application provides a device for transmitting transactions in a circuit design file, the device comprising: 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.

[0008] In a third aspect, an embodiment of the present application further provides an electronic device, including a processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method of the first aspect.

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

[0010] In the embodiment of the present application, first, the first transaction constructed by the assembly language in the verification platform is analyzed to obtain the corresponding transaction attributes, and based on the transaction attributes, the first transaction is converted into a byte stream, and the transaction-level modeling interface of the verification platform is called to transmit the byte stream to the target platform. Then, based on the transaction attributes, the target language transaction attributes and interface files are constructed, and the communication interface of the verification platform is called to transmit the target language transaction attributes and interface files to the target platform, so that according to the interface file and the target language transaction attributes, the byte stream is parsed by the target platform into the second transaction corresponding to the target language for display, and the transaction information can be intuitively viewed and analyzed in the development environment of the target language, which can reduce the learning threshold of the language, and 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, which increases the applicable scenarios of the verification platform and enhances the flexibility and scalability of the system.

[0011] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0013] Figure 1 It is a flowchart of the steps of a method for transmitting a transaction in a circuit design file provided in an embodiment of the present application; Figure 2 It is a flowchart of the specific steps of a method for transmitting a transaction in a circuit design file provided in an embodiment of the present application; Figure 3 It is a schematic diagram of a processing flow from the hardware level to the multi-language level provided in an embodiment of the present application; Figure 4 It is a schematic diagram of a system architecture and data flow of hardware verification and multi-language interaction provided by an embodiment of the present application; Figure 5 This is a block diagram of a transmission device for a transaction in a circuit design file provided in an embodiment of the present application; Figure 6 is a block diagram of an electronic device provided in an embodiment of the present application; Figure 7 It is a block diagram of another electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0015] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally a class, 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 kinds of relationships can exist, for example, A and / or B can be represented: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the front and back associated objects are a kind of "or" relationship. In the embodiment of the present application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0016] Figure 1 is a flowchart of a method for transmitting a transaction in a circuit design file provided by an embodiment of the present application, such as Figure 1 As shown, the method may include: Step 101: 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.

[0017] For example, a verification platform is a software environment used to verify the correctness of a hardware design. It provides a series of tools and mechanisms for generating stimuli, monitoring the response of the design, and checking whether the design meets the expected functional specifications. The verification platform usually contains transaction-level modeling interfaces, communication interfaces, etc., which can simulate the behavior of the hardware system and perform comprehensive verification of the design. For example, when verifying a central processing unit (CPU) design, the verification platform can simulate different instruction sequences as stimuli and send them to the CPU for execution, while monitoring the CPU's output results and comparing them with the expected results to ensure that the CPU functions correctly.

[0018] For example, assembly language refers to the language used to build transactions in the testbench. The assembly language can be SystemVerilog, and each assembly instruction corresponds to one or more machine instructions. In the testbench, some specific transactions may be written in assembly language to more precisely control the behavior of the hardware.

[0019] For example, a transaction is a transaction built in assembly language in the verification platform. Transaction is a basic concept in the verification platform, which represents a sequence of operations with a specific function or behavior. In hardware verification, a transaction can be a memory read or 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.

[0020] For example, transaction attributes are a set of parameters that describe transaction characteristics and behaviors. These attributes may include transaction types, such as read transactions, write transactions, etc., transaction addresses, transaction data, etc. By analyzing transaction attributes, the behavior and intent of a transaction can be better understood, leading to more effective verification. For example, transaction attributes may include: transaction type: read transaction, transaction address: 0x1000, transaction data: 0x12345678.

[0021] For example, by parsing the UVM transaction file specified by the user, the corresponding transaction attributes are obtained. For example, the tool is used to read the UVM transaction file, and the parser is used to parse it to extract the name of the transaction class, the transaction type, the transaction address, the transaction data and other information. Specifically, the tool will parse the name of the transaction class as my_transaction, the transaction type as cmd, the transaction address as addr, and the transaction data as data.

[0022] 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 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.

[0023] For example, in chip verification, 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 the byte stream can represent any type of data, such as integers, floating point numbers, strings, images, audio, etc. Byte stream is the basic form of data transmission and storage between hardware and software. For example, a memory write transaction is: transaction type: write operation (1 byte), transaction address: 0x1000 (4 bytes), transaction data: 0x12345678 (4 bytes), the transaction type is converted to 0x01, the transaction address 0x1000 is converted to 0x00 0x10 0x00 0x00, and the transaction data 0x12345678 is converted to 0x12 0x34 0x56 0x78, then the memory write transaction is converted to a byte stream: 0x01 0x000x10 0x00 0x00 0x12 0x34 0x56 0x78. By parsing transactions into byte streams, the data flow in actual hardware can be simulated and efficient system-level verification can be supported.

[0024] For example, the target language refers to the language to be used after the first transaction is converted. It can be any of a variety of programming languages, such as Python, Java, C++, etc. Different target languages ​​have different syntax 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 Python's syntax and specifications.

[0025] For example, the target language transaction attribute defines the attribute template corresponding to the transaction in the target language. It describes the data structure and attribute type of the transaction in the target language, similar to the definition of a class. Through this template, you can create a transaction object in the target language and operate on its attributes.

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

[0027] Step 103, 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 a byte stream into transaction attributes.

[0028] For example, the transaction level modeling (TLM) interface originated from a transaction level communication standard of SystemC. The so-called transaction level refers to the communication at the signal line level between modules in the Design under Test (DUT). Simply put, a transaction is a class that encapsulates a group of information with a specific function. In this way, the communication frequency can be reduced to reduce the resource loss 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.

[0029] For example, the communication interface is an interface in the verification platform for data transmission 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 a socket interface for processing, and the processing results are returned to the UVM verification platform through the socket interface for verification.

[0030] Step 104: 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.

[0031] For example, taking the target platform as the Python platform, after the Python platform receives the interface file and the target language transaction attribute, the interface file is read and parsed 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 corresponding data types to obtain the second transaction attribute. Finally, the attribute value in the second transaction attribute is assigned to the instance of the transaction template class to create the second transaction.

[0032] In summary, in the embodiment of the present application, first, the first transaction constructed by the assembly language in the verification platform is analyzed to obtain the corresponding transaction attributes, and based on the transaction attributes, the first transaction is converted into a byte stream, and the transaction-level modeling interface of the verification platform is called to transmit the byte stream to the target platform. Then, based on the transaction attributes, the target language transaction attributes and interface files are constructed, and the communication interface of the verification platform is called to transmit the target language transaction attributes and interface files to the target platform, so that according to the interface file and the target language transaction attributes, the byte stream is parsed through the target platform into the second transaction corresponding to the target language for display, and the transaction information can be intuitively viewed and analyzed in the development environment of the target language, which can reduce the learning threshold of the language, and there is no need to frequently switch between different language environments. Cross-language interaction between the verification platform and the target platform can be achieved, which increases the applicable scenarios of the verification platform and enhances the flexibility and scalability of the system.

[0033] Figure 2 is a flowchart of the specific steps of a method for transmitting a transaction in a circuit design file provided in an embodiment of the present application, such as Figure 2 As shown, the method may include: Step 201, obtaining a first transaction constructed by assembly language in a verification platform, and analyzing the first transaction to obtain a corresponding first transaction attribute; the transaction attribute includes: a transaction type field, a transaction address field, and a transaction data field.

[0034] This step may specifically refer to the above step 101, and will not be described in detail here.

[0035] Step 202: Obtain a syntax tree corresponding to the first transaction.

[0036] For example, 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 relationship between the nodes reflects the hierarchical and logical relationship between these syntax elements.

[0037] For example, obtaining the syntax tree of a transaction can help us perform code analysis, automated testing, and other operations.

[0038] Step 203, traverse 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.

[0039] For example, the transaction type field is used to identify the specific type of transaction. In chip verification, database operations, or other systems involving transaction processing, different types of transactions may have different behaviors and processing logic. For example, in memory access transactions, transaction types may include read transactions, write transactions, etc.; in database operations, transaction types may include inserts, deletes, updates, etc. The transaction type field usually exists in the transaction data in the form of some encoding or identification. 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 type, depending on how the transaction type is encoded. For example, if the transaction type is encoded using an integer, read transactions are represented by 0, and write transactions are represented by 1, then the first numerical value may be 0 or 1.

[0040] For example, the transaction address field is used to specify the address involved in the transaction operation. In a memory access transaction, the transaction address field indicates the memory address to be accessed; in a network communication transaction, the transaction address field may indicate 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 how the address is represented. For example, in a memory access transaction, the second numerical value may be a hexadecimal memory address.

[0041] For example, 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 to 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 and specific requirements of the transaction. 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 to 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 and specific requirements of the transaction.

[0042] Optionally, step 203 may specifically include: Sub-step 2031, traverse the syntax tree, find nodes representing transaction type, transaction address nodes and transaction data nodes, 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.

[0043] For example, the syntax tree is traversed to accurately locate the nodes representing the transaction type, transaction address, and transaction data. 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 turn. These values ​​are of great significance in transaction processing and analysis, and can be used for subsequent logical judgment, data processing, and other operations.

[0044] Step 204: 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.

[0045] For example, a memory write transaction is: transaction type: write operation (1 byte); transaction address: 0x1000 (4 bytes); transaction data: 0x12345678 (4 bytes). The transaction type is converted to 0x01, the transaction address 0x1000 is converted to 0x000x10 0x00 0x00, and the transaction data 0x12345678 is converted to 0x12 0x34 0x56 0x78.

[0046] Step 205, in the order of the transaction type field, the transaction address field and the transaction data field, 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 to generate the byte stream.

[0047] For example, after generating the byte stream corresponding to the first numerical value, the byte stream corresponding to the second numerical value, and the byte stream corresponding to the third numerical value, the byte stream corresponding to the first numerical value, and the byte stream corresponding to the third numerical value are concatenated in the order of the transaction type field, the transaction address field, and the transaction data field to obtain the byte stream of the memory write transaction: 0x01 0x00 0x10 0x00 0x00 0x12 0x34 0x56 0x78.

[0048] Step 206, constructing a target language transaction attribute and an interface file based on the first transaction attribute; 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 a plurality of languages ​​different from the assembly language.

[0049] This step may be specifically referred to as the above step 102, and will not be described in detail here.

[0050] Optionally, the transaction attributes include: a transaction type field, a transaction address field, and a transaction data field. Step 206 may specifically include: Sub-step 2061, constructing a transaction class corresponding to the target language according to the target language; Sub-step 2062, in the transaction class corresponding to the target language, generating a target transaction type field corresponding to the target language according to the transaction type field, generating a target transaction address field corresponding to the target language according to the transaction address field, and generating a target transaction data field corresponding to the target language according to the transaction data field; Sub-step 2063: 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, thereby obtaining the target language transaction attribute.

[0051] For sub-steps 2061 to 2063, taking Python as the target language, the UVM transaction class includes: a transaction type field cmd, a transaction address field addr, and a transaction data field data. According to the transaction type field cmd, the transaction address field addr, and the transaction data field data, the transaction attributes corresponding to Python are generated, namely, self.cmd, self.addr, and self.data.

[0052] Optionally, step 206 may further include: Sub-step 2064, obtaining 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; Sub-step 2065, according to the method of parsing byte stream into transaction attributes defined in the interface file, parse the byte stream corresponding to the transaction type field into a value corresponding to the target transaction type field, parse the byte stream corresponding to the transaction address field into a value corresponding to the target transaction address field, and parse the byte stream corresponding to the transaction data field into a value corresponding to the target transaction data field; Sub-step 2066, after the parsing is completed, obtaining the second transaction attribute corresponding to the target language.

[0053] For sub-steps 2064 to 2066, taking the byte stream of 0x01 0x00 0x10 0x00 0x00 0x12 0x34 0x56 0x78 as an example, the byte stream corresponding to the transaction type field is 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 byte streams 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 attribute corresponding to the target language.

[0054] Optionally, 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; step 206 may further include: Sub-step 2067, generating 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; Sub-step 2068, obtaining 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; Sub-step 2069, replacing the placeholder corresponding to the transaction class item in the first template file with the compiled language transaction class name to generate the interface file.

[0055] For sub-steps 2067 to 2069, taking the compiled language platform as the SystemC platform as an example, a compiled 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 compiled language transaction class name my_transaction to obtain an interface file.

[0056] Optionally, step 206 may further include: Sub-step 20610, obtaining 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; Sub-step 20611, according to the method of parsing byte streams into transaction attributes defined in the interface file, 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 to obtain the second transaction attributes corresponding to the target language.

[0057] For sub-steps 20610-20611, taking the byte stream of 0x01 0x00 0x10 0x00 0x00 0x12 0x34 0x56 0x78 as an example, the byte stream corresponding to the transaction type field is 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 byte streams 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 attribute corresponding to the target language.

[0058] Step 207, 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 the method of parsing the byte stream into transaction attributes.

[0059] This step may be specifically referred to as the above step 103, and will not be described in detail here.

[0060] Optionally, before step 207, the method further includes: Step A1, encapsulating the byte stream into a general transaction object; Step 207 may specifically include: Sub-step 2071, calling the transaction-level modeling interface of the verification platform to transfer the general transaction object to the target platform.

[0061] For step A1 and sub-step 2071, the generic transaction object can be Generic Payload. From the UVM source code, it can be seen that the default type uvm_tlm_generic_payload is used in places where the interface and socket interface involve transaction types. The base class of Generic Payload is uvm_sequence_item, which can be regarded as a defined transaction template that can be directly used for bus system modeling. Because it is a transaction created for bus system modeling, the domains contained in Generic Payload are basically related to the bus, such as address m_address, data 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.

[0062] For example, the transaction is parsed into a byte stream, encapsulated into a Generic Payload, and transmitted through TLM, which can achieve transaction-level communication and improve the reliability and efficiency of transmission.

[0063] Optionally, before step 207, the method further includes: Step B1, generating a configuration file according to the first transaction attribute, wherein the communication interface is stored in the configuration file; Step 207 may further include: 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 attributes and the interface file to the target platform.

[0064] 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 transfer the target language transaction attributes and interface files to the target platform. By storing the socket interface information in the configuration file, the information can be flexibly modified according to actual needs without modifying the code, which can improve the flexibility and configurability of the system.

[0065] Optionally, the configuration file includes: a transaction name, a verification platform interface, and a compilation language platform interface; step B1 may specifically include: Sub-step B11, obtaining a second template file defining a basic structure of a configuration file; Sub-step B12, 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; Sub-step B13, replacing 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, replacing the placeholder corresponding to the verification platform interface with the socket interface corresponding to the verification platform, and replacing the placeholder corresponding to the compilation language platform interface with the socket interface corresponding to the compilation language platform; Sub-step B14, after the replacement is completed, generating the configuration file.

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

[0067] Step 208: 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.

[0068] This step may be specifically referred to as the above step 104, and will not be described in detail here.

[0069] Optionally, the method further includes: Step 209, generating a target language packaging code according to the interface file; Step 210, using a compiled language compiler to compile the interface file and the target language packaging code into a target language extension module, and generate an extended interface file; Step 208 may specifically include: Sub-step 2081: parsing 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.

[0070] Regarding steps 209-2010, and sub-step 2081, SWIG is a tool for exposing C / C++ code to other high-level languages, such as Python, Java, etc. Taking Python as the target language and C / C++ as the compilation language, the Python wrapper code is generated by the SWIG tool, and the code is responsible for calling the underlying C / C++ function. Then, the Python wrapper code and the interface file are compiled into a Python extension module using a C / C++ compiler, so that the generated module can be imported in the Python language and the C / C++ function can be directly called.

[0071] For example, through the SWIG tool, the interface of the compiled language platform can be exposed to the high-level language, so that the SystemC module can be used in a higher-level programming environment.

[0072] Optionally, the method further includes: Step 211, in response to the target platform's processing operation on the second transaction, obtaining a third transaction obtained after processing, and analyzing the third transaction to obtain a corresponding third transaction attribute; Step 212: based on the third transaction attribute, convert the third transaction into a byte stream; Step 213, 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; Step 214: According to the interface file, the verification platform parses the byte stream into a fourth transaction corresponding to the assembly language for display.

[0073] For step 211-step 214, the processing operation of the target platform can be varied, depending on the specific application scenario. For example, in a memory read and write simulation scenario, the target platform may perform corresponding read and write operations on the simulated memory according to the read and write request in the second transaction, and generate a third transaction containing the operation result. The third transaction is analyzed in detail to extract key attributes therein, such as transaction type, transaction address, transaction data, etc. The attributes of the third transaction are encoded into a byte stream according to certain rules so as to be transmitted between different platforms. After the verification platform receives the interface file and the byte stream, the byte stream is parsed into the fourth transaction corresponding to the assembly language according to the rules of the interface file, and the parsing result is displayed. The transaction object in the target language can be converted into a byte stream. It is transmitted to the UVM environment via SystemC and UVMC and restored to the original transaction object. Transaction transmission between UVM and high-level languages ​​can be realized.

[0074] In summary, in the embodiment of the present application, first, the first transaction constructed by the assembly language in the verification platform is analyzed to obtain the corresponding transaction attributes, and based on the transaction attributes, the first transaction is converted into a byte stream, and the transaction-level modeling interface of the verification platform is called to transmit the byte stream to the target platform. Then, based on the transaction attributes, the target language transaction attributes and interface files are constructed, and the communication interface of the verification platform is called to transmit the target language transaction attributes and interface files to the target platform, so that according to the interface file and the target language transaction attributes, the byte stream is parsed through the target platform into the second transaction corresponding to the target language for display, and the transaction information can be intuitively viewed and analyzed in the development environment of the target language, which can reduce the learning threshold of the language, and there is no need to frequently switch between different language environments. Cross-language interaction between the verification platform and the target platform can be achieved, which increases the applicable scenarios of the verification platform and enhances the flexibility and scalability of the system.

[0075] Figure 3 It is a schematic diagram of a processing flow from a hardware level to a multi-language level provided by an embodiment of the present application, and the schematic diagram includes: a hardware level, a compiled language level, and a multi-language level. There are three input sources at the hardware level, namely, a general verification methodology file, a general verification methodology compiled language header file, and a template file. The general verification methodology file is automatically parsed to generate a transaction, and a simplified packaging interface generator is generated through a code generator based on the transaction, the general verification methodology compiled language header file, and the template file. At the compiled language level, the transaction and the simplified packaging interface generator are processed by the compiled language wrapper, and then a packaging library is generated through the compiled language compiler. At the multi-language level, the compiled language wrapper is expanded to obtain a language wrapper, and the language wrapper and the packaging library are generated into a software package. A process starting from hardware-related files, after a series of processing and conversion, finally generates a software package and realizes multi-language support is presented.

[0076] Figure 4 It is a schematic diagram of a system architecture and data flow of hardware verification and multi-language interaction provided by an embodiment of the present application, including two parts: interaction between components and data flow. Among them, the main components of the component interaction part are the verification platform, the compiled language platform and the target language platform. The verification platform and the compiled language platform communicate through the transaction-level modeling interface. The compiled language platform is expanded by simplifying the encapsulation interface generator to obtain the target language platform. Specifically, the compiled language platform generates wrappers of different languages ​​​​through the simplified encapsulation interface generator, including Python wrappers, Java wrappers and Go wrappers, corresponding to Python language, Java language and Go language respectively, thereby realizing the interaction between different high-level languages ​​​​and the underlying hardware verification module. In the data flow part, the first transaction is first converted into a byte stream, and then the byte stream is encapsulated into a "generic transaction object tlm_generic_payload". After parsing and reconstruction, the second transaction corresponding to the target language is generated. This process shows the conversion of data between different formats to adapt to the processing requirements of different modules in the system. This architecture diagram aims to realize the interaction between hardware verification modules and multiple high-level programming languages ​​through transaction-level modeling and multi-language wrappers, and presents in detail the flow and processing of data in the system, which helps to improve the flexibility and efficiency of hardware design and verification.

[0077] Figure 5 is a block diagram of a transmission device 30 for a transaction in a circuit design file provided in an embodiment of the present application, the device comprising: A first analysis module 301 is used to 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; The processing module 302 is used to convert the first transaction into a byte stream based on the first transaction attribute, and to 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; The first transmission module 303 is used 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 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 304 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.

[0078] Optionally, the transaction attributes include: a transaction type field, a transaction address field, and a transaction data field; The processing module comprises: A first acquisition submodule, used to acquire a syntax tree corresponding to the first transaction; a second acquisition submodule, 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; a conversion submodule, configured to convert the first numerical value into a corresponding byte stream, convert the second numerical value into a corresponding byte stream, and convert the third numerical value into a corresponding byte stream; The first generating submodule is used 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.

[0079] Optionally, the second acquisition submodule includes: A determination unit is used to traverse the syntax tree, 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.

[0080] Optionally, the device further comprises: An encapsulation module, used for encapsulating the byte stream into a general transaction object; The first transmission module includes: The first transmission submodule is used to call the transaction-level modeling interface of the verification platform to transmit the general transaction object to the target platform.

[0081] Optionally, the transaction attributes include: a transaction type field, a transaction address field, and a transaction data field; The processing module comprises: A first construction submodule is used to construct a transaction class corresponding to the target language according to the target language; A second generating submodule is used to generate, in the transaction class corresponding to the target language, a target transaction type field corresponding to the target language according to the transaction type field, generate a target transaction address field corresponding to the target language according to the transaction address field, and generate a target transaction data field corresponding to the target language according to the transaction data field; The second construction submodule is used to construct 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.

[0082] Optionally, the first parsing module includes: A third acquisition submodule, used to 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; A first parsing submodule is used to parse the byte stream corresponding to the transaction type field into a value corresponding to the target transaction type field, parse the byte stream corresponding to the transaction address field into a value corresponding to the target transaction address field, and parse the byte stream corresponding to the transaction data field into a value corresponding to the target transaction data field according to the method of parsing the byte stream into transaction attributes defined in the interface file; The third generating submodule is used to obtain the second transaction attribute corresponding to the target language after the parsing is completed.

[0083] Optionally, 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 processing module comprises: A fourth generating submodule, configured to generate a compiled language transaction class corresponding to a compiled language platform according to the transaction type field, the transaction address field, and the transaction data field; A fourth acquisition submodule is used to 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 first generating submodule is used to replace the placeholder corresponding to the transaction class item in the first template file with the compiled language transaction class name to generate the interface file.

[0084] Optionally, the first parsing module includes: a fifth acquisition submodule, configured to 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; The second parsing submodule is used 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 according to the method of parsing the byte stream into transaction attributes defined in the interface file, so as to obtain the second transaction attributes corresponding to the target language.

[0085] Optionally, the device further comprises: A first generating module, configured to generate a configuration file according to the first transaction attribute, wherein the communication interface is stored in the configuration file; The first transmission module includes: The second transmission submodule is used to obtain 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 attribute and the interface file to the target platform.

[0086] Optionally, the configuration file includes: a transaction name, a verification platform interface, and a compilation language platform interface; the generation module includes: A sixth acquisition submodule, used to acquire a second template file defining a basic structure of a configuration file; A seventh acquisition submodule, used to acquire the name of the class to which the first transaction attribute belongs, and to verify the socket interface corresponding to the platform and the socket interface corresponding to the compiled language platform; a replacement submodule, used 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 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; The second generating submodule is used to generate the configuration file after the replacement is completed.

[0087] Optionally, the device further comprises: A second generating module, used for generating a target language packaging code according to the interface file; A third generation module is used to use a compiled language compiler to compile the interface file and the target language packaging code into a target language extension module to generate an extended interface file; The first parsing module comprises: The third parsing submodule is used 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.

[0088] Optionally, the device further comprises: A second analysis module is used to respond to the processing operation of the target platform on the second transaction; obtain a third transaction obtained after the processing, and analyze the third transaction to obtain a corresponding third transaction attribute; A conversion module, configured to convert the third transaction into a byte stream based on the third transaction attribute; A second transmission module, used for 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; The second parsing module is used to parse the byte stream into a fourth transaction corresponding to the assembly language through the verification platform according to the interface file for display.

[0089] In summary, in the embodiment of the present application, first, the first transaction constructed by the assembly language in the verification platform is analyzed to obtain the corresponding transaction attributes, and based on the transaction attributes, the first transaction is converted into a byte stream, and the transaction-level modeling interface of the verification platform is called to transmit the byte stream to the target platform. Then, based on the transaction attributes, the target language transaction attributes and interface files are constructed, and the communication interface of the verification platform is called to transmit the target language transaction attributes and interface files to the target platform, so that according to the interface file and the target language transaction attributes, the byte stream is parsed through the target platform into the second transaction corresponding to the target language for display, and the transaction information can be intuitively viewed and analyzed in the development environment of the target language, which can reduce the learning threshold of the language, and there is no need to frequently switch between different language environments. Cross-language interaction between the verification platform and the target platform can be achieved, which increases the applicable scenarios of the verification platform and enhances the flexibility and scalability of the system.

[0090] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0091] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0092] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0093] An embodiment of the present application provides a device for transmitting transactions in a circuit design file, including a memory and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by one or more processors to include methods for performing one or more of the methods described in the above-mentioned embodiments.

[0094] Figure 6 4 is a block diagram of an electronic device 400 provided in 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.

[0095] Reference 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 .

[0096] The processing component 402 generally controls the overall operation of the electronic device 400, such as operations associated with display, phone calls, data communications, 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-mentioned method. 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.

[0097] 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, etc. 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.

[0098] The power supply component 406 provides power to the 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 to the electronic device 400.

[0099] 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 may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide 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 may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

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

[0101] The input / output interface 412 provides an interface between the processing component 402 and the peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0102] The sensor assembly 414 includes one or more sensors for providing various aspects of status assessment for the electronic device 400. For example, the sensor assembly 414 can detect the open / closed state of the electronic device 400, the relative positioning of the components, such as the display and keypad of the electronic device 400, and the sensor assembly 414 can also detect the position change of the electronic device 400 or a component of the electronic device 400, the presence or absence of contact between the user and 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 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 414 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 414 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0103] The communication component 416 is used to facilitate wired or wireless communication between the electronic device 400 and other devices. The electronic device 400 can access a wireless network based on a communication standard, such as WiFi, a carrier network (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 also 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.

[0104] In an exemplary embodiment, the electronic device 400 may 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 to implement the methods provided in the embodiments of the present application.

[0105] 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 instructions can be executed by a processor 420 of an electronic device 400 to perform the above method. 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, an optical data storage device, etc.

[0106] Figure 7 is a block diagram of another electronic device 500 provided in an embodiment of the present application. For example, the electronic device 500 may be provided as a server. Figure 7 , the electronic device 500 includes a processing component 522, which further includes one or more processors, and a memory resource represented by a memory 532, for storing instructions that can be executed by the processing component 522, such as an application. The application 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 in the embodiment of the present application.

[0107] The electronic device 500 may further include a power supply 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 Server TM, Mac OS X TM, Unix TM, Linux TM, FreeBSD TM or the like.

[0108] An embodiment of the present application further provides a computer program product, including a computer program, which implements the method described in the above embodiment when executed by a processor.

[0109] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the application disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0110] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only 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