Serial expansion bus hardware acceleration verification method, device, equipment and storage medium

Abstract

This application provides a method, apparatus, device, and storage medium for hardware-accelerated verification of a serial expansion bus. The method includes: instantiating a first verification unit and a second verification unit in a hardware-accelerated verification platform; interconnecting the serial expansion bus interfaces of the first and second verification units; providing a clock signal to the verification environment through a clock port unit of the hardware-accelerated verification platform; setting the first verification unit to master mode and the second verification unit to slave mode, and performing a first-direction test; after completing the first-direction test, switching the first verification unit back to slave mode and the second verification unit back to master mode, and performing a second-direction test. This method is used to realize bidirectional interconnection function verification of the serial expansion bus interface in the pre-silicon stage, improving the bus interface verification coverage and overall verification efficiency.

Description

Technical Field

[0001] This application relates to the field of hardware testing, and in particular to a method, apparatus, device, and storage medium for hardware acceleration verification of a serial extended bus. Background Technology

[0002] Serial expansion buses, as the core interconnect carrier for high-speed data interaction in smart terminal chips, are widely used in functional interaction and data transmission scenarios across various chip platforms. In the chip development process, pre-silicon hardware acceleration verification is a crucial step in ensuring the stability, protocol compatibility, and hardware performance of high-speed interfaces. The completeness of interface verification directly determines the overall design quality of the chip and the reliability of the end product.

[0003] In existing hardware-accelerated verification schemes, the verification of the serial expansion bus interface of the chip under test (DUT) typically relies on a protocol conversion component provided with the platform. This component consists of a dedicated hardware board and interface packaging logic, and its core function is to convert the simulation signals inside the hardware-accelerated verification platform into standard-compliant physical interface signals, thereby enabling the DUT to connect with external physical devices or development kits. Under this architecture, the verification environment presents a clear master-slave unidirectional structure, with the DUT fixedly configured to play a single role: either as a master device connecting to external slave devices, or as a slave device receiving access from external master devices.

[0004] Existing hardware acceleration verification platforms rely on external protocol conversion components and cannot load self-developed physical layer modules. This prevents the pre-silicon stage from performing real functional verification and bidirectional interactive testing of the physical layer of the serial extended bus interface. Consequently, physical layer design flaws are difficult to expose before tape-out, and pre-silicon software development and debugging cannot cover physical layer-related scenarios. This shifts a large number of verification issues to the post-silicon stage, significantly increasing the difficulty and time cost of debugging after tape-out, and potentially leading to chip redesign. Summary of the Invention

[0005] This application provides a serial extended bus hardware acceleration verification method, apparatus, device, and storage medium to improve bus interface verification coverage and overall verification efficiency.

[0006] In a first aspect, embodiments of this application provide a serial extended bus hardware acceleration verification method, including:

[0007] Instantiate the first verification unit and the second verification unit in the hardware-accelerated verification platform;

[0008] Interconnect the serial expansion bus interfaces of the first verification unit and the second verification unit;

[0009] The clock port unit of the hardware-accelerated verification platform provides a clock signal to the verification environment.

[0010] By modifying the role identifier values ​​of the first verification unit and the second verification unit, the first verification unit is set to master device mode and the second verification unit is set to slave device mode, and the first direction test is performed.

[0011] After completing the first direction test, the role identifier values ​​of the first verification unit and the second verification unit are modified to switch the first verification unit to slave mode and the second verification unit to master mode, and then the second direction test is executed.

[0012] In one possible implementation, instantiating the first verification unit and the second verification unit in the hardware-accelerated verification platform includes:

[0013] Obtain the design data for the physical layer unit of the serial extended bus;

[0014] The simulation portion of the design data is described as a synthesizable model using a synthesizable model language.

[0015] The digital portion of the design data is described as a register-transfer-level model using register-transfer-level language.

[0016] Based on the synthesizable model and the register transfer level model, the physical layer unit and control unit in the first verification unit and the second verification unit are instantiated.

[0017] In one possible implementation, the simulation portion of the design data is described as a synthesizable model using a synthesizable model language, including:

[0018] Obtain preset physical layer signal interference characteristic data;

[0019] Based on the signal interference characteristic data, a crosstalk model and / or a noise model are integrated into the synthesizable model;

[0020] The synthesizable model, which integrates the crosstalk model and / or the noise model, is used as the transformation result of the simulation part.

[0021] In one possible implementation, it also includes:

[0022] Obtain the preset phase-locked loop empty processing configuration information;

[0023] Based on the empty processing configuration information, the phase-locked loop units inside the first verification unit and the second verification unit are configured to be in an empty state so that the phase-locked loop units do not participate in clock generation.

[0024] In one possible implementation, performing a first-direction test or performing a second-direction test includes:

[0025] Obtain preset fault configuration information;

[0026] A preset fault is written to the verification environment based on the fault configuration information;

[0027] Record the response data of the first verification unit and / or the second verification unit under fault scenarios.

[0028] In one possible implementation, modifying the role identifier values ​​of the first verification unit and the second verification unit includes:

[0029] Obtain historical test scenario data;

[0030] Extract test result feature data from the historical test scenario data;

[0031] The test result feature data is input into a pre-trained machine learning model to obtain the test parameter configuration;

[0032] Based on the aforementioned test parameter configuration, an automated test script is generated;

[0033] The automated test script writes the role identifier value to the preset mode configuration register.

[0034] Secondly, embodiments of this application provide a serial extended bus hardware acceleration verification apparatus, comprising:

[0035] A building block is used to instantiate the first and second verification units in the hardware-accelerated verification platform.

[0036] The construction module is also used to interconnect the serial expansion bus interfaces of the first verification unit and the second verification unit;

[0037] The building module is also used to provide a clock signal to the verification environment through the clock port unit of the hardware acceleration verification platform;

[0038] The testing module is used to modify the role identifier values ​​of the first verification unit and the second verification unit, setting the first verification unit to master device mode and the second verification unit to slave device mode, and to perform a first-direction test.

[0039] The testing module is also used to, after completing the first direction test, modify the role identifier values ​​of the first verification unit and the second verification unit to switch the first verification unit to slave device mode and the second verification unit to master device mode, and then execute the second direction test.

[0040] In one possible implementation, the building module is specifically used for:

[0041] Obtain the design data for the physical layer unit of the serial extended bus;

[0042] The simulation portion of the design data is described as a synthesizable model using a synthesizable model language.

[0043] The digital portion of the design data is described as a register-transfer-level model using register-transfer-level language.

[0044] Based on the synthesizable model and the register transfer level model, the physical layer unit and control unit in the first verification unit and the second verification unit are instantiated.

[0045] In one possible implementation, the building module is further configured to:

[0046] Obtain preset physical layer signal interference characteristic data;

[0047] Based on the signal interference characteristic data, a crosstalk model and / or a noise model are integrated into the synthesizable model;

[0048] The synthesizable model, which integrates the crosstalk model and / or the noise model, is used as the transformation result of the simulation part.

[0049] In one possible implementation, the building module is further configured to:

[0050] Obtain the preset phase-locked loop empty processing configuration information;

[0051] Based on the empty processing configuration information, the phase-locked loop units inside the first verification unit and the second verification unit are configured to be in an empty state so that the phase-locked loop units do not participate in clock generation.

[0052] In one possible implementation, the test module is specifically used for:

[0053] Obtain preset fault configuration information;

[0054] A preset fault is written to the verification environment based on the fault configuration information;

[0055] Record the response data of the first verification unit and / or the second verification unit under fault scenarios.

[0056] In one possible implementation, the test module is further configured to:

[0057] Obtain historical test scenario data;

[0058] Extract test result feature data from the historical test scenario data;

[0059] The test result feature data is input into a pre-trained machine learning model to obtain the test parameter configuration;

[0060] Based on the aforementioned test parameter configuration, an automated test script is generated;

[0061] The automated test script writes the role identifier value to the preset mode configuration register.

[0062] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0063] The memory stores computer-executed instructions;

[0064] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0065] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0066] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0067] In a sixth aspect, embodiments of this application provide a chip, the chip including at least one processor, the processor being configured to execute program instructions to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0068] The serial extended bus hardware acceleration verification method, apparatus, device, and storage medium provided in this application embodiment directly build two identical verification units inside the hardware acceleration verification platform and complete their interconnection. By using the platform's own clock drive and dynamically modifying the role settings of the two units to make them take turns acting as master and slave devices for bidirectional mutual testing, the self-developed physical layer can fully participate in the verification process without the need for external conversion devices, thereby achieving the effect of improving the bus interface verification coverage and overall verification efficiency. Attached Figure Description

[0069] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0070] Figure 1 A schematic diagram illustrating a scenario for verifying the hardware acceleration of the serial expansion bus provided in this application;

[0071] Figure 2 A flowchart illustrating the serial expansion bus hardware acceleration verification method provided in this application;

[0072] Figure 3 A schematic diagram of the structure of the serial expansion bus hardware acceleration verification example provided in this application;

[0073] Figure 4 A schematic diagram of the serial expansion bus hardware acceleration verification device provided in this application;

[0074] Figure 5 A schematic diagram of the structure of the electronic device provided in this application.

[0075] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0076] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0077] The serial expansion bus hardware acceleration verification method refers to a method that verifies the functionality of the serial expansion bus interface by instantiating verification units and interconnecting them in a hardware acceleration verification platform, using the platform clock as the driver, and dynamically modifying the role identifier value to perform bidirectional testing.

[0078] Hardware accelerated verification platform: refers to hardware equipment that performs large-scale logic simulation through dedicated processor arrays or programmable logic arrays for pre-silicon verification of chips.

[0079] Verification Unit: Refers to a functional module instantiated within the hardware-accelerated verification platform, containing a serial extended bus physical layer and control logic, which can be configured as a master device or a slave device according to the role identifier value.

[0080] Serial expansion bus interface: refers to a serial communication interface used for high-speed data exchange between chips, supporting point-to-point full-duplex data transmission.

[0081] Clock port unit: refers to the hardware module in the hardware acceleration verification platform used to generate and distribute clock signals, providing a stable clock source for the verification environment.

[0082] Verification environment: refers to the test runtime environment composed of instantiated verification units, interconnect interfaces, and clock drivers.

[0083] Role Identifier Value: This refers to the parameter written to the mode configuration register, which specifies whether the verification unit is currently running as a master or slave device.

[0084] Master mode: refers to the working mode of the master device in a serial extended bus architecture, which is responsible for initiating transaction requests and managing data exchange.

[0085] Slave mode: refers to the slave device working mode in a serial extended bus architecture that responds to master device requests and performs corresponding operations.

[0086] First-direction test: refers to the data interaction test performed after setting the first verification unit as the master device and the second verification unit as the slave device.

[0087] Second-direction testing refers to the data interaction test performed after the first-direction test is completed, by switching the first verification unit to the slave device and the second verification unit to the master device.

[0088] Serial expansion bus physical layer module: refers to the circuit module that implements the physical layer function of the serial expansion bus interface, including analog and digital parts.

[0089] Synthesizable model language: refers to a hardware description language used to describe the behavior of circuits that can be synthesized into hardware logic by a hardware acceleration verification platform.

[0090] Register-transfer level language: refers to a hardware description language that describes digital circuits based on the data flow and logical operations between registers.

[0091] Phase-locked loop (PLL) unit: refers to a closed-loop feedback circuit unit used to generate and synchronize clock signals.

[0092] Fault configuration information: refers to the set of control parameters used to inject preset abnormal events into the verification environment.

[0093] Mode configuration register: refers to a read-write storage unit used to store verification unit working mode configuration information such as role identifier value.

[0094] Automated test scripts refer to a set of program instructions generated based on historical test data, which can automatically complete the writing of role identifier values ​​and the execution of tests.

[0095] The specific application scenario of this application is the hardware acceleration testing stage of the serial expansion bus during the chip development phase, suitable for high-speed interface function verification and link interaction verification. Based on the above scenario, it is clear that existing technologies, relying on fixed role configurations for interface testing, can only complete data transmission verification in one direction, resulting in limited testing scenarios and a technical problem where bidirectional interaction conditions cannot be fully covered.

[0096] The serial extended bus hardware acceleration verification method provided in this application solves the technical problem that traditional interface testing cannot take into account bidirectional transmission scenarios and has insufficient verification coverage dimensions by building a dual-set verification unit interconnection environment, supporting operation with a unified clock, flexibly switching the working modes of the two sets of units, and performing bidirectional tests step by step.

[0097] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0098] Figure 1 A schematic diagram illustrating the application scenario of the serial expansion bus hardware acceleration verification method provided in this application, such as... Figure 1 As shown, it includes: terminal 101 and server 102.

[0099] Terminal 101 is used to send test commands to server 102. The test commands include configuration parameters for modifying the role identifier value of the verification unit. Server 102 is used to receive the test commands sent by terminal 101 and perform verification unit instantiation, interface interconnection, clock signal provision, role identifier value modification, and bidirectional test operations to generate test response data.

[0100] Figure 2 This is a flowchart illustrating the serial expansion bus hardware acceleration verification method provided in this application. The execution entity in this embodiment can be... Figure 1 The server 102 in the illustrated embodiment can also be other computer-related devices, and can also be applied to terminal devices / base stations, or chips or chip modules in terminal devices / base stations. No particular limitation is made to this embodiment.

[0101] like Figure 2 As shown, the serial expansion bus hardware acceleration verification method includes the following steps:

[0102] Step S201: Instantiate the first verification unit and the second verification unit in the hardware-accelerated verification platform.

[0103] Specifically, the design data of the physical layer unit of the serial extended bus is obtained. The analog portion of the design data is described as a synthesizable model using a synthesizable model language, and the digital portion is described as a register-transfer-level model using a register-transfer-level language. Based on the synthesizable and register-transfer-level models, the physical layer units and control units of the first and second verification units are instantiated in the hardware-accelerated verification platform. Specifically, the analog portion of the physical layer unit replaces the actual analog circuit with a behavioral-level model described by the synthesizable model language, and the digital portion is implemented using a register-transfer-level model described by the register-transfer-level language.

[0104] Synthesizable modeling languages ​​can describe the behavioral characteristics of analog circuits, enabling previously unsynthesizable analog circuits to be logically equivalently mapped to hardware-accelerated verification platforms. Register-transfer level languages ​​directly describe the data flow and logical operations between registers in digital circuits, fully compatible with the platform's synthesizability requirements. Two functionally equivalent verification units are provided for bidirectional interconnect testing, allowing the self-developed physical layer module to truly participate in verification operations on the hardware-accelerated verification platform, eliminating dependence on external protocol conversion components. This achieves real loading and operation of the self-developed physical layer module in the silicon pre-processing stage, filling the gap in physical layer verification in existing solutions and providing a hardware foundation for subsequent bidirectional interconnects and role switching.

[0105] Step S202: Interconnect the serial expansion bus interfaces of the first verification unit and the second verification unit.

[0106] Specifically, the transmit, receive, and control channels of the serial extended bus interface of the first verification unit are physically and logically connected to the corresponding channels of the second verification unit, forming a point-to-point full-duplex data transmission path. The data in the interconnection channel includes transaction layer data packets, data link layer control information, and physical layer encoded signals.

[0107] The serial expansion bus interface adopts a full-duplex point-to-point topology. Each channel contains independent transmit differential signal pairs and receive differential signal pairs. Through physical logic interconnection, two verification units can directly perform bidirectional data interaction without the need for external physical devices or development kits. This establishes a direct data path between the two verification units, forming a closed loop in the verification environment. It eliminates the limitation of existing technologies that can only perform tests in one direction, and provides a physical path guarantee for subsequent dynamic role switching and bidirectional testing.

[0108] Step S203: Provide a clock signal to the verification environment through the clock port unit of the hardware-accelerated verification platform.

[0109] Specifically, the clock port unit is a hardware resource within the hardware acceleration verification platform used to generate and distribute clock signals, providing a continuously oscillating and precisely controllable clock signal. The phase-locked loop unit inside the verification unit is a non-synthesizable analog circuit for the platform. By bypassing it through cavitation processing, the timing drive of the entire verification environment uniformly depends on the controllable clock port unit, ensuring timing consistency.

[0110] It provides a unified and stable clock drive for the verification environment, replacing the non-synthesizable phase-locked loop unit inside the verification unit. With the loading of the self-developed physical layer module, it ensures the timing stability and consistency of the verification environment, solves the compatibility problem caused by clock conversion of external protocol conversion components, and reduces hardware costs.

[0111] Step S204: By modifying the role identifier values ​​of the first verification unit and the second verification unit, the first verification unit is set to master device mode and the second verification unit is set to slave device mode, and the first direction test is executed.

[0112] Specifically, the debugging tool writes a first role identifier value and a second role identifier value to a preset mode configuration register. This allows the control unit of the first verification unit to recognize the value and enter master mode, while the control unit of the second verification unit recognizes the value and enters slave mode. In master mode, the first verification unit acts as the master, initiating transaction requests and managing the data exchange process. In slave mode, the second verification unit acts as the slave, responding to master requests and executing corresponding operations. Under this configuration, first-direction test items such as data read / write, interrupt response, and link management are performed.

[0113] The mode configuration register is a read-write storage unit within the verification unit used to store working mode configuration information. Its value directly affects the control unit's determination of the working mode of the physical layer unit. By dynamically modifying the role identifier value in the register at runtime using debugging tools, the master / slave role of the verification unit can be switched without recompiling the hardware configuration file. This enables flexible control of the test direction, allowing two verification units to assume the roles of master and slave devices respectively under a single hardware architecture. This completes data interaction testing from the first verification unit to the second verification unit, covering the entire interaction process from the master device initiating a transaction request to the slave device responding and executing operations, verifying the functional correctness and protocol compliance of the unidirectional data path.

[0114] Step S205: After completing the first direction test, by modifying the role identifier values ​​of the first verification unit and the second verification unit, the first verification unit is switched to slave device mode and the second verification unit is switched to master device mode, and the second direction test is executed.

[0115] Specifically, after completing all test items in the first direction test, the mode configuration register is rewritten using debugging tools. The role identifier value of the first verification unit is modified to the parameter corresponding to the slave device mode, and the role identifier value of the second verification unit is modified to the parameter corresponding to the master device mode. After the modification, the second verification unit, which was originally a slave device, switches to the master device to initiate transaction requests, and the first verification unit, which was originally a master device, switches to the slave device to respond to requests, executing the reverse data interaction test corresponding to the first direction test.

[0116] The dynamic rewriteability of role identifier values ​​allows the same verification unit to switch between different operating modes multiple times during runtime. Bidirectional testing, through a round-robin assignment method, allows two functionally equivalent verification units to experience both the master and slave devices, thus covering data transmission scenarios in both directions of the serial extended bus topology, including all protocol interaction stages such as link training, transaction requests and responses, and interrupt propagation. Building upon the first-direction testing, full coverage testing of the reverse data path is completed, achieving complete verification of bidirectional interconnection of the serial extended bus interface. This ensures full coverage of bidirectional data interaction scenarios, verifying both the sending and receiving channels of the self-developed physical layer unit under both master and slave roles, guaranteeing full functional coverage and verification completeness in bidirectional interconnection scenarios.

[0117] The serial expansion bus hardware acceleration verification method provided in this invention instantiates two structurally equivalent verification units within a hardware acceleration verification platform and completes full-duplex physical layer interconnection. It utilizes the platform clock port unit to provide a unified clock drive and then dynamically modifies the role identifier value to perform complete tests in the first and second directions respectively. This achieves full-function verification of the self-developed physical layer unit in a bidirectional interconnection scenario under a single verification environment setup, significantly improving the coverage and overall verification efficiency of pre-silicon verification of the serial expansion bus interface.

[0118] This embodiment provides a detailed description of the process of instantiating the first verification unit and the second verification unit in the hardware-accelerated verification platform described in the above embodiments. The specific implementation of this process includes the following steps:

[0119] Step a1: Obtain the design data for the physical layer unit of the serial extended bus.

[0120] Specifically, all design files for the physical layer units of the serial extended bus are extracted from the chip design database, including the behavioral-level description or circuit netlist of the analog part and the register transfer-level code of the digital part. The analog part of the physical layer unit design data defines the electrical behavior characteristics of signal transmission and reception, while the digital part defines the logical behavior of encoding, decoding, and state control. This provides a complete and accurate input data source for subsequent model conversion and instantiation operations, ensuring that the physical layer modules integrated in the verification unit are functionally consistent with the final chip design. This allows the physical layer unit design data to be directly used in the verification process, avoiding deviations from actual chip behavior in verification results due to information loss during data conversion.

[0121] Step a2: Describe the simulation portion of the design data as a synthesizable model using a synthesizable model language.

[0122] Specifically, behavioral characteristics of the analog components are extracted from the design data, and the functional behavior of the analog circuits is redescribed using a hardware-accelerated verification platform that supports a synthetic modeling language. Pre-defined physical layer signal interference characteristic data, such as crosstalk or noise models, can be further integrated into the synthesizable model, enabling the model to simulate signal attenuation and interference effects in a real physical layer environment.

[0123] The hardware-accelerated verification platform can synthesize behavioral-level logic described using a synthesizable model language. Behavioral-level models abstract the input-output response relationships of analog circuits, equivalently reproducing the functionality of the analog portion at the logic level without relying on the actual analog circuit structure. After integrating a signal interference model, the synthesizable model further possesses the ability to simulate signal degradation effects in link transmission, transforming unsynthesizable analog circuits into platform-loadable behavioral-level models. This enables the analog portion of the physical layer units to possess synthesizability and loadability within the hardware-accelerated verification platform, and can simulate real physical effects such as signal interference, providing a model foundation for subsequent verification of physical layer robustness in bidirectional testing.

[0124] Step a3: Describe the digital portion of the design data as a register-transfer level model using register-transfer level language.

[0125] Specifically, register-transfer-level (RTL) language is used to logically describe the digital portion of physical layer units, including the data flow and logical operation relationships between registers in sub-modules such as encoders, decoders, parallel-to-serial converters, serial-to-parallel converters, and link state machines. RTL language uses data transfer between registers and combinational logic operations as its basic descriptive units, and can be directly mapped to digital logic circuits in hardware-accelerated verification platforms. The digital portion of physical layer units is naturally designed in register-transfer-level form, and its logical functions remain equivalent during the conversion process, requiring no behavioral abstraction or simplification.

[0126] The digital design data is loaded into the verification environment in the form of equivalent logic to ensure that the digital logic behavior of the physical layer in the verification unit is completely consistent with the actual chip design. This realizes the conversion of the digital design data to the verification platform and ensures that digital control functions such as link training, data encoding, and error detection can be accurately verified cycle by cycle in the verification environment.

[0127] Step a4: Based on the synthesizable model and the register-transfer level model, instantiate the physical layer unit and control unit in the first verification unit and the second verification unit.

[0128] Specifically, the synthesizable model and the register-transfer level model are integrated to form a complete physical layer unit. The physical layer unit and its corresponding control unit are connected via a physical interface standard protocol and instantiated in the logic resources of the hardware-accelerated verification platform, forming the first verification unit and the second verification unit. The two verification units have completely identical structures and contain complete and equivalent physical layer functions and control functions.

[0129] The hardware-accelerated verification platform generates runnable bitstream files by mapping logic designs onto its internal distributed processor arrays or programmable logic resources. Once loaded, these files form a real, running logic circuit. The combined instantiation of physical layer units and control units is equivalent to building two fully functional serial expansion bus devices within the platform.

[0130] By simultaneously building two functionally equivalent verification units within a single hardware acceleration verification platform, a symmetrical dual-sided hardware structure is provided for subsequent interconnection testing. Complete interface function verification can be run without relying on any external physical devices, achieving complete loading of physical layer units and control units. The two verification units have identical structures and equivalent functions, providing a symmetrical hardware foundation for subsequent bidirectional interconnection testing through dynamic role switching.

[0131] This invention achieves complete migration of the physical layer module from design data to the verification environment by using a synthesizable modeling language for behavioral modeling of the physical layer simulation part and a register-transfer level language for equivalent logic description of the digital part. After integrating the two models, they are instantiated on both sides with the corresponding control unit in a hardware acceleration verification platform. This enables pre-silicon verification to cover the full functionality of the physical layer and no longer relies on external components to replace the physical layer position.

[0132] This embodiment details the process of describing the simulation portion of the design data as a synthesizable model using a synthesizable model language as described in the above embodiments. The specific implementation of this process includes the following steps:

[0133] Step b1: Obtain the preset physical layer signal interference characteristic data.

[0134] Specifically, physical layer signal interference characteristic data is extracted from a pre-defined signal integrity analysis database. This includes quantitative indicators characterizing the non-ideal properties of the physical link, such as crosstalk coupling coefficient, noise power spectral density, and channel insertion loss parameters. In reality, serial expansion bus links on printed circuit boards are not ideal transmission channels. Electromagnetic coupling between adjacent traces generates crosstalk, and power fluctuations and thermal noise are superimposed on the useful signal. The pre-defined interference characteristic data is obtained through electromagnetic simulation or actual measurement of real physical links, and can quantitatively describe the degree of signal degradation under specific frequency and wiring conditions.

[0135] This provides parameterized input for injecting signal interference effects into synthesizable models, enabling the models to equivalently reproduce the non-ideal transmission characteristics in physical links at the logic simulation level. It introduces the interference characteristics of real physical links into the verification process in the form of parameterized data, providing a quantitative basis for the subsequent integration of interference models into synthesizable models, and making the interference simulation physically realistic rather than an idealized assumption.

[0136] Step b2: Based on the signal interference characteristic data, integrate the crosstalk model and / or noise model into the synthesizable model.

[0137] Specifically, the crosstalk model is embedded as a coupled transfer function into the input of the synthesizable model's receiving channel, causing the transmitted signals from adjacent channels to be weighted and superimposed onto the received signal of the current channel according to their coupling coefficients. The noise model is injected into the signal path of the receiving channel as an additive pseudo-random sequence, the statistical characteristics of which match the noise power spectral density data. The crosstalk and noise models can be integrated individually or simultaneously, and the integrated synthesizable model automatically adds the interference effect during each data transmission simulation.

[0138] Crosstalk can be modeled at the logical level as a weighted coupling of signals in adjacent channels, while noise can be modeled as a random process with a specific distribution. Synthesizable modeling languages ​​support describing the mixed behavior of sequential and combinational logic, allowing the insertion of coupled computational logic and pseudo-random generation logic into the behavioral description of the receiving channel. This results in hardware logic with interference simulation capabilities after platform synthesis, enabling synthesizable models that originally only described ideal signal transmission and reception behavior to simulate non-ideal link effects. This realistically reflects the operating state of physical layer modules when signals are interfered with, providing hardware-accelerated simulation capabilities for verifying the robustness of physical layer modules in complex electromagnetic environments.

[0139] Step b3: The synthesizable model after integrating the crosstalk model and / or noise model is used as the transformation result of the simulation part.

[0140] Specifically, the synthesizable model after integrating the interference model undergoes functional equivalence checks and synthesis compliance verification to confirm that the model still meets the synthesizable constraints of the hardware-accelerated verification platform after the addition of interference logic, and that the output response under ideal conditions is consistent with the original analog circuit specifications. After successful verification, this model is used as the formal model of the analog part in the verification environment for the instantiation of physical layer units in the first and second verification units.

[0141] The synthesizable model integrating the interference model forms a logic circuit in the hardware-accelerated verification platform. In actual operation, it will simultaneously exhibit the characteristics of an ideal transceiver and the signal degradation response after interference. Thus, it can fully express all the verification requirements of the simulation part in one model, providing the verification unit with a physical layer simulation model that integrates ideal function and interference simulation. A single model can cover both standard functional testing and signal integrity stress testing scenarios. It can carry multiple verification capabilities with a single model, avoiding the need to maintain multiple model versions for different test scenarios, simplifying the verification environment configuration process, and ensuring that functional verification and robustness verification are carried out on the basis of a unified simulation part model.

[0142] This invention integrates preset physical layer signal interference characteristic data into a synthesizable model in the form of crosstalk and noise models, and uses the integrated model as the formal conversion result of the simulation part. This enables the physical layer simulation part to not only reproduce the ideal transmission and reception function in the hardware acceleration verification platform, but also to simulate the signal impairment of real physical links. This achieves hardware-accelerated verification of the anti-interference performance of the physical layer module in the silicon front-end stage.

[0143] In some optional implementations, the specific implementation of the above embodiments further includes the following steps:

[0144] Step c1: Obtain the preset phase-locked loop empty processing configuration information.

[0145] Specifically, the phase-locked loop (PLL) empty processing configuration information is read from the verification environment configuration parameter set. The PLL empty processing configuration information indicates that the PLL units inside the first and second verification units are processed in an empty manner on the hardware acceleration verification platform, that is, the PLL units are not included in the synthesis and simulation scope.

[0146] The PLL empty processing configuration information is a preset compilation control parameter during the verification environment construction phase. Its function is to instruct the platform toolchain to skip the conversion process of PLL units during the logic synthesis and netlist mapping phases. The hardware-accelerated verification platform toolchain performs logical isolation processing on PLL units during synthesis based on this configuration information. This provides a clear configuration basis for subsequent emptying operations on PLL units within the verification unit, ensuring that the platform toolchain treats PLL units according to the empty processing strategy during the compilation phase. By specifying the processing method of PLL units in the form of preset configuration parameters, the empty processing operation has a basis for repeatability and automated execution, avoiding manual intervention each time the verification environment is set up.

[0147] Step c2: Based on the empty processing configuration information, configure the phase-locked loop units inside the first verification unit and the second verification unit to an empty state so that the phase-locked loop units do not participate in clock generation.

[0148] Specifically, during the compilation and generation of the bitstream file in the verification environment, the input clock ports of the phase-locked loop (PLL) units inside the first and second verification units are connected to fixed logic levels according to the empty processing configuration information, while the output clock ports remain disconnected. The feedback loop and loop filters of the PLL units, as well as other analog structures, are not logically mapped. All timing logic of the physical layer units and control units within the verification units is uniformly driven by the clock port units of the hardware-accelerated verification platform.

[0149] The phase-locked loop (PLL) unit multiplies or divides the reference clock to the target frequency and suppresses jitter through closed-loop negative feedback. Internally, it contains analog circuit structures such as a phase detector, charge pump, loop filter, and voltage-controlled oscillator. These analog circuits do not have corresponding synthesizable logic units in the hardware-accelerated verification platform. The cavitation state essentially bypasses the PLL unit at the logic level, severing its timing coupling with other logic within the verification unit, and replacing its function with an external unified clock source. This substitution ensures the integrity of the timing system in the verification environment while eliminating the obstruction of the platform's synthesis process by non-synthesizable modules.

[0150] By separating the timing references of the two verification units from their respective internal phase-locked loop (PLL) units and providing them uniformly through the clock port unit of the hardware-accelerated verification platform, the physical layer units on both sides operate in the same clock domain in both the transmit and receive directions, providing a strictly synchronized timing framework for full-duplex data transmission. This solves the problem that the verification environment cannot be fully generated due to the inclusion of non-synthesizable analog circuits in the chip's internal PLL unit, while ensuring the homogeneity of the clock references of the two verification units, providing a reliable guarantee for timing consistency in bidirectional interconnect testing.

[0151] This invention, by acquiring preset empty processing configuration information and bypassing the internal phase-locked loop unit of the verification unit to an empty state, enables both verification units to be uniformly driven by the clock port unit of the hardware-accelerated verification platform. This eliminates the obstacle of non-synthesizable simulation modules to the construction of the verification environment, and achieves the smooth generation and stable operation of the verification environment while ensuring the integrity and consistency of timing.

[0152] This embodiment provides a detailed description of the process of performing the first direction test or the second direction test in the above embodiments. The specific implementation of this process includes the following steps:

[0153] Step d1: Obtain the preset fault configuration information.

[0154] Specifically, preset fault configuration information is read from the verification test case database. This configuration information defines the fault type, fault injection time point, fault duration, and fault scope. Fault types include link disconnection, data bit flipping, and control character errors, etc. The configuration information is stored in the form of a structured parameter set.

[0155] Fault configuration information consists of pre-compiled injection control parameters for fault tolerance testing during the pre-silicon verification phase. Fault injection does not rely on actual hardware damage or environmental anomalies. Instead, it proactively introduces event sequences that deviate from normal protocol behavior at the logic level to test the verification unit's detection and recovery mechanisms for abnormal operating conditions. This provides precise parameter templates for subsequent fault injection operations, ensuring that the fault type, timing, and scope of each injection are preset and reproducible, guaranteeing the consistency and repeatability of abnormal scenario testing. Defining fault injection strategies in the form of structured parameters transforms abnormal scenario verification from relying on accidental triggers to targeted coverage, providing standardized input for systemic fault tolerance testing.

[0156] Step d2: Write preset faults to the verification environment based on the fault configuration information.

[0157] Specifically, during the execution of the first-direction or second-direction test, fault commands are written to the verification environment at specified time points using debugging tools based on the fault configuration information. For link disconnection faults, the corresponding physical layer channel interface signal is forcibly pulled to an invalid state and maintained for a specified duration; for data bit flipping faults, a logical inversion operation is performed at specific bit positions in the transaction layer data packet; for control character errors, the link layer control sequence is replaced with an illegal encoded value.

[0158] When the verification environment runs on the hardware-accelerated verification platform, all internal signal states can be read and written in real time through debugging tools. Fault injection essentially involves modifying the current value or driving behavior of a target signal through an external debugging interface at a specified simulation time, thereby creating transient or persistent anomalies in the normally operating data path. This intervention mechanism leverages the hardware-accelerated verification platform's support for signal-level debugging to construct abnormal scenarios without modifying the internal logic of the design under test.

[0159] By dynamically introducing preset abnormal events during bidirectional testing, link layer and physical layer failures that may occur in real working environments are simulated, verifying the detection, response, and recovery processes of the verification unit when anomalies occur. This allows abnormal scenarios to be precisely embedded into any stage of the bidirectional testing process, covering boundary conditions and failure modes that traditional functional testing cannot reach, and providing a controllable source of abnormal stimuli for fault tolerance mechanism verification.

[0160] Step d3: Record the response data of the first verification unit and / or the second verification unit under the fault scenario.

[0161] Specifically, after fault injection, the output signals and internal status register data of the verification unit are continuously collected, including interrupt reporting status, link retraining process, error log register recorded values, data retransmission counts, and timeout handling triggering status. The collected data is categorized and stored according to timestamps and fault types to form a fault response record set.

[0162] The fault-tolerant behavior of the verification unit is ultimately manifested as a series of observable protocol and physical layer responses. The hardware-accelerated verification platform provides waveform capture and register state snapshot functions, enabling it to completely record all visible behaviors of the verification unit throughout continuous simulation cycles following fault injection. By analyzing the timing of the response data, it can be determined whether the verification unit correctly detected the fault, executed the recovery process specified in the protocol, and restored normal operation within the specified time.

[0163] By transforming the actual performance of the verification unit under abnormal conditions into a quantitatively analyzable response dataset, objective evidence is provided for the effectiveness of the fault tolerance mechanism and the discovery of design defects. A complete closed loop from fault injection to response acquisition is established, so that each abnormal scenario test has a corresponding traceable behavior record, supporting the item-by-item quantification of the fault tolerance capability of the verification unit.

[0164] This invention, through its embodiments, dynamically injects abnormal events such as link disconnection and data flipping into the verification environment based on preset fault configuration information during bidirectional testing, and fully records the response behavior of the verification unit under fault scenarios. This achieves proactive verification of the fault tolerance mechanism of the serial extended bus interface, transforming the pre-silicon abnormal scenario testing from passively waiting for accidental triggers to planned structured coverage, significantly improving the verification depth and fault detection capability.

[0165] This embodiment provides a detailed description of the process of modifying the role identifier values ​​of the first verification unit and the second verification unit in the above embodiments. The specific implementation of this process includes the following steps:

[0166] Step e1: Obtain historical test scenario data.

[0167] Specifically, historical test scenario data accumulated from previous serial expansion bus verification tasks is read from the verification data management system, including role configuration mode, data rate, link width, test duration, and corresponding test pass status for each test scenario.

[0168] Historical test scenario data consists of naturally accumulated test records from multiple verification executions, containing correlation patterns between different combinations of test parameters and verification results. This data does not rely on manual annotation or assumptions, directly reflecting the correspondence between parameter configurations and functional performance during actual verification.

[0169] Historical test scenario data provides a real and sufficient data foundation for feature extraction and parameter configuration optimization of subsequent test results. By using data accumulated from previous verification practices as the input source, it effectively avoids blind speculation on test parameter configuration and provides real training samples for machine learning models.

[0170] Step e2: Extract test result feature data from historical test scenario data.

[0171] Specifically, historical test scenario data is structured and organized to extract key features representing test results, including quantitative indicators such as link training success rate, data throughput, transaction processing latency, error retransmission frequency, and timeout occurrences. The extracted feature data is then categorized according to test scenarios to form feature vector sets.

[0172] Test result feature data is an abstraction and quantification of the original test records, reflecting the test scenario in numerical form. Link training success rate characterizes the stability of physical layer initialization, throughput and latency reflect transmission efficiency, and error retransmission and timeout reflect protocol layer anomalies. These features, from different dimensions, collectively characterize the validity of the verification and the degree of problem exposure under given parameter configurations.

[0173] By transforming unstructured historical test records into structured numerical features, standardized inputs are provided for the training and analysis of machine learning models. This completes data preprocessing from raw test records to usable model inputs, retains key information highly relevant to test results, filters out redundant details, and improves model computation efficiency.

[0174] Step e3: Input the test result feature data into the pre-trained machine learning model to obtain the test parameter configuration.

[0175] Specifically, the test result feature data is input into a pre-trained machine learning model. Based on learning the mapping relationship between parameters and results in historical feature data, the machine learning model outputs test parameter configurations for the current verification target, including the preferred rate level, link width setting, and test execution duration.

[0176] Machine learning models learn the patterns and nonlinear mappings between test parameter combinations and test results from a large amount of historical feature data during the training phase. During the analysis phase, the model predicts parameter combinations that maximize coverage of high-frequency problem scenarios based on the feature distribution characteristics of the input. High-frequency problem scenarios typically manifest as parameter neighborhoods with low success rates and high error frequencies in historical data. The model output tends to guide testing resources towards these areas.

[0177] By replacing manual experience-based judgment with data-driven methods, test parameter configurations that are highly targeted and cover high-frequency problem scenarios are automatically generated, improving the scientific nature and efficiency of testing. This upgrades test parameter configuration from manual setting to intelligent recommendation, enabling subsequent automated test scripts to focus on parameter areas with weak historical performance or boundary states, thereby increasing the probability of defect discovery within a limited test time.

[0178] Step e4: Generate automated test scripts based on the test parameter configuration.

[0179] Specifically, the test parameter configuration is converted into automated test scripts. The automated test scripts include instructions for writing mode configuration register addresses, role identifier values, data transmission start instructions, and test data acquisition instructions, all of which are arranged according to a preset execution sequence.

[0180] Automated test scripts act as an intermediate layer, transforming parameter configurations into instruction sequences that can be directly executed by debugging tools. By calling the debugging tool's programming interface, the script converts parameters into register access instructions recognizable by the hardware-accelerated verification platform, thus achieving end-to-end automation from parameter decision-making to hardware operation. With standardized script structure, different parameter configurations correspond to different instruction parameter values, but share the same execution framework. This eliminates input errors and efficiency losses that may be introduced during manual configuration, achieving seamless integration between test parameter decision results and actual operation in the verification environment. It also enables end-to-end automated execution of the entire process of dynamically modifying role identifier values.

[0181] Step e5: Write the role identifier value to the preset mode configuration register through an automated test script.

[0182] Specifically, before the first-direction test begins, the automated test script writes the corresponding master device mode role identifier value to the mode configuration register of the first verification unit and the corresponding slave device mode role identifier value to the mode configuration register of the second verification unit, then triggers the test start command. After all the first-direction tests are completed, the script automatically writes the role-swapped identifier values ​​to the mode configuration registers of the two verification units and triggers the second-direction test start command. During the test, the register writing timing and data acquisition trigger timing are both uniformly controlled by the script.

[0183] The mode configuration register is a dedicated storage unit within the verification unit used to set the operating mode. The value of the mode configuration register directly controls the jump branches of the verification unit's state machine. Writing register values ​​via debugging tools is an in-band configuration method, which takes effect in real time while the verification environment is running continuously, without interrupting the simulation or reloading the bitstream file. The automated script uses batch register write instructions to synchronize the switching of the role identifier values ​​of the two verification units with precise timing.

[0184] This system enables the setting and switching of roles between two verification units in master and slave modes, allowing bidirectional testing to be started and switched without manual intervention. It eliminates the time-consuming step of manually writing registers one by one and ensures the timing synchronization accuracy of the role switching operation between the two verification units, providing an efficient and repeatable execution mechanism for large-scale regression testing.

[0185] This invention extracts result features from historical test scenario data, uses a pre-trained machine learning model to intelligently generate test parameter configurations, and automatically converts them into executable automated test scripts. Then, the script writes role identifier values ​​to a preset mode configuration register to complete the role setting and switching of the verification unit. This achieves a closed-loop process from test experience accumulation to test parameter decision-making to automated execution, significantly improving the automation level of bidirectional testing of serial expansion buses and the efficiency of regression testing.

[0186] This embodiment uses a hardware acceleration verification of a certain type of serial expansion bus (PCIe, Peripheral Component Interconnect Express) as an example to illustrate the method. Figure 3 As shown:

[0187] First, in the PXP (Palladium XP) hardware acceleration verification platform, two sets of functionally equivalent verification units are instantiated, namely UnisocChip0 on the left and UnisocChip1 on the right in the diagram. Both sets of units include a PCIE controller (PCIE CTRL) and a physical layer (PCIE PHY). The digital part of the physical layer is a register-transfer level model, while the analog part is implemented using a synthesizable model, including the PXP_CLK (clock), PXP_TX (transmit), PXP_RX (receive), PXP_INIT (initialization), and PXP_CTRL (control) modules.

[0188] The PCIE (PHY Interface for PCI Express) physical layers (PCIE PHYA) of the two sets of verification units are directly interconnected through the platform's high-speed data channel, forming a closed-loop link. The interconnection signals include bidirectional 20-bit wide PXP_TX_DATA, PXP_RX_DATA, and PXP_RX_PRESENT status signals, constructing a complete bidirectional data interaction path.

[0189] All clock signals are provided by the ClockPort unit of the PXP platform, including PIPE_MAC_PCLK and PXP_CLK, and the clock is in a continuous oscillation state. The PLL (Phase Locked Loop) modules inside the verification unit are all nulled because they are not synthesizable and do not participate in clock generation to ensure consistent and controllable timing.

[0190] By writing role identifier values ​​to the registers using the debugging tool Trace32, the left-side Chip0 is configured as a root complex device (RC) and the right-side Chip1 is configured as an endpoint device (EP). After configuration, a first-direction test is performed under this topology to verify bus data transmission, link training, and protocol interaction functions.

[0191] After the first direction test is completed, there is no need to modify the hardware connection. Simply modify the role identifier value again through Trace32, switch Chip0 on the left to EP mode and Chip1 on the right to RC mode, and execute the second direction test to cover the reverse data transmission scenario.

[0192] This embodiment, through a dual-unit direct-connect architecture and a dynamic role switching mechanism, completes bidirectional functional verification of the PCIe bus in one go within the same verification environment. It eliminates the need to repeatedly build the environment or rely on additional conversion hardware, significantly improving verification efficiency and scenario coverage, and effectively reducing the probability of chip tape-out problems and development costs.

[0193] Figure 4 A schematic diagram of the serial expansion bus hardware acceleration verification device provided in this application. Figure 4 As shown, the serial expansion bus hardware acceleration verification device 40 includes:

[0194] Module 401 is used to instantiate the first verification unit and the second verification unit in the hardware-accelerated verification platform;

[0195] The building module 401 is also used to interconnect the serial expansion bus interfaces of the first verification unit and the second verification unit;

[0196] Module 401 is also used to provide clock signals to the verification environment through the clock port unit of the hardware-accelerated verification platform;

[0197] Test module 402 is used to modify the role identifier values ​​of the first verification unit and the second verification unit to set the first verification unit to master device mode and the second verification unit to slave device mode, and execute the first direction test.

[0198] The test module 402 is also used to perform the second direction test after the first direction test is completed by modifying the role identifier values ​​of the first verification unit and the second verification unit, switching the first verification unit to slave mode and the second verification unit to master mode.

[0199] In one possible implementation, module 401 is specifically used for:

[0200] Obtain the design data for the physical layer unit of the serial extended bus;

[0201] The simulation portion of the design data is described as a synthesizable model using a synthesizable model language.

[0202] The digital portion of the design data is described as a register-transfer-level model using a register-transfer-level language.

[0203] Based on the synthesizable model and the register-transfer level model, the physical layer unit and control unit in the first verification unit and the second verification unit are instantiated.

[0204] In one possible implementation, module 401 is further used for:

[0205] Obtain preset physical layer signal interference characteristic data;

[0206] Based on signal interference characteristic data, crosstalk model and / or noise model are integrated into a synthesizable model;

[0207] The synthesizable model, which integrates the crosstalk model and / or the noise model, is used as the transformation result of the simulation part.

[0208] In one possible implementation, module 401 is further used for:

[0209] Obtain the preset phase-locked loop empty processing configuration information;

[0210] Based on the empty processing configuration information, the phase-locked loop units inside the first verification unit and the second verification unit are configured to be in an empty state so that the phase-locked loop units do not participate in clock generation.

[0211] In one possible implementation, test module 402 is specifically used for:

[0212] Obtain preset fault configuration information;

[0213] Preset faults are written to the verification environment based on fault configuration information;

[0214] Record the response data of the first verification unit and / or the second verification unit under fault scenarios.

[0215] In one possible implementation, test module 402 is further used for:

[0216] Obtain historical test scenario data;

[0217] Extract test result feature data from historical test scenario data;

[0218] The test result feature data is input into a pre-trained machine learning model to obtain the test parameter configuration;

[0219] Generate automated test scripts based on test parameter configuration;

[0220] The role identifier value is written to the preset mode configuration register through an automated test script.

[0221] The serial extended bus hardware acceleration verification device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0222] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0223] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0224] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0225] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0226] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0227] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0228] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0229] This application also provides a chip, which includes at least one processor for executing program instructions to perform the methods described above.

[0230] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0231] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0232] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0233] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0234] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0235] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0236] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0237] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0238] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for hardware acceleration verification of a serial expansion bus, the method comprising: include: Instantiate the first verification unit and the second verification unit in the hardware-accelerated verification platform; Interconnect the serial expansion bus interfaces of the first verification unit and the second verification unit; The clock port unit of the hardware-accelerated verification platform provides a clock signal to the verification environment. By modifying the role identifier values ​​of the first verification unit and the second verification unit, the first verification unit is set to master device mode and the second verification unit is set to slave device mode, and the first direction test is performed. After completing the first direction test, the role identifier values ​​of the first verification unit and the second verification unit are modified to switch the first verification unit to slave mode and the second verification unit to master mode, and then the second direction test is executed.

2. The method according to claim 1, characterized in that, Instantiating the first verification unit and the second verification unit in the hardware-accelerated verification platform includes: Obtain the design data for the physical layer unit of the serial extended bus; The simulation portion of the design data is described as a synthesizable model using a synthesizable model language. The digital portion of the design data is described as a register-transfer-level model using register-transfer-level language. Based on the synthesizable model and the register transfer level model, the physical layer unit and control unit in the first verification unit and the second verification unit are instantiated.

3. The method according to claim 2, characterized in that, The simulation portion of the design data is described as a synthesizable model using a synthesizable model language, including: Obtain preset physical layer signal interference characteristic data; Based on the signal interference characteristic data, a crosstalk model and / or a noise model are integrated into the synthesizable model; The synthesizable model, which integrates the crosstalk model and / or the noise model, is used as the transformation result of the simulation part.

4. The method according to claim 2, characterized in that, Also includes: Obtain the preset phase-locked loop empty processing configuration information; Based on the empty processing configuration information, the phase-locked loop units inside the first verification unit and the second verification unit are configured to be in an empty state so that the phase-locked loop units do not participate in clock generation.

5. The method according to claim 1, characterized in that, Perform the first-direction test or the second-direction test, including: Obtain preset fault configuration information; A preset fault is written to the verification environment based on the fault configuration information; Record the response data of the first verification unit and / or the second verification unit under fault scenarios.

6. The method according to claim 1, characterized in that, Modifying the role identifier values ​​of the first verification unit and the second verification unit includes: Obtain historical test scenario data; Extract test result feature data from the historical test scenario data; The test result feature data is input into a pre-trained machine learning model to obtain the test parameter configuration; Based on the aforementioned test parameter configuration, an automated test script is generated; The automated test script writes the role identifier value to the preset mode configuration register.

7. A serial expansion bus hardware acceleration verification device, characterized in that, include: A building block is used to instantiate the first and second verification units in the hardware-accelerated verification platform. The construction module is also used to interconnect the serial expansion bus interfaces of the first verification unit and the second verification unit; The building module is also used to provide a clock signal to the verification environment through the clock port unit of the hardware acceleration verification platform; The testing module is used to modify the role identifier values ​​of the first verification unit and the second verification unit, setting the first verification unit to master device mode and the second verification unit to slave device mode, and to perform a first-direction test. The testing module is also used to, after completing the first direction test, modify the role identifier values ​​of the first verification unit and the second verification unit to switch the first verification unit to slave device mode and the second verification unit to master device mode, and then execute the second direction test.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images