WO2022148305A1 - 一种芯片的系统级验证方法、系统及相关装置 - Google Patents
一种芯片的系统级验证方法、系统及相关装置 Download PDFInfo
- Publication number
- WO2022148305A1 WO2022148305A1 PCT/CN2021/143310 CN2021143310W WO2022148305A1 WO 2022148305 A1 WO2022148305 A1 WO 2022148305A1 CN 2021143310 W CN2021143310 W CN 2021143310W WO 2022148305 A1 WO2022148305 A1 WO 2022148305A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- module
- verified
- verification
- signal
- port
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/39—Circuit design at the physical level
- G06F30/398—Design verification or optimisation, e.g. using design rule check [DRC], layout versus schematics [LVS] or finite element methods [FEM]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2115/00—Details relating to the type of the circuit
- G06F2115/02—System on chip [SoC] design
Definitions
- the present application relates to the field of chip verification, and in particular, to a system-level verification method, system and related device of a chip.
- SoC system-on-a-chip
- the purpose of this application is to provide a system-level verification method, system, computer-readable storage medium and electronic device for a chip, which can flexibly match modules and improve system-level verification efficiency.
- the present application provides a system-level verification method for a chip, and the specific technical solutions are as follows:
- the module to be verified includes a module to be eliminated and a module to be replaced;
- the module to be verified is replaced by the hollow module and added to the simulation script for system-level verification.
- assigning a value to the port signal in the hollow file to obtain the hollow module includes:
- the port signal is assigned according to the fixed value of the signal to obtain a hollowing module.
- determining the corresponding fixed signal value according to the signal type of the port signal includes:
- the port assignment table is called to determine the corresponding fixed value of the signal according to the signal type of the port signal.
- the co-simulation of the to-be-verified module also includes:
- the co-simulation is performed by adding the generic model validation environment to a simulation script.
- generating the general model verification environment of the module to be verified according to the port definition of the module to be verified includes:
- the port signal is a bus-type port, specify that the bus verification IP corresponding to the bus-type port is mounted on the bus-type port, so as to generate a general model verification environment of the module to be verified;
- the port signal is a non-universal function, configure the activation mode of the sequencer in the general model verification environment, and generate the general model verification environment of the module to be verified;
- the port signal is a general function
- a general model verification environment of the module to be verified is generated.
- the module to be verified also needs to simulate a driver class and a sequence class, it also includes:
- the driver class and the sequence class in the module machine verification environment corresponding to the module to be verified are reused, and participate in the system-level verification.
- the application also provides a system-level verification system for a chip, including:
- the request receiving module is used to receive the verification request
- the module to be verified includes a module to be eliminated and a module to be replaced;
- a knockout file generation module configured to analyze the to-be-verified module to perform a knockout operation by using a knockout script, obtain a port signal, and generate a knockout file in combination with the module path and the module name;
- an assignment module for assigning a value to the port signal in the hollowed-out file to obtain a hollowed-out module
- a verification module configured to replace the module to be verified with the hollow module and add it to a simulation script to perform system-level verification.
- the assignment module includes:
- a value determination unit configured to determine the corresponding fixed value of the signal according to the signal type of the port signal
- an assignment unit configured to assign an assignment to the port signal according to the fixed value of the signal to obtain a hollowing module.
- the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, implements the steps of the above-described method.
- the present application also provides an electronic device, comprising a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps of the above method when the computer program in the memory is invoked.
- the application provides a system-level verification method for a chip, including: receiving a verification request; confirming a module path and module name of a module to be verified according to the verification request; the module to be verified includes a module to be eliminated and a module to be replaced;
- the script parses the to-be-verified module to perform a hollowing operation, obtains a port signal, and generates a hollowing file in combination with the module path and the module name; assigns a value to the port signal in the hollowing file to obtain a hollowing module;
- the module to be verified is replaced by the hollow module and added to the simulation script for system-level verification.
- the hollow module is used to replace the module to be verified to participate in the system-level verification. This can solve the problem that multiple modules cannot be verified collaboratively due to inconsistent design and delivery nodes of different modules.
- the present application also provides a system-level verification system for a chip, a computer-readable storage medium, and an electronic device, which have the above-mentioned beneficial effects, which will not be repeated here.
- FIG. 1 is a flowchart of a system-level verification method for a chip provided by an embodiment of the present application
- FIG. 3 is a schematic structural diagram of a system-level verification system of a chip according to an embodiment of the present application.
- FIG. 1 is a flowchart of a system-level verification method for a chip provided by an embodiment of the present application. The method includes:
- the purpose of this step is to receive a verification request for system-level verification, and the information content included in the verification request is not specifically limited here. It may include the verification object, that is, the relevant information of the module to be verified, or it may not include, and is obtained by the subsequent process according to the verification request, all of which can implement this embodiment and obtain the corresponding technical effects of this embodiment.
- This step aims to confirm the module path and module name of the module to be verified, and the module to be verified may include the module to be eliminated and the module to be replaced.
- the module to be eliminated refers to the module to be deleted, and the module to be replaced can be a module that has not been designed yet, and can be the module to be verified in this embodiment, that is, the system-level verification method of this embodiment is used for verification.
- the module path and module name need to be confirmed according to the verification request, but how to obtain the above information according to the verification request is not specifically limited. If the verification request contains the module path and module name, the verification request can be directly parsed to obtain the module path and module name. If the verification request does not include the above information, the module path and module name can be obtained from the requester according to the path information of the verification request.
- module path and module name are required to be obtained in this step, and in the specific application process of this embodiment, those skilled in the art can also confirm other module-related information of the module to be verified, such as module function, module interface and module Relevant signal information, etc., should also fall within the protection scope of the present application.
- S103 Use a culling script to analyze the module to be verified to perform a hollowing operation, obtain a port signal, and generate a hollowing file in combination with the module path and the module name;
- the purpose of this step is to execute the knockout script, parse the port signal of the module to be verified, and then obtain the knockout file according to the port signal, module path and module name obtained by the analysis.
- culling script is used here, as long as it can parse the port signal of the module to be verified.
- the purpose of this embodiment is to replace the module to be verified with the hollow module, and it is only necessary to simulate the same function of the module to be verified, that is, to ensure that the input signal can be obtained after the input signal is consistent with the expected output result of the module to be verified. The output signal can be used by subsequent modules. Therefore, this step focuses on parsing the port signal of the module to be verified, and generating a corresponding hollow file to prepare for replacing the module to be verified.
- S104 assigning a value to the port signal in the hollow file to obtain a hollow module
- the purpose of this step is to assign a value to the port signal, and the purpose of the assignment is to prevent the unassigned port signal from outputting an uncertain signal, which affects the system-level verification, and may even affect the normal operation of other modules. Therefore, it is necessary to assign values to each port signal.
- a corresponding fixed signal value may be determined according to the signal type of the port signal, and then the port signal may be assigned a value according to the fixed signal value to obtain a hollowing module. Since the purpose of assignment is mainly to avoid the influence of unassigned port signals on system-level verification, a fixed value can be assigned to port signals.
- the fixed value of the signal is related to the signal type of the port signal, and can be calculated or determined in advance by those skilled in the art. In addition, if no assignment is made, all port signals can be connected to a fixed value of 0 by default, so as to avoid adverse effects caused by unassigned port signals. See Table 1. Table 1 is a list of port assignments, including assignment examples of several port signals.
- the hollowed-out file can be used as a hollowed-out module to replace the module to be verified.
- the port assignment table may be invoked to determine the corresponding fixed signal value according to the signal type of the port signal.
- the port assignment table can be as shown in Table 1, including information such as port signal name, type, etc. After the port signal is parsed and obtained in the preceding steps, the logical assignment of each port signal can be obtained by looking up the table, and the assignment is performed for the port signal.
- the module to be verified is replaced by the hollowed-out module and added to the simulation script, and the file is recompiled and linked in the simulation script to perform system-level verification.
- the verification impact on the remaining modules can be reduced when the module to be verified is not completed, and the verification period can be shortened.
- the use of hollow modules to replace the modules to be verified to participate in system-level verification can solve the problem that multiple modules cannot be verified collaboratively due to inconsistent design and delivery nodes of different modules.
- the above-mentioned embodiments aim to realize the replacement process of the module to be verified.
- problems such as different module delivery times.
- the result of this situation is that the collaborative verification can only be carried out after all the related modules are designed, which often slows down the system. progress of level verification.
- the following steps may also be included at this time.
- S201 Generate a general model verification environment of the module to be verified according to the port definition of the module to be verified;
- S202 call the sequence class to drive the general model verification environment
- a general model verification environment of the module to be verified can be generated according to the function category of the port signal of the module to be verified.
- the general model verification environment can be generated based on the existing general verification IP template, but needs to match the function of the module to be verified to be realized, and is driven by the port to complete the collaborative verification with its associated module.
- the port signal is a bus-type port, specify that the bus verification IP corresponding to the bus-type port is mounted on the bus-type port to generate a general model verification environment for the module to be verified; if the port signal is a non-general function, configure the general model verification environment The enabling mode of the sequencer is generated, and the general model verification environment of the module to be verified is generated; if the port signal is a general function, after the sequencer is driven and updated, the general model verification environment of the module to be verified is generated.
- the sequence class in step S202 may be developed in advance, or may be developed on-site, as long as it is adapted to the general model verification environment. Finally, a generic model verification environment can be added to the simulation script for co-simulation.
- the module to be verified also needs to simulate the driver class and the sequence class, it can directly reuse the driver class and sequence class in the module machine verification environment of the module corresponding to the module to be verified, and participate in the system-level verification.
- the driver class and sequence class of its related modules in the module-level verification environment can be reused, which can further improve the module level to the system level. Verifying the reusability of the environment makes the entire reuse simpler and more efficient.
- the main application scenario of this application is the co-simulation verification between modules at the system level.
- system-level verification is in a later stage in the entire verification cycle, such as after all module-level verifications are completed. Because if the module function design and development is not completed and the relevant module functions are not verified, the system-level system verification cannot be started. However, if system-level verification is started after all module-level verifications are completed, the verification period will be lengthened, which will bring great pressure to the entire verification process, especially the system-level verification stage.
- This application allows verification engineers to ensure the completeness of the system-level verification platform through simple parameter configuration when some modules have not yet been designed and developed, or when some modules have not been developed at all, so as to start the system-level stage as soon as possible
- the functional correctness of the system module is guaranteed, which saves time for the entire project verification cycle, and ensures and improves the functional quality of the chip.
- system-level verification system for a chip provided by an embodiment of the present application.
- the system-level verification system described below and the system-level verification method for a chip described above may refer to each other correspondingly.
- FIG. 2 is a schematic structural diagram of a system-level verification system for a chip provided by an embodiment of the application.
- the application also provides a system-level verification system for a chip, including:
- a request receiving module 100 configured to receive a verification request
- the parsing module 200 is used to confirm the module path and module name of the module to be verified according to the verification request; the module to be verified includes a module to be eliminated and a module to be replaced;
- the knockout file generation module 300 is configured to analyze the to-be-verified module to perform a knockout operation by using a knockout script, obtain a port signal, and generate a knockout file in combination with the module path and the module name;
- the assignment module 400 is used for assigning value to the port signal in the hollow file to obtain the hollow module
- the verification module 500 is configured to replace the module to be verified with the hollow module and add it to a simulation script to perform system-level verification.
- the assignment module 400 includes:
- a value determination unit configured to determine the corresponding fixed value of the signal according to the signal type of the port signal
- an assignment unit configured to assign an assignment to the port signal according to the fixed value of the signal to obtain a hollowing module.
- the value determination unit is a unit for invoking a port assignment table to determine a corresponding fixed value of a signal according to a signal type of the port signal.
- the co-simulation module is used to generate a general model verification environment of the to-be-verified module according to the port definition of the to-be-verified module when performing the co-simulation of the to-be-verified module; call the sequence class to drive the general-purpose model verification environment; A verification environment is added to the simulation script to perform the co-simulation.
- the foregoing co-simulation module includes:
- An environment configuration unit configured to generate a general model verification environment of the to-be-verified module according to the functional category of the port signal of the to-be-verified module; if the port signal is a bus-type port, specify the bus verification corresponding to the bus-type port
- the IP is mounted to the bus class port to generate the general model verification environment of the module to be verified; if the port signal is a non-general function, configure the enable mode of the sequencer in the general model verification environment, and generate The general model verification environment of the module to be verified; if the port signal is a general function, after the sequencer is driven and updated, the general model verification environment of the module to be verified is generated.
- the multiplexing module is used for multiplexing the driver class and the sequence class of the relevant module corresponding to the to-be-verified module in the module machine verification environment, and participating in the system-level verification.
- the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed, the steps provided by the above embodiments can be implemented.
- the storage medium may include: U disk, removable hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program codes.
- the present application also provides an electronic device, which may include a memory and a processor, where a computer program is stored in the memory, and when the processor invokes the computer program in the memory, the steps provided in the above embodiments can be implemented.
- the electronic device may also include various network interfaces, power supplies and other components.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Design And Manufacture Of Integrated Circuits (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请提供一种芯片的系统级验证方法，包括：接收验证请求；根据所述验证请求确认待验证模块的模块路径和模块名；所述待验证模块包括待剔除模块和待替换模块；利用剔除脚本解析所述待验证模块执行挖空操作，得到端口信号，并结合所述模块路径和所述模块名生成挖空文件；对所述挖空文件中的端口信号进行赋值，得到挖空模块；利用所述挖空模块替换所述待验证模块添加至仿真脚本进行系统级验证。本申请能够在待验证模块未完成时降低对其余模块的验证影响，缩短验证周期。本申请还提供一种芯片的系统级验证系统、计算机可读存储介质和电子设备，具有上述有益效果。
Description
本申请要求在2021年1月7日提交中国专利局、申请号为202110018482.3、发明名称为“一种芯片的系统级验证方法、系统及相关装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
本申请涉及芯片验证领域，特别涉及一种芯片的系统级验证方法、系统及相关装置。
在整个芯片开发设计流程中，功能验证已经成为最大最耗时间的瓶颈。目前越来越多的芯片设计企业采用核心功能模块自研，通用模块外购的片上系统(System-on-a-chip，SoC)设计策略，却给芯片的系统级功能验证工作带来了严峻的挑战。系统级验证主要确认芯片体系结构满足所赋予的功能/性能要求，通过将用户需求转换成功能/性能要求，并实现行为/功能设计，然后映射到相应的体系结构上(设计输入、硬IP核、软IP核、软/硬件划分、性能分析、总体优化、性价比评估等反复迭代)，最后进行系统级验证。
SoC进行系统仿真时会暴露，IP核与IP核之间信号时序的不匹配、控制逻辑无法协调、功能不能衔接等问题。为了减少在SoC级别上的部署时间，目前主流做法是对模块或子模块的验证组件、环境和方案进行可复用检查并合理的在SoC级别进行复用。在SoC级上，主要关注SoC顶层同各个验证子模块之间的数据交互是否正确。
但如果每一次系统级验证都要重新搭建验证环境、编写验证代码，将耗费巨大的时间成本和人力成本。此外测试过程中时常出现其中某些模块购买或者开发已经完成，而另外一些互联的模块不能及时完成交付从而影响协同功能验证。
发明内容
本申请的目的是提供一种芯片的系统级验证方法、系统、计算机可读存储介质和电子设备，能够灵活搭配模块，提高系统级验证效率。
为解决上述技术问题，本申请提供一种芯片的系统级验证方法，具体技术方案如下：
接收验证请求；
根据所述验证请求确认待验证模块的模块路径和模块名；所述待验证模块包括待剔除模块和待替换模块；
利用剔除脚本解析所述待验证模块执行挖空操作，得到端口信号，并结合所述模块路径和所述模块名生成挖空文件；
对所述挖空文件中的端口信号进行赋值，得到挖空模块；
利用所述挖空模块替换所述待验证模块添加至仿真脚本进行系统级验证。
可选的，对所述挖空文件中的端口信号进行赋值，得到挖空模块包括：
根据所述端口信号的信号类别确定对应的信号固定值；
根据所述信号固定值对所述端口信号进行赋值，得到挖空模块。
可选的，根据所述端口信号的信号类别确定对应的信号固定值包括：
调用端口赋值表根据所述端口信号的信号类别确定对应的信号固定值。
可选的，若进行所述待验证模块的协同仿真，还包括：
根据待验证模块的端口定义生成所述待验证模块的通用模型验证环境；
调用序列类驱动通用模型验证环境；
将所述通用模型验证环境添加至仿真脚本，进行所述协同仿真。
可选的，根据待验证模块的端口定义生成所述待验证模块的通用模型验证环境包括：
根据所述待验证模块的端口信号的功能类别生成所述待验证模块的通用模型验证环境；
若所述端口信号为总线类端口，指定所述总线类端口对应的总线验证IP挂载至所述总线类端口，以生成所述待验证模块的通用模型验证环境；
若所述端口信号为非通用功能，配置所述通用模型验证环境中定序器的启用模式，并生成所述待验证模块的通用模型验证环境；
若所述端口信号为通用功能，对所述定序器进行驱动更新后，生成所述待验证模块的通用模型验证环境。
可选的，若所述待验证模块还需要模拟驱动类和序列类，还包括：
复用与所述待验证模块对应相关模块在模块机验证环境中的驱动类和序列类，并参与所述系统级验证。
本申请还提供一种芯片的系统级验证系统，包括：
请求接收模块，用于接收验证请求；
解析模块，用于根据所述验证请求确认待验证模块的模块路径和模块名；所述待验证模块包括待剔除模块和待替换模块；
挖空文件生成模块，用于利用剔除脚本解析所述待验证模块执行挖空操作，得到端口信号，并结合所述模块路径和所述模块名生成挖空文件；
赋值模块，用于对所述挖空文件中的端口信号进行赋值，得到挖空模块；
验证模块，用于利用所述挖空模块替换所述待验证模块添加至仿真脚本进行系统级验证。
可选的，所述赋值模块包括：
值确定单元，用于根据所述端口信号的信号类别确定对应的信号固定值；
赋值单元，用于根据所述信号固定值对所述端口信号进行赋值，得到挖空模块。
本申请还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的方法的步骤。
本申请还提供一种电子设备，包括存储器和处理器，所述存储器中存有计算机程序，所述处理器调用所述存储器中的计算机程序时实现如上所述的方法的步骤。
本申请提供一种芯片的系统级验证方法，包括：接收验证请求；根据所述验证请求确认待验证模块的模块路径和模块名；所述待验证模块包括待剔除模块和待替换模块；利用剔除脚本解析所述待验证模块执行挖空操作，得到端口信号，并结合所述模块路径和所述模块名生成挖空文件；对所述挖空文件中的端口信号进行赋值，得到挖空模块；利用所述挖空模块替换所述待验证模块添加至仿真脚本进行系统级验证。
本申请通过对待验证模块进行解析和复制，并生成对应的挖空模块作为待验证模块的替代品参与系统级验证，能够在待验证模块未完成时降低对其余模块的验证影响，缩短验证周期，同时采用挖空模块替代待验证模块参与系统级验证该你可以解决由于不同模块设计交付节点不一致导致的多模块无 法协同验证的问题。
本申请还提供一种芯片的系统级验证系统、计算机可读存储介质和电子设备，具有上述有益效果，此处不再赘述。
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请实施例所提供的一种芯片的系统级验证方法的流程图；
图2为本申请实施例所提供的协同验证方法的流程图；
图3为本申请实施例所提供的一种芯片的系统级验证系统结构示意图。
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
一颗芯片里逻辑功能模块的开发一般是由不同的架构和设计工程师负责，基于不同模块的复杂难易程度，所有模块的设计往往会发生交付时间先后不一，设计质量参差不齐等问题。这些问题会影响到相应的系统级集成设计，进而影响到芯片的系统级验证工作。基于这样的场景，在系统级功能验证阶段，当出问题的模块和其他模块之间交互性不大，不会因为该模块的缺失而影响其它模块的协同仿真时，本申请可以在原有系统级验证环境不变的基础上，通过简单参数的传递和信号的赋值来快速完成该模块在待测设计里的移除和替换操作，具体步骤可以如下：
请参考图1，图1为本申请实施例所提供的一种芯片的系统级验证方法的流程图，该方法包括：
S101：接收验证请求；
本步骤旨在接收系统级验证的验证请求，在此对于该验证请求所包含的信息内容不作具体限定。其可以包含验证对象，即待验证模块的相关信息，也可以不包含，由后续过程根据验证请求获取，均可以实现本实施例，并得到本实施例对应的技术效果。
S102：根据所述验证请求确认待验证模块的模块路径和模块名；
本步骤旨在确认待验证模块的模块路径和模块名，而该待验证模块可以包括待剔除模块和待替换模块。待剔除模块指需要被删除的模块，待替换模块可以为当前尚未设计完成的模块，均可以为本实施例中的待验证模块，即利用本实施例的系统级验证方法进行验证。
本步骤需要根据验证请求确认模块路径和模块名，但对于如何根据验证请求获得上述信息不作具体限定。若验证请求中包含模块路径和模块名，则可以直接解析验证请求以得到模块路径和模块名。若验证请求中不包括上述信息，则可以根据验证请求的路径信息向请求方获取模块路径和模块名。
此外，本步骤中要求至少获得模块路径和模块名，而在本实施例的具体应用过程中，本领域技术人员还可以确认待验证模块的其他模块相关信息，例如模块功能、模块接口和模块的相关信号信息等等，也应在本申请的保护范围内。
S103：利用剔除脚本解析所述待验证模块执行挖空操作，得到端口信号，并结合模块路径和所述模块名生成挖空文件；
本步骤旨在执行剔除脚本，对待验证模块的端口信号进行解析，再根据解析得到的端口信号、模块路径和模块名得到挖空文件。在此对于采用何种剔除脚本不作具体限定，只要其可以解析待验证模块的端口信号即可。需要注意的是，本实施例的目的在于利用挖空模块替换待验证模块，而只需要模拟出待验证模块的相同作用即可，即保证输入信号输入后可以得到与待验证模块预期输出结果一致的输出信号供后续模块使用即可，因此，本步骤重点在于解析待验证模块的端口信号，以及生成相应的挖空文件，为替换待验证模块做准备。
S104：对所述挖空文件中的端口信号进行赋值，得到挖空模块；
本步骤旨在对端口信号进行赋值，赋值的目的在于避免未赋值的端口信号输出不确定信号，影响系统级验证，甚至可能影响其他模块的正常运行。 因此，需要对各端口信号进行赋值。可选的，在执行本步骤时，可以先根据端口信号的信号类别确定对应的信号固定值，再根据所述信号固定值对端口信号进行赋值，得到挖空模块。由于赋值的目的主要在于避免未赋值的端口信号对于系统级验证的影响，因此可以给端口信号赋固定值。该信号固定值与端口信号的信号类别相关，可以由本领域技术人事先计算或者确定。此外，如果不赋值，可以默认所有端口信号都接固定值0，以避免未赋值的端口信号造成不良影响。参见表1，表1为端口赋值列表，包含了几种端口信号的赋值示例。
表1端口赋值列表
| 信号名 | 类型 | 位宽 | 逻辑赋值 | 注释 |
| moduleA_clk_i | input | 1 | always 100M | 100M时钟 |
| moduleA_rst_n | input | 1 | 0,0us；1，1us | 0时刻0，1微秒赋1 |
| moduleA_req_i | input | 1 | 1 | 始终1 |
| moduleA_ack_o | output | 1 | 0,0us；1，1us | 0时刻0，1微秒赋1 |
| moduleA_bus1_o | output | [15:0] | 15'hffff | 输出全1 |
| moduleA_data_o | output | [31:0] | 32'b0 | 输出32位0 |
赋值后，挖空文件即可作为挖空模块，替代待验证模块。
此外，作为一种可选的执行方式，在执行本步骤时，可以调用端口赋值表根据端口信号的信号类别确定对应的信号固定值。该端口赋值表可以如表1所示，包含端口信号名称、类型等信息，当前述步骤中解析得到端口信号后，即可查表得到每个端口信号的逻辑赋值，并针对端口信号进行赋值。
S105：利用所述挖空模块替换所述待验证模块添加至仿真脚本进行系统级验证。
在得到挖空模块后，利用挖空模块替换所述待验证模块添加至仿真脚本，在仿真脚本中重新编译和链接该文件，进行系统级验证。
本申请实施例通过对待验证模块进行解析和复制，并生成对应的挖空模块作为待验证模块的替代品参与系统级验证，能够在待验证模块未完成时降低对其余模块的验证影响，缩短验证周期，同时采用挖空模块替代待验证模块参与系统级验证可以解决由于不同模块设计交付节点不一致导致的多模块无法协同验证的问题。
在上述实施例的基础上，上述实施例旨在实现待验证模块的替换过程。而在系统级验证中的模块协同验证时，也存在模块交付时间不一等问题，这种情况导致的结果就是只能等到相关的模块全部设计完成后才能进行协同验证，这样往往会拖慢系统级验证的进度。为了能够尽快开始系统级的协同验证，至少保证已设计完成的模块不会被未完成模块所影响，此时还可以包括如下步骤，参见图2，图2为本申请实施例所提供的协同验证方法的流程图：
S201：根据待验证模块的端口定义生成待验证模块的通用模型验证环境；
S202：调用序列类驱动通用模型验证环境；
S203：将通用模型验证环境添加至仿真脚本，进行协同仿真。
在执行步骤S201时，可以根据待验证模块的端口信号的功能类别生成待验证模块的通用模型验证环境。该通用模型验证环境可以基于已有的通用验证IP模板生成，但需要匹配待验证模块的功能加以实现，并通过端口驱动以完成和其关联模块的协同验证。
首先需要明确待验证模块的端口信号的功能划分。若端口信号为总线类端口，指定总线类端口对应的总线验证IP挂载至总线类端口，以生成待验证模块的通用模型验证环境；若端口信号为非通用功能，配置通用模型验证环境中定序器的启用模式，并生成待验证模块的通用模型验证环境；若端口信号为通用功能，对定序器进行驱动更新后，生成待验证模块的通用模型验证环境。
步骤S202中的序列类可以事先开发完毕，也可以现场开发，适配通用模型验证环境即可。最后可以将通用模型验证环境添加至仿真脚本，进行协同仿真。
此外，若待验证模块还需要模拟驱动类和序列类，可以直接复用与待验证模块对应相关模块在模块机验证环境中的驱动类和序列类，并参与系统级验证。
当要替换的待验证模块需要开发模拟该模块的驱动类和序列类时，完全可以复用和其相关模块在模块级验证环境里的驱动类和序列类，可以进一步提升从模块级到系统级验证环境的复用性，让整个复用变得更加简单高效。
本申请主要的应用场景是系统级阶段模块间的协同仿真验证。一般系统级验证在整个验证周期都是排在比较靠后的阶段，比如所有模块级验证都结 束后。因为如果模块功能设计开发没有完成，相关模块功能没有验证通过的话，系统级的系统验证是没法开始的。但是如果所有模块级验证结束后再来启动系统级验证的话，就会加长验证周期，给整个验证环节尤其系统级验证阶段带来很大的压力。本申请可以让验证工程师在部分模块还没有设计开发完成时，又或者在部分模块压根还没有开发时，就可以通过简单的参数配置来保证系统级验证平台的完备性，来尽早开始系统级阶段的模块协同验证工作，在简单高效的测试方法的基础上保证系统模块的功能正确性，为整个项目验证周期节约时间，保证并提升芯片功能质量。
下面对本申请实施例提供的一种芯片的系统级验证系统进行介绍，下文描述的系统级验证系统与上文描述的芯片的系统级验证方法可相互对应参照。
参见图2，图2为本申请实施例所提供的一种芯片的系统级验证系统结构示意图，本申请还提供一种芯片的系统级验证系统，包括：
请求接收模块100，用于接收验证请求；
解析模块200，用于根据所述验证请求确认待验证模块的模块路径和模块名；所述待验证模块包括待剔除模块和待替换模块；
挖空文件生成模块300，用于利用剔除脚本解析所述待验证模块执行挖空操作，得到端口信号，并结合所述模块路径和所述模块名生成挖空文件；
赋值模块400，用于对所述挖空文件中的端口信号进行赋值，得到挖空模块；
验证模块500，用于利用所述挖空模块替换所述待验证模块添加至仿真脚本进行系统级验证。
基于上述实施例，作为可选的实施例，所述赋值模块400包括：
值确定单元，用于根据所述端口信号的信号类别确定对应的信号固定值；
赋值单元，用于根据所述信号固定值对所述端口信号进行赋值，得到挖空模块。
基于上述实施例，作为可选的实施例，所述值确定单元为用于调用端口赋值表根据所述端口信号的信号类别确定对应的信号固定值的单元。
基于上述实施例，作为可选的实施例，还包括：
协同仿真模块，用于进行所述待验证模块的协同仿真时，根据待验证模块的端口定义生成所述待验证模块的通用模型验证环境；调用序列类驱动通用模型验证环境；将所述通用模型验证环境添加至仿真脚本，进行所述协同仿真。
基于上述实施例，作为可选的实施例，上述协同仿真模块包括：
环境配置单元，用于根据所述待验证模块的端口信号的功能类别生成所述待验证模块的通用模型验证环境；若所述端口信号为总线类端口，指定所述总线类端口对应的总线验证IP挂载至所述总线类端口，以生成所述待验证模块的通用模型验证环境；若所述端口信号为非通用功能，配置所述通用模型验证环境中定序器的启用模式，并生成所述待验证模块的通用模型验证环境；若所述端口信号为通用功能，对所述定序器进行驱动更新后，生成所述待验证模块的通用模型验证环境。
基于上述实施例，作为可选的实施例，还可以包括：
复用模块，用于复用与所述待验证模块对应相关模块在模块机验证环境中的驱动类和序列类，并参与所述系统级验证。
本申请还提供了一种计算机可读存储介质，其上存有计算机程序，该计算机程序被执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本申请还提供了一种电子设备，可以包括存储器和处理器，所述存储器中存有计算机程序，所述处理器调用所述存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然所述电子设备还可以包括各种网络接口，电源等组件。
说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例提供的系统而言，由于其与实施例提供的方法相对应，所以描述的 比较简单，相关之处参见方法部分说明即可。
本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。
还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
Claims (10)
- 一种芯片的系统级验证方法，其特征在于，包括：接收验证请求；根据所述验证请求确认待验证模块的模块路径和模块名；所述待验证模块包括待剔除模块和待替换模块；利用剔除脚本解析所述待验证模块执行挖空操作，得到端口信号，并结合所述模块路径和所述模块名生成挖空文件；对所述挖空文件中的端口信号进行赋值，得到挖空模块；利用所述挖空模块替换所述待验证模块添加至仿真脚本进行系统级验证。
- 根据权利要求1所述的系统级验证方法，其特征在于，对所述挖空文件中的端口信号进行赋值，得到挖空模块包括：根据所述端口信号的信号类别确定对应的信号固定值；根据所述信号固定值对所述端口信号进行赋值，得到挖空模块。
- 根据权利要求2所述的系统级验证方法，其特征在于，根据所述端口信号的信号类别确定对应的信号固定值包括：调用端口赋值表根据所述端口信号的信号类别确定对应的信号固定值。
- 根据权利要求1所述的系统级验证方法，其特征在于，若进行所述待验证模块的协同仿真，还包括：根据待验证模块的端口定义生成所述待验证模块的通用模型验证环境；调用序列类驱动通用模型验证环境；将所述通用模型验证环境添加至仿真脚本，进行所述协同仿真。
- 根据权利要求4所述的系统级验证方法，其特征在于，根据待验证模块的端口定义生成所述待验证模块的通用模型验证环境包括：根据所述待验证模块的端口信号的功能类别生成所述待验证模块的通用模型验证环境；若所述端口信号为总线类端口，指定所述总线类端口对应的总线验证IP挂载至所述总线类端口，以生成所述待验证模块的通用模型验证环境；若所述端口信号为非通用功能，配置所述通用模型验证环境中定序器的启用模式，并生成所述待验证模块的通用模型验证环境；若所述端口信号为通用功能，对所述定序器进行驱动更新后，生成所述待验证模块的通用模型验证环境。
- 根据权利要求4所述的系统级验证方法，其特征在于，若所述待验证模块还需要模拟驱动类和序列类，还包括：复用与所述待验证模块对应相关模块在模块机验证环境中的驱动类和序列类，并参与所述系统级验证。
- 一种芯片的系统级验证系统，其特征在于，包括：请求接收模块，用于接收验证请求；解析模块，用于根据所述验证请求确认待验证模块的模块路径和模块名；所述待验证模块包括待剔除模块和待替换模块；挖空文件生成模块，用于利用剔除脚本解析所述待验证模块执行挖空操作，得到端口信号，并结合所述模块路径和所述模块名生成挖空文件；赋值模块，用于对所述挖空文件中的端口信号进行赋值，得到挖空模块；验证模块，用于利用所述挖空模块替换所述待验证模块添加至仿真脚本进行系统级验证。
- 根据权利要求7所述的系统级验证系统，其特征在于，所述赋值模块包括：值确定单元，用于根据所述端口信号的信号类别确定对应的信号固定值；赋值单元，用于根据所述信号固定值对所述端口信号进行赋值，得到挖空模块。
- 一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-6任一项所述的芯片的系统级验证方法的步骤。
- 一种电子设备，其特征在于，包括存储器和处理器，所述存储器中存有计算机程序，所述处理器调用所述存储器中的计算机程序时实现如权利要求1-6任一项所述的芯片的系统级验证方法的步骤。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110018482.3A CN112733490A (zh) | 2021-01-07 | 2021-01-07 | 一种芯片的系统级验证方法、系统及相关装置 |
| CN202110018482.3 | 2021-01-07 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2022148305A1 true WO2022148305A1 (zh) | 2022-07-14 |
Family
ID=75591036
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2021/143310 Ceased WO2022148305A1 (zh) | 2021-01-07 | 2021-12-30 | 一种芯片的系统级验证方法、系统及相关装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN112733490A (zh) |
| WO (1) | WO2022148305A1 (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115470751A (zh) * | 2022-09-22 | 2022-12-13 | 沐曦科技(北京)有限公司 | 基于内存数据库的追踪信息生成系统 |
| CN116090376A (zh) * | 2023-04-10 | 2023-05-09 | 芯来智融半导体科技(上海)有限公司 | 芯片集成验证组件开发方法、装置及计算机设备 |
| CN118093448A (zh) * | 2024-04-29 | 2024-05-28 | 浪潮云信息技术股份公司 | 基于信创操作系统核心功能的全量测试方法、设备及介质 |
| CN118536442A (zh) * | 2024-07-25 | 2024-08-23 | 上海灵动微电子股份有限公司 | Dft信号数据处理方法、dft设计方法及验证方法 |
| CN119026561A (zh) * | 2023-05-25 | 2024-11-26 | 成都融见软件科技有限公司 | 基于python语言的芯片系统级验证系统 |
| CN119150768A (zh) * | 2024-11-15 | 2024-12-17 | 格创通信(浙江)有限公司 | 一种芯片验证方法、装置、电子设备及存储介质 |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112733490A (zh) * | 2021-01-07 | 2021-04-30 | 苏州浪潮智能科技有限公司 | 一种芯片的系统级验证方法、系统及相关装置 |
| CN113361220A (zh) * | 2021-06-22 | 2021-09-07 | 无锡江南计算技术研究所 | 一种对集成电路设计自动裁剪的验证环境构建方法及装置 |
| CN114417763B (zh) * | 2022-01-20 | 2025-07-25 | 山东云海国创云计算装备产业创新中心有限公司 | 一种形式验证的方法、系统、设备和存储介质 |
| CN114528792B (zh) * | 2022-02-18 | 2023-08-29 | 杭州爱芯元智科技有限公司 | 芯片验证方法、装置、电子设备及存储介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7100133B1 (en) * | 2000-06-23 | 2006-08-29 | Koninklijke Philips Electronics N.V | Computer system and method to dynamically generate system on a chip description files and verification information |
| CN106295048A (zh) * | 2016-08-19 | 2017-01-04 | 西安电子科技大学 | 一种数字芯片功能验证方法及系统 |
| CN111859827A (zh) * | 2020-06-29 | 2020-10-30 | 山东云海国创云计算装备产业创新中心有限公司 | 一种芯片ip集成方法、装置及电子设备和存储介质 |
| CN111859832A (zh) * | 2020-07-16 | 2020-10-30 | 山东云海国创云计算装备产业创新中心有限公司 | 一种芯片仿真验证方法、装置及相关设备 |
| CN112733490A (zh) * | 2021-01-07 | 2021-04-30 | 苏州浪潮智能科技有限公司 | 一种芯片的系统级验证方法、系统及相关装置 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101008962A (zh) * | 2006-12-29 | 2007-08-01 | 深圳市明微电子有限公司 | 可配置可替换的网络芯片使用参考模型的验证方法 |
| CN103150438B (zh) * | 2013-03-12 | 2016-01-06 | 青岛中星微电子有限公司 | 一种电路编译方法及装置 |
| CN103713993B (zh) * | 2013-05-30 | 2015-07-22 | 深圳市汇春科技有限公司 | 芯片验证平台及其实现芯片测试的方法 |
| CN108228973A (zh) * | 2017-12-14 | 2018-06-29 | 天津津航计算技术研究所 | 一种模块接口验证组件的生成方法 |
-
2021
- 2021-01-07 CN CN202110018482.3A patent/CN112733490A/zh active Pending
- 2021-12-30 WO PCT/CN2021/143310 patent/WO2022148305A1/zh not_active Ceased
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7100133B1 (en) * | 2000-06-23 | 2006-08-29 | Koninklijke Philips Electronics N.V | Computer system and method to dynamically generate system on a chip description files and verification information |
| CN106295048A (zh) * | 2016-08-19 | 2017-01-04 | 西安电子科技大学 | 一种数字芯片功能验证方法及系统 |
| CN111859827A (zh) * | 2020-06-29 | 2020-10-30 | 山东云海国创云计算装备产业创新中心有限公司 | 一种芯片ip集成方法、装置及电子设备和存储介质 |
| CN111859832A (zh) * | 2020-07-16 | 2020-10-30 | 山东云海国创云计算装备产业创新中心有限公司 | 一种芯片仿真验证方法、装置及相关设备 |
| CN112733490A (zh) * | 2021-01-07 | 2021-04-30 | 苏州浪潮智能科技有限公司 | 一种芯片的系统级验证方法、系统及相关装置 |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115470751A (zh) * | 2022-09-22 | 2022-12-13 | 沐曦科技(北京)有限公司 | 基于内存数据库的追踪信息生成系统 |
| CN115470751B (zh) * | 2022-09-22 | 2023-06-06 | 沐曦科技(北京)有限公司 | 基于内存数据库的追踪信息生成系统 |
| CN116090376A (zh) * | 2023-04-10 | 2023-05-09 | 芯来智融半导体科技(上海)有限公司 | 芯片集成验证组件开发方法、装置及计算机设备 |
| CN116090376B (zh) * | 2023-04-10 | 2023-08-15 | 芯来智融半导体科技(上海)有限公司 | 芯片集成验证组件开发方法、装置及计算机设备 |
| CN119026561A (zh) * | 2023-05-25 | 2024-11-26 | 成都融见软件科技有限公司 | 基于python语言的芯片系统级验证系统 |
| CN118093448A (zh) * | 2024-04-29 | 2024-05-28 | 浪潮云信息技术股份公司 | 基于信创操作系统核心功能的全量测试方法、设备及介质 |
| CN118536442A (zh) * | 2024-07-25 | 2024-08-23 | 上海灵动微电子股份有限公司 | Dft信号数据处理方法、dft设计方法及验证方法 |
| CN119150768A (zh) * | 2024-11-15 | 2024-12-17 | 格创通信(浙江)有限公司 | 一种芯片验证方法、装置、电子设备及存储介质 |
| CN119150768B (zh) * | 2024-11-15 | 2025-05-09 | 格创通信(浙江)有限公司 | 一种芯片验证方法、装置、电子设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112733490A (zh) | 2021-04-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2022148305A1 (zh) | 一种芯片的系统级验证方法、系统及相关装置 | |
| CN106940428B (zh) | 芯片验证方法、装置及系统 | |
| CN111859834B (zh) | 一种基于uvm的验证平台开发方法、系统、终端及存储介质 | |
| US5953519A (en) | Method and system for generating electronic hardware simulation models | |
| US20230153158A1 (en) | Method, apparatus, system, and storage medium for performing eda task | |
| CN114912391A (zh) | 寄存器设计和验证模型自动生成方法、装置、设备及介质 | |
| CN106021111A (zh) | 接口测试方法及系统 | |
| CN102404167B (zh) | 基于变量依赖的并行扩展有限状态机的协议测试生成方法 | |
| CN102486749B (zh) | 数据驱动测试方法及系统 | |
| CN102014016A (zh) | 一种网络协议缺陷测试系统及方法 | |
| CN102866944A (zh) | 一种压力测试系统及方法 | |
| CN116303034A (zh) | 一种片上网络的自动测试系统、方法、设备及介质 | |
| CN103986669A (zh) | 一种云计算中资源分配策略的评估方法 | |
| CN115544922B (zh) | 可配置支持多种工作模式的PCIe验证IP自动集成方法及系统 | |
| CN116341428A (zh) | 构建参考模型的方法、芯片验证方法及系统 | |
| CN118503106A (zh) | 一种芯片验证方法及系统 | |
| CN114239453B (zh) | 仿真验证平台构建方法、仿真验证方法、装置及设备 | |
| CN115987821A (zh) | 网关路由测试方法及装置 | |
| CN103019931A (zh) | Asn.1接口的检测处理方法和装置 | |
| CN114896919A (zh) | 一种基于fpga的集成电路原型验证系统及方法 | |
| CN118646689A (zh) | 片上网络测试平台的生成方法、装置、电子设备及介质 | |
| CN114548027A (zh) | 在验证系统中追踪信号的方法、电子设备及存储介质 | |
| CN113779918A (zh) | SoC仿真方法、装置、计算设备和计算机存储介质 | |
| CN115114755A (zh) | 片上网络的仿真模型生成方法、装置、电子设备及计算机可读存储介质 | |
| CN114880045A (zh) | 寄存器配置方法、装置及相关设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21917344 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 21917344 Country of ref document: EP Kind code of ref document: A1 |