Cross-reset-domain script generation method and device for verifying system-on-chip

Abstract

The invention discloses a cross-reset-domain script generation method for verifying a system-on-chip, and relates to the technical field of chips, and the method comprises the steps: obtaining an original text, the original text comprises a first code, a second code and a third code, the first code represents a data signal, a clock signal and a reset signal of the system-on-chip, and the second code represents a reset signal of the system-on-chip; the second code represents an output code obtained by modeling and simulation of the system-level chip, and the third code represents a user-defined cross-reset domain verification condition; the original text is analyzed, a structured text is obtained, and the structured text comprises a clock signal and a reset signal of the system-on-chip and structured information of a port and a module; according to the method, the structured text is converted into the cross-reset-domain script for verifying the system-on-chip, so that the problem of low cross-reset-domain verification efficiency of the system-on-chip in related technologies is solved, and the cross-reset-domain verification efficiency of the system-on-chip is improved.

Description

Technical Field

[0001] The present invention relates to the field of chip technology, and in particular to a method and device for generating a cross-reset domain script for verifying a system-on-chip. Background Art

[0002] From consumer electronics to high-performance computing, systems-on-chips (SoCs) are ubiquitous. As demands for SoC functionality and performance increase, SoCs integrate a large number of submodules, including system-on-chip control logic modules, microprocessors / microcontrollers, digital signal processors, embedded memory modules, peripheral interface modules, and bus modules. These submodules have different reset domains, leading to reset domain cross (RDC) issues. Related technologies rely on manually written scripts for cross-reset domain verification, which suffers from low verification efficiency. Summary of the Invention

[0003] The present invention provides a method and device for generating a script for verifying a cross-reset domain of a system-on-chip, so as to at least solve the problem of low efficiency of cross-reset domain verification of SoC in the related art.

[0004] The present invention provides a script generation method for verifying cross-reset domains of a system-on-chip, comprising:

[0005] Obtaining original text, where the original text includes a first code, a second code, and a third code, wherein the first code represents a data signal, a clock signal, and a reset signal of the system-level chip, the second code represents an output code obtained by modeling and simulation of the system-level chip, and the third code represents a user-defined cross-reset domain verification condition;

[0006] Parsing the original text to obtain structured text, which includes structured information of the clock signal, reset signal and port of the system-level chip;

[0007] Convert structured text into scripts for verifying cross-reset domains of system-on-chips.

[0008] The present invention also provides a script generation device for verifying cross-reset domains of a system-on-chip, comprising:

[0009] An acquisition module is used to acquire original text, where the original text includes a first code, a second code, and a third code. The first code represents a data signal, a clock signal, and a reset signal of the system-level chip; the second code represents an output code obtained by modeling and simulation of the system-level chip; and the third code represents a user-defined cross-reset domain verification condition.

[0010] A parsing module is used to parse the original text to obtain structured text, which includes structured information of the clock signal, reset signal and port of the system-level chip;

[0011] A conversion module that converts structured text into scripts for verifying cross-reset domains of system-on-chips.

[0012] The present invention also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing any of the steps of the above-mentioned script generation method for verifying the cross-reset domain of a system-on-chip when executing the computer program.

[0013] The present invention also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the computer program implements the steps of any of the above-mentioned script generation methods for verifying the cross-reset domain of the system-on-chip.

[0014] The present invention also provides a computer program product, comprising a computer program, which implements any of the steps of the above-mentioned script generation method for verifying the cross-reset domain of the system-on-chip when the computer program is executed by a processor.

[0015] The present invention automatically parses the design code (signal definition, simulation output, user constraints) and automatically extracts the connection relationship between the clock, reset signal and port, avoiding the tedious process of manually combing through complex signal topologies. It generates structured text containing clock / reset signal paths and port attributes, eliminating errors such as signal misbinding and constraint omissions when manually writing scripts, and improving verification reliability. It then uses structured data to drive script generation, solving the problem of low efficiency of traditional manually written RDC verification scripts. It greatly improves the RDC verification efficiency of SoC chips. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 A flowchart of a method for generating a script for verifying cross-reset domains of a system-on-chip provided by an embodiment of the present invention;

[0018] Figure 2 is a flowchart of a method for parsing original text into structured text according to an embodiment of the present invention;

[0019] Figure 3 1 is a schematic diagram of the RTL code parsing process according to an embodiment of the present invention;

[0020] Figure 4 Schematic diagram of a process for parsing a second code according to an embodiment of the present invention;

[0021] Figure 5 is a flow chart of a method for converting structured text into a script for verifying RDC of a SoC chip according to an embodiment of the present invention;

[0022] Figure 6 is a flowchart of a method for generating a verification report using a script for verifying an RDC of a SoC chip according to an embodiment of the present invention;

[0023] Figure 7 is a flow chart of an RDC verification method according to an embodiment of the present invention;

[0024] Figure 8 is a flowchart of a method for automatically generating a black box model according to an embodiment of the present invention;

[0025] Figure 9 1 is a structural block diagram of a script generation device for verifying a cross-reset domain of a system-on-chip according to an embodiment of the present invention;

[0026] Figure 10 Schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0027] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0028] It should be noted that, in the description of the present invention, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. The terms "first," "second," etc., in the present invention are used to distinguish similar objects, and are not used to describe a particular order or precedence.

[0029] In order to help understand this solution more clearly, the technical terms involved in the present invention are explained as follows:

[0030] SoC: refers to an integrated circuit design technology that integrates complete system components such as processors, memory, and peripherals into a single chip.

[0031] Clock Domain Cross (CDC): refers to the signal transmission between modules controlled by different clocks in digital circuits. Due to differences in clock frequency and phase, direct transmission can easily cause metastability or data errors.

[0032] RDC refers to the potential risk caused by reset signal asynchrony or timing deviation when signals or data are transferred from one reset domain (a logic area controlled by a specific reset signal) to another in a system-on-chip (SoC). For example, if the signal in asynchronous reset domain A directly drives the logic in domain B without synchronization, this could cause metastability, data corruption, or functional failure when the reset is released.

[0033] Black box model: refers to a script used to verify the RDC of SoC chips that only focuses on the relationship between system input and output without considering its internal implementation details.

[0034] Register Transfer Level (RTL): A level of abstraction in digital circuit design that describes the flow and conversion of data between registers, as well as the control logic. Typically implemented in hardware description languages ​​(such as Verilog and VHDL), RTL focuses on data paths and state machine behavior. This is a critical design phase before logic synthesis, generating actual gate-level circuits.

[0035] Tool Command Language (TCL): A scripting language widely used in electronic design automation tools. Its core functionality includes variables, flow control, process definition, and interaction with application programs. It is often used to automate IC design processes (such as constraint configuration, simulation control, and file handling).

[0036] In order to enable those skilled in the art to better understand the solutions of the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0037] The technical solution of this invention can be widely applied to the design of high-performance SoC chips, such as communication chips, artificial intelligence chips, and automotive electronic controllers. It is particularly suitable for complex systems with multiple voltage domains, hybrid reset strategies (a combination of asynchronous and synchronous resets), and dynamic clock gating. Through automated script generation, verification cycles can be significantly shortened, effectively solving common industry challenges such as hot reset verification of data center chips and low-power state switching verification of IoT devices.

[0038] For today's large-scale SoC designs, users typically expect each module to have its own independent reset signal, allowing for quick fixes through local resets in the event of SoC malfunctions. However, during top-level module design, signals flowing from one reset domain to another can cause RDC issues, which can be affected by metastability. With the increasing prevalence of technologies like multi-phase power-up / startup sequencing, asynchronous resets are becoming increasingly common, leading to more RDC-related design errors. While RDC errors are generally less common than clock domain crossing errors during SoC design, RDC paths can span long logic links, and any issues can lead to tapeout failures. To prevent metastability caused by RDC errors, RDC verification must be performed early in the chip design process. This allows chip designers to identify potential RDC paths in the design as early as possible and optimize the circuit design in a timely manner. Before SoC tapeout, users face challenges in RDC verification for SoCs: how to quickly establish RDC verification limits and refine constraints to achieve more accurate results.

[0039] During the RDC verification process, constraint setting is crucial for the accuracy of RDC verification results. Inappropriate constraints can lead to false positives, false RDC violations, or even failure to detect real RDC violations. Traditional RDC verification requires users to set up black-box models for modules within the SoC whose internal logic is unknown or whose register conversion-level circuit code has not yet been fully developed. They must also write scripts in a scripting language to describe the boundary conditions of the black-box models. Otherwise, the RDC verification results will contain numerous violations that are not part of the actual RTL design. This means that there are too many false positives to analyze and block, and real RDC design errors can be buried in the sea of ​​false positives. However, manually building black-box models is labor-intensive and time-consuming. Therefore, it is necessary to fully describe the boundary conditions of the black-box models used in RDC verification and develop effective tools to assist chip R&D engineers. This can shift the start of RDC verification to the chip architecture design phase, providing more time for RDC verification.

[0040] In the research and development of SoC chips, RDC verification is one of the scenarios that must be covered. However, in actual testing, RDC errors occur randomly and may cause chip failures that are difficult to detect, reproduce, and debug in the laboratory. Conventional RDC verification only begins in the later stages of RTL code development. Therefore, it is necessary to combine the RDC verification process with the SoC chip development workflow. When the SoC chip architecture definition is completed, the method of this patent can be applied to perform SoC chip RDC verification work, collect necessary RDC constraints, and be able to perform high-level RDC verification as quickly as possible to complete the evaluation of IP performance, system functions or performance indicators to see whether they meet the requirements. Top-level RDC verification is performed in the early stages of SoC chip RTL code development to accelerate the convergence of RDC verification constraints, thereby ensuring the completeness of RDC verification work. At the same time, this method can quickly generate a black box model for RDC verification in the later stages of chip development, remove internal details of modules without RDC risks, and reduce the simulation time of RDC verification.

[0041] An embodiment of the present invention provides a method for generating a script for verifying a cross-reset domain of a system-on-chip. The method is described in detail in conjunction with the execution flow of the method for generating a script for verifying a cross-reset domain of a system-on-chip.

[0042] In this embodiment, a script generation method for verifying the cross-reset domain of a system-level chip is provided, which can be run on a personal computer or a cloud server. Figure 1 FIG. 1 is a flow chart of a method for generating a script for verifying a cross-reset domain of a system-on-chip according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0043] Step S101, obtain the original text, which includes a first code, a second code and a third code. The first code represents the data signal, clock signal and reset signal of the system-level chip, the second code represents the output code obtained by modeling and simulation of the system-level chip, and the third code represents the user-defined cross-reset domain verification condition.

[0044] In the present embodiment, the original text refers to a multi-source input file set for SoC chip design, including a first code, a second code, and a third code. The first code refers to a hardware description code representing a data signal, a clock signal, and a reset signal of the SoC chip. Preferably, the first code is an RTL code, such as Verilog or Verilog Hardware Description Language (HDL). The second code refers to an electronic system-level simulation result code. Preferably, the second code is a simulation output code of an electronic system-level (ESL) model based on SystemC (a language for electronic system-level design based on C++ language), which can operate on the data signal, clock signal, and reset signal of the SoC chip. The third code refers to a user-defined verification rule configuration file. Preferably, the third code is a JS key-value pair data (JavaScript Object Notation, JSON), which is used to describe verification conditions such as cross-reset domain signal synchronization requirements, timing constraint boundaries, etc. According to the prepared first code, second code, and third code as original text, source data is provided for RDC analysis.

[0045] Step S102 , parsing the original text to obtain a structured text, where the structured text includes structured information of a clock signal, a reset signal, and a port of the system-on-chip.

[0046] Structured text refers to a standardized, categorized, and integrated set of raw text that is structured and organized into a collection of chip design data. Preferably, the format of structured text is JSON. This structured text includes structured information about the SoC chip's clock signals, reset signals, and ports. After obtaining the raw text, it is parsed into structured text to extract signal topology relationships, resulting in a unified data interface. This facilitates direct reading of the structured text by electronic design automation (EDA) tools.

[0047] Optionally, in the early stages of chip development, functional modules that need to be reused are first identified, such as cross-clock modules, scheduling arbitration modules, random access memory (RAM) read / write modules, bus interface modules, control logic modules, microprocessors / microcontrollers, digital signal processor modules, embedded memory modules, peripheral interface modules, and bus modules. The RTL code for these modules is then collected and parsed into structured text.

[0048] Optionally, parse the ESL code into structured text, perform syntax analysis on the ESL file using the SystemC language parsing function, build a module mapping model, and confirm the connection descriptions in the Verilog design file. Build a module connection model based on the Verilog design file parsing results, and use JSON text to express the connection relationships between ports and devices, and between devices.

[0049] Optionally, user-defined JSON code contains information about the module's port behavior, including clock signals, reset signals, outputs, inputs, and associated signals. This information structure differs from structured text. Parsing the user-defined JSON code into JSON structured text extracts signal information, primarily clock and reset signals, and port information, and reorganizes it into JSON structured text.

[0050] Step S103 : converting the structured text into a script for verifying the cross-reset domain of the system-on-chip.

[0051] In this embodiment, the script refers to instruction or command text that can be recognized by the RDC checking tool. Preferably, the script is in TCL format. After obtaining the structured text, the structured text is converted into a script that can verify the RDC of the SoC chip using a conversion tool. This enables the automated generation of RDC verification scripts, improving the cross-reset domain verification efficiency of the SoC.

[0052] In this embodiment, a script generation method for verifying the cross-reset domain of a system-level chip is provided, which can be used in the above-mentioned personal computer or cloud server, etc. Figure 2 FIG. 1 is a flow chart of a method for parsing original text into structured text according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0053] Step S201, obtain the original text, which includes a first code, a second code and a third code. The first code represents the data signal, clock signal and reset signal of the system-level chip, the second code represents the output code obtained by modeling and simulation of the system-level chip, and the third code represents the user-defined cross-reset domain verification condition.

[0054] For details, please see Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0055] Step S202 , parsing the original text to obtain a structured text, where the structured text includes structured information of a clock signal, a reset signal, and a port of the system-on-chip.

[0056] Specifically, the above step S202 includes:

[0057] Step S2021 : determining a target binding relationship between a clock signal, a reset signal, and a port of the system-on-chip according to a first code, wherein the first code represents a data signal, a clock signal, and a reset signal of the system-on-chip.

[0058] In this embodiment, the target binding relationship refers to the correspondence between the clock signal and reset signal of the SoC chip and the data signal of the port in the first code, which is expressed using structured text. The first code represents the data signal, clock signal and reset signal of the SoC chip.

[0059] In an exemplary implementation of this embodiment, Figure 3 1 is a schematic diagram of the RTL code parsing process of an embodiment of the present invention. Figure 3 As shown, according to the input RTL code, the module hierarchy is extracted, the reset signals input and output of each functional module of the SoC chip are extracted, and according to the output reset signal, the reset definition point, valid level and other information are extracted to generate a first JSON file. According to the output reset signal name, the reset mode is extracted and a second JSON file is generated. According to the extracted module hierarchy relationship and the input and output reset signals, the reset signal assertion order is extracted and a third JSON file is generated. Among them, the generated first JSON file, second JSON file and third JSON file complete the extraction of reset signal properties. The first JSON file, second JSON file and third JSON file are used to generate a fourth JSON file. According to the input RTL code, the module hierarchy is extracted, the data signals and clock signals of each functional module of the SoC chip are extracted, and according to the data signal information and clock signal information, the relationship between the data signal and the clock signal is extracted. According to the reset signal information and data signal information provided by the fourth JSON file, the relationship between the data signal and the reset signal is extracted. The relationship between the data signal and the clock signal is combined with the relationship between the data signal and the reset signal as the target binding relationship.

[0060] In another exemplary implementation of this embodiment, the clock pins of all registers and latches in the RTL code are traversed, and the stored logical connection relationship is applied to trace the end to which any pin can be connected. For any register input clock pin, the clock input-related path is obtained by querying the connection table until the relevant input port or register output port is reached; the nature of the signal at the end of any pin is determined. If the terminal of the pin is an external interface of the design, the interface is the input of a clock domain; if the terminal is the output of the register, the input clock of the register is traced; if the terminal is a half-latch, the clock path is discarded; the clock domain of the terminal is indexed by the port name to form a list. Multiple attributes of the reset signal can also be identified, such as: the polarity of the signal reset sequential element (high level active or low level active); the reset source, including the main input, derived combination, generated by the reset synchronizer, driven by the non-synthesizable or non-driven network; the output value of the sequential element after reset (set or reset signal).

[0061] In an example of this embodiment, the first code represented by the RTL code is as follows:

[0062]

[0063]

[0064]

[0065] The structured text converted from the first code above is as follows:

[0066]

[0067]

[0068]

[0069] Step S2022: determining a target connection relationship between ports and devices in the system-on-chip according to the second code, where the second code represents an output code obtained by modeling and simulation of the system-on-chip.

[0070] In this embodiment, the target connection relationship refers to the connection relationship between the ports and devices of the SoC chip, represented by the second code using structured text. The second code refers to the output code obtained through modeling and simulation of the SoC chip. After obtaining the second code, the connection relationship between the ports and devices in the SoC chip can be analyzed based on the port information in the second code.

[0071] In one example of this embodiment, the ESL file is parsed according to the parsing module of the SystemC language, a module mapping model is established, the description of the connection method in the Verilog design file is confirmed, and a module connection model is established according to the parsing result of the Verilog design file to express the connection relationship between ports and devices, and between devices.

[0072] In an exemplary implementation of this embodiment, Python's subprocess module is used to call a SystemC simulation tool (such as sc_sim) and capture its output, while Python's string processing function is used to parse the module structure and signal connections. The following is a Python-based implementation method, and the specific implementation steps are as follows:

[0073] a) Call the SystemC simulation tool, use the subprocess module to run the SystemC simulation, and capture the output; use the SystemC internal audit function to print the module hierarchy and port connection information.

[0074] b) Parse the output and extract information. Use regular expressions or other string processing methods to parse the simulation output. Extract module names, port connections, clock signals (CLK), and reset signals (RST).

[0075] c) Establish a module mapping model and use Python data structures (such as dictionaries and lists) to store module hierarchies and signal connection information. Store the parsing results in JSON format or other suitable formats.

[0076] d) Output the results, print the parsing results to the console or save them to a file.

[0077] In one example of this embodiment, Figure 4 FIG. 1 is a flow chart of parsing the second code according to an embodiment of the present invention. Figure 4 As shown, start the SystemC simulation tool and check whether the simulation is successful. If the simulation is successful, capture the simulation output. Otherwise, print an error message and exit. After capturing the simulation output, parse it to extract the modules, ports, clock signal CLK, and reset signal RST. Build a module mapping model and store the model in JSON format. Print or save the JSON result to complete the parsing. The JSON result records the target connection relationship.

[0078] Step S2023: Obtain a target constraint relationship defined by the user in the third code, where the target constraint relationship indicates a behavior of the port.

[0079] A target constraint relationship is a user-defined, structured description of the behavior that limits or constrains the port behavior of a specific module on an SoC chip. When setting verification boundary conditions for target binding relationships and target connection relationships and selecting target ports on the SoC chip for verification, these boundary conditions can be defined using a third code. This third code is user-defined based on requirements.

[0080] In one example of this embodiment, the third code describes the port behavior of the module in JSON format as follows:

[0081]

[0082] Step S2024: Merge the target binding relationship, target connection relationship, and target constraint relationship into structured text.

[0083] According to the corresponding data labels of the target binding relationship, target connection relationship and target constraint relationship, they are fused into structured text.

[0084] In some optional implementations, the above step S2024 includes:

[0085] Step a1: According to the priority rules, the target binding relationship, the target connection relationship and the target constraint relationship are merged into a structured text, wherein the priority of the priority rules is target constraint relationship, target binding relationship and target connection relationship from high to low.

[0086] In this embodiment, the priority rule refers to the order in which the target binding relationship, target connection relationship and target constraint relationship are processed. Among them, the priority of the priority rule is target constraint relationship, target binding relationship and target connection relationship from high to low. According to the user-defined target constraint relationship for the port behavior of the SoC chip, the search and construction scope of the target binding relationship and the target connection relationship can be narrowed. The data signal, clock signal and port relationship defined by the target binding relationship are processed after the target constraint relationship is processed, which can narrow the search scope of the connection between devices in the target connection relationship, further improve the fusion efficiency of processing structured text, and achieve higher flexibility.

[0087] Specifically, the priority rules can also assign priorities based on the weight values ​​determined by the target binding relationships, target connection relationships, and target constraint relationships for the success rate of RDC verification. For example, using the organized target binding relationships, target connection relationships, and target constraint relationships and the results of RDC verification as training samples, a deep neural network is trained through deep learning to calculate the weight values ​​of the target binding relationships, target connection relationships, and target constraint relationships as priorities. Those with larger weights have higher priorities, and those with smaller weights have lower priorities.

[0088] Step S203 : converting the structured text into a script for verifying the cross-reset domain of the system-on-chip.

[0089] In this embodiment, the structured text is converted into a script for verifying the RDC of the SoC chip. Optionally, the JSON code is converted into a TCL script, and a Python script is used to convert the JSON file into a TCL script that can be recognized by the RDC checking tool. The structured text of the JSON file example is as follows:

[0090]

[0091]

[0092] The TCL script generated by the above structured text for verifying RDC is as follows:

[0093] set_constraints_scope-module MODULE_A

[0094] define_attribute-name path0

[0095] set_reset_attribute path0-reset_objects rst0

[0096] set_clock_attribute path0-clock_objects clk1

[0097] apply_attribute path0-objects{in1}

[0098] define_attribute-name path1

[0099] set_reset_attribute path1-reset_objects{rst1 rst2}

[0100] set_clock_attribute path1-clock_objects clk1

[0101] apply_attribute path1-objects{in2}

[0102] define_attribute-name path2

[0103] set_connectivity_attribute path2-path_type combo-related_ports in3

[0104] apply_attribute path2-objects{out3}

[0105] define_attribute-name path3

[0106] set_reset_attribute path3-reset_objects rst0

[0107] set_clock_attribute path3-clock_objects clk1

[0108] apply_attribute path3-objects{out1}

[0109] define_attribute-name path4

[0110] set_reset_attribute path4-reset_objects{rst1 rst2}

[0111] set_clock_attribute path4-clock_objects clk1

[0112] apply_attribute path4-objects{out2}

[0113] define_attribute-name path5

[0114] set_clock_attribute path5-clock_objects clk1

[0115] apply_attribute path5-objects{rst0 rst1 rst2}

[0116] end_constraints_scope

[0117] By using the method of this embodiment, the original text is parsed into structured text, thereby realizing the automated structured integration of the reset domain design data of the SoC chip and improving the extraction efficiency and accuracy of the RDC verification information.

[0118] In this embodiment, a script generation method for verifying the cross-reset domain of a system-level chip is provided, which can be used in the above-mentioned personal computer or cloud server, etc. Figure 5 is a flow chart of a method for converting structured text into a script for verifying RDC of a SoC chip according to an embodiment of the present invention, as shown in FIG. Figure 5 As shown, the process includes the following steps:

[0119] Step S501, obtain the original text, which includes a first code, a second code and a third code. The first code represents the data signal, clock signal and reset signal of the system-level chip, the second code represents the output code obtained by modeling and simulation of the system-level chip, and the third code represents the user-defined cross-reset domain verification condition.

[0120] For details, please see Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0121] Step S502 , parsing the original text to obtain a structured text, wherein the structured text includes structured information of a clock signal, a reset signal, and a port of the system-on-chip.

[0122] For details, please see Figure 2 Step S202 of the illustrated embodiment will not be described in detail here.

[0123] Step S503 : converting the structured text into a script for verifying the cross-reset domain of the system-on-chip.

[0124] Specifically, the above step S503 includes:

[0125] Step S5031: parse the structured text to obtain a structured text parsing result.

[0126] In this embodiment, after the original text is parsed into the structured text, the port information, clock signal, and reset signal of the module of the SoC chip are extracted from the structured text as the structured text parsing result.

[0127] Step S5032: construct a clock tree and a reset tree of the SoC based on the structured text parsing result. The clock tree represents the path of clock signals distributed to the functional modules of the SoC, and the reset tree represents the path of reset signals distributed to the functional modules of the SoC.

[0128] In this embodiment, the clock tree refers to the physical distribution path of the internal clock signal of the SoC chip from the source (such as a phase-locked loop, crystal oscillator) to the functional module (all target modules and registers). Its design goal is to minimize clock skew and jitter and ensure that all logic units in the clock domain work synchronously. The reset tree refers to the transmission path of the reset signal from the reset source to the controlled functional module, which is used to initialize the circuit state. It is necessary to ensure that the reset signal is effectively released at the timing to avoid metastable states. The clock tree of the SoC chip is constructed based on the clock signal data of the structure text parsing result; the reset tree of the SoC chip is constructed based on the reset signal data of the structure text parsing result.

[0129] Step S5033 , verifying the clock tree, reset tree, ports and functional modules. If the clock tree, reset tree, ports and functional modules pass the verification, a script for verifying the cross-reset domain of the system-on-chip is generated based on the structured text parsing result.

[0130] In this embodiment, the clock tree, reset tree, ports, and functional modules are verified for correctness. The clock and reset signals are verified for integrity, synchronization, stability, and pointing. The integrity and synchronization of the ports, as well as the integrity of the functional module definitions, are verified. If the clock tree, reset tree, ports, and functional module definitions pass verification, a script is generated using a script generation tool based on the structured text parsing results to verify the RDC of the SoC chip.

[0131] Optionally, the integrity of the clock and reset signals refers to the functional modules of the SoC chip, that is, all modules and registers can correctly receive the clock and reset signals; the synchronization of the clock and reset signals refers to the synchronization of the clock and reset signals in the target clock domain; the stability of the clock and reset signals refers to the stability of the clock and reset signals in the design without unnecessary jitter; the above integrity, synchronization, and stability checks all point to the reset source, and display the path from the reset source to the trigger it uses in the form of a circuit.

[0132] In some optional implementations, the above step S5032 includes:

[0133] Step b1: extracting clock signals and reset signals of functional modules of the system-on-chip from the structured text parsing results.

[0134] In this embodiment, the clock signals and reset signals of the functional modules of the SoC chip are extracted from the structured text parsing results. For example, the clocks field and resets field are extracted from the JSON file as the basis for constructing the clock tree and reset tree.

[0135] Step b2: determine the clock source of the clock signal, the first target module and / or first target register to which the clock signal is distributed, and the clock buffer through which the clock signal passes from the clock source to the first target module and / or first target register.

[0136] In this embodiment, the first target module refers to the functional module of the SoC chip to which the clock signal is distributed. The first target register refers to the register of the SoC chip to which the clock signal is distributed. The clock buffer is a signal amplifier used to enhance and optimize the transmission of the clock signal. Based on the clock signal extracted from the structured text parsing result, the source of the clock signal is determined as the clock source, for example, a phase-locked loop or an on-chip crystal oscillator; how the clock signal is distributed to the various modules and registers of the functional module is analyzed to determine the first target module and / or the first target register. The clock buffer is obtained by taking into account the buffers and gated logic circuits that the clock signal may pass through during the distribution process.

[0137] Step b3: obtaining the time difference between the clock signal and the different registers in the system-on-chip, and taking the time duration when the time difference is less than or equal to the time difference threshold as the clock skew value.

[0138] In this embodiment, the time difference between the clock signal reaching different registers in the SoC chip is obtained, and the time difference is verified to be within an acceptable range. The time duration during which the time difference is less than or equal to the time difference threshold is used as the clock skew value of the clock tree.

[0139] Step b4: constructing a clock tree according to the clock source, the first target module and / or the first target register, the clock buffer and the clock skew value.

[0140] A clock tree of the SoC chip is constructed according to the clock source, the first target module and / or the first target register, the clock buffer, and the clock skew value.

[0141] Step b5: construct a reset tree using the attribute information of the reset signal, where the attribute information includes the reset source, delay duration, reset synchronizer, and reset function module of the reset signal.

[0142] The reset signal attribute information includes the reset source, delay duration, reset synchronizer, and reset function module. Using the reset signal attribute information, the reset tree of the SoC chip can be constructed.

[0143] Through this implementation, a high-precision clock tree structure is constructed, providing reference clock information for cross-reset domains.

[0144] In an optional implementation, the above step b5 includes:

[0145] Step c1: determining a reset source and a second target module and / or a second target register to which the reset signal is distributed.

[0146] In this embodiment, the second target module refers to a functional module of the SoC chip to which the reset signal is distributed. The second target register refers to a register of the SoC chip to which the reset signal is distributed.

[0147] Step c2: If the reset signal is an asynchronous reset signal, a reset synchronizer is inserted into the reset signal to synchronize the clock signal.

[0148] In this embodiment, if the reset signal is an asynchronous reset signal, a reset synchronizer needs to be inserted into the reset signal to ensure that the reset signal is synchronized in the target clock domain.

[0149] Step c3: Obtain the delay duration. If the delay duration is less than or equal to the delay threshold, use the delay duration as the target delay time.

[0150] In this embodiment, the delay duration of the reset signal is obtained from the information of the reset signal to ensure that the delay duration of the reset signal is short enough, that is, the delay duration is less than or equal to the delay threshold, and then the delay duration is used as the target delay time to complete the reset operation within the clock cycle.

[0151] Step c4: constructing a reset tree according to the reset source, the second target module and / or the second target register, the reset synchronizer, and the target delay time.

[0152] In this embodiment, a reset tree of the SoC chip is constructed according to attribute information such as a reset source, a second target module and / or a second target register, a reset synchronizer, and a target delay time.

[0153] Through this implementation, a refined reset tree structure is constructed, which can analyze the timing margin at the clock domain boundary in detail, providing a key timing basis for reset synchronization verification of RDC.

[0154] In an optional implementation, the above step S3033 includes:

[0155] Step d1: Perform a format check on the reset signal of the reset tree. If the reset format condition is met, generate a first constraint script.

[0156] In this embodiment, the reset format condition indicates that the information of the reset signal of the SoC chip can be converted into the conditions that need to be met by the script for verifying the RDC, including ensuring that each reset signal is correctly connected to all registers that need to be reset to ensure the integrity of the reset signal, ensuring that all reset signals are synchronized in the target clock domain to ensure the synchronization of the reset signal, ensuring that the polarity of the reset signal is consistent throughout the design, and ensuring that the source of the reset signal is consistent throughout the design. Ensure that the delay of the reset signal is consistent throughout the design. Optionally, check the resets field in the JSON to ensure that each reset signal is correctly assigned to all relevant ports and registers; check the resets field in the JSON to ensure that each reset signal passes through the reset synchronizer; check the resets field in the JSON to ensure that the polarity of all reset signals (high level active or low level active) is consistent; check the resets field in the JSON to ensure that the source of all reset signals (such as external input, internal generation, etc.) is consistent; check the resets field in the JSON to ensure that the delay of all reset signals (such as synchronizer delay) is consistent. If the reset signal of the reset tree meets the reset format condition, then a first constraint script is generated through a text conversion tool. The first constraint script represents the verification script for the reset signal used for RDC verification.

[0157] Step d2: Perform a format check on the clock signal of the clock tree. If the clock format condition is met, generate a second constraint script.

[0158] In this embodiment, the clock format condition indicates that the information of the clock signal of the SoC chip can be converted into the conditions that need to be met by the script for verifying the RDC, including ensuring that each clock signal is correctly connected to all registers that require clocks and ensuring that all clock signals are synchronized in the target clock domain. Optionally, the clocks field in the JSON is checked to ensure that each clock signal is correctly distributed to all related ports and registers; the clocks field in the JSON is checked to ensure that each clock signal passes through the necessary clock synchronization logic. If the clock signal of the clock tree meets the clock format condition, a second constraint script is generated, wherein the second constraint script represents a script of verification instructions for the clock signal used for RDC verification.

[0159] Step d3: Perform format check on the ports and functional modules. If the check format is satisfied, generate a third constraint script.

[0160] In this embodiment, the ports and functional modules are format checked to check the integrity and synchronization of the ports and the integrity of the module definition. Optionally, the ports field in the JSON is checked to ensure that each port is correctly connected to the clock and reset signals to check the integrity of the port; the ports field in the JSON is checked to ensure that each port has passed the necessary synchronization logic to check the synchronization of the port; the module name (module_name) field in the JSON is checked to ensure that the module name of the functional module is correct and contains all necessary port, clock and reset signal information to ensure the integrity of the functional module definition. If the ports and sub-modules of the functional module are format checked and all meet the check format, then a third constraint script is generated. The check format refers to checking the constraints of the ports and functional modules. The third constraint script is used to represent the relevant script commands of the ports and functional modules in the RDC verification.

[0161] Step d4: merge the first constraint script, the second constraint script, and the third constraint script into a script for verifying the cross-reset domain of the system-on-chip.

[0162] In this embodiment, according to the corresponding fields in the first constraint script, the second constraint script, and the third constraint script, they are merged into a script for verifying the RDC of the SoC chip.

[0163] This implementation verifies the clock tree, reset tree, ports, and modules, generating a TCL script that can be recognized by the RDC checker. This significantly reduces the time and workload required for RDC verification and improves the RDC verification efficiency of SoC chips.

[0164] In this embodiment, a script generation method for verifying the cross-reset domain of a system-level chip is provided, which can be used in a personal computer or a cloud server, etc. Figure 6 is a flowchart of a method for generating a verification report using a script for verifying an RDC of a SoC chip according to an embodiment of the present invention. Figure 6 As shown, the process includes the following steps:

[0165] Step S601, obtain the original text, which includes a first code, a second code and a third code. The first code represents the data signal, clock signal and reset signal of the system-level chip, the second code represents the output code obtained by modeling and simulation of the system-level chip, and the third code represents the user-defined cross-reset domain verification condition.

[0166] For details, please see Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0167] Step S602 , parsing the original text to obtain a structured text, where the structured text includes structured information of a clock signal, a reset signal, and a port of the system-on-chip.

[0168] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0169] Step S603 : converting the structured text into a script for verifying the cross-reset domain of the system-on-chip.

[0170] For details, please see Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0171] Step S604 : performing cross-reset domain verification on the system-on-chip using a cross-reset domain verification script of the system-on-chip, and generating a verification report.

[0172] In this embodiment, the verification report refers to output information indicating the RDC verification results, such as whether there is a metastability risk or not. Using the obtained RDC verification script for the SoC chip, verification software or tools are used to perform cross-reset domain verification on the SoC chip. A verification report is generated to indicate the verification results, providing data reference for RDC verification fault cause analysis. Optionally, the RDC verification tool can be Synopsys VC SpyGlass@RDC.

[0173] In one implementation of this embodiment, Figure 7 FIG. 1 is a flow chart of an RDC verification method according to an embodiment of the present invention. Figure 7 As shown, in the standard RDC verification process, a netlist file describing the connection relationship of circuit elements and an RTL code in a hardware description language are used to perform RDC verification, and the constraints in the verification are collected to generate a first RDC verification report. This solution collects user-defined JSON code, SysC (SystemC) code, and RTL code, and generates an RDC verification script (such as a TCL script) through a black box model automatic generation device (verification script generation module), making the RDC verification process more efficient and accurate. The RDC verification script is used to perform RDC verification and generate a first RDC verification report. The first RDC verification report is noise-shielded and constraint conditions are collected. The rationality of the results of the first RDC verification report is judged. If the results of the verification report are reasonable, a second RDC verification report is generated. Otherwise, the TCL script, netlist file, and RTL file are re-checked and re-verified using the RDC verification script to ensure the reliability of the verification results.

[0174] In this embodiment, a script generation method for verifying the cross-reset domain of a system-level chip is provided, which can be used in the above-mentioned personal computer or cloud server, etc. Figure 8 FIG. 1 is a flow chart of a method for automatically generating a black box model according to an embodiment of the present invention. Figure 8 As shown, manually collected ESL code is input into the SysC language parsing module, and a JSON file is generated through the JSON code generation module. RTL code is input into the RTL language parsing module, and JSON code is generated through the JSON code generation module. Simultaneously, user-defined JSON code is input into the JSON code generation module to generate a unified structured JSON text. Based on the clock and reset signals recorded in the structured JSON text, the clock tree and reset tree are generated through the clock tree and reset tree inference module. The clock tree and reset tree are verified using the verification module, and the clock tree and reset tree that meet the verification conditions are parsed into JSON text through the JSON code parsing module. The JSON text is then output into black box model code through the TCL code generation module, that is, a script for verifying the RDC is generated. This achieves automated generation of RDC verification scripts for SoC chips, improving the efficiency of RDC verification of SoC chips.

[0175] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0176] The embodiment of the present invention also provides a script generation device for verifying the cross-reset domain of the system-level chip, such as Figure 9 As shown, the device includes:

[0177] Acquisition module 901 is used to obtain original text, which includes a first code, a second code and a third code. The first code represents the data signal, clock signal and reset signal of the system-level chip, the second code represents the output code obtained by modeling and simulation of the system-level chip, and the third code represents the user-defined cross-reset domain verification condition.

[0178] The parsing module 902 is configured to parse the original text to obtain a structured text, where the structured text includes structured information of the clock signal, reset signal, and port of the system-on-chip.

[0179] The conversion module 903 is configured to convert the structured text into a script for verifying the cross-reset domain of the system-on-chip.

[0180] In some optional implementations, the parsing module includes:

[0181] a binding relationship determining unit, configured to determine a target binding relationship between a clock signal, a reset signal, and a port of the system-on-chip according to a first code, wherein the first code represents a data signal, a clock signal, and a reset signal of the system-on-chip;

[0182] a connection relationship determining unit, configured to determine a target connection relationship between a port and a device in the system-on-chip according to a second code, wherein the second code represents an output code obtained by modeling and simulation of the system-on-chip;

[0183] A constraint relationship obtaining unit, configured to obtain a target constraint relationship defined by a user in the third code, where the target constraint relationship indicates a behavior of a port;

[0184] The relationship fusion unit is used to fuse the target binding relationship, target connection relationship and target constraint relationship into structured text.

[0185] In an optional implementation, the relationship fusion unit includes:

[0186] The fusion subunit is used to fuse the target binding relationship, target connection relationship and target constraint relationship into structured text according to the priority rules, wherein the priority of the priority rules is target constraint relationship, target binding relationship and target connection relationship from high to low.

[0187] In some optional implementations, the conversion module includes:

[0188] A text parsing unit, used to parse the structured text and obtain the structured text parsing result;

[0189] A construction unit, configured to construct a clock tree and a reset tree of the system-on-chip according to the structured text parsing result, wherein the clock tree represents a path for distributing clock signals to functional modules of the system-on-chip, and the reset tree represents a path for distributing reset signals to functional modules of the system-on-chip;

[0190] The verification script generation unit is used to verify the clock tree, reset tree, port and functional module. If the clock tree, reset tree, port and functional module are verified, a script for verifying the cross-reset domain of the system-level chip is generated based on the structured text parsing results.

[0191] In some optional embodiments, the building block comprises:

[0192] A signal extraction subunit, used to extract clock signals and reset signals of functional modules of the system-level chip from the structured text parsing results;

[0193] a first determining subunit, configured to determine a clock source of a clock signal, a first target module and / or a first target register to which the clock signal is distributed, and a clock buffer through which the clock signal passes from the clock source to the first target module and / or the first target register;

[0194] A time difference acquisition subunit is used to obtain the time difference between the clock signal reaching different registers in the system-level chip, and the duration during which the time difference is less than or equal to the time difference threshold is used as the clock skew value;

[0195] A clock tree construction subunit, configured to construct a clock tree according to a clock source, a first target module and / or a first target register, a clock buffer, and a clock skew value;

[0196] The reset tree construction subunit is used to construct a reset tree using the attribute information of the reset signal. The attribute information includes the reset source, delay duration, reset synchronizer, and reset function module of the reset signal.

[0197] In some optional implementations, the reset tree construction subunit is configured to:

[0198] determining a reset source and a second target module and / or a second target register to which the reset signal is distributed;

[0199] If the reset signal is an asynchronous reset signal, a reset synchronizer is inserted into the reset signal to synchronize the clock signal;

[0200] Get the delay duration. If the delay duration is less than or equal to the delay threshold, use the delay duration as the target delay time.

[0201] A reset tree is constructed according to a reset source, a second target module and / or a second target register, a reset synchronizer, and a target delay time.

[0202] In some optional implementations, the verification script generation unit includes:

[0203] a first checking subunit, configured to perform a format check on the reset signal of the reset tree, and generate a first constraint script if the reset format condition is met;

[0204] The second checking sub-unit is used to perform a format check on the clock signal of the clock tree, and generate a second constraint script if the clock format condition is met;

[0205] The third checking subunit is used to perform format checking on the ports and functional modules, and generate a third constraint script if the checking conditions are met;

[0206] The script merging subunit is used to merge the first constraint script, the second constraint script and the third constraint script into a script for verifying the cross-reset domain of the system-on-chip.

[0207] In some optional implementations, the conversion module further includes:

[0208] The verification report generating unit is used to perform cross-reset domain verification on the system-on-chip by using a script for verifying the cross-reset domain of the system-on-chip, and generate a verification report.

[0209] For the description of the features in the embodiment corresponding to the script generation device for verifying the cross-reset domain of the system-level chip, please refer to the relevant description of the embodiment corresponding to the script generation method for verifying the cross-reset domain of the system-level chip, which will not be repeated here.

[0210] An embodiment of the present invention further provides an electronic device, such as Figure 10 As shown, it includes a memory 10 and a processor 20, wherein the memory 10 stores a computer program, and the processor 20 is configured to run the computer program to execute the steps in any of the above-mentioned embodiments of the script generation method for verifying the cross-reset domain of the system-level chip.

[0211] An embodiment of the present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned script generation method embodiments for verifying the cross-reset domain of the system-level chip when running.

[0212] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0213] An embodiment of the present invention further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned script generation method embodiments for verifying the cross-reset domain of a system-on-chip are implemented.

[0214] An embodiment of the present invention also provides another computer program product, including a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, implementing the steps of any of the above-mentioned script generation method embodiments for verifying the cross-reset domain of the system-level chip.

[0215] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0216] The above is a detailed introduction to the script generation method, device, electronic device, computer-readable storage medium and computer program product for verifying the cross-reset domain of the system-level chip provided by the present invention. This article uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, the present invention can also be improved and modified. These improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. A script generation method for verifying cross-reset domain of a system-on-chip, characterized in that: The method comprises: Obtaining an original text, the original text including a first code, a second code, and a third code, wherein the first code represents a data signal, a clock signal, and a reset signal of the system-on-chip; the second code represents an output code obtained by modeling and simulation of the system-on-chip; and the third code represents a user-defined cross-reset domain verification condition; Parsing the original text to obtain a structured text, wherein the structured text includes structured information of a clock signal, a reset signal, and a port of the system-on-chip; The structured text is converted into a script for verifying the cross-reset domain of the system-on-chip.

2. The method according to claim 1, characterized in that Parsing the original text to obtain structured text includes: determining, according to the first code, a target binding relationship between a clock signal, a reset signal, and a port of the system-on-chip; determining, according to the second code, a target connection relationship between ports and devices in the system-on-chip; Obtaining a target constraint relationship defined by a user in the third code, where the target constraint relationship indicates a behavior of the port; The target binding relationship, the target connection relationship and the target constraint relationship are merged into the structured text.

3. The method according to claim 2, characterized in that Merging the target binding relationship, the target connection relationship, and the target constraint relationship into the structured text includes: According to the priority rules, the target binding relationship, the target connection relationship and the target constraint relationship are merged into the structured text, wherein the priorities of the priority rules are, from high to low, the target constraint relationship, the target binding relationship and the target connection relationship.

4. The method according to claim 1, wherein The converting of the structured text into a script for verifying the cross-reset domain of the system-level chip includes: Parsing the structured text to obtain a structured text parsing result; Constructing a clock tree and a reset tree of the system-on-chip according to the structured text parsing result, wherein the clock tree represents a path for distributing the clock signal to the functional modules of the system-on-chip, and the reset tree represents a path for distributing the reset signal to the functional modules; The clock tree, the reset tree, the port and the functional module are verified. If the clock tree, the reset tree, the port and the functional module are verified, a script for verifying the cross-reset domain of the system-on-chip is generated according to the structured text parsing result.

5. The method according to claim 4, characterized in that The step of constructing a clock tree and a reset tree of the system-on-chip according to the structured text parsing result includes: Extracting the clock signal and reset signal of the functional module from the structured text parsing result; Determine a clock source of the clock signal, a first target module and / or a first target register to which the clock signal is distributed, and a clock buffer through which the clock signal passes from the clock source to the first target module and / or the first target register; Obtaining a time difference between the clock signal arriving at different registers in the system-on-chip, and taking a duration during which the time difference is less than or equal to a time difference threshold as a clock skew value; constructing the clock tree according to the clock source, the first target module and / or the first target register, the clock buffer, and the clock skew value; The reset tree is constructed using attribute information of the reset signal, where the attribute information includes a reset source of the reset signal, a delay duration, a reset synchronizer, and the reset functional module.

6. The method according to claim 5, characterized in that The constructing the reset tree by using the attribute information of the reset signal includes: determining the reset source and a second target module and / or a second target register to which the reset signal is distributed; If the reset signal is an asynchronous reset signal, inserting the reset synchronizer into the reset signal to synchronize the clock signal; Obtain the delay duration, and if the delay duration is less than or equal to the delay threshold, use the delay duration as the target delay time; The reset tree is constructed according to the reset source, the second target module and / or the second target register, the reset synchronizer, and the target delay time.

7. The method according to claim 4, characterized in that If the clock tree and the reset tree are verified, a script for verifying the cross-reset domain of the system-on-chip is generated according to the structured text parsing result, including: Performing a format check on the reset signal of the reset tree, and generating a first constraint script if the reset format condition is met; Performing a format check on the clock signal of the clock tree, and generating a second constraint script if the clock format condition is met; Performing format check on the port and the functional module, and generating a third constraint script if the check conditions are met; The first constraint script, the second constraint script, and the third constraint script are merged into a script for verifying the cross-reset domain of the system-on-chip.

8. The method according to any one of claims 1 to 7, characterized in that After converting the structured text into a script for verifying the cross-reset domain of the system-level chip, the method further includes: The cross-reset domain verification of the system-on-chip is performed on the system-on-chip using a script for verifying the cross-reset domain of the system-on-chip, and a verification report is generated.

9. A script generation device for verifying cross-reset domain of a system-on-chip, characterized in that: The device comprises: an acquisition module, configured to acquire original text, the original text including a first code, a second code, and a third code, wherein the first code represents a data signal, a clock signal, and a reset signal of the system-on-chip; the second code represents an output code obtained by modeling and simulation of the system-on-chip; and the third code represents a user-defined cross-reset domain verification condition; A parsing module, configured to parse the original text to obtain a structured text, wherein the structured text includes structured information of a clock signal, a reset signal, and a port of the system-on-chip; A conversion module is used to convert the structured text into a script for verifying the cross-reset domain of the system-on-chip.

10. An electronic device, characterized in that: include: Memory for storing computer programs; A processor is configured to implement the steps of the method for generating a script for verifying a cross-reset domain of a system-on-chip as claimed in any one of claims 1 to 8 when executing the computer program.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the script generation method for verifying the cross-reset domain of the system-on-chip according to any one of claims 1 to 8 are implemented.

12. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the script generation method for verifying the cross-reset domain of the system-on-chip are implemented as claimed in any one of claims 1 to 8.

Images