A configuration method for a verification platform

Abstract

This invention relates to the field of chip verification technology, and in particular to a configuration method for a verification platform. The method involves: acquiring N hardware input ports related to the current verification target in the design under test; acquiring a preset classification strategy of the verification platform and M interface sets configured according to the classification strategy; dividing the N hardware input ports into M port classification sets according to the classification strategy, and binding the hardware input ports in the M port classification sets to the interfaces in the M interface sets of the verification platform; binding an independent dedicated input agent to each interface set in the verification platform; and acquiring the transactions generated by the verification sequence each time a verification sequence is started, connecting the verification sequence to the sequencer of the dedicated agent matching the classification type according to the classification type of the data in the transaction, and then applying stimuli to the hardware input ports through a driver to drive the design under test, thus achieving the versatility of the verification platform.

Description

Technical Field

[0001] This invention relates to the field of chip verification technology, and in particular to a method for configuring a verification platform. Background Technology

[0002] Machine Check Architecture (MCA) is a hardware error detection and handling architecture, initially proposed by Intel to improve the high reliability (RAS, Reliability, Availability, Serviceability) of servers and data centers, becoming a cornerstone of modern data centers and high-reliability systems. In the early days of servers and high-end computing, hardware errors, such as memory ECC errors, bus signal loss, or cache inconsistency failures, could lead to system crashes or data corruption. Traditional software detection mechanisms, such as polling, were inefficient and unable to cover all error types. In the early 2000s, Intel introduced MCA in processors such as Xeon and P6, using hardware-level error detection and standardized registers (MCA and Standardized Register, MSR) to record error information, combined with exception or interrupt notifications to system software, enabling rapid response. With the rapid development of chips, MCA has become deeply integrated with operating systems (Linux's mcelog, Windows' WHEA) and firmware (ACPIAPEI), forming a closed loop of error handling from chip to system.

[0003] During the chip verification phase, errors are actively injected through the MCA register to test the coverage of the error handling path, thereby simulating error functions and ensuring the correctness of the tested functions. Since each chip includes multiple functional modules, each with its own independent error types and triggering mechanisms, in traditional verification methods, the verification platform is developed for a specific functional module. All interfaces of the design under test use the same agent. To adapt to different behaviors, the agent's internal branching logic is complex and strongly coupled with each functional module. Adding a new functional module requires modifying the component's internal code, resulting in poor agent versatility and a long error detection cycle. Summary of the Invention

[0004] To address the aforementioned technical problems, the present invention adopts the following technical solution: a configuration method for a verification platform, the method comprising: acquiring N hardware input ports related to the current verification target in the design under test, where N is a positive integer; acquiring a preset classification strategy of the verification platform and M interface sets configured according to the classification strategy; dividing the N hardware input ports into M port classification sets according to the classification strategy, and binding the hardware input ports in the M port classification sets to the interfaces in the M interface sets of the verification platform, where M is a positive integer and M is less than or equal to N; binding an independent dedicated input agent to each interface set in the verification platform, the agent components of the dedicated input agent including a driver and a sequencer; acquiring a verification sequence; wherein, each time the verification sequence is started, acquiring the transaction generated by the verification sequence, and connecting the verification sequence to the sequencer of the dedicated agent matching the classification type according to the classification type of the data in the transaction; the sequencer receives and outputs the transaction to the driver in sequence; the driver converts the transaction into an stimulus and applies the stimulus to the hardware input port through the interface bound to the driver to drive the design under test.

[0005] The present invention has at least the following beneficial effects: In the method provided by this invention, each dedicated input agent has its own dedicated verification sequence and agent components. The internal code of each dedicated input agent only needs to focus on one type of data and no longer depends on specific functional modules. Compared with the prior art, which requires adaptive modification of the internal logic of the input agent components in the verification platform according to new functional modules, the method provided by this invention decouples the logic coupled within a single input agent into multiple types of input agents. New functional modules only need to select and map existing agent types without modifying the internal code. The input agent components have strong reusability, achieving the universality of the verification platform. In addition, this method enables people to better understand and maintain the verification platform. Attached Figure Description

[0006] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0007] Figure 1 A flowchart illustrating a configuration method for a verification platform provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a verification platform provided in an embodiment of the present invention. Detailed Implementation

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

[0009] Unless otherwise defined, all technical and scientific terms used in the embodiments of this invention have the same meaning as commonly understood by those skilled in the art.

[0010] Please see Figure 1 and Figure 2 ,in, Figure 1 A method for configuring a verification platform is shown. Figure 2 The verification platform is shown. The method includes: S100: Obtain the N hardware input ports related to the current verification target in the design under test, where N is a positive integer.

[0011] The Design Under Test (DUT) is the hardware design entity that is tested in the simulation verification.

[0012] The current verification target is a specific function or behavior of a functional module within a hardware design entity. The correctness of this specific function or behavior is verified by interacting with the verification platform.

[0013] In this context, hardware input ports refer to the set of ports in the design under test (DUT) that are relevant to the current verification objective. The verification platform needs to simulate the behavior of the DUT. Therefore, a corresponding reference model needs to be built on the verification platform to simulate the behavior of the DUT, output corresponding output data, and compare it with the actual output data to verify the correctness of the error reporting and error detection functions of the MCA module under test.

[0014] The current verification target can be a functional module, subsystem, or the entire design under test. Specific current verification targets or those defined in other ways also fall within the scope of this invention. In one embodiment, the current verification target is a functional module, and the N hardware input ports in S100 represent all the external hardware input ports of the functional module.

[0015] S200: Obtain the classification strategy preset by the verification platform and the M interface sets configured according to the classification strategy.

[0016] It should be noted that the design under test is instantiated in the verification platform and stimuli are transmitted through an interface. The verification platform sends the stimuli to the interface, and the stimuli are then bound to the ports of the instantiated design under test for transmission.

[0017] In one implementation, the classification strategy is to classify according to data type or function type. Other classification strategies also fall within the scope of this invention. Specifically, classification by data type refers to classification according to the characteristics of the input interface data, such as level data, pulse data, and register data. Classification by function type refers to classification according to the function of the input interface data.

[0018] In one implementation, the M interface sets cover all hardware input ports of the current verification target in the design under test.

[0019] In one implementation, when the classification strategy is based on data type, the M interface sets include an interface set for receiving level data, an interface set for receiving pulse data, and an interface set for receiving register data. Level data refers to level signals or hardware control signals that only support 0 and 1 values, suitable for real-time response scenarios, and primarily responsible for control flow data. Pulse data refers to control instructions or monitoring data that support complex values, suitable for complex data transmission, and primarily responsible for data flow data. Register data refers to register-related data used to control the transmission of data to the current verification target. The interfaces for receiving register data include a register address interface for specifying the address of the register to be accessed, a register data interface for transmitting data during read / write operations, and a register read / write interface for indicating whether a read or write operation is performed on the register. It should be noted that after the M types of interfaces apply stimulus to the current verification target through their respective agents, the transmission strategy for sending level data and pulse data to the current verification target is controlled by the register data.

[0020] S300, according to the classification strategy, the N hardware input ports are divided into M port classification sets, and the hardware input ports in the M port classification sets are bound to the M interface sets of the verification platform, where M is a positive integer and M is less than or equal to N.

[0021] This involves binding hardware input ports and interfaces to establish a connection between the verification platform and the current verification target. It should be noted that the hardware input ports and interfaces are bound one-to-one.

[0022] In one implementation, the step of binding the hardware input ports of the M port classification sets and the interfaces of the M interface sets of the verification platform includes: for port classification sets and interface sets of the same classification, obtaining the port name of each hardware input port in the port classification set and obtaining the interface name of each interface in the interface set; binding the port name of the hardware input port and the interface name of the interface.

[0023] In one implementation, the step of binding the port name of a hardware input port and the interface name of an interface includes: both the port name of the hardware input port and the interface name of the interface include a public name and a private interface name; when the hardware input port and the interface are used to receive the same signal and have the same private interface name, then the hardware input port and the interface are directly bound. It should be noted that the interface names of both the hardware input port and the interface are composed of a public name and a private interface name. However, in practical applications, due to differences in naming conventions, hardware input ports and interfaces used to receive the same signal, or those that are actually the same interface, may have different private interface names. In this case, it is also necessary to bind the private interface names of the hardware input port and the interface. Other types of binding rules also fall within the scope of protection of this invention.

[0024] In one implementation, for the SystemVerilog language, when instantiating a functional module, the hardware input port and interface are bound using the port binding statement ".port_name(signal_name)". As an example, when mca_elr_reg_addr represents the register address interface of the current verification target in the design under test, and reg_if.send is the simulated register address interface in the verification platform, ".mca_elr_reg_addr(reg_if.addr)" indicates that these two interfaces are bound.

[0025] In one embodiment, the public name concatenated with the interface name serves as a prefix or suffix to the interface name. In another embodiment, the interface name uses string concatenation, with the public and private interface names separated by a preset separator. Other concatenation methods also fall within the scope of this invention. It should be noted that the interface names of hardware input ports and interfaces can use different concatenation methods. In one embodiment, the separator is an underscore "_" or a forward slash " / ", but other types of separators also fall within the scope of this invention.

[0026] S400, in the verification platform, binds each interface set to its own independent dedicated input agent, the agent components of which include a driver and a sequencer.

[0027] The input agent is a modular component used in the verification environment to drive and / or monitor interface signals. The agent component includes a sequencer, a driver, and a monitor. Each interface set is bound to an independent dedicated input agent, and each dedicated input agent only needs to focus on one type of data. Compared to a scheme with only one agent, the internal logic of its input agent component is simple.

[0028] A transaction is the basic unit of communication or operation, including address, data, and opcode, which can be converted into pin excitation signals by the driver. Examples include an instruction, a read operation, or a write operation.

[0029] The sequencer is used to send transactions to the driver according to the order in which they are sent.

[0030] The driver is used to convert transactions into timing signals that conform to the hardware input port protocol of the design under test and apply them to the hardware input port of the design under test.

[0031] The monitor is used to monitor the interface signals of the design under test, collect data and send it to modules that need to use the monitoring data, such as the scoreboard.

[0032] S500, Obtain the verification sequence. The verification sequence is used to generate transactions and define their sending order.

[0033] Furthermore, each time a verification sequence is initiated, the transaction generated by the verification sequence is acquired, and the verification sequence is connected to the sequencer of a dedicated agent that matches the classification type of the data in the transaction; the sequencer receives and outputs the transaction to the driver in sequence; the driver converts the transaction into an stimulus and applies the stimulus to the hardware input port through an interface bound to the driver to drive the design under test.

[0034] In summary, the method provided by this invention provides a method where each dedicated input agent has its own dedicated verification sequence and agent components. The internal code of each dedicated input agent only needs to focus on one type of data and no longer depends on specific functional modules. Compared to existing technologies that require adaptive modification of the internal logic of the input agent components in the verification platform according to new functional modules, the method provided by this invention decouples the logic coupled within a single input agent into multiple types of input agents. New functional modules only need to select and map existing agent types without modifying the internal code. The input agent components have strong reusability, achieving the universality of the verification platform. Furthermore, this method enables people to better understand and maintain the verification platform.

[0035] In one implementation, please refer again. Figure 2When verifying the MCA module of the current verification target, the stimulus applied to the hardware input port is an error injection stimulus. The output terminal of the design under test includes an output agent, and the monitor of the output agent monitors the output terminal of the design under test, detecting error output values ​​and fatal error output values; wherein, the error output values ​​and fatal error output values ​​are the actual output results of the current verification target. It should be noted that the communication between the monitor of the output agent and the output terminal of the design under test is achieved by: establishing an output terminal interface of the verification platform and binding the mapping relationship between the output terminal interface and the hardware output terminal of the current verification target.

[0036] In one implementation, the output monitor detects different error types based on the different output types of the design under test.

[0037] In one implementation, please refer again. Figure 2 The method further includes configuring a scoreboard, which comprises a reference model component and a comparison component. The reference model component simulates the current verification target, outputting simulation results when multiple types of data from the input hardware input port are input. The comparison component compares the simulation results of the reference model component with the target verification results of the current verification target. If the data mismatch occurs, an error is reported; if a match occurs, a successful comparison message is reported, yielding the accuracy of the behavior prediction for the verification target. The simulation results include internal error and fatal error reports and external error and fatal error reports or results obtained through operation. Internal error and fatal error reports refer to the generation of error reports and fatal error reports when multiple types of data from the input hardware input port reach the preset trigger conditions of the MCA module in the current verification target. External error and fatal error reports refer to errors and fatal errors input from external verification targets.

[0038] In one implementation, the verification platform randomly configures the control registers in the current verification target to simulate test scenarios where the error or fatal error mechanism outputs 0 or 1 under different configurations, thereby ensuring the correctness of the internal MCA module of the verification target in handling internal behavior.

[0039] In one implementation, the verification platform uses an interface set that receives register data to configure input signals for errors or fatal errors, and simulates output signals for errors or fatal errors from the upper-layer verification target to simulate a more realistic test scenario.

[0040] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0041] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0042] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0043] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0044] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of this invention is defined by the appended claims.

Claims

1. A configuration method for a verification platform, characterized in that, The method includes: Obtain the N hardware input ports related to the current verification target in the design under test, where N is a positive integer; Obtain the classification strategy preset by the verification platform and the M interface sets configured according to the classification strategy; According to the classification strategy, the N hardware input ports are divided into M port classification sets, and the hardware input ports in the M port classification sets are bound to the M interface sets of the verification platform, where M is a positive integer and M is less than or equal to N. In the verification platform, each interface set is bound to its own independent dedicated input agent, and the agent components of the dedicated input agent include a driver and a sequencer; wherein, each dedicated input agent focuses on only one type of data; Obtain the verification sequence; Specifically, each time the verification sequence is initiated, the transaction generated by the verification sequence is acquired, and the verification sequence is connected to the sequencer of a dedicated agent that matches the classification type of the data in the transaction; the sequencer receives and outputs the transaction to the driver in sequence; the driver converts the transaction into an stimulus and applies the stimulus to the hardware input port through an interface bound to the driver to drive the design under test.

2. The method according to claim 1, characterized in that, The classification strategy is to classify according to data type or function type.

3. The method according to claim 1, characterized in that, The M interface sets cover all hardware input ports of the current verification target in the design under test.

4. The method according to claim 1, characterized in that, When the classification strategy is based on data type, the M interface sets include the interface set for receiving level data, the interface set for receiving pulse data, and the interface set for receiving register data.

5. The method according to claim 1, characterized in that, The steps for binding the hardware input ports in the M port classification sets and the interfaces in the M interface sets of the verification platform include: for port classification sets and interface sets of the same classification, obtaining the port name of each hardware input port in the port classification set and obtaining the interface name of each interface in the interface set; binding the port name of the hardware input port and the interface name of the interface.

6. The method according to claim 5, characterized in that, The public name is the concatenated part of the interface name, which serves as a prefix or suffix to the interface name.

7. The method according to claim 1, characterized in that, When verifying the MCA module of the current verification target, the output terminal of the design under test includes an output agent. The output monitor of the output agent monitors the output terminal of the design under test and detects error output values ​​and fatal error output values. The error output values ​​and fatal error output values ​​are the actual output results of the current verification target.

8. The method according to claim 7, characterized in that, The output monitor detects different error types based on the different output types of the design under test.

9. The method according to claim 1, characterized in that, The method further includes: randomly configuring the control register in the current verification target through the verification platform to simulate test scenarios where the error or fatal error mechanism inside the current verification target outputs 0 or 1 under different configurations.

10. The method according to claim 1, characterized in that, The method further includes: on the verification platform, configuring error or fatal error input signals through an interface set for receiving register data, and simulating error or fatal error output signals of the upper-layer verification target.

Images