一种验证平台管理方法及装置与流程

文档序号:13422210阅读:161来源:国知局
一种验证平台管理方法及装置与流程

本发明涉及集成电路设计验证领域,尤其涉及一种验证平台管理方法及装置。



背景技术:

目前,对集成电路的验证平台的管理通常使用脚本进行实现。

现有技术中,一种方式,采用makefile脚本进行管理,对于简单的小模块验证可以使用makefile进行管理,比较方便,因为模块简单,验证环境就相对的简单。但如果是一个复杂的模块,它的验证环境也会复杂,管理这种复杂的结构就体现了makefile的局限性。

为了解决对验证多个模块的管理,以及操作流程上的方便,现有技术中,另一种方式,使用shell语言或者perl语言的脚本对验证平台进行管理,通过perl语言编写的多个脚本来实现,每个功能对应一个脚本。

参阅图1所示,现有技术中,验证平台的管理平台需要一个脚本集合,每一个功能的脚本简单地组成一个集合,这样,这种集合的结构,可以方便的在项目间移植,也实现了可扩展性。但是这种结构虽然对验证平台的管理有一定的优化,但是每一个功能都需要先找到对应的脚本的位置才能实现,而且每个脚本根据功能的不同可能会在不同的文件夹中,这样就导致脚本的管理非常复杂。



技术实现要素:

本发明实施例提供一种验证平台管理方法及装置,以解决现有技术中验证平台管理的复杂性高的问题。

本发明实施例提供的具体技术方案如下:

一种验证平台管理方法,针对所述验证平台,预先设计脚本的三层结构,包括入口脚本、一级功能脚本和二级功能脚本,具体包括:

接收到命令时,根据入口脚本中预设的命令与一级功能脚本的映射关系,确定所述命令对应的一级功能脚本;

根据所述命令中配置的验证环境变量,确定所述一级功能脚本对应的二级功能脚本的执行情况;

根据确定的一级功能脚本和所述一级功能脚本对应的二级功能脚本的执行情况,运行一级功能脚本和二级功能脚本,进行验证。

较佳的,所述入口脚本,表示保存有一级功能脚本与命令的映射关系,并用于识别命令的脚本;

所述一级功能脚本,表示根据验证过程中相对独立的功能,编写的独立功能脚本;

所述二级功能脚本,表示根据一级功能脚本中不同功能的划分,编写的功能脚本。

较佳的,进一步包括:

若增加新的一级功能脚本,则在所述入口脚本中创建所述新的一级功能脚本与命令的映射关系。

较佳的,进一步包括:

当确定移植脚本时,在移植过程中,不修改所述一级功能脚本,并根据实际需求,修改相应的二级功能脚本。

较佳的,所述命令的格式为:入口脚本的名称+空格+入口脚本解析后确定的对应的一级功能脚本+空格+一级功能脚本所需的配置的验证环境变量。

较佳的,所述入口脚本、一级功能脚本和二级功能脚本,使用perl语言或shell语言编写。

较佳的,接收到命令之前,进一步包括:

根据验证所需的基础文件,生成基础目录;

较佳的,进一步包括:在验证过程中,根据所述命令和所述基础文件,生成编译目录和仿真目录,并根据所述编译目录和仿真目录,运行对应的一级功能脚本和二级功能脚本,以及,在确定验证完成后,删除所述编译目录和仿真目录。

一种验证平台管理装置,针对所述验证平台,预先设计脚本的三层结构,包括入口脚本、一级功能脚本和二级功能脚本,具体包括:

第一确定单元,用于接收到命令时,根据入口脚本中预设的命令与一级功能脚本的映射关系,确定所述命令对应的一级功能脚本;

第二确定单元,用于根据所述命令中配置的验证环境变量,确定所述一级功能脚本对应的二级功能脚本的执行情况;

运行单元,用于根据确定的一级功能脚本和所述一级功能脚本对应的二级功能脚本的执行情况,运行一级功能脚本和二级功能脚本,进行验证。

较佳的,所述入口脚本,表示保存有一级功能脚本与命令的映射关系,并用于识别命令的脚本;

所述一级功能脚本,表示根据验证过程中相对独立的功能,编写的独立功能脚本;

所述二级功能脚本,表示根据一级功能脚本中不同功能的划分,编写的功能脚本。

较佳的,进一步包括:

更新单元,用于若增加新的一级功能脚本,则在所述入口脚本中创建所述新的一级功能脚本与命令的映射关系。

较佳的,进一步包括:

移植单元,用于当确定移植脚本时,在移植过程中,不修改所述一级功能脚本,并根据实际需求,修改相应的二级功能脚本。

较佳的,所述命令的格式为:入口脚本的名称+空格+入口脚本解析后确定的对应的一级功能脚本+空格+一级功能脚本所需的配置的验证环境变量。

较佳的,所述入口脚本、一级功能脚本和二级功能脚本,使用perl语言或shell语言编写。

较佳的,进一步包括:

生成单元,用于接收到命令之前,根据验证所需的基础文件,生成基础目录,并在验证过程中,根据所述命令和所述基础文件,生成编译目录和仿真目录;

运行单元,进一步用于根据所述编译目录和仿真目录,运行对应的一级功能脚本和二级功能脚本;

删除单元,用于在确定验证完成后,删除所述编译目录和仿真目录。

一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述任一种验证平台管理方法的步骤。

针对所述验证平台,预先设计脚本的三层结构,包括入口脚本、一级功能脚本和二级功能脚本,具体包括:接收到命令时,根据入口脚本中预设的命令与一级功能脚本的映射关系,确定所述命令对应的一级功能脚本;根据所述命令中配置的验证环境变量,确定所述一级功能脚本对应的二级功能脚本的执行情况;根据确定的一级功能脚本和所述一级功能脚本对应的二级功能脚本的执行情况,运行一级功能脚本和二级功能脚本,进行验证,这样,设计脚本结构为包括入口脚本、一级功能脚本和二级功能脚本的三层结构,这种脚本结构不仅具有很高的移植性和扩展性,而且也极大简化了脚本管理的复杂性,提高了对验证平台的管理效率。基于该脚本结构,接收到命令时,通过入口脚本的解析,可以选择执行相应的一级功能脚本和二级功能脚本,不需要用户在验证时查找功能脚本的位置,只需预先了解入口脚本中的命令即可,非常简单,降低了对验证平台管理的复杂性。

附图说明

图1为现有技术中,验证平台的管理脚本集;

图2为本发明实施例中,设计的脚本的三层结构;

图3为本发明实施例中,对于不同的项目,收集仿真数据脚本的数据变化;

图4为本发明实施例中,验证平台管理方法流程图;

图5为本发明实施例中,验证平台管理装置结构图。

具体实施方式

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,并不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

为了解决现有技术中验证平台管理的复杂性高的问题,本发明实施例中,设计了一种脚本结构,为脚本的三层结构,接收到命令时,通过入口脚本对该命令进行解析,确定该命令对应的一级功能脚本,并根据命令中配置的验证环境变量,确定所述一级功能脚本对应的二级功能脚本的执行情况,进而运行一级功能脚本和二级功能脚本,进行验证。

下面通过具体实施例对本发明方案进行详细描述,当然,本发明并不限于以下实施例。

实际中,对于集成电路的验证平台的管理,通常采用脚本进行实现,每个功能对应一个脚本,构成一个集合,在验证运行过程中,需要从这个集合中先找到脚本的位置,由于脚本数量比较多,并且每个脚本根据功能的不同可能会在不同的文件夹中,因此,找起来不太方便,对脚本的管理比较复杂,不利于用户的使用,本发明实施例中,对于验证平台的管理,预先设计了三层结构的脚本结构,便于脚本的查找和管理,同时也具有很高的可扩展性和移植性。

因此,为便于后续描述,下面先对本发明实施例中,设计的脚本的三层结构进行介绍。

参阅图2所示,为本发明实施例中,设计的脚本的三层结构。

本发明实施例中,针对验证平台的管理的脚本,设计出一种脚本结构,为三层结构,包括入口脚本、一级功能脚本和二级功能脚本。

其中,入口脚本、一级功能脚本和二级功能脚本,使用perl语言或shell语言编写。当然也可以采用其它的语言进行编写,本发明实施例中,并不进行限制。

1)入口脚本。

入口脚本,表示保存有一级功能脚本与命令的映射关系,并用于识别命令的脚本。

本发明实施例中,针对每个一级功能脚本,分别预先设置每个一级功能脚本对应的命令,进而在入口脚本中分别建立每个一级功能脚本与对应的命令的映射关系。

这样,入口脚本可以很容易地根据接收到的命令,自动找到该命令对应的一级功能脚本,无需用户一个一个地在目录结构中寻找所需的脚本,用户只需了解入口脚本的命令,即可调用对应的功能脚本,脚本管理非常简单方便。

进一步地,若增加新的一级功能脚本,则在所述入口脚本中创建所述新的一级功能脚本与命令的映射关系。

也就是说,本发明实施例中,可以增加新的一级功能脚本,只需相应地在入口脚本中创建这个新的一级功能脚本的入口,即为该新的一级功能脚本设置一个命令,并建立新的一级功能脚本与该命令的映射关系,入口脚本能够扩展更多的一级功能脚本,进而,使得本发明实施例中,脚本的三层结构,具有很高的扩展性。

并且,本发明实施例中,入口脚本中建立的一级功能脚本与命令的映射关系,可以不需要修改,便于用户了解每个一级功能脚本对应的命令。

2)一级功能脚本。

一级功能脚本,表示根据验证过程中相对独立的功能,编写的独立功能脚本。

也就是说,本发明实施例中,根据验证过程需要使用到的功能或工作,较佳的,为相对独立的功能,将这些相对独立的功能,编写为一级功能脚本,例如,参阅图2所示,一级功能脚本可以为,编译脚本、仿真脚本、启动verdi脚本等,用户可以根据实际情况,编写多个一级功能脚本。

进一步地,可以增加一级功能脚本,例如,如果在验证过程中解决了某个问题,编写了一个脚本,并且,该脚本对其它项目也有帮助,则可以增加该脚本,只需在入口脚本中创建该脚本与命令的映射关系,就可以在之后使用该脚本。

并且,本发明实施例中,由于一级功能脚本是在项目中各个验证阶段需要使用到的相对独立的功能,因此,可以很方便地移植到另一个项目中,并且一级功能脚本,一般在移植过程中不会进行修改,对于多个不同的项目都可以适用。

3)二级功能脚本。

二级功能脚本,表示根据一级功能脚本中不同功能的划分,编写的功能脚本。

本发明实施例中,进一步地设置一级功能脚本对应的二级功能脚本,这是因为,在某些一级功能脚本中的某个验证阶段,需要分更多的步骤,并且,每个步骤都有很繁琐的设置,为便于管理和简便化,因此,可以在这些复杂的一级功能脚本中,按照更具体的功能的不同,再划分出若干个二级功能脚本,并且,二级功能脚本也可以进行扩展。

例如,参阅图2所示,对于一级功能脚本中的仿真脚本,可以包括以下几个二级功能脚本,分别为:收集仿真数据脚本、执行c模型脚本、执行仿真脚本和执行结果比对脚本等。

并且,这些二级功能脚本与具体的项目相关,因此,在移植过程中,可以根据项目的不同,进行修改。例如,根据项目的不同,在仿真时需要的数据也不相同,因此在移植时,只需要修改收集仿真数据脚本中所收集的数据信息即可完成移植操作,例如,参阅图3所示,为本发明实施例中,对于不同的项目,收集仿真数据脚本的数据变化,对于项目一,收集仿真数据脚本对应a类文件、b类文件和c类文件,对于项目二,收集仿真数据脚本对应e类文件、b类文件和d类文件,项目一和项目二的文件发生了变化,在移植时,需要相应地修改收集仿真数据脚本。

值得说明的是,本发明实施例中,并不是每一个一级功能脚本都必须有相应的二级功能脚本,可能对于一些简单的一级功能脚本就不需要再划分出多个二级功能脚本了,具体用户可以根据实际情况,进行划分和设置。

这样,本发明实施例中,创造性地设计出一种脚本的三层结构,通过这种三层结构的脚本,构成验证平台的管理平台,可以高效地管理复杂结构的验证,在移植时,整套脚本结构,可以完全地移植到另一个项目中,只需要修改一些二级功能脚本即可,对于入口脚本和一级功能脚本可以不需要修改,移植比较简单方便;并且,可以扩展更多的一级功能脚本,只需在入口脚本中增加命令即可,扩展实现也比较简单;

同时,相较于现有技术中,在验证过程中运行某个脚本时,需要先找到该脚本的位置然后进行执行,对于一个新的验证人员来说,需要熟悉目录结构找到对应的功能脚本,这就需要一段时间进行培训,不便于用户使用和管理,本发明实施例中,对于用户来说,只需要了解入口脚本的命令,就可以调用对应的功能脚本,降低了对验证平台管理的复杂性,便于用户使用。

因此,本发明实施例中,设计的脚本结构,不仅具有很高的移植性和扩展性,而且也极大简化了脚本管理的复杂性,提高了对验证平台的管理效率。

基于上述实施例,参阅图4所示,本发明实施例中,验证平台管理方法的具体流程如下:

步骤400:接收到命令时,根据入口脚本中预设的命令与一级功能脚本的映射关系,确定所述命令对应的一级功能脚本。

本发明实施例中,入口脚本中保存有一级功能脚本与命令的映射关系。用户预先知道这些命令,在验证时,当需要调用某个功能脚本时,可以输入相应的命令,入口脚本就可以通过识别外部的命令执行不同的一级功能脚本。

其中,命令的格式可以为:入口脚本的名称+空格+入口脚本解析后确定的对应的一级功能脚本+空格+一级功能脚本所需的参数选项(即配置的验证环境变量)。

进一步地,若增加新的一级功能脚本,则在入口脚本中创建新的一级功能脚本与命令的映射关系。

这样,本发明实施例中,入口脚本可以扩展一级功能脚本,提高了脚本的可扩展性。

步骤410:根据所述命令中配置的验证环境变量,确定所述一级功能脚本对应的二级功能脚本的执行情况。

本发明实施例中,对于一个一级功能脚本对应的二级功能脚本,也不需要都执行,具体根据命令中配置的验证环境变量,确定二级功能脚本的执行情况,即选择执行哪些二级功能脚本。

本发明实施例中,在具体实现时,每个配置的验证环境变量,都可以称为该一级功能脚本的选项,并且,可以增加或删除选项。

例如,对于一级功能脚本中的仿真脚本,可以包括以下几种验证环境变量,dump_en:是否生成波形选项,new_seed:是否使用新seed选项,regress_en:是否回归选项,cover_en:是否生成cover选项,cover_type:cover类型选项等,对于是否的选项,若配置为on,则执行,若配置为off,则不执行,进而根据这些验证环境变量的配置,选择相应的二级功能脚本。

步骤420:根据确定的一级功能脚本和所述一级功能脚本对应的二级功能脚本的执行情况,运行一级功能脚本和二级功能脚本,进行验证。

进一步地,本发明实施例中,当确定移植脚本时,在移植过程中,不修改所述一级功能脚本,并根据实际需求,修改相应的二级功能脚本。

也就是说,本发明实施例中,当确定移植脚本时,例如从项目一移植到项目二中,可以不需要修改一级功能脚本和入口脚本,只需要根据项目的不同需求,修改相应的二级脚本,这是因为,本发明实施例中,一级功能脚本是在项目中各个验证阶段需要使用到的相对独立的功能,一般对于不同的项目都是一样的,并且,由于入口脚本中保存一级功能脚本与命令的映射关系,一级功能脚本不需要修改,因此,相应地入口脚本也不需要修改。而对于二级功能脚本,是一级功能脚本下的具体的测试用例的选项,对于不同项目,这些选项可能是不同的,例如,可能对于项目二不需要某些选项,则在移植时,可以删除该选项对应的二级功能脚本。

进一步地,本发明实施例中,在验证之前,会预先建立验证所需的基础文件的结构目录,也可以称为基础(base)目录,并且会把这些基础文件单独保存,由于这些基础文件通常都是基础源代码文件,占用内存一般比较小。

在验证过程中,会根据脚本,生成编译目录和仿真目录,其中,编译目录是根据基础文件编译成的可执行文件生成的,仿真目录根据项目的不同需求进行创建,并且一般一个测试用例对应一个仿真目录。在验证过程中,产生的各种仿真数据和编译文件,也会单独保存,并且保存在不同于基础文件的内存中,这样,由于这些验证过程中的仿真数据和编译文件,对于不同项目是不同的,一般不需要保留,因此,在验证完成后,可以通过调用一级功能脚本clear,删除这些验证过程中产生的仿真数据和编译文件,例如包括仿真目录、仿真波形和编译目录等,这样可以进一步释放内存。

这样,基于本发明实施例中的三层结构的脚本结构,根据接收到的命令,通过入口脚本的解析,可以选择执行相应的一级功能脚本和二级功能脚本,不需要用户在验证时查找功能脚本的位置,只需预先了解入口脚本中的命令即可,非常简单,降低了对验证平台管理的复杂性。

基于上述实施例,参阅图5所示,本发明实施例中,验证平台管理装置,具体包括:

第一确定单元50,用于接收到命令时,根据入口脚本中预设的命令与一级功能脚本的映射关系,确定所述命令对应的一级功能脚本;

第二确定单元51,用于根据所述命令中配置的验证环境变量,确定所述一级功能脚本对应的二级功能脚本的执行情况;

运行单元52,用于根据确定的一级功能脚本和所述一级功能脚本对应的二级功能脚本的执行情况,运行一级功能脚本和二级功能脚本,进行验证。

较佳的,所述入口脚本,表示保存有一级功能脚本与命令的映射关系,并用于识别命令的脚本;

所述一级功能脚本,表示根据验证过程中相对独立的功能,编写的独立功能脚本;

所述二级功能脚本,表示根据一级功能脚本中不同功能的划分,编写的功能脚本。

较佳的,进一步包括:

更新单元53,用于若增加新的一级功能脚本,则在所述入口脚本中创建所述新的一级功能脚本与命令的映射关系。

较佳的,进一步包括:

移植单元54,用于当确定移植脚本时,在移植过程中,不修改所述一级功能脚本,并根据实际需求,修改相应的二级功能脚本。

较佳的,所述命令的格式为:入口脚本的名称+空格+入口脚本解析后确定的对应的一级功能脚本+空格+一级功能脚本所需的配置的验证环境变量。

较佳的,所述入口脚本、一级功能脚本和二级功能脚本,使用perl语言或shell语言编写。

较佳的,进一步包括:

生成单元55,用于接收到命令之前,根据验证所需的基础文件,生成基础目录,并在验证过程中,根据所述命令和所述基础文件,生成编译目录和仿真目录;

运行单元52,进一步用于根据所述编译目录和仿真目录,运行对应的一级功能脚本和二级功能脚本;

删除单元56,用于在确定验证完成后,删除所述编译目录和仿真目录。

本发明实施例中,针对所述验证平台,预先设计脚本的三层结构,包括入口脚本、一级功能脚本和二级功能脚本,具体包括:接收到命令时,根据入口脚本中预设的命令与一级功能脚本的映射关系,确定所述命令对应的一级功能脚本;根据所述命令中配置的验证环境变量,确定所述一级功能脚本对应的二级功能脚本的执行情况;根据确定的一级功能脚本和所述一级功能脚本对应的二级功能脚本的执行情况,运行一级功能脚本和二级功能脚本,进行验证,这样,设计脚本结构为包括入口脚本、一级功能脚本和二级功能脚本的三层结构,这种脚本结构不仅具有很高的移植性和扩展性,而且也极大简化了脚本管理的复杂性,提高了对验证平台的管理效率。基于该脚本结构,接收到命令时,通过入口脚本的解析,可以选择执行相应的一级功能脚本和二级功能脚本,不需要用户在验证时查找功能脚本的位置,只需预先了解入口脚本中的命令即可,非常简单,降低了对验证平台管理的复杂性。

本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然,本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样,倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1