Vehicle regulation chip TRGMUX module verification system and method

Abstract

The invention relates to a vehicle regulation chip TRGMUX module verification system and a vehicle regulation chip TRGMUX module verification method, a module-level verification system special for a TRGMUX module is constructed based on a UVM verification platform according to actual verification requirements of the vehicle regulation chip TRGMUX module, and rapid customization of a verification environment and a verification process for the TRGMUX module through a configuration file configuration mode is supported. According to the method, the information of the module is captured through the automatic script and the UVM verification environment is generated by using the information, so that the verification work of the module is completed, and the completeness verification of each function of the module is effectively adapted. Compared with traditional manual verification, the verification system has the advantages that the verification efficiency of the module is remarkably improved, the verification difficulty of the module is reduced, the verification completeness of the type of module is greatly improved, and effective support is provided for further enhancing the safety performance of a vehicle gauge level chip.

Description

Technical Field

[0001] The present invention belongs to the technical field of chip verification and relates to a vehicle-grade chip TRGMUX module verification system and method. Background Art

[0002] Automotive products not only have extremely high safety requirements, but also require automotive-grade chips to meet strict safety standards, such as ISO26262 safety standards, to ensure their reliability under various working conditions. And with the development of automotive intelligence, the functions of automotive-grade chips have become more and more complex, including autonomous driving, car networking and advanced driver assistance systems (ADAS), all of which have put forward higher requirements for the reliability and functional safety of automotive-grade chips. The TRGMUX (Trigger Multiplexer) module is a core functional module in the SOC (system on chip), which mainly acts as a route for mutual triggering between modules. In the field of smart cars with extremely high safety performance requirements, its functions need to be further expanded, requiring the TRGMUX module to effectively handle triggers from asynchronous events to ensure that the system can respond quickly to various external conditions; it is also required to be able to select different trigger sources in different operating modes, optimize resource usage, reduce power consumption and improve performance; it can be connected to the chip's pad and filter the signal in the pad, record the status of the pad, support pulse modulation, support source trigger signal widening processing, and have functional safety modules, such as circuit redundancy backup, CRC check and bus check. With the increase in the functions of the TRGMUX module in automotive-grade chips and the increase in input and output ports, how to conduct complete and efficient verification of the TRGMUX module in the field of smart cars remains one of the technical problems to be solved. Summary of the invention

[0003] In response to the problems existing in the above-mentioned traditional technologies, the present invention proposes a vehicle-grade chip TRGMUX module verification system and a vehicle-grade chip TRGMUX module verification method, which can perform complete and efficient verification of the TRGMUX module in the field of smart cars.

[0004] In order to achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: On the one hand, a TRGMUX module verification system for an automotive chip is provided, comprising a verification case layer, a top connection layer, a verification environment layer, and a TRGMUX module to be verified. The verification case layer is used to simulate the actual usage scenario of the TRGMUX module to be verified, and the top connection layer is used to instantiate the TRGMUX module to be verified and connect the instantiated TRGMUX module to be verified to a verification platform through an interface. The verification environment layer includes apb agent, master agent, slave agent, scoreboard, virtualized sequencer, configuration file and register model. The apb agent is connected to the TRGMUX module to be verified through the apb interface, the master agent is connected to the TRGMUX module to be verified through the input interface, and the slave agent is connected to the TRGMUX module to be verified through the output interface. The apb agent is used to read and write the registers of the TRGMUX module to be verified through the apb interface. The master agent includes multiple master agents, each of which corresponds to each input port of the TRGMUX module to be verified, and each master agent is used to send input transactions to the TRGMUX module to be verified; the slave agent includes multiple slave agents, each of which corresponds to each output port of the TRGMUX module to be verified, and each slave agent is used to capture the output transactions of the TRGMUX module to be verified and send them to the scoreboard; The virtualized sequencer is used to control the execution of the test sequence according to the verification scenario of the TRGMUX module to be verified. The register model is used to read and write the registers of the TRGMUX module to be verified, simulate the register behavior and monitor the register status. The configuration file is used to configure the verification environment, each agent and the configuration register model. The scoreboard is used to compare the output result of the TRGMUX module to be verified with the expected output result based on the configuration expectation to obtain the verification result of the TRGMUX module to be verified.

[0005] On the other hand, a vehicle-regulatory chip TRGMUX module verification method is also provided, which is applied to the above-mentioned vehicle-regulatory chip TRGMUX module verification system. The vehicle-regulatory chip TRGMUX module verification method includes the following steps: Execute the automated top-level file script to generate the platform architecture of the TRGMUX module verification system for automotive chips; Execute the automated register configuration script and capture the register information in the given register configuration table, generate a register model based on the register information and integrate it into the generated verification environment layer; Execute the automated TRGMUX script and capture the input signal and configurable processing information in the given input configuration table, capture the output signal and configurable processing information in the given output configuration table, and supplement and improve the configuration in the verification system; wherein, the process of supplementing and improving the configuration in the verification system includes: generating a master agent according to the input configuration table, filling in the input signal, and filling the processing information in the input configuration table into the configuration file of the master agent, generating a slave agent according to the output configuration table, filling in the output signal, and filling the processing information in the output configuration table into the configuration file of the slave agent; In the platform architecture of the TRGMUX module verification system for automotive chips, input transactions are sent to the TRGMUX module to be verified and output transactions of the TRGMUX module to be verified are captured; In the platform architecture of the automotive chip TRGMUX module verification system, the verification result of the TRGMUX module to be verified is obtained by comparing the output result of the TRGMUX module to be verified with the expected output result based on the configuration expectation through the scoreboard.

[0006] One of the above technical solutions has the following advantages and beneficial effects: The above-mentioned automotive chip TRGMUX module verification system and method, by targeting the actual verification requirements of automotive chip TRGMUX modules, builds a module-level verification system dedicated to automotive chip TRGMUX modules based on the UVM verification platform, supports rapid customization of the verification environment and verification process of automotive chip TRGMUX modules through configuration files, supports capturing TRGMUX module information through automated scripts and using this information to generate a UVM verification environment to complete the verification of the module, thereby effectively adapting to the completeness verification of various functions of automotive chip TRGMUX modules. Compared with traditional manual verification, the above-mentioned verification system significantly improves the verification efficiency of automotive chip TRGMUX modules, reduces its verification difficulty, and greatly improves the completeness of this type of module verification, providing effective support for further strengthening the safety performance of automotive-grade chips. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the conventional technology, the drawings required for use in the embodiments or the conventional technology descriptions are briefly introduced below. 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 creative work.

[0008] Figure 1 It is a structural block diagram of a TRGMUX module verification system for a vehicle-grade chip in one embodiment; Figure 2 The figure is a flow chart of a method for verifying a TRGMUX module of a vehicle-grade chip in an embodiment. DETAILED DESCRIPTION

[0009] In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention is further described in detail below in conjunction with the accompanying drawings and Examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those generally understood by those skilled in the art of the present invention. The terms used in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0010] It should be noted that the reference to "embodiment" in this article means that the specific features, structures or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The presentation of this phrase at various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It will be appreciated by those skilled in the art that the embodiments described herein may be combined with other embodiments. The term "and / or" used in the specification of the present invention and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

[0011] The following will describe the implementation of the present invention in detail with reference to the accompanying drawings in the embodiment diagram of the present invention.

[0012] In one embodiment, Figure 1 As shown, a verification system for a TRGMUX module of an automotive chip is provided, including a verification use case layer, a top connection layer, a verification environment layer and a TRGMUX module to be verified. The verification use case layer is used to simulate the actual usage scenario of the TRGMUX module to be verified. The top connection layer is used to instantiate the TRGMUX module to be verified and connect the instantiated TRGMUX module to be verified to the verification platform through an interface. The verification environment layer includes an apb agent, a master agent, a slave agent, a scoreboard, a virtualized sequencer, a configuration file and a register model. The apb agent is connected to the TRGMUX module to be verified through the apb interface, the master agent is connected to the TRGMUX module to be verified through the input interface, and the slave agent is connected to the TRGMUX module to be verified through the output interface.

[0013] The apb agent is used to read and write the registers of the TRGMUX module to be verified through the apb interface. There are multiple master agents, each of which corresponds to each input port connected to the TRGMUX module to be verified, and each master agent is used to send input transactions to the TRGMUX module to be verified. There are multiple slave agents, each of which corresponds to each output port connected to the TRGMUX module to be verified, and each slave agent is used to capture the output transactions of the TRGMUX module to be verified and send them to the scoreboard. The virtualized sequence generator is used to control the execution of the test sequence according to the verification scenario of the TRGMUX module to be verified. The register model is used to read and write the registers of the TRGMUX module to be verified, simulate the register behavior and monitor the register status. The configuration file is used to configure the verification environment, each agent and the configuration register model. The scoreboard is used to compare the output result of the TRGMUX module to be verified with the expected output result based on the configuration expectation, and obtain the verification result of the TRGMUX module to be verified.

[0014] It can be understood that the design of each component in the above-mentioned automotive chip TRGMUX module verification system follows the existing UVM verification methodology. According to the detailed verification needs of the TRGMUX module functions, the verification system is built based on the UVM verification platform to configure components of corresponding functions, and complete basic operations such as connection and connectivity testing between components to ensure normal data flow between components during the verification process.

[0015] Specifically, a verification environment for the TRGMUX module is built using a general UVM verification platform, the function configuration information of the TRGMUX module is captured through an automated script, and the function configuration information is used to generate a UVM verification environment to complete the verification of the TRGMUX module. Figure 1As shown in the figure, the top-level file (Testbench) created in the verification system includes a verification case layer, a top connection layer, and a verification environment layer. Among them, the verification case layer is used to simulate the actual use scenario of DUT (Device Under Test, which refers to the design to be tested, and in this manual, it is the TRGMUX module to be verified), such as the triggering of the output destination by the input source, filtering and processing of certain signals in the input source, etc. The top connection layer is used to instantiate the TRGMUX module to be verified and connect it to the verification platform. The verification environment layer includes a series of hierarchical components that constitute the verification environment, such as uvm_env (environment component), uvm_agent (agent component), uvm_driver (driver), uvm_virtual_sequencer (virtual sequencer) and uvm_scoboard (scoreboard), as well as non-hierarchical components, such as uvm_configure (configuration file), transaction (transaction), sequence (sequence) and interface (interface).

[0016] In the top connection layer, the TRGMUX module to be verified is connected to the verification platform through the interface interface, and the interface interface is transferred to the verification environment through the uvm_configure_db::set function (an important function in the UVM verification platform, used to set configuration information in the UVM verification environment). The top-level file defines the macro for clock generation, which can adjust various parameters of the clock, such as frequency, duty cycle, and offset. The control logic of the clock and reset is globally controlled at the top level.

[0017] The interface can be divided into different master interfaces according to the source of the input signal of the TRGMUX module to be verified. For example, the interface of the pad module from the chip is the pad master interface (pad master_interface). Similarly, according to the source of the output signal of the TRGMUX module to be verified, it can be divided into different slave interfaces. For example, the interface output to the SENT module is the sent slave interface (sent slaver_interface). Subdividing the input and output interfaces into multiple groups can help to control the port signals more finely, facilitate the simultaneous control of multiple groups of signals, and combine them to generate incentives that are more suitable for the actual use scenarios of the TRGMUX module.

[0018] The verification case layer can be divided into basic case files and extended case files. The basic case file (including the test case base class) instantiates the environment component uvm_env and pre-sets some common tasks, such as checking some register values ​​and configuring the mode of the TRGMUX module to be verified. The extended case file inherits from the basic case file and is used to call and combine sequences in the test sequence library to generate stimuli for the TRGMUX module to be verified, so as to test the specific functions of the TRGMUX module to be verified.

[0019] The register model in the verification environment layer is used to simulate the registers in the TRGMUX module to be verified, which defines the properties of the registers, such as name, width, reset value, and offset address. After the register model is connected to the apb agent, it is more convenient to read and write the registers of the TRGMUX module to be verified, simulate register behavior, and monitor register status during the verification process.

[0020] The scoreboard in the verification environment layer is mainly used to collect and compare the output results of the TRGMUX module to be verified with the expected results of the configuration during the verification process, so as to determine whether the TRGMUX module to be verified works correctly. The scoreboard will generate detailed verification reports and simulation logs based on the comparison results. These reports record the differences between the output results of the TRGMUX module to be verified and the expected results. These reports provide direct and effective support data for verification engineers to debug and fix problems in the TRGMUX module.

[0021] The configuration files in the verification environment layer can include the configuration files of the verification environment and the configuration files of each agent. The configuration files of the verification environment are used to configure the number of instantiations of components, types and the connection relationship between them; to set the parameters of the verification environment, such as the clock cycle required for the entire verification process to fully test the DUT; to determine the strategy adopted for verification, such as whether to use coverage-driven verification or function-based verification. The configuration files of each agent are used to configure the signal timing of the apb interface, such as setting the number of clocks in the read and write cycles in the APB protocol and the width of data transmission. They can also be used to customize the behavior of each agent and specify the interaction details when the agent interacts with other components in the verification environment. For example, the agent configuration file can specify how the agent passes the output results obtained from the DUT to the scoreboard for data comparison to determine whether the function of the DUT is correct.

[0022] The above-mentioned automotive chip TRGMUX module verification system, through the actual verification needs of automotive chip TRGMUX modules, has built a module-level verification system dedicated to automotive chip TRGMUX modules based on the UVM verification platform. It supports rapid customization of the verification environment and verification process of automotive chip TRGMUX modules through configuration files, supports capturing TRGMUX module information through automated scripts and using this information to generate a UVM verification environment to complete the verification of the module, thereby effectively adapting to the completeness verification of various functions of automotive chip TRGMUX modules. Compared with traditional manual verification, the above-mentioned verification system significantly improves the verification efficiency of automotive chip TRGMUX modules, reduces its verification difficulty, and greatly improves the completeness of this type of module verification, providing effective support for further strengthening the safety performance of automotive-grade chips.

[0023] The verification environment layer includes a series of verification components, each of which performs its own functions.

[0024] In one embodiment, the apb agent includes an apb stimulus file, an apb sequence generator, an apb main driver, and an apb monitor. The apb sequence generator generates an apb sequence according to the apb stimulus file, the apb main driver drives the apb sequence to the TRGMUX module to be verified using the apb port, and the apb monitor is used to monitor the apb interface.

[0025] Specifically, the verification environment layer includes three types of agent components, namely apb agent, master agent and slave agent. Among them, apb agent supports APB protocol and is used to read and write the registers of the TRGMUX module to be verified through the APB protocol interface. The apb agent includes apb stimulus file, apb sequence generator, apb master driver that drives apb sequence to the TRGMUX module to be verified using apb port, and apb monitor that monitors the apb interface.

[0026] In one embodiment, an apb protocol bus functional model apb vip is integrated into the verification system.

[0027] Yes, the tool of APB protocol bus functional model APB VIP can also be integrated in the verification system, so that the APB bus agent can use the APB VIP tool, that is, in the process of verifying the APB bus agent, the APB VIP can be used to build a verification environment; wherein, the APB bus agent is a component used to connect the verification platform and the APB bus interface in the verification architecture, and its function is to convert the high-level transactions (such as read and write operation requests) issued by the verification platform into signals that comply with the APB protocol, and vice versa. For example, APB VIP may include modules for generating read and write operation stimuli that comply with the APB protocol. When verifying the APB bus agent, by using these modules in APB VIP, standard APB read and write operation requests can be sent to the APB bus agent, and then the response returned by the APB bus agent can be checked to see if it meets expectations. In this way, it can be efficiently verified whether the APB bus agent correctly implements the conversion and transmission functions of the APB protocol. At the same time, APB VIP may also provide some functions for checking protocol violations, monitoring signal status, etc., to help verification engineers verify the APB bus agent more comprehensively.

[0028] In one embodiment, each master agent includes an excitation file, a sequencer, a master driver, a port, a monitor and a configuration file. Each master agent is connected to the corresponding input port of the TRGMUX module to be verified through the port. Each slave agent includes a configuration file, an excitation file, a port and a monitor. Each slave agent is connected to the corresponding output port of the TRGMUX module to be verified through the port.

[0029] It can be understood that the master agent can be divided into multiple master agents, such as master agent 0 to master agent N, according to the source of the input port of the TRGMUX module to be verified. Each master agent includes an incentive file, a sequencer, a main driver, a port port, a monitor and a configuration file. The slave agent can be divided into multiple slave agents, such as slave agent 0 to slave agent N, according to the flow direction of the output port of the TRGMUX module to be verified. Each slave agent includes a configuration file, an incentive file, a port port and a monitor. The configuration file can define the way to post-process the received incentive. The monitor records the information on the monitoring interface in the incentive file and sends it to the scoreboard through the port port.

[0030] The virtualized sequencer in the verification environment layer is used to control the execution of the test sequence according to the verification scenario. It does not directly generate or send data, but ensures that the test is executed according to the predetermined steps by scheduling and managing the execution order of different sequences in the verification process.

[0031] The automated construction and testing process of the TRGMUX module verification system for automotive chips can be as follows: Step 1: Execute the automated top-level file script (i.e. uvm_tb_gen) to generate the platform architecture of the TRGMUX module verification system for automotive chips. The verification system is divided into the verification use case layer, the top connection layer, and the verification environment layer.

[0032] In one embodiment, simulation tools vcs and verdi are integrated into the verification system.

[0033] It can be understood that the required simulation tools (such as vcs and verdi) can also be integrated into the verification system. vcs is a high-performance Verilog and System-Verilog compiled simulator that can compile design files (such as RTL code written in Verilog or System-Verilog) and verification files (including verification system code). During the compilation process, vcs will perform syntax checking, semantic analysis and other operations on the code to convert the code into an internal executable format. For example, for the complex object-oriented programming part of System-Verilog (such as the definition and use of classes and objects), vcs can accurately parse and generate corresponding machine-readable instructions to ensure the correctness of the code. After the compilation is completed, vcs can simulate the design to be tested. It can simulate the behavior of the hardware circuit, and according to the input stimulus of the design to be tested, it gradually calculates the state of each module and each signal, so as to verify whether the design to be tested meets the expected function.

[0034] Verdi is a powerful debugging and visualization tool. During the verification process, when simulation tools such as VCS find design errors or unexpected behaviors, Verdi can help verification engineers quickly locate the problem: it can display the waveform of the input / output signal, allowing verification engineers to intuitively see the changes of each signal on the time axis, so as to quickly determine at which time point or which signal the abnormality occurs, whether it is a data transmission error or a synchronization problem at the receiving end, etc. Verdi can also perform code coverage analysis, which can count the various coverage indicators in the corresponding code of the design to be tested, so as to help verification engineers evaluate the completeness of the verification and determine whether more test cases need to be added to improve the coverage, so as to more comprehensively verify the design to be tested.

[0035] In one embodiment, the verification system includes a generated Makefile script, which is used to perform automatic compilation, simulation, use case regression, and code collection and function coverage of the verification system.

[0036] It can be understood that a Makefile script for compilation and simulation is generated. The Makefile script can support regression testing of test cases, whether the incoming transmission control simulator collects coverage, and can help organize and manage a large number of design files (such as Verilog or System-Verilog code) and simulation files, as well as the dependencies between them, to further improve verification efficiency.

[0037] Step 2: Execute the automated register configuration script (i.e., rgm_gen), capture the register information in the given register configuration table (as shown in Table 1), such as register name, domain name, range, access rights, offset address, and reset value, etc., generate a register model, and integrate it into the generated verification environment layer. Call the read and write sequences that come with the register model to check whether the registers in the TRGMUX module to be verified can be read and written normally to ensure the correctness of the verification environment.

[0038] Table 1

[0039] WR stands for "Write" permission.

[0040] Step 3: Execute the automated TRGMUX script (i.e., trgmux_gen), capture the input signals and their configurable processing information in the given input configuration table (as shown in Table 2), and capture the output signals and their configurable processing information in the given output configuration table (as shown in Table 3). Through the extracted signals, the configuration in the verification system is supplemented and improved, so that the verification system is more suitable for the verification scenario of the TRGMUX module to be verified. Taking Table 2 as an example, the name of the input module is extracted and filled into the agent name of the agent. Each input module corresponds to an agent, and master agent 0 and master agent 1 can be generated. Extract the input signal information of the input module and fill it into the corresponding interface interface and stimulus file, such as the input signal 0 (maser0_sig0), input signal 1 (maser0_sig1) and maser0_sig1 variables of master agent 0 in the input interface (master_interfac) and input transaction. Some additional variables can be defined in the transaction component to control the above-mentioned maser0_sig1 variable, such as controlling the number of packets sent each time and the interval between packets sent.

[0041] The processing mode information is filled into the configuration file, such as whether direct configuration (direct_cfg), whether the input signal can be filtered (filter_cfg), etc. The extraction and processing of the information in Table 3 are similar, and slave agent 0 (slver0_agent), slave agent 1 (slaver1_agent), and slave agent 2 (slaver2_agent) can be generated.

[0042]

[0043] Step 4: In the platform architecture of the verification system, send input transactions to the TRGMUX module to be verified and capture the output transactions of the TRGMUX module to be verified. According to the verification scenario, the virtualized sequencer controls multiple test sequences to simultaneously input transactions to the TRGMUX module to be verified through the main drivers in different master agents. At the same time, the monitor in the master agent monitors the signal data on the input interface in real time and packages it into input transactions, which are sent to the scoreboard through the port port. While the master agent is inputting transactions to the TRGMUX module to be verified, the monitor in the slave agent monitors the signal variables of the corresponding output interface in real time and packages the monitored signal variables into output transactions (also called output results), which are sent to the scoreboard through the channel port port.

[0044] Step 5: In the platform architecture of the verification system, the scoreboard can synchronously obtain the register values ​​in the TRGMUX module to be verified through the backdoor access of the register model. After obtaining the input transaction, the scoreboard can generate the expected output transaction (also called the expected output result) of the TRGMUX module to be verified according to the corresponding register value read, such as reading the filter register, and performing corresponding filtering processing on the transaction; reading the level expansion register, and performing corresponding widening processing on the transaction; reading the level modulation register, and performing corresponding level modulation processing on the transaction, etc. The scoreboard compares and verifies the expected output transaction and the output transaction actually captured from the agent to obtain the verification result of the TRGMUX module to be verified.

[0045] Each component in the above-mentioned automotive chip TRGMUX module verification system can be fully or partially implemented by software, hardware and their combination. The above-mentioned components can be embedded in or independent of a device with data processing functions in the form of hardware, or can be stored in the memory of the aforementioned device in the form of software, so that the processor can call and execute the operations corresponding to the above modules. The aforementioned device can be, but is not limited to, various types of chip verification computers already available in the art.

[0046] In one embodiment, a vehicle-regulatory chip TRGMUX module verification method is provided, which is applied to the vehicle-regulatory chip TRGMUX module verification system, such as Figure 2As shown, the vehicle-grade chip TRGMUX module verification method includes the following steps S10 to S18: S10, execute the automated top-level file script to generate the platform architecture of the TRGMUX module verification system for the automotive chip; S12, executing the automated register configuration script and capturing register information in a given register configuration table, generating a register model according to the register information and integrating it into the generated verification environment layer; S14, execute the automated TRGMUX script and capture the input signal and configurable processing information in the given input configuration table, capture the output signal and configurable processing information in the given output configuration table, and supplement and improve the configuration in the verification system; wherein the process of supplementing and improving the configuration in the verification system includes: generating a master agent according to the input configuration table, filling in the input signal, and filling the processing information in the input configuration table into the configuration file of the master agent, generating a slave agent according to the output configuration table, filling in the output signal, and filling the processing information in the output configuration table into the configuration file of the slave agent; S16, in the platform architecture of the TRGMUX module verification system of the automotive chip, sending input transactions to the TRGMUX module to be verified and capturing output transactions of the TRGMUX module to be verified; S18, in the platform architecture of the automotive chip TRGMUX module verification system, the output result of the TRGMUX module to be verified is compared with the expected output result based on the configuration expectation through the scoreboard to obtain the verification result of the TRGMUX module to be verified.

[0047] The above-mentioned automotive chip TRGMUX module verification method builds a module-level verification system dedicated to automotive chip TRGMUX modules based on the UVM verification platform in response to the actual verification needs of automotive chip TRGMUX modules. It supports rapid customization of the verification environment and verification process of automotive chip TRGMUX modules through configuration files, supports capturing TRGMUX module information through automated scripts and using this information to generate a UVM verification environment to complete the verification of the module, thereby effectively adapting to the completeness verification of various functions of automotive chip TRGMUX modules. Compared with traditional manual verification, the above-mentioned verification system significantly improves the verification efficiency of automotive chip TRGMUX modules, reduces its verification difficulty, and greatly improves the completeness of this type of module verification, providing effective support for further strengthening the safety performance of automotive-grade chips.

[0048] For the specific limitations of the verification method of the automotive chip TRGMUX module, please refer to the corresponding limitations of the automotive chip TRGMUX module verification system in the above text, which will not be repeated here.

[0049] It should be understood that although Figure 2 The steps in the method are shown in sequence as indicated by the arrows, but the steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of the steps, and the steps can be executed in other orders. Figure 2 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequentially, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0050] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided by the present invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus dynamic random access memory (RambusDRAM, referred to as RDRAM) and interface dynamic random access memory (DRDRAM).

[0051] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0052] The above embodiments only express several implementation methods of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of protection of the invention. It should be pointed out that, for those of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present invention, which all belong to the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the attached claims.

Claims

1. A TRGMUX module verification system for automotive grade chips, characterized in that: It includes a verification use case layer, a top connection layer, a verification environment layer and a TRGMUX module to be verified, wherein the verification use case layer is used to simulate the actual use scenario of the TRGMUX module to be verified, and the top connection layer is used to instantiate the TRGMUX module to be verified and connect the instantiated TRGMUX module to be verified to the verification platform through an interface; The verification environment layer includes an apb agent, a master agent, a slave agent, a scoreboard, a virtualization sequencer, a configuration file, and a register model. The apb agent is connected to the TRGMUX module to be verified through an apb interface, the master agent is connected to the TRGMUX module to be verified through an input interface, and the slave agent is connected to the TRGMUX module to be verified through an output interface. The apb agent is used to read and write the register of the TRGMUX module to be verified through the apb interface. The master agent includes multiple master agents, each of which is connected to the input port of the TRGMUX module to be verified, and each of the master agents is used to send input transactions to the TRGMUX module to be verified; the slave agent includes multiple slave agents, each of which is connected to the output port of the TRGMUX module to be verified, and each of the slave agents is used to capture the output transaction of the TRGMUX module to be verified and send it to the scoreboard; The virtualized sequence generator is used to control the execution of the test sequence according to the verification scenario of the TRGMUX module to be verified, the register model is used to perform read and write operations on the registers of the TRGMUX module to be verified, simulate register behavior and monitor register status, the configuration file is used to configure the verification environment, each agent and configure the register model, and the scoreboard is used to compare the output result of the TRGMUX module to be verified with the expected output result based on the configuration expectation, so as to obtain the verification result of the TRGMUX module to be verified.

2. The vehicle-grade chip TRGMUX module verification system according to claim 1 is characterized in that: The apb agent includes an apb stimulus file, an apb sequence generator, an apb main driver and an apb monitor. The apb sequence generator generates an apb sequence according to the apb stimulus file. The apb main driver drives the apb sequence to the TRGMUX module to be verified using an apb port. The apb monitor is used to monitor the apb interface.

3. The vehicle-regulatory chip TRGMUX module verification system according to claim 1 or 2 is characterized in that: Each of the master agents includes an excitation file, a sequencer, a main driver, a port, a monitor and a configuration file. Each of the master agents is connected to the corresponding input port of the TRGMUX module to be verified through a port. Each of the slave agents includes a configuration file, an excitation file, a port and a monitor. Each of the slave agents is connected to the corresponding output port of the TRGMUX module to be verified through a port.

4. The TRGMUX module verification system for automotive chip according to claim 3 is characterized in that: The simulation tools vcs and verdi are integrated into the verification system 5. The vehicle-grade chip TRGMUX module verification system according to claim 4 is characterized in that: The apb protocol bus functional model apb vip is integrated in the verification system.

6. The vehicle-regulatory chip TRGMUX module verification system according to claim 4 or 5, characterized in that: The verification system includes a generated Makefile script, which is used to perform automated compilation, simulation, use case regression, and code and function coverage of the verification system.

7. A TRGMUX module verification method for automotive chip, characterized in that: Applied to the vehicle-regulation chip TRGMUX module verification system according to any one of claims 1 to 6, the vehicle-regulation chip TRGMUX module verification method comprises the steps of: Execute the automated top-level file script to generate the platform architecture of the TRGMUX module verification system for the automotive chip; Execute the automated register configuration script and capture the register information in the given register configuration table, generate a register model based on the register information and integrate it into the generated verification environment layer; Execute the automated TRGMUX script and capture the input signal and configurable processing information in the given input configuration table, capture the output signal and configurable processing information in the given output configuration table, and supplement and improve the configuration in the verification system; wherein the process of supplementing and improving the configuration in the verification system includes: generating a master agent according to the input configuration table, filling in the input signal, and filling the processing information in the input configuration table into the configuration file of the master agent, generating a slave agent according to the output configuration table, filling in the output signal, and filling the processing information in the output configuration table into the configuration file of the slave agent; In the platform architecture of the vehicle-regulatory chip TRGMUX module verification system, an input transaction is sent to the TRGMUX module to be verified and an output transaction of the TRGMUX module to be verified is captured; In the platform architecture of the automotive chip TRGMUX module verification system, the verification result of the TRGMUX module to be verified is obtained by comparing the output result of the TRGMUX module to be verified with the expected output result based on the configuration expectation through the scoreboard.

Images