Bus modeling method and device, computer equipment and storage medium

Abstract

The invention discloses a bus modeling method and device, computer equipment and a storage medium, and relates to the technical field of integrated circuits, and the method comprises the steps: generating bidirectional sockets in a communication component, and carrying out the bidirectional binding of the corresponding bidirectional sockets, and obtaining a binding relation. And determining a data transmission strategy of the bidirectional socket and a communication load field of the to-be-modeled bus, and creating a target bus model corresponding to the to-be-modeled bus in combination with the information. According to the method, a socket binding method is expanded, the definition of a transmission interface is reconstructed, the definition of a general load class is reconstructed, and the modeling requirement of a transaction-level non-memory mapping type bus can be met. The problem that the non-memory mapping type bus is difficult to model is solved. The method has the advantages that modeling requirements of a memory mapping type bus and a non-memory mapping type bus are completely compatible, and the memory mapping type bus and the non-memory mapping type bus can be modeled respectively.

Description

Technical Field

[0001] The present invention relates to the technical field of integrated circuit design, and in particular, to a bus modeling method, device, computer device, and storage medium. Background Art

[0002] When using the transaction-level modeling method to model a System on Chip (SoC), it is necessary to model the communication bus of the SoC. According to its communication protocol, the communication bus can be divided into a memory-mapped type bus and a non-memory-mapped type bus.

[0003] Currently, the method of modeling the communication bus in the transaction-level modeling method is mainly formulated for the memory-mapped type bus, and it cannot be well used to create a model of the non-memory-mapped type bus. For example: the fields included in the general payload are not applicable to the communication protocols adopted by all non-memory-mapped type buses, and some fields are useless or incompatible; the modeling method cannot simulate the full-duplex communication of the non-memory-mapped type bus.

[0004] Therefore, there is a problem in the related art that it is difficult to model the non-memory-mapped type bus. Summary of the Invention

[0005] In view of this, the present invention provides a bus modeling method, device, computer device, and storage medium to solve the problem of difficulty in modeling the non-memory-mapped type bus.

[0006] In a first aspect, the present invention provides a bus modeling method, which includes:

[0007] Generating a first bidirectional socket in a first communication component and a second bidirectional socket in a second communication component;

[0008] Bidirectionally binding the first bidirectional socket and the second bidirectional socket to obtain a binding relationship;

[0009] Determining a data transmission strategy of the first bidirectional socket and a data transmission strategy of the second bidirectional socket, and determining the communication load fields of the bus to be modeled;

[0010] Based on the first bidirectional socket, the second bidirectional socket, the binding relationship, the data transmission strategy, and the communication load fields, creating a target bus model corresponding to the bus to be modeled.

[0011] In a second aspect, the present invention provides a bus modeling device, which includes:

[0012] A socket generation module, configured to generate a first bidirectional socket in a first communication component and a second bidirectional socket in a second communication component;

[0013] A socket binding module, configured to perform two-way binding on a first two-way socket and a second two-way socket to obtain a binding relationship;

[0014] A determination module, configured to determine a data transmission strategy of the first two-way socket and a data transmission strategy of the second two-way socket, and determine a communication load field of the bus to be modeled;

[0015] A creation module, configured to create a target bus model corresponding to the bus to be modeled based on the first two-way socket, the second two-way socket, the binding relationship, the data transmission strategy, and the communication load field.

[0016] In a third aspect, the present invention provides a computer device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the bus modeling method according to the first aspect or any corresponding embodiment thereof.

[0017] In a fourth aspect, the present invention provides a computer-readable storage medium, on which computer instructions are stored. The computer instructions are used to cause a computer to execute the bus modeling method according to the first aspect or any corresponding embodiment thereof.

[0018] In a fifth aspect, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the bus modeling method according to the first aspect or any corresponding embodiment thereof.

[0019] Through the present application, two-way sockets are generated in a communication component, and the corresponding two-way sockets are two-way bound to obtain a binding relationship. The data transmission strategies of the two-way sockets and the communication load field of the bus to be modeled are determined, and a target bus model corresponding to the bus to be modeled is created by combining the above information. The binding method of the socket is extended, the definition of the transmission interface is reconstructed, and the definition of the general payload class is reconstructed, which can meet the modeling requirements of the transaction-level non-memory mapped type bus, and there is no need for redundant implementation and the interfaces related to the memory mapped type bus and the fields inside the general payload; in addition, this method can also be fully compatible with the modeling requirements of the memory mapped type bus, making it more convenient to model the bus. The problem of difficult modeling of non-memory mapped type buses is solved. It has the effects of being fully compatible with the modeling requirements of both memory mapped type buses and non-memory mapped type buses, and can model memory mapped type buses and non-memory mapped type buses respectively. Description of the Drawings

[0020] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the related art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the related art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0021] Figure 1 It is a schematic flowchart of a bus modeling method according to an embodiment of the present invention;

[0022] Figure 2 It is a schematic diagram of a non-memory mapped type bus communication model according to an embodiment of the present invention;

[0023] Figure 3 It is a schematic diagram of a non-memory mapped type bus model socket class according to an embodiment of the present invention;

[0024] Figure 4 It is a schematic diagram of a non-memory mapped type bus model interface according to an embodiment of the present invention;

[0025] Figure 5 It is a schematic diagram of a non-memory mapped type bus model general payload class according to an embodiment of the present invention;

[0026] Figure 6 It is a structural block diagram of a bus modeling device according to an embodiment of the present invention;

[0027] Figure 7 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Specific Embodiments

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

[0029] Currently, the computational complexity of communication terminals and devices has increased, and the demand for the integration scale of real-time complex system chips will grow rapidly. Dozens or hundreds or thousands of processing units may be integrated on a single chip, resulting in a very complex in-chip communication system. In such an integrated system, it is necessary to design a high-performance in-chip communication system that is reliable, high-speed, and low-power. The difficulty in designing an SoC stems from its complexity, which has given rise to SystemC (a language for system design based on the C++ language) and the Electronic System Level (ESL) methodology for modeling SoCs. Transaction-level modeling is the key to ESL design. For complex SoCs, in-depth system-level simulation is required before RTL (Register Transfer Level circuit) design to confirm whether the designed architecture is appropriate, whether the bus can meet throughput and real-time requirements, and whether the memory is wasted. In order to shorten the design cycle of the key IP (Intellectual Property) cores of the SoC and assist the design process, and at the same time to bridge the gap between system architecture design and hardware RTL circuit implementation, a modeling methodology is needed to describe the functions and architecture of the entire circuit system without getting caught up in the complicated signal timing and gate circuits of the hardware circuit. Therefore, ESL design came into being. Using the ESL design methodology to describe the system at an appropriate level of abstraction, construct a virtual hardware prototype platform, explore the hardware architecture and develop software programs, and achieve rapid system modeling and simulation analysis. The core of ESL is the Transaction Level Modeling (TLM) method.

[0030] When modeling an SoC using transaction-level modeling, the communication bus of the SoC is usually modeled. According to its communication protocol, the bus can be divided into memory-mapped buses and non-memory-mapped buses. Among them, memory-mapped buses include: AXI (Advanced eXtensible Interface), AHB (Advanced high-performance bus), APB (Advanced peripheral bus), etc. Memory mapping means that when the host performs read and write operations on the slave, or specifies a target address, this target address corresponds to the address in the system storage space, indicating read and write operations on this space. Non-memory-mapped buses include: UART (Universal Asynchronous Receiver / Transmitter), CAN (Controller Area Network), Ethernet, etc. In the non-memory-mapped protocol, UART is a "one-to-one" communication link, and CAN or Ethernet is a "many-to-many" communication link.

[0031] The TLM2.0 standard of transaction-level modeling is mainly formulated for memory-mapped on-chip buses, such as bus types like AXI and AHB. Therefore, it cannot be well used to model non-memory-mapped bus models. For example, the fields included in the general payload of the TLM2.0 standard are not applicable to all non-memory mapping protocols. Some fields are useless for specific categories of protocols. For example, the address field is useless for UART, and the bus width field is useless for UART. There are some fields that are incompatible. For example, the data length field is incompatible with non-memory-mapped buses and cannot support correct communication. There is no bidirectional socket support and full-duplex communication simulation cannot be achieved.

[0032] Based on the above, embodiments of the present invention provide a bus modeling method, which extends the binding method of sockets based on the TLM2.0 standard, reconstructs the definition of the transmission interface, and reconstructs the definition of the general payload class. It can meet the modeling requirements of transaction-level non-memory mapped type buses, and does not require redundant implementation of interfaces related to memory mapped type buses and fields inside the general payload. When the architecture is clearly defined (i.e., when the user's requirements are clear), this method can be applied to perform transaction-level chip modeling and simulation work, enabling the simulation of chip hardware behavior to be completed as soon as possible, evaluating whether the intellectual property core performance, system function, or performance indicators meet the requirements, providing feedback and iteration on the chip architecture design, and ultimately increasing the possibility that the chip design has correct functions and meets the requirements. It fully complies with the modeling requirements of non-memory mapped type buses and is convenient for modeling non-memory mapped type buses.

[0033] According to an embodiment of the present invention, a bus modeling embodiment is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer device with data processing capabilities, such as a computer, a server, etc. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0034] In this embodiment, a bus modeling method is provided. Figure 1 It is a flowchart of the bus modeling method according to an embodiment of the present invention, as Figure 1 shown, and this process includes the following steps:

[0035] Step S101, generate a first bidirectional socket in the first communication component and a second bidirectional socket in the second communication component.

[0036] Specifically, this embodiment extends the binding method of bidirectional sockets based on the TLM2.0 standard, defines a transaction-level basic bidirectional socket class (denoted as the tlm_base_bidrectional_socket class), and in implementation, it inherits the transaction-level initiator short socket class (denoted as the tlm_initiator_socket class) and the transaction-level target socket class (denoted as the tlm_target_socket class).

[0037] The first communication component is, for example: Figure 2 the non-memory mapped type bus module 0 in Figure 2 and the second communication component is, for example:

[0038] Generate a first bidirectional socket in the first communication component and a second bidirectional socket in the second communication component. For example, define a bidirectional socket transport_socket_0 as the first bidirectional socket (tlm_base_bidrectional_socket transport_socket_0) in the non-memory mapped type bus module 0. Define a bidirectional socket transport_socket_1 as the second bidirectional socket (tlm_base_bidrectional_socket transport_socket_1) in the non-memory mapped type bus module 1. As Figure 2 shown, both the non-memory mapped type bus module 0 and the non-memory mapped type bus module 1 contain bidirectional sockets.

[0039] Step S102: Bidirectionally bind the first bidirectional socket and the second bidirectional socket to obtain a binding relationship.

[0040] Specifically, the process of bidirectional binding is as follows: The first communication component calls the accept() method to accept the connection request from the second communication component and returns a new connected socket. If both sides can act as the sender or receiver of the non-memory mapped type bus respectively, they need to initiate connection requests to each other and establish a bidirectional channel. Verify the connection validity by sending / receiving test data to confirm that the connection is normal. Store the binding relationship, including associating and storing information such as the file descriptors, IP (Internet Protocol Address) addresses, and port numbers of the two sockets to form a binding relationship. Configure bidirectional communication parameters, including setting the buffer size, data encoding format (such as UTF-8), encryption protocol (such as TLS), etc. Enable the heartbeat mechanism or keep-alive option to ensure connection stability. As Figure 2 shown, the bidirectional binding of transaction-level sockets realizes full duplex. The bidirectional binding can also use the bind method to associate the first bidirectional socket and the second bidirectional socket.

[0041] Step S103: Determine the data transfer strategy of the first bidirectional socket and the data transfer strategy of the second bidirectional socket, and determine the communication load field of the bus to be modeled.

[0042] Specifically, as Figure 2As shown, the data transfer policy is determined based on the method of calling the transfer interface through sockets. The methods of calling the transfer interface through sockets include: non-blocking forward transfer interface method, non-blocking backward transfer interface method, blocking transfer interface method, debug interface method, etc. Therefore, the data transfer policies include: non-blocking forward transfer, which is used for the pipelining operation of the high-speed bus. The initiator continuously sends multiple transactions through the socket without waiting for a response; non-blocking backward transfer is used for the interrupt controller to asynchronously notify interrupt events through the socket; blocking transfer is used for the synchronous writing of configuration registers to ensure that the operation takes effect immediately; debug interface transfer provides bypass access capabilities through the socket to directly access memory or registers without interfering with the normal transaction flow.

[0043] In the above data transfer policy, determine the data transfer policy corresponding to the first bidirectional socket and the data transfer policy corresponding to the second bidirectional socket.

[0044] The bus to be modeled can be a memory-mapped type bus and a non-memory-mapped type bus. If the bus to be modeled is a memory-mapped type bus, determine the communication load fields of the bus to be modeled, such as: address field, data length, bus width field, etc. If the bus to be modeled is a non-memory-mapped type bus, determine the communication load fields of the bus to be modeled, such as: read / write type, data pointer, data length, parity bit, stop bit, baud rate, etc. The above communication load fields do not include redundant parts such as the address field belonging to the communication of the memory-mapped type bus.

[0045] Step S104, based on the first bidirectional socket, the second bidirectional socket, the binding relationship, the data transfer policy, and the communication load fields, create a target bus model corresponding to the bus to be modeled.

[0046] Specifically, as Figure 2 shown, both the first communication component and the second communication component are the sending end / receiving end of the non-memory-mapped type bus. Determine the first bidirectional socket and the second bidirectional socket among them. Determine the binding relationship, complete the two-way binding of the transaction-level socket, and achieve full duplex. Determine the data transfer policy, that is, the method of calling the transfer interface through the socket. Finally, determine the communication load fields, that is, the general payload passed in the transfer interface method. Combine the above information to complete the creation of the target bus model corresponding to the bus to be modeled.

[0047] It should be noted that in this embodiment, for specific different non-memory-mapped type buses, such as I2C (Inter-Integrated Circuit, serial communication protocol), CAN, etc., the specific parts can be extracted, and a method that can meet the modeling requirements of more non-memory-mapped type buses can be further defined.

[0048] The bus modeling method provided in this embodiment generates a bidirectional socket in a communication component, performs bidirectional binding on the corresponding bidirectional sockets to obtain a binding relationship. Determine the data transmission strategy of the bidirectional socket and the communication load field of the bus to be modeled, and create a target bus model corresponding to the bus to be modeled in combination with the above information. It expands the binding method of the socket, reconstructs the definition of the transmission interface, and reconstructs the definition of the general payload class, which can meet the modeling requirements of the transaction-level non-memory mapped type bus, and there is no need to redundantly implement the interfaces related to the memory mapped type bus and the fields inside the general payload; in addition, this method can also be fully compatible with the modeling requirements of the memory mapped type bus, making it more convenient to model the bus. It solves the problem of difficult modeling of non-memory mapped type buses. It has the effect of being fully compatible with the modeling requirements of both memory mapped type buses and non-memory mapped type buses, and can model memory mapped type buses and non-memory mapped type buses separately.

[0049] In some alternative embodiments, before generating the first bidirectional socket in the first communication component, the method further includes:

[0050] Obtain the transaction-level initiator socket class and the transaction-level target socket class;

[0051] Create a bidirectional socket class based on the transaction-level initiator socket class and the transaction-level target socket class, where the bidirectional socket class is used to generate the first bidirectional socket and the second bidirectional socket.

[0052] Specifically, obtain the transaction-level initiator socket class (tlm_base_bidrectional_socket class) and the transaction-level target socket class (tlm_target_socket class).

[0053] Based on the TLM2.0 standard, the binding method of the bidirectional socket is extended, and the transaction-level basic bidirectional socket class, that is, the bidirectional socket class (denoted as tlm_base_bidrectional_socket class), is defined. In implementation, it inherits the transaction-level initiator short socket class (denoted as tlm_initiator_socket class) and the transaction-level target socket class (denoted as tlm_target_socket class). The above first bidirectional socket and second bidirectional socket can be generated through the bidirectional socket class.

[0054] The process of creating a bidirectional socket class is as follows: inherit from the transaction-level initiating short socket class, provide interfaces for the initiator, such as b_transport, transport_dbg, etc., to actively initiate transactions, support delayed modeling of transactions and non-blocking transmission. Inherit from the transaction-level target socket class, provide interfaces for the target, such as the passive reception implementation of b_transport, support blocking response of transactions and direct memory access (DMA) simulation. Set the bidirectional extension function and uniformly bind the interfaces: through the bind method, associate two bidirectional socket instances to automatically complete the binding of the initiator and the target. Transaction routing: Dynamically select the initiator or target interface according to the transaction type (read / write / control). Error handling: Capture exceptions (such as timeouts, protocol errors) during bidirectional transmission and trigger the callback mechanism.

[0055] As described above Figure 3 shown, a bidirectional socket class is created based on the transaction-level initiating short socket class and the transaction-level target socket class, and the bidirectional socket class inherits from the transaction-level initiating short socket class, and the bidirectional socket class inherits from the transaction-level target socket class.

[0056] In this embodiment, a bidirectional socket class is created, the socket binding method is extended, the binding of the bidirectional socket is realized, and then the full-duplex communication of the analog bus is realized.

[0057] In some optional embodiments, determining the data transmission strategies of the first bidirectional socket and the second bidirectional socket includes:

[0058] Obtain the forward interface corresponding to the first bidirectional socket and the forward interface corresponding to the second bidirectional socket in the first preset interface set;

[0059] Obtain the backward interface corresponding to the first bidirectional socket and the backward interface corresponding to the second bidirectional socket in the second preset interface set;

[0060] Use the data transmission methods corresponding to the forward interface and the data transmission methods corresponding to the backward interface as the data transmission strategies.

[0061] Specifically, in this embodiment, the definition of the transmission interface is reconstructed based on the TLM2.0 standard. The interfaces related to direct memory access in the methods inherited by the forward interface and the backward interface are separated out separately. The non-blocking forward transmission interface method, the non-blocking backward transmission interface method, the blocking transmission interface method, and the debugging interface method are continued to be used. The DMI (Direct Memory Interface) is separately decomposed and no longer used. The forward interface and the backward interface applicable to the transaction-level non-memory-mapped type bus do not need to inherit the interfaces related to direct memory access.

[0062] The bus to be modeled can be a memory-mapped type bus and a non-memory-mapped type bus. If the bus to be modeled is a non-memory-mapped type bus, the first preset interface set includes interfaces such as a forward non-blocking transmission interface, a blocking transmission interface, and a debugging interface. The second preset interface set includes a backward non-blocking transmission interface. If the bus to be modeled is a memory-mapped type bus, the first preset interface set includes interfaces such as a forward non-blocking transmission interface, a blocking transmission interface, a debugging interface, and a direct memory access interface. The second preset interface set includes a backward non-blocking transmission interface and a direct memory access failure interface.

[0063] According to the type of the bus to be modeled, obtain the forward interface corresponding to the first bidirectional socket and the forward interface corresponding to the second bidirectional socket from the corresponding first preset interface set above. Obtain the backward interface corresponding to the first bidirectional socket and the backward interface corresponding to the second bidirectional socket in the second preset interface set.

[0064] Use the data transmission methods corresponding to the forward interface and the backward interface as the data transmission strategy of the socket. For example: if the forward interface is a non-blocking forward transmission interface, the data transmission strategy is non-blocking forward transmission, which is used for the pipelining operation of the high-speed bus. The initiator continuously sends multiple transactions through the socket without waiting for a response. If the forward interface is a blocking transmission interface, the data transmission strategy is blocking transmission, which is used for the synchronous writing of the configuration register to ensure that the operation takes effect immediately. If the backward interface is a non-blocking backward transmission interface method, the data transmission strategy is non-blocking backward transmission, which is used for the interrupt controller to asynchronously notify interrupt events through the socket.

[0065] Non-blocking forward transmission interface method, non-blocking backward transmission interface method, blocking transmission interface method, debugging interface method, etc. Therefore, the data transmission strategies include: non-blocking forward transmission, which is used for the pipelining operation of the high-speed bus. The initiator continuously sends multiple transactions through the socket without waiting for a response; blocking transmission is used for the synchronous writing of the configuration register to ensure that the operation takes effect immediately; debugging interface transmission provides bypass access capabilities through the socket to directly access memory or registers without interfering with the normal transaction flow.

[0066] In some alternative embodiments, when the bus to be modeled is a non-memory-mapped type bus, the first preset interface set includes at least one of a forward non-blocking transfer interface, a blocking transfer interface, and a debug interface;

[0067] The second preset interface set includes a backward non-blocking transfer interface.

[0068] Specifically, the TLM2.0 standard stipulates that each TLM transfer class is based on two interfaces: one for forward communication is the forward interface, and the other for backward communication is the backward interface. The forward interface inherits from four interfaces, all of which contain exclusive pure virtual methods, specifically including a forward non-blocking transfer interface, a blocking transfer interface, a debug interface, and a direct memory access interface; the backward interface inherits from two interfaces, specifically including a backward non-blocking transfer interface and a direct memory access invalidate interface.

[0069] When simulating a non-memory-mapped type bus, the direct memory access invalidate interface is not applicable to the protocol, and these interfaces must also be implemented, which will bring redundant work. Therefore, the definition of the transfer interface is reconstructed. The idea is to separate the direct memory access-related interfaces in the methods inherited by the forward interface and the backward interface. The forward interface applicable to the transaction-level non-memory-mapped type bus is defined as tlm_base_fw_transport_if, which inherits from three interfaces, specifically including a forward non-blocking transfer interface, a blocking transfer interface, and a debug interface; the backward interface applicable to the transaction-level non-memory-mapped type bus is defined as tlm_base_bw_transport_if. The backward interface inherits from one interface, that is, the backward non-blocking transfer interface. On this basis, it is further extended. The definitions of the interfaces tlm_fw_transport_if and tlm_bw_transport_if are applicable to the transaction-level memory-mapped type bus, which is consistent with the TLM2.0 standard and does not exceed the scope stipulated by the TLM2.0 standard. As described above Figure 4 shown, there are a total of 6 interfaces, namely a forward non-blocking transfer interface, a blocking transfer interface, a debug interface, a direct memory access interface, a backward non-blocking transfer interface, and a direct memory access invalidate interface. Among them, the forward non-blocking transfer interface, the blocking transfer interface, and the debug interface constitute the forward interface of the non-memory-mapped type bus. The forward interface and the direct memory access interface form the forward interface. The backward non-blocking transfer interface is the backward interface of the non-memory-mapped type bus. The backward interface and the direct memory access invalidate interface form the backward interface.

[0070] Based on the above, in the case where the bus to be modeled is a non-memory-mapped type bus, the first preset interface set includes at least one of a forward non-blocking transfer interface, a blocking transfer interface, and a debug interface; the second preset interface set includes a backward non-blocking transfer interface.

[0071] In this embodiment, the definition of the transfer interface is reconstructed. The non-blocking forward transfer interface method, the non-blocking backward transfer interface method, the blocking transfer interface method, and the debug interface method are continued to be used. The direct memory access interface is separately decomposed and no longer used, which is convenient for subsequent modeling of the non-memory-mapped type bus.

[0072] In some optional embodiments, determining the communication load field of the bus to be modeled includes:

[0073] In the case where the bus to be modeled is a non-memory-mapped type bus, obtain the communication load field corresponding to the bus to be modeled in the first load field class;

[0074] In the case where the bus to be modeled is a memory-mapped type bus, obtain the communication load field corresponding to the bus to be modeled in the second load field class.

[0075] Specifically, the bus to be modeled can be a memory-mapped type bus and a non-memory-mapped type bus. Store the load fields that the memory-mapped type bus may use into the first load field class, and the first load field class includes: address field, data length, bus width field, etc. Store the load fields that the non-memory-mapped type bus may use into the second load field class, and the second load field class includes: read / write type, data pointer, data length, parity bit, stop bit, baud rate, etc. It should be noted that the second load field class does not include redundant parts such as the address field belonging to the communication of the memory-mapped type bus.

[0076] Based on the above, if the bus to be modeled is a non-memory-mapped type bus, obtain the communication load field corresponding to the bus to be modeled in the first load field class. If the bus to be modeled is a memory-mapped type bus, obtain the communication load field corresponding to the bus to be modeled in the second load field class.

[0077] In some optional embodiments, before determining the communication load field of the bus to be modeled, the method further includes:

[0078] Obtain the first intermediate fields corresponding to the first preset number of non-memory-mapped type buses;

[0079] Obtain the second intermediate fields corresponding to the second preset number of memory-mapped type buses;

[0080] Create a first payload field class according to the first intermediate field, and create a second payload field class according to the second intermediate field.

[0081] Specifically, in the definition of reconstructing the general payload class in the modeling method of the transaction-level non-memory-mapped type bus, the reconstruction idea is to separate the two parts of the payload field and the extension mechanism inside the general payload (in the original TLM2.0 standard, the payload field and the extension mechanism are implemented in one class), and define the content of the payload field in the original TLM2.0 standard in the second payload field class (tlm_memory_mapped_payload), define the extension mechanism in the payload field extension class (tlm_base_generic_payload), and the second payload field class inherits from the payload field extension class. In addition, a new first payload field class (tlm_non_memory_mapped_payload) is defined, which internally implements the general communication fields of the non-memory-mapped type bus, including but not limited to: read / write type, data pointer, data length, parity bit, stop bit, baud rate, etc.; the communication fields belonging to the non-memory-mapped type bus are extended in the content, and redundant parts such as the address field belonging to the memory-mapped type bus communication are not included.

[0082] The first preset quantity represents a plurality, and no specific quantity limit is set here. Obtain the first intermediate fields corresponding to the first preset quantity of non-memory-mapped type buses. The first preset quantity of non-memory-mapped type buses are, for example: universal asynchronous receiver / transmitter bus, serial communication protocol bus, Ethernet bus, etc. The first intermediate fields are, for example: command field (m_command), data field (m_data), length field (m_length), parity bit field (m_parity_bit), etc.

[0083] The second preset quantity represents a plurality, and no specific quantity limit is set here. Obtain the second intermediate fields corresponding to the second preset quantity of memory-mapped type buses. The second preset quantity of memory-mapped type buses are, for example: advanced eXtensible Interface bus, advanced high performance bus, advanced peripheral bus, etc. The second intermediate fields are, for example: address field (m_address), command field (m_command), data field (m_data), length field (m_length), direct memory access field (m_dmi), etc.

[0084] Create a first payload field class according to the first intermediate field. As Figure 5 shown, the first payload field class includes first intermediate fields such as a command field, a data field, a length field, and a parity bit field. Create a second payload field class according to the second intermediate field. As Figure 5As shown, the second payload field class includes: an address field, a command field, a data field, a length field, a direct memory access field, and other second intermediate fields. For specific content, see Figure 5 , which will not be elaborated here.

[0085] Taking the bus to be modeled as a Universal Asynchronous Receiver / Transmitter (UART) bus as an example for illustration, part of the code for defining the first payload field class is as follows:

[0086]

[0087] In this embodiment, the definition of the general payload class is reconstructed, separating the original defined payload part and the extension mechanism, and forming an inheritance relationship. Different non-memory mapped type buses only need to modify the data payload part. Also, in the first payload field class, communication fields belonging to non-memory mapped type buses are extended, and redundant parts such as the address field belonging to memory mapped type bus communication are not included, making the included fields applicable to all non-memory mapped type buses.

[0088] In some alternative embodiments, after creating the first payload field class according to the first intermediate field and creating the second payload field class according to the second intermediate field, the method further includes:

[0089] Creating a first inheritance relationship between the first payload field class and the payload field extension class, and creating a second inheritance relationship between the second payload field class and the payload field extension class;

[0090] According to the first inheritance relationship, copying the payload fields in the payload field extension class to the first payload field class;

[0091] According to the second inheritance relationship, copying the payload fields in the payload field extension class to the second payload field class.

[0092] Specifically, in the modeling method of the transaction-level non-memory mapped type bus, the definition of the general payload class is reconstructed. The reconstruction idea is to separate the two parts of the payload fields and the extension mechanism inside the general payload, including: defining the content of the payload fields of the original memory mapped type bus in the second payload field class, defining the extension mechanism in the payload field extension class, and the second payload field class inherits from the payload field extension class. Additionally, a new first payload field class is defined, which internally implements the general communication fields of the non-memory mapped type bus, extends the communication fields belonging to the non-memory mapped type bus in the content, and does not include redundant parts such as the address field belonging to memory mapped type bus communication. The first payload field class also inherits from the payload field extension class.

[0093] Based on the above, create a first inheritance relationship between the first payload field class and the payload field extension class, and create a second inheritance relationship between the second payload field class and the payload field extension class. The payload field extension class, for example: as Figure 5 shown, the payload field extension class includes extension fields (m_extensions), memory manager fields (m_mm), reference counter fields (m_ref_count), set extension data fields (set_extension), get extension data fields (get_extension), set auto-extension data fields (set_auto_extension), etc. As Figure 5 shown, the second payload field class inherits from the payload field extension class, and the first payload field class also inherits from the payload field extension class.

[0094] According to the first inheritance relationship, copy the payload fields in the payload field extension class to the first payload field class. For example: copy the existing fields such as extension fields and memory manager fields in the payload field extension class to the first payload field class, or copy the newly added extension fields in the payload field extension class to the first payload field class.

[0095] According to the second inheritance relationship, copy the payload fields in the payload field extension class to the second payload field class. For example: copy the existing fields such as extension fields and memory manager fields in the payload field extension class to the second payload field class, or copy the newly added extension fields in the payload field extension class to the second payload field class.

[0096] In this embodiment, the definition of the general payload class is reconstructed, which can meet the modeling requirements of the transaction-level non-memory-mapped type bus, and there is no need for redundant implementation of the interfaces related to the memory-mapped type bus and the fields inside the general payload.

[0097] In some alternative embodiments, after completing the bus modeling, the system-on-chip can be simulated and tested according to the target bus model. The specific process can include step A1 and step A2.

[0098] Step A1, set the configuration file. The configuration file includes address, data, read / write flag, bus type, and read data check flag. The address refers to the register configuration address for read or write operations. The data represents the configuration value written to the specified address during write operations and the expected value of the read data during read operations. The bus type is used to specify the bus type for register configuration and storage read / write of different bus types. The read data check flag indicates whether data checking is performed during read operations.

[0099] Step A2, read and parse the information in the configuration file according to the target bus model parsing function, and operate on the specified address in sequence according to the configuration information.

[0100] Specifically, the specific process of the parsing function for parsing the configuration file is as follows: Determine whether the configuration file can be opened normally. If the file exists and can be opened normally, obtain the configuration information; judge the read-write flag. If the write flag is 1, execute writing the configuration data to the specified address, call the target bus model and the write function, and then execute. If the read flag is 1, execute reading data from the specified address, call the target bus model and the read function, and obtain the value of the read data; for the read operation, judge whether data verification is required. If so, compare the read data with the configuration, otherwise proceed to the operation of the next address; if the verification fails, read the data from the address again until the verification is successful. If the verification is successful, proceed to the operation of the next address.

[0101] In this embodiment, the simulation of all test cases can be completed through one compilation, which can greatly reduce the human resources and time costs of verification, and at the same time reduce the occupation of hardware simulation resources, thereby improving the verification efficiency.

[0102] In this embodiment, a bus modeling device is further provided. This device is used to implement the above-mentioned embodiment and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0103] This embodiment provides a bus modeling device, as Figure 6 shown, including:

[0104] A socket generation module 601, configured to generate a first bidirectional socket in the first communication component and a second bidirectional socket in the second communication component;

[0105] A socket binding module 602, configured to perform bidirectional binding on the first bidirectional socket and the second bidirectional socket to obtain a binding relationship;

[0106] A determination module 603, configured to determine the data transmission strategy of the first bidirectional socket and the data transmission strategy of the second bidirectional socket, and determine the communication load field of the bus to be modeled;

[0107] A creation module 604, configured to create a target bus model corresponding to the bus to be modeled based on the first bidirectional socket, the second bidirectional socket, the binding relationship, the data transmission strategy, and the communication load field.

[0108] In some alternative embodiments, the device further includes:

[0109] An acquisition module, configured to acquire a transaction-level initiator socket class and a transaction-level target socket class;

[0110] A creation module, configured to create a bidirectional socket class based on the transaction-level initiator socket class and the transaction-level target socket class, wherein the bidirectional socket class is used to generate a first bidirectional socket and a second bidirectional socket.

[0111] In some alternative embodiments, the determination module 603 includes:

[0112] A first acquisition unit, configured to acquire a forward interface corresponding to the first bidirectional socket and a forward interface corresponding to the second bidirectional socket from a first preset interface set;

[0113] A second acquisition unit, configured to acquire a backward interface corresponding to the first bidirectional socket and a backward interface corresponding to the second bidirectional socket from a second preset interface set;

[0114] Set the data transfer mode corresponding to the forward interface and the data transfer mode corresponding to the backward interface as the data transfer strategy.

[0115] In some alternative embodiments, when the bus to be modeled is a non-memory-mapped type bus, the first preset interface set includes at least one of a forward non-blocking transfer interface, a blocking transfer interface, and a debugging interface; the second preset interface set includes a backward non-blocking transfer interface.

[0116] In some alternative embodiments, the determination module 603 includes:

[0117] A third acquisition unit, configured to acquire a communication load field corresponding to the bus to be modeled from a first load field class when the bus to be modeled is a non-memory-mapped type bus;

[0118] A fourth acquisition unit, configured to acquire a communication load field corresponding to the bus to be modeled from a second load field class when the bus to be modeled is a memory-mapped type bus.

[0119] In some alternative embodiments, the determination module 603 further includes:

[0120] A fifth acquisition unit, configured to acquire first intermediate fields corresponding to a first preset number of non-memory-mapped type buses;

[0121] A sixth acquisition unit, configured to acquire second intermediate fields corresponding to a second preset number of memory-mapped type buses;

[0122] A creation unit, configured to create a first load field class according to the first intermediate fields and create a second load field class according to the second intermediate fields.

[0123] In some alternative embodiments, the determination module 603 further includes:

[0124] A creation unit, configured to create a first inheritance relationship between a first payload field class and a payload field extension class, and create a second inheritance relationship between a second payload field class and the payload field extension class;

[0125] A first data copying unit, configured to copy the payload fields in the payload field extension class to the first payload field class according to the first inheritance relationship;

[0126] A second data copying unit, configured to copy the payload fields in the payload field extension class to the second payload field class according to the second inheritance relationship.

[0127] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding foregoing embodiments, and will not be elaborated herein.

[0128] The bus modeling device in this embodiment is presented in the form of functional units. Here, the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0129] An embodiment of the present invention further provides a computer device having the above-mentioned Figure 6 shown bus modeling device.

[0130] Please refer to Figure 7 , Figure 7 which is a schematic structural diagram of a computer device provided by an alternative embodiment of the present invention. As shown in Figure 7 , the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system). Figure 7 In

[0131] The processor 10 may be a central processing unit, a network processor, or a combination thereof. Among them, the processor 10 may further include a hardware chip. The above-mentioned hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above-mentioned programmable logic device may be a complex programmable logic device, a field programmable gate array, a generic array logic, or any combination thereof.

[0132] Among them, the memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiments.

[0133] The memory 20 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 may optionally include a memory remotely disposed relative to the processor 10, and these remote memories may be connected to the computer device through a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0134] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk, or a solid-state drive; the memory 20 may also include a combination of the above types of memories.

[0135] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or communication networks.

[0136] The embodiments of the present invention also provide a computer-readable storage medium. The method according to the embodiments of the present invention may be implemented in hardware, firmware, or may be implemented as computer code recorded on a storage medium, or may be implemented as computer code originally stored in a remote storage medium or a non-transitory machine-readable storage medium and downloaded through a network and to be stored in a local storage medium, so that the method described herein may be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium may be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium may also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component capable of storing or receiving software or computer code, and when the software or computer code is accessed and executed by the computer, the processor, or the hardware, the method shown in the above embodiments is implemented.

[0137] A part of the present invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can call or provide the methods and / or technical solutions according to the present invention through the operation of the computer. Those skilled in the art should understand that the forms of existence of computer program instructions in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways for computer program instructions to be executed by a computer include, but are not limited to: the computer directly executes the instructions, or the computer compiles the instructions and then executes the corresponding compiled program, or the computer reads and executes the instructions, or the computer reads and installs the instructions and then executes the corresponding installed program. Herein, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible by the computer.

[0138] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the scope defined by the present invention.

Claims

1. A bus modeling method, characterized in that The method includes: Generating a first bi-directional socket in a first communication component and generating a second bi-directional socket in a second communication component; Performing bi-directional binding on the first bi-directional socket and the second bi-directional socket to obtain a binding relationship; Determining a data transmission strategy of the first bi-directional socket and a data transmission strategy of the second bi-directional socket, and determining a communication load field of a bus to be modeled; Creating a target bus model corresponding to the bus to be modeled based on the first bi-directional socket, the second bi-directional socket, the binding relationship, the data transmission strategy, and the communication load field.

2. The method according to claim 1, wherein Before generating the first bi-directional socket in the first communication component, the method further includes: Obtaining a transaction-level initiator socket class and a transaction-level target socket class; Creating a bi-directional socket class based on the transaction-level initiator socket class and the transaction-level target socket class, where the bi-directional socket class is used to generate the first bi-directional socket and the second bi-directional socket.

3. The method according to claim 1, characterized in that The determining the data transmission strategy of the first bi-directional socket and the data transmission strategy of the second bi-directional socket includes: Obtaining a forward interface corresponding to the first bi-directional socket and a forward interface corresponding to the second bi-directional socket in a first preset interface set; Obtaining a backward interface corresponding to the first bi-directional socket and a backward interface corresponding to the second bi-directional socket in a second preset interface set; Using the data transmission method corresponding to the forward interface and the data transmission method corresponding to the backward interface as the data transmission strategy.

4. The method according to claim 3, characterized in that, When the bus to be modeled is a non-memory mapped type bus, the first preset interface set includes at least one of a forward non-blocking transmission interface, a blocking transmission interface, and a debugging interface; The second preset interface set includes a backward non-blocking transmission interface.

5. The method according to claim 1, wherein The determining the communication load field of the bus to be modeled includes: When the bus to be modeled is a non-memory mapped type bus, obtaining the communication load field corresponding to the bus to be modeled in a first load field class; When the bus to be modeled is a memory mapped type bus, obtaining the communication load field corresponding to the bus to be modeled in a second load field class.

6. The method according to claim 5, wherein Before determining the communication load field of the bus to be modeled, the method further includes: Obtaining first intermediate fields corresponding to a first preset number of the non-memory mapped type buses; Obtaining second intermediate fields corresponding to a second preset number of the memory mapped type buses; Creating the first load field class according to the first intermediate fields and creating the second load field class according to the second intermediate fields.

7. The method according to claim 6, wherein After creating the first load field class according to the first intermediate fields and creating the second load field class according to the second intermediate fields, the method further includes: Creating a first inheritance relationship between the first load field class and a load field extension class, and creating a second inheritance relationship between the second load field class and the load field extension class; Copying the load fields in the load field extension class to the first load field class according to the first inheritance relationship; Copy the payload fields in the payload field extension class to the second payload field class according to the second inheritance relationship.

8. A bus modeling device, characterized in that, The device includes: A socket generation module, configured to generate a first two-way socket in a first communication component and a second two-way socket in a second communication component; A socket binding module, configured to perform two-way binding on the first two-way socket and the second two-way socket to obtain a binding relationship; A determination module, configured to determine a data transmission policy of the first two-way socket and a data transmission policy of the second two-way socket, and determine a communication payload field of a bus to be modeled; A creation module, configured to create a target bus model corresponding to the bus to be modeled based on the first two-way socket, the second two-way socket, the binding relationship, the data transmission policy, and the communication payload field.

9. A computer device, characterized in that, Including: A memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to execute the bus modeling method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the bus modeling method according to any one of claims 1 to 7.

Images