An uvm-based ahci verification system and verification method

Abstract

The application provides an AHCI verification system and method based on UVM, and relates to the technical field of AHCI verification. The AHCI verification system based on UVM comprises an AHCI general verification component, an AHCI general verification platform, a multi-vendor VIP adaptation module and a multi-interface adaptation module. The AHCI general verification component is connected to a to-be-tested module, is independent of a vendor VIP module and a host interface bus protocol, and is used for realizing the core logic of the AHCI protocol; the AHCI general verification platform is used for providing a verification environment to perform AHCI verification on the to-be-tested module; the multi-vendor VIP adaptation module is connected to the AHCI general verification component and a plurality of different types of vendor VIP modules; and the multi-interface adaptation module is connected to the AHCI general verification component and a plurality of different types of host interface buses. The scheme provided by the application has the effects of being compatible with different vendor VIPs and being adaptable to multiple host interfaces.

Description

Technical Field

[0001] This application relates to the field of AHCI verification technology, and more specifically, to an AHCI verification system and verification method based on UVM. Background Technology

[0002] With the rapid development of servers, storage devices, embedded systems, and high-performance computing platforms, AHCI (Advanced Host Controller Interface), as the mainstream interface standard for storage control, is widely used in various chip products. In the chip design process, functional verification is a critical step to ensure design correctness, and standardized verification based on UVM (Universal Verification Methodology) has become the mainstream practice in the industry.

[0003] Currently, functional verification of the AHCI protocol typically employs a UVM-based verification environment. This environment uses a commercial SATA (Serial Advanced Technology Attachment) VIP (Verification Intellectual Property) module to simulate storage device behavior and interact with the design under test (DUT) to complete protocol compliance checks and data transmission verification. The basic architecture of this verification environment usually includes modules for test stimulus generation, register configuration, protocol checking, data comparison, and coverage collection. This type of verification scheme is widely used in real-world projects and is an important component of the current chip verification process.

[0004] However, existing AHCI verification solutions generally suffer from the following technical defects: First, the verification environment is deeply coupled with the SATA VIP of a specific vendor. There are significant differences in interface definition, timing process and data encapsulation format between different vendors' VIPs. When replacing the VIP, a lot of code needs to be refactored, resulting in poor reusability. Second, the verification component is tightly bound to the host interface bus protocol and only supports a single AXI or PCIe interface, making cross-platform porting difficult.

[0005] In summary, existing AHCI verification solutions suffer from incompatibility with VIPs from different vendors and inability to adapt to multiple host interfaces. Summary of the Invention

[0006] The purpose of this application is to provide an AHCI verification system and method based on UVM to solve the problems of incompatibility with different vendor VIPs and inability to adapt to multiple host interfaces in existing AHCI verification schemes.

[0007] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide an AHCI verification system based on UVM, the system comprising: AHCI universal verification component, connects to the module under test, is independent of the vendor's VIP module and host interface bus protocol, and is used to implement the core logic of the AHCI protocol; The AHCI universal verification platform connects to the AHCI universal verification component and provides a verification environment for performing AHCI verification on the module under test. A multi-vendor VIP adaptation module connects to the AHCI universal verification component and multiple different types of vendor VIP modules, and is used to shield the interface differences of the vendor VIP modules from the AHCI universal verification component. A multi-interface adapter module is connected to the AHCI universal verification component and various different types of host interface buses respectively, and is used to shield the protocol differences of each host interface bus from the AHCI universal verification component. The AHCI universal verification component interacts with the vendor VIP module on the device side through the multi-vendor VIP adaptation module, and interacts with different types of host interface buses on the host side through the multi-interface adaptation module.

[0008] Optionally, the AHCI universal verification component includes: The AHCI register model submodule is used to implement register reset, read / write mirroring, access permission check and automatic register field verification of the register space of the AHCI host bus adapter, and provides an abstract application programming interface for register read / write. The AHCI command construction submodule is used to generate AHCI command headers and command tables. The FIS frame transceiver parsing submodule is used to encode, transmit, receive, and decode various frame information structure types. The interrupt handling submodule is used to simulate the HBA interrupt state machine, handle device interrupts, DMA completion interrupts, error interrupts and NCQ asynchronous interrupts, and maintain the interrupt mask corresponding to the interrupt status / interrupt enable. The NCQ queue management submodule is used to implement the dispatching, out-of-order completion, queue reordering, asynchronous notification, queue overflow protection, and command timeout detection of multi-depth NCQ command circular queues. The PIO / DMA transfer control submodule is used to separate the PIO register transfer path from the DMA memory batch transfer path, and to perform PRD linked list traversal, data handling and transfer length matching verification. The error detection and protocol inspection submodule is used to build in the AHCI protocol compliance inspection rule set and perform violation detection based on the rule set.

[0009] Optionally, the multi-vendor VIP adaptation module includes: A unified calling interface is provided to connect with the AHCI general verification component and to be called by the AHCI general verification component. Multiple differentiated adapter driver interfaces are provided, each connecting to a different manufacturer's VIP module. Each of these differentiated adapter driver interfaces adapts and converts the operation of the corresponding manufacturer's VIP module. The multi-vendor VIP adaptation module uses the unified calling interface and the multiple differentiated adaptation driver interfaces to bidirectionally isolate and translate the AHCI general verification component with the underlying VIP modules of each vendor.

[0010] Optionally, the multi-vendor VIP adaptation module is used to implement the following process: The VIP unified initialization process is used to receive the link configuration parameters issued by the AHCI general verification component, and automatically map the link configuration parameters into the private initialization sequence, register configuration timing, reset process and link training trigger logic required by the corresponding vendor VIP module according to the currently bound vendor VIP module type, so as to complete the power-on reset, register configuration and physical link enable of the vendor VIP module. The FIS bidirectional forwarding process is used to translate the standard structured FIS data packets issued by the AHCI universal verification component into an internal data structure that can be recognized by the current vendor's VIP module and send it into the VIP transmission path, and to strip the vendor's private encapsulation header from the uplink returned device FIS frames from the VIP module side of each vendor and convert them into a unified standard FIS structure and pass it up to the AHCI universal verification component. The event synchronization processing flow is used to poll and register callbacks in real time to listen for DMA completion events, NCQ command completion events, device response events and link establishment events inside the VIP modules of each vendor, and normalize the custom events of each vendor into event enumeration types defined by the protocol layer. The unified hardware status reporting process is used to periodically synchronize the HBA running status, SATA link online status, queue occupancy status, transmission error count, and interrupt suspension status within the VIP modules of various manufacturers, and to encapsulate the different status registers and status flags of various manufacturers into a unified status structure for output.

[0011] Optionally, the multi-interface adapter module includes: A unified host access abstraction interface is provided for the AHCI general verification component to call in order to perform host memory access and status interaction operations; AXI bus adapter path, used to interface with the AXI host interface bus; PCIe bus adapter path, used to interface with PCIe host interface bus; The multi-interface adaptation module automatically identifies the effective host interface type based on the current verification platform's hardware configuration and bus operating mode, and automatically completes bus path switching and adaptation logic loading between the AXI bus adaptation path and the PCIe bus adaptation path.

[0012] Optionally, the multi-interface adapter module is configured to perform at least one of the following functions: A unified address mapping adaptation mechanism is used to build a globally unified address mapping model, automatically completing bidirectional translation and alignment conversion between AXI physical addresses, PCIe bus addresses and AHCI controller local addresses, so as to unify the address reading and writing, PRD linked list address parsing and DMA addressing access logic of the AHCI general verification component. The bus transaction bidirectional conversion function is used to automatically parse and convert the memory read transaction, memory write transaction, register configuration transaction, DMA initiation transaction and transmission termination transaction issued by the AHCI general verification component into standard transaction messages and timing operations of the AXI bus or PCIe bus, and to normalize the completed transaction, response status and transmission end signal reported by the AXI bus and PCIe bus into a transaction feedback structure and transmit it to the AHCI general verification component. The cross-bus interrupt signal synchronization and timing compatibility unit is used to unify the interrupt identification, synchronization and reporting logic to address the differences between the AXI level interrupt reporting mechanism and the PCIe message interrupt and MSI interrupt reporting mechanisms. It completes the sampling calibration, edge synchronization, debouncing and event normalization processing of interrupt signals from different buses, and encapsulates the interrupt signals of the underlying heterogeneous buses into standard AHCI interrupt events and reports them to the AHCI general verification component. The multi-bus timing compatibility calibration unit is used to automatically perform timing adaptation, cross-clock domain synchronization, data sampling alignment, and transmission delay compensation for the different handshake logic, transmission delay, and synchronization mechanisms of AXI bus timing and PCIe bus timing.

[0013] Optionally, the AHCI general verification platform includes a register configuration module, which is used to execute the HBA controller initialization process, port enable process, command start process, interrupt configuration process and real-time status reading process according to the set specifications. The HBA controller initialization process includes: completing the HBA global hardware reset and soft reset operations, automatically parsing the HBA capability register to identify hardware capability parameters, and configuring the global control register based on the hardware capability parameters; The port enabling process includes: performing port link reset, port status clearing, transmission mode configuration, SATA link negotiation enabling, NCQ queue function enabling, PIO transmission path and DMA transmission path enabling operations on each independent physical port, and initializing the command list base address, FIS receive buffer base address and queue depth configuration for the corresponding port. The command startup process includes: automatically building and loading the AHCI standard command table and PRD linked list, automatically completing command parameter validity verification, transmission address alignment verification and transmission length compliance verification, and setting the port command startup register according to the AHCI protocol timing. The interrupt configuration process includes: supporting hierarchical configuration of global interrupts and port local interrupts; independently enabling and disabling DMA transfer completion interrupts, device FIS acknowledgment interrupts, link connection / disconnection interrupts, NCQ command completion interrupts, transmission error interrupts, and timeout exception interrupts by configuring the global interrupt mask and port IE interrupt enable register. The real-time status reading process includes: acquiring the HBA global running status, physical port link status, command queue occupancy, current command execution progress, data transmission completion status, interruption suspension status, and protocol error statistics status in real time by combining periodic register sampling with event callbacks.

[0014] Optionally, the AHCI universal verification platform further includes: The incentive generation module is connected to the AHCI general verification component and is used to generate incentives based on different scenarios. The incentives include at least one of read / write commands, NCQ commands, exceptions, timeouts, error responses, and hot-plugging. The scoring board and data inspection module are connected to the AHCI general verification component. They are used to automatically compare the correctness of written data and read data, register status, interrupt signals and FIS frames, and to report and locate problems in real time when the comparison is inconsistent. The coverage statistics module is connected to the AHCI general verification component and is used to count at least one of command type coverage, register access coverage, interface switching coverage, abnormal scenario coverage, data length coverage, and transaction type coverage. The reset and clock control module is connected to the AHCI universal verification component and is used to control system reset, clock frequency and multi-clock domain synchronization.

[0015] On the other hand, embodiments of this application also provide a UVM-based AHCI verification method, applied to the aforementioned UVM-based AHCI verification system, the method comprising: The AHCI universal verification platform selects the host interface bus type on the host side and the vendor VIP module type on the device side based on the configuration information of the module under test. The host interface bus type is either AXI bus or PCIe bus. The AHCI universal verification platform starts the verification environment, establishes a communication link with the host side through the multi-interface adaptation module, and establishes a communication link with the device side through the multi-vendor VIP adaptation module. The AHCI universal verification platform sends standardized configuration transactions to the module under test via the multi-interface adaptation module through the AHCI universal verification component to complete the register initialization, port enabling and interrupt configuration of the AHCI controller in the module under test. The AHCI universal verification platform issues test task instructions to the AHCI universal verification component; the AHCI universal verification component generates standardized protocol data packets conforming to the AHCI protocol specification according to the test task instructions; the host-side transactions in the standardized protocol data packets are converted into bus transactions of the corresponding host interface bus protocol by the multi-interface adaptation module and then sent to the module under test; the device-side FIS frames in the standardized protocol data packets are converted into a private format recognizable by the corresponding vendor VIP module by the multi-vendor VIP adaptation module and then sent to the vendor VIP module. The AHCI universal verification component receives the host-side response returned by the module under test through the multi-interface adaptation module, and receives the device-side response returned by the vendor VIP module through the multi-vendor VIP adaptation module, and normalizes the responses from both sides into standardized feedback data respectively. The AHCI general verification component reports the standardized feedback data to the AHCI general verification platform, and the AHCI general verification platform determines the execution result of the current test command based on the standardized feedback data.

[0016] Optionally, the step of sending the device-side FIS frame in the standardized protocol data packet to the vendor VIP module after being converted into a proprietary format recognizable by the corresponding vendor VIP module by the multi-vendor VIP adaptation module includes: The AHCI universal verification component generates a standardized device-side FIS frame sending request based on the currently executed test task. The AHCI universal verification component sends the standardized device-side FIS frame sending request to the multi-vendor VIP adaptation module through the unified calling interface of the multi-vendor VIP adaptation module. The multi-vendor VIP adaptation module converts the standardized device-side FIS frame into a private format data that can be recognized by the corresponding vendor VIP module according to the type of the currently bound vendor VIP module. The multi-vendor VIP adaptation module sends the proprietary format data to the corresponding vendor VIP module through the driver interface of the vendor VIP module.

[0017] Compared with the prior art, this application has the following advantages: This application constructs a generic AHCI verification component independent of the vendor's VIP module and host interface as the protocol core, and sets up a multi-vendor VIP adaptation module and a multi-interface adaptation module as two independent isolation layers. This shields the upper core component from the differences in the underlying vendor's VIP interface and host bus protocol, thereby enabling a verification environment to be compatible with multiple vendors' VIPs and adapted to multiple host interfaces such as AXI and PCIe without modifying the core code.

[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic diagram of the modules of the UVM-based AHCI verification system provided in the embodiments of this application.

[0021] Figure 2 This is another schematic diagram of a UVM-based AHCI verification system provided in an embodiment of this application.

[0022] Figure 3 A schematic diagram of the modules of the AHCI universal verification component provided in the embodiments of this application.

[0023] Figure 4 A schematic diagram of the multi-vendor VIP adaptation module provided in the embodiments of this application.

[0024] Figure 5 An exemplary flowchart of the UVM-based AHCI verification method provided in this application embodiment.

[0025] In the picture: 110 - AHCI General Verification Component; 111 - AHCI Register Model Submodule; 112 - AHCI Command Construction Submodule; 113 - FIS Frame Transmission and Parsing Submodule; 114 - NCQ Queue Management Submodule; 115 - PIO / DMA Transmission Control Submodule; 116 - Interrupt Handling Submodule; 117 - Error Detection and Protocol Checking Submodule; 120 - AHCI General Verification Platform; 130 - Multi-Vendor VIP Adaptation Module; 140 - Multi-Interface Adaptation Module. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0027] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0028] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0029] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Some embodiments of this application are described in detail below with reference to the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0030] As described in the background section, existing AHCI verification schemes are incompatible with VIPs from different vendors and cannot adapt to multiple host interfaces.

[0031] In view of this, in order to solve the above problems, this application provides an AHCI verification system based on UVM. For ease of understanding, this application first explains the relevant technical terms: SATA: Serial Advanced Technology Attachment, a serial communication interface standard used to connect storage devices (such as hard drives and solid-state drives) to a host.

[0032] AHCI: Advanced Host Controller Interface, defines a standardized programming interface for interaction between system software and the SATA host controller.

[0033] UVM: Universal Verification Methodology, a standardized framework for chip functional verification based on the SystemVerilog language.

[0034] VIP: Verification Intellectual Property. This refers to pre-designed, reusable verification modules used to simulate the behavior of external devices.

[0035] DUT: Design Under Test, which is the target chip design or IP module to be verified.

[0036] FIS: Frame Information Structure, a data frame used in the SATA protocol to transmit control and status information between the host and the device.

[0037] NCQ, Native Command Queuing, is a feature of AHCI that allows a device to receive up to 32 commands simultaneously and optimize their execution order.

[0038] PIO, Programmable Input / Output, is a data transfer method that uses CPU instructions to move data.

[0039] DMA, or Direct Memory Access, is a data transfer method that moves data between memory and peripherals directly without going through the CPU.

[0040] PRD, Physical Region Descriptor, is a data structure used to describe the location and size of the data buffer in physical memory during DMA transfer.

[0041] HBA, Host Bus Adapter, is the AHCI controller itself, responsible for managing data transfer between the host and storage devices.

[0042] CAP, Capabilities Register, is one of the AHCI registers and identifies the hardware features supported by the HBA.

[0043] GHC, Global Host Control Register, is one of the AHCI registers and controls the global operating status of the HBA.

[0044] IS, Interrupt Status Register, is one of the AHCI registers and records the interrupt trigger status of each port.

[0045] IE, Interrupt Enable Register, is one of the AHCI registers that controls the enabling and disabling of interrupts on each port.

[0046] CLB, Command List Base Address Register, is one of the AHCI registers and specifies the starting address of the command list in memory.

[0047] FB, FIS Base Address Register, is one of the AHCI registers and specifies the starting address of the FIS receive buffer in memory.

[0048] PCIe, Peripheral Component Interconnect Express, is a high-speed serial computer expansion bus standard.

[0049] AXI, Advanced eXtensible Interface, is a high-performance bus interface in the AMBA (Advanced Microcontroller Bus Architecture) bus protocol proposed by ARM.

[0050] As one implementation method, please refer to Figure 1The UVM-based AHCI verification system includes: AHCI general verification component 110, AHCI general verification platform 120, multi-vendor VIP adaptation module 130, and multi-interface adaptation module 140. The AHCI universal verification component 110 connects to the module under test (DUT), operating independently of the vendor's VIP module and host interface bus protocol, and is used to implement the core logic of the AHCI protocol. The AHCI universal verification platform 120 connects to the AHCI universal verification component 110, providing a verification environment for AHCI verification of the DUT. The multi-vendor VIP adapter module 130 connects to the AHCI universal verification component 110 and multiple different types of vendor VIP modules, shielding the AHCI universal verification component 110 from the interface differences of each vendor's VIP module. The multi-interface adapter module 140 connects to the AHCI universal verification component 110 and multiple different types of host interface buses, shielding the AHCI universal verification component 110 from the protocol differences of each host interface bus. The AHCI universal verification component 110 interacts with the vendor's VIP module on the device side through the multi-vendor VIP adapter module 130, and interacts with different types of host interface buses on the host side through the multi-interface adapter module 140.

[0051] Understandably, this application constructs an AHCI universal verification component 110, which is independent of the vendor's VIP module and host interface, as the protocol core, and sets up a multi-vendor VIP adaptation module 130 and a multi-interface adaptation module 140 as two independent isolation layers. This shields the upper core components from the differences in the underlying vendor's VIP interface and host bus protocol, thereby enabling a verification environment to be compatible with multiple vendors' VIPs and adapt to multiple host interfaces such as AXI and PCIe without modifying the core code.

[0052] It should be noted that the module under test (DUT) described in this application can be a design under test (DUT) (i.e., an AHCI controller chip or IP module); the vendor VIP module can be a SATA verification intellectual property module from multiple different vendors, and the system also provides an external clock source and reset source. The vendor VIP module is a reusable verification model developed by EDA (Electronic Design Automation) tool vendors or professional IP (Intellectual Property) companies to simulate the behavior of SATA storage devices. Its behavior is similar to that of a real SATA hard drive chip. Before the chip is manufactured, verification engineers use this VIP model to interact with the AHCI controller design to discover errors in the design in advance.

[0053] The AHCI general verification component 110 is used to implement the core logic of the AHCI protocol, completely decoupled from the vendor's VIP module and host interface. It includes functions such as AHCI register model, command construction, FIS transmission and reception, interrupt handling, NCQ, PIO / DMA transfer, error detection, and protocol checking. For one implementation method, please refer to [link / reference]. Figure 2 and Figure 3 The AHCI Universal Validation Component 110 includes: The AHCI register model submodule 111 implements register reset, read / write mirroring, access permission checks, and automatic register field verification for the AHCI host bus adapter's register space, and provides an abstract application programming interface for register read / write. The AHCI command construction submodule 112 generates AHCI command headers and command tables. The FIS frame transmission and parsing submodule 113 encodes, transmits, and decodes various frame information structure types. The interrupt handling submodule 116 simulates the HBA interrupt state machine, handles device interrupts, DMA completion interrupts, error interrupts, and NCQ asynchronous interrupts, and maintains the interrupt mask corresponding to the interrupt status / interrupt enable. The NCQ queue management submodule 114 implements dispatching, out-of-order completion, queue reordering, asynchronous notification, queue overflow protection, and command timeout detection for multi-depth NCQ command circular queues. The PIO / DMA transfer control submodule 115 separates the PIO register transfer path from the DMA memory batch transfer path, and performs PRD linked list traversal, data movement, and transfer length matching verification. Error detection and protocol inspection submodule 117 is used to build in the AHCI protocol compliance inspection rule set and perform violation detection based on the rule set.

[0054] Among them, the AHCI register model submodule 111 fully implements the AHCI HBA register space, including the modeling of the following standard registers: CAP (Capability Register): Identifies the functional characteristics supported by the HBA, including supported NCQ command depth (maximum 32), maximum number of ports, supported command types, DMA transfer granularity, etc. Regarding NCQ (Native Command Queuing), the AHCI protocol specifies a maximum queue depth of 32. In practical applications, a depth value less than 32, such as 16 or 8, can be configured according to hardware design needs. This application flexibly supports various depth configurations through a register model.

[0055] GHC (Global Control Register): Controls the global operating state of the HBA, including global enable, soft reset control, interrupt enable, AHCI mode enable, etc.

[0056] IS (Interrupt Status Register): Records the current interrupt trigger status of each port.

[0057] Interrupt Enable Register (IE): Controls the enabling and disabling of interrupts on each port.

[0058] CLB (Command List Base Address Register): Specifies the starting address of the port command list in host memory.

[0059] FB (FIS Base Address Register): Specifies the starting address of the FIS receive buffer in the host memory. FIS (Frame Information Structure) is a data frame used in the SATA protocol to transmit control and status information between the host and the device.

[0060] This submodule also includes the following functions: register reset (all registers are restored to their default values ​​upon power-up), read / write mirroring (keeping the mirrored register values ​​consistent with the actual hardware values), access permission checking (distinguishing the legality of access to different types of registers such as read-only, write-only, and read / write), and automatic register field verification (performing protocol compliance checks on the values ​​of each field in the registers). Furthermore, this submodule provides a standardized register read / write abstract API (Application Programming Interface) for other components in the verification environment to call.

[0061] In UVM verification environments, register models are typically implemented by deriving from base classes such as `uvm_reg_block` and `uvm_reg`. Each register is defined as a subclass of `uvm_reg`, and register fields are defined as subclasses of `uvm_reg_field`. Register read and write operations are implemented through the backdoor and frontdoor access mechanisms provided by UVM. This application uses UVM's standard register abstraction layer method to construct the register model, ensuring seamless integration with the UVM verification environment.

[0062] The AHCI command construction submodule 112 is responsible for standardizing the generation of the AHCI Command Header and Command Table. The command header contains general control information for the command, including: the command's FIS type indication, command priority, PRD table length, transfer direction (read / write), and command status.

[0063] The command table contains the specific command parameters, and different types of commands have different content formats: NCQ commands include NCQ tags (used to identify specific entries in the command queue, with values ​​ranging from 0 to 31), LBA (Logical Block Addressing) addresses, sector counts, and command codes.

[0064] PIO commands: contain PIO (Programmed Input / Output) transmission parameters. PIO is a transmission method that uses CPU instructions to move data, mainly used for small data volume scenarios such as device identification and configuration information reading.

[0065] DMA read / write commands: These include DMA (Direct Memory Access) transfer parameters. DMA is a data transfer method that moves data directly between memory and peripherals without going through the CPU. It is suitable for scenarios involving large-volume batch transfers and can significantly reduce CPU load.

[0066] Device identification command: contains device identification request parameters.

[0067] This submodule is also responsible for automatically populating the PRD physical descriptor linked list. It supports variable transmission length and multi-segment PRD fragmentation, enabling flexible construction of data transmission scenarios with different sizes and segmentation methods according to testing requirements.

[0068] The FIS frame transmission and reception parsing submodule 113 implements the encoding, transmission, reception, and decoding functions for all standard FIS types. FIS is a standard data structure in the SATA protocol used for transmitting control and status information between the host and device. The standard FIS types supported by this submodule include: Register FIS: Used to transfer register values ​​between the host and the device, it is the most basic FIS type and is used for command issuance and status reading.

[0069] Data FIS: Used for actual data transmission, containing the data payload, and is used in both PIO and DMA transfers.

[0070] PIO Setup FIS: Used to establish PIO transmissions, containing parameter information for PIO transmissions.

[0071] DMA Setup FIS: Used to establish DMA transfers, containing address and length information for the DMA transfer.

[0072] PIO Setup FIS / DMA Setup FIS (Device Bit Setting FIS): Used by the device to report status bits to the host, playing a key role in NCQ asynchronous notification.

[0073] In terms of encoding and transmission, this submodule receives standard structured FIS data from the upper-layer protocol logic, packages, verifies, and fills fields according to the format specified by the SATA protocol, and generates an FIS frame data stream that can be sent by the lower-layer VIP. In terms of receiving and decoding, this submodule receives device FIS frames reported by the lower-layer VIP, performs FIS type identification, length verification, and field validity verification, and then parses them into a standardized FIS structure for use by the upper layer.

[0074] The interrupt handling submodule 116 is used to simulate the HBA interrupt state machine and handle various interrupt events. The interrupt mechanism is the key to the efficient I / O operation of the AHCI protocol, and this submodule can accurately simulate the interrupt behavior of the HBA in various transmission scenarios.

[0075] This submodule handles the following types of interrupts: Device interruption: Various asynchronous notifications issued by SATA devices.

[0076] DMA completion interrupt: Triggered after DMA transfer is completed.

[0077] Error interruption: Triggered when an error occurs during transmission.

[0078] NCQ Asynchronous Interrupt: Triggered when an NCQ command completes out of order, and reports the completion status to the host via Set Device Bits FIS.

[0079] This submodule is also responsible for automatically maintaining the IS (Interrupt Status) / IE (Interrupt Enable) interrupt mask, realizing hierarchical control of interrupt enabling and masking, generating standardized interrupt event reporting signals, and distinguishing between edge-triggered and level-triggered interrupt types to ensure accurate simulation of interrupt behavior.

[0080] The NCQ queue management submodule 114 is used to manage a 32-deep NCQ command circular queue. NCQ is a key feature of the AHCI protocol, allowing the host to send up to 32 commands to the device simultaneously. The device optimizes the command execution order based on its internal state to improve storage access performance. The core functions of this submodule include command dispatch, out-of-order completion, queue reordering, asynchronous NCQ notification, queue overflow protection, and command timeout detection, strictly adhering to the AHCI NCQ scheduling specification.

[0081] The PIO / DMA transfer control submodule 115 separates the PIO register transfer path from the DMA memory batch transfer path, enabling independent control of the two transfer modes. In the PIO path, this submodule simulates the process of transferring data byte-by-byte via register access, primarily used for small data volume scenarios such as device identification and configuration information reading. In the DMA path, this submodule implements efficient batch data transfer control, including: traversing the PRD linked list to determine the physical address sequence for transfer, triggering host memory data movement, ensuring SATA device-side data buffer alignment, and performing length matching checks to prevent data overflow or insufficiency.

[0082] The error detection and protocol inspection submodule 117 has a built-in AHCI protocol compliance inspection rule set, which can automatically detect and report various protocol violations. Detection rules include, but are not limited to: Register illegal access detection: For example, detecting write operations to read-only registers, read operations to write-only registers, and access to reserved addresses. FIS field illegal value detection: For example, checking if each field in the FIS is within the legal value range. NCQ command ID conflict detection: For example, detecting whether commands were issued using the same NCQ tag. DMA length mismatch detection: For example, checking if the total length described in the PRD matches the actual transmission length. Transmission timeout detection: For example, checking if the transmission process exceeds the maximum time specified by the protocol. Interrupt exception detection: For example, checking if the timing and status of interrupt signals comply with regulations. Protocol timing violation detection: For example, checking if the timing relationship between various protocol operations meets the specification requirements. Upon detecting an error, this submodule automatically prints a detailed error log (including error type, occurrence time, relevant register values, FIS content, etc.) and throws a verification failure flag for the scoring board or upper-layer test cases to capture and process.

[0083] The aforementioned submodules are functionally independent, each responsible for its own function and not interfering with the internal operations of other modules. In actual runtime, they collaborate closely through standardized data objects and API calls.

[0084] Taking a "DMA write command" as an example, the data flow order between the sub-modules is as follows: the register model sub-module is first called to read registers such as CAP and GHC to confirm the controller's capabilities; then the command construction sub-module generates a command table and PRD linked list according to the test task; next, the FIS transceiver parsing sub-module generates the corresponding Register FIS; the NCQ queue management sub-module 114 adds the command to the queue for dispatch and scheduling; the PIO / DMA transfer control sub-module 115 executes the actual DMA data transfer; after the transfer is completed, the interrupt handling sub-module 116 captures and reports the DMA completion interrupt; finally, the error detection and protocol check sub-module 117 performs compliance verification on the entire process.

[0085] The submodules do not directly call each other's internal functions. Instead, they communicate through standardized data objects (such as command objects, FIS objects, and status objects). This ensures both the independent maintainability of each submodule and the seamless integration of the overall functionality.

[0086] As one implementation method, please refer to Figure 4 The multi-vendor VIP adapter module 130 includes: A unified calling interface connects to the AHCI general verification component 110 and is called by the AHCI general verification component 110; multiple differentiated adaptation driver interfaces connect to different vendor VIP modules respectively, and each differentiated adaptation driver interface adapts and converts the operation of the corresponding vendor VIP module; the multi-vendor VIP adaptation module 130 uses the unified calling interface and multiple differentiated adaptation driver interfaces to bidirectionally isolate and translate the AHCI general verification component 110 and the underlying vendor VIP modules.

[0087] This application adopts the concept of encapsulation model, which completely encapsulates the implementation differences of VIPs from various vendors within the adaptation layer through the multi-vendor VIP adaptation module 130. The upper-layer AHCI general verification component 110 accesses all vendor VIPs through a unified interface without needing to care about the specific implementation methods of the underlying VIPs.

[0088] The multi-vendor VIP adaptation module, as the core execution unit of the vendor VIP module abstract adapter, undertakes bidirectional isolation between upper and lower layers and standardized translation capabilities. The module provides a unified calling interface to the upper layer and connects to VIP modules from different vendors to the lower layer. It completes the unified VIP initialization process, the FIS bidirectional forwarding process, the event synchronization process, and the unified hardware status reporting process, shielding the differences between underlying VIPs.

[0089] It should be noted that the unified calling interface defines a set of standardized method calls and data structures, covering the following operation types: register interaction interface (register read, register write), FIS message transmission and reception interface (FIS send, FIS receive), interrupt event reading interface, hardware status query interface, and link initialization control interface.

[0090] All protocol operations in the AHCI General Verification Component 110 are initiated and called only through these standardized interfaces. It is completely unaware of which vendor's VIP module is being accessed at the underlying level. There are no hard-coded vendor-specific signals, vendor-specific task functions, or vendor-customized timing logic.

[0091] Multiple differentiated adapter driver interfaces interface with different vendor VIP modules. Each differentiated adapter driver interface performs one-to-one adaptation and conversion for the unique characteristics of the corresponding vendor VIP module, including but not limited to: different adaptation of initialization timing, different adaptation of FIS message packing and unpacking formats, different adaptation of interrupt event reporting signal definitions, different adaptation of link status register mirror structure, different adaptation of completion event callback function mechanism, and different adaptation of abnormal status feedback logic.

[0092] Furthermore, the multi-vendor VIP adaptation module 130 is used to implement the following processes: The VIP unified initialization process is used to receive the link configuration parameters issued by the AHCI general verification component 110, and automatically map the link configuration parameters into the private initialization sequence, register configuration timing, reset process and link training trigger logic required by the corresponding vendor VIP module according to the type of the currently bound vendor VIP module, so as to complete the power-on reset, register configuration and physical link enable of the vendor VIP module.

[0093] This process receives standardized link configuration parameters from the AHCI universal verification component 110. These parameters include the number of channels, transmission rate, NCQ queue depth, and interrupt enable configuration. Then, based on the currently bound vendor VIP type, these standardized parameters are automatically mapped and converted into the private initialization sequence, register configuration timing, reset procedure, and link training trigger logic required by the corresponding vendor VIP, completing the VIP power-on reset, HBA basic register configuration, and SATA physical link enablement.

[0094] During the SATA physical layer initialization process, after the physical layer is reset, the state machine sequentially goes through different states, eventually entering the PR_Ready state. At this point, the physical layer initialization is complete and signal transmission and reception can begin. Different vendor VIPs may have differences in the specific timing and state transition details of physical layer initialization. The multi-vendor VIP adaptation module 130 implements corresponding initialization drivers for the characteristics of each vendor's VIP, ensuring that the initialization behavior seen by the upper-layer components is consistent regardless of which VIP is connected.

[0095] The FIS bidirectional forwarding process is used to translate the standard structured FIS data packets issued by the AHCI universal verification component 110 into an internal data structure that can be recognized by the current vendor's VIP module and then send it into the VIP transmission path. It also strips the vendor's private encapsulation header from the uplink returned device FIS frames from the VIP module side of each vendor, converts them into a unified standard FIS structure, and then passes it up to the AHCI universal verification component 110.

[0096] In the downlink direction, after the AHCI universal verification component 110 sends out standard structured FIS data packets through the unified interface, the adaptation module automatically translates the standard FIS fields into an internal data structure that can be recognized by the current vendor VIP, and then sends it into the VIP transmission path.

[0097] In the uplink direction, the adapter module listens to the device FIS frames returned by the VIP side of the manufacturer in real time, strips the manufacturer's proprietary encapsulation header or additional fields, converts them into a unified standard FIS structure, and then passes them up to the AHCI universal verification component 110.

[0098] The entire process masks the differences in FIS storage formats, bit order, and additional private identifier fields among various vendors.

[0099] The event synchronization processing flow is used to poll and register callbacks in real time to listen for DMA completion events, NCQ command completion events, device response events, and link establishment events within the VIP modules of each vendor, and to normalize the custom events of each vendor into event enumeration types defined by the protocol layer.

[0100] This process monitors various events within each vendor's VIP through real-time polling and registered callback listeners, including: DMA completion events, NCQ command completion events, device response events, and link establishment events.

[0101] For the monitored events, the adaptation module will unify and normalize the custom event identifiers (which may be integer IDs, string names or other forms) of various manufacturers into standardized event enumeration types defined by the protocol layer, eliminating the differences in event IDs and event reporting triggering methods (level callback, blocking task, status flag) between different manufacturers, and ensuring that the upper-layer event perception logic is completely universal.

[0102] The unified hardware status reporting process is used to periodically synchronize the HBA running status, SATA link online status, queue occupancy status, transmission error count, and interrupt suspension status within the VIP modules of various manufacturers, and to encapsulate the different status registers and status flags of various manufacturers into a unified status structure for output.

[0103] This process periodically synchronizes the HBA running status, SATA link online status, queue occupancy status, transmission error count, and interruption pending status within each vendor's VIP, and encapsulates the different status register layouts and status flag definitions of each vendor into a standardized status structure for output.

[0104] Thanks to the comprehensive design of layered interfaces, isolation of vendor-specific logic, and standardized data and event translation mechanisms, this adapter module completely shields the heterogeneous differences in interface definition, timing process, data encapsulation, and event reporting mechanisms among various vendors' SATA VIPs at the underlying level. This enables the AHCI protocol core logic to switch and connect to any vendor's SATA VIP without any modification.

[0105] As one implementation, the multi-interface adaptation module 140 includes a unified host access abstract interface, an AXI bus adaptation path, and a PCIe bus adaptation path. Based on the current verification platform's hardware configuration and bus operating mode, the multi-interface adaptation module 140 automatically identifies the effective host interface type and automatically switches between the AXI bus adaptation path and the PCIe bus adaptation path, loading the adaptation logic.

[0106] Among them, the Unified Host Access Abstraction Interface is called by the AHCI General Verification Component 110 to perform host memory access and status interaction operations. This interface defines standardized data structures and calling specifications for operations such as memory read, memory write, and register configuration. All core business logic at the upper layer completes the interaction based on this set of general abstraction interfaces.

[0107] The AXI bus adapter path is used to interface with the AXI host interface bus and handle the AXI protocol's unique read / write transactions, burst transfers, address mapping, and other logic. The AXI bus adopts a flat memory addressing mode, supports separate address / control / data phases, supports unaligned data transfer, and supports out-of-order transaction completion.

[0108] The PCIe bus adapter path is used to interface with the PCIe host interface bus and handle PCIe protocol-specific logic such as memory transactions, configuration transactions, and message transactions. The PCIe bus uses a point-to-point message-based data bus with scalable transmission line speed, and is typically used for high-speed data transmission between I / O modules and external modules.

[0109] The multi-interface adapter module 140 is used to perform at least one of the following functions: A unified address mapping adaptation mechanism is used to build a globally unified address mapping model, automatically completing bidirectional translation and alignment conversion between AXI physical addresses, PCIe bus addresses and AHCI controller local addresses, so as to unify the address read / write, PRD linked list address resolution and DMA addressing access logic of the AHCI general verification component 110.

[0110] Through this mechanism, the address reading and writing of upper-layer components, the PRD linked list address resolution, and the DMA addressing access logic are unified, avoiding problems such as addressing anomalies, data misalignment, and transmission failures that may be caused by the differences in the two types of bus address mapping rules.

[0111] In its implementation, for the PCIe bus, the adapter module utilizes the BAR (Base Address Register) mechanism in the PCIe protocol for address mapping. PCIe devices request address space from the system via the BAR, the system software writes the physical address into the BAR, and the device responds to host access within that address range. This application simulates the BAR configuration process of a PCIe device to map the AHCI controller's memory space into the PCIe address space, enabling PCIe hosts to access the AHCI controller. For the AXI bus, flat addressing is directly performed using the AXI address signals.

[0112] The bus transaction bidirectional conversion function is used to automatically parse and convert memory read transactions, memory write transactions, register configuration transactions, DMA initiation transactions and transmission termination transactions issued by the AHCI general verification component 110 into standard transaction messages and timing operations of the AXI bus or PCIe bus, and to normalize the completed transactions, response status and transmission end signals reported by the AXI bus and PCIe bus into transaction feedback structures and transmit them to the AHCI general verification component 110.

[0113] The cross-bus interrupt signal synchronization and timing compatibility unit is used to address the differences between the AXI level interrupt reporting mechanism and the PCIe message interrupt and MSI (Message Signaled Interrupt) interrupt reporting mechanisms. It unifies the interrupt identification, synchronization and reporting logic, completes the sampling calibration, edge synchronization, debouncing and event normalization processing of interrupt signals from different buses, and uniformly encapsulates the interrupt signals of the underlying heterogeneous buses into standard AHCI interrupt events and reports them to the AHCI general verification component 110.

[0114] The multi-bus timing compatibility calibration unit is used to automatically perform timing adaptation, cross-clock domain synchronization, data sampling alignment, and transmission delay compensation for the different handshake logic, transmission delay, and synchronization mechanisms of AXI bus timing and PCIe bus timing.

[0115] Through the aforementioned comprehensive and multi-dimensional bus adaptation and differentiated shielding mechanisms, this adaptation module achieves seamless compatibility and automatic switching between AXI and PCIe dual host interfaces, completely eliminating the strong coupling between the upper-layer verification core and the lower-layer host bus type.

[0116] As one implementation method, the AHCI general verification platform 120 includes a register configuration module, which is used to execute the HBA controller initialization process, port enable process, command start process, interrupt configuration process and real-time status reading process according to the set specifications. The HBA controller initialization process includes: completing the HBA global hardware reset and soft reset operations, automatically parsing the HBA capability register to identify hardware capability parameters, and configuring the global control register based on the hardware capability parameters.

[0117] For example, when performing a global hardware reset and a soft reset, the HBA global hardware reset operation is performed first, which is triggered by setting the HR bit of the GHC register, and then the reset is waited for to complete. Subsequently, a soft reset operation is performed to clear the controller's internal state machine, command queue, interrupt pending flag, and transmission buffer data, ensuring that the controller returns to its standard initial state.

[0118] When parsing capability parameters, the HBA capability registers CAP and CAP2 (Capabilities 2 Register) are automatically parsed to identify hardware capability parameters such as NCQ depth, maximum number of ports, DMA transfer granularity, timeout mechanism, and sleep power consumption mode supported by the current controller.

[0119] When configuring the global control register, the standardized configuration of the GHC register is completed based on the read capability parameters, including enabling the global HBA, enabling asynchronous notification, resetting and releasing, binding the host memory base address, and configuring register access permissions.

[0120] The port enabling process includes: performing port link reset, port status clearing, transmission mode configuration, SATA link negotiation enabling, NCQ queue function enabling, PIO transmission path and DMA transmission path enabling operations on each independent physical port, and initializing the command list base address, FIS receive buffer base address and queue depth configuration for the corresponding port.

[0121] The command startup process includes: automatically building and loading the AHCI standard command table and PRD linked list, automatically completing command parameter validity verification, transmission address alignment verification and transmission length compliance verification, and setting the port command startup register according to the AHCI protocol timing.

[0122] The interrupt configuration process includes: supporting hierarchical configuration of global interrupts and port local interrupts; independently enabling and disabling DMA transfer completion interrupts, device FIS acknowledgment interrupts, link connection / disconnection interrupts, NCQ command completion interrupts, transmission error interrupts, and timeout exception interrupts by configuring the global interrupt mask and port IE interrupt enable register.

[0123] The real-time status reading process includes: acquiring the HBA global running status, physical port link status, command queue occupancy, current command execution progress, data transmission completion status, interruption suspension status, and protocol error statistics status in real time through a combination of periodic register sampling and event callbacks.

[0124] In addition, as an implementation method, the AHCI general verification platform 120 also includes an incentive generation module, a scoreboard and data checking module, a coverage statistics module, and a reset and clock control module.

[0125] The stimulus generation module connects to the AHCI general verification component 110 and is used to generate stimuli based on different scenarios. The stimuli include at least one of read / write commands, NCQ commands, exceptions, timeouts, error responses, and hot-plugging.

[0126] The stimulus generation module is based on the UVM constraint stochastic verification methodology and supports stimulus generation for the following three scenarios: Constrained random scenarios: Define the range of values ​​and constraints for random variables. The UVM randomization engine automatically generates diverse test stimuli, covering various combinations in the parameter space. In UVM, constrained randomization is implemented using the `rand` keyword and the `constraint` block. Verification engineers can define random variables such as data length, LBA address, command type, and NCQ label, and ensure that the generated stimulus scenarios conform to the protocol specifications through cross constraints.

[0127] Targeted scenarios: For specific functionalities or boundary conditions, directly specify specific combinations of command parameters for targeted verification of specific functions. For example, for a full NCQ queue scenario, generate 32 consecutive NCQ commands; for a PRD cross-page boundary scenario, construct a cross-page PRD descriptor.

[0128] Hybrid Scenario: Combining random and targeted methods, while keeping the basic configuration fixed, some parameters are randomized. For example, the DMA write command type is fixed, but the data length and LBA address are randomized.

[0129] The generated read / write commands include single-sector, multi-sector, and cross-page boundary commands; NCQ commands include single command, concurrent multi-command, and queue full scenarios; abnormal scenarios include command errors, data errors, and protocol violations; timeout scenarios include device unresponsiveness and link interruption; error response scenarios include device returning an error status; and hot-plug scenarios include dynamic link connection and disconnection.

[0130] The scoring board and data inspection module are connected to the AHCI general verification component 110 to automatically compare the correctness of written data and read data, register status, interrupt signals and FIS frames, and to report errors and locate problems in real time when the comparison is inconsistent.

[0131] During data comparison, the system automatically captures the data content of write operations and compares it byte-by-byte with the data returned by subsequent read operations. Any inconsistencies are immediately reported. This function supports data lengths ranging from a single sector (512 bytes) to the maximum transmission unit (MTB), and supports data reassembly and comparison in scenarios with discontinuous PRD segments. During register status comparison, the system periodically compares the mirrored register values ​​with the actual read values ​​to detect abnormal tampering or configuration failures. During interrupt signal comparison, the system checks the timing and type consistency between expected interrupt occurrences and actual interrupt triggers. During FIS frame correctness comparison, the system performs field-by-field format checks and content verification on the transmitted and received FIS frames, including FIS type, length, and the legal values ​​of each field.

[0132] For all inconsistencies discovered during comparison, the scoreboard automatically prints detailed error information (including error type, expected value, actual value, occurrence time, and relevant context), pinpointing the specific test case execution phase. The coverage statistics module, connected to the AHCI general verification component 110, is used to calculate at least one of the following: command type coverage, register access coverage, interface switching coverage, exception scenario coverage, data length coverage, and transaction type coverage.

[0133] Command type coverage refers to the coverage of various AHCI commands (PIO read, PIO write, DMA read, DMA write, NCQ commands, device identification, etc.). Register access coverage refers to the coverage of access operations to various AHCI registers, including read / write combinations of different registers. Interface switching coverage refers to the coverage of each function point under both AXI and PCIe interface modes. Anomaly scenario coverage refers to the coverage of various error injection and anomaly handling processes. Data length coverage refers to the coverage range of different data transmission lengths (from a single sector to the maximum transmission unit). Transaction type coverage refers to the coverage of various bus transaction types. Coverage data is updated in real time during simulation, and a standardized coverage report is generated after simulation to allow verification engineers to evaluate verification progress and quality.

[0134] The reset and clock control module, connected to the AHCI universal verification component 110, is used to control system reset, clock frequency, and multi-clock domain synchronization.

[0135] The reset and clock control module is responsible for providing stable and controllable reset signals and clock cycles for the entire verification environment. Reset control refers to the module generating a power-on reset sequence to ensure that each module completes its reset sequentially according to the correct timing. It supports both hard reset (global reset) and soft reset (partial reset) modes to meet the needs of different verification scenarios. Clock control refers to the module generating the clock signal required for the AHCI controller to operate, supporting flexible clock frequency configuration to adapt to different operating modes (such as normal operating mode, low-power partial mode, and sleep / slumber mode). In the SATA physical layer, after physical layer initialization, it enters the PR_Ready state, at which point it can enter low-power mode (partial) or sleep mode (slumber) according to control information. Multi-clock domain synchronization refers to the fact that different bus interfaces such as AXI and PCIe may have different operating clock frequencies; this module ensures the correctness of data transmission between clock domains through a cross-clock domain synchronization mechanism.

[0136] Based on the above implementation, this application provides an AHCI verification method based on UVM. Please refer to [link / reference]. Figure 5 The method includes: S102, the AHCI universal verification platform 120 selects the host interface bus type on the host side and the vendor VIP module type on the device side based on the configuration information of the module under test. The host interface bus type is either AXI bus or PCIe bus.

[0137] S104, the AHCI universal verification platform 120 starts the verification environment, establishes a communication link with the host side through the multi-interface adapter module 140, and establishes a communication link with the device side through the multi-vendor VIP adapter module 130.

[0138] S106, the AHCI universal verification platform 120 sends standardized configuration transactions to the module under test via the AHCI universal verification component 110 and the multi-interface adapter module 140 to complete the register initialization, port enabling and interrupt configuration of the AHCI controller in the module under test.

[0139] S108, the AHCI universal verification platform 120 issues a test task instruction to the AHCI universal verification component 110; the AHCI universal verification component 110 generates a standardized protocol data packet conforming to the AHCI protocol specification according to the test task instruction; the host-side transactions in the standardized protocol data packet are converted into bus transactions of the corresponding host interface bus protocol by the multi-interface adaptation module 140 and then sent to the module under test; the device-side FIS frames in the standardized protocol data packet are converted into a private format recognizable by the corresponding vendor VIP module by the multi-vendor VIP adaptation module 130 and then sent to the vendor VIP module.

[0140] S110, the AHCI universal verification component 110 receives the host-side response returned by the module under test through the multi-interface adapter module 140, and receives the device-side response returned by the vendor VIP module through the multi-vendor VIP adapter module 130, and normalizes the responses from both sides into standardized feedback data respectively.

[0141] S112, the AHCI general verification component 110 reports the standardized feedback data to the AHCI general verification platform 120, and the AHCI general verification platform 120 determines the execution result of the current test command based on the standardized feedback data.

[0142] As one implementation, the steps of converting the device-side FIS frame in the standardized protocol data packet into a proprietary format recognizable by the corresponding vendor's VIP module via the multi-vendor VIP adaptation module 130 and then sending it to the vendor's VIP module include: The AHCI General Verification Component 110 generates a standardized device-side FIS frame sending request based on the currently executed test task. The AHCI universal verification component 110 sends standardized device-side FIS frame sending requests to the multi-vendor VIP adaptation module 130 through the unified calling interface of the multi-vendor VIP adaptation module 130. The multi-vendor VIP adaptation module 130 converts the standardized device-side FIS frames into private format data that can be recognized by the corresponding vendor VIP module, based on the type of the currently bound vendor VIP module. The multi-vendor VIP adapter module 130 sends proprietary format data to the corresponding vendor VIP module through the driver interface of the corresponding vendor VIP module.

[0143] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0144] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. An AHCI verification system based on UVM, characterized in that, The system includes: AHCI universal verification component, connects to the module under test, is independent of the vendor's VIP module and host interface bus protocol, and is used to implement the core logic of the AHCI protocol; The AHCI universal verification platform connects to the AHCI universal verification component and provides a verification environment for performing AHCI verification on the module under test. A multi-vendor VIP adaptation module connects to the AHCI universal verification component and multiple different types of vendor VIP modules, and is used to shield the interface differences of the vendor VIP modules from the AHCI universal verification component. A multi-interface adapter module is connected to the AHCI universal verification component and various different types of host interface buses respectively, and is used to shield the protocol differences of each host interface bus from the AHCI universal verification component. The AHCI universal verification component interacts with the vendor VIP module on the device side through the multi-vendor VIP adaptation module, and interacts with different types of host interface buses on the host side through the multi-interface adaptation module.

2. The UVM-based AHCI verification system according to claim 1, characterized in that, The AHCI universal verification component includes: The AHCI register model submodule is used to implement register reset, read / write mirroring, access permission check and automatic register field verification of the register space of the AHCI host bus adapter, and provides an abstract application programming interface for register read / write. The AHCI command construction submodule is used to generate AHCI command headers and command tables. The FIS frame transceiver parsing submodule is used to encode, transmit, receive, and decode various frame information structure types. The interrupt handling submodule is used to simulate the HBA interrupt state machine, handle device interrupts, DMA completion interrupts, error interrupts and NCQ asynchronous interrupts, and maintain the interrupt mask corresponding to the interrupt status / interrupt enable. The NCQ queue management submodule is used to implement the dispatching, out-of-order completion, queue reordering, asynchronous notification, queue overflow protection, and command timeout detection of multi-depth NCQ command circular queues. The PIO / DMA transfer control submodule is used to separate the PIO register transfer path from the DMA memory batch transfer path, and to perform PRD linked list traversal, data handling and transfer length matching verification. The error detection and protocol inspection submodule is used to build in the AHCI protocol compliance inspection rule set and perform violation detection based on the rule set.

3. The UVM-based AHCI verification system according to claim 1, characterized in that, The multi-vendor VIP adaptation module includes: A unified calling interface is provided to connect with the AHCI general verification component and to be called by the AHCI general verification component. Multiple differentiated adapter driver interfaces are provided, each connecting to a different manufacturer's VIP module. Each of these differentiated adapter driver interfaces adapts and converts the operation of the corresponding manufacturer's VIP module. The multi-vendor VIP adaptation module uses the unified calling interface and the multiple differentiated adaptation driver interfaces to bidirectionally isolate and translate the AHCI general verification component with the underlying VIP modules of each vendor.

4. The UVM-based AHCI verification system according to claim 3, characterized in that, The multi-vendor VIP adaptation module is used to implement the following process: The VIP unified initialization process is used to receive the link configuration parameters issued by the AHCI general verification component, and automatically map the link configuration parameters into the private initialization sequence, register configuration timing, reset process and link training trigger logic required by the corresponding vendor VIP module according to the currently bound vendor VIP module type, so as to complete the power-on reset, register configuration and physical link enable of the vendor VIP module. The FIS bidirectional forwarding process is used to translate the standard structured FIS data packets issued by the AHCI universal verification component into an internal data structure that can be recognized by the current vendor's VIP module and send it into the VIP transmission path, and to strip the vendor's private encapsulation header from the uplink returned device FIS frames from the VIP module side of each vendor and convert them into a unified standard FIS structure and pass it up to the AHCI universal verification component. The event synchronization processing flow is used to poll and register callbacks in real time to listen for DMA completion events, NCQ command completion events, device response events and link establishment events inside the VIP modules of each vendor, and normalize the custom events of each vendor into event enumeration types defined by the protocol layer. The unified hardware status reporting process is used to periodically synchronize the HBA running status, SATA link online status, queue occupancy status, transmission error count, and interrupt suspension status within the VIP modules of various manufacturers, and to encapsulate the different status registers and status flags of various manufacturers into a unified status structure for output.

5. The UVM-based AHCI verification system according to claim 1, characterized in that, The multi-interface adaptation module includes: A unified host access abstraction interface is provided for the AHCI general verification component to call in order to perform host memory access and status interaction operations; AXI bus adapter path, used to interface with the AXI host interface bus; PCIe bus adapter path, used to interface with PCIe host interface bus; The multi-interface adaptation module automatically identifies the effective host interface type based on the current verification platform's hardware configuration and bus operating mode, and automatically completes bus path switching and adaptation logic loading between the AXI bus adaptation path and the PCIe bus adaptation path.

6. The UVM-based AHCI verification system according to claim 5, characterized in that, The multi-interface adapter module is used to perform at least one of the following functions: A unified address mapping adaptation mechanism is used to build a globally unified address mapping model, automatically completing bidirectional translation and alignment conversion between AXI physical addresses, PCIe bus addresses and AHCI controller local addresses, so as to unify the address reading and writing, PRD linked list address parsing and DMA addressing access logic of the AHCI general verification component. The bus transaction bidirectional conversion function is used to automatically parse and convert the memory read transaction, memory write transaction, register configuration transaction, DMA initiation transaction and transmission termination transaction issued by the AHCI general verification component into standard transaction messages and timing operations of the AXI bus or PCIe bus, and to normalize the completed transaction, response status and transmission end signal reported by the AXI bus and PCIe bus into a transaction feedback structure and transmit it to the AHCI general verification component. The cross-bus interrupt signal synchronization and timing compatibility unit is used to unify the interrupt identification, synchronization and reporting logic to address the differences between the AXI level interrupt reporting mechanism and the PCIe message interrupt and MSI interrupt reporting mechanisms. It completes the sampling calibration, edge synchronization, debouncing and event normalization processing of interrupt signals from different buses, and encapsulates the interrupt signals of the underlying heterogeneous buses into standard AHCI interrupt events and reports them to the AHCI general verification component. The multi-bus timing compatibility calibration unit is used to automatically perform timing adaptation, cross-clock domain synchronization, data sampling alignment, and transmission delay compensation for the different handshake logic, transmission delay, and synchronization mechanisms of AXI bus timing and PCIe bus timing.

7. The UVM-based AHCI verification system according to claim 1, characterized in that, The AHCI general verification platform includes a register configuration module, which is used to execute the HBA controller initialization process, port enable process, command start process, interrupt configuration process and real-time status reading process according to the set specifications. The HBA controller initialization process includes: completing the HBA global hardware reset and soft reset operations, automatically parsing the HBA capability register to identify hardware capability parameters, and configuring the global control register based on the hardware capability parameters; The port enabling process includes: performing port link reset, port status clearing, transmission mode configuration, SATA link negotiation enabling, NCQ queue function enabling, PIO transmission path and DMA transmission path enabling operations on each independent physical port, and initializing the command list base address, FIS receive buffer base address and queue depth configuration for the corresponding port. The command startup process includes: automatically building and loading the AHCI standard command table and PRD linked list, automatically completing command parameter validity verification, transmission address alignment verification and transmission length compliance verification, and setting the port command startup register according to the AHCI protocol timing. The interrupt configuration process includes: supporting hierarchical configuration of global interrupts and port local interrupts; independently enabling and disabling DMA transfer completion interrupts, device FIS acknowledgment interrupts, link connection / disconnection interrupts, NCQ command completion interrupts, transmission error interrupts, and timeout exception interrupts by configuring the global interrupt mask and port IE interrupt enable register. The real-time status reading process includes: acquiring the HBA global running status, physical port link status, command queue occupancy, current command execution progress, data transmission completion status, interruption suspension status, and protocol error statistics status in real time by combining periodic register sampling with event callbacks.

8. The UVM-based AHCI verification system according to claim 1, characterized in that, The AHCI universal verification platform also includes: The incentive generation module is connected to the AHCI general verification component and is used to generate incentives based on different scenarios. The incentives include at least one of read / write commands, NCQ commands, exceptions, timeouts, error responses, and hot-plugging. The scoring board and data inspection module are connected to the AHCI general verification component. They are used to automatically compare the correctness of written data and read data, register status, interrupt signals and FIS frames, and to report and locate problems in real time when the comparison is inconsistent. The coverage statistics module is connected to the AHCI general verification component and is used to count at least one of command type coverage, register access coverage, interface switching coverage, abnormal scenario coverage, data length coverage, and transaction type coverage. The reset and clock control module is connected to the AHCI universal verification component and is used to control system reset, clock frequency and multi-clock domain synchronization.

9. A UVM-based AHCI verification method, characterized in that, The method, applied to the UVM-based AHCI verification system as described in any one of claims 1 to 8, comprises: The AHCI universal verification platform selects the host interface bus type on the host side and the vendor VIP module type on the device side based on the configuration information of the module under test. The host interface bus type is either AXI bus or PCIe bus. The AHCI universal verification platform starts the verification environment, establishes a communication link with the host side through the multi-interface adaptation module, and establishes a communication link with the device side through the multi-vendor VIP adaptation module. The AHCI universal verification platform sends standardized configuration transactions to the module under test via the multi-interface adaptation module through the AHCI universal verification component to complete the register initialization, port enabling and interrupt configuration of the AHCI controller in the module under test. The AHCI universal verification platform issues test task instructions to the AHCI universal verification component; the AHCI universal verification component generates standardized protocol data packets conforming to the AHCI protocol specification according to the test task instructions; the host-side transactions in the standardized protocol data packets are converted into bus transactions of the corresponding host interface bus protocol by the multi-interface adaptation module and then sent to the module under test; the device-side FIS frames in the standardized protocol data packets are converted into a private format recognizable by the corresponding vendor VIP module by the multi-vendor VIP adaptation module and then sent to the vendor VIP module. The AHCI universal verification component receives the host-side response returned by the module under test through the multi-interface adaptation module, and receives the device-side response returned by the vendor VIP module through the multi-vendor VIP adaptation module, and normalizes the responses from both sides into standardized feedback data respectively. The AHCI general verification component reports the standardized feedback data to the AHCI general verification platform, and the AHCI general verification platform determines the execution result of the current test command based on the standardized feedback data.

10. The UVM-based AHCI verification method according to claim 9, characterized in that, The steps of sending the device-side FIS frames in the standardized protocol data packets to the vendor VIP module after being converted into a proprietary format recognizable by the corresponding vendor VIP module by the multi-vendor VIP adaptation module include: The AHCI universal verification component generates a standardized device-side FIS frame sending request based on the currently executed test task. The AHCI universal verification component sends the standardized device-side FIS frame sending request to the multi-vendor VIP adaptation module through the unified calling interface of the multi-vendor VIP adaptation module. The multi-vendor VIP adaptation module converts the standardized device-side FIS frame into a private format data that can be recognized by the corresponding vendor VIP module according to the type of the currently bound vendor VIP module. The multi-vendor VIP adaptation module sends the proprietary format data to the corresponding vendor VIP module through the driver interface of the vendor VIP module.

Images