Function verification method, device, equipment and storage medium

Abstract

The application provides a function verification method, device and equipment and a storage medium, and relates to the chip technical field. The function verification method comprises the following steps: configuring a link parameter of an adapter, wherein the adapter is used for connecting a first verification component and a device under test; sending a link establishment signal to the device under test based on the link parameter through the adapter, so as to establish a link between the first verification component and the device under test; and after the link is established, converting transaction data transmitted on the link based on the link parameter through the adapter, so as to perform function verification on the device under test. The above method improves the verification efficiency of the verification platform.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a functional verification method, apparatus, device, and storage medium. Background Technology

[0002] In the field of chip technology, after the chip design is completed, a verification platform is needed to verify the chip's functionality. In the verification platform, data transmission occurs between the verification components and the device under test (DUT) via a link.

[0003] In related technologies, when performing functional verification on a chip, the physical layer of the device under test (DUT) first undergoes link training, which includes negotiating the data transmission rate and determining the link width. After the link training is completed, functional verification of the DUT begins.

[0004] However, the link training process consumes a significant amount of time and computational resources. Especially in environments requiring the execution of multiple test cases, link training is necessary at the start of each test case, leading to a decrease in the verification efficiency of the verification platform. Summary of the Invention

[0005] This application provides a functional verification method, apparatus, device, and storage medium. The technical solutions provided by this application are as follows.

[0006] According to one aspect of the embodiments of this application, a functional verification method is provided, the method comprising: Configure the link parameters of the adapter, which is used to connect the first verification component and the device under test; The adapter sends a link establishment signal to the device under test based on the link parameters to establish a link between the first verification component and the device under test. After the link is established, the adapter converts the transaction data transmitted on the link based on the link parameters to verify the functionality of the device under test.

[0007] According to one aspect of the embodiments of this application, a functional verification apparatus is provided, the apparatus comprising: The parameter configuration module is used to configure the link parameters of the adapter, which is used to connect the first verification component and the device under test. The link establishment module is used to send a link establishment signal to the device under test based on the link parameters through the adapter to establish a link between the first verification component and the device under test; The data conversion module is used to convert the transaction data transmitted on the link based on the link parameters through the adapter after the link is established, so as to perform functional verification on the device under test.

[0008] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described functional verification method.

[0009] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is loaded and executed by a processor to implement the above-described functional verification method.

[0010] According to one aspect of the embodiments of this application, a chip is provided, the chip including programmable logic circuits and / or program instructions, which, when the chip is running, are used to implement the above-described functional verification method.

[0011] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being loaded and executed by a processor to implement the above-described functional verification method.

[0012] The technical solution provided in this application can bring the following beneficial effects: By configuring link parameters, the adapter can generate a link establishment signal and send it to the device under test (DUT) to establish a link. On one hand, the physical layer of the DUT does not need to perform link training during the link establishment process, thus reducing the time and computational resources required for link establishment. On the other hand, when each test case starts, the adapter can directly establish the link based on the link parameters corresponding to the test case, without repeatedly performing link training. Furthermore, after the link is established, the adapter can convert the transaction data transmitted on the link based on the link parameters to achieve functional verification of the DUT. Therefore, the above technical solution ensures normal functional verification while reducing the time and computational resources required for link establishment, thereby improving the verification efficiency of the verification platform. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a schematic diagram of a verification platform provided in one possible implementation of the related technology; Figure 2 This is a flowchart of a functional verification method provided in one possible implementation of this application; Figure 3 This is a flowchart of link establishment provided in one possible implementation of this application; Figure 4 This is a schematic diagram of the verification platform provided in one possible implementation of this application; Figure 5 This is a schematic diagram of an adapter provided in one possible implementation of this application; Figure 6 This is a schematic diagram illustrating data transformation provided in one possible implementation of this application; Figure 7 This is a structural block diagram of a functional verification device provided in one possible implementation of this application; Figure 8 This is a structural block diagram of a computer device provided in one possible implementation of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0016] Before introducing the technical solution proposed in this application, the relevant technical background and related technologies will be briefly described below.

[0017] With the development of high-speed interconnect technology, data interaction between chips is becoming increasingly complex. Taking Compute Express Link (CXL) technology as an example, CXL is a high-speed interconnect protocol used to improve communication efficiency between components such as the Central Processing Unit (CPU), Graphics Processing Unit (GPU), and Field Programmable Gate Array (FPGA) and memory expansion devices. Within CXL technology, the CXL.mem protocol is used to implement memory access transactions between the host and memory expansion devices. Therefore, functional verification of the CXL.mem protocol is necessary to ensure its correctness and reliability in data routing, error handling, and performance.

[0018] For related technologies, please refer to Figure 1 , Figure 1This is a schematic diagram of a verification platform provided in one possible implementation of the related technology. The aforementioned verification platform is based on the Universal Verification Methodology (UVM) and includes a CXL Verification Intellectual Property Core (VIP) 110, a VIP 120, a reference model 130, a scoreboard 140, a Device Under Test (DUT) 150, an Arbiter (ARB) 160, a Physical Layer (PL, also known as the Flex bus physical layer) 170, and an interface 180. The DUT 150 internally contains a Transaction Layer (TL) 151 and a Link Layer (LL) 152. The Arbiter 160 and the Physical Layer 170 are connected between the DUT 150 and the VIP 120.

[0019] VIP 110 connects to the transaction layer 151 of the device under test 150 via interface 180, and is used to send stimuli to the device under test 150 and collect transactions of the transaction layer 151. VIP 120 connects to the physical layer 170 for data interaction with the physical layer 170. Reference model 130 is connected to VIP 110 and scoreboard 140 respectively, and is used to generate expected results based on the stimuli sent by VIP 110. Scoreboard 140 is connected to VIP 110, VIP 120 and reference model 130 respectively, and is used to compare the expected results generated by reference model 130 with the actual results collected by VIP 110 and VIP 120 for functional verification.

[0020] In the aforementioned verification platform, both VIP 110 and VIP 120 internally encapsulate agents. Each agent contains a driver, a monitor, and a sequencer, used to generate stimuli and acquire signals. Specifically, the sequencer schedules sequences and delivers randomized sequence items to the driver, which converts them into precise timing sequences to drive the device under test (DUT) 150. The monitor acquires bus signals, generates transaction data, and sends it to the scoring board 140 via a Transaction Level Modeling (TLM) port.

[0021] It is worth noting that each time a test case is run, the device under test (DUT) 150 needs to be trained into a specific protocol mode through link training. Link Training and Status State Machine (LTSSM) is the core control logic of PCIe (Peripheral Component Interconnect Express, a high-speed serial computer expansion bus standard) and the physical layer 170. It is used to automatically negotiate the speed, bit width, and signal equalization when two ports are powered on, reset, or reconnected, and to stably enter a normal operating state (L0 state). For example, depending on the device's capabilities, the DUT can be trained into one of the following modes: CXL.IO, CXL.cache, CXL.mem, or CXL.cache+CXL.mem. Only after training is complete, i.e., after the LTSSM enters the L0 state, is the corresponding transaction data sent and functional verification performed.

[0022] However, the aforementioned technologies have the following technical problems: Functional verification of the transaction and link layers of the device under test mainly focuses on routing, packetization, and retransmission, neglecting the link training process at the physical layer. However, due to the presence of the arbitrator and the physical layer, verification of the transaction and link layer functions must wait for the physical layer to complete link training. Link training involves processes such as rate negotiation, bit width configuration, and signal equalization, consuming significant simulation time and computational resources. Especially in verification scenarios requiring the execution of numerous test cases, each test case must repeatedly undergo the link training process upon startup, leading to reduced verification efficiency of the verification platform.

[0023] To address the aforementioned problems, this application provides a functional verification method. For example, please refer to... Figure 2 , Figure 2 This is a flowchart of a functional verification method provided in one possible implementation of this application. The functional verification method may include at least one of the following steps 210 to 230.

[0024] Step 210: Configure the link parameters of the adapter. The adapter is used to connect the first verification component and the device under test.

[0025] In one aspect of this embodiment, link parameters refer to configuration information used to describe the transmission characteristics of the link between the verification component and the device under test. Link parameters determine the physical transmission characteristics and data transmission format of the link, serving as the basis for subsequent link establishment and transaction data conversion. By configuring link parameters, the adapter can operate according to preset transmission characteristics without requiring hardware auto-negotiation. Specifically, link parameters can include various parameters related to link transmission. For example, link parameters can include link configuration parameters indicating the link width; protocol format parameters indicating the data transmission format; speed mode parameters indicating the transmission rate; and protocol type parameters indicating the protocol currently running on the link.

[0026] In one specific embodiment, the link parameters may include, but are not limited to, at least one of the following: 1. Link configuration: Used to indicate the bit width of the link, such as x1, x2, x4, x8, x16, etc.

[0027] 2. Protocol Format: Indicates the flit (flow control unit) format used by the link. The flow control unit is the basic unit of data transmission at the link layer. For example, the protocol format may include 68B (68 bytes), 68B VH (Virtual Hierarchy), 256B PBR (Port Based Routing), 256B HBR (Hierarchy Based Routing), 256BLOPT (Latency-Optimized 256B Flit), etc.

[0028] 3. Speed ​​Mode: Used to indicate the link's transmission rate, such as 2.5GT / s (Giga Transfer per Second), 5GT / s, 8GT / s, 16GT / s, 32GT / s, etc. Here, transmission rate represents the number of data transfers per second, with GT / s being gigabit-per-second transmissions.

[0029] 4. Protocol Type: Indicates the protocol mode running on the link, such as PCIe, CXL.IO, CXL TYPE1, CXL TYPE2, CXL TYPE3, etc. CXL TYPE1, CXL TYPE2, and CXL TYPE3 are different device types defined in the CXL protocol.

[0030] By configuring the link parameters described above, different verification scenarios can be flexibly adapted. For example, in the CXL.mem verification scenario, the verification platform's speed mode can be set to 32GT / s, the link configuration to x16, and the protocol format to 256B PBR to simulate a high-speed, high-bandwidth transmission scenario. Simultaneously, depending on the type of device under test, the protocol type can be configured as CXL TYPE3. Through these configurations, targeted functional verification of the device under test can be performed.

[0031] It should be noted that the specific content of the link parameters can be selected and expanded according to actual verification needs, and this application embodiment does not limit this.

[0032] In one aspect of this embodiment, the adapter is an intermediate module connected between the first verification component and the device under test (DUT), used to enable data interaction between the two devices. The adapter is configurable and can process the data transmitted on the link according to the configured link parameters. By setting the adapter, the first verification component and the DUT can directly interact with each other without going through intermediate modules such as arbitrators or physical layers in the DUT.

[0033] In one aspect of this embodiment, the adapter can be implemented in a variety of ways. For example, the adapter can be implemented using hardware circuitry (such as an Application Specific Integrated Circuit (ASIC)); or, the adapter can be implemented using a programmable logic device (such as an FPGA); or, the adapter can be implemented using a Hardware Description Language (HDL).

[0034] In one embodiment, an adapter connects the first verification component and the link layer of the device under test (DUT). The adapter internally includes signal conversion logic capable of converting data sent by the first verification component conforming to interface timings into a data format acceptable to the DUT's link layer. For example, in a CXL verification scenario, the adapter can convert data sent by the VIP conforming to Logical Physical Interface (LPIF) timings into a data format acceptable to the DUT's link layer. In this specific embodiment, data communication between the link layers of the first verification component and the DUT is achieved through the adapter's signal conversion function.

[0035] In another embodiment, the adapter can be used to control the data transmission rate. In chip verification scenarios, the data transmission rate of the verification component and the data reception rate of the device under test (DUT) may be inconsistent, and the adapter can resolve the rate mismatch problem between the verification component and the DUT. For example, the adapter may internally include a data buffer and rate control logic. When the data transmission rate of the verification component is higher than the data reception rate of the DUT, the adapter can temporarily store the data and send it to the DUT at a lower rate; conversely, when the data transmission rate of the DUT is higher than the data reception rate of the verification component, the adapter can also perform corresponding rate adaptation. Similarly, when the verification component acts as the data receiver and the DUT acts as the data sender, the adapter can also resolve the rate mismatch problem between the verification component and the DUT, which will not be elaborated further here.

[0036] It is worth noting that the specific implementation of the adapter is not limited in the embodiments of this application. Any module or device that can connect the first verification component and the device under test and complete data communication between the first verification component and the device under test according to the configured link parameters falls within the protection scope of this application.

[0037] In one aspect of this embodiment, the first verification component is a verification module in the verification platform used to generate stimulus data, drive the device under test (DUT), and collect response data. Exemplarily, the first verification component can be implemented as a VIP. A VIP is a set of reusable, standardized, and high-coverage verification components, which can encapsulate sub-components such as drivers, monitors, and sequencers to generate transaction data conforming to a specific protocol and drive it to the DUT.

[0038] In one aspect of this embodiment, the device under test (DUT) is a target chip or chip module to be verified. The specific structure and function of the DUT depend on the actual requirements of the verification task. For example, the DUT may include layers such as a transaction layer and a link layer. The transaction layer is used to handle end-to-end business interactions and is responsible for generating and processing transaction-level data such as read / write requests, completion responses, and messages. The link layer is used to ensure reliable transmission between two directly connected ports and is responsible for transmitting the transaction layer's data packets securely, error-free, and in an orderly manner to the other end (such as the first verification component mentioned above).

[0039] In one embodiment, the first verification component is a CXL VIP, and the device under test (DUT) is a CXL.mem DUT. The CXL VIP generates transaction data conforming to the CXL protocol, and the CXL.mem DUT receives and processes this transaction data to verify the correctness and reliability of the CXL.mem DUT in memory access transactions. In another embodiment, the first verification component is a PCIe VIP, and the DUT is a PCIe device. The PCIe VIP generates transaction data conforming to the PCIe protocol, and the PCIe device receives and processes this transaction data. In the above specific embodiments, the adapter can convert the transaction data according to the configured PCIe link parameters (such as link speed, link width, etc.) to achieve functional verification of the PCIe device. In yet another embodiment, the first verification component is a high-speed interface protocol VIP (e.g., Ethernet VIP, Universal Serial Bus (USB) VIP, etc.), and the DUT is the corresponding protocol processing chip. The adapter can convert the transaction data according to the link parameters of the corresponding protocol to achieve functional verification of chips using different protocols.

[0040] It is worth noting that the embodiments of this application do not limit the specific type of the first verification component. Any verification module capable of generating stimulus data, driving the device under test, and collecting response data can serve as the first verification component. Similarly, the embodiments of this application do not limit the specific type of the device under test. Any target chip or chip module that needs to be functionally verified through a verification platform can serve as the device under test.

[0041] Step 220: The adapter sends a link establishment signal to the device under test based on the link parameters to establish a link between the first verification component and the device under test.

[0042] In one aspect of this application embodiment, the link establishment between the first verification component and the device under test (DUT) is achieved by an adapter sending a link establishment signal to the DUT. Specifically, the adapter can directly generate and send a link establishment signal to the DUT based on pre-configured link parameters to establish the link. The link establishment signal is used to instruct the DUT to perform initialization of its internal link layer, thereby entering a normal operating state. Specifically, the adapter can perform the following operations to establish the link: First, the adapter generates a link establishment signal based on the link parameters configured in step 210. The link establishment signal includes at least the aforementioned link parameters and a pause request signal. The pause request signal is used to request the DUT's link layer to pause its current data transmission / reception operation and enter a paused state.

[0043] In one embodiment, for example, please refer to Figure 3 , Figure 3This is a flowchart of link establishment provided in one possible implementation of this application. The link establishment process described above may include at least one of the following steps 310 to 340.

[0044] Step 310: Configure the adapter's link parameters. The adapter is configured according to the link parameters (including link configuration, protocol format, speed mode, protocol type, etc.) configured in step 210. At this time, the adapter is in a reset state.

[0045] Step 320: The link layer of the device under test sends a status request signal to the adapter, requesting to enter the active state. The link layer of the device under test sets the status request signal to active, requesting to enter the active state.

[0046] Step 330: The adapter sends a link establishment signal to the link layer of the device under test (DUT). The link layer initializes and returns a pause confirmation signal. The link establishment signal includes at least a pause request signal and the link parameters configured in step 310. Upon receiving the link establishment signal, the DUT's link layer initializes its configuration according to the link parameters and, in response to the pause request signal, initiates an internal data refresh process, clearing all pending data packets within the link layer. After completing the data refresh, the DUT's link layer returns a pause confirmation signal to the adapter, indicating that it has entered a paused state.

[0047] Step 340: Wait for the adapter link to be ready and the link establishment to be completed. After receiving the pause confirmation signal, the adapter checks its own link status. Once the adapter's link is ready and its status changes from reset to active, the link establishment is complete, and transaction data transmission can begin.

[0048] In this way, the embodiments of this application can quickly establish a link between the first verification component and the device under test without waiting for the physical layer to complete automatic negotiation, thereby shortening the link establishment time.

[0049] It is worth noting that this application does not limit the specific form of the link establishment signal or the interaction process, nor does it impose mandatory requirements on the execution order of the above steps. Any method of establishing a link by sending a signal to the device under test through an adapter falls within the protection scope of this application.

[0050] Step 230: After the link is established, the adapter converts the transaction data transmitted on the link based on the link parameters to verify the functionality of the device under test.

[0051] In one aspect of this embodiment, after the link is established, the first verification component and the device under test (DUT) can transmit transaction data. However, the first verification component and the DUT may use different data formats, different interface timings, or different transmission rates. For example, the first verification component may output transaction data according to the LPIF interface, while the link layer of the DUT may expect to receive transaction data in a specific format. To solve the above problems, the adapter can perform real-time conversion of the transaction data transmitted on the link based on pre-configured link parameters. Specifically, the process of the adapter converting the transaction data may include, but is not limited to: identifying the valid transmission period of the transaction data, determining the valid data format of the transaction data according to the link parameters, splitting or merging the transaction data, and performing rate adaptation when the transmission rates do not match. Through the above conversion, the first verification component and the DUT can communicate normally, thereby realizing the functional verification of the DUT.

[0052] In one embodiment, the first verification component uses a 32-bit data bus, while the link layer of the device under test (DUT) uses a 16-bit data bus. Based on this scenario, the adapter can split or merge transaction data according to the link width information configured in the link parameters. For example, when the first verification component sends 32-bit data, the adapter splits the 32-bit data into two 16-bit data sets and sends them sequentially to the link layer of the DUT; conversely, when the link layer of the DUT sends 16-bit data, the adapter merges the two 16-bit data sets into one 32-bit data set before sending it to the first verification component. This method achieves the conversion between different data widths.

[0053] In another embodiment, the first verification component sends transaction data using the AXI (Advanced eXtensible Interface) protocol, while the device under test receives transaction data using the AHB (Advanced High-performance Bus) protocol. The adapter can convert the AXI protocol transaction data to the AHB protocol transaction data according to the configured protocol type information, including address mapping, data format conversion, and control signal adaptation, enabling normal communication between modules using different bus protocols.

[0054] It is worth noting that the specific implementation method of the adapter converting transaction data is not described in detail in this embodiment, but can be found in the embodiments below. This application does not limit the specific implementation method of the adapter converting data; any method that can convert transaction data transmitted on the link based on configured link parameters falls within the protection scope of this application.

[0055] By configuring link parameters, the adapter can generate a link establishment signal based on these parameters and send it to the device under test (DUT) to establish a link. On one hand, the physical layer of the DUT does not need to perform link training during the link establishment process, thus reducing the time and computing resources required for link establishment. On the other hand, when each test case is started, the adapter can directly establish a link based on the link parameters corresponding to the test case, without repeatedly performing link training. Furthermore, after the link is established, the adapter can convert the transaction data transmitted on the link based on the link parameters to achieve functional verification of the DUT. Therefore, this embodiment of the application ensures normal functional verification while reducing the time and computing resources required for link establishment, thereby improving the verification efficiency of the verification platform.

[0056] In some embodiments, the adapter is used to replace the arbitrator and physical layer of the device under test to convert transaction data transmitted over the link.

[0057] The arbitrator, also known as an arbitrator / multiplexer, is used to arbitrate and multiplex multiple data channels. In related technologies, when multiple data channels simultaneously have transaction data to be transmitted, the arbitrator determines the data transmission order of each channel based on a preset priority or polling strategy, and merges the transaction data from multiple channels onto a single data path for transmission. It should be understood that the arbitrator is only an exemplary implementation method, and those skilled in the art will know that any component capable of multi-channel data selection and merging functions (such as a multiplexer (MUX), bus arbitrator, etc.) can be used to implement similar functions.

[0058] The physical layer is responsible for establishing and maintaining the link and transmitting transaction data. Its core functions generally include: converting parallel data into a serial bit stream for transmission over the physical medium through serialization; restoring the received serial bit stream into parallel data through deserialization; and ensuring the reliability of data transmission through encoding / decoding. It should be understood that the physical layer is merely an exemplary implementation. Those skilled in the art will recognize that any physical layer capable of establishing the link and transmitting data (such as the Flex bus physical layer, PCIe physical layer, etc.) can be used to implement similar functions.

[0059] In one aspect of this embodiment, the adapter can be directly connected between the first verification component and the link layer of the device under test. In this connection mode, single-channel transmission is used between the link layer of the first verification component and the device under test, eliminating the need for multi-channel arbitration. Therefore, the adapter itself does not need to implement arbitration functionality; it only needs to complete data communication between the first verification component and the link layer through transaction data conversion. Compared to introducing a separate arbitrator, the adapter simplifies the transmission path and avoids the additional overhead and complexity associated with arbitration logic.

[0060] In another aspect of this embodiment, the physical layer performs serialization / deserialization, encoding / decoding, and other processing on the transaction data. The essential purpose is to resolve the data format mismatch between the data sender and receiver; that is, to convert the data format at the sender to a format suitable for transmission on the physical medium and restore it to its original format at the receiver. In this embodiment, the adapter does not perform physical layer-level serialization / deserialization, encoding / decoding, etc., but instead splits or merges the transaction data based on link parameters. Specifically, when the transaction data bit width sent by the first verification component is greater than the bit width that the link layer of the device under test can receive, the adapter splits the transaction data into multiple smaller data blocks and sends them sequentially; when the transaction data bit width sent by the first verification component is less than the bit width that the link layer of the device under test can receive, the adapter merges multiple transaction data blocks into one data block before sending it. Through this method, the adapter also achieves data format adaptation between the data sender and receiver, achieving the same data transmission effect as the physical layer conversion.

[0061] In summary, the adapter replaces the arbitrator and physical layer in the two core functions of link establishment and transaction data conversion. The verification platform can establish the link and communicate transaction data between the first verification component and the device under test without relying on a separate arbitrator and physical layer, thus avoiding the link training overhead and related computing resource consumption associated with the arbitrator and physical layer.

[0062] For example, please refer to Figure 4 , Figure 4 This is a schematic diagram of a verification platform provided in one possible implementation of this application. It is worth noting that... Figure 4 In the verification platform shown, the first verification component is VIP 120, and the device under test 150 includes a transaction layer 151 and a link layer 152. Figure 1 The verification platforms shown are different. Figure 4 The verification platform shown omits the arbitrator 160 and physical layer 170; the adapter 190 is directly connected between the VIP 120 and the device under test 150. Specifically, transaction data sent by the VIP 120 no longer passes through the arbitrator 160 and physical layer 170. Instead, it is received and converted by the adapter 190 before being sent directly to the link layer 152 of the device under test 150. Conversely, transaction data sent by the link layer 152 also no longer passes through the physical layer 170 and arbitrator 160. Instead, it is received and converted by the adapter 190 before being sent directly to the VIP 120. In summary, the adapter replaces the arbitrator and physical layer in the data transmission path (i.e., the link) and is used to convert transaction data transmitted on the link.

[0063] It should be understood that Figure 4The verification platform shown is merely an exemplary implementation of this application and does not constitute a limitation on the scope of protection. Depending on the actual verification scenario and the interface of the device under test, the first verification component can be other forms of VIP, stimulus generator, or simulation model, etc.; the device under test can also contain other functional modules besides the transaction layer and link layer; the interconnection between the adapter and the link layer can adopt various feasible forms such as bus, point-to-point interface, and on-chip network. Furthermore, the arbitrator and physical layer are described in this application as having a functional role "replaced by the adapter," and their specific implementation can be completed by equivalent components such as multiplexers, bus arbitrators, and LPIFs. The internal functional structure of the adapter can also be implemented using different data processing units or logic circuits according to the link parameters and protocol format. As long as the functions of the arbitrator and physical layer can be realized during link establishment and transaction data conversion, they all fall within the scope of this application.

[0064] By replacing the arbitrator and physical layer with an adapter, the verification platform can perform functional verification of the device under test without deploying an arbitrator and / or physical layer. This simplifies the verification environment, reduces the additional overhead caused by the conversion between arbitration logic and physical layer, and thus improves the verification efficiency of the verification platform.

[0065] In some embodiments, the device under test includes a link layer, and the adapter includes: a first conversion module for converting transaction data sent by the first verification component into transaction data that the link layer of the device under test can receive; and a second conversion module for converting transaction data sent by the link layer of the device under test into transaction data that the first verification component can receive.

[0066] It is important to emphasize that in a verification platform, the link layers of the first verification component and the device under test (DUT) typically follow different interface protocols or have different interface configurations. Specifically, the first verification component, as the stimulus source or monitoring unit in the verification environment, usually defines its interface based on standard bus protocols or its internal data structures; while the DUT's link layer, as part of the actual chip design, typically follows specific link layer protocol specifications. Therefore, the two often differ in terms of transaction data bit width, packet format, and timing requirements, making direct data transmission impossible.

[0067] In one aspect of this embodiment, an adapter is set up between the link layer of the first verification component and the device under test (DUT), and the first conversion module and the second conversion module inside the adapter process the data streams in different transmission directions respectively, thereby realizing bidirectional data communication between the two. For example, the first conversion module is used to process transaction data sent by the first verification component to the link layer of the DUT. Specifically, the first conversion module receives the transaction data sent by the first verification component, performs format conversion on the transaction data according to the configured link parameters (such as link width, flow control unit format, etc.), and the converted transaction data conforms to the reception timing and data format requirements of the DUT's link layer. Further, the first conversion module sends the converted transaction data to the link layer of the DUT, thereby meeting the functional verification requirements of the DUT. Similarly, the second conversion module is used to convert the transaction data sent by the link layer of the DUT into transaction data that the first verification component can receive, which will not be elaborated here. It should be noted that the first conversion module is responsible for data conversion from the first verification component to the link layer, and the second conversion module is responsible for data conversion from the link layer to the first verification component. The two conversion modules are independent of each other, thus supporting bidirectional data conversion.

[0068] For example, please refer to Figure 5 , Figure 5 This is a schematic diagram of an adapter provided in one possible implementation of this application. As shown, the adapter 190 includes a first conversion module 191 and a second conversion module 192, and the device under test 150 includes a link layer 152. The first conversion module 191 is connected between the first verification component 510 and the link layer 152 of the device under test 150, and is used to convert transaction data sent by the first verification component 510 into transaction data that the link layer 152 can receive. The second conversion module 192 is connected between the link layer 152 and the first verification component 510, and is used to convert transaction data sent by the link layer 152 into transaction data that the first verification component 510 can receive. Through this structure, the two conversion modules in the adapter operate through their respective independent data paths, realizing bidirectional data conversion.

[0069] It is worth noting that those skilled in the art can flexibly configure the implementation of the first conversion module and the second conversion module according to the actual verification platform architecture, and this application does not limit them in this regard.

[0070] For example, in one possible implementation, the first conversion module and the second conversion module can be implemented as hardware circuits. Specifically, the first conversion module and the second conversion module can be configured as logic circuit units within an FPGA or ASIC. In the above case, the first conversion module and / or the second conversion module may include components such as an input interface circuit, a data buffer, bit-width processing logic, and an output interface circuit. The input interface circuit is used to receive transaction data, the data buffer is used to temporarily store transaction data to be processed, the bit-width processing logic performs the conversion of the transaction data through combinational logic circuits such as shift registers and multiplexers, and the output interface circuit is used to send the converted transaction data to the target end.

[0071] For example, in another possible implementation, the first conversion module and / or the second conversion module can be implemented as software programs or firmware. Specifically, the adapter can be embodied as program code or functional components running on the verification platform. The first and second conversion modules are configured as a series of computer-executable instructions that, when executed by the processor, perform operations such as reading, parsing, bit-width calculation, splitting or merging, and forwarding of transaction data. For instance, in a UVM-based verification platform, the first and second conversion modules can be implemented as part of a converter or monitor within the UVM component, simulating the aforementioned data conversion process through software algorithms.

[0072] It should be understood that the above implementation methods are merely illustrative examples of this application and do not constitute a limitation on the scope of protection of this application. The first conversion module and the second conversion module can also be implemented by a combination of hardware and software, or other logical units or functional modules with equivalent functions can be used instead, depending on the specific protocol type.

[0073] By configuring the first conversion module and the second conversion module to handle the transaction data sent from the first verification component to the device under test (DUT) and the transaction data sent from the DUT to the first verification component, respectively, independent configuration of data conversion in the two transmission directions is achieved. This architecture ensures that the data conversion processes in the two transmission directions do not interfere with each other, thereby improving the data conversion efficiency of the adapter.

[0074] In some embodiments, the transaction data transmitted on the link is converted by an adapter based on link parameters, including: obtaining the transaction data transmitted on the link and the valid indication information corresponding to the transaction data through the adapter; determining the valid period of the transmitted transaction data based on the valid indication information; and converting the transaction data based on the valid period and link parameters.

[0075] In one aspect of this embodiment, the transaction data transmitted on the link includes both transaction data sent from the first verification component to the device under test (DUT) and transaction data sent from the DUT to the first verification component; this embodiment does not limit this. For ease of description, the following description will use the application scenario of the first verification component sending transaction data to the DUT as an example. The scenario of the DUT sending transaction data to the first verification component is similar in principle and will not be elaborated further.

[0076] In one aspect of this embodiment, the transmission of transaction data on the link is not always continuous; it is often accompanied by idle periods or invalid data. To accurately identify valid data and avoid erroneous processing of invalid data, the adapter needs to acquire valid indication information corresponding to the transaction data. Valid indication information is an identification signal accompanying the transaction data transmission, used to indicate whether the transaction data on the link is valid within the current clock cycle. In one possible implementation, the valid indication information can be an independent signal line (such as a valid signal). When the valid signal is at a preset valid level (e.g., high level), it indicates that the data transmitted in the current cycle is valid transaction data; conversely, when the valid signal is at an invalid level (e.g., low level), it indicates that the data transmitted in the current cycle is invalid transaction data or the link is in an idle state.

[0077] In one aspect of this embodiment, based on valid indication information, the adapter can determine the valid period for transmitting transaction data. The valid period refers to the clock cycle interval during which the valid indication information remains in a valid state (e.g., the valid information remains high). By monitoring the level state of the valid indication information, the adapter can accurately obtain the start time, duration, and end time of the transaction data, thereby defining the transmission window for valid data. This process is crucial for subsequent data conversion because data conversion operations (such as bit width adjustment) must be performed based on the valid data window; otherwise, data misalignment or loss may occur.

[0078] In one aspect of this embodiment, the link parameters define key information such as the data bit width and protocol format that the link layer and / or the first verification component of the device under test can receive. After determining the validity period, the adapter can convert the transaction data within the validity period according to the link parameters. For example, when the bit width of the transaction data transmitted within the validity period is inconsistent with the target bit width, the adapter needs to split or merge the transaction data within the duration of the validity period to ensure that the converted transaction data meets the requirements of the receiving end in terms of bit width and format. The specific implementation process of the above steps will be described in the following embodiments and will not be repeated here.

[0079] It should be noted that this application does not limit the specific form of valid indication information. Valid indication information can be a dedicated identification signal transmitted by an independent signal line, a specific code or identifier embedded within the transaction data, or a handshake signal defined in the data transmission protocol (such as the Valid signal mentioned above). Any information that can be recognized by the adapter and used to determine the validity period of the transaction data falls within the protection scope of this application.

[0080] By introducing valid indication information and determining the valid period, the adapter can achieve precise control over the transmission of discontinuous transaction data, ensuring that data conversion operations are performed only on valid data segments, thereby improving the accuracy and reliability of data conversion and avoiding verification errors caused by invalid data.

[0081] In some embodiments, link parameters include link information and protocol information. Based on the validity period and link parameters, the transaction data is transformed, including: determining the link width based on the link information; determining the data transmission format based on the protocol information; determining the valid data format of the transaction data based on the link width and data transmission format; and splitting and / or merging the transaction data based on the valid data format and validity period to complete the transformation of the transaction data.

[0082] In one aspect of this embodiment, link information is used to describe the physical transmission attributes of the link. Exemplarily, the link information includes at least link configuration and speed mode. The link configuration indicates the physical bit width of the link, such as x1, x2, x4, x8, x16, etc. This parameter directly determines the number of data bits that the link can transmit in a single clock cycle, i.e., the link bit width. The speed mode indicates the transmission rate of the link, such as 2.5GT / s, 5GT / s, 8GT / s, 16GT / s, 32GT / s, etc. The transmission rate represents the number of data transmissions per second, and this parameter affects the timing matching of data transmission.

[0083] In one aspect of this embodiment, protocol information is used to describe the data protocol specifications of the link. Exemplarily, the protocol information includes at least a protocol format and a protocol type. The protocol format indicates the flow control unit format used by the link, where the flow control unit is the basic unit for data transmission at the link layer. Exemplarily, the protocol format may include 68B, 68B VH, 256BPBR, 256B HBR, 256B LOPT, etc.; the protocol type indicates the type of protocol the link operates on, such as PCIe, CXL.IO, CXL TYPE1, CXL TYPE2, CXL TYPE3, etc., and the protocol type determines the encapsulation structure of transaction data and command parsing rules.

[0084] It should be emphasized that the link parameters are not limited to the link configuration, speed mode, protocol format, and protocol type listed above. In other embodiments, link parameters may also include reset signals, clock signals, operating voltage parameters, etc., which are not limited in this embodiment. The above-mentioned parameters together constitute the constraints for the adapter to perform data conversion.

[0085] In one aspect of this embodiment, determining the valid data format of transaction data refers to calculating or mapping the actual bit width and arrangement structure of the valid data under the current link configuration based on the link bit width and data transmission format. It is important to emphasize that the determination of the valid data format has bidirectional applicability. For the sending side, the original transaction data sent by the first verification component needs to be mapped according to the link bit width and data transmission format to generate a valid data format that meets the current link transmission requirements. For the receiving side, the adapter also needs to parse the data stream output from the link layer based on the same link parameters to reconstruct the corresponding valid data format. In other words, whether it is the data to be sent by the first verification component or the data to be received output from the link layer of the device under test, its data structure must be determined jointly based on the link bit width and protocol format in the link parameters.

[0086] In one aspect of this embodiment, based on a determined valid data format and validity period, the adapter performs specific data splitting and / or data merging operations. This process is the core mechanism by which the adapter implements data conversion, and specifically, it may include: 1. When the bit width of the transaction data within the valid period exceeds the bit width required by the valid data format, the adapter performs a data splitting operation. Specifically, the adapter cuts the original transaction data block into multiple data slices according to the valid data format. The bit width of each data slice is consistent with the bit width of the valid data format. Subsequently, the adapter sequentially sends each data slice to the receiving end within consecutive valid periods. During the above process, the adapter needs to maintain the transmission order of the data slices to ensure that the transmission order of high-bit data and low-bit data conforms to the protocol specification and prevents data misalignment.

[0087] 2. When the bit width of transaction data within a valid period is less than the bit width required by the valid data format, the adapter performs a data merging operation. Specifically, the adapter buffers and concatenates transaction data received within multiple consecutive valid periods. When the bit width of the concatenated data meets the bit width requirement of the valid data format, the adapter sends the merged data block as a complete data unit to the receiving end. During this process, the adapter needs to monitor the buffer status and determine the continuity of transaction data based on valid indication information to ensure that the merged data block remains logically complete and correct.

[0088] 3. When the bit width of the transaction data within the valid period matches the bit width required by the valid data format, the adapter can directly send the transaction data to the receiving end without splitting or merging it.

[0089] It is worth noting that this application does not limit the specific content of link information and protocol information. In addition to the link configuration and speed mode listed above, link information may also include link status, link number, etc.; in addition to the protocol format and protocol type listed above, protocol information may also include protocol version number, verification rules, etc. Furthermore, this application does not limit the specific process for determining the valid data format; the process may be a query operation based on a preset lookup table, a calculation operation based on a preset formula, etc. Any process that determines the valid data format of transaction data based on the link width and data transmission format, and performs data conversion accordingly, should fall within the protection scope of this application.

[0090] Link information determines the link's bit width, while protocol information determines the data transmission format. In summary, link parameters precisely define the valid data format of transaction data. This allows the adapter to perform accurate data splitting or merging operations within the valid timeframe, improving the accuracy of data conversion and further enhancing the verification efficiency of the verification platform.

[0091] In some embodiments, the method further includes: when the transmission rate of transaction data meets a first preset condition, controlling the first verification component and / or the device under test to stop transmitting transaction data via an adapter; or, when the transmission rate of transaction data meets a second preset condition, controlling the first verification component and / or the device under test to continue transmitting transaction data via an adapter.

[0092] In one aspect of this embodiment, a first preset condition is used to indicate that the transmission rate of transaction data exceeds the processing capacity of the current link and / or the receiving end. For example, the first preset condition may include: the transmission rate is greater than the receiving rate, the transmission rate exceeds a preset rate threshold, or the buffer occupancy rate of the receiving end exceeds a preset occupancy threshold, etc. When any of the above conditions are met, it indicates that there is a risk of data overflow. In the above situation, the adapter can generate and send a pause signal to control the first verification component and / or the device under test to stop sending transaction data, thereby preventing data loss.

[0093] In one aspect of this embodiment, the second preset condition is used to indicate that the transmission rate of physical data is within the processing capacity range of the current link and / or the receiving end. For example, the second preset condition may include: the transmission rate is less than the receiving rate, the transmission rate is lower than a preset rate threshold, or the buffer occupancy rate of the receiving end is lower than a preset occupancy threshold, etc. When any of the above conditions are met, it indicates that the link has the ability to continue transmitting data. In the above case, the adapter can generate and send a recovery signal to control the first verification component and / or the device under test to continue transmitting transaction data, thereby restoring data transmission.

[0094] It should be noted that this application does not limit the specific manifestation of the first and second preset conditions. They can be threshold ranges defined by numerical comparison or logical conditions defined by signal states. Furthermore, this application does not limit the specific implementation method for controlling the first verification component and / or the device under test to stop or continue sending transaction data. The control method can be hardware-level signal control (such as pulling low / high ready signals) or software-level message notification or status register updates. Any implementation method that can trigger the corresponding control behavior of the adapter based on the rate condition should fall within the protection scope of this application.

[0095] By setting the first and second preset conditions, the adapter can dynamically adjust the data transmission rate according to the real-time transmission capability of the link, avoiding data overflow or loss due to rate mismatch, thereby improving the stability and reliability of data transmission during the verification process.

[0096] In one embodiment, for example, please refer to Figure 6 , Figure 6 This is a schematic diagram illustrating data transformation provided in one possible implementation of this application. Figure 6 This demonstrates the specific process by which the first conversion module 191 converts the transaction data sent by the first verification component into transaction data that the link layer of the device under test can receive. It is worth noting that, to highlight the data conversion process, neither the first verification component nor the link layer of the device under test are explicitly shown. Figure 6 As shown in the figure, please refer to the details. Figure 5 The first verification component 510 and the link layer 152 of the device under test 150 are not described in detail here.

[0097] Specifically, the first conversion module receives transaction data and validity indication information from the first verification component. This transaction data and validity indication information are determined by the link parameters configured in the verification environment. Simultaneously, the transaction data and validity indication information received by the link layer of the device under test are also affected by the link parameters. Therefore, during the data conversion process, the first conversion module can perform the following steps: 1. The first conversion module identifies the current link width and data transmission format based on the link parameters, thereby determining the valid data format of the transaction data. This step ensures that the first conversion module can accurately define the structural characteristics of the transaction data (such as the effective bit width).

[0098] 2. The first conversion module determines the valid period for transmitting transaction data based on valid indication information. By monitoring valid indication information, the first conversion module can capture the transmission window of valid data. Within the valid period, the first conversion module performs data splitting and / or data merging on the collected transaction data based on the valid data format, converting it into transaction data that meets the link layer reception requirements of the device under test. This process achieves flexible adaptation between different bit widths and protocol formats.

[0099] 3. In addition, the first conversion module also has a rate matching function. In this embodiment, the first and second preset conditions are reflected in the signal state of the receive ready signal. Specifically, when the link layer of the device under test cannot continue to receive transaction data, it will set the receive ready signal to an invalid state (e.g., pull it low) and send it to the first conversion module. After detecting the receive ready signal, the first conversion module sends it to the first verification component to control the first verification component to stop sending transaction data. Conversely, when the link layer of the device under test can continue to receive transaction data, it will set the receive ready signal to an valid state (e.g., pull it high) and send it to the first transfer module. The first conversion module then sends it to the first verification component to control the first verification component to continue sending transaction data.

[0100] Similarly, the data conversion process (i.e., the function of the second conversion module) sent from the link layer of the device under test to the first verification component is implemented in a similar way to the above process, and will not be described in detail here.

[0101] It is worth noting that, Figure 6 The illustrated embodiments are merely exemplary implementations of this application, used to demonstrate the logical flow of data conversion, and do not constitute an undue limitation on the scope of protection of this application. In specific applications, the specific internal structures, signal processing timing, and rate matching mechanisms of the first and second conversion modules can be adjusted according to the actual verification environment. For example, in addition to using a receive-ready signal, the rate matching control signal can also be implemented using other hardware logic such as counter threshold triggering and state machine transitions. Furthermore, the specific algorithms for data splitting and data merging can also be optimized according to different protocol specifications. Any scheme that determines the valid data format based on link parameters in the adapter and performs data conversion in conjunction with the valid period falls within the scope of protection of this application.

[0102] In some embodiments, the device under test includes a transaction layer and a link layer. An adapter is used to convert transaction data transmitted on the link between the first verification component and the link layer of the device under test. The method further includes: transmitting transaction data between the second verification component and the transaction layer of the device under test to perform functional verification on the device under test.

[0103] In one aspect of this embodiment, the device under test (DUT) follows a layered protocol architecture, including a transaction layer and a link layer. The transaction layer is responsible for handling transaction requests, responses, and data encapsulation for higher-level protocols, while the link layer is responsible for reliable data transmission and link management. By directly interacting with the transaction layer of the DUT through the second verification component, the complex timing of the link layer can be bypassed, allowing for targeted testing of the transaction layer's logical functions.

[0104] In one embodiment, refer to Figure 4 It should be emphasized that the first verification component corresponds to Figure 4 In VIP120, the second verification component corresponds to Figure 4 VIP 110 is included in this embodiment. In one embodiment, VIP 110 is connected to a scoring board 140 to collect actual transaction data of the transaction layer 151 of the device under test (DUT) 150. Simultaneously, VIP 110 is also connected to a reference model 130, which generates expected transaction data based on input stimuli and connects to the scoring board 140. The scoring board 140 automatically verifies the transaction layer functionality by comparing the actual transaction data from the transaction layer 151 of the DUT 150 with the expected transaction data from the reference model 130. Furthermore, VIP 120 is connected to the scoring board 140 to collect transaction data of the link layer 152 of the DUT 150. Simultaneously, VIP 120 also sends transaction data to the link layer 152 of the DUT 150 via adapter 190, thereby enabling monitoring and verification of link layer data transmission.

[0105] It should be noted that this application does not limit the specific interaction content between the second verification component and the transaction layer of the device under test, the modeling granularity of the reference model, or the comparison rules of the scoreboard. The architecture described in the above embodiments is only one possible implementation example of this application. In other embodiments, the verification platform may also include other functional modules, such as an excitation generator and a protocol checker. Any architecture that verifies the transaction layer of the device under test through the second verification component and verifies the link layer in combination with the first verification component and the adapter should fall within the protection scope of this application.

[0106] By introducing interaction between the second verification component and the transaction layer of the device under test, the architecture of the verification platform is improved. This architecture can simultaneously cover the verification requirements of both the transaction layer and the link layer, thereby improving the verification coverage and efficiency of the platform.

[0107] In some embodiments, the first verification component is used to generate Slave to Master (S2M) type transaction data and send it to the link layer of the device under test through an adapter; and / or, the second verification component is used to generate Master to Slave (M2S) type transaction data and send it to the transaction layer of the device under test.

[0108] In one aspect of this embodiment, the present application supports bidirectional path verification, covering data transmission scenarios of the device under test (DUT) under different operating modes. Specifically, S2M type transaction data is used to simulate the data transmission process from slave device to master device, and M2S type transaction data is used to simulate the data transmission process from master device to slave device. For example, in one possible implementation, for slave-to-master device verification, a first verification component generates S2M type transaction data, performs data format conversion via an adapter, and sends it to the link layer of the DUT to verify the DUT's link layer's ability to process this type of data. For master-to-slave device verification, a second verification component generates M2S type transaction data and sends it to the transaction layer of the DUT to verify the DUT's transaction layer's ability to process this type of data. It should be noted that this application does not limit the specific timing, incentive constraints, or concurrency mechanism of the transaction data generated by the first and second verification components. The S2M and M2S types described in the above embodiments are merely one possible example of this application. In other embodiments, the verification component may also generate other types of transaction data according to protocol specifications. Any scheme that uses different verification components to generate transaction data in different directions to achieve bidirectional path verification of the device under test shall fall within the protection scope of this application.

[0109] By configuring the first and second verification components to generate S2M and M2S type transaction data respectively, the verification platform constructs a complete bidirectional verification environment. This solution can flexibly simulate real data communication scenarios, comprehensively covering the S2M and M2S data paths of the device under test, thereby improving the coverage of verification scenarios and the reliability of verification results.

[0110] In some embodiments, the method further includes: sending preset raw transaction data directly to the device under test via an adapter. The data content of the raw transaction data is configurable and includes at least one of a transaction metadata field, a byte enable bit, and a tail valid indicator bit.

[0111] In one aspect of this embodiment, preset raw transaction data can be directly sent to the device under test via an adapter. The content of the raw transaction data is configurable. Specifically, the transaction metadata field carries custom or control information for the transaction; the byte enable bit indicates the validity of each byte in the transaction data, often used to identify which bytes in a data block contain valid data; and the tail validity indicator bit indicates the validity of the data packet tail, often used to identify data boundaries. By configuring these fields, the verification platform can construct raw transaction data that meets specific verification requirements.

[0112] For example, in one possible implementation, the adapter supports bypassing the transaction layer of the first and second verification components during the verification process. That is, the verifier can directly send preset raw transaction data to the device under test (DUT) through the adapter. During transmission, the adapter flexibly configures and expands key fields of the raw transaction data according to the needs of the test scenario. Specifically, the verification platform can randomize transaction metadata fields to test the DUT's parsing logic and fault tolerance capabilities for non-standard or abnormal metadata; it can configure specific byte enable bits, such as setting the enable bits corresponding to non-contiguous bytes in the target data block to a valid state, to simulate the data transmission scenario of non-contiguous data and verify the DUT's behavior in processing non-contiguous data; it can also configure a tail valid indicator bit, such as forcibly setting the indicator bit to an invalid or error state, to test the DUT's robustness in handling packet end boundaries. Through the above configuration, the verification platform can construct boundary conditions and abnormal data that are difficult to generate by the conventional transaction layer.

[0113] It should be noted that this application does not limit the specific configuration method, configuration triggering time, or specific bit width of each field for the raw transaction data. The transaction element fields, byte enable valid bits, and tail valid indicator bits listed in the above embodiments are only one possible example of this application. In other embodiments, the raw transaction data may also include other protocol-defined fields or custom fields. Any scheme that can send preset raw transaction data to the device under test through the adapter should fall within the protection scope of this application.

[0114] By sending pre-defined raw transaction data through an adapter, the verification platform can bypass the constraints of the transaction layer and directly test the boundary conditions and abnormal paths of the device under test. This mechanism enhances the flexibility of the verification scenario, expands the testing scope that conventional transaction layer verification cannot cover, and thus improves the verification coverage of the verification platform.

[0115] In some embodiments, the link supports the transmission of transaction data of various sizes.

[0116] In one aspect of this embodiment, the verification platform can flexibly support the transmission and verification of different data packet sizes to comprehensively cover various processing scenarios of the device under test at the link layer. For example, in one possible implementation, the transaction data size is a standard size. The first verification component can generate and send full-size transaction data (e.g., 64 bytes) to the device under test, following the protocol specifications indicated by the link parameters, to verify the correctness of the standard transmission path of the device under test.

[0117] In another possible implementation, the transaction data size is the fragment size. For a specific protocol scenario, the first verification component splits the transaction data into multiple data fragments for transmission. For example, the transaction data is split into a first half and a second half, and sent sequentially to the link layer of the device under test (DUT). This method verifies the DUT's link layer's ability to correctly receive, identify, and reassemble the fragmented transaction data into the original transaction data. In yet another possible implementation, the transaction data size can be the compact package size. Specifically, the first verification component can extract the tail information of multiple data packets and concatenate them tightly after the first data packet, thus achieving a tight data arrangement, i.e., obtaining transaction data of the compact package size. This method verifies the DUT's ability to parse and process discontinuous, high-density data streams.

[0118] It should be noted that this application does not limit the specific size of the transaction data. Any scheme that supports the transmission of multiple different sizes of transaction data on the link for verification should fall within the protection scope of this application.

[0119] By supporting transaction data transmission of various sizes, the verification platform can simulate complex and ever-changing data transmission scenarios in real links. It not only covers standard transmission paths, but also deeply verifies complex protocol mechanisms such as fragmentation and reassembly, and tight packing, thereby expanding the verification scenarios of the verification platform.

[0120] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0121] For example, please refer to Figure 7 , Figure 7 This is a structural block diagram of a functional verification device provided in one possible implementation of this application. The aforementioned functional verification device 700 includes a parameter configuration module 710, a link establishment module 720, and a data conversion module 730.

[0122] The parameter configuration module 710 is used to configure the link parameters of the adapter, which is used to connect the first verification component and the device under test. The link establishment module 720 is used to send a link establishment signal to the device under test based on the link parameters through the adapter to establish a link between the first verification component and the device under test; The data conversion module 730 is used to convert the transaction data transmitted on the link based on the link parameters through the adapter after the link is established, so as to perform functional verification of the device under test.

[0123] In some embodiments, the data conversion module 730 is configured to: obtain transaction data transmitted on the link and valid indication information corresponding to the transaction data through an adapter; determine the valid period of the transmitted transaction data based on the valid indication information; and convert the transaction data based on the valid period and link parameters.

[0124] In some embodiments, link parameters include link information and protocol information. The data conversion module 730 is configured to: determine the link width based on the link information; determine the data transmission format based on the protocol information; determine the valid data format of the transaction data based on the link width and data transmission format; and perform data splitting and / or data merging on the transaction data based on the valid data format and validity period to complete the conversion of the transaction data.

[0125] In some embodiments, the functional verification device 700 further includes a rate control module (not shown in the figure). The rate control module is configured to: control the first verification component and / or the device under test to stop sending transaction data when the transaction data transmission rate meets a first preset condition; or control the first verification component and / or the device under test to continue sending transaction data when the transaction data transmission rate meets a second preset condition.

[0126] In some embodiments, the adapter is used to replace the arbitrator and physical layer of the device under test to convert transaction data transmitted over the link.

[0127] In some embodiments, the device under test includes a link layer, and the adapter includes: a first conversion module for converting transaction data sent by the first verification component into transaction data that the link layer of the device under test can receive; and a second conversion module for converting transaction data sent by the link layer of the device under test into transaction data that the first verification component can receive.

[0128] In some embodiments, the device under test (DUT) includes a transaction layer and a link layer. An adapter is used to convert transaction data transmitted on the link between the first verification component and the link layer of the DUT. The functional verification apparatus 700 also includes a data transmission module (not shown). The data transmission module is used to: transmit transaction data between the second verification component and the transaction layer of the DUT to perform functional verification on the DUT.

[0129] In some embodiments, the first verification component is used to generate transaction data of the device-to-master type and send it to the link layer of the device under test through an adapter; and / or, the second verification component is used to generate transaction data of the master-to-slave type and send it to the transaction layer of the device under test.

[0130] In some embodiments, the data transmission module is used to directly send preset raw transaction data to the device under test via an adapter; wherein the data content of the raw transaction data is configurable, and the data content includes at least one of a transaction element field, a byte enable valid bit, and a tail valid indicator bit.

[0131] In some embodiments, the link supports the transmission of transaction data of various sizes.

[0132] The functional verification device provided in this application embodiment configures link parameters, enabling the adapter to generate a link establishment signal based on these parameters and send it to the device under test (DUT) to establish a link. On one hand, the physical layer of the DUT does not need to perform link training during the link establishment process, thereby reducing the time and computational resources required for link establishment. On the other hand, when each test case is started, the adapter can directly establish a link based on the link parameters corresponding to the test case, eliminating the need for repeated link training. Furthermore, after the link is established, the adapter can convert the transaction data transmitted on the link based on the link parameters to achieve functional verification of the DUT. In summary, the functional verification device provided in this application embodiment ensures normal functional verification while reducing the time and computational resources required for link establishment, thereby improving the verification efficiency of the verification platform.

[0133] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0134] For example, please refer to Figure 8 , Figure 8 This is a structural block diagram of a computer device provided in one possible implementation of this application. The computer device 800 can be any electronic device with data computing, processing, and storage functions. The computer device 800 can be used to implement the functional verification method provided in the above embodiments.

[0135] Typically, computer device 800 may include a processor 810 and a memory 820.

[0136] Processor 810 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 810 may be implemented using at least one hardware form selected from DSP (Digital Signal Processor), FPGA, and PLA (Programmable Logic Array). Processor 810 may also include a main processor and a coprocessor. The main processor, also known as the CPU, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 810 may integrate a GPU, which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 810 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0137] The memory 820 may include one or more computer-readable storage media, which may be non-transitory. The memory 820 may also include high-speed random access memory and NVM (Non-Virtual Machine). Volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage medium in memory 820 is used to store a computer program configured to be executed by one or more processors to implement the above-described functional verification method.

[0138] Those skilled in the art will understand that Figure 8 The structure shown does not constitute a limitation on the computer device 800, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0139] In an illustrative embodiment, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor of a computer device, implements the aforementioned functional verification method. Optionally, the computer-readable storage medium may be a ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, or optical data storage device, etc.

[0140] In an exemplary embodiment, a chip is also provided, the chip including programmable logic circuitry and / or program instructions, the programmable logic circuitry and / or program instructions being stored in a computer-readable storage medium. A processor of a computer device reads the programmable logic circuitry and / or program instructions from the computer-readable storage medium, and the processor executes the programmable logic circuitry and / or program instructions, causing the computer device to perform the aforementioned functional verification method.

[0141] In an exemplary embodiment, a computer program product is also provided, which includes a computer program that is loaded and executed by a processor to implement the above-described functional verification method.

[0142] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes 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, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0143] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A functional verification method, characterized in that, The method includes: Configure the link parameters of the adapter, which is used to connect the first verification component and the device under test; The adapter sends a link establishment signal to the device under test based on the link parameters to establish a link between the first verification component and the device under test. After the link is established, the adapter converts the transaction data transmitted on the link based on the link parameters to verify the functionality of the device under test.

2. The method according to claim 1, characterized in that, The step of converting transaction data transmitted on the link based on the link parameters via the adapter includes: The adapter obtains the transaction data transmitted on the link and the valid indication information corresponding to the transaction data. Based on the valid indication information, determine the valid period for transmitting the transaction data; The transaction data is transformed based on the validity period and the link parameters.

3. The method according to claim 2, characterized in that, The link parameters include link information and protocol information; The transformation of the transaction data based on the validity period and the link parameters includes: Based on the link information, the link width of the link is determined; Based on the protocol information, the data transmission format of the link is determined; Based on the link bit width and the data transmission format, determine the valid data format of the transaction data; Based on the valid data format and the valid period, the transaction data is split and / or merged to complete the transformation of the transaction data.

4. The method according to claim 1, characterized in that, The method further includes: If the transmission rate of the transaction data meets a first preset condition, the adapter controls the first verification component and / or the device under test to stop transmitting the transaction data; or... If the transmission rate of the transaction data meets the second preset condition, the adapter controls the first verification component and / or the device under test to continue transmitting the transaction data.

5. The method according to claim 1, characterized in that, The adapter is used to replace the arbitrator and physical layer of the device under test in order to convert the transaction data transmitted on the link.

6. The method according to claim 1, characterized in that, The device under test includes a link layer, and the adapter includes: The first conversion module is used to convert the transaction data sent by the first verification component into transaction data that the link layer of the device under test can receive. The second conversion module is used to convert the transaction data sent by the link layer of the device under test into transaction data that the first verification component can receive.

7. The method according to claim 1, characterized in that, The device under test includes a transaction layer and a link layer. The adapter is used to convert transaction data transmitted on the link between the first verification component and the link layer of the device under test. The method further includes: The second verification component transmits transaction data between itself and the transaction layer of the device under test to perform functional verification of the device under test.

8. The method according to claim 7, characterized in that, The first verification component is used to generate transaction data of the device-to-master type and send it to the link layer of the device under test through the adapter; and / or, The second verification component is used to generate transaction data of master-to-slave type and send it to the transaction layer of the device under test.

9. The method according to claim 1, characterized in that, The method further includes: The adapter sends preset raw transaction data directly to the device under test; wherein the data content of the raw transaction data is configurable, and the data content includes at least one of the following: transaction element field, byte enable valid bit, and tail valid indicator bit.

10. The method according to claim 1, characterized in that, The link supports the transmission of transaction data of various sizes.

11. A functional verification device, characterized in that, The device includes: The parameter configuration module is used to configure the link parameters of the adapter, which is used to connect the first verification component and the device under test. The link establishment module is used to send a link establishment signal to the device under test based on the link parameters through the adapter to establish a link between the first verification component and the device under test; The data conversion module is used to convert the transaction data transmitted on the link based on the link parameters through the adapter after the link is established, so as to perform functional verification on the device under test.

12. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the method as claimed in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 10.

14. A chip, characterized in that, The chip includes programmable logic circuitry and / or program instructions, which, when the chip is running, are used to implement the method as described in any one of claims 1 to 10.

15. A computer program product, characterized in that, The computer program product includes a computer program that is loaded and executed by a processor to implement the method as claimed in any one of claims 1 to 10.

Images