Communication method and system, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides a communication method and system, electronic equipment and a readable storage medium. The method comprises the following steps: a sending end collects a verification event sequence triggered by a to-be-tested design of a processor in a current verification period; the verification event sequence comprises verification events corresponding to at least two verification types; any verification type contained in the verification event sequence serves as a to-be-packaged type, and the area length of a verification event corresponding to the to-be-packaged type in the verification event sequence is determined; based on the area length of each to-be-packaged type, packaging verification events contained in the verification event sequence in the current verification period to obtain a to-be-transmitted data packet of the current verification period; splicing the to-be-transmitted data packets of the at least one verification period to obtain a spliced packet with a preset size, and sending the spliced packet to a receiving end; and the receiving end is used for receiving the splicing packet sent by the sending end and unpacking the splicing packet. And communication cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit technology, and in particular to a communication method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] In processor co-simulation verification, it is necessary to simultaneously simulate the processor's circuitry under test (DUT) and a software-implemented instruction set simulator (reference model). Verification of the DUT is achieved by comparing the states of both after each processor instruction has been executed. During this verification process, extensive communication is required between the hardware side (hardware simulation platform) and the software side (reference model).

[0003] Currently, the communication method between hardware and software involves the hardware side transmitting a verification event to the software side after it is generated, thus completing one hardware-software communication. However, the processor verification framework has many types of verification events, requiring a large number of communications per simulation cycle on average. Each communication requires hardware-software handshakes and pauses, resulting in significant communication overhead. Summary of the Invention

[0004] The purpose of this invention is to provide a communication method, system, electronic device, and readable storage medium to solve the problem of high communication overhead. The specific technical solution is as follows: In a first aspect of the present invention, a communication method is provided, the method being applied to a transmitting end in a communication system, the communication system further comprising a receiving end, the transmitting end being communicatively connected to the receiving end; the method comprising: During the current verification cycle, a sequence of verification events triggered by the processor design under test is collected; the sequence of verification events contains verification events corresponding to at least two verification types. Take any of the verification types contained in the verification event sequence as the type to be packaged, and determine the region length of the verification event in the verification event sequence corresponding to the type to be packaged; Based on the region length of each of the types to be packaged, the verification events contained in the verification event sequence within the current verification period are packaged to obtain the data packet to be transmitted in the current verification period. The data packets to be transmitted for at least one verification period are spliced ​​together to obtain a spliced ​​packet of a preset size, and the spliced ​​packet is sent to the receiving end; The receiving end is used to receive the spliced ​​packet sent by the sending end and to unpack the spliced ​​packet.

[0005] In a second aspect of the invention, a communication method is also provided, the method being applied to a receiving end in a communication system, the communication system further including a transmitting end, the transmitting end being communicatively connected to the receiving end; the method comprising: Receive the spliced ​​packet and unpack the spliced ​​packet; the spliced ​​packet was sent by the sending end; The sending end is used to collect a sequence of verification events triggered by the processor design under test within the current verification period; the sequence of verification events contains verification events corresponding to at least two verification types; any verification type contained in the sequence of verification events is taken as a type to be packaged, and the region length of the verification event corresponding to the type to be packaged in the sequence of verification events is determined; based on the region length of each type to be packaged, the verification events contained in the sequence of verification events within the current verification period are packaged as a data packet to be transmitted in the current verification period; the data packets to be transmitted in at least one verification period are spliced ​​together to obtain a spliced ​​packet of a preset size, and the spliced ​​packet is sent to the receiving end.

[0006] In a third aspect of the present invention, a communication system is also provided, the communication system including a transmitting end and a receiving end, the transmitting end and the receiving end being communicatively connected; The sending end is used to collect a sequence of verification events triggered by the processor design under test within the current verification cycle; the sequence of verification events includes verification events corresponding to at least two verification types. The sending end is used to take any of the verification types contained in the verification event sequence as the type to be packaged, and determine the region length of the verification event corresponding to the type to be packaged in the verification event sequence; The sending end is used to package the verification events contained in the verification event sequence within the current verification period based on the region length of each of the types to be packaged, and use them as the data packets to be transmitted in the current verification period. The sending end is used to splice together data packets to be transmitted for at least one verification period to obtain a spliced ​​packet of a preset size, and send the spliced ​​packet to the receiving end; The receiving end is used to receive the spliced ​​packet sent by the sending end and to unpack the spliced ​​packet.

[0007] In a fourth aspect of the present invention, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus. Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the method described in the first or second aspect above.

[0008] In a fifth aspect of the invention, a computer-readable storage medium is also provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the method described in the first or second aspect above.

[0009] In a sixth aspect of the invention, a computer program product comprising instructions is also provided, which, when run on a computer, causes the computer to perform the method described in the first or second aspect above.

[0010] The communication method provided in this invention involves the sending end collecting a sequence of verification events triggered by the processor's design under test within the current verification period. The verification event sequence includes verification events corresponding to at least two verification types. Any verification type in the verification event sequence is used as a packet type, and the region length of the verification event corresponding to that packet type in the verification event sequence is determined. Based on the region length of each packet type, the verification events included in the verification event sequence within the current verification period are packetized to obtain a data packet to be transmitted for the current verification period. The data packets to be transmitted for at least one verification period are concatenated to obtain a concatenated packet of a preset size, and the concatenated packet is sent to the receiving end. The receiving end receives the concatenated packet sent by the sending end and unpacks the concatenated packet. Thus, by packaging verification events of multiple verification types, this invention can achieve the transmission of multiple verification events in a single communication, reducing communication costs. Furthermore, this invention does not use a fixed offset during the packaging process but rather packages based on the region length of each packet type, which improves the flexibility of the packaging process. Meanwhile, by splicing together the data packets to be transmitted in at least one verification cycle to obtain a spliced ​​packet of a preset size, multiple cycles of packaged data can be assembled into a fixed-size transmission packet based on cross-type packaging to adapt to the port width and protocol requirements of the software and hardware interfaces. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0012] Figure 1 This is a flowchart illustrating the steps of a communication method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a communication system provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the steps of another communication method in an embodiment of the present invention; Figure 4 A schematic diagram of the workflow of a communication system provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of another communication system in an embodiment of the present invention; Figure 6 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

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

[0014] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, the first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In embodiments of this invention, the term "multiple" refers to two or more, and other quantifiers are similar.

[0015] Figure 1 This is a flowchart illustrating the steps of a communication method according to an embodiment of the present invention. The method can be applied to a transmitting end in a communication system, which also includes a receiving end, and the transmitting end and receiving end are communicatively connected. Figure 1 As shown, the method may include: Step 101: During the current verification cycle, collect the sequence of verification events triggered by the processor design under test; the sequence of verification events contains verification events corresponding to at least two verification types.

[0016] Step 102: Take any of the verification types contained in the verification event sequence as the type to be packaged, and determine the region length of the verification event corresponding to the type to be packaged in the verification event sequence.

[0017] Step 103: Based on the region length of each of the types to be packaged, package the verification events contained in the verification event sequence within the current verification period to obtain the data packet to be transmitted for the current verification period.

[0018] Step 104: Concatenate the data packets to be transmitted for at least one verification period to obtain a concatenated packet of a preset size, and send the concatenated packet to the receiving end. The receiving end is used to receive the concatenated packet sent by the sending end and unpack the concatenated packet.

[0019] Regarding steps 101-104 above, this embodiment of the invention can be applied to any communication system consisting of a hardware side and a software side within a co-simulation verification framework. Accordingly, the transmitting end can be a hardware simulation platform, and the receiving end can be a reference model such as an instruction set simulator. Furthermore, the transmitting end and the receiving end can be communicatively connected. Specifically, the communication connection can be achieved through hardware and software communication methods such as Peripheral Component Interconnect Express (PCIe) or Ethernet. Of course, other methods can also be used, and this embodiment of the invention does not limit this.

[0020] It should be noted that in processor co-simulation verification, the processor design-under-test (DUT) circuitry and a software-implemented instruction set simulator (also known as a reference model) are simulated simultaneously. After each processor instruction is executed, the architectural states of the two are compared to verify the correctness of the DUT implementation. The processor simulation framework extracts processor verification events, such as instruction commits and register updates, after each instruction execution and transmits them to the reference model for comparison.

[0021] Existing processor verification solutions mainly include two technical approaches: simulation of the processor design under test based on software simulators (such as open-source simulators (Verilator), compiled simulators (VCS), and modeling simulators (ModelSim)) and simulation based on hardware simulation platforms (such as hardware simulators (Emulator) and field-programmable gate arrays (FPGA)). Among these, the software simulator-based approach is speed-limited when simulating large-scale integrated circuits, capable of simulating only a few thousand processor cycles per second, which cannot meet the simulation requirements of long-term, large-scale verification workloads. To address the speed issues of software emulators, the industry has introduced hardware simulation platforms based on FPGAs or dedicated emulators. The processor design under test is deployed on the hardware simulation platform, while the software reference model is deployed on a host computer with a complex instruction set computer architecture (such as x86) or a reduced instruction set computer architecture (such as Advanced RISC Machines, ARM), forming a "software-hardware co-simulation" architecture. Verification events are transmitted through hardware and software communication methods such as Peripheral Component Interconnect Express (PCIe), Ethernet, and InfiniBand (IB).

[0022] Figure 2 This is a schematic diagram of a communication system provided in an embodiment of the present invention. The communication system can be a hardware / software co-simulation architecture, such as... Figure 2 As shown, the hardware-software co-simulation architecture can include a hardware simulation platform and a software runtime environment. The processor design under test can run on the hardware simulation platform, while reference models such as instruction set simulators can be deployed in the software runtime environment. The hardware simulation platform can be an Emulator or an FPGA, and the software runtime environment can be a host computer using x86 or ARM architecture. Accordingly, both can use different clock frequencies; for example, the hardware side can use 1~50MHz, and the software side can use 50~100MHz. Of course, they can also use the same frequency, and this embodiment of the invention does not impose any limitations on this.

[0023] During hardware-software communication, numerous verification events of different types occur. Each valid verification event triggers a hardware-software communication, transmitting data to the software side. For example, when a processor submits an instruction, the corresponding verification event is valid, triggering a communication that transmits the instruction content to the software side. Taking the DiffTest co-simulation verification framework as an example, it covers 32 verification events, generating an average of approximately 15 communications per simulation cycle. Because each hardware-software communication requires a conversion from hardware circuit signals to software data, the hardware simulation platform and the software-side host computer need to perform hardware-software handshakes and pauses, resulting in high hardware-software communication overhead.

[0024] The aforementioned verification period can be a pre-set simulation period, such as 1 minute, 10 minutes, 30 seconds, etc., and can be set according to actual verification requirements. This embodiment of the invention does not impose any restrictions on this. The aforementioned processor design under test can be a pre-set processor design to be verified. The aforementioned verification event refers to the state change information generated by the processor during operation. There can be multiple verification event types, such as instruction submission, register update, memory access, etc.

[0025] The aforementioned verification event sequence can include a series of verification events triggered by the processor design under test (DUT). Specifically, the sending end can monitor the DUT based on verification requirements, and when a valid event is detected, it adds that event as a verification event to the verification event sequence. For example, taking a register update event, the verification framework connects a probe to the processor register file. When a register value changes, the probe records the updated value as a verification event, such as "Registry 32 has been updated, and the updated value is X". Specifically, the aforementioned verification event sequence can include verification events corresponding to at least two verification types.

[0026] Specifically, during co-simulation, the data structure and length of verification events of the same verification type are completely identical. In this embodiment of the invention, for verification events of the same verification type, a multi-way selection tree (muxtree) can be used to collect these events in parallel. Furthermore, during the collection process, this embodiment of the invention can instantiate a set of prefix counters for each triggered verification event to count the number of valid verification events triggered before that verification event. Therefore, the number of verification events of the same verification type can be counted through this prefix counter.

[0027] Furthermore, in this embodiment of the invention, verification events of the same verification type can be clustered, and the region length of verification events of the same verification type can be determined. Optionally, in this embodiment of the invention, step 102 can be performed when the number of verification events of the same verification type reaches a preset value. For example, when the prefix counter value of a certain verification event is K-1, and the verification event is validly triggered, the event can be used as the Kth item to be packaged.

[0028] The aforementioned region length refers to the number of bytes in the verification event. This region length can be determined by the number and type of verification events. For example, taking instruction submission as the type to be packaged, if each instruction in the processor instruction set architecture is 16 bytes long, and the verification event sequence contains verification events for two instruction submissions, then the region length of the verification event corresponding to the instruction submission is 16 * 2 = 32 bytes.

[0029] Furthermore, in this embodiment of the invention, each verification event contained in the verification event sequence within the current verification period can be packaged based on the region length of each type to be packaged, to obtain the data packet to be transmitted in the current verification period.

[0030] Optionally, in this embodiment of the invention, verification events corresponding to any of the types to be packaged are stored continuously in the data packets to be transmitted; verification events corresponding to different types to be packaged are stored continuously in the data packets to be transmitted.

[0031] It should be noted that related technologies typically employ a fixed offset method, which pre-allocates a fixed offset and fixed length space for each type of event, and fills the corresponding fixed space with each type of event. This allows all verification events within a processor simulation cycle to be packaged into a single long data packet and transmitted to the software side, requiring only one hardware-software handshake and pause. Specifically, on the hardware side, valid verification events are filled into the allocated space, while invalid events are filled with bubbles to maintain overall alignment. The software side extracts and parses the data based on the space allocated to each type of event. However, in existing co-simulation verification frameworks, there are many types of verification events with significant length differences, and they are often not simultaneously valid. Taking the verification practice of the open-source high-performance processor "Xiangshan" as an example, the actual verification process included more than 32 types of verification events, with structural length differences exceeding 170 times. In processor verification practice, the length difference between different verification events can reach up to 170 times, and the number of valid events in different cycles also varies greatly. Existing fixed offset packaging schemes result in a significant decrease in communication efficiency. When invalid verification events are used, bubble filling is employed, resulting in over 60% invalid bubbles and wasted bandwidth in the data packets. Compared to ideal bubble-free transmission, this requires 1.67 times more hardware and software communication. Furthermore, the fixed offset scheme also suffers from insufficient scalability. When new verification event types are introduced or event lengths change, the data packet structure needs to be redefined, leading to poor compatibility and flexibility.

[0032] In this case, the present invention embodiment can make the verification events corresponding to any type to be packaged in the data packet to be transmitted stored continuously, and the verification events corresponding to different types to be packaged are stored continuously. That is, in the data packet to be transmitted, the A-type verification events are stored continuously first, then the B-type verification events are stored continuously, and so on. This can eliminate cavitation in the data packet to a certain extent, realize compact packaging between events, reduce invalid cavitation, and improve the utilization of transmission bandwidth.

[0033] Furthermore, to ensure compatibility with the port width and protocol requirements of the hardware and software interfaces, embodiments of the present invention can further concatenate the data packets to be transmitted for at least one verification cycle to obtain a concatenated packet of a preset size. The preset size can be set based on the actual port width and protocol requirements of the hardware and software interfaces, and embodiments of the present invention do not impose any limitations on this.

[0034] Furthermore, the spliced ​​packet can be sent to the receiving end. Accordingly, the receiving end can receive the spliced ​​packet sent by the sending end, and after unpacking the spliced ​​packet, obtain the verification event. Then, the receiving end can perform subsequent processor verification operations based on the verification event.

[0035] In summary, the communication method provided by this invention is applied to the transmitting end of a communication system. Within the current verification period, it collects a sequence of verification events triggered by the processor's design under test. The verification event sequence includes verification events corresponding to at least two verification types. Any verification type included in the verification event sequence is used as a packet type, and the region length of the verification event corresponding to that packet type in the verification event sequence is determined. Based on the region length of each packet type, the verification events included in the verification event sequence within the current verification period are packetized to obtain a data packet to be transmitted in the current verification period. The data packets to be transmitted in at least one verification period are concatenated to obtain a concatenated packet of a preset size, and the concatenated packet is sent to the receiving end. The receiving end receives the concatenated packet sent by the transmitting end and unpacks the concatenated packet. Thus, by packaging verification events of multiple verification types, this invention can achieve the transmission of multiple verification events in a single communication, reducing communication costs. Furthermore, this invention does not use a fixed offset during the packaging process but rather packages based on the region length of each packet type, which improves the flexibility of the packaging process. Meanwhile, by splicing together the data packets to be transmitted in at least one verification cycle to obtain a spliced ​​packet of a preset size, multiple cycles of packaged data can be assembled into a fixed-size transmission packet based on cross-type packaging to adapt to the port width and protocol requirements of the software and hardware interfaces.

[0036] Optionally, the operation of packaging the verification events contained in the verification event sequence within the current verification period based on the region length of each of the types to be packaged, to obtain the data packet to be transmitted in the current verification period, may specifically include the following in this embodiment of the invention: S21. Select a type to be packaged as the starting type, add the verification event corresponding to the starting type in the verification event sequence to the starting storage position in the data packet to be transmitted, and divide the starting type into the packaged group.

[0037] S22. Select a type to be packaged that does not belong to the packaged group as the target type, and determine the offset corresponding to the target type based on the region length of each type to be packaged in the packaged group.

[0038] S23. Based on the starting storage location and the offset corresponding to the target type, determine the storage location corresponding to the target type as the target location.

[0039] S24. Add the verification event corresponding to the target type in the verification event sequence to the target position, and classify the target type into the packaged group.

[0040] S25. Re-execute the operation of selecting a type to be packaged that does not belong to the packaged group as the target type, and determining the offset corresponding to the target type based on the region length of each type to be packaged in the packaged group, until there is no type to be packaged that does not belong to the packaged group in the verification event sequence within the current verification period, and obtain the data packet to be transmitted.

[0041] Specifically, to ensure continuous storage of each verification event, the above-mentioned packaging operation can be implemented through steps S21-S25. That is, the verification events corresponding to each type to be packaged are stored sequentially and continuously starting from the starting storage position. First, a type to be packaged is selected as the starting type, and the verification events corresponding to the starting type are added to the starting storage position and assigned to the packaged group. Further, another type to be packaged that does not belong to the above-mentioned packaged group can be selected again, and its offset can be determined. Specifically, this offset can be determined based on the region length of each type to be packaged in the packaged group, and the offset can be the sum of the region lengths of each type to be packaged in the packaged group. Further, the packaged group can contain the structure identifier of each type to be packaged, which can represent the type of the type to be packaged and the number of verification events it contains. For example, if the packaged group contains two types of types to be packaged, the structure identifier of the first type is "2 instruction commits", and the structure identifier of the second type is "4 register updates", then the offset of the third type of event is: 2 × instruction commit length + 4 × register length.

[0042] Furthermore, the storage location corresponding to the target type can be determined based on the starting storage location and the offset. Specifically, the target location can be obtained by offsetting the starting storage location by the aforementioned offset. Further, the verification event corresponding to the target type can be added to the determined target location, and the target type can be assigned to the packaged group.

[0043] Furthermore, the operations of S22 to S24 above can be performed again until there are no unpacked types that do not belong to the packaged group. This indicates that all unpacked types have been packaged. Then, the verification events stored in the packaged group from the starting storage position to the last target position can be used as data packets to be transmitted.

[0044] Understandably, after packaging valid events of the same category, this invention further packages different types of events together within the same cycle. For each type of event, this invention dynamically calculates the offset of the event to be packaged based on the structure length and number of valid events in the preceding event metadata, and allocates a storage area in a data packet to it, thereby achieving on-demand allocation of space for different types of events and eliminating invalid bubbles.

[0045] Furthermore, since the number of valid events varies greatly in different periods, the offset and region length of each type of event are dynamically calculated in this step, thereby ensuring that different types of events can be arranged compactly, avoiding a large number of cavitation bubbles generated by the traditional fixed offset method, and improving the utilization of transmission bandwidth.

[0046] Optionally, the operation of sending the spliced ​​packet to the receiving end described above may specifically include, in this embodiment of the invention: S31. Generate a structure identifier for the splicing package; the structure identifier includes the verification type of the verification events contained in the splicing package, the number of verification events corresponding to the verification type, and the splicing order of the verification events corresponding to each verification type.

[0047] S32. The splicing packet and the structure identifier are sent to the receiving end. Specifically, the receiving end is used to extract the event data corresponding to each verification type from the splicing packet based on the structure identifier, and call the reconstruction function corresponding to each verification type to restore each event data to each verification event.

[0048] The aforementioned structure identifier can include the verification type of the verification events contained in the concatenated packet, the number of verification events contained in each verification type, and the concatenation order of the verification events corresponding to each verification type. Through this structure identifier, the receiving end can dynamically extract the compactly packaged verification events, thereby restoring the original data structure of the events and achieving a flexible and efficient parsing process.

[0049] For example, if the structure identifier of the splicing packet indicates that there are 2 instruction submission events, 4 register update events, etc. in the splicing packet, then the software side (receiving end) will extract the data corresponding to each event from the splicing packet in sequence according to the arrangement information.

[0050] Furthermore, taking the instruction commit event as an example, bytes 1-8 represent the instruction counter, bytes 9-16 represent the instruction type, and so on. During hardware packaging, in order to dynamically write verification data to any offset in the data packet, the hardware side treats the verification event as an unformatted byte stream, for example, a total of 16 bytes. During software packaging, the software side, based on the structure identifier, can know that these 16 bytes are the instruction commit event, thereby restoring the original data structure of the event, using the first 8 bytes as the instruction counter, and the last 8 bytes as the instruction type, etc.

[0051] Optionally, the structure identifier of the concatenated packet can include the structure identifiers of each type to be packaged. Based on this, the verification events in the concatenated packet can be concatenated with each type to be packaged separately. For example, the first structure identifier in the concatenated packet is "2 command submissions", and each command corresponding to the command submission type has a length of 16 bytes. According to the structure identifier, it can be known that the first 16 bytes in the data packet correspond to the first command submission, and the second 16 bytes correspond to the second command submission.

[0052] In this way, structural identifiers can facilitate the receiving end to unpack the spliced ​​packets while ensuring communication efficiency, thus guaranteeing the accuracy of communication.

[0053] Optionally, the operation of splicing together data packets to be transmitted for at least one verification period to obtain a spliced ​​packet of a preset size may specifically include, in this embodiment of the invention: If the size of the data packet to be transmitted in any verification period is less than the preset size, the data packet to be transmitted is used as the data packet to be spliced. The verification events corresponding to at least one type to be packaged are split from the data packet to be transmitted in another verification period as sub-data packets. The data packet to be spliced ​​is spliced ​​with the sub-data packets to form a spliced ​​packet of the preset size.

[0054] Specifically, since the length of a single cycle's packet is variable, there may be situations where the remaining space in the transmission packet is insufficient to accommodate the complete data of a cycle. Therefore, this invention can split the cycle data according to different types of boundaries, so that the first part can fill the remaining space of the current transmission packet, and the remaining part automatically enters the next transmission packet.

[0055] This method effectively reduces the bandwidth loss caused by merging variable-length data with different periods into fixed-length data packets, and reduces the number of data packets required for cross-platform communication.

[0056] Figure 3 This is a flowchart illustrating the steps of another communication method provided in an embodiment of the present invention. The method is applied to a receiving end in a communication system, which also includes a transmitting end. The transmitting end is communicatively connected to the receiving end, as shown below. Figure 3 As shown, the method may include: Step 201: Receive the spliced ​​packet and unpack the spliced ​​packet; the spliced ​​packet is sent by the sending end.

[0057] The sending end is used to collect a sequence of verification events triggered by the processor design under test within the current verification period; the sequence of verification events contains verification events corresponding to at least two verification types; any verification type contained in the sequence of verification events is taken as a type to be packaged, and the region length of the verification event corresponding to the type to be packaged in the sequence of verification events is determined; based on the region length of each type to be packaged, the verification events contained in the sequence of verification events within the current verification period are packaged as a data packet to be transmitted in the current verification period; the data packets to be transmitted in at least one verification period are spliced ​​together to obtain a spliced ​​packet of a preset size, and the spliced ​​packet is sent to the receiving end.

[0058] The aforementioned verification period can be a pre-set simulation period, such as 1 minute, 10 minutes, 30 seconds, etc., and can be set according to actual verification requirements. This embodiment of the invention does not impose any restrictions on this. The aforementioned processor design under test can be a pre-set processor design to be verified. The aforementioned verification event refers to the state change information generated by the processor during operation. There can be multiple verification event types, such as instruction submission, register update, memory access, etc.

[0059] The aforementioned verification event sequence can include a series of verification events triggered by the processor design under test (DUT). Specifically, the sending end can monitor the DUT based on verification requirements, and when a valid event is detected, it adds that event as a verification event to the verification event sequence. For example, taking a register update event, the verification framework connects a probe to the processor register file. When a register value changes, the probe records the updated value as a verification event, such as "Registry 32 has been updated, and the updated value is X". Specifically, the aforementioned verification event sequence can include verification events corresponding to at least two verification types.

[0060] Specifically, during co-simulation, the data structure and length of verification events of the same verification type are completely identical. In this embodiment of the invention, for verification events of the same verification type, a multi-way selection tree (muxtree) can be used to collect these events in parallel. Furthermore, during the collection process, this embodiment of the invention can instantiate a set of prefix counters for each triggered verification event to count the number of valid verification events triggered before that verification event. Therefore, the number of verification events of the same verification type can be counted through this prefix counter.

[0061] Furthermore, in this embodiment of the invention, verification events of the same verification type can be clustered, and the region length of verification events of the same verification type can be determined. Optionally, in this embodiment of the invention, step 102 can be performed when the number of verification events of the same verification type reaches a preset value. For example, when the prefix counter value of a certain verification event is K-1, and the verification event is validly triggered, the event can be used as the Kth item to be packaged.

[0062] The aforementioned region length refers to the number of bytes in the verification event. This region length can be determined by the number and type of verification events. For example, taking instruction submission as the type to be packaged, if each instruction in the processor instruction set architecture is 16 bytes long, and the verification event sequence contains verification events for two instruction submissions, then the region length of the verification event corresponding to the instruction submission is 16 * 2 = 32 bytes.

[0063] Furthermore, in this embodiment of the invention, each verification event contained in the verification event sequence within the current verification period can be packaged based on the region length of each type to be packaged, to obtain the data packet to be transmitted in the current verification period.

[0064] Optionally, in this embodiment of the invention, verification events corresponding to any of the types to be packaged are stored continuously in the data packets to be transmitted; verification events corresponding to different types to be packaged are stored continuously in the data packets to be transmitted.

[0065] It should be noted that related technologies typically employ a fixed offset method, which pre-allocates a fixed offset and fixed length space for each type of event, and fills the corresponding fixed space with each type of event. This allows all verification events within a processor simulation cycle to be packaged into a single long data packet and transmitted to the software side, requiring only one hardware-software handshake and pause. Specifically, on the hardware side, valid verification events are filled into the allocated space, while invalid events are filled with bubbles to maintain overall alignment. The software side extracts and parses the data based on the space allocated to each type of event. However, in existing co-simulation verification frameworks, there are many types of verification events with significant length differences, and they are often not simultaneously valid. Taking the verification practice of the open-source high-performance processor "Xiangshan" as an example, the actual verification process included more than 32 types of verification events, with structural length differences exceeding 170 times. In processor verification practice, the length difference between different verification events can reach up to 170 times, and the number of valid events in different cycles also varies greatly. Existing fixed offset packaging schemes result in a significant decrease in communication efficiency. When invalid verification events are used, bubble filling is employed, resulting in over 60% invalid bubbles and wasted bandwidth in the data packets. Compared to ideal bubble-free transmission, this requires 1.67 times more hardware and software communication. Furthermore, the fixed offset scheme also suffers from insufficient scalability. When new verification event types are introduced or event lengths change, the data packet structure needs to be redefined, leading to poor compatibility and flexibility.

[0066] In this case, the present invention embodiment can make the verification events corresponding to any type to be packaged in the data packet to be transmitted stored continuously, and the verification events corresponding to different types to be packaged are stored continuously. That is, in the data packet to be transmitted, the A-type verification events are stored continuously first, then the B-type verification events are stored continuously, and so on. This can eliminate cavitation in the data packet to a certain extent, realize compact packaging between events, reduce invalid cavitation, and improve the utilization of transmission bandwidth.

[0067] Furthermore, to ensure compatibility with the port width and protocol requirements of the hardware and software interfaces, embodiments of the present invention can further concatenate the data packets to be transmitted for at least one verification cycle to obtain a concatenated packet of a preset size. The preset size can be set based on the actual port width and protocol requirements of the hardware and software interfaces, and embodiments of the present invention do not impose any limitations on this.

[0068] Furthermore, the spliced ​​packet can be sent to the receiving end. Accordingly, the receiving end can receive the spliced ​​packet sent by the sending end, and after unpacking the spliced ​​packet, obtain the verification event. Then, the receiving end can perform subsequent processor verification operations based on the verification event.

[0069] In summary, the communication method provided by this invention allows for the transmission of multiple verification events in a single communication by packaging verification events of various verification types at the sending end, thereby reducing communication costs. Furthermore, this invention does not use a fixed offset during the packaging process; instead, it packages data based on the region length of each type to be packaged, improving packaging flexibility. Additionally, by concatenating data packets to be transmitted for at least one verification cycle to obtain a pre-sized concatenated packet, multiple cycles of packaged data can be assembled into a fixed-size transmission packet based on cross-type packaging, adapting to the port width and protocol requirements of hardware and software interfaces.

[0070] Optionally, the sending end is further configured to: generate a structure identifier for the spliced ​​packet; the structure identifier includes the verification type of the verification events contained in the spliced ​​packet, the number of verification events corresponding to each verification type, and the splicing order of the verification events corresponding to each verification type; and send the spliced ​​packet and the structure identifier to the receiving end.

[0071] The above-mentioned unpacking operation of the spliced ​​packet may specifically include: Based on the structure identifier, the event data corresponding to each verification type is extracted sequentially from the splicing packet, and the reconstruction function corresponding to each verification type is called respectively to restore each event data to each verification event.

[0072] Specifically, for example, in a data packet, there might be two instruction commit events, four register update events, etc. The software side extracts the data corresponding to each event from the data packet based on the arrangement information. Taking the instruction commit event as an example, bytes 1-8 represent the instruction counter, bytes 9-16 represent the instruction type, and so on. During hardware packaging, in order to dynamically write verification data to any offset in the data packet, the hardware side treats the verification events as an unformatted byte stream, for example, a total of 16 bytes. During software packaging, the software side, based on the structure identifier, can identify that these 16 bytes are instruction commit events, thereby reconstructing the data structure, using the first 8 bytes as the instruction counter, the last 8 bytes as the instruction type, etc.

[0073] Specifically, the aforementioned reconstruction function can be pre-set and is used to restore different types of event data to their original structure.

[0074] Thus, even when there are significant differences in event structures and tight packaging across cycles, the embodiments of the present invention can still accurately and effectively complete event decoding and structure recovery on the software side, thereby ensuring the correctness and efficiency of the verification framework.

[0075] It should be noted that in existing collaborative simulation verification frameworks, there are many types of verification events with large differences in length, and they are often not simultaneously valid. Taking the verification practice of the open-source high-performance processor "Xiangshan" as an example, the length difference between different verification events in the processor verification practice can reach up to 170 times, and the number of valid events in different periods also varies greatly. The existing fixed-offset packetization scheme uses bubble filling when the verification event is invalid, resulting in more than 60% invalid bubbles and bandwidth waste in the data packet. Compared with ideal bubble-free transmission, it requires 1.67 times more hardware and software communication. In addition, the fixed-offset scheme also has insufficient scalability. When a new type of verification event is introduced or the event length changes, the data packet structure needs to be redefined, resulting in poor compatibility and flexibility. It also suffers from the drawback of high hardware and software communication frequency, which limits the simulation performance.

[0076] In the embodiments of the present invention, Figure 4 This is a schematic diagram of the operation flow of a communication system provided in an embodiment of the present invention, such as... Figure 4 As shown, the step-by-step process (Batch Flow) is as follows: On the hardware side, the sending end is represented by the Monitor, which indicates that the verification framework extracts verification events from the processor. For example, in cycle 0, there are two instruction commit events (Instr.commit, IC) and two register update events (Reg Update, RU). In cycle 1, there is one IC event and one RU event.

[0077] Pack corresponds to packaging. During the packaging process, each type of event in each cycle is concatenated separately. For example, in cycle 0, two instruction commits are tightly concatenated together, generating a structure identifier indicating "two instruction commits". Further, the data and identifiers of different types of events in each cycle are concatenated separately. For instance, in cycle 0, two instruction commits and two register updates are concatenated together. The offset of the register updates is calculated based on the identifier and is the sum of the lengths of the two instruction commits.

[0078] Furthermore, data packets from different periods can be concatenated to obtain a concatenated packet awaiting transmission. The data and identifier from period 0 and period 1 can be concatenated separately.

[0079] Unpack corresponds to the unpacking process on the receiving end (software side). The software side can parse the received concatenated packet based on the structure identifier (Meta-guide parse). Through the structure identifier, it can be known that the data packet contains "2 command commits, 2 register updates, 1 command commit, and 1 register update" in sequence. The software parsing function extracts the data of the corresponding length for each event and then restores its data interface.

[0080] This invention utilizes the structural information of verification data to package only valid verification events, eliminating the need to fill in bubbles for invalid events. It also supports compact packaging between different verification events, thereby transmitting the same verification event with fewer data packets. This optimizes hardware and software communication, reduces communication frequency, and accelerates the overall collaborative simulation verification process. It achieves bubble-free compact packaging, effectively reducing hardware and software communication requirements and fully leveraging the acceleration advantages of the hardware simulation platform. This solves the problem of high hardware and software communication frequency in related technologies, which limits simulation performance.

[0081] This invention enables the compact packaging of verification events of different architecture types during the hardware and software communication process in co-simulation, effectively eliminating cavitation in communication data and thus significantly reducing communication frequency. Experimental results based on the DiffTest co-simulation verification framework show that this solution can reduce the hardware and software communication frequency by 43 times and improve the overall co-simulation acceleration performance by 12–28 times. This solution has been successfully applied to the hardware simulation platform co-simulation verification framework of the "Xiangshan" processor, supporting 32 types of architecture verification events, including control flow, register updates, memory access, caching and consistency, and instruction set architecture (ISA) extensions. In actual verification, it has helped discover and fix more than 150 complex design defects.

[0082] Optionally, embodiments of the present invention can adopt a Reduced Instruction Set Computer V (RISC-V) standard to design a universal interface, thus making it applicable to all RISC-V processors and providing good portability. Simultaneously, it can be implemented using an agile design language (Chisel). Only the design interface needs to be connected to the processor under test; the remaining communication code can be automatically generated, enabling rapid deployment in RISC-V processor verification tasks and significantly improving the verification efficiency and reliability of complex processors.

[0083] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0084] Figure 5 This is a schematic diagram of another communication system in an embodiment of the present invention, such as... Figure 5 As shown, the system 30 may include a transmitter 301 and a receiver 302, which are communicatively connected.

[0085] The sending end is used to collect a sequence of verification events triggered by the processor design under test within the current verification cycle; the sequence of verification events includes verification events corresponding to at least two verification types. The sending end is used to take any of the verification types contained in the verification event sequence as the type to be packaged, and determine the region length of the verification event corresponding to the type to be packaged in the verification event sequence; The sending end is used to package the verification events contained in the verification event sequence within the current verification period based on the region length of each of the types to be packaged, and use them as the data packets to be transmitted in the current verification period. The sending end is used to splice together data packets to be transmitted for at least one verification period to obtain a spliced ​​packet of a preset size, and send the spliced ​​packet to the receiving end; The receiving end is used to receive the spliced ​​packet sent by the sending end and to unpack the spliced ​​packet.

[0086] Optionally, verification events corresponding to any of the types to be packaged are stored continuously in the data packets to be transmitted; verification events corresponding to different types to be packaged are stored continuously in the data packets to be transmitted.

[0087] Optionally, the sending end is further configured to: Select a type to be packaged as the starting type, add the verification events corresponding to the starting type in the verification event sequence to the starting storage position in the data packet to be transmitted, and classify the starting type into the packaged group; Select a type to be packaged that does not belong to the packaged group as the target type, and determine the offset corresponding to the target type based on the region length of each type to be packaged in the packaged group; The target location is determined based on the starting storage location and the offset corresponding to the target type; Add the verification event corresponding to the target type in the verification event sequence to the target position, and classify the target type into the packaged group; The process of selecting a type to be packaged that does not belong to the packaged group as the target type and determining the offset corresponding to the target type based on the region length of each type to be packaged in the packaged group is repeated until there is no type to be packaged that does not belong to the packaged group in the verification event sequence within the current verification period, thus obtaining the data packet to be transmitted.

[0088] Optionally, the sending end is further configured to: generate a structure identifier for the spliced ​​packet; the structure identifier includes the verification type of the verification events contained in the spliced ​​packet, the number of verification events corresponding to the verification type, and the splicing order of the verification events corresponding to each verification type; The splicing packet and the structural identifier are sent to the receiving end; The receiving end is specifically used to extract the event data corresponding to each verification type from the splicing packet in sequence based on the structure identifier, and call the reconstruction function corresponding to each verification type to restore each event data to each verification event.

[0089] Optionally, the sending end is further configured to: if the size of the data packet to be transmitted in any verification period is less than the preset size, use the data packet to be transmitted as a data packet to be spliced, split the verification events corresponding to at least one type to be packaged from the data packet to be transmitted in another verification period as sub-data packets, and splice the data packet to be spliced ​​with the sub-data packets to form a spliced ​​packet of the preset size.

[0090] Optionally, the sending end is further configured to: generate a structure identifier for the spliced ​​packet; the structure identifier includes the verification type of the verification events contained in the spliced ​​packet, the number of verification events corresponding to each verification type, and the splicing order of the verification events corresponding to each verification type; and send the spliced ​​packet and the structure identifier to the receiving end; The receiving end is further configured to: extract event data corresponding to each verification type sequentially from the splicing packet based on the structure identifier, and call the reconstruction function corresponding to each verification type respectively to restore each event data to each verification event.

[0091] In summary, the communication system provided by this embodiment of the invention includes a transmitting end that, within the current verification period, collects a sequence of verification events triggered by the processor's design under test; the verification event sequence contains verification events corresponding to at least two verification types; any verification type contained in the verification event sequence is taken as a packaging type, and the region length of the verification event corresponding to the packaging type in the verification event sequence is determined; based on the region length of each packaging type, the verification events contained in the verification event sequence within the current verification period are packaged to obtain a data packet to be transmitted in the current verification period; the data packets to be transmitted in at least one verification period are spliced ​​together to obtain a spliced ​​packet of a preset size, and the spliced ​​packet is sent to the receiving end; the receiving end is used to receive the spliced ​​packet sent by the transmitting end and unpack the spliced ​​packet. Thus, by packaging verification events of multiple verification types, this embodiment of the invention can achieve the transmission of multiple verification events in a single communication, reducing communication costs. Furthermore, this embodiment of the invention does not use a fixed offset during the packaging process, but rather packages based on the region length of each packaging type, which improves the flexibility of packaging. Meanwhile, by splicing together the data packets to be transmitted in at least one verification cycle to obtain a spliced ​​packet of a preset size, multiple cycles of packaged data can be assembled into a fixed-size transmission packet based on cross-type packaging to adapt to the port width and protocol requirements of the software and hardware interfaces.

[0092] As the system implementation is basically similar to the method implementation, it is described in a relatively simple way. For relevant details, please refer to the description of the method implementation.

[0093] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0094] Regarding the communication device in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0095] This invention also provides an electronic device, including: a processor and a memory for storing processor-executable instructions, wherein the processor is configured to execute the above-described communication method.

[0096] Reference Figure 6 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Figure 6As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to execute the communication method of the aforementioned embodiment.

[0097] It should be noted that the electronic devices in the embodiments of this application include mobile electronic devices and non-mobile electronic devices.

[0098] The processor can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), a FPGA (Field Programmable Gate Array), or other programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0099] The communication bus may include a path for transmitting information between the memory and the communication interface. The communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0100] The memory may be ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or it may be EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disk Read Only), magnetic tape, floppy disk and optical data storage devices, etc.

[0101] This invention also provides a non-transitory computer-readable storage medium that, when instructions in the storage medium are executed by a processor of an electronic device (server or terminal), enables the processor to perform... Figure 1 The communication method shown.

[0102] This invention also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform... Figure 1 The communication method shown.

[0103] This application also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described communication method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0104] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0105] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0106] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid state disks (SSDs)).

[0107] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0108] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0109] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0110] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0111] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0112] It should be noted that the various data-related processes in the embodiments of this application are carried out in compliance with the relevant data protection laws and policies of the country where the location is located, and with the authorization granted by the owner of the corresponding device.

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

[0114] The communication method, apparatus, electronic device, and readable storage medium provided by the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A communication method, characterized in that, The method is applied to a transmitting end in a communication system, the communication system further including a receiving end, the transmitting end and the receiving end being communicatively connected; the method includes: During the current verification cycle, a sequence of verification events triggered by the processor design under test is collected; the sequence of verification events contains verification events corresponding to at least two verification types. Take any of the verification types contained in the verification event sequence as the type to be packaged, and determine the region length of the verification event in the verification event sequence corresponding to the type to be packaged; Based on the region length of each of the types to be packaged, the verification events contained in the verification event sequence within the current verification period are packaged to obtain the data packet to be transmitted in the current verification period. The data packets to be transmitted for at least one verification period are spliced ​​together to obtain a spliced ​​packet of a preset size, and the spliced ​​packet is sent to the receiving end; The receiving end is used to receive the spliced ​​packet sent by the sending end and to unpack the spliced ​​packet.

2. The method according to claim 1, characterized in that, The verification events corresponding to any of the types to be packaged are stored consecutively in the data packets to be transmitted; the verification events corresponding to different types to be packaged are stored consecutively in the data packets to be transmitted.

3. The method according to claim 2, characterized in that, Based on the region length of each of the types to be packaged, the verification events contained in the verification event sequence within the current verification period are packaged to obtain the data packet to be transmitted in the current verification period, including: Select a type to be packaged as the starting type, add the verification events corresponding to the starting type in the verification event sequence to the starting storage position in the data packet to be transmitted, and classify the starting type into the packaged group; Select a type to be packaged that does not belong to the packaged group as the target type, and determine the offset corresponding to the target type based on the region length of each type to be packaged in the packaged group; The target location is determined based on the starting storage location and the offset corresponding to the target type; Add the verification event corresponding to the target type in the verification event sequence to the target position, and classify the target type into the packaged group; The process of selecting a type to be packaged that does not belong to the packaged group as the target type and determining the offset corresponding to the target type based on the region length of each type to be packaged in the packaged group is repeated until there is no type to be packaged that does not belong to the packaged group in the verification event sequence within the current verification period, thus obtaining the data packet to be transmitted.

4. The method according to claim 1, characterized in that, Sending the spliced ​​packet to the receiving end includes: Generate a structure identifier for the spliced ​​packet; the structure identifier includes the verification type of the verification events contained in the spliced ​​packet, the number of verification events corresponding to the verification type, and the splicing order of the verification events corresponding to each verification type; The splicing packet and the structural identifier are sent to the receiving end; The receiving end is specifically used to extract the event data corresponding to each verification type from the splicing packet in sequence based on the structure identifier, and call the reconstruction function corresponding to each verification type to restore each event data to each verification event.

5. The method according to claim 1, characterized in that, The step of concatenating data packets to be transmitted from at least one verification period to obtain a concatenated packet of a preset size includes: If the size of the data packet to be transmitted in any verification period is less than the preset size, the data packet to be transmitted is used as the data packet to be spliced. The verification events corresponding to at least one type to be packaged are split from the data packet to be transmitted in another verification period as sub-data packets. The data packet to be spliced ​​is spliced ​​with the sub-data packets to form a spliced ​​packet of the preset size.

6. A communication method, characterized in that, The method is applied to a receiving end in a communication system, the communication system further including a transmitting end, the transmitting end being communicatively connected to the receiving end; the method includes: Receive the spliced ​​packet and unpack the spliced ​​packet; the spliced ​​packet was sent by the sending end; The sending end is used to collect a sequence of verification events triggered by the processor design under test within the current verification period; the sequence of verification events contains verification events corresponding to at least two verification types; any verification type contained in the sequence of verification events is taken as a type to be packaged, and the region length of the verification event corresponding to the type to be packaged in the sequence of verification events is determined; based on the region length of each type to be packaged, the verification events contained in the sequence of verification events within the current verification period are packaged as a data packet to be transmitted in the current verification period; the data packets to be transmitted in at least one verification period are spliced ​​together to obtain a spliced ​​packet of a preset size, and the spliced ​​packet is sent to the receiving end.

7. The method according to claim 6, characterized in that, The sending end is further configured to: generate a structure identifier for the spliced ​​packet; the structure identifier includes the verification type of the verification events contained in the spliced ​​packet, the number of verification events corresponding to each verification type, and the splicing order of the verification events corresponding to each verification type; The splicing packet and the structural identifier are sent to the receiving end; The unpacking of the spliced ​​packet includes: Based on the structure identifier, the event data corresponding to each verification type is extracted sequentially from the splicing packet, and the reconstruction function corresponding to each verification type is called respectively to restore each event data to each verification event.

8. A communication system, characterized in that, The communication system includes a transmitter and a receiver, and the transmitter and the receiver are communicatively connected. The sending end is used to collect the sequence of verification events triggered by the processor design under test within the current verification cycle; The verification event sequence contains verification events corresponding to at least two verification types; The sending end is used to take any of the verification types contained in the verification event sequence as the type to be packaged, and determine the region length of the verification event corresponding to the type to be packaged in the verification event sequence; The sending end is used to package the verification events contained in the verification event sequence within the current verification period based on the region length of each of the types to be packaged, and use them as the data packets to be transmitted in the current verification period. The sending end is used to splice together data packets to be transmitted for at least one verification period to obtain a spliced ​​packet of a preset size, and send the spliced ​​packet to the receiving end; The receiving end is used to receive the spliced ​​packet sent by the sending end and to unpack the spliced ​​packet.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

11. A computer program, characterized in that, The computer program is executed by a computer to implement the method as described in any one of claims 1-7.

Images