CN113706110B - 一种fpga测试工具一体化测试管理平台 - Google Patents

Abstract

本公开涉及一种FPGA测试工具一体化测试管理平台包括：测试项目管理***用于接收测试项目信息，对测试项目信息进行分析获取多个字段，根据多个字段建立多个数据表并存储在数据库确定多个实体，每个实体与每个数据表一一对应，每个实体的属性对应每个数据表中的字段；测试工具管理***用于接收测试工具执行命令，测试工具执行命令包括测试工具标识，根据测试工具标识获取调用的测试插件或测试工具的部署位置，根据部署位置选择目标方式调用测试插件或测试工具，从插件工具库获取插件地址信息，通过插件地址信息连接远程或本地的插件，发送插件任务给插件，插件调用测试工具进行测试生成测试结果。由此，提高测试项目管理和测试工具管理的质量和效率。

Description

一种FPGA测试工具一体化测试管理平台

技术领域

本公开涉及测试管理技术领域，尤其涉及一种FPGA(Field Programmable GateArray，现场可编程逻辑门阵列)测试工具一体化测试管理平台。

背景技术

当前FPGA测试工具评测领域，一些测评实验室，采用填写Excel或Word模板进行测试工具测试项目管理，由于实验室管理过程存在不同角色之间大量的耦合关系，这些工作完全依赖于人工控制，工作量大、效率低、容易出错。

更具体地，在测试实施过程管理方面，目前对测试工具管理和使用上更缺少标准化、自动化管理。针对不同的测试方法均存在多款测试工具，因此对军用FPGA测试工具测试过程中需要涉及到大量的不同厂家的测试工具，且各种工具都具备相对独立的功能、使用方法和配置要求，因此在对军用FPGA测试工具的规则检查过程中，往往需要多种工具的组合应用，才能保证测试的充分性、有效性。

因此，目前军用FPGA测试工具测试各测试阶段均需要使用大量的第三方工具，缺少对测试过程跟踪控制、文档和工具等测试关键要素的统一管理***。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种FPGA测试工具一体化测试管理平台。

本公开提供了一种FPGA测试工具一体化测试管理平台，包括：测试项目管理***和测试工具管理***；其中，所述测试项目管理***包括：人机交互层、接口管理和业务逻辑层、文档和配置管理层以及数据库；所述测试工具管理***包括：所述人机交互层、所述接口管理和业务逻辑层、插件管理层和插件工具库；

所述人机交互层，用于接收测试项目信息；

所述接口管理和业务逻辑层，用于对所述测试项目信息进行分析，获取多个字段；

所述文档和配置管理层，用于根据所述多个字段建立多个数据表并存储在所述数据库；

所述文档和配置管理层，还用于确定多个实体，每个所述实体与每个所述数据表一一对应，每个所述实体的属性对应每个所述数据表中的字段；

所述人机交互层，还用于接收测试工具执行命令；其中，所述测试工具执行命令包括测试工具标识；

所述接口管理和业务逻辑层，还用于根据测试工具标识获取调用的测试插件或测试工具的部署位置，根据所述部署位置选择目标方式调用所述测试插件或所述测试工具；

所述插件管理层，用于从所述插件工具库获取插件地址信息，通过所述插件地址信息连接远程或本地的插件，发送插件任务给所述插件，以使所述插件调用所述测试工具进行测试，生成测试结果。

在本公开一个可选的实施例中，所述人机交互层，还用于接收文档生成请求；所述接口管理和业务逻辑层，用于基于所述文档生成请求确定文档模板；所述文档和配置管理层，用于根据所述文档模板确定目标字段，并根据所述目标字段在所述数据库的数据表中进行匹配，获取文档数据，并基于所述文档数据和所述文档模板生成文档。

在本公开一个可选的实施例中，所述文档和配置管理层，还用于对所述多个数据表进行分析，获取数据表类型和管理模型，建立每个所述数据表、所述数据表类型和所述管理模型的关联关系；其中，所述管理模型包括组织管理、过程管理、项目管理、文档管理、技术管理、综合管理中的一种或者多种。

在本公开一个可选的实施例中，所述接口管理和业务逻辑层，具体用于：

根据测试工具标识获取调用的测试插件或测试工具的部署位置在工作站端，则使用应用程序接口函数调用所述测试插件或所述测试工具；或，

根据测试工具标识获取调用的测试插件或测试工具的部署位置在服务器端，生成接口信息发送到服务器端。

在本公开一个可选的实施例中，部署在所述服务器端的插件管理层在收到所述接口信息之后，对所述接口信息进行解析，获取测试工具标识和命令类型生成执行脚本执行，完成所述测试工具的调用和执行。

在本公开一个可选的实施例中，所述测试工具管理***，还包括：第一规则集配置层；所述第一规则集配置层，用于：

通过第一预设命令字，选择规则集路径；

通过第二预设命令字，删除第一规则集中的第一规则；

通过第三预设命令字，删除第二规则集中的所有规则；

通过第四预设命令字，删除第三规则集中的所有规则；

通过第五预设命令字，提取目标格式的规则配置文件；

启动目标测试工具，根据预设脚本使用第六预设命令字，读取所述规则配置文件进行规则配置。

在本公开一个可选的实施例中，所述测试工具管理***，还包括：第二规则集配置层；所述第二规则集配置层，用于：

通过预设第一命令，启动目标规则编辑工具；

通过所述预设第一命令，编辑规则文件后保存为目标格式文件；

根据默认规则集和自定义规则对所述目标格式文件进行更改，获取目标格式规则配置文件；

通过脚本读取所述目标格式规则配置文件进行规则配置。

在本公开一个可选的实施例中，所述的FPGA测试工具一体化测试管理平台，还包括：仿真层；

所述人机交互层，还用于：接收命令及命令参数；其中，所述命令参数包括测试工具标识；

所述仿真层，用于：

所述测试工具标识大于预设数值，则确定为工作端测试工具；

在所述测试工具标识为第一目标数值时，启动目标测试工具，生成批处理文件；

根据所述命令生成所述目标测试工具的执行脚本文件；

通过调用应用程序接口函数执行所述批处理文件，执行仿真，以使用户对仿真结果和覆盖率分析报告。

在本公开一个可选的实施例中，所述仿真层，还用于：

所述测试工具标识小于等于所述预设数值，则确定为服务器端测试工具；

根据所述命令，生成可扩展标记语言文件；

通过网际互连协议地址和端口号接收所述可扩展标记语言文件，对所述可扩展标记语言文件进行解析，获取目标命令字和目标命令参数；

在所述测试工具标识为第二目标数值时，根据所述目标命令字和所述目标命令参数生成目标文件；

执行所述目标文件，返回覆盖率文件。

在本公开一个可选的实施例中，所述测试工具管理***，还包括：逻辑检查层；

所述逻辑检查层，用于：

获取等效性检查文件；

对所述等效性检查文件进行编译后，切换到逻辑等效性检查模式；

对待设计的输入输出进行映射，并通过比较命令对两组设计进行效性检查，获取等效性检查结果。

本公开实施例提供的技术方案与现有技术相比具有如下优点：

通过提出一种FPGA测试工具一体化测试管理平台，包括：测试项目管理***和测试工具管理***；其中，测试项目管理***包括：人机交互层、接口管理和业务逻辑层、文档和配置管理层以及数据库；测试工具管理***包括：人机交互层、接口管理和业务逻辑层、插件管理层和插件工具库；人机交互层，用于接收测试项目信息；接口管理和业务逻辑层，用于对测试项目信息进行分析，获取多个字段；文档和配置管理层，用于根据多个字段建立多个数据表并存储在数据库；文档和配置管理层，还用于确定多个实体，每个实体与每个数据表一一对应，每个实体的属性对应每个数据表中的字段；人机交互层，还用于接收测试工具执行命令；其中，测试工具执行命令包括测试工具标识；接口管理和业务逻辑层，还用于根据测试工具标识获取调用的测试插件或测试工具的部署位置，根据部署位置选择目标方式调用测试插件或测试工具；插件管理层，用于从插件工具库获取插件地址信息，通过插件地址信息连接远程或本地的插件，发送插件任务给插件，以使插件调用测试工具进行测试，生成测试结果。由此，提供了一种覆盖FPGA测试工具测评全周期的信息化管理和测试平台，实现了对FPGA测试工具测试流程的规范化、标准化、自动化，提高了测试质量和效率，也便于管理人员、质量监督人员、配置管理人员等进行质量管理和跟踪控制。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本公开实施例提供的一种FPGA测试工具一体化测试管理平台的结构示例图；

图2为本公开实施例FPGA测试工具一体化测试管理平台的网络拓扑结构的示例图；

图3为本公开实施例文档生成流程示例图；

图4为本公开实施例一种规则集配置过程示例图；

图5为本公开实施例另一种规则集配置过程示例图；

图6为本公开实施例测试工具调用关系示例图；

图7为本公开实施例逻辑等效性检查流程示例图；

图8为本公开实施例测试工具与军标要求的测试方法的对应关系示例图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

目前，常用项目管理***的管理过程、标准等不符合军用规范，因此不适应国内军用FPGA测试工具测试实验室的项目管理要求。且这些管理***对测试质量控制、项目过程和技术文件管理、测试工具管理和使用方面，往往作为几个互相独立的内容进行管理，缺少统一的、标准化、自动化的管理平台，造成测试流程控制和技术实现无法有效衔接，导致测试效率降低、测试质量管控出现漏洞。同时军用FPGA测试工具测试过程中，每一阶段均需要测试人员编写大量的测试文档、质量记录等，一般情况下编写各类文档时间占整个测试周期的一半左右，因此急需一款自动化的文档生成测试工具。

再者，传统的军用FPGA测试工具测试代码规则检查阶段中，由于市面上存在大量的第三方测试工具，测试过程需要测试人员对测试工具和相关的规则集等进行选择和配置，但过程中缺少***化的测试工具选择配置标准和质量监督标准，因此最终的分析结果受测试人员技术水平影响较大，可能造成测试质量不稳定。

另外，在仿真测试过程中，使用第三方仿真工具如modelsim(一种仿真工具)、VCS(一种仿真工具)、Active-HDL(一种仿真工具)等，需要使用FPGA厂商提供的对应芯片的资源库，而不同厂商的库类型具有较大差异，且同一厂商开发工具的不同版本对应的库文件也无法完全通用，因此找到对应芯片的库文件并正确编译使用，对测试人员技术门槛和经验要求较高。同时以上仿真工具各具特点，优势互补，但是各种工具的执行命令字和使用方式又存在很大差异，测试人员很难同时精通，同时编制多种仿真工具的执行脚本也增加了无谓的工作量，导致测试周期拉长。

最后，执行逻辑等效性检查时，对FPGA设计使用的综合器兼容性水平参差不齐，且个别工具需要人工添加FPGA厂商的工艺库，但目前部分厂商已不再公开该工艺库。同时以上工具均价格不菲，因此在FPGA测试工具逻辑等效性检查时选择一种兼容性好、使用方便的工具对缺少相关测试经验的人员来说有很大的挑战。

针对上述问题，本公开提出了一种FPGA测试工具一体化测试管理平台。具体地，本发明提出了一种FPGA测试工具一体化测试管理平台支持支持《GJB-2725A测试实验室和校准实验室通用要求》和《GJB-9433军用可编程逻辑器件测试工具测试要求》中要求的军用FPGA测试工具测试全阶段的过程、人员、项目、文档、测试类型、测试工具、质量控制等管理功能。即实现军用FPGA测试工具测试评价全过程集约化管理，提高测试效率和测试全过程的标准化、自动化水平。

其中，FPGA测试工具一体化测试管理平台主要功能包括军用FPGA测试工具测试全过程管理、测试文档生成、测试工具管理和辅助使用等功能，以及采用插件技术完成测试工具集成，该框架通过对各类工具提供定制化插件，完成功能的封装，使用XML(ExtensibleMarkup Language，可扩展标记语言)/TCL(Tool Command Language，工具命令语言)/Makefile(一种文件格式)格式的命令文件实现对工具的本地或远程调用，收集执行结果，该模式可以有效的实现平台对工具的灵活扩展，又能够支持分布式环境下的FPGA测试任务。

综上，该管理***为测试管理人员、测试项目负责人、测试人员、质量保证人员、配置管理人员等提供了覆盖军用FPGA测试工具测评全周期的信息化管理和测试平台。

图1为本公开实施例提供的一种FPGA测试工具一体化测试管理平台的结构示例图。如图1所示，FPGA测试工具一体化测试管理平台包括：测试项目管理***和测试工具管理***，测试项目管理***包括：人机交互层100、接口管理和业务逻辑层200、文档和配置管理层300以及数据库400；测试工具管理***包括：人机交互层100、接口管理和业务逻辑层200、插件管理层500和插件工具库600。

其中，人机交互层100，用于接收测试项目信息。

接口管理和业务逻辑层200，用于对测试项目信息进行分析，获取多个字段。

文档和配置管理层300，用于根据多个字段建立多个数据表并存储在数据库400。

文档和配置管理层300，还用于确定多个实体，每个实体与每个数据表一一对应，每个实体的属性对应每个数据表中的字段。

人机交互层100，还用于接收测试工具执行命令；其中，测试工具执行命令包括测试工具标识。

接口管理和业务逻辑层200，还用于根据测试工具标识获取调用的测试插件或测试工具的部署位置，根据部署位置选择目标方式调用测试插件或测试工具。

插件管理层500，用于从插件工具库600获取插件地址信息，通过插件地址信息连接远程或本地的插件，发送插件任务给插件，以使插件调用测试工具进行测试，生成测试结果。

具体地，本公开的FPGA测试工具一体化测试管理平台采用扩展性更好的树型网络拓扑结构，可以根据需求配置工作站的数量，如图2所示：***测试工具分为工作站端和服务器端两部分组成，其中，工作站端部署在windows(视窗)操作***下，服务器端部署在linux(一种操作***名称)操作***下。根据测试工具和插件的运行环境要求，可自由选择部署在服务器端或工作站端，并完成工具标识和工具安装路径的匹配，***配置信息存储在服务器中的Mysql(关系型数据库管理***)数据库中。

具体地，FPGA测试工具一体化测试管理平台测试工具设计可以采用C/S(Client-Server，服务器-客户机)架构，采用java(一门面向对象编程语言)语言进行编程，因此满足分布式***的跨平台特性，使用socket(套接字)接口实现工作站端测试工具与服务器端测试工具间的数据通信。

具体地，通过使用swing(用户界面开发工具包)框架实现人机交互层的控制和视图，使用Spring(一个开源框架)框架实现功能管理模块的模型库构建,使用Hibernate框架(开放源代码的对象关系映射框架)实现数据库的访问与存储。

在本公开的一个实施例中，文档和配置管理层300，还用于对多个数据表进行分析，获取数据表类型和管理模型，建立每个数据表、数据表类型和管理模型的关联关系；其中，管理模型包括组织管理、过程管理、项目管理、文档管理、技术管理、综合管理中的一种或者多种。

具体地，军用测试工具测评实验室管理要求主要包括：组织、质量管理体系、文件的控制、要求、委托书及合同的评审、分包、采购、对委托方的服务、意见的处理、不符合要求的控制、纠正措施、预防措施、记录的控制、内部审核、管理评审；技术要求主要包括：人员、设施和环境、测试、校准或检定方法及其确认、设备、测量溯源性、抽样、被测件或被校件或被检件的处置。因此，本公开的测试项目管理***按功能划分主要分为基础数据管理、项目信息管理、测试活动管理、测试数据管理、测试实施管理、测试跟踪管理等模块。按照数据管理划分主要分为组织管理、过程管理、项目管理、文档管理、技术管理、综合管理6个数据管理模型，对应18个数据表类型。

每个管理模型对应军用测试工具FPGA测试项目管理的一个管理过程，比如采用的数据为关系型数据库，各业务实体保存在数据库表中，实体之间的关联作为关系保存在数据库表中，如表1所示。

表1数据表结构图

具体地，使用Hibernate框架实现数据表对应字段的增删、修改和查询处理。

在本公开的一个实施例中，人机交互层100，还用于接收文档生成请求，接口管理和业务逻辑层200，用于基于文档生成请求确定文档模板，文档和配置管理层300，用于根据文档模板确定目标字段，并根据目标字段在数据库400的数据表中进行匹配，获取文档数据，并基于文档数据和文档模板生成文档。

具体地，通过查询数据表数据和对应的文档模板信息，可以通过VBA(VisualBasic for Applications，编程语言的一种宏语言)宏进行字段匹配，自动生成基于录入模板的测试大纲、测试报告、质量记录等文件，文档生成流程如图3所示。

在本公开实施例中，还建立业务功能实体类如表2所示，与表1之间的映射关系，并在程序执行过程中根据该映射关系来实现对象形式的数据和数据库记录形式的数据之间的转换。在对象关系映射模型中，每一个实体类与一个数据库表对应，实体的属性对应数据库表中的字段。每一个数据库表必须包含一个自动编号的主键字段，该字段与实体类的标识属性对应。每一个实体类的对象保存到数据库中以后就是该实体对应的数据库表的一条记录，程序其它模块只需要与实体对象交互。

表2功能管理结构图

在本公开的一个实施例中，接口管理和业务逻辑层200，具体用于：根据测试工具标识获取调用的测试插件或测试工具的部署位置在工作站端，则使用应用程序接口函数调用测试插件或所述测试工具；或，根据测试工具标识获取调用的测试插件或测试工具的部署位置在服务器端，生成接口信息发送到服务器端。

在本公开的一个实施例中，部署在服务器端的插件管理层500在收到接口信息之后，对接口信息进行解析，获取测试工具标识和命令类型生成执行脚本执行，完成测试工具的调用和执行。

具体地，通过人机交互界面选择和调用测试工具。首先确定每种测试方法中集成的测试工具，选择测试工具对应按键和对应工程，即向接口管理层下发对该工程的工具执行指令。

具体地，接口管理和业务逻辑层200收到人机交互层100下发的指令，首先根据工具标识判断调用的测试插件或测试工具的部署位置，若部署在工作站端则使用应用程序接口函数直接调用相关测试插件或测试工具，比如modelsim(测试工具名称)、ALintPro(测试工具名称)、Timing Analyzer(测试工具名称)、synplify(测试工具名称)等；若测试工具部署在服务器端，接口管理和业务逻辑层200将输入进行处理，其加工的输出通过XML格式的标签属性的方式list＝<key，value>，其中，关键词key表示选择的测试工具标识、执行命令和命令携带的参数类型，属性值value则主要用于记录具体的数据内容，保存为.XML文件。然后通过socket接口，根据服务器的IP(Internet Protocol，网际互连协议)地址和端口号，发送到***服务器端测试工具。

具体地，插件管理层500完成查询插件信息库600，从插件信息库600中找到合适的插件地址信息，通过地址信息连接远程或本地的插件，发送插件任务给插件。其中，插件信息,600的描述信息主要包括身份标识ID和地址Address。其中，ID为部署完成的工具测试工具标识，是每一个插件的唯一标识，Address则表示为插件的地址，若服务器端测试工具其具体形式为IP地址和端口号形式，若工作站端测试工具则为测试工具的安装路径。

具体地，在服务器端的插件管理层在收到XML数据之后，完成XML文件的解析，根据解析出的工具标识、命令类型等数据生成makefile脚本，通过shell命令执行脚本，完成指定工具的调用和执行。服务器端的测试工具包括VCS(测试工具名称)、EC-360(测试工具名称)、Leda(测试工具名称)、spyglass(测试工具名称)、PrimeTime(测试工具名称)等。

具体地，测试工具根据执行脚本开始运行程序，状态监控插件收集产生的中间数据，并以心跳包的形式发送给接口管理层，实时上传测试进度。

具体地，监控插件在工具执行完操作之后，将仿真波形文件/覆盖率文件/逻辑匹配结果/时序分析报告/规则检查问题记录等,返回给工作站端测试工具，并保存在指定路径，供测试人员使用和二次分析。

表3测试工具表

在本公开的一个实施例中，测试工具管理***，还包括：第一规则集配置层700，第一规则集配置层700，用于：通过第一预设命令字，选择规则集路径，通过第二预设命令字，删除第一规则集中的第一规则，通过第三预设命令字，删除第二规则集中的所有规则，通过第四预设命令字，删除第三规则集中的所有规则，通过第五预设命令字，提取目标格式的规则配置文件，启动目标测试工具，根据预设脚本使用第六预设命令字，读取规则配置文件进行规则配置。

其中，不同的测试工具预设命令字不同，比如使用“cd$aldec/examples/quick_start/create_from_file”命令字，选定规则集路径。

在本公开的一个实施例中，测试工具管理***，还包括：第二规则集配置层800；第二规则集配置层800，用于：通过预设第一命令，启动目标规则编辑工具；通过预设第一命令，编辑规则文件后保存为目标格式文件；根据默认规则集和自定义规则对目标格式文件进行更改，获取目标格式规则配置文件；通过脚本读取目标格式规则配置文件进行规则配置。

通过对各种规则检查测试工具和规则集进行比较分析，本***对Alintpro、Leda、spyglass三款规则检查工具进行集成，通过对以上测试工具的规则集进行编辑定制，制定了如下规则检查的标准化测试流程：

鉴于Alintpro测试工具报错率过高、CDC提示位置不准确等问题，使用Alintpro测试工具进行STARC(一种固定规则集名称)规则集、DO-254(一种固定规则集名称)规则集、RMM(一种固定规则集名称)规则集、Aldec(一种固定规则集名称)规则集分析，并对以上规则集的重复规则进行裁剪，并屏蔽CDC分析；AlintPro规则集配置过程见图4。

具体地，如图4所示：401，通过第一预设命令字，选择规则集路径；402，通过第二预设命令字，删除第一规则集中的第一规则；403，通过第三预设命令字，删除第二规则集中的所有规则；404，通过第四预设命令字，删除第三规则集中的所有规则；405，通过第五预设命令字，提取目标格式的规则配置文件；406，启动目标测试工具，根据预设脚本使用第六预设命令字，读取规则配置文件进行规则配置。

具体地，使用“cd$aldec/examples/quick_start/create_from_file”命令字，选定规则集路径，使用“global.policy.delete-rule STARC_VLOG.1.1.1.1”命令字，删除STARC规则集下的VLOG.1.1.1.1条规则，使用“global.policy.delete-rule ALDEC_CDC.*”命令字，删除ALDEC_CDC规则集下所有规则，屏蔽CDC，使用“global.policy.delete-ruleALDEC_SV.*”命令字，删除ALDEC_SV规则集下所有规则，屏蔽SV(System Verilog)语法的检查，使用“export_policy”命令字，自动导出policy.do的规则配置文件，启动Alintpro根据tcl脚本使用“Execute_marco”命令字，自动读取policy.do的规则配置文件。

使用Leda测试工具进行FPGA厂商规则集和根据相关国军标自定义的安全性规则集(如：状态机安全属性设置、注释率、case(实例)分支重叠等)分析，补充分析Alintpro不支持的厂商和自定义安全性规则集；以增加规则“避免使用锁存器”并使用xilinx(赛灵思)规则集为例，Leda规则集配置见图5。

具体地，如图5所示：501，通过预设第一命令，启动目标规则编辑工具；502，通过预设第一命令，编辑规则文件后保存为目标格式文件；503，根据默认规则集和自定义规则对目标格式文件进行更改，获取目标格式规则配置文件；504，通过脚本读取目标格式规则配置文件进行规则配置。

具体地，使用tcl命令“$Leda_path/bin/leda-specifier&”启动leda-specifie规则编辑工具，使用tcl命令编制规则文件“Rul_1:Ruleset latch_rul is No latch inalways_construct Message”avoid using latches in design”End ruleset”，使用“rule_manage_policy-policy Rul_1compile*.sl”保存并编译规则文件为*.sl文件，config菜单选择厂商规则集xilinx和自定义规则Rul_1，保存为*.tcl规则配置文件，程序运行通过脚本自动读取*.tcl进行规则配置。

鉴于spyglass的CDC分析效果更好但支持规则集不全的情况，仅使用spyglass测试工具进行CDC分析。

在本公开的一个实施例中，测试工具管理***，还包括：仿真层900，仿真层900，人机交互层100，还用于：接收命令及命令参数；其中，命令参数包括测试工具标识，仿真层900，用于：测试工具标识大于预设数值，则确定为工作端测试工具，在测试工具标识为第一目标数值时，启动目标测试工具，生成批处理文件，根据命令生成目标测试工具的执行脚本文件，通过调用应用程序接口函数执行批处理文件，执行仿真，以使用户对仿真结果和覆盖率分析报告。

在本公开的一个实施例中，仿真层900，还用于：测试工具标识小于等于预设数值，则确定为服务器端测试工具，根据命令，生成可扩展标记语言文件，通过网际互连协议地址和端口号接收可扩展标记语言文件，对可扩展标记语言文件进行解析，获取目标命令字和目标命令参数，在测试工具标识为第二目标数值时，根据目标命令字和目标命令参数生成目标文件，执行目标文件，返回覆盖率文件。

集成VCS和modelsim两种仿真工具测试工具，同时支持以上测试工具的一键启动、辅助测试(库编译、执行结果收集)等功能。其中，modelsim兼容windows***，使用方便，便于信号追踪和波形分析；VCS在linux下运行，相较服务器和普通个人电脑的硬件和***性能差别，一般情况下VCS执行效率远高于modelsim，但信号追踪波形分析能力不如modelsim。二者互为补充。基于分布式***的特点，可在modelsim下开展功能仿真、门级仿真对DUT功能、性能开展验证；同时使用VCS执行仿真时间较长的时序仿真和覆盖率测试。因此可以大幅缩减仿真测试和覆盖率测试的验证时间。其中，Modelsim和VCS执行流程见图6。

具体地，如图6所示，601，接收命令及命令参数；其中，命令参数包括测试工具标识；602，测试工具标识大于预设数值，则确定为工作端测试工具；603，在测试工具标识为第一目标数值时，启动目标测试工具，生成批处理文件；604，根据命令生成目标测试工具的执行脚本文件；605，通过调用应用程序接口函数执行批处理文件，执行仿真，以使用户对仿真结果和覆盖率分析报告；606，测试工具标识小于等于预设数值，则确定为服务器端测试工具；607，根据命令，生成可扩展标记语言文件，通过网际互连协议地址和端口号接收可扩展标记语言文件；608，对可扩展标记语言文件进行解析，获取目标命令字和目标命令参数；609，在测试工具标识为第二目标数值时，根据目标命令字和目标命令参数生成目标文件，执行目标文件，返回覆盖率文件。

具体地，人机交层收到命令及命令参数，ID(Identity document，身份标识)>100，这里YD指的是测试工具标识，工作站端软件，ID＝101，启动modelsim软件，产生批处理文件.bat，根据人机交互层的下发的指令，生成modelsim执行脚本sim.do文件，通过调用API函数执行批处理文件，执行仿真，人工分析仿真结果和覆盖率分析报告；ID<＝100，服务器端软件，根据人机交互层的下发的指令，生成XML文件，IP地址和端口号，XML文件解析，ID＝001，启动VCS，根据解析出的命令字、命令参数等生成VCS的makefile执行脚本，在shell模式下make命令执行makefile文件，执行完成返回覆盖率文件coverage.txt文件。

Modelsim的do脚本主要流程为：1.vlib指令建立work(工作)工作库；2.vmap指令对dut和work进行映射；3.vlog/vcom对dut和器件库进行编译；4.vsim启动仿真，并使能覆盖率统计；5.add(添加)指令添加波形到监控窗口；6.run(运行)指令执行仿真；7.使用“coverage report-recursive-select bces-file cov.txt”命令将覆盖率结果保存到cov.txt文件中。

VCS的执行脚本makefile文件的主要流程为：1.使用-l指定DUT文件路径；2.使用VCS命令对DUT文件进行编译；3./simv命令仿真执行；4.dve指令打开波形监测窗口；5.urg指令生成.txt格式的覆盖率报告；6.clean命令清除仿真过程中间临时文件；在本公开的一个实施例中，测试工具管理***，还包括：逻辑检查层1000，逻辑检查层1000，用于：获取等效性检查文件，对等效性检查文件进行编译后，切换到逻辑等效性检查模式，对待设计的输入输出进行映射，并通过比较命令对两组设计进行效性检查，获取等效性检查结果。

鉴于EC-360对各FPFA和EDA厂商的芯片和综合器兼容性均优于formality、FormalPro等测试工具，该***集成EC-360作为逻辑等效性分析工具。同时支持一键启动，根据onespin测试工具的tcl命令字生成makefile脚本自动进行逻辑等效性检查。执行流程如图7所示。

具体地，如图7所示，701，获取等效性检查文件；702，对等效性检查文件进行编译后，切换到逻辑等效性检查模式；703，对待设计的输入输出进行映射；704，通过比较命令对两组设计进行效性检查，获取等效性检查结果。

具体地，使用read_verilog-golden和read_vhdl-revised导入需要进行等效性检查的设计文件，使用elaborate-both对导入设计文件进行阐述(对不关心的模块指定黑盒子等)，使用compile-both对设计文件进行编译，使用set_mode ec将模式切换到逻辑等效性检查模式，使用map将待测设计的输入输出进行映射，使用compare命令对两组设计进行等效性检查，对不匹配的设计模块进行人工二次分析。

支持基于GJB2725A和GJB9433规范的，覆盖从测试策划、测试需求分析、测试设计与实现、测试执行、测试总结的FPGA测试工具测评全周期的过程、产品、质量控制。

该***使用基于VBA语言的word/excel宏编程，通过进行关键字的查找匹配，提取数据库中对应的字段，根据用户定义的文档模板，实现测试大纲、测试报告、测试工具问题报告等测试文件及评审单、QA单等质量记录文档的自动生成功能。并支持文档模板自定义功能。

通过插件技术实现分布式环境下的FPGA测试工具测试，为用户提供windows和linux两种操作***下的测试工具调用和执行功能。Windows***下，使用JAVA中JNI接口调用中API函数的方式进行工具调用和执行；linux***下，使用shell命令执行makefile脚本的方式进行工具调用执行。支持FPGA测试工具测试全阶段测试工具的自动化调用和执行，并具备自动编译库等测试辅助功能。

其中，***各模块功能进行独立开发，相互之间不存在互依赖性，使各个独立的功能都可以单独运行，对于修改功能模块也不会影响到其他插件模块的正常运行，降低了***的维护难度，提高了***的可扩展性。插件技术的主要实现方式为：1.抽离出插件功能接口，定义插件的抽象类；2.实现具体功能的插件实现插件抽象类，然后将该具体的插件打成JAR包，并将JAR包放到指定的插件目录下；3.创建插件配置文件XML文件，每当新增一个插件后，在配置文件中添加一条该插件的信息，该信息主要包括“插件名称(jar包名称)”和“插件主类的完整路径(包名类名)”；4.主程序中首先解析插件配置文件，得到插件名称和插件主类的路径，然后获取插件的jar所在的URL或路径，通过ClassLoader方法得到插件的类加载器，最后通过类加载器即可得到对应的插件类的实例。

本***依据《GJB-2725A测试实验室和校准实验室通用要求》及其附加要求和《GJB-9433军用可编程逻辑器件测试工具测试要求》中要求的军用FPGA测试工具测试全阶段的过程、人员、项目、文档、测试类型、测试工具、质量控制等管理要求，形成了本管理***的测试项目管理体系。并通过插件技术实现对军用FPGA测试工具全流程测试工具的有效集成，具体方式是根据相关国军标的要求，结合我公司多年的军用fpga测试工具测试实践经验和对行业相关单位的调研结果，对当前军用FPGA测试工具评测行业常用的工具测试工具进行比较分析，并通过对相关规则集的定制优化，对军用FPGA测试工具全流程测试工具进行集成和自动化、标准化定制，最终形成了FPGA测试工具一体化测试和管理平台。

综上，该***为军用FPGA测试工具测试管理人员、测试项目负责人、测试人员、质量保证人员、配置管理人员等，提供了一种覆盖军用fpga测试工具测评全周期的信息化管理和测试平台。该***实现了对FPGA测试工具测试流程的规范化、标准化、自动化。提高了测试人员的测试质量和效率，也便于管理人员、质量监督人员、配置管理人员等进行质量管理和跟踪控制。

如图8所示，集成的主要测试工具与军标要求的测试方法的对应关系。

综上所述，本公开的一种FPGA测试工具一体化测试管理平台，包括：测试项目管理***和测试工具管理***；其中，测试项目管理***包括：人机交互层、接口管理和业务逻辑层、文档和配置管理层以及数据库；测试工具管理***包括：人机交互层、接口管理和业务逻辑层、插件管理层和插件工具库；人机交互层，用于接收测试项目信息；接口管理和业务逻辑层，用于对测试项目信息进行分析，获取多个字段；文档和配置管理层，用于根据多个字段建立多个数据表并存储在数据库；文档和配置管理层，还用于确定多个实体，每个实体与每个数据表一一对应，每个实体的属性对应每个数据表中的字段；人机交互层，还用于接收测试工具执行命令；其中，测试工具执行命令包括测试工具标识；接口管理和业务逻辑层，还用于根据测试工具标识获取调用的测试插件或测试工具的部署位置，根据部署位置选择目标方式调用测试插件或测试工具；插件管理层，用于从插件工具库获取插件地址信息，通过插件地址信息连接远程或本地的插件，发送插件任务给插件，以使插件调用测试工具进行测试，生成测试结果。由此，提供了一种覆盖FPGA测试工具测评全周期的信息化管理和测试平台，实现了对FPGA测试工具测试流程的规范化、标准化、自动化，提高了测试质量和效率，也便于管理人员、质量监督人员、配置管理人员等进行质量管理和跟踪控制。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (5)

1.一种FPGA测试工具一体化测试管理平台，其特征在于，包括：测试项目管理***和测试工具管理***；其中，所述测试项目管理***包括：人机交互层、接口管理和业务逻辑层、文档和配置管理层以及数据库；所述测试工具管理***包括：所述人机交互层、所述接口管理和业务逻辑层、插件管理层和插件工具库；

所述人机交互层，用于接收测试项目信息；

所述接口管理和业务逻辑层，用于对所述测试项目信息进行分析，获取多个字段；

所述文档和配置管理层，用于根据所述多个字段建立多个数据表并存储在所述数据库；

所述文档和配置管理层，还用于确定多个实体，每个所述实体与每个所述数据表一一对应，每个所述实体的属性对应每个所述数据表中的字段；

所述人机交互层，还用于接收测试工具执行命令；其中，所述测试工具执行命令包括测试工具标识；

所述接口管理和业务逻辑层，还用于根据测试工具标识获取调用的测试插件或测试工具的部署位置，根据所述部署位置选择目标方式调用所述测试插件或所述测试工具；

所述插件管理层，用于从所述插件工具库获取插件地址信息，通过所述插件地址信息连接远程或本地的插件，发送插件任务给所述插件，以使所述插件调用所述测试工具进行测试，生成测试结果；

所述人机交互层，还用于接收文档生成请求；

所述接口管理和业务逻辑层，用于基于所述文档生成请求确定文档模板；

所述文档和配置管理层，用于根据所述文档模板确定目标字段，并根据所述目标字段在所述数据库的数据表中进行匹配，获取文档数据，并基于所述文档数据和所述文档模板生成文档；

其中，所述接口管理和业务逻辑层，具体用于：

根据测试工具标识获取调用的测试插件或测试工具的部署位置在工作站端，则使用应用程序接口函数调用所述测试插件或所述测试工具；或，

根据测试工具标识获取调用的测试插件或测试工具的部署位置在服务器端，生成接口信息发送到服务器端；

所述的FPGA测试工具一体化测试管理平台，还包括：

部署在所述服务器端的插件管理层在收到所述接口信息之后，对所述接口信息进行解析，获取测试工具标识和命令类型生成执行脚本执行，完成所述测试工具的调用和执行；

所述测试工具管理***，还包括：仿真层；

所述人机交互层，还用于：接收命令及命令参数；其中，所述命令参数包括测试工具标识；

所述仿真层，用于：

所述测试工具标识大于预设数值，则确定为工作端测试工具；

在所述测试工具标识为第一目标数值时，启动目标测试工具，生成批处理文件；

根据所述命令生成所述目标测试工具的执行脚本文件；

通过调用应用程序接口函数执行所述批处理文件，执行仿真，以使用户对仿真结果和覆盖率进行分析，生成报告；

所述仿真层，还用于：

所述测试工具标识小于等于所述预设数值，则确定为服务器端测试工具；

根据所述命令，生成可扩展标记语言文件；

通过网际互连协议地址和端口号接收所述可扩展标记语言文件，对所述可扩展标记语言文件进行解析，获取目标命令字和目标命令参数；

在所述测试工具标识为第二目标数值时，根据所述目标命令字和所述目标命令参数生成目标文件；

执行所述目标文件，返回覆盖率文件。

2.根据权利要求1所述的FPGA测试工具一体化测试管理平台，其特征在于，

所述文档和配置管理层，还用于对所述多个数据表进行分析，获取数据表类型和管理模型，建立每个所述数据表、所述数据表类型和所述管理模型的关联关系；其中，所述管理模型包括组织管理、过程管理、项目管理、文档管理、技术管理、综合管理中的一种或者多种。

3.根据权利要求1所述的FPGA测试工具一体化测试管理平台，其特征在于，所述测试工具管理***，还包括：第一规则集配置层；所述第一规则集配置层，用于：

通过第一预设命令字，选择规则集路径；

通过第二预设命令字，删除第一规则集中的第一规则；

通过第三预设命令字，删除第二规则集中的所有规则；

通过第四预设命令字，删除第三规则集中的所有规则；

通过第五预设命令字，提取目标格式的规则配置文件；

启动目标测试工具，根据预设脚本使用第六预设命令字，读取所述规则配置文件进行规则配置。

4.根据权利要求1所述的FPGA测试工具一体化测试管理平台，其特征在于，所述测试工具管理***，还包括：第二规则集配置层；所述第二规则集配置层，用于：

通过预设第一命令，启动目标规则编辑工具；

通过所述预设第一命令，编辑规则文件后保存为目标格式文件；

根据默认规则集和自定义规则对所述目标格式文件进行更改，获取目标格式规则配置文件；

通过脚本读取所述目标格式规则配置文件进行规则配置。

5.根据权利要求1所述的FPGA测试工具一体化测试管理平台，其特征在于，所述测试工具管理***，还包括：逻辑检查层；

所述逻辑检查层，用于：

获取等效性检查文件；

对所述等效性检查文件进行编译后，切换到逻辑等效性检查模式；

对待设计的输入输出进行映射，并通过比较命令对两组设计进行效性检查，获取等效性检查结果。

Images