A method, apparatus, medium, and device for SoC performance verification based on dynamic QoS regulation.

Abstract

This application belongs to the field of integrated circuit design verification technology, specifically disclosing a SoC performance verification method, apparatus, medium, and device based on dynamic QoS control. The method includes: analyzing the chip architecture to obtain a chip resource mapping table; constructing an automated verification environment based on the chip resource mapping table and performing testing; configuring scenario parameters according to the target application scenario and based on the chip resource mapping table; and performing dynamic QoS control based on the configured scenario parameters in the tested automated verification environment to achieve SoC performance verification. This application can improve the accuracy, efficiency, and consistency of SoC performance verification results with actual application scenarios.

Description

Technical Field

[0001] This application belongs to the field of integrated circuit design verification technology, specifically relating to a SoC performance verification method, apparatus, medium, and device based on dynamic QoS control. Background Technology

[0002] Current performance verification of SoCs (System-on-a-Chip) typically focuses on testing under extreme stress scenarios, and usually employs a fixed QoS policy to configure the entire data transmission path during the verification process. This method ultimately outputs a set of optimal performance data under a specific static configuration, and this result is often used as the theoretical performance ceiling of the chip. However, such verification methods lack a systematic and standardized methodology for dynamic QoS scenario performance verification, making it difficult to truly reflect the dynamics and diversity of resource scheduling in real-world applications. This leads to a significant deviation between the verification results and the chip's actual performance in real-world scenarios. Summary of the Invention

[0003] To address the shortcomings of existing technologies, the purpose of this application is to provide a SoC performance verification method, apparatus, medium, and device based on dynamic QoS control. This application aims to improve the accuracy, efficiency, and consistency of SoC performance verification results with actual application scenarios.

[0004] To achieve the above objectives, this application provides the following technical solution:

[0005] A method for SoC performance verification based on dynamic QoS control includes: parsing the chip architecture to obtain a chip resource mapping table; constructing an automated verification environment based on the chip resource mapping table and performing tests; configuring scenario parameters according to the target application scenario and based on the chip resource mapping table; and performing dynamic QoS control based on the configured scenario parameters in the tested automated verification environment to achieve SoC performance verification.

[0006] Optionally, the step of parsing the chip architecture and obtaining the chip resource mapping table includes: using an automated script to parse the SoC design file to extract key component information; and integrating the key component information to generate a structured chip resource mapping table.

[0007] Optionally, the step of constructing an automated verification environment based on the chip resource mapping table and testing the verification environment includes: constructing a script engine; constructing an automated verification environment based on the constructed script engine; and testing the automated verification environment.

[0008] Optionally, configuring scenario parameters based on the target application scenario and the chip resource mapping table includes: selecting scenario-participating components from the chip resource mapping table according to the target application scenario; setting expected performance values ​​for the selected scenario-participating components; defining the rules and boundaries for each component in the dynamic control process; and setting environmental operating parameters.

[0009] Optionally, the step of performing performance verification on the SoC based on configured scenario parameters in a pre-tested automated verification environment includes: loading scenario configuration and generating a dynamic QoS test sequence; and performing dynamic QoS control based on the dynamic QoS test sequence.

[0010] Optionally, the step of performing dynamic QoS control based on the dynamic QoS test sequence to achieve SoC performance verification includes: collecting measured bandwidth and latency data of the components involved in the scenario; comparing the measured bandwidth and latency data with the expected performance values ​​and calculating the degree of performance deviation; and adjusting the QoS priority based on the comparison results through dynamic control logic to achieve SoC performance verification.

[0011] Optionally, the step of performing dynamic QoS control based on the dynamic QoS test sequence to achieve SoC performance verification further includes: dynamically controlling QoS using a neural network-based decision model. The decision model includes an input layer, an evaluation layer, a decision layer, and an optimization layer. The input layer is used to input bandwidth deviation rate, latency deviation rate, current QoS value, and application scenario weights. The evaluation layer is used to quantify the current performance state through a reward function, providing an evaluation basis for the decision layer. The decision layer is used to determine whether to adjust QoS and the adjustment range based on the output of the evaluation layer. The optimization layer is used to dynamically adjust the weights of bandwidth and latency in the reward function through adaptive weight updates to adapt to different scenario requirements.

[0012] This application also provides a SoC performance verification device based on dynamic QoS control. The device includes: a parsing module for parsing the chip architecture and obtaining a chip resource mapping table; a construction module for constructing an automated verification environment based on the chip resource mapping table and performing tests; a configuration module for configuring scenario parameters according to the target application scenario and based on the chip resource mapping table; and a control module for performing dynamic QoS control based on the configured scenario parameters in the tested automated verification environment to achieve SoC performance verification.

[0013] This application also provides a storage medium including instructions that, when executed on a computer, cause the computer to perform the method as described in the preceding claim.

[0014] This application also provides an electronic device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in any of the preceding claims.

[0015] Compared with the prior art, the beneficial effects of this application are as follows:

[0016] 1. This application constructs a dynamically configurable verification environment by automatically parsing the chip architecture and generating a resource mapping table, thereby realizing the performance verification of the system-on-a-chip (SoC) based on dynamic quality of service (QoS) in multiple application scenarios;

[0017] 2. By adopting a closed-loop feedback mechanism, this application can monitor the bandwidth and latency data of each master device in real time and dynamically adjust QoS parameters based on performance deviations. This can significantly improve the consistency between verification results and actual chip performance, effectively identify performance bottlenecks and resource conflicts, and generate reusable structured test cases, thereby greatly improving verification efficiency, accuracy and cross-project reusability. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a SoC performance verification method based on dynamic QoS control according to an embodiment of this application;

[0019] Figure 2 This is a schematic diagram of the structure of a decision model provided in another embodiment of this application;

[0020] Figure 3 This is a schematic diagram of a SoC performance verification device based on dynamic QoS regulation, provided in another embodiment of this application. Detailed Implementation

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

[0022] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0023] In this invention, unless otherwise explicitly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0024] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the meaning of "and / or" throughout the text includes three parallel solutions; for example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0025] Figure 1 This is a flowchart illustrating a SoC performance verification method based on dynamic QoS control according to an embodiment of this application. Figure 1 As shown, the method includes the following steps:

[0026] S100: Analyze the chip architecture and obtain the chip resource mapping table;

[0027] S200: Construct an automated verification environment based on the chip resource mapping table and perform testing;

[0028] S300: Configure scenario parameters according to the target application scenario and based on the chip resource mapping table;

[0029] S400: In a well-tested automated verification environment, dynamic QoS control is performed based on configured scenario parameters to achieve SoC performance verification.

[0030] In another exemplary embodiment, step S100, which involves parsing the chip architecture to obtain the chip resource mapping table, includes the following steps:

[0031] S101: Use automated scripts to parse the SoC design files (such as RTL and netlist) to extract key component information;

[0032] In this embodiment, the design files of the SoC are parsed to extract key component information through the following steps:

[0033] First, the SoC's design files (such as RTL and netlist) are loaded using appropriate parsing libraries (e.g., XML / JSON parsers). The file content is read into memory and converted into a nested data structure (e.g., an Abstract Syntax Tree (AST)). This maps the objects or data classes defined within the program that represent hardware entities. Then, the parser traverses this node tree, automatically creating corresponding object instances (e.g., Master, Slave, clock domain, bus, etc.) by recognizing specific parameter tags (e.g., module definitions, port declarations, attribute annotations). The attribute values ​​within the tags (e.g., clock frequency, burst type, read / write capability, etc.) are assigned to the corresponding attributes of the object. This systematically extracts all key component information and ultimately integrates it to generate a structured chip resource mapping table.

[0034] In this step, the key component information includes, for example, all Master components (master devices, such as CPU and GPU) that initiate data requests and their specific parameters, all Slave components (slave devices, such as DDR controller) that receive data requests and their access attributes, the clock domain distribution of each module, operating frequency and voltage level information, and the complete access path topology between Master components and Slave components (e.g., the complete path "GPU → Arbiter Arbit1 → DDR controller").

[0035] S102: Integrate the key component information extracted in step S101 to generate a structured chip resource mapping table.

[0036] In this step, after extracting the key component information, it is necessary to classify and associate the various score information. This process includes: First, grouping all master devices according to the chip's physical or logical subsystem. Then, creating a detailed record for each master, mapping and populating its parsed static parameters (such as name, clock frequency, cache and buffer capacity, read / write attributes) and dynamic performance parameters (such as outstanding read / write channel capabilities, burst type, data size and length), as well as the name of the slave device it ultimately accesses, according to a predefined table structure. This forms a machine-readable, hierarchical, and comprehensive structured data table describing the internal resources and topology of the SoC. This table is output in CSV or JSON format to provide an authoritative data source for subsequent automated verification. The chip resource mapping table is shown in Table 1.

[0037] Table 1 Chip Resource Mapping Table

[0038]

[0039] Note: The parameters in Table 1 are explained below:

[0040] subsystem: The naming of the small chip modules;

[0041] master name: The name of the master component;

[0042] clkfreq: The highest clock frequency used by the master component;

[0043] Bufferable: refers to whether data can be temporarily stored in a buffer during data transmission;

[0044] cacheable: This refers to whether the data can be cached during transmission, which is determined by the master component;

[0045] rw: The read / write property of the master component. rw means readable and writable, ro means read-only, and rw means write-only.

[0046] r_ost: The outstanding capability value of the read channel;

[0047] w_ost: The outstanding capability value of the write channel;

[0048] r_burst: The burst type of the read channel, including fixed, incr, and wrap types;

[0049] w_burst: The burst type for writing channels, including fixed, incr, and wrap types;

[0050] r_size: The size value of the read channel;

[0051] w_size: The size value of the write channel;

[0052] r_len: The length of the read channel (len);

[0053] w_len: The length (len) of the write channel;

[0054] slave name: The name of the slave component.

[0055] In another exemplary embodiment, step S200, which involves constructing an automated verification environment based on the chip resource mapping table and testing the verification environment, includes the following steps:

[0056] S201: Build script engine;

[0057] In this step, building the script engine begins with creating a core program capable of reading and parsing chip resource mapping tables (such as JSON format). This engine, through a built-in template processing mechanism, dynamically generates corresponding verification agent code for each master device identified in the mapping table. Specifically, the engine loads predefined hardware verification language (such as SystemVerilog) code templates and uses specific master device names, bus types, and other key parameters extracted from the resource mapping table, along with keyword substitution (e.g., replacing the template with...).<MASTER_NAME> (Replace with the actual host device name) to automatically generate customized verification component code files and write them to the target directory, thereby quickly and automatically building the basic components of the verification environment that can flexibly adapt to different SoC architectures without the need for manual repetitive code writing.

[0058] For example, the above construction process can be implemented using the following pseudocode:

[0059] # Read the schema mapping JSON file

[0060] set json_data [read_file "soc_arch_map.json"]

[0061] set arch_map [json::json2dict $json_data]

[0062] # Instantiate an incentive generator (Agent) for each Master.

[0063] foreach master $masters_in_map {

[0064] set master_name [dict get $master "name"]

[0065] # Generate the Agent's SystemVerilog code using templates and keyword replacement.

[0066] set agent_template [read_file "templates / master_agent_template.sv"]

[0067] set agent_code [string map [list "<MASTER_NAME> " $master_name] $agent_template]

[0068] # Write the generated code to a file

[0069] write_file "tb / ${master_name}_agent.sv" $agent_code

[0070] puts "Generated verification agent for: $master_name"

[0071] }

[0072] S202: Build an automated verification environment based on the constructed script engine;

[0073] In this step, the construction of the automated verification environment based on the constructed script engine includes the following processes:

[0074] The script engine first reads the structured chip resource mapping table shown in Table 1, and then automatically generates a test environment template conforming to the AMBA protocol (such as AXI). This template includes a stimulus generator and a response receiver. The engine then dynamically connects the stimulus end and the receiver end of the test environment to the AXI interfaces of the corresponding master and slave devices of the DUT according to the access relationship defined in the mapping table (such as Master1 accessing Slave1), completing precise automatic connection. After that, the engine automatically generates and applies stimulus vectors conforming to the protocol specification to the DUT based on the clock frequency, burst type and other parameter information of each master device in the resource table. At the same time, it captures the returned data at the receiver end and embeds performance monitoring logic in key nodes such as the arbiter and memory controller to collect real-time statistics on the bandwidth and latency information of each path. Finally, the engine integrates all statistical results to generate a structured report and automatically displays it, providing users with a clear performance visualization and data analysis interface.

[0075] Furthermore, the constructed automated verification environment includes, for example:

[0076] Bus path model, used to accurately reproduce the physical path from Master to Slave (e.g., adding arbitrator nodes to simulate resource contention).

[0077] The dynamic control interface is used to adjust the service incentive mode of the Master component (such as burst data volume and transmission rate).

[0078] Configure the Slave receiving point to control the location where the Slave receives data through parameters, thereby autonomously adjusting the length of the performance test link to simulate different access latencies;

[0079] An integrated clock controller is used to integrate a configurable clock controller into the environment to support dynamic switching of multiple frequencies at various voltage levels during simulation (e.g., supporting multiple levels such as 0.8GHz / 1.2GHz / 1.5GHz).

[0080] This embodiment utilizes a script engine to automatically generate a configurable verification environment. This verification environment can dynamically control the excitation mode of the master device, the response behavior of the slave device, and the system clock frequency, adapting to new chips without manual coding.

[0081] S203: Test the automated verification environment.

[0082] In this step, the testing of the automated verification environment may include basic connectivity testing, extreme stress testing, and pre-configured limit testing scenarios. Below, this embodiment will provide a detailed description of each test.

[0083] Basic connectivity testing refers to verifying the normal transmission of all data paths from Master to Slave by running basic read and write tests to ensure uninterrupted basic functionality. These basic read and write tests include, for example, basic write and read verification (writing a specific data pattern (e.g., 0xAAAA_AAAA) to a specific address on the Slave, then immediately reading data from the same address to verify that the read value is exactly the same as the written value), address traversal testing (testing the base address, boundary address, and midpoint of the address space of each Slave device to verify the correctness of the address decoding logic and ensure that accesses are not incorrectly crossed or lost), and byte enable testing (for Slaves that support byte-granular writes (such as memory), testing different combinations of byte enable signals. For example, writing only the high 16 bits of a 32-bit data set, then reading the entire 32-bit data set to verify that disabled bytes are not overwritten and that enabled bytes are correct).

[0084] Performing extreme stress tests involves injecting high-load traffic flows at the lowest and highest clock frequencies to detect stability issues such as signal integrity or timing violations in the transmission path. For example, performing a "frequency-load dual-boundary squeeze test." Specifically, the automated script first configures the entire SoC's clock network to the lowest frequency (e.g., 0.8GHz). Under this condition, it continuously injects high-intensity pseudo-random data streams (with packet length and burst type covering the design specifications' limits) into all identified Master→Slave paths. This simulates the extreme scenario of the chip suddenly handling intensive tasks in ultra-low power mode. By utilizing the longer low-frequency clock cycle, it amplifies the time-domain window for integrity issues such as crosstalk and power noise during long-path transmission, making it easier for monitoring tools to capture weak signal glitches. Subsequently, the script instantly switches the clock to the highest frequency (e.g., 1.5GHz) without delay and maintains the same data stream bombardment. This tests the stability of the path under extreme timing conditions: due to the drastically shortened clock cycle, the margins for setup time and hold time become extremely stringent. Any combinational logic delay or clock skew can easily trigger timing violations, and may even induce race conditions and metastability issues that are difficult to model in static timing analysis. Through this creative method of "squeezing" the path back and forth at the boundaries of both frequency and load, the system can efficiently filter out deep-seated stability defects that only manifest under specific combinations of stress and speed, thus providing a solid and reliable underlying environment for subsequent performance verification based on dynamic QoS.

[0085] Pre-configured extreme test scenarios refer to building an extreme performance test environment by locking the clock to the highest frequency and pre-loading high-load services, in preparation for subsequent dynamic verification.

[0086] This embodiment verifies the correctness and stability of the data paths between all master and slave devices by testing the automated verification environment. It ensures that the simulation environment can accurately simulate the behavior of the chip under harsh conditions such as high load and multiple frequency switching, thereby providing a reliable, controllable, and realistically reflective underlying test platform for subsequent performance verification based on dynamic QoS.

[0087] In another exemplary embodiment, step S300, configuring the scenario parameters according to the target application scenario and based on the chip resource mapping table, includes the following steps:

[0088] S301: Select the scenario-participating components from the chip resource mapping table according to the target application scenario;

[0089] This step first requires selecting the key master and slave devices from all components listed in the chip resource mapping table, based on the real-world application scenario to be simulated. For example, for an "8K video recording" scenario, the master devices to be selected include the VPU (Video Processing Unit, responsible for high-quality video encoding and decoding), ISP (Image Signal Processor, responsible for processing image signals), and CPU (responsible for system control and scheduling). The slave devices include the DDR controller (memory).

[0090] S302: Set the expected performance values ​​for the selected components participating in the scenario;

[0091] In this step, a quantified performance expectation value needs to be set for each Master component selected in step S301, which will serve as the benchmark for subsequent dynamic QoS control. For example, a write bandwidth requirement of ≥ 8 GB / s can be set for the VPU, and a memory access latency of ≤ 100 ns can be set for the CPU, thereby providing clear and measurable performance targets for the subsequent dynamic control process.

[0092] S303: Define the rules and boundaries for each component during the dynamic control process;

[0093] In this step, it is necessary to define the control rules and boundaries for each component. For example, set the initial QoS value as the default priority of each Master when the scenario starts (e.g., uniformly initialize it to 5); clarify the adjustable range of QoS to limit the upper and lower limits of the dynamic adjustment of the priority of each Master (e.g., allow VPU to adjust between 1 and 10); and implicitly determine the control sensitivity through the built-in algorithm to decide the specific magnitude and frequency of priority adjustment.

[0094] S304: Set environment operating parameters.

[0095] This step requires configuring global parameters needed for the verification environment to run, such as setting the operating frequency of the SoC in this scenario (e.g., 1.2 GHz). This process may involve selecting the DVFS (Dynamic Voltage Frequency Scaling) level. At the same time, the Master stimulus mode can also be configured to define the business model of a specific Master more finely, such as setting parameters like data burst length and read / write ratio, thereby more realistically simulating its actual behavior in the target application scenario.

[0096] Based on the above steps, a structured scenario specification is ultimately generated, serving as the authoritative input and performance target for the entire dynamic performance verification process. Finally, this structured document is converted into a machine-readable configuration file (such as JSON or YAML format) by an automated script, thereby precisely driving the automatic generation and execution of subsequent test sequences and ensuring that the verification process always revolves around the preset performance goals.

[0097] In another exemplary embodiment, step S400, which involves performing dynamic QoS control based on configured scenario parameters in a well-tested automated verification environment to achieve performance verification of the SoC, includes the following steps:

[0098] S401: Load scenario configuration and generate dynamic QoS test sequences;

[0099] In this step, the scenario specification defines key parameters in a structured data format (such as JSON or YAML), including participating components, expected performance targets for each master device (such as bandwidth and latency thresholds), initial QoS values ​​and adjustable ranges, clock frequency, and excitation mode. An automated configuration parsing script written in a scripting language such as Python or TCL can read the pre-configured scenario specification based on the target application scenario. This script calls a standard JSON or YAML parsing library (such as Python's JSON module or PyYAML), takes the file path as input, and uses the `open()` and `load()` methods to read the pre-configured scenario specification file based on the target application scenario, fully load its contents into memory, and parse it into structured data objects such as dictionaries and lists that can be manipulated by the program. Subsequently, these parameters are parsed and the topology described in the chip resource mapping table is used to automatically generate a dynamic test sequence that can be executed on the simulation platform. This sequence precisely includes a series of instructions such as initializing the environment, driving the master device to send differentiated service flows according to the configuration, embedding performance monitoring logic in key nodes such as the arbitrator and memory controller, and embedding closed-loop control strategies. This transforms the user's high-level verification intent into an executable dynamic QoS verification process that is adapted to specific scenarios.

[0100] S402: Perform dynamic QoS control based on the dynamic QoS test sequence.

[0101] In this step, a monitoring circuit is deployed at key nodes such as the arbiter and the DDR controller entry point. This circuit connects to the path under test through a physical interface to capture the timestamps and data information of transmission events in real time, such as collecting measured data on the bandwidth (BW) and latency of each Master. These two measured data are used as model inputs and compared in real time with the performance expectations set in the scenario specification. During the comparison, if a deviation is found (such as a Master's bandwidth being lower than the target value or latency being lower than the target value, for example, the measured bandwidth of the VPU is 6GB / s < the target of 8GB / s, and the measured latency is 27ns > the target of 24ns), then based on the calculated degree of performance deviation, the bandwidth with the larger deviation from the target is prioritized for QoS adjustment (such as QoS+1) to improve the QoS priority of that Master. The monitoring-decision-adjustment process is executed cyclically through a closed-loop feedback mechanism until the performance of all master devices meets the standard or reaches the preset adjustment threshold, thereby achieving adaptive resource allocation and dynamic optimization.

[0102] For example, in the initial state, assuming that the QoS of both the VPU and GPU is 5, the measured bandwidth of the VPU is 6GB / s (lower than the target 8GB / s) and the latency is 27ns (higher than the target 24ns). The system first detects that there is a deviation in both bandwidth and latency. After calculation, the bandwidth deviation is greater. Therefore, the QoS of the VPU is increased to 6, which increases the bandwidth to 7GB / s and reduces the latency to 26.5ns. Subsequently, the second adjustment still prioritizes the bandwidth deviation and further increases the QoS to 7. At this time, the bandwidth reaches 8.8GB / s (meeting the expectation), but the latency of 26ns is still too high. Finally, the third adjustment fine-tunes the QoS to 6.5, which reduces the bandwidth to 8.1GB / s and the latency to 23.8ns. Both indicators meet the expected targets. In the whole process, the arbitrator and the DDR controller work together to achieve dynamic resource optimization and allocation.

[0103] After the above simulation is completed, the system will automatically compare the measured performance data of all components with the expected target values ​​defined in the scenario specification. If the bandwidth and latency of all components meet the requirements, the scenario is marked as verified and the final optimized dynamic configuration parameters are recorded (e.g., VPU QoS=7, GPU QoS=5). If there are components that do not meet the requirements, the system can intelligently locate the performance bottleneck (e.g., "GPU bandwidth is insufficient due to Arbit1 throughput limitation of arbiter") and provide specific optimization suggestions (e.g., increase the arbiter clock frequency or increase its buffer depth). The system can also adjust the design or configuration parameters based on the diagnostic results and rerun the simulation until the performance fully meets the requirements.

[0104] For scenarios that have passed verification, the system stores their complete configuration parameters—including QoS priority, clock frequency, and service incentive parameters—into the verification database and generates structured, reusable "golden test cases." For example:

[0105] {"Scene": "8K Video Encoding / Decoding", "QoS Configuration": {"VPU": 7, "GPU": 5}, "Clock": "1.2GHz"}

[0106] Such use cases can not only be directly used for performance acceptance testing of mass-produced chips, but can also be ported to other verification environments with the same or similar SoC architectures to improve verification efficiency and project reusability.

[0107] Furthermore, it should be noted that, based on the above-mentioned verification using rule-based algorithms, for certain particularly complex or poorly performing scenarios, this application uses dynamic adjustment logic (e.g., constructing a decision model based on neural networks) to perform in-depth analysis and optimization of the data.

[0108] For example, such as Figure 2 As shown, this neural network-based decision-making model includes an input layer, an evaluation layer, a decision layer, and an optimization layer. The input layer is used to input parameters including bandwidth bias rate. Delay deviation rate Current QoS value Application scenario weight Four features; the evaluation layer is used to quantify the "goodness" or "badness" of the current performance state through a reward function, providing an evaluation basis for the decision layer. The reward function is expressed as follows:

[0109]

[0110] in, This represents the reward value. A negative value indicates poor performance, 0 indicates that the performance meets expectations, and a positive value indicates that the performance is better than expected. This represents the bandwidth weight, with a value range of [0,1]. This represents the delay weight, with a value range of [0,1]. This represents the stability penalty coefficient, with a value range of [0,1].

[0111] In the reward function shown above, the first half... As the core of driver optimization, it is responsible for converting performance deviations into penalty signals; the latter half As a regularization technique, it is used to ensure that the optimization process converges smoothly.

[0112] The decision layer is used to determine whether to adjust QoS and the adjustment amount based on the output of the evaluation layer. For example, when the reward value... Adjustments are triggered when the value falls below a set threshold. The specific adjustment can be made according to the following formula:

[0113]

[0114] in, This represents the learning rate, used to determine the magnitude of each adjustment. The larger the value, the more drastic the QoS changes during each adjustment. The smaller the value, the smoother the QoS changes with each adjustment. This represents the proportion, determining whether bandwidth deviation or latency deviation is dominant in this adjustment. If bandwidth deviation... Large delay bias If the value is very small, close to 1, this adjustment will focus on correcting bandwidth; conversely, if the value is large, it will focus on correcting latency. Indicates the target bandwidth; Indicates the actual bandwidth; when < , An output of 1 indicates that the QoS priority of the master device needs to be increased to allocate more resources to increase bandwidth; conversely, an output of -1 indicates that the QoS priority of the master device needs to be decreased to avoid consuming more resources.

[0115] The optimization layer is used to dynamically adjust the weights of bandwidth and latency in the reward function through adaptive weight updates to adapt to different scenario requirements, as shown below:

[0116]

[0117]

[0118] in, , These represent the weights of bandwidth and latency in the evaluation layer, respectively. This represents the weight learning rate.

[0119] Below, this application uses an 8K video recording scenario as an example to illustrate the above decision-making model:

[0120] Assume the 8K video recording scenario includes the data shown in Table 2:

[0121] Table 2 8K Video Recording Scenarios

[0122]

[0123] In Table 2, the VPU's bandwidth skew rate is 0.25 and latency skew rate is 0.125. The reward can be calculated using the above formula. ,because (For example, the threshold is set to 0), thus triggering an adjustment:

[0124]

[0125] In summary, this application constructs the decision model shown above to dynamically regulate QoS. By calculating the performance deviation reward value in real time and generating adaptive adjustment instructions, it can accurately perceive the system status, intelligently balance bandwidth and latency conflicts, and stably converge to the optimal resource configuration. This helps to improve the accuracy, automation, and consistency with real chip behavior of SoC performance verification in complex application scenarios.

[0126] In another exemplary embodiment, this application also provides a SoC performance verification device based on dynamic QoS regulation, such as... Figure 3 As shown, the device includes: a parsing module 100, used to parse the chip architecture and obtain a chip resource mapping table; a construction module 200, used to build an automated verification environment based on the chip resource mapping table and perform testing; a configuration module 300, used to configure scene parameters according to the target application scenario and based on the chip resource mapping table; and a control module 400, used to perform dynamic QoS control based on the configured scene parameters in the tested automated verification environment to achieve performance verification of the SoC.

[0127] In another exemplary embodiment, this application also provides a storage medium including instructions that, when executed on a computer, cause the computer to perform the method as described in the preceding embodiment.

[0128] In another exemplary embodiment, this application also provides an electronic device, the electronic device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method as described in any of the preceding embodiments.

[0129] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A SoC performance verification method based on dynamic QoS control, characterized in that, The method includes: Analyze the chip architecture and obtain the chip resource mapping table; An automated verification environment is built and tested based on the chip resource mapping table; Configure scenario parameters according to the target application scenario and based on the chip resource mapping table; In a well-tested automated verification environment, dynamic QoS adjustment is performed based on configured scenario parameters to achieve SoC performance verification. The configuration of scenario parameters based on the target application scenario and the chip resource mapping table includes: Components participating in the scenario are selected from the chip resource mapping table according to the target application scenario; Set performance expectations for the selected scenario-participating components; Define the rules and boundaries for each component during the dynamic control process; Configure environment operating parameters; The process of performing performance verification on the SoC based on configured scenario parameters in a pre-tested automated verification environment includes: Load the scenario configuration and generate a dynamic QoS test sequence; Dynamic QoS control is performed based on the dynamic QoS test sequence to verify the performance of the SoC. The step of performing dynamic QoS control based on the dynamic QoS test sequence to verify the performance of the SoC also includes: A neural network-based decision model dynamically adjusts QoS. The model comprises an input layer, an evaluation layer, a decision layer, and an optimization layer. The input layer is used to input bandwidth deviation rate, latency deviation rate, current QoS value, and application scenario weight; The evaluation layer is used to quantify the current performance status through a reward function, providing an evaluation basis for the decision-making layer; The decision-making layer is used to determine whether to adjust QoS and the adjustment amount based on the output of the evaluation layer; The optimization layer is used to dynamically adjust the weights of bandwidth and latency in the reward function through adaptive weight updates to adapt to different scenario requirements.

2. The method according to claim 1, characterized in that, The step of parsing the chip architecture and obtaining the chip resource mapping table includes: Use automated scripts to parse the SoC design files to extract key component information; Integrate key component information to generate a structured chip resource mapping table.

3. The method according to claim 1, characterized in that, The process of constructing an automated verification environment based on the chip resource mapping table and testing the verification environment includes: Build a script engine; An automated verification environment is built based on the constructed script engine; Test the automated verification environment.

4. The method according to claim 1, characterized in that, The step of performing dynamic QoS control based on the dynamic QoS test sequence to verify the performance of the SoC includes: Collect measured bandwidth and latency data of the components involved in the scenario; The measured bandwidth and latency data are compared with the expected performance values, and the degree of performance deviation is calculated. Based on the comparison results, the QoS priority is adjusted through dynamic control logic to achieve SoC performance verification.

5. A SoC performance verification device based on dynamic QoS regulation, characterized in that, The device includes: The parsing module is used to parse the chip architecture and obtain the chip resource mapping table; The module is used to build an automated verification environment and perform tests based on the chip resource mapping table; The configuration module is used to configure scenario parameters according to the target application scenario and based on the chip resource mapping table; The control module is used to perform dynamic QoS control based on configured scenario parameters in a well-tested automated verification environment in order to achieve performance verification of the SoC. The method for configuring scenario parameters based on the target application scenario and the chip resource mapping table includes: Components participating in the scenario are selected from the chip resource mapping table according to the target application scenario; Set performance expectations for the selected scenario-participating components; Define the rules and boundaries for each component during the dynamic control process; Configure environment operating parameters; The method for performing performance verification of the SoC based on configured scenario parameters in a pre-tested automated verification environment includes: Load the scenario configuration and generate a dynamic QoS test sequence; Dynamic QoS control is performed based on the dynamic QoS test sequence to verify the performance of the SoC. The step of performing dynamic QoS control based on the dynamic QoS test sequence to verify the performance of the SoC also includes: A neural network-based decision model dynamically adjusts QoS. The model comprises an input layer, an evaluation layer, a decision layer, and an optimization layer. The input layer is used to input bandwidth deviation rate, latency deviation rate, current QoS value, and application scenario weight; The evaluation layer is used to quantify the current performance status through a reward function, providing an evaluation basis for the decision-making layer; The decision-making layer is used to determine whether to adjust QoS and the adjustment amount based on the output of the evaluation layer; The optimization layer is used to dynamically adjust the weights of bandwidth and latency in the reward function through adaptive weight updates to adapt to different scenario requirements.

6. A storage medium, characterized in that, It includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 4.

7. An electronic device, characterized in that, The electronic device includes: Memory, processor, and computer programs stored in memory and executable on the processor, wherein, When the processor executes the program, it implements the method as described in any one of claims 1 to 4.

Images