System on chip verification method, electronic device, and storage medium

Abstract

Embodiments of the present application provide a system-on-chip verification method, an electronic device and a storage medium, the method comprising: based on a target operating system and a workload, obtaining tracking information of the target operating system running time; based on the tracking information, generating a plurality of types of segment templates through a plurality of pre-generated template agents, and storing the segment templates into a template library; the segment templates at least include interaction type, link type and feature type; through a pre-generated assembly agent, generating an initial verification segment based on the corresponding segment templates of each type in the template library, and generating an executable target verification segment based on the initial verification segment; executing the target verification segment in a software simulator. The verification efficiency of the system-on-chip is improved.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a system-on-a-chip verification method, electronic device, and storage medium. Background Technology

[0002] In complex system-on-chip (SoC) design verification, it is typically necessary to perform operations such as booting a complete Linux operating system and running real workloads. Currently, related technologies often use field-programmable gate array (FPGA) prototyping platforms for this purpose.

[0003] However, this approach requires placement and routing, which often takes several hours, resulting in low verification efficiency and making it unsuitable for rapid iteration. Summary of the Invention

[0004] This invention provides a system-on-a-chip verification method, an electronic device, and a storage medium to address the problem of low verification efficiency in related technologies.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is implemented as follows: In a first aspect, the present invention provides a system-on-a-chip verification method, the method comprising: Based on the target operating system and workload, obtain the runtime tracing information of the target operating system; Based on the tracking information, multiple types of fragment templates are generated using pre-generated template agents, and these fragment templates are stored in a template library; each fragment template includes at least an interaction class, a link class, and a feature class. Using a pre-generated assembly agent, an initial verification fragment is generated based on various corresponding fragment templates in the template library, and an executable target verification fragment is generated based on the initial verification fragment. The target verification fragment is executed in a software simulator.

[0006] In a second aspect, the present invention provides an electronic device comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the program to implement the method described in the first aspect above.

[0007] Thirdly, the present invention provides a readable storage medium that, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method described in the first aspect.

[0008] The system-on-a-chip verification method provided in this embodiment of the invention can obtain the runtime tracing information of the target operating system based on the target operating system and workload; based on the tracing information, multiple types of fragment templates are generated by pre-generated template agents, and the fragment templates are stored in a template library; the fragment templates include at least interaction classes, link classes, and feature classes; an initial verification fragment is generated based on the corresponding fragment templates in the template library by a pre-generated assembly agent, and an executable target verification fragment is generated based on the initial verification fragment; the target verification fragment is executed in a software simulator. In this embodiment of the invention, instead of using an FPGA verification platform, verification fragments are automatically generated adaptively based on the target operating system and workload using pre-generated template agents and assembly agents, and the verification fragments are executed in a software simulator, which can improve verification efficiency to a certain extent. At the same time, this embodiment of the invention can realize the independent generation and independent expansion of different fragment templates through multiple template agents, and the assembly agent can select templates from the template library to generate verification fragments, with strong independence and composability. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart of the steps of a system-on-a-chip verification method provided in an embodiment of the present invention; Figure 2 This is a verification flowchart provided by an embodiment of the present invention; Figure 3 This is a flowchart illustrating the first intelligent agent provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the extraction of the system call template provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the extraction of the identifier switching template provided in an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the extraction of the permission change sequence template provided in an embodiment of the present invention; Figure 7 This is a flowchart illustrating the second intelligent agent provided in an embodiment of the present invention; Figure 8 This is a schematic diagram illustrating the extraction of a feature class template provided in an embodiment of the present invention; Figure 9This is an assembly diagram provided by an embodiment of the present invention; Figure 10 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0012] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, the first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In embodiments of this invention, the term "multiple" refers to two or more, and other quantifiers are similar.

[0013] Figure 1 This is a flowchart illustrating the steps of a system-on-a-chip verification method provided in an embodiment of the present invention, as follows: Figure 1 As shown, the method may include the following steps: Step 101: Based on the target operating system and workload, obtain the runtime tracing information of the target operating system.

[0014] Step 102: Based on the tracking information, generate multiple types of fragment templates using multiple pre-generated template agents, and store the fragment templates in a template library; the fragment templates include at least interaction classes, link classes, and feature classes; Step 103: Using the pre-generated assembly agent, generate an initial verification fragment based on the corresponding fragment templates in the template library, and generate an executable target verification fragment based on the initial verification fragment.

[0015] Step 104: Execute the target verification segment in the software simulator.

[0016] The embodiments of the present invention can be applied to computer devices such as servers, specifically steps 101-104 above. The target operating system can be the operating system used by the system-on-a-chip to be verified, and the workload can be a remote dictionary server (Redis), a structured query language (MySQL), etc. The target operating system and workload can be set according to actual verification requirements, and the embodiments of the present invention do not impose any limitations on this.

[0017] The trace information mentioned above can be obtained after running the target operating system and workload on the server. Specifically, a full-system simulation and instruction-level instrumentation using a Quick EMUlator (QEMU) can be employed to run the target operating system and workload on the server. Optionally, this operation can be performed offline, allowing dynamic execution and trace information recording of the target operating system and workload within the QEMU environment. Specifically, the call number, parameters, return value, and virtual clock cycle (timestamp) of each system call can be recorded. Furthermore, this information can be written to a structured file on disk, such as a lightweight data format (JavaScript Object Notation, JSON) or binary format, thus obtaining a dynamic trace file.

[0018] In this context, the aforementioned template agents, assembly agents, and other intelligent agents (skills) can all be pre-generated control programs. Specifically, these intelligent agents can be obtained through interaction with a Large Language Model (LLM). Specifically, in this embodiment of the invention, relevant verification personnel can input prompt words into the LLM according to verification requirements, domain rules, and pre-set template generation rules, causing the LLM to output automated scripts or modules as the aforementioned intelligent agents.

[0019] For example, the prompt could be "Extract system call templates from the Trace, combine them with predefined extraction rules, and generate code for the agent script." The prompt could also specify the input and output formats for the script.

[0020] Furthermore, the embodiments of the present invention can implement the corresponding steps by executing the above-described intelligent agents.

[0021] The aforementioned template agent can be an agent used to generate interactive fragment templates, link fragment templates, and feature fragment templates. Different agents can be used to generate different types of fragment templates. For example, in this embodiment of the invention, three agents can be pre-generated to generate interactive, link, and feature fragment templates, respectively.

[0022] The aforementioned interactive fragment templates can also be called basic templates, which may include interactive information such as system calls, identifiers, and permissions.

[0023] The aforementioned link-type fragment templates may include control flow, data flow, and call chains.

[0024] The aforementioned feature fragment templates may include frequency distributions, transfer maps, etc.

[0025] Specifically, the aforementioned fragment template can be a template framework for generating verification fragments. It can characterize the behavior patterns, call chains, and behavioral characteristics of the target operating system and workload during runtime. Thus, the behavior patterns can be reused through the fragment template, and various test cases can be generated through parameterization, thereby accelerating the verification process.

[0026] The aforementioned template library can be pre-built and used to store fragment templates produced for different target operating systems and workloads.

[0027] Accordingly, the assembly agent described above can be an agent used to call fragment templates in a template library to generate an initial verification fragment. The assembly agent can assemble fragment templates according to system characteristics, thereby generating the initial verification fragment.

[0028] Specifically, step 103 above can be to select a template based on the verification target, select high-frequency system calls and uncovered driver modes, and assemble them according to rules such as complete control flow, consistent data flow, valid address space, and consistent timing constraints to obtain an initial verification fragment.

[0029] Specifically, the aforementioned target verification segment may include initialization code (stack, page table, exception vector), page table mapping, main instruction sequence (the aforementioned initial verification segment), termination code (ebreak), compilation script (Makefile), etc.

[0030] The software simulator mentioned above can be a commercial simulator (Verilog Compiler Simulator, VCS) or an open-source simulator (Verilator), etc., and the embodiments of the present invention do not limit it.

[0031] Specifically, the above execution process can involve first using a cross-compilation toolchain (such as riscv64-unknown-elf-gcc) to compile the C / assembly source files into binary files (such as hex or bin), then loading the binary files into simulation memory using the simulator's (VCS or Verilator) load command, setting the program counter to the _start address, and starting the simulation until encountering ebreak. The execution results can include: waveform files, such as a Value Change Dump (VCD) or a Fast Signal Database (FSDB), recording signal changes for each clock cycle; simulation logs, printing program output and instruction execution traces; final register values ​​and memory snapshots; and built-in pass / fail checks (such as comparing expected data or assertion triggers). These execution results can be used to verify whether the processor behavior is correct.

[0032] Optionally, after obtaining the execution results, waveform debugging can also be performed through the automated debugging platform (Verdi).

[0033] Optionally, the different intelligent agents mentioned above can exchange data through standardized interfaces (e.g., data interaction interfaces on disks), so that they do not need to call each other's internal interfaces.

[0034] It should be noted that in the verification of complex system-on-a-chip (SoC) designs, the following verification tasks are usually required: booting a complete Linux operating system; running real workloads, such as Redis and MySQL; and verifying system-level behaviors such as the Memory Management Unit (MMU), Physical Memory Protection (PMP), exception handling, multi-process scheduling, and system security.

[0035] However, due to the extremely slow execution speed of software simulators (VCS / Verilator) (typically on the order of kHz), the aforementioned complete system-level verification cannot be actually completed in the simulator. Therefore, the industry generally adopts FPGA prototyping platforms. However, this approach has the following problems: Extremely weak FPGA debugging capabilities: poor internal signal visibility, limited waveform capture depth, and once a fault (bug) occurs, it often takes days or even weeks to locate. Long regression cycle: FPGA synthesis, placement and routing, and bitstream loading take several hours, making it unsuitable for rapid iteration.

[0036] The system-on-a-chip verification method provided in this embodiment of the invention can obtain the runtime tracking information of the target operating system based on the target operating system and workload; based on the tracking information, multiple types of fragment templates are generated by pre-generated template agents, and the fragment templates are stored in a template library; the fragment templates include at least interaction classes, link classes, and feature classes; an initial verification fragment is generated based on the corresponding fragment templates in the template library by a pre-generated assembly agent, and an executable target verification fragment is generated based on the initial verification fragment; the target verification fragment is executed in a software simulator. In this embodiment of the invention, instead of using an FPGA verification platform, verification fragments are automatically generated adaptively based on the target operating system and workload using pre-generated template agents and assembly agents, and the verification fragments are executed in a software simulator, which can improve verification efficiency to a certain extent. At the same time, this embodiment of the invention can realize the independent generation and independent expansion of different fragment templates through multiple template agents, and the assembly agent can select templates from the template library to generate verification fragments, which has strong independence and composability.

[0037] For example, Figure 2 This is a verification flowchart provided by an embodiment of the present invention, such as... Figure 2 As shown in the diagram, this illustrates the complete data flow from the initial input to the final simulation execution. In this embodiment of the invention, during the offline analysis phase, dynamic execution and trace recording of the target operating system and workload can be performed in the QEMU environment. Specifically, a QEMU full-system simulation + instruction-level instrumentation approach can be used to run the target operating system and workload on a server. The specific execution content may include the content shown in Table 1 below: Table 1: Execution object Detailed description Linux kernel boot From the bootloader to the kernel entry point, initialization is performed and the init process is created. Workload loading and running Execute user-mode test program System call execution All system calls at kernel entry and exit points (open, read, write, mmap, fork, etc.) Exception / Interruption Handling Page fault, illegal instruction, clock interrupt, external device interrupt. Context switching Process switching, thread switching, ASID / VMID updates Privilege level switching For example: user / kernel switching Memory management unit operations Page table base address switching (SATAP write), TLB refresh, page table traversal Furthermore, Figure 2 Skills 1 through 3 in the code are template agents, used to extract interactive fragment templates, link fragment templates, and feature fragment templates, respectively. The three agents can perform template extraction operations in parallel, and the extracted fragment templates can be stored in template libraries.

[0038] Furthermore, Figure 2 The skill4 in the text corresponds to the assembly agent mentioned above. After reading three types of templates from the template library and assembling them to generate an initial verification fragment, it generates a self-contained verification fragment based on the initial verification fragment.

[0039] Furthermore, after obtaining the self-contained verification segment, the simulation execution phase begins, where the generated segment is executed in VCS or Verilator, and waveform debugging can be performed in conjunction with Verdi.

[0040] Optionally, the operation of generating multiple types of fragment templates based on the tracking information and through multiple pre-generated template agents may specifically include the following in this embodiment of the invention: S21. The first intelligent agent obtains system call templates, identifier switching templates, and permission change sequence templates based on the tracking information, and uses them as fragment templates corresponding to the interaction class.

[0041] S22. The second intelligent agent obtains the control flow template, data flow template, and call chain template based on the tracking information, and uses them as the fragment templates corresponding to the link class.

[0042] S23. Using a third intelligent agent, obtain a frequency distribution table and a transfer map based on the tracking information, and use them as fragment templates corresponding to the feature class.

[0043] Specifically, fragment templates can include three categories: basic templates or interactive templates (system calls, ID switching, page tables / permissions), link templates (control flow, data flow, system call chains), and system features (frequency distribution, transition probability).

[0044] Optionally, the operation of obtaining system call templates, identifier switching templates, and permission change sequence templates based on the tracking information as fragment templates corresponding to the interaction class, as described above, may specifically include the following in this embodiment of the invention: S31. Based on the tracking information, obtain the call parameter combination, page table status and memory status corresponding to each system call number, and generate a system call template.

[0045] S32. Based on the tracking information, obtain the switching events corresponding to different identifiers, and obtain the occurrence order of each switching event. Arrange the switching events according to the occurrence order to obtain the identifier switching template.

[0046] S33. Based on the tracking information, obtain page table base address switching records, page table entry permission modification records, and physical memory protection configuration records, and generate a permission change sequence template.

[0047] Specifically, the first to third intelligent agents mentioned above can be referred to as skill1 to skill3, respectively.

[0048] Furthermore, Figure 3 This is a flowchart illustrating the first intelligent agent provided in an embodiment of the present invention, as shown below. Figure 3 As shown, Skill 1 basic template extraction consists of three subtasks. These are used to extract system call templates, identifier (ID) switching templates, and page table / permission templates, respectively.

[0049] Specifically, the method for extracting system call templates is as follows: classify the system call records by system call number, count the common parameter values ​​and combinations for each system call, record the changes in page tables and memory states before and after the call, and generate parameterizable call templates.

[0050] Specifically, Figure 4 This is a schematic diagram illustrating the extraction of the system call template provided in an embodiment of the present invention, such as... Figure 4 As shown, the system call number and its parameter list are first captured from the trace data. Then, the return value is recorded. Simultaneously, the memory state and page table state before and after the system call execution are captured. Finally, all information is encapsulated into a complete system call template. Each template is saved independently, supporting subsequent on-demand invocation and parameterized modification.

[0051] Specifically, during the extraction of the system call template, the system call number identifies the kernel service type (read, write, memory mapping, etc.), and the parameter list specifies the specific operation object of the service (file descriptor, buffer address, length, etc.). Together, they define the complete behavior of the system call. Memory state refers to the content and data values ​​of the virtual address range; page table state refers to the mapping relationship and access permissions from virtual addresses to physical addresses. They reflect the interaction between the operating system and the hardware MMU. In this embodiment of the invention, QEMU can intercept system call paths to capture call numbers and parameters; memory callbacks can be used to record data at key addresses; and CSR writes and page table traversals can be monitored to capture page table states. Parameters for similar calls are replaced with placeholders to represent constant values, and pre / post states are abstracted into conditions and actions, forming parameterizable templates.

[0052] The method for extracting the ID switching template is as follows: extract the time point and values ​​before and after each switching of identifiers such as Address Space Identifier (ASID), Virtual Machine Identifier (VMID), and Supervisor Domain Identifier (SDID), to form a time series. Then, mine the recurring switching patterns and output a parameterizable switching sequence template.

[0053] For example, taking ASID / VMID as an example, ASID is located in the ASID field of the SATAP register (typically bits 63-60 or similar, depending on XLEN), and VMID is located in the VMID field of the HGATP register (if H extension is supported). In QEMU full system simulation, the csrw instruction can be instrumented. When the target register is SATAP or HGATP, the write value is read, and the ASID or VMID field is extracted through the bitmask. Simultaneously, the current virtual clock cycle and HART number are recorded.

[0054] For implicit switches caused by exceptions or interruptions (such as VM entry / exit), the current CSR value is read in the relevant handling function (such as riscv_cpu_do_interrupt) and recorded as a switch event.

[0055] The encapsulation rule for identifier switching events can be to arrange all switching events in chronological order, with each event including (timestamp, HART, identifier type, old value, new value).

[0056] Specifically, Figure 5 This is a schematic diagram of the extraction of the identifier switching template provided in an embodiment of the present invention, such as... Figure 5 As shown, it simultaneously captures switching events for ASID (Address Space Identifier), VMID (Virtual Machine Identifier), SDID (Security Domain Identifier), etc., and records the chronological order of each switching event, ultimately encapsulating them into an ID switching sequence template. This template can simulate concurrent access scenarios involving multiple processes, multiple virtual machines, and multiple security worlds.

[0057] Accordingly, the method for extracting page tables and permission switching templates (permission change sequence templates) is as follows: capture write operations of the page table base address register, modification of page table entry permission bits, and PMP configuration updates, record the values ​​before and after each switch, and generate permission change sequence templates.

[0058] Specifically, Figure 6 This is a schematic diagram illustrating the extraction of the permission change sequence template provided in an embodiment of the present invention, as shown below. Figure 6 As shown, three types of permission-related behaviors can be captured simultaneously: switching of the page table base address register (such as the SATA register in RISC-V), modification of read / write / execute (R / W / X) permission bits in page table entries, and reconfiguration of PMP (Physical Memory Protection) or MPT (Fine-grained Physical Memory Protection Permission Page Table) permissions. These behaviors are encapsulated into permission switching sequence templates to verify the correctness of the hardware permission checking mechanism.

[0059] Specifically, page table base address switching: capture CSrW write operations to the SATA register. Record the old and new values, and extract the ASID and page table base address physical page number (PPN) from them.

[0060] Page table entry permission modification: Page table entries are stored in memory. QEMU monitors write operations to the page table memory area (the page table tree whose address range is pointed to by satp) through memory write callbacks. The written PTE is parsed to extract its permission bits (R, W, X, U) and the corresponding virtual page number (VPN).

[0061] PMP Configuration: Capture write operations to the pmpaddrX and pmpcfgX registers, and record the address range, permission configuration (R / W / X), and lock bits.

[0062] Encapsulation rules: Record each event in chronological order as (timestamp, HART, type, old permission, new permission). Only retain the first occurrence of consecutive identical values.

[0063] For page table base address switching, the sequence is represented as [old SATA → new SATA]; for page table entry modification, it is represented as [VPN: old permissions → new permissions].

[0064] For PMP, it is represented as [region index: old configuration → new configuration].

[0065] Furthermore, after the above steps, they are finally merged into a permission switching template.

[0066] In this embodiment of the invention, the fragment template corresponding to the interactive class can be extracted using the above method.

[0067] Optionally, the operation of obtaining the control flow template, data flow template, and call chain template based on the tracing information as the fragment template corresponding to the link class in the above embodiments of the present invention may specifically include: S41. Based on the basic block execution sequence recorded by the tracking information, obtain the execution count of the jump edge contained in the binary file corresponding to the workload, and determine the path whose execution count meets the preset requirements as the control flow template.

[0068] And, S42, based on the trace information, construct an instruction mapping table for each register and each memory address, and for any read instruction, establish a dependency chain corresponding to the read instruction based on the instruction in the instruction mapping table corresponding to the read position of the read instruction.

[0069] S43. Cluster the dependency chains to obtain the data flow template.

[0070] And, S44, based on the parameter passing behavior of each system call event, obtain the system call sequence to obtain the call chain template.

[0071] Specifically, Skill 2 link template extraction can contain three subtasks. Figure 7 This is a flowchart illustrating the second intelligent agent provided in an embodiment of the present invention, as shown below. Figure 7 As shown, Skill 2 internally executes three subtasks in parallel: 2A extracts control flow dependencies (execution order of basic blocks, branch jump relationships), 2B extracts data flow dependencies (read / write dependencies of registers / memory), and 2C extracts system call chain templates (the open→read→write→close sequence in file operations). The output consists of three types of link templates, which are used to combine with the base template later.

[0072] The method for extracting the control flow dependency template is as follows: Combining static disassembly and dynamic execution paths, extract the jump relationships and execution order between basic blocks, identify frequently occurring branch paths, and output the control flow template. Specifically, this can be achieved through the following steps: Input: workload binary file + QEMU dynamic trace (records basic block entry / exit).

[0073] Static disassembly of the binary data constructs jump edges (direct, conditional, and indirect) between basic blocks. Dynamic trace records the actual executed sequence of basic blocks and counts the execution count of each edge.

[0074] High-frequency paths (such as basic block sequences that appear frequently in succession) are extracted as control flow templates.

[0075] Output: Control flow template (basic block sequence, including branch conditions and jump targets).

[0076] The method for extracting the data flow dependency template is as follows: trace the register or memory address read by each instruction, reverse the location to the instruction that was most recently written to that location, form a data flow path, extract common read / write dependency patterns, and output the data flow template.

[0077] Specifically, this can be achieved through the following steps: Input: Instruction-level trace (including register reads and writes, memory addresses, and data).

[0078] Maintain a mapping table of "last write instructions" for each register and each memory address.

[0079] Scan the trace. For each instruction: if a register or memory is read, establish a dependency edge between that instruction and the instruction last written to that location in the mapping table.

[0080] Record the dependency chain (write → read) and cluster common patterns (such as load → add → store).

[0081] Output: Data flow template (dependency chain, replacing specific register numbers or address offsets with variables).

[0082] The method for extracting the system call chain template is as follows: identify call pairs with parameter dependencies (such as file descriptor passing) from the system call sequence, mine the frequently occurring call order, and output the call chain template.

[0083] Specifically, it can be extracted through the following steps: Input: System call trace (including call number, parameters, return value, especially transitive parameters such as file descriptors).

[0084] Treat each system call as an event and record its input / output parameters.

[0085] Identify parameter passing dependencies: for example, the file descriptor returned by open is used by subsequent read / write / close operations.

[0086] Use a sequence pattern mining algorithm to find frequently occurring system call sequences (such as open→read→write→close).

[0087] System call chain template (a call sequence with parameter dependencies).

[0088] In this embodiment of the invention, the dependency chain template can be obtained through the above method.

[0089] Optionally, the operation of obtaining the frequency distribution table and transition map based on the tracking information as the fragment template corresponding to the feature class in the above embodiments of the present invention may specifically include: S51. Based on the system call events in the tracking information, obtain the number of times different system call events are called.

[0090] S52. Based on the number of times each system call event is called, obtain the change sequence and call density of each system call event in the tracking information, and generate the frequency distribution table.

[0091] In addition, S53, construct a directed graph with different system call events as nodes, and count the number of times another system call event is executed after any system call event, so as to calculate the transition probability.

[0092] S54. Generate a transition probability matrix based on the transition probability of each system call event, which serves as the transition map.

[0093] Specifically, Figure 8This is a schematic diagram illustrating the extraction of a feature class template provided in an embodiment of the present invention, such as... Figure 8 As shown, Skill 3 system feature extraction can consist of two subtasks. Specifically, the input to Skill 3 is dynamic workload trace data with timestamps. Skill 3 executes two subtasks in parallel: 3A performs frequency analysis (statistically analyzing the proportion of system calls, call intervals, and changes within time windows), and 3B performs graph analysis (constructing a directed graph of system call transitions, calculating the transition probability matrix, and constructing a Markov chain). The output is a system feature description file, used to guide feature injection in Skill 4. Skill-3B constructs a directed graph G=(V,E), where node V represents the system call type, and edge E represents the transition relationship between system calls and its frequency. The transition probability matrix is ​​calculated based on the number of transitions, and an N-order Markov chain (N≥1) is further constructed to describe the statistical regularity of the system call sequence. This graph is used to generate representative system call sequences according to the statistical regularity of the real workload when generating validation fragments.

[0094] Furthermore, the frequency analysis extraction method involves: statistically analyzing the total number of system calls, their proportion, and the distribution of adjacent call intervals for each system call, and then analyzing the frequency changes over time according to a time window, outputting a frequency distribution table. Specifically, firstly, the total number of calls for each type of system call is counted, and the statistical characteristics of the call interval distribution (mean, variance, histogram) are calculated. Simultaneously, the frequency change trend over time is analyzed according to a time window (e.g., more mmap calls during initialization, more read / write calls during stable operation), and the call density (number of calls per unit time) is calculated. These statistical characteristics are used to determine the injection ratio and temporal distribution of various system calls in the generated verification fragment.

[0095] The specific statistical and calculation methods are as follows: To count the total number of system calls: Scan the entire Trace file, and for each system call record (including the system call number) encountered, increment the counter for the corresponding call number. Finally, obtain the absolute number of each type of system call.

[0096] Calculate the call interval distribution: For each system call, record the time difference between two adjacent calls (in terms of virtual cycles or instruction count). After collecting all interval values, calculate the mean and variance, and divide the data into several intervals (such as 0-100, 100-500, etc.) to generate a histogram.

[0097] Analyze trends within a time window: Divide the entire trace into fixed-length time windows (e.g., 100,000 cycles). Within each window, count the frequency or percentage of various system calls to obtain a time series. By comparing the distribution across different windows, identify characteristics such as the initialization phase and the stable operation phase.

[0098] Call density is calculated as follows: Call density = number of calls per unit time. The average density is obtained by dividing the total number of calls by the total duration of the trace (virtual cycles). Local density can also be calculated by window.

[0099] These acquired features need to be stored. They are encapsulated into system feature description files (such as JSON format) and stored in a system feature library on disk. This feature library, along with the basic template library and the linked template library, is used by Skill 4 to guide the injection ratio and timing distribution of system calls.

[0100] Furthermore, the extraction method of graph analysis is as follows: construct a directed graph with system call type as the node, count the number of times each system call is followed by another system call, calculate the transition probability, and extend it to a higher-order Markov chain to output the transition probability matrix.

[0101] Specifically, after counting the number of transitions, each source node is normalized to obtain a probability matrix.

[0102] The transition probability matrix is ​​calculated as follows: First, count the number of transitions for each edge (A→B) in the directed graph, i.e., the total number of times system call A is immediately followed by B. For each source node A, sum the counts of all its outgoing edges to obtain the total number of transitions originating from A. Then, calculate the probability of each target node B: P(A→B) = count(A→B) / total number of transitions. This results in a row-normalized matrix, where each row corresponds to a source system call type, and each column represents the target system call type. The probability value indicates the likelihood that the next call will be of that type given the current call.

[0103] It should be noted that the state of an N-order Markov chain is represented by N consecutive system calls, and the conditional probability is calculated by counting the number of N+1 tuples. N is determined through cross-validation or when the prediction accuracy no longer improves, and typically takes values ​​from 1 to 3.

[0104] Optionally, the operation of generating an initial verification fragment based on various corresponding fragment templates in the template library, as described above, may specifically include the following in this embodiment of the invention: S61. Match the fragment templates corresponding to the interaction class and the fragment templates corresponding to the link class to obtain the initial instruction sequence.

[0105] S62. Based on the frequency distribution table in the fragment template corresponding to the feature class, insert various system calls into the initial instruction sequence.

[0106] S63. Based on the transition graph in the fragment template corresponding to the feature class, insert a system call with a transition probability that meets the requirements into the current initial instruction sequence.

[0107] S64. Based on the frequency distribution table in the fragment template corresponding to the feature class, adjust the timing distribution of each system call in the current initial instruction sequence to obtain the initial verification fragment.

[0108] Specifically, the purpose of the above matching operation is to establish a correspondence between the behavioral dependencies (control flow, data flow, system call chain) described in the link template and the specific operations (system call instructions, ID switching instructions, page table operations, etc.) that can be executed in the basic template, thereby generating a preliminary instruction sequence that can actually be executed in the simulator.

[0109] The matching operations described above can specifically include: instruction-level dependency matching: mapping dependency chains such as load→ALU→store to specific memory access and operation instruction sequences. System call chain matching: mapping call chains such as open→read→close to trigger instructions (ecall) and their parameter setting sequences for corresponding system call numbers. ID switching requirement matching: mapping ID switching requirements to write instruction sequences for CSRs (e.g., satp). After merging, a preliminary sequence with practical significance is obtained, which mixes ordinary instructions, system call trap instructions, and CSR write instructions.

[0110] Optionally, the operation of generating an executable target verification fragment based on the initial verification fragment, as described above, may specifically include, in embodiments of the present invention: S71. Verify the initial verification segment according to the preset verification rules, and generate environment code based on the verified hardware state if the verification is successful.

[0111] S72. Combine the environment code, the initial verification segment, the preset end code, and the compilation script to obtain an executable target verification segment.

[0112] Specifically, Figure 9 This is an assembly diagram provided by an embodiment of the present invention, such as... Figure 9As shown, Skill 4's input comes from the outputs of the first three Skills: the base template, the linked template, and system features. Skill 4 internally executes four subtasks sequentially: 4A template matching, 4B feature injection, 4C consistency verification, and 4D executable generation. If the consistency verification fails, it reverts to 4A for re-matching, forming a feedback optimization loop. The final output is a self-contained verification fragment.

[0113] Skill-4A performs three types of matching operations: matching instruction-level dependencies (such as load→ALU→store) in the link template with system call templates in Skill 1; matching system call chain dependencies (such as open→read→close) with system call templates; and matching ID switching requirements with ID switching sequence templates. The matching results are merged into a preliminary sequence and output to the next stage.

[0114] Skill-4B Feature Injection: Based on the system feature description file output by Skill 3, three types of injection operations are performed: First, according to the system call frequency distribution, an appropriate proportion of various system calls are inserted into the matched sequence. Second, according to the system call transition probability matrix, the subsequent call with the highest probability is inserted after the existing call. Third, according to the time window characteristics, the temporal distribution of each call is adjusted (e.g., placing the dense mmap calls in the initialization phase at the beginning of the segment). The final output is the complete injected sequence.

[0115] For example, suppose the characteristics of Skill 3 output may include: Frequency: mmap 10%, read 45%, write 30%, close 15%; Transition probabilities: open→read 0.7, open→close 0.3; read→write 0.6, read→close 0.4; Time window: The first 20% window is occupied by 60% of mmap, and the latter 80% window is occupied by 80% of read / write.

[0116] Skill-4A has generated a preliminary sequence containing a single open.

[0117] Injection steps: 1. Frequency-based completion: The target total number of calls is 100, and there is already one `open` call. 10 more `mmap` calls, 45 `read` calls, 30 `write` calls, and 15 `close` calls need to be inserted (the percentage of `open` itself is negligible). Specific parameter instances are selected from the template library.

[0118] 2. Insert subsequent calls according to transition probabilities: Starting with `open`, there's a 70% probability of following `read` and a 30% probability of following `close`. Assuming `read` is followed, then `write` is followed with a 60% probability and `close` with a 40% probability. This process is recursively repeated until a sufficiently long call chain that matches the transition probabilities is generated.

[0119] 3. Adjust the position according to the time window: Place all 10 mmap calls in the first 20% of the sequence; place the read / write calls in the last 80%; insert empty loops between adjacent calls to match the time window length.

[0120] The final system call sequence is 100 in length, and its type ratio, transfer pattern and timing distribution are consistent with the actual load.

[0121] Furthermore, the aforementioned verification rules may specifically include: whether the ASID is consistent with the current page table binding, whether the VMID is correctly mapped to the address space, whether the PMP / MPT permission settings match subsequent access operations, whether the values ​​of key registers such as the stack pointer and PC are valid, and whether the mapping relationship between physical addresses and virtual addresses is complete. If all five checks pass, the verification is returned as passed; if any one check fails, the verification is returned as failed with a reason for failure, triggering a rollback and regeneration.

[0122] Furthermore, the core purpose of verification is to ensure that the generated verification fragment can be executed correctly in the simulator, avoiding simulation crashes or meaningless errors caused by inconsistent states (such as missing address mapping, permission conflicts, and illegal registers), thereby ensuring the validity of the verification results.

[0123] If the ASID is not consistent with the current page table binding: the currently set ASID does not match the ASID recorded in the page table base address register, resulting in TLB lookup errors.

[0124] If the VMID and address space mapping are incorrect: the virtual machine identifier and page table mapping relationship do not match, which may lead to memory access across virtual machines.

[0125] If the PMP / MPT permissions do not match the subsequent access operation: The access type of the next load / store instruction to be executed conflicts with the permission settings of the current physical memory region (such as performing a write operation in a read-only region).

[0126] If the stack pointer or PC value is invalid: the stack pointer is not aligned or points to a non-memory region, or the PC points to an unmapped address or a non-executable region.

[0127] If the mapping between physical and virtual addresses is incomplete: if a virtual address is not mapped to a physical address, it will result in a page fault, but the fragment does not have exception handling code prepared.

[0128] The verification failed because the template matching and feature injection phases only focused on behavior frequency and control flow, failing to automatically guarantee all hardware state constraints. For example, the page table pointer was not updated synchronously after an ID switch, or the injected memory access address was not pre-mapped in the page table. These omissions or inconsistencies will be caught during the verification phase and trigger a rollback upstream to adjust the template selection or injection parameters until a hardware-acceptable verification fragment is generated.

[0129] Furthermore, Skill-4D generates an executable fragment consisting of four parts: initialization code (setting the stack pointer, TLB pre-filling, and exception vector table), the main instruction sequence (the final instruction / system call sequence after matching and injection), termination code (fixed template, stopping the simulation), and a matching Makefile compilation script. The combined output of these four parts is a complete verification fragment that can be directly compiled and run in VCS or Verilator.

[0130] Optionally, after storing the fragment template in the template library as described above, the embodiments of the present invention may further include: S81. In the template library, add an index identifier to the fragment template; the index identifier is associated with the version of the target operating system and the type of the workload.

[0131] Specifically, embodiments of the present invention can establish a version management system for the template library, which can be indexed by operating system version, workload type, and hardware configuration. This facilitates the reuse of fragment templates.

[0132] Optionally, after obtaining the runtime tracing information of the target operating system as described above, the embodiments of the present invention may further include: S91. Based on the tracking information and the historical tracking information already acquired, obtain incremental information.

[0133] S92. Based on the incremental information, generate an incremental template.

[0134] S93. Based on the incremental template and the fragment templates stored in the template library, generate corresponding fragment templates for the tracking information.

[0135] Specifically, when the input (operating system version, workload type, hardware configuration) changes, the incremental template extraction method is as follows: Difference detection: The new input is compared with the index of the existing version in the template library (such as version number, file hash, kernel configuration summary) to identify the changed modules (such as the system call table in the upgraded kernel, the newly added workload functions, the page table level in the hardware configuration, etc.).

[0136] Replay Changes: Only re-execute QEMU dynamic trace for workloads or operating system modules that have changed, such as only running newly added or modified system call code paths, rather than the full OS startup and all workloads.

[0137] Incremental template generation: For unmatched events appearing in the new Trace (such as new system call parameter combinations, new ID switching modes), Skill 1 and Skill 2 analysis are performed to generate incremental templates (only the newly added or changed templates are recorded). Unchanged parts directly reuse the old templates.

[0138] Differential storage: Incremental templates are stored in diff format (e.g., only newly added system call templates, or incremental histograms of parameter distribution in existing templates). During merging, the increments are applied to the base template library to generate a new version of the full template.

[0139] Version tagging: Each template instance comes with a version range and difference tags, automatically selecting the best-matching template during a query. Subsequent assembly will prioritize using the newest version template.

[0140] It should be noted that in one scenario, the relevant technologies cannot be integrated with the emulator's native debugging toolchain: for example, efficient waveform debugging methods such as Universal Digital Block (UDB) and Verdi cannot be used. Due to the limitation of the emulation frequency, the emulator can only run extremely simple tests: existing simulation verification can only run bare-metal programs or very lightweight real-time operating systems (RTOS), and cannot handle the verification requirements of real Linux+workload.

[0141] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0142] The present invention also provides an electronic device, see [link to relevant documentation]. Figure 10 The system includes a processor 401, a memory 402, and a computer program 4021 stored in the memory and executable on the processor. When the processor executes the program, it implements the system-on-a-chip verification method of the aforementioned embodiments.

[0143] It should be noted that the electronic terminal in the embodiments of the present invention includes mobile electronic devices and non-mobile electronic devices.

[0144] The processor can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), a FPGA (Field Programmable Gate Array), or other programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0145] The communication bus may include a path for transmitting information between the memory and the communication interface. The communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 10 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0146] The memory may be ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or it may be EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disk Read Only), magnetic tape, floppy disk and optical data storage devices, etc.

[0147] The present invention also provides a readable storage medium, wherein when the instructions in the storage medium are executed by the processor of an electronic device, the electronic device is able to execute the system-on-a-chip verification method of the foregoing embodiments.

[0148] The present invention also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform... Figure 1 The system-on-a-chip verification method is shown.

[0149] The present invention also provides a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the various processes of the above-described system-on-a-chip verification method embodiments, and achieving the same technical effect. To avoid repetition, it will not be described again here.

[0150] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0151] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid state disks (SSDs)).

[0152] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0153] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0154] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0155] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0156] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0157] Similarly, it should be understood that, in order to simplify the invention and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into this detailed description, wherein each claim itself is a separate embodiment of the invention.

[0158] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0159] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the sorting device according to the present invention. The present invention can also be implemented as a device or apparatus program for performing part or all of the methods described herein. Such a program implementing the present invention can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0160] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0161] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0162] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0163] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for verifying a system-on-a-chip, characterized in that, The method includes: Based on the target operating system and workload, obtain the runtime tracing information of the target operating system; Based on the tracking information, multiple types of fragment templates are generated using pre-generated template agents, and these fragment templates are stored in a template library; each fragment template includes at least an interaction class, a link class, and a feature class. Using a pre-generated assembly agent, an initial verification fragment is generated based on various corresponding fragment templates in the template library, and an executable target verification fragment is generated based on the initial verification fragment. The target verification fragment is executed in a software simulator.

2. The method according to claim 1, characterized in that, Based on the tracking information, multiple types of fragment templates are generated through pre-generated template agents, including: The first intelligent agent obtains system call templates, identifier switching templates, and permission change sequence templates based on the tracking information, which serve as fragment templates corresponding to the interaction class. The second intelligent agent obtains the control flow template, data flow template, and call chain template based on the tracking information, which serve as the fragment templates corresponding to the link class. A third intelligent agent obtains a frequency distribution table and a transfer map based on the tracking information, which serve as fragment templates corresponding to the feature class.

3. The method according to claim 2, characterized in that, The process of obtaining system call templates, identifier switching templates, and permission change sequence templates based on the tracking information, as fragment templates corresponding to the interaction class, includes: Based on the tracking information, obtain the call parameter combination, page table status and memory status corresponding to each system call number, and generate a system call template. Based on the tracking information, the switching events corresponding to different identifiers are obtained, and the occurrence order of each switching event is obtained. The switching events are arranged according to the occurrence order to obtain the identifier switching template. Based on the tracking information, page table base address switching records, page table entry permission modification records, and physical memory protection configuration records are obtained, and permission change sequence templates are generated.

4. The method according to claim 2, characterized in that, The step of obtaining the control flow template, data flow template, and call chain template based on the tracing information, as the fragment template corresponding to the link class, includes: Based on the basic block execution sequence recorded by the tracking information, the number of executions of the jump edges contained in the binary file corresponding to the workload is obtained, and the path whose execution count meets the preset requirements is determined as the control flow template; Furthermore, based on the tracking information, an instruction mapping table for each register and each memory address is constructed, and for any read instruction, a dependency chain corresponding to the read instruction is established based on the instruction in the instruction mapping table corresponding to the read position of the read instruction; Cluster the dependency chains to obtain the data flow template; Furthermore, based on the parameter passing behavior of each system call event, the system call sequence is obtained, and the call chain template is obtained.

5. The method according to claim 2, characterized in that, The step of obtaining a frequency distribution table and a transfer map based on the tracking information, as a fragment template corresponding to the feature class, includes: Based on the system call events in the tracking information, the number of times each system call event is called is obtained; Based on the number of times each system call event is invoked, the change sequence and call density of each system call event in the tracing information are obtained, and the frequency distribution table is generated; Additionally, a directed graph with different system call events as nodes is constructed, and the number of times one system call event is executed after any system call event is counted to calculate the transition probability; A transition probability matrix is ​​generated based on the transition probabilities of each system call event, which serves as the transition map.

6. The method according to claim 1, characterized in that, The process of generating an initial verification fragment based on various corresponding fragment templates in the template library includes: The fragment templates corresponding to the interaction class and the fragment templates corresponding to the link class are matched to obtain the initial instruction sequence; Based on the frequency distribution table in the fragment template corresponding to the feature class, various system calls are inserted into the initial instruction sequence; Based on the transition graph in the fragment template corresponding to the feature class, insert a system call with a transition probability that meets the requirements into the current initial instruction sequence; Based on the frequency distribution table in the fragment template corresponding to the feature class, the timing distribution of each system call is adjusted in the current initial instruction sequence to obtain the initial verification fragment.

7. The method according to claim 6, characterized in that, The step of generating an executable target verification fragment based on the initial verification fragment includes: The initial verification segment is verified according to the preset verification rules, and if the verification passes, environment code is generated based on the verified hardware state. The environment code, the initial verification fragment, the preset end code, and the compilation script are combined to obtain an executable target verification fragment.

8. The method according to any one of claims 1-7, characterized in that, After storing the fragment template in the template library, the method further includes: In the template library, an index identifier is added to the fragment template; the index identifier is associated with the version of the target operating system and the type of the workload.

9. The method according to any one of claims 1-7, characterized in that, After obtaining the runtime tracing information of the target operating system, the method further includes: Based on the tracking information and the historical tracking information already acquired, incremental information is obtained; Based on the incremental information, an incremental template is generated; Based on the incremental template and the fragment templates already stored in the template library, corresponding fragment templates of various types are generated for the tracking information.

10. An electronic device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method as claimed in any one of claims 1 to 9.

11. A computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1 to 9.

Images