A chip simulation and test method and device, electronic equipment and storage medium

Abstract

The application discloses a chip simulation and test method and device, electronic equipment and storage medium, and relates to the field of chip development, and comprises the following steps: in the chip simulation stage, an excitation file received is parsed to obtain keywords corresponding to each subsequence; for each subsequence, a simulation instruction is generated according to the keywords, and the simulation instruction is executed through a corresponding access port to perform chip simulation; in the chip test stage, a test file is obtained by translating the operation type based on a test library; and the test file is executed on the chip to actually test the simulated chip. By introducing a dynamically updatable excitation file, repeated modification of simulation code when updating the scene is avoided, and the test file required in the test stage is automatically generated based on the excitation file, so that single-source reuse of simulation and test is realized, which not only greatly improves the flexibility and development efficiency of the verification scene construction, but also effectively guarantees the coverage and reliability of the chip from design to test.

Description

Technical Field

[0001] This invention relates to the field of chip development technology, and in particular to a chip simulation and testing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of artificial intelligence and high-performance computing, the development of existing chips faces unprecedented design complexity. A single chip often instantiates multiple memory controllers in parallel, each interfacing with memory chips of different generations and protocols, and exposing them to the upper-layer on-chip interconnect via multiple ports. To address this multi-generational, multi-protocol, multi-instance, multi-port, and multi-rate chip design, the Universal Verification Methodology (UVM) verification platform needs to handle massive amounts of regression testing and be reused across multiple stages, including simulation, netlisting, prototyping, and post-silicon testing. The simulation and testing stages, in particular, play a crucial role in chip quality.

[0003] Currently, when simulating chips, the stimulus content is hard-coded into the code. When the scenario needs to be modified, the code needs to be recompiled, which makes the development and debugging cycle too long and increases the workload of developers. Two sets of stimulus code are used in the simulation and testing phases. During the parallel evolution of the two sets of code, it is very easy for the scenario covered by the simulation to be not covered by the test or vice versa, which brings huge risks to chip debugging. Summary of the Invention

[0004] This invention provides a method, apparatus, electronic device, and storage medium for simulating and testing chips, thereby enabling accurate simulation and testing of chips and improving chip quality.

[0005] According to a first aspect of the present invention, a method for simulating and testing a chip is provided, the method comprising: parsing a received stimulus file during the chip simulation stage to obtain keywords corresponding to each subsequence; For each subsequence, simulation instructions are generated based on the keywords, and the simulation instructions are executed by calling the corresponding access port to perform chip simulation. During the chip testing phase, the operation type corresponding to the keyword is obtained, and the operation type is translated based on the test library to obtain the test file; The test file is executed on the chip to perform actual testing on the simulated chip.

[0006] According to another aspect of the present invention, a chip simulation and testing apparatus is provided, the apparatus comprising: an stimulus file parsing module, configured to parse a received stimulus file during the chip simulation phase to obtain keywords corresponding to each subsequence; The chip simulation module is used to generate simulation instructions for each sub-sequence based on the keywords, and to execute the simulation instructions by calling the corresponding access port to perform chip simulation. The test file acquisition module is used to acquire the operation type corresponding to the keyword during the chip testing phase, and to translate the operation type based on the test library to obtain the test file; A chip testing module is used to execute the test file on the chip to perform actual testing on the simulated chip.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: one or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any embodiment of the present invention.

[0008] According to another aspect of the present invention, a storage medium for computer-executable instructions is provided, on which a computer program is stored, which, when executed by a processor, implements the method as described in any of the embodiments of the present invention.

[0009] The technical solution of this invention avoids repeated modifications to the simulation code when the scenario is updated by introducing a dynamically updatable stimulus file, which reduces the workload of developers. Furthermore, it automatically generates the test files required for the testing phase based on the stimulus file, thereby realizing single-source reuse for simulation and testing. This fundamentally eliminates the risk of inconsistency between pre- and post-verification caused by maintaining two sets of stimulus code. This not only greatly improves the flexibility and development efficiency of verification scenario construction, but also more effectively ensures the coverage and reliability of the chip from design to testing.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0012] Figure 1 This is a flowchart of a chip simulation and testing method provided according to Embodiment 1 of the present invention; Figure 2This is a flowchart of another chip simulation and testing method provided according to Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the structure of a chip simulation and testing device provided according to Embodiment 3 of the present invention; Figure 4 This is a structural block diagram of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

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

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, apparatus, product, or terminal device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or terminal devices.

[0015] Example 1 Figure 1 This is a flowchart of a chip simulation and testing method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations involving chip simulation and testing. The method can be executed by a chip simulation and testing device, which can be implemented in hardware and / or software, and can be integrated into an electronic device with data processing capabilities. Figure 1 As shown, the method includes: S101, during the chip simulation stage, parses the received stimulus file to obtain the keywords corresponding to each subsequence.

[0016] Optionally, during the chip simulation phase, the received stimulus file is parsed to obtain the keywords corresponding to each sub-sequence. This includes: starting a sequence container in the upper-layer concurrent orchestration parser to perform parsing work during the chip simulation phase; and parsing the received stimulus file through the sequence container to obtain the keywords corresponding to each sub-sequence, wherein the keywords include configuration keywords and action keywords.

[0017] Specifically, in this embodiment, during the chip testing phase, a stimulus file in plain text format written by the user is received. The system parses the received stimulus file through an upper-layer concurrent orchestration parser. Specifically, the sequence container in the upper-layer concurrent orchestration parser is started to perform the parsing work, and the sequence container is used to parse the stimulus file to obtain the keywords corresponding to each sub-sequence. The keywords specifically include configuration keywords and action keywords. For example, the configuration keywords include set_seq. <name> <param> <value>This keyword configures the parameters of the created subsequence in string form, where `name` represents the name of the subsequence and `param` represents the specific parameters configured, which are scenario-dependent and can be dynamically updated as needed; action keywords include: `add_seq`. <name> <type>、start_seq <name>、 wait_seq <name>、stop_seq <name>、del_seq <name>、delay <val> <unit>and include <file>Among them, add_seq <name> <type>This indicates that a subsequence object is created in the container with the string "name". The subsequence type "type" is dynamically instantiated through the UVM factory. `start_seq` <name>This indicates that the subsequence is started using the `fork...join_none` method, which is non-blocking; `wait_seq` <name>`stop_seq` indicates blocking and waiting for the subsequence with the specified name to finish; <name>This indicates that the specified subsequence is actively stopped; del_seq <name>, indicates the deletion of a subsequence from the container; delay <val> <unit>This indicates that a main process level delay is inserted in ns / ps; include <file>This indicates that the inline contains another .tf file, supporting modular reuse. Furthermore, the keywords parsed in this implementation can be for multiple sub-sequences, specifically determined by the name of each keyword. This implementation does not limit the specific content of the parsed keywords, and each of the aforementioned sub-sequences corresponds to a simulation task of a memory controller in the chip. This implementation does not limit the number of parsed sub-sequences; it is specifically related to the number of memory controllers included in the chip to be designed.

[0018] Optionally, the method also includes: constructing an associative array indexed by strings based on the parsed subsequences through an upper-level concurrent orchestration parser; constructing a running status bit array that matches the associative array, wherein the running status bit array is used to record the running status of each subsequence.

[0019] Specifically, in this implementation, the upper-layer concurrent orchestration parser constructs an associative array `trans_seq_t seq_dict[string]` indexed by the string `name`. This associative array contains all the subsequences obtained from the parsing. Additionally, this implementation creates a runtime state bit array corresponding to the associative array, for example, `seq_run_state[string]`, which records the runtime state of each subsequence. In this implementation, the combination of the associative array, the runtime state bit array, and `fork-join_none` is equivalent to implementing a lightweight user-space thread model at the UVM sequence level. Developers can orchestrate any number of concurrent subsequences in text-based manner, similar to writing shell scripts, thus enabling the addition and deletion of concurrent threads without modifying the SV code. Each thread has an addressable string handle, facilitating cross-instruction referencing. The subsequence type is dynamically instantiated by the UVM factory, naturally supporting the replacement or overwriting of an old type with a new one without modifying the original code, consistent with the UVM design principles.

[0020] S102 generates simulation instructions for each subsequence based on keywords, and executes the simulation instructions by calling the corresponding access port to perform chip simulation.

[0021] Optionally, for each subsequence, simulation instructions are generated based on keywords, and the simulation instructions are executed by calling the corresponding access port to perform chip simulation. This includes: determining the operation type for each subsequence based on configuration keywords and the action type based on action keywords through a lower-level atomic operation parser. The operation types include data path type, configuration register type, register tunnel type, performance monitoring type, memory backdoor type, timing type, and context setting type. The simulation instructions corresponding to the subsequence are determined based on the operation type and action type, and the access port corresponding to the simulation instructions is determined. The simulation instructions are executed by calling the corresponding access port to perform chip simulation.

[0022] Specifically, in this implementation, the lower-level courtyard operation parser determines the operation type for each sub-sequence based on the configured keywords, for example, specifically based on set_seq. <name> <param> <value>The `param` parameter in the configuration file determines the operation type. For example, operation types can include data path classes, configuration register classes, register tunnel classes, performance monitoring classes, memory backdoor classes, timing classes, and context setting classes. Specifically, data path classes can include WR / WRBLOCK / RD / RDBLOCK, corresponding to non-blocking write, blocking write, non-blocking read, and blocking read, respectively; configuration register classes can include REGWR / REGRD / REGPULL, corresponding to register write, read verification, and polling, respectively; register tunnel classes can include PIFWR / PIFRD / PIFPULL, corresponding to write operations, read operations, and polling operations, respectively, accessing the physical layer interface PHY through a two-level register tunnel of PHY_APB_ADDR (access control) / PHY_CSR_ACCESS (destination address); and performance monitoring classes can include PMCSEL / PMCWR / PMCR. D / PMCPULL correspond to the selection, write, read, and polling operations of the PMC registers, respectively, and select the PMC register group according to the AXI / DFI0 / DFI1 channels. AXI is typically a high-speed communication interface inside or outside the chip, while DFI0 / DFI1 are typically interfaces connecting the memory controller and the PHY. Memory backgate classes can include MEMFIL, corresponding to memory filling, and performing backgate initialization on the memory chips according to the start address / length. Timing classes include DELAY, corresponding to delay instructions, and include the INCLUDE class, which introduces another test sequence, configuration file, or code snippet into the current test flow. Context setting classes can include: SETQOS / SETID / SETIDPAT / SETADDRUSER / SETADDRUSERPAT / SETMC / SETDFPORT / SETBURSTSIZE / SETBURSTTYPE / SETSEQR correspond to setting the quality of service, setting the transport identifier, setting the identifier mode, setting the user signal of the address channel, setting the mode of the user signal of the address channel, setting the memory controller parameters, setting the data stream port, setting the burst transfer size, setting the burst transfer type, and setting the sequence generator, which is used to dynamically switch the randomization mode and target port of subsequent instructions, etc. Of course, this embodiment is only an example and does not limit the specific content of the operation type.

[0023] In this embodiment, the action type can also be determined based on action keywords, such as start_seq. <name>The corresponding action type is "start", wait_seq <name>This corresponds to blocking wait, stop_seq <name>The action type corresponding to speed is active stop, del_seq <name>The corresponding action types are deletion, etc., but the specific content of the action type is not limited in this embodiment. In this embodiment, the corresponding operation type and action type are combined for each sub-sequence to obtain simulation instructions. In this implementation, the corresponding access port API for each simulation instruction is determined. The simulation instructions are executed by calling the corresponding access port to perform chip simulation. The types of access port APIs can include memory controller operation classes, register operation classes, timing control classes, or memory backdoor initialization classes. Among them, memory controller operation classes can include `mc_write`, used to write configuration or data to the memory controller, and `mc_read`, used to read status, configuration information, or read back data from the memory controller; register operation classes can include `reg_write`, used to write data to a register inside the chip, `reg_read`, used to read the current value of a register inside the chip, and `reg_pull`, a register polling or pull operation; timing control classes include `delay`, which inserts a waiting time between consecutive hardware operations; memory backdoor initialization classes include `dram_mem::mem_bkd_init_soc`, which calls the backdoor initialization function in the `dram_mem` class to directly initialize the DRAM memory at the SoC level. In this embodiment, different simulation instructions are executed by calling different access ports to simulate and verify different functions of the chip. Furthermore, this embodiment can access multiple access ports simultaneously to execute different simulation instructions in parallel, thereby improving the simulation efficiency of the chip.

[0024] Optionally, the method further includes: when a user's simulation test scenario update instruction is received, extracting scenario parameters under the updated scenario from the simulation test scenario update instruction; updating the valid values ​​of the configured keywords in the stimulus file according to the scenario parameters to obtain an updated stimulus file that matches the updated scenario; and performing simulation and testing on the chip based on the updated stimulus file under the updated scenario.

[0025] In this embodiment, when a user wants to update the simulation scenario, they only need to update the valid values ​​of the configured keywords in the stimulus file. The lower-level atomic operation parser will then perform simulation on the chip in the updated scenario based on the updated stimulus file. This enables the switching of the chip in different simulation scenarios without modifying the code, significantly improving the simulation efficiency of the chip and reducing the workload of developers.

[0026] It should be noted that in this implementation, the upper-layer concurrent orchestration parser maintains the run state bit array `seq_run_state[string]` during simulation. The upper-layer concurrent orchestration parser performs scheduling during simulation; for example, the `start_seq` keyword sets `seq_run_state[name]` to 1 and forks a subsequence. After the subsequence ends, the scheduler clears the state bit to 0 at the end of the fork branch. The `wait_seq` keyword waits for the state bit to become 0 in a #10ns polling loop. Compared to the traditional hard-coded `fork...join`, this mechanism is data-driven, and the stimulus no longer needs to explicitly declare fork branches in the SV. Each thread is indexed by `name`, which can be reused by name in subsequent `wait_seq` / `stop_seq` / `del_seq` operations, avoiding the problem of anonymous fork branches not being accurately synchronized / terminated. The subsequence type is instantiated by the UVM factory, naturally supporting runtime `type_override`, facilitating switching the stimulus generator implementation version without modifying the stimulus file.

[0027] S103: During the chip testing phase, obtain the operation type corresponding to the keyword, and translate the operation type based on the test library to obtain the test file.

[0028] Optionally, the test files are obtained by translating the operation types based on the test library, including: retrieving the test library from the local machine, wherein the test library includes the correspondence between operation types and test languages; querying the test languages ​​corresponding to each operation type from the test library, and combining the test languages ​​to generate test files.

[0029] Specifically, in this embodiment, after chip simulation and actual production are completed, the newly produced chip still needs to be tested. Since C++ is mainly used for testing, existing technologies typically use independently compiled test code for testing. Because the stimulus file used during simulation is mainly determined based on UVM stimulus, the language structures of the two are different. Therefore, this embodiment will obtain the operation type corresponding to the keywords obtained during the simulation phase by parsing, and translate each keyword into C++ API call language based on the bare-metal test library. For example, utils.write_mc_reg (write register), utils.read_mc_reg_and_compare (read and compare), utils.poll_mc_reg (polling register), utils.write_mc_mem (write memory), utils.read_mc_mem (read memory), pTb_Intf->tb_wait (wait delay), utils.set_param (set parameter), etc., and combine the above-obtained test languages ​​to generate a test file for chip testing. In addition, in this embodiment, the pre-simulation UVM stimulus and the post-silicon C++ stimulus share the same stimulus file as the only trusted source. Therefore, when the stimulus content is iterated, the verification team only needs to modify one stimulus file, and the pre-simulation and post-silicon tests take effect simultaneously, thereby eliminating the risk of coverage drift caused by the parallel evolution of two sets of stimulus code.

[0030] S104 executes the test file on the chip to perform actual testing on the simulated chip.

[0031] In this implementation, test files are executed on the chip to test different chip functions. Both the testing and simulation processes are based on the same stimulus file from the chip design phase, thus avoiding the risk of inconsistencies in verification caused by maintaining two sets of stimulus code. Furthermore, compared to traditional hard-coded SV stimulus, this implementation eliminates the need for re-coding stimulus modifications; only runtime parsing and execution are required. Concurrent orchestration offers high readability because it relies on plain text keywords such as add / start / wait / stop. Threads can be named and referenced, using string name indexes for synchronization or termination by name. The cost of adding new stimulus operations is reduced, requiring only the addition of interpreter branches and atomic APIs, without the need for new SV classes or code recompilation.

[0032] The technical solution of this invention avoids repeated modifications to the simulation code when the scenario is updated by introducing a dynamically updatable stimulus file, which reduces the workload of developers. Furthermore, it automatically generates the test files required for the testing phase based on the stimulus file, thereby realizing single-source reuse for simulation and testing. This fundamentally eliminates the risk of inconsistency between pre- and post-verification caused by maintaining two sets of stimulus code. This not only greatly improves the flexibility and development efficiency of verification scenario construction, but also more effectively ensures the coverage and reliability of the chip from design to testing.

[0033] Example 2 Figure 2 This is a flowchart of another chip simulation and testing method provided by an embodiment of the present invention. Based on the above embodiments, this embodiment executes a test file on the chip to perform actual testing on the simulated chip. It further includes: obtaining simulation results and actual test results for the chip; comparing the simulation results and actual test results to obtain the simulation test error; and correcting the stimulus test file based on the simulation test error, such as... Figure 2 As shown, the method includes: S201: During the chip simulation phase, the received stimulus file is parsed to obtain the keywords corresponding to each subsequence.

[0034] Optionally, during the chip simulation phase, the received stimulus file is parsed to obtain the keywords corresponding to each sub-sequence. This includes: starting a sequence container in the upper-layer concurrent orchestration parser to perform parsing work during the chip simulation phase; and parsing the received stimulus file through the sequence container to obtain the keywords corresponding to each sub-sequence, wherein the keywords include configuration keywords and action keywords.

[0035] Optionally, the method also includes: constructing an associative array indexed by strings based on the parsed subsequences through an upper-level concurrent orchestration parser; constructing a running status bit array that matches the associative array, wherein the running status bit array is used to record the running status of each subsequence.

[0036] S202 generates simulation instructions for each subsequence based on keywords, and executes the simulation instructions by calling the corresponding access port to perform chip simulation.

[0037] Optionally, for each subsequence, simulation instructions are generated based on keywords, and the simulation instructions are executed by calling the corresponding access port to perform chip simulation. This includes: determining the operation type for each subsequence based on configuration keywords and the action type based on action keywords through a lower-level atomic operation parser. The operation types include data path type, configuration register type, register tunnel type, performance monitoring type, memory backdoor type, timing type, and context setting type. The simulation instructions corresponding to the subsequence are determined based on the operation type and action type, and the access port corresponding to the simulation instructions is determined. The simulation instructions are executed by calling the corresponding access port to perform chip simulation.

[0038] Optionally, the method further includes: when a user's simulation test scenario update instruction is received, extracting scenario parameters under the updated scenario from the simulation test scenario update instruction; updating the valid values ​​of the configured keywords in the stimulus file according to the scenario parameters to obtain an updated stimulus file that matches the updated scenario; and performing simulation and testing on the chip based on the updated stimulus file under the updated scenario.

[0039] S203: During the chip testing phase, obtain the operation type corresponding to the keyword, and translate the operation type based on the test library to obtain the test file.

[0040] Optionally, the test files are obtained by translating the operation types based on the test library, including: retrieving the test library from the local machine, wherein the test library includes the correspondence between operation types and test languages; querying the test languages ​​corresponding to each operation type from the test library, and combining the test languages ​​to generate test files.

[0041] S204 executes the test file on the chip to perform actual tests on the simulated chip. S205: Obtain simulation results and actual test results for the chip, compare the simulation results and actual test results to obtain simulation test error, and correct the test file or stimulus file based on the simulation test error. Specifically, this implementation method acquires the actual test results after the chip completes testing and compares the simulation results with the actual test results. Since the same parameters are involved in both the initial simulation stage of chip design and the actual testing stage after chip production, such as operating frequency, cache size, power consumption, or noise tolerance, this implementation method does not limit the specific types of parameters involved in simulation or testing. Therefore, for the same parameter, the simulation results and experimental test results are compared. Normally, the simulation test error should be within a preset range. However, when the simulation test error exceeds the preset range, it indicates that the test file generated based on the stimulus file may have errors during the translation process. In this case, the test file will be corrected, for example, by re-translating it. However, if the simulation test error does not decrease after the test file is corrected, the original stimulus file may be incorrect. In this case, the stimulus file on which the simulation and testing process is based will be checked, and the errors will be corrected.

[0042] It should be noted that in this embodiment, the operations during the modification of the test file or stimulus file will be recorded to generate a correction log. In the subsequent simulation and testing process, if the simulation test error is within the same range, the historical correction log will be called to automatically modify the file, thereby avoiding the time cost of manually querying the cause of the error. Of course, this embodiment is only an example and does not limit the specific method of file modification.

[0043] The technical solution of this invention avoids repeated modifications to the simulation code when the scenario is updated by introducing a dynamically updatable stimulus file, which reduces the workload of developers. Furthermore, it automatically generates the test files required for the testing phase based on the stimulus file, thereby realizing single-source reuse for simulation and testing. This fundamentally eliminates the risk of inconsistency between pre- and post-verification caused by maintaining two sets of stimulus code. This not only greatly improves the flexibility and development efficiency of verification scenario construction, but also more effectively ensures the coverage and reliability of the chip from design to testing.

[0044] Example 3 Figure 3 This is a schematic diagram of a chip simulation and testing device provided in an embodiment of the present invention. Figure 3 As shown, the device includes: an excitation file parsing module 310, a chip simulation module 320, a test file acquisition module 330, and a chip testing module 340.

[0045] The stimulus file parsing module 310 is used to parse the received stimulus file during the chip simulation stage to obtain the keywords corresponding to each sub-sequence. The stimulus file can be dynamically updated according to the simulation scenario requirements. The chip simulation module 320 is used to generate simulation instructions for each sub-sequence based on keywords, and execute the simulation instructions by calling the corresponding access port to perform chip simulation. The test file acquisition module 330 is used to acquire the operation type corresponding to the keyword during the chip testing phase, and to translate the operation type based on the test library to obtain the test file; The chip test module 340 is used to execute test files on the chip to perform actual tests on the simulated chip.

[0046] Optionally, the stimulus file parsing module 310 is used to start the sequence container that performs parsing work in the upper-layer concurrent orchestration parser during the chip simulation stage; The received stimulus file is parsed using a sequence container to obtain the keywords corresponding to each subsequence. These keywords include configuration keywords and action keywords.

[0047] Optionally, the chip simulation module 320 is used to determine the operation type for each subsequence based on the configuration keyword and the action type based on the action keyword through the lower-level atomic operation parser. The operation types include data path type, configuration register type, register tunnel type, performance monitoring type, memory backdoor type, timing type and context setting type. The simulation instructions corresponding to the sub-sequence are determined based on the operation type and action type, and the access ports corresponding to the simulation instructions are also determined. Chip simulation is performed by executing simulation instructions through the corresponding access port.

[0048] Optionally, the device also includes an array construction module for constructing an associative array indexed by strings from the parsed subsequences by an upper-level concurrent orchestration parser; Construct a running status bit array that matches the associated array, where the running status bit array is used to record the running status of each subsequence.

[0049] Optionally, the test file acquisition module 330 is used to retrieve the test library from the local machine, wherein the test library includes the correspondence between operation types and test languages; The test language corresponding to each operation type is queried from the test library, and the test languages ​​are combined to generate test files.

[0050] Optionally, the device also includes a scene update module, which is used to extract scene parameters under the updated scene from the simulation test scene update instruction when a user's simulation test scene update instruction is received; The valid values ​​of the configured keywords in the incentive file are updated according to the scenario parameters to obtain an updated incentive file that matches the updated scenario. In the updated scenario, simulation and testing of the chip are performed based on the updated stimulus file.

[0051] Optionally, the device also includes a stimulus test file correction module for obtaining simulation results and actual test results for the chip; The simulation results are compared with the actual test results to obtain the simulation test error, and the test file or stimulus file is corrected based on the simulation test error.

[0052] The chip simulation and testing apparatus provided in this embodiment of the invention can execute the chip simulation and testing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0053] Example 4 Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0054] The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the invention described and / or claimed herein.

[0055] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0056] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other electronic devices through computer networks such as the Internet and / or various telecommunications networks.

[0057] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as chip simulation and testing methods.

[0058] That is, during the chip simulation stage, the received stimulus file is parsed to obtain the keywords corresponding to each sub-sequence. The stimulus file can be dynamically updated according to the requirements of the simulation scenario. For each subsequence, simulation instructions are generated based on keywords, and the simulation instructions are executed by calling the corresponding access port to perform chip simulation. During the chip testing phase, the operation type corresponding to the keyword is obtained, and the operation type is translated based on the test library to obtain the test file; Execute the test file on the chip to perform actual tests on the simulated chip.

[0059] In some embodiments, the chip simulation and testing methods may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the chip simulation and testing methods described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the chip simulation and testing methods by any other suitable means (e.g., by means of firmware).

[0060] Various embodiments of the apparatuses and techniques described above herein can be implemented in digital electronic circuit devices, integrated circuit devices, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), device-on-a-chip (SoC) devices, complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable device including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage device, at least one input device, and at least one output device, and transmitting data and instructions to the storage device, the at least one input device, and the at least one output device.

[0061] Computer programs used for implementing the simulation and testing methods of the chip of this invention can be written in any combination of one or more programming languages. These computer programs can be provided to the processor of a general-purpose computer or a special-purpose computer, such that when executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer programs can be executed entirely on the machine, partially on the machine, or as a standalone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0062] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution apparatus, device, or electronic device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage electronics, magnetic storage electronics, or any suitable combination thereof.

[0063] To provide interaction with a user, the devices and techniques described herein can be implemented on an electronic device having: a display device (e.g., a touchscreen) for displaying information to the user; and buttons through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0064] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0065] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.< / name> < / name> < / name> < / name> < / value> < / name> < / file> < / unit> < / val> < / name> < / name> < / name> < / name> < / type> < / name> < / file> < / unit> < / val> < / name> < / name> < / name> < / name> < / type> < / name> < / value> < / name>

Claims

1. A method for simulating and testing a chip, characterized in that, The method includes: During the chip simulation phase, the received stimulus file is parsed to obtain the keywords corresponding to each sub-sequence. The stimulus file can be dynamically updated according to the requirements of the simulation scenario. For each subsequence, simulation instructions are generated based on the keywords, and the simulation instructions are executed by calling the corresponding access port to perform chip simulation. During the chip testing phase, the operation type corresponding to the keyword is obtained, and the operation type is translated based on the test library to obtain the test file; The test file is executed on the chip to perform actual testing on the simulated chip.

2. The method according to claim 1, characterized in that, The step of parsing the received stimulus file and obtaining the keywords corresponding to each sub-sequence during the chip simulation stage includes: During the chip simulation phase, the sequence container that performs parsing work in the upper-layer concurrent orchestration parser is started; The received stimulus file is parsed using the sequence container to obtain keywords corresponding to each sub-sequence, wherein the keywords include configuration keywords and action keywords.

3. The method according to claim 2, characterized in that, The step of generating simulation instructions for each sub-sequence based on the keyword, and executing the simulation instructions by calling the corresponding access port to perform chip simulation includes: The lower-level atomic operation parser determines the operation type for each subsequence based on the configuration keyword and the action type based on the action keyword. The operation types include data path type, configuration register type, register tunnel type, performance monitoring type, memory backdoor type, timing type and context setting type. Based on the operation type and the action type, determine the simulation instruction corresponding to the sub-sequence, and determine the access port corresponding to the simulation instruction; Chip simulation is performed by calling the corresponding access port to execute the simulation instructions.

4. The method according to claim 2, characterized in that, The method further includes: The upper-level concurrent orchestration parser constructs an associative array indexed by strings based on the parsed subsequences; Construct a running status bit array that matches the associated array, wherein the running status bit array is used to record the running status of each subsequence.

5. The method according to claim 1, characterized in that, The process of translating the operation type based on the test library to obtain the test file includes: The test library is retrieved locally, wherein the test library includes the correspondence between operation types and test languages; The test language corresponding to each operation type is queried from the test library, and the test languages ​​are combined to generate the test file.

6. The method according to claim 2, characterized in that, The method further includes: When a user's simulation test scenario update instruction is received, the scenario parameters under the updated scenario are extracted from the simulation test scenario update instruction; The effective values ​​of the configured keywords in the incentive file are updated according to the scenario parameters to obtain an updated incentive file that matches the updated scenario. The chip is simulated and tested based on the updated stimulus file in the updated scenario.

7. The method according to claim 1, characterized in that, After executing the test file on the chip to perform actual testing on the simulated chip, the process further includes: Obtain simulation results and actual test results for the chip; The simulation results and the actual test results are compared to obtain the simulation test error, and the test file or stimulus file is corrected based on the simulation test error.

8. A chip simulation and testing apparatus, characterized in that, The device includes: The stimulus file parsing module is used to parse the received stimulus file during the chip simulation stage to obtain the keywords corresponding to each sub-sequence. The stimulus file can be dynamically updated according to the simulation scenario requirements. The chip simulation module is used to generate simulation instructions for each sub-sequence based on the keywords, and to execute the simulation instructions by calling the corresponding access port to perform chip simulation. The test file acquisition module is used to acquire the operation type corresponding to the keyword during the chip testing phase, and to translate the operation type based on the test library to obtain the test file; A chip testing module is used to execute the test file on the chip to perform actual testing on the simulated chip.

9. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-7.

10. A storage medium for computer-executable instructions, wherein a computer program is stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

Images