Audio chip verification method based on layered verification IP and related device
Patent Information
- Application Number
- CN202611495368.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-24
- Publication Date
- 2026-10-30
AI Technical Summary
这种接口协议测试与内部功能测试相割裂的模式,无法实现端到端音频通路的闭环验证,难以真实反映芯片在实际工作中的音频传输质量
在本申请的实施例中,通过构建由激励层、协议层、时序层和监测层解耦配置的分层式验证IP,提高了验证架构内部逻辑的透明度与环境配置的灵活性;在自动化验证过程中,不仅通过获取音频反馈数据进行端到端闭环比对以确认内部音频通路功能,还同步利用监测层采集总线波形以执行协议一致性校验,实现了接口通信合规性测试与芯片内部核心功能处理测试的联动结合;此外,通过该验证IP向待测芯片针对性地注入目标异常特征并下发低功耗模式切换指令,捕获了芯片在边界工况下的容错表现与低功耗状态下的时序跳转数据。本申请的方案,基于多维度的测试反馈综合计算验证覆盖率,解决了传统验证环境相对封闭、接口协议测试与内部功能测试相割裂以及异常与低功耗边界场景难以覆盖的技术问题,提高了音频芯片自动化验证的测试完备度与验证结果的可靠性。
Smart Images

Figure CN123011627A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of integrated circuit chip verification technology, and specifically to an audio chip verification method and related apparatus based on hierarchical verification IP. Background Technology
[0002] With the increasing demand for multi-channel audio concurrency and ultra-low power standby in smart terminals, the MIPI SoundWire protocol, due to its support for bidirectional transmission and fine-grained low-power management, has gradually become the mainstream alternative to audio buses. Currently, verification of SoundWire interface chips typically relies heavily on commercial third-party verification IP. However, these commercial verification IPs are generally black-box packaged, with their internal logic not visible to the outside world. Testers cannot customize and extend them according to the proprietary protocols or differentiated functions of different manufacturers, resulting in poor verification flexibility.
[0003] In practical engineering verification, existing testing schemes often focus only on the compliance verification of the SoundWire bus interface protocol itself, failing to effectively link it with the core processing logic inside the audio chip (such as analog-to-digital conversion, digital-to-analog conversion, and gain adjustment). This model, which separates interface protocol testing from internal functional testing, cannot achieve closed-loop verification of the end-to-end audio path and is difficult to truly reflect the audio transmission quality of the chip in actual operation.
[0004] Meanwhile, due to the closed nature of existing verification environments, test platforms struggle to accurately simulate and batch-inject sudden situations such as bus timing anomalies and control frame loss. They also cannot effectively link and test the dynamic switching and rapid wake-up mechanisms of multi-level low-power modes. This insufficient coverage of boundary conditions and fault-tolerant scenarios can easily lead to missed defects in the underlying code, resulting in reliability issues such as state machine deadlock, sleep-wake failures, or audio frame drops in actual applications after chip fabrication. Summary of the Invention
[0005] In view of the aforementioned problems, this application is proposed to provide an audio chip verification method and related apparatus based on hierarchical verification IP that overcomes or at least partially solves the aforementioned problems, comprising: An audio chip verification method based on hierarchical verification IP, applied to a verification device, the method comprising: Configure a hierarchical verification IP according to the specifications of the audio chip under test, and establish a bidirectional communication connection with the audio chip under test; the hierarchical verification IP includes an excitation layer, a protocol layer, a timing layer and a monitoring layer that are decoupled from top to bottom; Test stimuli are generated through the stimulus layer and sent to the audio chip under test via the protocol layer and the timing layer. Audio feedback data returned by the audio chip under test is obtained, and end-to-end closed-loop comparison is performed on the audio feedback data to obtain the functional comparison result. The monitoring layer collects bus waveform data on the bidirectional communication connection, and performs a protocol consistency check on the bus waveform data to obtain the protocol check result. The target abnormal features are injected into the audio chip under test via the hierarchical verification IP, and / or a low-power mode switching command is issued to obtain the corresponding abnormal fault tolerance feedback data and / or low-power timing data. Based on the functional comparison results, protocol verification results, anomaly fault tolerance feedback data, and / or low-power timing data, the verification coverage data is calculated and a verification report is generated.
[0006] According to one embodiment of the present invention, after calculating and verifying the coverage data, the method further includes: If the verification coverage data does not reach the preset target, then random supplementary test cases are generated based on the verification coverage data. The hierarchical verification IP is triggered to perform iterative verification based on the supplementary test cases until the verification coverage data meets the standard.
[0007] According to one embodiment of the present invention, configuring the layered verification IP according to the specifications of the audio chip under test includes: Configure the audio sampling rate, transmission bit width, and random test case generation parameters in the excitation layer; Configure the multiplexing transmission logic for control frames and data frames, as well as the master-slave device operating mode, at the protocol layer; Configure the bus clock frequency, single-sided and double-sided edge sampling modes, and signal timing parameters in the timing layer; Monitoring nodes for passively verifying bus signals are mounted on the monitoring layer.
[0008] According to one embodiment of the present invention, the step of acquiring the audio feedback data returned by the audio chip under test and performing an end-to-end closed-loop comparison of the audio feedback data to obtain a functional comparison result includes: The test stimulus, which includes control frames, is sent via the bidirectional communication connection to instruct the audio chip under test to complete register configuration. Input a standard audio source signal to the audio chip under test; The audio feedback data transmitted back by the audio chip under test after processing the standard audio source signal through its internal functional pathway is obtained. Based on the sampling point comparison strategy and the spectrum feature comparison strategy, the audio feedback data is compared with the expected audio data generated according to the current audio configuration to obtain the audio path error index, and the function comparison result is generated based on the audio path error index.
[0009] According to one embodiment of the present invention, before calculating the verification coverage data, the method further includes: Obtain the complete set of parameter combinations of the audio chip under test in terms of sampling rate, transmission bit width, gain level, and channel mode. For any set of parameters encountered, the hierarchical verification IP is driven to perform audio transmission tests with the audio chip under test, and the continuity of audio transmission is monitored when the parameter combination is switched. Performance verification results are generated based on the continuous state and then added to the functional comparison results.
[0010] According to one embodiment of the present invention, injecting the target anomalous feature into the audio chip under test via the hierarchical verification IP includes at least one of the following: The protocol layer generates and sends a first abnormal stimulus containing protocol transmission abnormal characteristics, which include at least one of frame loss, data bit flipping, and bus burst preemption. The timing layer injects timing offsets or clock jitter into the bus signals; The activation layer generates and sends a second abnormal activation containing logical state abnormality features, which include at least one of parameter out-of-bounds, illegal configuration, and abnormal wake-up.
[0011] According to an embodiment of the present invention, the step of issuing a low-power mode switching command and obtaining corresponding fault-tolerant feedback data and low-power timing data includes: Mode switching commands are sequentially sent to the audio chip under test to instruct it to switch between normal operation, shallow sleep, deep sleep and event-triggered wake-up modes; During mode switching, monitor the pause and resume status of the bus clock; Obtain the sleep register hold value and wake-up response time of the audio chip under test; The low-power timing data is generated based on the sleep register hold value, wake-up response time, pause state, and resume state.
[0012] According to an embodiment of the present invention, the step of performing protocol conformance verification on the bus waveform data to obtain the protocol verification result includes: The monitoring layer verifies the frame synchronization characteristics and two-dimensional frame boundary alignment status, address compliance, control field encoding correctness, and corresponding bus state machine transition logic and timing margin of the bus waveform data. If a protocol violation is detected, an error log containing the violation type is generated and the corresponding simulation waveform timestamp is marked. The error logs and simulation waveform timestamps are compiled into the protocol verification result.
[0013] An audio chip verification device based on hierarchical verification IP, comprising: The environment configuration module is used to configure a hierarchical verification IP according to the specifications of the audio chip under test and establish a bidirectional communication connection with the audio chip under test; the hierarchical verification IP includes an excitation layer, a protocol layer, a timing layer and a monitoring layer that are decoupled from top to bottom; The functional closed-loop test module is used to generate test stimuli through the stimulus layer and send them to the audio chip under test via the protocol layer and the timing layer, obtain the audio feedback data returned by the audio chip under test, and perform end-to-end closed-loop comparison on the audio feedback data to obtain the functional comparison result. The protocol verification module is used to collect bus waveform data on the bidirectional communication connection through the monitoring layer, and perform protocol consistency verification on the bus waveform data to obtain the protocol verification result. The anomaly and power injection module is used to inject target anomaly features into the audio chip under test via the hierarchical verification IP, and / or issue low power mode switching instructions, and obtain corresponding anomaly fault tolerance feedback data and / or low power timing data. The coverage report module is used to calculate the verification coverage data and generate a verification report based on the functional comparison results, protocol verification results, anomaly fault tolerance feedback data and / or low power timing data.
[0014] A computer electronic device includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When executed by the processor, the computer program implements the steps of the audio chip verification method based on hierarchical verification IP as described above.
[0015] This application has the following advantages: In the embodiments of this application, by constructing a layered verification IP with decoupled configuration of the excitation layer, protocol layer, timing layer, and monitoring layer, the transparency of the internal logic of the verification architecture and the flexibility of the environment configuration are improved. During automated verification, not only is end-to-end closed-loop comparison performed by acquiring audio feedback data to confirm the internal audio path function, but the monitoring layer is also used simultaneously to collect bus waveforms to perform protocol consistency verification, realizing the linkage between interface communication compliance testing and chip internal core function processing testing. Furthermore, by injecting targeted abnormal features into the chip under test through this verification IP and issuing low-power mode switching instructions, the fault-tolerant performance of the chip under boundary conditions and the timing jump data in low-power states are captured. The solution of this application, based on multi-dimensional test feedback comprehensive calculation of verification coverage, solves the technical problems of relatively closed traditional verification environments, the separation of interface protocol testing and internal function testing, and the difficulty in covering abnormal and low-power boundary scenarios, thereby improving the test completeness and reliability of automated audio chip verification. Attached Figure Description
[0016] To more clearly illustrate the technical solution of this application, the drawings used in the description of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 This is a flowchart of an audio chip verification method based on hierarchical verification IP provided in an embodiment of this application; Figure 2 This is a partial flowchart of step S120 in an audio chip verification method based on hierarchical verification IP provided in an embodiment of this application; Figure 3 This is a partial flowchart of the audio chip verification method based on hierarchical verification IP provided in an embodiment of this application, before step S150. Figure 4 This is a schematic diagram of the internal logical architecture of a layered verification IP provided in an embodiment of this application; Figure 5 This is a structural block diagram of an audio chip verification device based on hierarchical verification IP provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a computer electronic device provided in an embodiment of the present invention; 1. Computer electronic device; 2. External device; 3. Processing unit; 4. Bus; 5. Network adapter; 6. I / O interface; 7. Display; 8. Memory; 9. Random access memory; 10. Cache memory; 11. Storage system; 12. Program / utility; 13. Program module. Detailed Implementation
[0018] To make the objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this 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.
[0019] Through analysis of existing technologies, the inventors discovered that most commercial audio verification IPs employ black-box packaging, making it difficult to flexibly configure underlying parameters such as sampling rate, multiplexing transmission logic, bus clock, and monitoring nodes. During routine testing, compliance verification of interface communication protocols is often separated from internal chip logic testing. This fails to perform end-to-end closed-loop comparison between the standard audio source signal and the data processed by internal analog-to-digital conversion, digital-to-analog conversion, and gain adjustment, making it difficult to accurately assess audio distortion in real-world scenarios. Furthermore, there is a lack of effective monitoring of audio transmission continuity during dynamic switching of multi-dimensional operating parameters. Simultaneously, due to the relatively closed verification environment, it is difficult to inject boundary anomalies such as frame loss, timing offsets, and illegal configurations at the protocol and functional layers. When verifying multi-level low-power mode switching, it is also impossible to accurately track clock start / stop states, sleep register hold values, and wake-up response times, making it easy to miss tests on the chip's fault tolerance mechanisms and timing jump logic. In addition, traditional verification processes generally lack a closed-loop feedback mechanism that automatically generates supplementary test cases based on the current coverage data and triggers iterations. This results in the entire verification process relying on manual intervention, making it difficult to efficiently and reliably converge to the expected test completeness target.
[0020] To make the objectives, technical solutions, and advantages of this invention clearer, before providing a detailed description of the specific embodiments of this invention, the following explanations and definitions are provided for some key technical terms involved in this invention: Verification Intellectual Property (VIP): Refers to a reusable virtual test component used in the integrated circuit design verification phase to simulate the communication behavior of bus protocols or interface peripherals. In this invention, it specifically refers to the SoundWire protocol functional module, which has a four-layer decoupled architecture consisting of an excitation layer, a protocol layer, a timing layer, and a monitoring layer, and whose internal logic is transparent and configurable.
[0021] Audio chip under test (DUT): refers to the target hardware object that is connected to the verification device for functional and protocol compliance verification. In this invention, it specifically refers to the codec chip and related audio peripheral chips equipped with the MIPI SoundWire interface.
[0022] UVM (Universal Verification Methodology): A standard framework for building chip verification platforms. It provides a standardized underlying class library and uses a controlled random number generation mechanism and modular encapsulation to build a verification environment with high reusability and automated iteration capabilities.
[0023] End-to-end closed-loop comparison: a comprehensive verification mechanism that crosses the boundary of a single interface. In this invention, it refers to a complete test process that not only verifies the protocol signals of the SoundWire bus interface, but also performs bidirectional mapping and verification of the standard audio source signals input to the audio chip under test and the data returned after processing by its internal core functional paths (such as analog-to-digital conversion, digital-to-analog conversion, gain adjustment, etc.).
[0024] Constrained random testing: an automated verification technology strategy. It refers to the automatic generation of random test stimulus sequences or parameter combinations by a computer within the preset parameter rules and boundaries (i.e., constraints) of the verification platform. The aim is to efficiently traverse unknown state spaces to fully expose the chip's boundary defects under complex operating conditions.
[0025] Reference Figure 1 This illustrates a Sound based on a hierarchical verification IP provided in an embodiment of this application. A method for verifying Wire protocol audio chips is presented. This method can be executed by a verification device, which is typically a hardware entity with logic operation and data communication scheduling capabilities. For example, the verification device can be, but is not limited to, a personal computer, graphics workstation, local server, cloud computing node, hardware emulator, or field-programmable gate array (FPGA) prototyping platform. The method specifically includes the following steps: S110. Configure a hierarchical verification IP according to the specifications of the audio chip under test, and establish a bidirectional communication connection with the audio chip under test; the hierarchical verification IP includes an excitation layer, a protocol layer, a timing layer and a monitoring layer that are decoupled from top to bottom.
[0026] During this step, the specifications of the audio chip under test are obtained and mapped to the configuration interface of the hierarchical verification IP. The hierarchical verification IP employs a modular decoupled architecture, using the specifications to initialize the use case generation rules of the stimulus layer, the frame transmission logic of the protocol layer, the bus sampling mode of the timing layer, and the verification rules of the monitoring layer. After configuration, the clock pin and bidirectional data multiplexing pin of the hierarchical verification IP are connected to the physical interfaces of the corresponding logic interfaces of the audio chip under test, respectively, to establish a bidirectional communication connection between them for data transmission and reception and status interaction.
[0027] As an optional internal logical reference, such as Figure 4 The diagram illustrates the internal logical architecture of the layered verification IP. In actual data flow, the stimulus layer, protocol layer, timing layer, and monitoring layer can perform specific data processing and state transitions through their respective internally encapsulated sub-units (such as the directional testing unit of the stimulus layer and the frame encapsulation and parsing unit of the protocol layer). Those skilled in the art should understand that... Figure 4 This is merely an example of logical data flow in a layered architecture and does not constitute a limitation on the physical structure of the entity executing the method steps in this application.
[0028] S120. Test stimuli are generated through the stimulus layer and sent to the audio chip under test via the protocol layer and the timing layer. Audio feedback data returned by the audio chip under test is obtained, and end-to-end closed-loop comparison is performed on the audio feedback data to obtain the functional comparison result.
[0029] After establishing a communication connection, an initial digital test stimulus is generated through the stimulus layer. This initial test stimulus undergoes a top-down data flow within the hierarchical verification IP. First, the protocol layer converts it into a control sequence and data payload conforming to the SoundWire bus specification. Then, the timing layer converts the control sequence and data payload into physical layer drive signals with setup and hold times, and sends them to the audio chip under test (AUT) along the bidirectional communication connection. The AUT receives the drive signal, processes it through its internal audio data path, and returns digital audio feedback data via the bidirectional communication connection. The verification device performs a reference transformation on the test audio source signal according to the currently configured sampling rate, transmission bit width, gain parameters, and channel mode, corresponding to the expected functional processing of the AUT, generating desired audio data. The device then performs feature comparison between the audio feedback data and the desired audio data to obtain the functional comparison result.
[0030] S130. The monitoring layer collects bus waveform data on the bidirectional communication connection, and performs a protocol consistency check on the bus waveform data to obtain the protocol check result.
[0031] During the transmission of the test stimulus and the audio feedback data, the bypass monitoring logic of the monitoring layer is simultaneously activated. The monitoring layer, acting as a non-intrusive passive data acquisition node, captures the clock toggle edges and data level states on the bidirectional communication link in real time, generating continuous bus waveform data. This bus waveform data is then sent to a preset protocol rule parser. By comparing the captured timing state transition logic with the ideal state transition logic defined by the standard protocol, it determines whether the audio chip under test has violated regulations or exceeded boundaries in its bus arbitration, frame format interaction, and other behaviors during data transmission and reception. The parser then generates the protocol verification result, which records the violation status and the corresponding time dimension.
[0032] S140. Inject target abnormal features into the audio chip under test via the hierarchical verification IP, and / or issue a low-power mode switching instruction to obtain corresponding abnormal fault-tolerant feedback data and / or low-power timing data.
[0033] To verify the boundary handling capabilities of the audio chip under test (AUT), the verification device generates target anomaly features containing non-standard logic or damaged characteristics and mixes them into the data transmission link of the hierarchical verification IP. The internal state recovery and interception behavior of the AUT after receiving an anomaly signal is monitored, and the data is collected and recorded as anomaly tolerance feedback data. Simultaneously, a low-power mode switching command is sent to the AUT via the hierarchical verification IP to intervene in its power supply or clock state. During the execution cycle of the command, the clock start / stop state sequence on the bus and the response delay interval of the AUT are continuously captured, and the aforementioned time-dimensional state transition information is aggregated into low-power timing data.
[0034] S150. Based on the functional comparison results, protocol verification results, fault tolerance feedback data and / or low-power timing data, calculate the verification coverage data and generate a verification report.
[0035] The functional comparison results, protocol verification results, anomaly tolerance feedback data, and low-power timing data, which are independently output from the aforementioned multiple dimensions, are summarized and analyzed. For example, the traversed parameter nodes and triggered functional branches recorded in the above data are extracted, and their intersection is compared with the full verification matrix pre-configured in the verification space to calculate the verification coverage data characterizing the current test completeness. Finally, the verification coverage data and the status logs from various verification processes are converted into a standardized format for output, generating the verification report.
[0036] In the embodiments of this application, by constructing a layered verification IP with decoupled configuration of the excitation layer, protocol layer, timing layer, and monitoring layer, the transparency of the internal logic of the verification architecture and the flexibility of the environment configuration are improved. During automated verification, not only is end-to-end closed-loop comparison performed by acquiring audio feedback data to confirm the internal audio path function, but the monitoring layer is also used simultaneously to collect bus waveforms to perform protocol consistency verification, realizing the linkage between interface communication compliance testing and chip internal core function processing testing. Furthermore, through this verification IP, targeted abnormal features are injected into the chip under test and / or low-power mode switching instructions are issued, capturing the chip's fault-tolerant performance under boundary conditions and / or timing jump data in low-power states. The solution of this application, based on multi-dimensional test feedback comprehensive calculation of verification coverage, solves the technical problems of relatively closed traditional verification environments, the separation of interface protocol testing and internal function testing, and the difficulty in covering abnormal and low-power boundary scenarios, thereby improving the test completeness and reliability of automated audio chip verification.
[0037] In one embodiment of the present invention, in step S150, after calculating the verification coverage data, the method further includes: if the verification coverage data does not reach a preset target, generating constrained random supplementary test cases based on the verification coverage data; triggering the hierarchical verification IP to perform iterative verification based on the supplementary test cases until the verification coverage data reaches the target.
[0038] Specifically, the verification device first compares the acquired verification coverage data with preset targets using feature comparison. When the target is not met, it extracts unmet state gaps from the data as constraint feedback conditions and dynamically adjusts the distribution weights of the random sequence generator to generate constraint random supplementary test cases pointing to the state gaps. In one example, by calling the controlled random number generation mechanism encapsulated in the UVM system, complex combinations of boundary test cases are automatically generated based on bias weights.
[0039] After generating the supplementary test cases, the generated supplementary test cases are further packaged and pushed into the scheduling queue of the hierarchical verification IP, triggering a new round of testing. The hierarchical verification IP reuses the aforementioned comparison and verification logic to update the cumulative coverage in real time, realizing fully automated unattended operation of full regression testing. This verification loop continues to execute until the latest coverage data meets the standard and then exits. In addition, to prevent physical dead code in the hardware logic from causing an infinite loop, the verification device starts the cumulative monitoring logic of the iteration count in parallel; when the number of executions reaches the preset safety threshold limit and the coverage is still not up to standard, a low-level interrupt instruction is forcibly triggered to terminate the current iteration and an alarm log is output to the system.
[0040] Through the aforementioned coverage-driven constraint random generation and iteration, a closed-loop feedback loop for automatic test state convergence was established. By leveraging exposed test gaps to guide the generation direction of subsequent test cases, the computational overhead of manually writing massive boundary test cases was reduced. Simultaneously, combined with interrupt interception to prevent infinite loops, the scale of invalid test data generation and bus bandwidth usage were reduced, ensuring efficient traversal of chip functional boundaries.
[0041] In one embodiment of the present invention, step S110, configuring the layered verification IP according to the specifications of the audio chip under test, includes: Configure the audio sampling rate, transmission bit width, and random test case generation parameters in the excitation layer.
[0042] Configure the multiplexing transmission logic for control frames and data frames, as well as the master-slave device operating mode, at the protocol layer.
[0043] Configure the bus clock frequency, single-sided and double-sided sampling modes, and signal timing parameters in the timing layer.
[0044] Monitoring nodes for passively verifying bus signals are mounted on the monitoring layer.
[0045] During the initialization phase of the hierarchical verification IP, after obtaining the specifications of the audio chip under test, parameters are first sent to the excitation layer through the top-level configuration interface. The extracted specification identifiers are mapped to specific audio sampling rates and transmission bit widths, which are then used as boundary constraints for generating random data sources. Simultaneously, weight thresholds for the control flow are written into the random test case generation parameters. In one example, the specific parameters configured by the verification device may include an audio sampling rate of 48kHz, 96kHz, or 192kHz, a transmission bit width of 16bit, 24bit, or 32bit, and a read / write transmission ratio ranging from 1:10 to 10:1. Furthermore, the verification device also supports configuring out-of-order transmission weights and idle period insertion ratios to the excitation layer to control the coverage of the test case generation engine for regular communication and extreme boundary scenarios.
[0046] After completing the data generation constraints of the excitation layer, the underlying interaction rules of the protocol layer are further assigned state values. By rewriting the internal state machine register, the time-division multiplexing transmission logic of the control frame and data frame on a single data line is configured to ensure half-duplex bidirectional interaction between control signaling and audio load. In one example, the verification device also switches the master-slave device working mode based on the attributes of the object under test. Since the audio chip under test is usually a codec peripheral node, the protocol layer is configured by default as the master device mode to simulate the system-on-a-chip host to drive and control it; when it is necessary to verify special topologies of multi-level cascading or direct communication interaction between slave devices, the protocol layer can also be partially switched to slave device mode. Furthermore, the verification device supports configuring a bus topology logic of single master to multiple slave devices in the protocol layer, mounting 2 to 8 audio chips under test or virtual slave device nodes on a single virtual bus, and assigning them mutually independent device numbers to verify the bus arbitration mechanism and the reliability of concurrent transmission of multiple audio streams.
[0047] Simultaneously, the verification device writes a division coefficient to the internal clock generation unit to determine the bus clock frequency, and selects either single data rate sampling triggered by the rising edge of the clock or double data rate sampling mode triggered by both the rising and falling edges, according to the hardware specifications. In one example, the verification device supports dynamically adjusting the bus clock frequency within the range of 1MHz to 12.288MHz, configuring single-edge (SDR) or double-edge (DDR) sampling, and synchronously injecting offset variables for signal setup and hold times to reproduce timing deviations or clock jitter physical scenarios under different printed circuit board (PCB) trace lengths.
[0048] Based on the above active drive link configuration, the verification device connects the monitoring node to the physical bus signal line output by the timing layer through a probe binding mechanism. Specifically, the monitoring node binds to the UVM virtual interface and uses a clock event triggering mechanism for non-intrusive sampling, bypassing the acquisition of the bus waveform data without changing the original digital logic drive state of the bus, thereby constructing a protocol consistency verification channel independent of the signal transmission link.
[0049] Through the above four-layer decoupling configuration method, the downlink mapping of abstract test cases to underlying physical electrical characteristics is realized. Utilizing a parameterized dynamic configuration method, not only is flexible switching of operating modes and timing constraints under different system network architectures satisfied, but also lossless bypass acquisition of bus data is ensured by mounting passive monitoring nodes, improving the verification platform's adaptability to differentiated audio chip specifications and complex wiring timing deviations.
[0050] Reference Figure 2As shown, in one embodiment of the present invention, step S120, which involves acquiring the audio feedback data returned by the audio chip under test and performing an end-to-end closed-loop comparison of the audio feedback data to obtain a functional comparison result, includes: S210. The test stimulus containing the control frame is sent through the bidirectional communication connection to instruct the audio chip under test to complete the register configuration.
[0051] For example, a control frame with a 16-bit address space is sent via a bidirectional communication connection. This control frame directly carries the underlying initialization signaling, eliminating the physical resource overhead of an external I2C configuration bus. The verification device performs actions such as single register read / write, batch configuration, or default value reset verification, and determines that the register configuration is complete after receiving a response message from the underlying chip.
[0052] S220. Input a standard audio source signal to the audio chip under test.
[0053] In response to the register configuration completion status, a digital signal generator is invoked to generate and distribute the standard audio source signal. In one example, the audio source signal is specifically a standard sine wave, white noise, or a real speech sequence with known envelope characteristics.
[0054] S230. Obtain the audio feedback data returned by the audio chip under test after processing the standard audio source signal through its internal functional path.
[0055] By constructing an external physical loopback link between the analog output pins and analog input pins of the audio chip under test (DT), or by configuring the chip's internal digital audio loopback register via a control frame, the audio source signal flows through the internal digital-to-analog converter (DAC), gain adjustment, and analog-to-digital converter (ADC) functional paths of the DT at the receiving end. After the aforementioned physical and logical transformations, the chip repackages the processing result into a frame format and transmits it back based on the return time slot. The verification device extracts the data frame payload at the side end, thereby obtaining the discrete audio feedback data.
[0056] S240. Based on the sampling point comparison strategy and the spectrum feature comparison strategy, the audio feedback data is compared with the expected audio data generated according to the current audio configuration to obtain the audio path error index, and the function comparison result is generated according to the audio path error index.
[0057] The verification device performs a reference transformation on the standard audio source signal based on the currently configured parameters such as gain, sampling rate, and channel mode to generate desired audio data. Subsequently, the verification device determines the time offset based on the preset processing delay or correlation characteristics between the desired audio data and the audio feedback data, and performs timing alignment on the audio feedback data based on the time offset. After timing alignment, the sampling point comparison strategy is executed to calculate the absolute amplitude error between the desired audio data and the audio feedback data in the discrete sampling point sequence in the time domain, obtaining a time domain error parameter. Simultaneously, the spectral feature comparison strategy is executed, extracting and comparing the frequency domain energy distribution differences between the two via Fast Fourier Transform to obtain a frequency domain error parameter. Then, the time domain error parameter and the frequency domain error parameter are normalized respectively, and weighted summed according to preset weights to calculate the audio path error index. The audio path error index is compared numerically with a preset tolerance threshold. If the audio path error index is less than or equal to the tolerance threshold, a functional comparison result representing a normal functional path state is generated.
[0058] By using the aforementioned inline control and multi-dimensional data closed-loop comparison, not only is the physical topology overhead of external control pins eliminated, but also the nonlinear distortion in the core audio path is quantified based on deep feature mapping in the time-frequency dual domain, thereby improving the detection and recall rate of chip functional defects.
[0059] Reference Figure 3 As shown, in one embodiment of the present invention, in step S150, before calculating the verification coverage data, the method further includes: S310. Obtain the complete set of parameter combinations of the audio chip under test in terms of sampling rate, transmission bit width, gain level, and channel mode.
[0060] For example, the verification device extracts the hardware boundary constraints of the audio chip under test and performs cross-calculation on the sampling rate, transmission bit width, gain, and channel mode using a Cartesian product algorithm. In one example, the sequence of dimensional variables included in the full parameter combination set may specifically include: full sampling rate levels of 8kHz, 16kHz, 44.1kHz, 48kHz, 96kHz, and 192kHz; full transmission bit width levels of 16bit, 24bit, and 32bit; full gain levels in the range of -60dB to +12dB; and combinations of channel modes such as mono, stereo, or multi-channel. This full parameter combination set is initialized in the form of a prefix tree or a multidimensional array mapping table and resides in the memory space of the verification device to support efficient querying and status addressing in subsequent testing processes.
[0061] S320. For any set of parameters traversed, drive the hierarchical verification IP and the audio chip under test to perform audio transmission test, and monitor the audio transmission continuity status when the parameter combination is switched.
[0062] For example, the verification device invokes a state machine to traverse parameter nodes, dynamically rewriting the configuration registers of the hierarchical verification IP within the node transition cycle to drive it to continuously interact with the audio data stream. A bypass sliding time window is simultaneously opened to calculate the timestamp interval and waveform phase offset between adjacent data blocks. If the interval is greater than a delay threshold or the offset exceeds the envelope range, the continuity state is determined to be either stream interruption or waveform distortion.
[0063] S330. Generate performance verification results based on the continuous state and supplement them to the functional comparison results.
[0064] After the global traversal test is completed, the waveform distortion timestamps and corresponding parameter transition paths are encapsulated into a performance verification result log. Subsequently, key feature vectors are extracted and concatenated into the previously output functional comparison results to construct a comprehensive data map that integrates static distortion and dynamic switching stability.
[0065] Through the above-mentioned multi-dimensional traversal and time-series jump dynamic monitoring mechanism, the underlying frame loss or buffer underflow phenomenon of audio stream at the moment of parameter reconstruction is captured, realizing the data fusion of dynamic performance indicators and static path indicators, and improving the defect interception rate in complex boundary switching scenarios.
[0066] In one embodiment of the present invention, injecting the target anomalous feature into the audio chip under test via the hierarchical verification IP includes at least one of the following: The protocol layer generates and sends out a first abnormal stimulus containing protocol transmission abnormality features, which include at least one of frame loss, data bit flipping, and bus burst preemption.
[0067] The timing layer injects timing offsets or clock jitter into the bus signals.
[0068] The activation layer generates and sends a second abnormal activation containing logical state abnormality features, which include at least one of parameter out-of-bounds, illegal configuration, and abnormal wake-up.
[0069] For fault tolerance verification at the protocol transmission layer, the verification device rewrites its internal protocol state machine to dynamically mix the aforementioned first anomaly stimulus as a fault vector into the normal transmission link. Specifically, during the frame encapsulation stage, the protocol layer forcibly modifies the payload of a specific time slot through mask mapping or XOR operations to trigger data bit flipping, or constructs a frame loss state by deliberately blocking the transmission sequence of frame synchronization identifiers. Alternatively, it forcibly pulls the data line level low during the master device's data transmission intervals to simulate bus burst preemption.
[0070] For fault tolerance verification of the physical layer electrical timing dimension, the verification device dynamically adjusts the phase delay between the bus clock signal and the data signal to generate the timing offset by rewriting the output driver configuration of the timing layer, or superimposes high-frequency phase jitter on the bus clock output to generate the clock jitter, thus reproducing the timing deterioration caused by board-level PCB trace deviation or power supply ripple interference.
[0071] For boundary verification of business logic states, the boundary space constraints of pseudo-random variables are removed. Parameter values exceeding the hardware addressing range are written to the register address of the audio chip under test to create a parameter out-of-bounds error, or control words with logical mutual exclusion properties are sent in parallel to construct an illegal configuration. In one example, when the verification device detects that the audio chip under test is in a sleep state, it deliberately constructs and sends a spurious pulse sequence that does not conform to the SoundWire wake-up handshake protocol, thereby injecting abnormal wake-up characteristics. The verification device continuously captures and records the interception or reset response data of the underlying hardware of the audio chip under test to the above-mentioned logical anomalies.
[0072] By using the bidirectional exception injection method that decouples the protocol layer, timing layer, and excitation layer, a full-stack fault state traversal is achieved, from the underlying physical transmission of electrical parameters to the logical disorder of the higher-level registers.
[0073] In one embodiment of the present invention, step S140, which involves issuing a low-power mode switching command and obtaining corresponding fault-tolerant feedback data and low-power timing data, includes: The audio chip under test is sequentially issued mode switching commands to instruct it to switch between normal operation, shallow sleep, deep sleep and event-triggered wake-up modes.
[0074] During mode switching, monitor the pause and resume status of the bus clock.
[0075] Obtain the sleep register hold value and wake-up response time of the audio chip under test.
[0076] The low-power timing data is generated based on the sleep register hold value, wake-up response time, pause state, and resume state.
[0077] When the low-power test logic is triggered, the verification device rewrites the control frame payload within the hierarchical verification IP to generate a mode switching instruction carrying a specific opcode. Following a preset low-power state machine topology, clock stop preparation frames are sequentially sent to the audio chip under test (DT). Upon detecting a ready signal from the DT via its status register, a clock stop execution frame is sent, and the bus clock is suspended. This drives the DT to transition between a normal operating state at full power, a shallow sleep state maintaining register context logic, a deep sleep state with the core power domain cut off, and an event-triggered wake-up mode based on in-band interrupt signaling.
[0078] In response to the issuance of the mode switching command, the verification device detects the level transition edge on the physical link of the bidirectional communication connection in real time; when the logic branch determines that no level transition is detected for N consecutive preset clock cycles, it records the current timestamp and marks it as the paused state; when it detects that the physical link re-outputs the synchronization word to establish a communication handshake, it records the corresponding timestamp and marks it as the resumed state.
[0079] After the audio chip under test is woken up from a low-power state and the bidirectional communication connection is detected to have resumed communication, a register read operation is initiated to the preset address space through the bidirectional communication connection to obtain a snapshot of the target register data after wake-up, which is used as the value held by the sleep register. Simultaneously, the absolute difference between the timestamp of sending the event wake-up command and the timestamp of the audio chip under test successfully returning the first valid control response frame is calculated; or, in a voice wake-up scenario, the in-band interrupt wake-up request signal actively sent by the audio chip under test on the data line is monitored, and the time difference between the issuance of the request signal and the resumption of the bus clock is calculated, quantizing the above difference as the wake-up response time.
[0080] After obtaining the aforementioned discrete register features and clock state nodes, the verification device performs structured aggregation. Further, it performs an XOR comparison between the sleep register hold value and a baseline configuration snapshot before the chip enters sleep mode to verify the integrity of the context saving mechanism; and it compares the wake-up response time with the nanosecond-level tolerance threshold defined by the protocol specification. Finally, the aforementioned timing differences, register feature mapping relationships, and clock state transition paths are encapsulated into a structured data dictionary in JSON or XML format, thereby generating the low-power timing data.
[0081] By employing the low-power testing method based on physical clock monitoring and register context snapshot extraction, timing tracking and logic loop verification of the audio chip during multi-level sleep and wake-up transitions were achieved. This verified the ability to maintain key states before and after deep sleep and exposed potential clock deadlocks or configuration loss defects in the chip's underlying hardware during power domain switching.
[0082] In one embodiment of the present invention, step S130, which involves performing a protocol conformance check on the bus waveform data to obtain a protocol check result, includes: The monitoring layer verifies the frame synchronization characteristics and two-dimensional frame boundary alignment status, address compliance, control field encoding correctness, and the corresponding bus state machine jump logic and timing margin of the bus waveform data.
[0083] If a protocol violation is detected, an error log containing the violation type is generated and the corresponding simulation waveform timestamp is marked.
[0084] The error logs and simulation waveform timestamps are compiled into the protocol verification result.
[0085] For example, the verification device extracts synchronization feature bits through mask comparison, identifies frame synchronization features, frame boundaries, and corresponding data field boundaries based on the bus waveform, and verifies the consistency between the identified frame boundaries and the preset SoundWire two-dimensional frame structure to confirm whether it deviates from the standard communication window; it extracts the addressing field and compares it with a preloaded valid register mapping table to confirm the address compliance; and it performs cyclic redundancy check to confirm the correctness of the control field encoding. Simultaneously, it drives the built-in protocol reference model, comparing the actual state transition path parsed from the waveform with the standard protocol transition diagram to verify the bus state machine transition logic. For the underlying electrical characteristics, it calculates the signal setup and hold times in real time and determines whether they meet the preset minimum timing margin threshold.
[0086] When any of the above checks fails the logical judgment rule, a violation exception handling branch is triggered, generating an error log containing the specific violation type. In one example, the error log is stored in a structured manner using key-value pairs in JSON format. The underlying fields include the violation enumeration type (such as "frame synchronization loss" or "establishment time out of bounds"), the expected standard value, and the error sample value. In response to the violation event, the verification device synchronously extracts the global clock counter value of the current simulation environment and uses it as the timestamp of the simulation waveform, strongly binding it to the error log to lock the absolute time coordinate of the exception occurrence.
[0087] Subsequently, the verification equipment cleans and deduplicates multiple discrete error logs and associated timestamp data from the test cycle, then compiles them into a pre-allocated memory database to form the protocol verification result with time-series characteristics. This compiled data can be exported as a structured report file or sent back to the automated test management module for coverage statistics.
[0088] Through the aforementioned protocol parsing and multi-dimensional feature mapping, in-depth compliance checks are covered, ranging from physical timing margins to logical state transitions. By combining structured error logs with timestamp binding, nanosecond-level backtracking and localization of protocol violation waveforms are achieved, reducing the computational time complexity of troubleshooting defects in complex bus communication.
[0089] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.
[0090] Reference Figure 5 This illustration shows an audio chip verification device 500 based on a hierarchical verification IP according to an embodiment of this application, which specifically includes the following modules: The environment configuration module 501 is used to configure a hierarchical verification IP according to the specifications of the audio chip under test and establish a bidirectional communication connection with the audio chip under test; the hierarchical verification IP includes an excitation layer, a protocol layer, a timing layer and a monitoring layer that are decoupled from top to bottom.
[0091] The functional closed-loop test module 502 is used to generate test stimuli through the stimulus layer and send them to the audio chip under test via the protocol layer and the timing layer, obtain the audio feedback data returned by the audio chip under test, and perform end-to-end closed-loop comparison on the audio feedback data to obtain the functional comparison result.
[0092] The protocol verification module 503 is used to collect bus waveform data on the bidirectional communication connection through the monitoring layer, and perform protocol consistency verification on the bus waveform data to obtain the protocol verification result.
[0093] The anomaly and power injection module 504 is used to inject target anomaly features into the audio chip under test via the hierarchical verification IP, issue a low-power mode switching command, and obtain corresponding anomaly fault tolerance feedback data and low-power timing data.
[0094] The coverage report module 505 is used to calculate the verification coverage data and generate a verification report based on the functional comparison results, protocol verification results, anomaly fault tolerance feedback data and low power timing data.
[0095] In one embodiment of the present invention, the method further includes a closed-loop iterative verification module, the closed-loop iterative verification module comprising: The supplementary test case generation submodule is used to generate constrained random supplementary test cases based on the verification coverage data when the verification coverage data does not reach the preset target.
[0096] The iterative verification triggering submodule is used to trigger the hierarchical verification IP to perform iterative verification based on the supplementary test cases until the verification coverage data meets the standard.
[0097] In one embodiment of the present invention, the environment configuration module 501 includes: The excitation layer parameter configuration submodule is used to configure the audio sampling rate, transmission bit width, and random test case generation parameters in the excitation layer.
[0098] The protocol layer logic configuration submodule is used to configure the multiplexing transmission logic of control frames and data frames, as well as the master-slave device operating mode, at the protocol layer.
[0099] The timing layer signal configuration submodule is used to configure the bus clock frequency, single-sided and double-sided edge sampling mode, and signal timing parameters in the timing layer.
[0100] The monitoring layer node mounting submodule is used to mount monitoring nodes for passively verifying bus signals on the monitoring layer.
[0101] In one embodiment of the present invention, the functional closed-loop test module 502 includes: The register configuration instruction submodule is used to send the test stimulus containing control frames through the bidirectional communication connection to instruct the audio chip under test to complete the register configuration.
[0102] The audio source signal input submodule is used to input a standard audio source signal to the audio chip under test.
[0103] The feedback data acquisition submodule is used to acquire the audio feedback data returned by the audio chip under test after the standard audio source signal has been processed by the internal functional path.
[0104] The dual-domain feature verification submodule is used to compare the audio feedback data with the expected audio data generated according to the current audio configuration based on the sampling point comparison strategy and the spectral feature comparison strategy, to obtain the audio path error index, and to generate the function comparison result based on the audio path error index.
[0105] In one embodiment of the present invention, the apparatus further includes a dynamic performance testing module, the dynamic performance testing module comprising: The full parameter set acquisition submodule is used to acquire the full parameter combination set of the audio chip under test in terms of sampling rate, transmission bit width, gain level and channel mode.
[0106] The parameter traversal and monitoring submodule is used to drive the hierarchical verification IP and the audio chip under test to perform audio transmission tests for any set of parameters traversed, and to monitor the continuity of audio transmission when the parameter combination is switched.
[0107] The performance result supplementation submodule is used to generate performance verification results based on the continuous state and supplement them to the functional comparison results.
[0108] In one embodiment of the present invention, the anomaly and power injection module 504 includes: The protocol layer anomaly injection submodule is used to generate and send out a first anomaly stimulus containing protocol transmission anomaly characteristics through the protocol layer. The protocol transmission anomaly characteristics include at least one of frame loss, data bit flipping, timing offset, and bus burst preemption.
[0109] The timing layer anomaly injection submodule is used to inject clock jitter or timing offset into the bus signal through the timing layer.
[0110] The excitation layer exception injection submodule is used to generate and send out a second exception excitation containing logical state exception features through the excitation layer. The logical state exception features include at least one of parameter out of bounds, illegal configuration, and exception wake-up.
[0111] In one embodiment of the present invention, the anomaly and power injection module further includes: The mode switching traversal submodule is used to sequentially send mode switching instructions to the audio chip under test to instruct it to switch between normal operation, shallow sleep, deep sleep and event-triggered wake-up modes.
[0112] The clock start / stop monitoring submodule is used to monitor the pause and resume status of the bus clock during mode switching.
[0113] The response parameter reading submodule is used to obtain the sleep register hold value and wake-up response time of the audio chip under test.
[0114] The timing data aggregation submodule is used to generate the low-power timing data based on the sleep register hold value, wake-up response time, pause state, and resume state.
[0115] In one embodiment of the present invention, the protocol verification module includes: The multi-dimensional rule verification submodule is used to verify the frame synchronization characteristics and two-dimensional frame boundary alignment status, address compliance, control field encoding correctness, and corresponding bus state machine jump logic and timing margin of the bus waveform data through the monitoring layer.
[0116] The error log tagging submodule is used to generate an error log containing the violation type and tag the corresponding simulation waveform timestamp when a protocol violation is detected. The verification result assembly submodule is used to assemble the error log and simulation waveform timestamp into the protocol verification result.
[0117] Reference Figure 6 The illustration shows a computer electronic device for implementing an audio chip verification method based on hierarchical verification IP according to the present invention, which may specifically include the following: The aforementioned computer electronic device 1 is manifested in the form of a general-purpose computing device. The components of the computer electronic device 1 may include, but are not limited to: one or more processors or processing units 3, memory 8, and a bus 4 connecting different system components (including memory 8 and processing unit 3).
[0118] Bus 4 represents one or more of several bus architectures, including memory buses or memory controllers, peripheral buses, graphics acceleration ports, processors, or local buses using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Audio / Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.
[0119] Computer electronic device 1 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computer electronic device 1, including volatile and non-volatile media, removable and non-removable media.
[0120] Memory 8 may include computer system readable media in the form of volatile memory, such as random access memory 9 and / or cache memory 10. Computer electronic device 1 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 11 may be used to read and write non-removable, non-volatile magnetic media (commonly referred to as a "hard disk drive"). Although Figure 6 As not shown, a disk drive for reading and writing to a removable non-volatile disk (such as a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 4 via one or more data media interfaces. The memory may include at least one program product having a set (e.g., at least one) of program modules 13 configured to perform the functions of the embodiments of this application.
[0121] A program / utility 12 having a set (at least one) of program modules 13 may be stored, for example, in memory. Such program modules 13 include—but are not limited to—an operating system, one or more application programs, other program modules 13, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 13 typically perform the functions and / or methods described in the embodiments of this application.
[0122] The computer electronic device 1 can also communicate with one or more external devices 2 (e.g., keyboard, pointing device, display 7, camera, etc.), and with one or more devices that enable an operator to interact with the computer electronic device 1, and / or with any device that enables the computer electronic device 1 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through the I / O interface 6. Furthermore, the computer electronic device 1 can also communicate with one or more networks (e.g., local area network (LAN)), wide area network (WAN), and / or public networks (e.g., the Internet) through the network adapter 5. Figure 6 As shown, network adapter 5 communicates with other modules of computer electronic device 1 via bus 4. It should be understood that, although... Figure 6 Not shown, it may be combined with other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processing unit 3, external disk drive array, RAID system, tape drive and data backup storage system 11, etc.
[0123] Processing unit 3 executes various functional applications and data processing by running programs stored in memory 8, such as implementing a Sound based on a hierarchical verification IP provided in the embodiments of this application. Verification method for Wire protocol audio chips.
[0124] In this application embodiment, the application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements an audio chip verification method based on hierarchical verification IP as provided in all embodiments of the application.
[0125] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.
[0126] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.
[0127] Computer program code for performing the operations of this application can be written in one or more programming languages or a combination thereof. These programming languages include object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as C or similar languages. The program code can be executed entirely on the operator's computer, partially on the operator's computer, as a standalone software package, partially on the operator's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the operator's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider). The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably.
[0128] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.
[0129] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.
[0130] The above provides a detailed description of an audio chip verification method and related apparatus based on hierarchical verification IP provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. An audio chip verification method based on hierarchical verification IP, characterized in that, Applied to a verification device, the method includes: Configure a hierarchical verification IP according to the specifications of the audio chip under test, and establish a bidirectional communication connection with the audio chip under test; the hierarchical verification IP includes an excitation layer, a protocol layer, a timing layer and a monitoring layer that are decoupled from top to bottom; Test stimuli are generated through the stimulus layer and sent to the audio chip under test via the protocol layer and the timing layer. Audio feedback data returned by the audio chip under test is obtained, and end-to-end closed-loop comparison is performed on the audio feedback data to obtain the functional comparison result. The monitoring layer collects bus waveform data on the bidirectional communication connection, and performs a protocol consistency check on the bus waveform data to obtain the protocol check result. The target abnormal features are injected into the audio chip under test via the hierarchical verification IP, and / or a low-power mode switching command is issued to obtain the corresponding abnormal fault tolerance feedback data and / or low-power timing data. Based on the functional comparison results, protocol verification results, anomaly tolerance feedback data and / or low-power timing data, calculate the verification coverage data and generate a verification report. The step of acquiring the audio feedback data returned by the audio chip under test, and performing an end-to-end closed-loop comparison of the audio feedback data to obtain the functional comparison result includes: The test stimulus, which includes control frames, is sent via the bidirectional communication connection to instruct the audio chip under test to complete register configuration. Input a standard audio source signal to the audio chip under test; The audio feedback data transmitted back by the audio chip under test after processing the standard audio source signal through its internal functional pathway is obtained. Based on the sampling point comparison strategy and the spectrum feature comparison strategy, the audio feedback data is compared with the expected audio data generated according to the current audio configuration to obtain the audio path error index, and the function comparison result is generated based on the audio path error index.
2. The method according to claim 1, characterized in that, After calculating and verifying the coverage data, the method further includes: If the verification coverage data does not reach the preset target, then random supplementary test cases are generated based on the verification coverage data. The hierarchical verification IP is triggered to perform iterative verification based on the supplementary test cases until the verification coverage data meets the standard.
3. The method according to claim 1, characterized in that, The configuration of the layered verification IP according to the specifications of the audio chip under test includes: Configure the audio sampling rate, transmission bit width, and random test case generation parameters in the excitation layer; Configure the multiplexing transmission logic for control frames and data frames, as well as the master-slave device operating mode, at the protocol layer; Configure the bus clock frequency, single-sided and double-sided edge sampling modes, and signal timing parameters in the timing layer; Monitoring nodes for passively verifying bus signals are mounted on the monitoring layer.
4. The method according to claim 1, characterized in that, Before calculating the verification coverage data, the method further includes: Obtain the complete set of parameter combinations of the audio chip under test in terms of sampling rate, transmission bit width, gain level, and channel mode. For any set of parameters encountered, the hierarchical verification IP is driven to perform audio transmission tests with the audio chip under test, and the continuity of audio transmission is monitored when the parameter combination is switched. Performance verification results are generated based on the continuous state and then added to the functional comparison results.
5. The method according to claim 1, characterized in that, The injection of target anomalous features into the audio chip under test via the hierarchical verification IP includes at least one of the following: The protocol layer generates and sends a first abnormal stimulus containing protocol transmission abnormal characteristics, which include at least one of frame loss, data bit flipping, and bus burst preemption. The timing layer injects timing offsets or clock jitter into the bus signals. The activation layer generates and sends a second abnormal activation containing logical state abnormality features, which include at least one of parameter out-of-bounds, illegal configuration, and abnormal wake-up.
6. The method according to claim 1, characterized in that, The process of issuing a low-power mode switching command and obtaining corresponding fault-tolerant feedback data and low-power timing data includes: Mode switching commands are sequentially sent to the audio chip under test to instruct it to switch between normal operation, shallow sleep, deep sleep and event-triggered wake-up modes; During mode switching, monitor the pause and resume status of the bus clock; Obtain the sleep register hold value and wake-up response time of the audio chip under test; The low-power timing data is generated based on the sleep register hold value, wake-up response time, pause state, and resume state.
7. The method according to claim 1, characterized in that, The process of performing a protocol conformance check on the bus waveform data to obtain the protocol check result includes: The monitoring layer verifies the frame synchronization characteristics and two-dimensional frame boundary alignment status, address compliance, control field encoding correctness, and corresponding bus state machine transition logic and timing margin of the bus waveform data. If a protocol violation is detected, an error log containing the violation type is generated and the corresponding simulation waveform timestamp is marked. The error logs and simulation waveform timestamps are compiled into the protocol verification result.
8. An audio chip verification device based on hierarchical verification IP, characterized in that, include: The environment configuration module is used to configure a hierarchical verification IP according to the specifications of the audio chip under test and establish a bidirectional communication connection with the audio chip under test; the hierarchical verification IP includes an excitation layer, a protocol layer, a timing layer and a monitoring layer that are decoupled from top to bottom; The functional closed-loop test module is used to generate test stimuli through the stimulus layer and send them to the audio chip under test via the protocol layer and the timing layer, obtain the audio feedback data returned by the audio chip under test, and perform end-to-end closed-loop comparison on the audio feedback data to obtain the functional comparison result. The protocol verification module is used to collect bus waveform data on the bidirectional communication connection through the monitoring layer, and perform protocol consistency verification on the bus waveform data to obtain the protocol verification result. The anomaly and power injection module is used to inject target anomaly features into the audio chip under test via the hierarchical verification IP, and / or issue low power mode switching instructions, and obtain corresponding anomaly fault tolerance feedback data and / or low power timing data. The coverage report module is used to calculate the verification coverage data and generate a verification report based on the functional comparison results, protocol verification results, anomaly fault tolerance feedback data and / or low power timing data. The functional closed-loop test module includes: The register configuration instruction submodule is used to send the test stimulus containing control frames through the bidirectional communication connection to instruct the audio chip under test to complete the register configuration; An audio source signal input submodule is used to input a standard audio source signal to the audio chip under test; The feedback data acquisition submodule is used to acquire the audio feedback data returned by the audio chip under test after the standard audio source signal has been processed by the internal functional path; The dual-domain feature verification submodule is used to compare the audio feedback data with the expected audio data generated according to the current audio configuration based on the sampling point comparison strategy and the spectral feature comparison strategy, to obtain the audio path error index, and to generate the function comparison result based on the audio path error index.
9. A computer electronic device, characterized in that, The method includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of the audio chip verification method based on hierarchical verification IP as described in any one of claims 1 to 7.
