SoC performance verification method and device based on dynamic QoS regulation and control, medium and equipment

Abstract

The invention belongs to the technical field of integrated circuit design verification, and particularly discloses an SoC performance verification method and device based on dynamic QoS regulation and control, a medium and equipment, and the method comprises the steps: analyzing a chip architecture, and obtaining a chip resource mapping table; constructing an automatic verification environment based on the chip resource mapping table and performing testing; scene parameter configuration is carried out according to a target application scene and based on the chip resource mapping table; and performing dynamic QoS regulation and control based on the configured scene parameters in a tested automatic verification environment so as to verify the performance of the SoC. According to the invention, the accuracy and efficiency of SoC performance verification and the consistency of the result and the actual application scene can be improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of integrated circuit design verification, and particularly relates to a SoC performance verification method, device, medium and equipment based on dynamic QoS regulation. BACKGROUND

[0002] The current scene performance verification of SoC (system on chip) is generally concentrated on the test of extreme stress scenes, and a fixed QoS strategy is usually used to configure the entire data transmission path during the verification process. The method finally outputs a set of optimal performance data under a specific static configuration, and the result is often used as the theoretical performance upper limit of the chip. However, such verification method lacks a systematic and standardized dynamic QoS scene performance verification methodology, and it is difficult to truly reflect the dynamicity and diversity of resource scheduling in actual application, resulting in significant deviation between the verification result and the actual performance of the chip in real scene. SUMMARY

[0003] In view of the deficiencies in the prior art, the purpose of the present application is to provide a SoC performance verification method, device, medium and equipment based on dynamic QoS regulation, which aims to improve the accuracy, efficiency and consistency of the results of SoC performance verification with actual application scenarios.

[0004] To achieve the above-mentioned purpose, the present application provides the following technical solutions: A SoC performance verification method based on dynamic QoS regulation, the method comprising: analyzing a 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 scene parameters according to a target application scenario and based on the chip resource mapping table; and performing dynamic QoS regulation based on the configured scene parameters in the tested automated verification environment to realize performance verification of the SoC.

[0005] Optionally, the analyzing the chip architecture to obtain the chip resource mapping table comprises: using an automated script to analyze design files of the SoC to extract key component information; and integrating the key component information to generate a structured chip resource mapping table.

[0006] Optionally, the constructing the automated verification environment based on the chip resource mapping table and performing testing on the verification environment comprises: constructing a script engine; constructing the automated verification environment based on the constructed script engine; and testing the automated verification environment.

[0007] Optionally, the scene parameter configuration according to the target application scenario and based on the chip resource mapping table comprises: screening out scene participating components from the chip resource mapping table according to the target application scenario; setting performance expectation values for the screened out scene participating components; defining rules and boundaries of each component in the dynamic regulation process; and setting environment running parameters.

[0008] Optionally, the performance verification of the SoC based on the configured scene parameters in the tested automated verification environment comprises: loading scene configuration and generating a dynamic QoS test sequence; and performing dynamic QoS regulation based on the dynamic QoS test sequence.

[0009] Optionally, the dynamic QoS regulation based on the dynamic QoS test sequence to achieve the performance verification of the SoC comprises: collecting bandwidth and delay measured data of the scene participating components; comparing the bandwidth and delay measured data with the performance expectation values and calculating performance deviation degrees; and based on the comparison results, regulating QoS priorities through dynamic regulation logic to achieve the performance verification of the SoC.

[0010] Optionally, the dynamic QoS regulation based on the dynamic QoS test sequence to achieve the performance verification of the SoC further comprises: dynamic regulation of QoS based on a neural network decision model, the decision model comprising an input layer, an evaluation layer, a decision layer and an optimization layer, wherein the input layer is used for inputting bandwidth deviation rate, delay deviation rate, current QoS value and application scenario weight; the evaluation layer is used for quantifying current performance state through a reward function to provide evaluation basis for the decision layer; the decision layer is used for deciding whether to adjust QoS and adjustment amplitude according to the output of the evaluation layer; and the optimization layer is used for dynamically adjusting weights of bandwidth and delay in the reward function through adaptive weight update to adapt to different scene requirements.

[0011] The application further provides a SoC performance verification device based on dynamic QoS regulation, the device comprising: an analysis module configured to analyze a chip architecture and obtain a chip resource mapping table; a construction module configured to construct an automated verification environment based on the chip resource mapping table and test the automated verification environment; a configuration module configured to configure scene parameters according to a target application scenario and based on the chip resource mapping table; and a regulation module configured to perform dynamic QoS regulation based on the configured scene parameters in the tested automated verification environment to achieve performance verification of the SoC.

[0012] The application further provides a storage medium comprising instructions which, when executed on a computer, cause the computer to perform the method according to any one of the preceding embodiments.

[0013] The 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 implements the method according to any one of the preceding embodiments when executing the program.

[0014] Compared with the prior art, the application has the following beneficial effects: 1. The application automatically analyzes the chip architecture and generates a resource mapping table, constructs a dynamically configurable verification environment, and realizes performance verification of a system-on-chip (SoC) in multiple application scenarios based on dynamic quality of service (QoS); 2. The application adopts a closed-loop feedback mechanism to monitor bandwidth and delay data of each master device in real time, dynamically adjusts QoS parameters according to performance deviation, can significantly improve the consistency of verification results and actual performance of the chip, effectively identifies performance bottlenecks and resource conflicts, simultaneously generates reusable structured test cases, and greatly improves verification efficiency, accuracy and cross-project reusability. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 is a flowchart of a SoC performance verification method based on dynamic QoS regulation provided by an embodiment of the application; Figure 2 is a structural diagram of a decision model provided by another embodiment of the application; Figure 3 is a structural diagram of a SoC performance verification device based on dynamic QoS regulation provided by another embodiment of the application. DETAILED DESCRIPTION

[0016] The technical solutions in the embodiments of the application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative efforts fall within the protection scope of the application.

[0017] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the application are only used to explain the relative positional relationship, movement condition, etc. between components in a certain posture (as shown in the drawings), and if the certain posture changes, the directional indications also change accordingly.

[0018] In the present application, unless otherwise explicitly specified and limited, the terms "connection", "fixing" and the like should be understood in a broad sense, for example, "fixing" can be fixed connection, or detachable connection, or integral; can be mechanical connection, or electrical connection; can be direct connection, or indirect connection through intermediate medium, can be internal connection of two elements or interaction relationship between two elements, unless otherwise explicitly limited. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0019] In addition, if the present application has a description of "first", "second" and the like, the description of "first", "second" and the like is only for the purpose of description, and cannot be understood as indicating or implying the relative importance of the indicated technical features or implicitly indicating the number of indicated technical features. Therefore, the features limited by "first", "second" can explicitly or implicitly include at least one of the features. In addition, the meaning of "and / or" appearing throughout the text includes three parallel schemes. For example, "A and / or B" includes A scheme, or B scheme, or A and B scheme. In addition, the technical solutions of each embodiment can be combined with each other, but it must be based on the realization of ordinary skilled in the art. When the combination of technical solutions appears contradictory or unachievable, it should be considered that the combination of technical solutions does not exist, nor is it within the scope of protection required by the present application.

[0020] Figure 1 is a flowchart of a SoC performance verification method based on dynamic QoS regulation provided by an embodiment of the present application, as shown in Figure 1 The method comprises the following steps: S100: analyzing the chip architecture to obtain a chip resource mapping table; S200: constructing an automated verification environment based on the chip resource mapping table and testing; S300: configuring scene parameters according to a target application scenario and based on the chip resource mapping table; S400: based on the configured scene parameters, performing dynamic QoS regulation in the tested automated verification environment to realize performance verification of the SoC.

[0021] In another exemplary embodiment, in step S100, the chip architecture is analyzed to obtain a chip resource mapping table, comprising the following steps: S101: using an automated script to analyze the design file (such as RTL, netlist) of the SoC to extract key component information; In this step, the design file of the SoC is analyzed to extract key component information by the following steps: First, load the design file (such as RTL, netlist) of the SoC using the corresponding analysis library (such as XML / JSON parser), read the file content into memory and convert it into a nested data structure (such as Abstract Syntax Tree (AST)), which maps the objects or data classes defined in the program internally to represent hardware entities. Then, traverse the node tree through the parser, automatically create corresponding object instances (such as Master, Slave, clock domain, bus, etc.) by identifying specific parameter tags (such as module definition, port declaration, attribute annotation, etc.), and assign attribute values (such as clock frequency, burst type, read / write capability, etc.) in the tags to the corresponding attributes of the object, thereby systematically extracting all key component information and finally integrating to generate a structured chip resource mapping table.

[0022] In this step, the key component information includes, for example: all Master components (such as CPU, GPU) initiating data requests and their specific parameters, all Slave components (such as DDR controller) receiving data requests and their access attributes, clock domain distribution of each module, working frequency and voltage level information, and complete access path topology between Master components and Slave components (such as "GPU → Arbit1 → DDR controller" complete path).

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

[0024] In this step, after completing the extraction of key component information, the various component information needs to be classified and associated. This process includes: first, group all Master components according to the physical or logical subsystems of the chip, then create a detailed record for each Master, parse the static parameters (such as name, clock frequency, cache and buffer capability, read / write attribute) and dynamic performance parameters (such as outstanding capability of read / write channel, burst type, data size and length) obtained, and the final accessed Slave component (Slave) name, and map and fill them according to the pre-defined table structure, thereby forming a structured data table that is machine-readable, hierarchical and fully describes the internal resource and topology relationship of the SoC. The table is output in CSV or JSON format to serve as an authoritative data source for subsequent automated verification. The chip resource mapping table is shown in Table 1: Table 1 Chip Resource Mapping Table

[0025] Note: The parameters in Table 1 are explained as follows: subsystem: name of chip sub-module; master name: the name of the master component; clkfreq: the highest clock frequency used by the master component; bufferable: whether the data can be temporarily stored in a buffer during transmission; cacheable: whether the data can be cached during transmission, determined by the master component; rw: the read-write attribute of the master component, rw for read-write, ro for read-only, and rw for write-only; r_ost: the outstanding capability value of the read channel; w_ost: the outstanding capability value of the write channel; r_burst: the burst type of the read channel, including fixed, incr, and wrap; w_burst: the burst type of the write channel, including fixed, incr, and wrap; r_size: the size value of the read channel; w_size: the size value of the write channel; r_len: the length of the read channel; w_len: the length of the write channel; slave name: the name of the slave component.

[0026] In another exemplary embodiment, in step S200, the automatic verification environment is constructed based on the chip resource mapping table and tested, including the following steps: S201: Constructing a script engine; In this step, the process of constructing the script engine starts with creating a core program that can read and parse the chip resource mapping table (such as in JSON format). The engine dynamically generates the corresponding verification agent (Agent) code for each master (Master) identified in the mapping table through the built-in template processing mechanism. Specifically, the engine loads the pre-defined hardware verification language (such as SystemVerilog) code template, and uses the specific master name, bus type, and other key parameters extracted from the resource mapping table to automatically generate customized verification component code files through keyword replacement (such as replacing <MASTER_NAME> in the template with the actual master name), and writes them to the target directory. This quickly and automatically constructs a verification environment basic component that can flexibly adapt to different SoC architectures without the need for manual repetitive code writing.

[0027] The above build process can be implemented by the following pseudo code, for example: # Read the architecture mapping JSON file set json_data [read_file "soc_arch_map.json"] set arch_map [json::json2dict $json_data] # Instantiate an agent for each master foreach master $masters_in_map { set master_name [dict get $master "name"] # Generate the SystemVerilog code for the agent using template and keyword substitution set agent_template [read_file "templates / master_agent_template.sv"] set agent_code [string map [list "<MASTER_NAME>" $master_name] $agent_template] # Write the generated code to a file write_file "tb / ${master_name}_agent.sv" $agent_code puts "Generated verification agent for: $master_name" } S202: build an automated verification environment based on the constructed script engine; In this step, the automated verification environment based on the constructed script engine includes the following processes: The script engine first reads the structured chip resource mapping table shown in Table 1 and automatically generates a test environment template that complies with AMBA protocols (such as AXI). This template includes a stimulus generator and a response receiver. The engine then dynamically connects the stimulus and response ends of the test environment to the AXI interfaces of the corresponding master and slave devices of the DUT based on the access relationships defined in the mapping table (such as Master1 accessing Slave1), completing precise automatic wiring. The engine then automatically generates and applies protocol-compliant stimulus vectors to the DUT based on parameter information such as the clock frequency and burst type of each master device in the resource table. Simultaneously, the engine captures return data at the receiving end and embeds performance monitoring logic in key nodes such as the arbiter and memory controller to provide real-time statistics on the bandwidth and latency of each path. Finally, the engine integrates all statistical results into a structured report and automatically displays it, providing users with a clear performance visualization and data analysis interface.

[0028] Furthermore, the constructed automated verification environment includes, for example: A bus path model, used to accurately replicate the physical path from Master to Slave (e.g., adding an arbitrator node to simulate resource contention); Dynamic control interface, used to adjust the service incentive mode of the Master component (such as burst data volume and transmission rate); 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 delays; The 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 (for example, supporting multiple levels such as 0.8 GHz, 1.2 GHz, and 1.5 GHz).

[0029] This embodiment automatically generates a configurable verification environment by using a script engine. The verification environment can dynamically control the master device (Master) excitation mode, the slave device (Slave) response behavior and the system clock frequency, and can adapt to new chips without manual coding.

[0030] S203: Testing the automated verification environment.

[0031] In this step, the testing of the automated verification environment may include basic connectivity testing, extreme stress testing, and pre-configured limit testing scenarios. Each test is described in detail below in this embodiment.

[0032] The basic connectivity test refers to verifying all Master-to-Slave data paths can complete normal transmission by running basic read-write tests of the foundation, to ensure that the basic functions are smooth and unblocked. Among them, the read-write tests of the foundation include, for example, basic write and read verification (write a specific data pattern (for example: 0xAAAA_AAAA) to a certain address of the Slave, and then immediately read the data from the same address, verify whether the read value is exactly the same as the written value), address traversal test (test the base address, boundary address and middle point of the address space of each Slave device to verify whether the address decoding logic is correct, and ensure that the access will not be incorrectly crossed or lost), byte enable test (for Slaves that support byte-granularity overwriting, such as memories, test different byte enable signal combinations. For example, only write the high 16 bits of 32-bit data, and then read the entire 32-bit data to verify that the disabled bytes are not overwritten, and the enabled byte data is correct).

[0033] Performing extreme stress testing refers to detecting whether there are signal integrity or timing violation stability problems in the path by injecting high-load traffic flows at the lowest and highest clock frequencies. For example, a "frequency-load double-boundary squeeze test" is performed. Specifically, the automatic script will first configure the entire SoC clock network to the lowest frequency (for example, 0.8 GHz), and continuously inject a high-intensity pseudo-random data stream (its packet length and burst type cover the limit values of the design specification) into all identified Master→Slave paths under this condition, which aims to simulate the extreme scenario of the chip suddenly processing intensive tasks in the ultra-low power mode, and to amplify the time domain window of signal integrity problems such as crosstalk and power noise in long-path transmission by taking advantage of the characteristics of long clock cycles at low frequencies, so that the monitoring tool is more likely to capture weak signal glitches. Subsequently, the script will instantaneously switch the clock to the highest frequency (for example, 1.5 GHz) without delay and maintain the same data stream bombardment, which tests the stability of the path under extreme timing: since the clock period is sharply shortened, the margin of setup time and hold time becomes extremely demanding, and any combination logic delay or clock skew is extremely likely to cause timing violations, and may even trigger race conditions and metastability problems that are difficult to model in static timing analysis. Through this creative method of "squeezing" the path back and forth on the boundary of the two dimensions of frequency and load, the system can efficiently screen out deep-level stability defects that only appear under certain pressure and speed combinations, thereby providing a solid and reliable underlying environment for subsequent dynamic QoS-based performance verification.

[0034] Pre-configured limit test scenario refers to constructing a limit performance test environment by locking the clock to the highest frequency and preloading high-load traffic, preparing for subsequent dynamic verification.

[0035] This embodiment can verify the correctness and stability of data paths between all master-slave devices by testing the automated verification environment, ensure that the simulation environment can accurately simulate the behavior of the chip under actual harsh conditions such as high load and multi-frequency switching, thereby providing a reliable, controllable and real hardware characteristic bottom test platform for subsequent dynamic QoS-based performance verification.

[0036] In another exemplary embodiment, in step S300, the scene parameter configuration according to the target application scenario and based on the chip resource mapping table comprises the following steps: S301: filtering out scene participating components from the chip resource mapping table according to the target application scenario; In this step, first, according to the real application scenario to be simulated, the key master (Master) and slave (Slave) devices participating in the scene are filtered out from all the components listed in the chip resource mapping table. For example, for the "8K video recording" scene, the master (Master) devices to be filtered out include VPU (video processing unit, responsible for high-quality video encoding and decoding processing), ISP (image signal processor, responsible for processing image signals), and CPU (responsible for system control and scheduling). The slave (Slave) devices include: DDR controller (memory).

[0037] S302: setting performance expectation values for the filtered-out scene participating components; In this step, a quantitative performance expectation value is set for each Master component filtered out in step S301, which serves as the evaluation benchmark for subsequent dynamic QoS regulation. For example, the write bandwidth requirement of VPU can be set to ≥ 8 GB / s, and the delay of CPU accessing memory is ≤ 100 ns, thereby providing an explicit and measurable performance target for the subsequent dynamic regulation process.

[0038] S303: defining rules and boundaries of each component in the dynamic regulation process; In this step, the regulation rules and boundaries of each component are defined, for example, setting the initial QoS value as the default priority of each Master at the scene start (for example, uniformly initialized to 5); explicitly defining the QoS adjustable range to limit the upper and lower limits of dynamic adjustment of the priority of each Master (for example, allowing VPU to adjust between 1 and 10); and implicitly determining the regulation sensitivity through built-in algorithms to decide the specific amplitude and frequency of priority adjustment. S304: setting environment running parameters.

[0039] In this step, global parameters required for the verification environment runtime are configured, such as setting the working frequency of the SoC in this scenario (e.g., 1.2 GHz), which may involve selecting the DVFS (Dynamic Voltage and Frequency Scaling) gear; at the same time, the Master stimulation mode can be configured to define the business model of a specific Master more finely, such as setting the data burst length, read-write ratio and other parameters, so as to more realistically simulate its actual behavior in the target application scenario.

[0040] Based on the above steps, a structured scenario specification (Scenario Spec) can be finally obtained, which is used as the authoritative input and performance target of the entire dynamic performance verification. Finally, the structured document is converted into a machine-readable configuration file (such as JSON or YAML format) by an automated script, so as to accurately drive the automatic generation and execution of the subsequent test sequence, and ensure that the verification process is always carried out around the preset performance target.

[0041] In another exemplary embodiment, in step S400, based on the configured scenario parameters, dynamic QoS regulation is performed in the tested automation verification environment to realize performance verification of the SoC, including the following steps: S401: Load scenario configuration and generate dynamic QoS test sequence; In this step, the scenario specification defines key parameters including participating components, performance expected targets (such as bandwidth and delay threshold) of each Master, QoS initial value and adjustable range, clock frequency and stimulation mode in a structured data format (such as JSON or YAML). The scenario specification (Scenario Spec) pre-configured based on the target application scenario can be read by using an automated configuration parsing script written in a script language such as Python or TCL. The script calls a standard JSON or YAML parsing library (such as the JSON module of Python or PyYAML) to read the scenario specification file pre-configured based on the target application scenario by using the open() function and the load() method, loads the content of the scenario specification file into the memory and parses it into structured data objects such as dictionaries and lists which can be operated by programs, with the file path as the input. Then, the parameters are parsed and a dynamic test sequence executable on the simulation platform is automatically generated according to the topology relationship described by the chip resource mapping table. The sequence accurately includes a series of instructions such as initializing the environment, driving the Master to send differentiated business flow according to the configuration, implanting performance monitoring logic at key nodes such as the arbiter and the memory controller, and embedding a closed-loop regulation strategy, so as to convert the user's high-level verification intention into an executable dynamic QoS verification process adapted to the specific scenario.

[0042] S402: Perform dynamic QoS regulation based on the dynamic QoS test sequence.

[0043] In this step, a monitoring circuit (Monitor) is deployed at key nodes such as the arbitrator (Arbit) and the DDR controller entrance. This circuit connects to the path under test through a physical interface to capture real-time timestamps and data information of transmission events, such as collecting the measured bandwidth (BW) and latency of each Master. These two measured data are used as model inputs and compared with the expected performance values set in the scenario specification in real time. During the comparison process, if a deviation is found (e.g., the bandwidth of a certain Master is lower than the target value or the latency is lower than the target value, such as VPU measured bandwidth 6GB / s < 8GB / s target, measured latency 27ns > 24ns target), the performance deviation degree is calculated, and the bandwidth with a larger target deviation is preferentially selected for QoS adjustment (e.g., QoS+1) to improve the QoS priority of the Master. Through a closed-loop feedback mechanism, the monitoring-decision-regulation process is executed in a loop until all Master performance meets the standard or reaches the preset adjustment threshold, thereby achieving adaptive resource allocation and dynamic optimization.

[0044] For example, in the initial state, assume that the QoS of VPU and GPU is 5, at this time the measured bandwidth of 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 both bandwidth and latency have deviations, and after calculation, the bandwidth deviation is larger, so the QoS of VPU is increased to 6, making the bandwidth rise to 7GB / s and the latency drop to 26.5ns. Subsequent second regulation still preferentially targets the bandwidth deviation, and the QoS is further increased to 7, at which time the bandwidth reaches 8.8GB / s (satisfying the expectation), but the latency 26ns is still too high. Finally, the third regulation fine-tunes the QoS to 6.5, making the bandwidth fall back to 8.1GB / s and the latency drop to 23.8ns, both indicators meeting the expected target. In the entire process, the arbitrator and the DDR controller cooperate to achieve dynamic resource optimization allocation.

[0045] 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 passed, 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 arbitrator Arbit1 throughput limitation"), and provide specific optimization suggestions (e.g., increase the clock frequency of the arbitrator or increase its buffer depth), and can adjust the design or configuration parameters based on the diagnostic results and re-run the simulation until the performance fully meets the requirements.

[0046] For the scenarios that have passed the verification, the system stores their complete configuration parameters, including QoS priority, clock frequency, traffic stimulation parameters, etc., to the verification database, and generates structured and reusable "golden test cases". For example: {"scenario": "8K video codec", "QoS configuration": {"VPU": 7, "GPU": 5}, "clock": "1.2GHz"} Such test cases can not only be directly used for performance acceptance testing of mass-produced chips, but also be transplanted to verification environments of other SoCs with the same or similar architecture to improve verification efficiency and project reusability.

[0047] In addition, it should be noted that, on the basis of the above verification using the rule algorithm, for some particularly complex or poorly performing scenarios, the present application performs deep analysis and optimization of data through dynamic control logic (e.g., a decision model based on a neural network).

[0048] For example, as shown in Figure 2 , the decision model based on a neural network includes an input layer, an evaluation layer, a decision layer, and an optimization layer, wherein the input layer is used to input four features including a bandwidth deviation rate , a delay deviation rate , a current QoS value , and an application scenario weight 4. The evaluation layer is used to quantify the "good" or "bad" of the current performance state through a reward function, and to provide an evaluation basis for the decision layer. The reward function is as follows:

[0049] wherein represents the reward value, if it takes a negative value, it means that the performance is poor, if it takes 0, it means that the performance meets the expectation, and if it takes a positive value, it means that the performance is better than the expectation; represents the bandwidth weight, and the value range is [0, 1]; represents the delay weight, and the value range is [0, 1]; represents the stability penalty coefficient, and the value range is [0, 1].

[0050] As shown in the reward function above, the first half is the core of driving optimization, which is responsible for converting performance deviation into a penalty signal; and the second half is a regularization means to ensure smooth convergence of the optimization process.

[0051] The decision layer is used to decide whether to adjust the QoS and the adjustment amplitude according to the output of the evaluation layer. For example, when the reward value is lower than a set threshold, adjustment is triggered, and the adjustment can be made according to the following formula:

[0052] wherein, represents learning rate, used to determine the strength of each adjustment, the greater, the more drastic the change in QoS each time the adjustment, the smaller, the more gradual the change in QoS each time the adjustment; represents the proportion term, which determines which of the bandwidth deviation and the delay deviation dominates in this adjustment, if the bandwidth deviation is very large and the delay deviation is very small, the ratio is close to 1, this adjustment will focus on correcting the bandwidth, otherwise it will focus on correcting the delay; represents the target bandwidth; represents the actual bandwidth; when , the output is 1, indicating that the QoS priority of the master device needs to be raised to allocate more resources to increase the bandwidth; otherwise, the output is -1, indicating that the QoS priority of the master device needs to be lowered to avoid occupying more resources.

[0053] The optimization layer is used to dynamically adjust the weights of bandwidth and delay in the reward function through adaptive weight updates to adapt to different scene requirements, which is specifically represented as follows:

[0054]

[0055] wherein, , respectively represent the weights of bandwidth and delay in the evaluation layer; represents the weight learning rate.

[0056] Below, the present application takes the 8K video recording scene as an example to exemplarily describe the above decision model: Assume that the 8K video recording scene includes the data shown in Table 2: Table 2 8K video recording scene

[0057] In Table 2, the bandwidth deviation rate of VPU = 0.25, the delay deviation rate = 0.125, and the reward can be calculated according to the above formula (e.g. the threshold is set to 0), thus triggering the adjustment:

[0058] ​To sum up, by constructing the decision model as shown above, the QoS is dynamically regulated, the performance deviation reward value is calculated in real time, and the adaptive adjustment instruction is generated, which can accurately perceive the system state, intelligently balance the bandwidth and delay conflict, and stably converge to the optimal resource configuration, thereby helping to improve the accuracy, automation degree and consistency with the real chip behavior of the performance verification of SoC in complex application scenarios.

[0059] In another example embodiment, the present application also provides a SoC performance verification device based on dynamic QoS regulation, as shown in Figure 3 The device includes: an analysis module 100 for analyzing the chip architecture and obtaining a chip resource mapping table; a construction module 200 for constructing an automated verification environment and performing testing based on the chip resource mapping table; a configuration module 300 for configuring scene parameters according to a target application scenario and based on the chip resource mapping table; and a regulation module 400 for performing dynamic QoS regulation based on the configured scene parameters in the tested automated verification environment, so as to realize performance verification of SoC.

[0060] In another example embodiment, the present application also provides a storage medium including instructions which, when executed on a computer, cause the computer to perform the method of any one of the preceding embodiments.

[0061] In another example embodiment, the present application also provides an electronic device including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of the preceding embodiments when executing the program.

[0062] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation using the content of the specification and drawings, or direct or indirect application in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A SoC performance verification method based on dynamic QoS control, characterized in that: The method comprises: Analyze the chip architecture and obtain the chip resource mapping table; Building an automated verification environment based on the chip resource mapping table and performing testing; Performing scenario parameter configuration according to the target application scenario and based on the chip resource mapping table; In a tested automated verification environment, dynamic QoS control is performed based on configured scenario parameters to achieve performance verification of SoC.

2. The method according to claim 1, characterized in that The chip architecture is parsed to obtain a chip resource mapping table, including: Use automated scripts to parse the SoC's design files to extract key component information; Integrate key component information and generate a structured chip resource mapping table.

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

4. The method according to claim 1, wherein The configuring of scenario parameters according to the target application scenario and based on the chip resource mapping table includes: Filtering scenario-participating components 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 of each component in the dynamic regulation process; Set the environment operating parameters.

5. The method according to claim 4, characterized in that The SoC performance verification is performed based on the configured scenario parameters in a tested automated verification environment, including: Load scenario configuration and generate dynamic QoS test sequence; Dynamic QoS control is performed based on the dynamic QoS test sequence to achieve performance verification of the SoC.

6. The method according to claim 5, characterized in that The performing dynamic QoS control based on the dynamic QoS test sequence to achieve performance verification of the SoC includes: Collect measured bandwidth and latency data for components involved in the scenario; Comparing the measured bandwidth and latency data with the expected performance values, and calculating the degree of performance deviation; Based on the comparison results, the QoS priority is regulated through dynamic control logic to achieve performance verification of SoC.

7. The method according to claim 5, characterized in that The performing dynamic QoS control based on the dynamic QoS test sequence to achieve performance verification of the SoC further includes: The decision model based on neural network dynamically controls QoS. The decision model includes input layer, evaluation layer, decision layer and optimization layer. The input layer is used to input bandwidth deviation rate, delay deviation rate, current QoS value and application scenario weight; The evaluation layer is used to quantify the current performance status through the reward function, providing an evaluation basis for the decision-making layer; The decision layer is used to decide 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 delay in the reward function through adaptive weight updates to adapt to the requirements of different scenarios.

8. A SoC performance verification device based on dynamic QoS control, characterized in that: The device comprises: The parsing module is used to parse the chip architecture and obtain the chip resource mapping table; A construction module, configured to construct an automated verification environment based on the chip resource mapping table and perform testing; A configuration module, configured to configure scenario parameters according to a 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 tested automated verification environment to achieve performance verification of the SoC.

9. A storage medium, characterized in that: The method comprises instructions, which, when executed on a computer, enable the computer to execute the method according to any one of claims 1 to 7.

10. An electronic device, characterized in that: The electronic device comprises: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 7 is implemented.

Images