一种基于可执行文件的芯片验证方法和装置与流程

文档序号:12063535阅读:270来源:国知局
一种基于可执行文件的芯片验证方法和装置与流程

本发明涉及产品检测技术领域,特别是涉及一种基于可执行文件的芯片验证方法和一种基于可执行文件的芯片验证装置。



背景技术:

在芯片的开发使用过程中,芯片的验证是非常重要的一个环节,它能够提高产品质量,间接影响总体的产品时间。

在目前芯片的验证方法中,仿真环境的基本架构如图1所示,该仿真环境下具体包括有Driver(驱动器),DUT(Design Under Test,被测设计),RM(Reference Model,参考模型),Monitor(监视器)以及checker(检查器)这几个模块。用户通过构造不同TC(Test Case,测试用例),从而产生验证环境所需要的配置信息和数据包,在验证环境中的Driver通过配置接口和数据接口,分别将配置信息和数据包发送给DUT及RM,DUT根据配置信息完成对数据包的处理,然后结果输出给验证环境的Monitor,Monitor采集DUT的输出结果送给checker,同时,RM的输出结果也送给checker,最后在checker中完成DUT的输出结果与RM的输出结果的比对,从而完成对芯片的验证。

从上述芯片的整个验证过程看,现有验证环境的一个核心组件是RM,目前对于RM的实现,业界通用的做法有两种,一是由验证人员根据DUT的规格利用system verilong(简称SV)语言实现,这是由于DUT是SV语言,所以第一种方案实现RM也需要利用SV语言),二是利用现有的C算法源码进行修改,利用DPI(Direct Programming Interface,直接编程接口)将C算法模型导入到验证环境中作为RM,因为RM源码是C语言,而DUT是SV语言,如果要使两者同时存在于验证环境,需要用DPI方式将C算法模型导入验证环境中。

但是,对于第一种方案,是一个二次开发的过程,容易引入错误,同时开发周期会比较长。对于第二种方案,需要算法人员将源代码开放 给验证人员,验证人员根据算法源码进行重新封装,保密性不能得到很好的保证,尤其是与第三方进行合作时,这种方法存在极大的风险。同时,以上两种方案都需要将RM作为验证环境的一部分,如果RM比较复杂,将会导致仿真过程中占用大量的内存,降低仿真效率。



技术实现要素:

鉴于上述问题,提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种基于可执行文件的芯片验证方法和一种基于可执行文件的芯片验证装置。

为了解决上述问题,本发明实施例公开了一种基于可执行文件的芯片验证方法,所述芯片的被测设计位于验证环境之内,所述可执行文件独立于所述验证环境之外,所述方法包括:

生成配置信息和数据包;

在所述可执行文件中依据所述配置信息和数据包生成第一输出结果;

在所述验证环境中依据所述配置信息和数据包生成第二输出结果;

采用所述第一输出结果和所述第二输出结果验证所述芯片的被测设计。

优选地,所述生成配置信息和数据包的步骤包括:

生成随机种子;

按照预置测试用例约束采用预置测试用例和所述随机种子,生成配置信息和数据包。

优选地,在所述生成配置信息和数据包的步骤之后,还包括:

将所述配置信息和数据包转换为符合所述可执行文件格式的配置信息和数据包;

则所述在可执行文件中依据所述配置信息和数据包生成第一输出结果的步骤包括:

在所述可执行文件中采用所述符合可执行文件格式的配置信息和数 据包,计算第一输出结果;

将所述第一输出结果保存到指定的文件中。

优选地,所述在验证环境中依据所述配置信息和数据包生成第二输出结果的步骤包括:

采用所述验证环境所需的配置信息配置所述芯片的被测设计;

将所述验证环境所需的数据包发送到所述芯片的被测设计中;

在配置后的芯片中采用所述数据包计算出第二输出结果。

优选地,在所述将验证环境所需的数据包发送到所述芯片中的步骤之后,还包括:

统计发送到所述芯片的被测设计中的数据包的个数。

优选地,所述采用第一输出结果和所述第二输出结果验证所述芯片的被测设计的步骤包括:

读取所述第一输出结果和所述第二输出结果;

将所述第一输出结果和所述第二输出结果进行比对;

若所述第一输出结果和所述第二输出结果不一致,则判定为所述芯片的被测设计验证失败;

当判断为芯片的被测设计验证失败时,停止验证所述芯片的被测设计。

优选地,所述采用第一输出结果和所述第二输出结果验证所述芯片的被测设计的步骤,还包括:

若所述第一输出结果和所述第二输出结果一致,则继续将所述验证环境所需的数据包发送到所述芯片的被测设计中;

在配置后的芯片的被测设计中继续采用所述数据包计算出第二输出结果;

当所述数据包的个数达到预设个数,且所述第一输出结果和所述第二输出结果一致,则判定为所述芯片的被测设计验证成功。

优选地,所述随机种子包括时间信息;所述可执行文件为C算法可执行文件。

本发明实施例还提供了一种基于可执行文件的芯片验证装置,所述芯片的被测设计位于验证环境之内,所述可执行文件独立于所述验证环境之外,所述装置包括:

数据生成模块,用于生成配置信息和数据包;

第一输出结果生成模块,用于在所述可执行文件中依据所述配置信息和数据包生成第一输出结果;

第二输出结果生成模块,用于在所述验证环境中依据所述配置信息和数据包生成第二输出结果;

芯片验证模块,用于采用所述第一输出结果和所述第二输出结果验证所述芯片的被测设计。

优选地,所述装置还包括:

数据转换模块,用于将所述配置信息和数据包转换为符合所述可执行文件格式的配置信息和数据包;

所述第一输出结果生成模块包括:

第一输出结果计算子模块,用于在所述可执行文件中采用所述符合可执行文件格式的配置信息和数据包,计算第一输出结果;

输出结果保存子模块,用于将所述第一输出结果保存到指定的文件中。

本发明实施例包括以下优点:

本发明实施例中在验证环境之外,存在与验证环境互相独立的可执行文件,在进行芯片验证的操作时,首先生成配置信息和数据包,然后再分别输入验证环境和可执行文件中得到输出结果,将两者的输出结果比对即可获知芯片的验证结果。由于本发明实施例中的验证环境与可执行文件互相独立互不影响,可执行文件不需要再作为验证环境中的一部分,即使验证环境与生成可执行文件的模型比较复杂,由于其与验证环境互相独立互不影响,那么在芯片验证过程中,可以减少所需使用的内存,提高验证效率。

应用本发明实施例,由于在整个芯片的仿真环境被划分为验证环境 以及C算法模型两个互相独立的部分,两者可分别开发,互不影响。例如,即使验证环境使用的是SV语言,而C算法模型使用的是C语言,即两者使用的数据规格有所不同,也只需要在的格式转换即可,而不需要再将C算法模型通过DPI的方式导入到验证环境中,或者需要让C算法模型使用SV语言来实现来二次开发,减少了开发周期。此外,C算法模型可以作为独立的一个模块进行开发,因此可不需要开放源代码,数据保密性较佳,减少了在与第三方进行合作时的泄漏风险。

附图说明

图1是一种芯片的仿真环境的基本结构图;

图2本发明的一种基于可执行文件的芯片验证方法实施例的步骤流程图;

图3本发明的一种芯片的仿真环境的基本结构图;

图4是本发明的一种芯片验证的仿真流程示意图;

图5是本发明的一种基于可执行文件的芯片验证装置实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本发明作进一步详细的说明。

参照图2,示出了本发明的一种基于可执行文件的芯片验证方法实施例的步骤流程图,所述芯片的被测设计可以位于验证环境之内,所述可执行文件可以独立于所述验证环境之外;

参照图3所示的本发明的一种芯片的仿真环境的基本结构图,在本发明实施例中的仿真环境中,在先验证环境下的参考模型已经不存在,而是用独立于验证环境之外的C算法模型替代,C算法模型下可以生成C可执行文件,并可独立于验证环境执行。在进行芯片的被测设计的验证时,在验证环境与可执行文件下分别基于测试用例得到输出结果,最后 在验证环境中进行比对,从而得出芯片被测设计的验证结果。

所述方法具体可以包括如下步骤:

步骤101,生成配置信息和数据包;

在本发明的一种优选实施例中,所述步骤101可以包括如下子步骤:

子步骤S11,生成随机种子;

子步骤S12,按照预置测试用例约束采用预置测试用例和所述随机种子,生成配置信息和数据包。

在本发明实施例中,在开始进行芯片的被测设计验证后的第一次编译过程中,首先将生成随机种子,这个随机种子一般是当前的时间信息(格式可以是年-月-日-小时-分钟-秒),由于不同时间进行验证时的时间信息必然有所不同,这样就能够保证在执行同样的测试用例时,每次得到的随机种子是不一样的,因此在随后采用测试用例产生的随机配置信息和数据包等数据也将会是不一样的。

当然,在实施本发明实施例时,随机种子也可以采用其他能够保证随机种子是不一样的方式来生成,比如可以通过设置的种子生成规则,可以随机生成一系列不同的随机种子,或者设置一个种子列表,在需要调用随机种子时直接从种子列表中提取,本发明实施例对此不加以限制。

在本发明的一种优选示例中,可执行文件可以采用C算法模型生成的C可执行文件。

本发明实施例在第一次编译过后,将进行预仿真,也称为第一次仿真。具体地来说,是根据随机种子及预先设置好的测试用例约束,生成配置信息和数据包。当预仿真得到配置信息和数据包后,退出预仿真。

在本发明的一种优选实施例中,在步骤101之后,即在所述生成配置信息和数据包的步骤之后,还可以包括如下步骤:

将所述配置信息和数据包转换为符合所述可执行文件格式的配置信息和数据包。

步骤102,在所述可执行文件中依据所述配置信息和数据包生成第一输出结果;

在本发明的一种优选实施例中,所述步骤102可以包括如下子步骤:

子步骤S21,在所述可执行文件中采用所述符合可执行文件格式的配置信息和数据包,计算第一输出结果;

子步骤S22,将所述第一输出结果保存到指定的文件中。

当退出预仿真后,可直接调用并运行C可执行文件。需要说明的是,在预仿真过程中,验证环境已经对配置信息进行了格式转换,输出的配置信息和数据包是直接符合C可执行文件需要的,因此,退出预仿真后,可直接调用C可执行文件,C可执行文件会直接读取预仿真输出的配置信息和数据包,输出第一输出结果,并保存到指定的文件中,以供后续芯片的被测设计验证时的比对使用。

步骤103,在所述验证环境中依据所述配置信息和数据包生成第二输出结果;

在本发明的一种优选实施例中,所述步骤103可以包括如下子步骤:

子步骤S31,采用所述验证环境所需的配置信息配置所述芯片的被测设计;

子步骤S32,将所述验证环境所需的数据包发送到所述芯片的被测设计中;

子步骤S33,在配置后的芯片的被测设计中采用所述数据包计算出第二输出结果。

在本发明实施例中,还会继续进行重新编译,也即是进入芯片验证的第二次编译过程。由于前面的流程会耗费一点时间,这样在重新编译时产生的随机种子与第一次编译时产生的随机种子就会不一致,如果直接用本次随机种子进行后面的过程,将会产生与第一次预仿真过程不一致的配置信息和数据包,这样后面得到的在验证环境中的输出结果也会不一致,考虑到这些问题,在本发明实施例的重新编译过程可以直接利用第一次编译过程产生的随机种子,后续仿真过程也会一直用这个随机种子,这样随机出的配置信息和数据包就会与预仿真时产生的一致。

本发明实施例在第二次编译过后,将在验证环境中进行芯片的第二 次仿真。在验证环境中将配置信息由图3所示的Driver组件通过配置接口写入DUT(芯片的被测设计)中,完成整个配置过程。同时,还会将数据包由图3所示的Driver组件通过数据接口传到DUT中,完成数据包传输动作。然后DUT根据配置信息,对于收到的数据包进行计算等处理,得到最终输出结果。

在本发明的一种优选实施例中,在所述子步骤S33之后,也即是在所述将验证环境所需的数据包发送到所述芯片的被测设计中的步骤之后,还可以包括如下子步骤:

统计发送到所述芯片的被测设计中的数据包的个数。

在具体实现中,将实时对于发送到芯片的被测设计数据包的个数进行统计。在本发明实施例中对于芯片的被测设计验证数据包的个数进行控制,当发送的数据包达到设定的个数时,就可以认为满足结束条件,并停止仿真。

步骤104,采用所述第一输出结果和所述第二输出结果验证所述芯片的被测设计。

在本发明的一种优选实施例中,所述步骤104可以包括如下子步骤:

子步骤S41,读取所述第一输出结果和所述第二输出结果;

子步骤S42,将所述第一输出结果和所述第二输出结果进行比对;

子步骤S43,若所述第一输出结果和所述第二输出结果不一致,则判定为所述芯片的被测设计验证失败;

子步骤S44,当判断为芯片的被测设计验证失败时,停止验证所述芯片的被测设计。

在本发明的一种优选实施例中,所述步骤104还可以包括如子下步骤:

子步骤S51,若所述第一输出结果和所述第二输出结果一致,则继续将所述验证环境所需的数据包发送到所述芯片的被测设计中;

子步骤S52,在配置后的芯片中继续采用所述数据包计算出第二输出结果;

子步骤S53,当所述数据包的个数达到预设个数,且所述第一输出结果和所述第二输出结果一致,则判定为所述芯片的被测设计验证成功。

在本发明实施例中,根据图3所示的Monitor组件进行收集然后打包,输出给checker组件,checker收到DUT的输出结果后,会通过读文件的方式获取预仿真过程中C算法模型的输出结果。最后将DUT的输出结果和C算法模型的输出结果进行比对,即可获知芯片的被测设计最终验证结果。

在本发明实施例中,如果第一输出结果和所述第二输出结果,也即是DUT的输出结果和C算法模型的输出结果的比对结果正确,则不满足预设的退出条件,则暂时还不会退出验证,而是继续处理下一个数据包继续进行比对的操作,直到数据包达到预先设置的个数时,才会视为满足结束条件,结束仿真。

在本发明的具体实施中,当发送数据包的个数满足设定的个数时,视为满足结束条件,也会结束芯片的被测设计的验证。如果最后比对结果均正确,又满足了结束条件,则可以说明芯片的被测设计验证成功,此时就可以打印表示芯片的被测设计验证成功的正确信息。

在另一种情况下,如果可执行文件得到的第一输出结果和验证环境得到的第二输出结果的比对结果不正确,那么说明芯片的被测设计验证失败,则可以停止该芯片的被测设计的验证,并打印表示验证失败的错误信息。

在本发明实施例中,可执行文件操作置于预仿真后,第二次仿真前,当然也可以置于第二次仿真后,本发明实施例对此无需加以限制。

在本发明的一种优选示例中,可以将可执行文件操作置于预仿真后,第二次仿真前,那么如果在验证环境下第一次发送数据包时,被验证出失误,就可以立即停止仿真,并上报错误,及时发现问题,减少整体的仿真时间。

由于本发明实施例中的验证环境与可执行文件互相独立互不影响,可执行文件不需要再作为验证环境中的一部分,即使验证环境与生成可 执行文件的模型比较复杂,由于其与验证环境互相独立互不影响,那么在芯片的被测设计验证过程中,可以减少所需使用的内存,提高验证效率。

本发明实施例最关键之处之一在于:在整个仿真环境下,验证环境的参考模型已经不存在,而是用独立于验证环境之外的C算法模型的输出结果与DUT的输出结果在checker中比对。由于C算法模型独立于验证环境执行,并且是可执行文件,那就需要解决如下问题:

1、保证每次仿真时验证环境中随机产生的配置信息与数据包能够被C算法模型获取。

2、C算法模型能够根据验证环境随机产生的配置信息和数据包输出能够与DUT比对的输出结果。

3、验证环境在仿真过程中获取C算法模型的输出结果与DUT的输出结果进行比对。

为解决上述问题,在本发明实施例中引入随机种子机制,预仿真机制,文件读写机制。参照图3所示的本发明实施例的一种芯片的被测设计仿真环境的基本结构图,整个仿真环境被划分为验证环境和C算法模型这两个互相独立的部分。其中,在验证环境下包括Driver、DUT、Monitor以及checker,C算法模型以及其下的C可执行文件则独立于验证环境,C算法模型下则包括C可执行文件。

参照图4所示的本发明的一种芯片的被测设计验证的仿真流程示意图,具体验证流程详细说明如下所示:

1编译:在DUT验证开始后的第一次编译过程中,会生成随机种子,这个随机种子一般是当前的时间信息(年-月-日-小时-分钟-秒),这样能够保证在执行同样的测试用例时,每次得到的随机种子是不一样的,因此在测试用例产生的随机配置信息和数据包也是不一样的。

2预仿真:也称为第一次仿真,这个动作已经启动了仿真的动作,但不会执行具体的配置DUT,发送数据包等动作,这个过程只会在仿真环 境中根据随机种子及测试用例约束,生成C可执行文件所需要的配置信息和数据包。然后将配置信息和数据包写入指定的文件中。由于不执行具体配置DUT,发送数据包等动作,因此预仿真过程会很快,仿真时间几乎可以忽略不计。

3退出仿真:由于在预仿真过程中,不会执行配置DUT,发送数据包等动作,在预仿真结束后,环境会自动退出。

4运行C可执行文件:运行C可执行文件的动作在退出预仿真之后,直接调用C可执行文件。C可执行文件会读取预仿真过程中产生的配置信息和数据包,然后根据配置信息和数据包,计算得到输出结果,并保存到指定的文件中,供后续比对使用。

5重新编译:这个动作及其以后的过程,才是真正仿真的开始。由于前面的流程会耗费一点时间,这样在重新编译时产生的随机种子与第一次编译时产生的随机种子就会不一致,如果直接用本次随机种子进行后面的过程,将会产生与第一次预仿真过程不一致的配置信息和数据包,这样DUT得到的配置信息及数据包就会与C算法模型得到的配置信息及数据包不一致,那么最后计算得到的输出结果肯定会不一致。因此,本示例中为了使DUT和C算法模型用的是相同的配置信息及数据包,在进行重新编译这个动作时,直接读取第一次编译时生成的随机种子,且后续仿真过程也会一直用这个随机种子,这样随机出的配置信息和数据包就会与预仿真时产生的一致。不会出现由于随机种子不一致导致输出结果不一致的情况,避免验证失误。

6配置DUT:此过程会根据随机种子及测试用例约束,生成DUT所需要的配置信息,然后将配置信息由图3所示的Driver组件通过配置接口写入DUT中,完成整个环境配置过程。

7给DUT发送数据包:此过程会根据随机种子及测试用例约束,生成DUT所需要的数据包,然后将数据包由图3所示的Driver组件通过数据接口传到DUT中,完成数据包传输动作。

8DUT数据计算结果:DUT根据配置信息,将接收到的数据包进行 计算等处理,计算得到最终输出结果,然后进行输出。

9数据比对:DUT的输出结果,由图2所示的Monitor组件进行收集然后打包,输出给checker组件,checker接收到DUT的输出结果后,会通过读文件的方式获取预仿真过程中C算法模型计算的输出结果。然后与DUT的输出结果进行比对。

10满足结束条件:如果两个输出结果出现数据比对错误,满足结束条件,将退出整个仿真,并打印错误信息。如果比对结果正确,则不满足退出条件,仿真环境不会退出,而是会继续处理下一个数据包,继续重复如图5所示动作。当发送数据包的个数满足仿真环境设定的个数时,才视为满足结束条件,仿真环境也会结束仿真,但是不会打印错误信息,而是打印正确信息。

从以上过程可以看出,本发明实施例已经解决了在一开始时提出的几个需要解决的关键问题。此处还有几点需要进行说明:

1、预仿真过程的控制:本发明实施例是通过宏定义的方式进行实现的。例如,可以在验证环境中的配置DUT、给DUT发送数据包等动作中加入`RE_SIM的宏定义,在第一次编译时,不加入该宏定义,则不会执行配置DUT、给DUT发送数据包等动作,在第二次重新编译时,加入该宏定义,即可进行配置DUT、给DUT发送数据包等动作,完成整个正常仿真。当然,对于不同的验证环境来说,还可能有其它的方案能够达到预仿真的目的,本发明实施例对此不加以限制,但由于宏定义的方式比较简单直接,易于操作,故通常使用宏定义的方式。

2、C可执行文件处理:由于C可执行文件是直接由C算法模型得到,而C算法模型需要的配置信息的格式及内容,可能与DUT所需要的不能完全一致。因此,在本发明实施例的验证环境中,需要根据测试用例约束将随机产生的DUT配置信息按C算法模型所需要的格式进行转换,然后才输出到C算法模型中。这也是为什么在执行配置DUT等动作时不直接读取预仿真产生的配置信息的原因之一。同时,由于C算法模型可能会是其它小组人员开发,这就需要在开发过程中,定义好所需要的配置 信息格式,数据包格式,输出结果格式,以便于最大限度的重用。

3、随机种子处理:在本发明实施例中重新仿真的随机种子需要与预仿真的随机种子一致,当然如果随机种子不一致,也可以实现DUT和C采用相同的配置信息及数据包,这就需要在第一次编译过程中在输出C所需要的配置信息及数据包的同时,还需要按照Driver的格式需求,输出DUT所需要的配置信息及数据包,然后在仿真时Driver读取配置信息及数据包,通过配置接口及数据接口发送给DUT。但是这种方式可能会增加仿真过程中内存的开销,减慢仿真速度,故一般会选用直接调用使用第一次仿真时产生的随机种子。当然,可以根据实际情况选择相应的处理方式,本发明实施例对此无需加以限制。

4、运行C可执行文件:在本发明实施例中运行C可执行文件操作置于预仿真后,第二次仿真前,当然也可以置于第二次仿真后。即执行完DUT的仿真,对DUT输出的结果写入指定的文件中,然后执行C可执行文件,将C可执行文件的输出结果与DUT的输出结果通过仿真环境的脚本进行比对。但这样做最大的问题是不能进行实时数据比对,需要等整个仿真结束后,才能确定是不是有错误。这样一来,如果一次仿真需要10个数据包,需要仿真10小时,当第一个数据包就错误时,要等10个数据包发送完成后才能知道,即10个小时后才能发现问题。因此本发明的一种优选示例将运行C可执行文件操作置于预仿真后,第二次仿真前,那么在验证环境中的第一个数据包错误后就会立即停止仿真,并上报错误,及时发现问题,减少整体的仿真时间。

应用本发明实施例,由于在整个芯片的仿真环境被划分为验证环境以及C算法模型两个互相独立的部分,两者可分别开发,互不影响。例如,即使验证环境使用的是SV语言,而C算法模型使用的是C语言,即两者使用的数据规格有所不同,也只需要在的格式转换即可,而不需要再将C算法模型通过DPI的方式导入到验证环境中,或者需要让C算法模型使用SV语言来实现来二次开发,减少了开发周期。此外,C算法模型可以作为独立的一个模块进行开发,因此可不需要开放源代码,数 据保密性较佳,减少了在与第三方进行合作时的泄漏风险。

需要说明的是,对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明实施例并不受所描述的动作顺序的限制,因为依据本发明实施例,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本发明实施例所必须的。

参照图5,示出了本发明的一种基于可执行文件的芯片验证装置实施例的结构框图,所述芯片的被测设计可以位于验证环境之内,所述可执行文件可以独立于所述验证环境之外,所述装置具体可以包括如下模块:

数据生成模块201,用于生成配置信息和数据包;

在本发明的一种优选实施例中,所述数据生成模块201可以包括如下子步骤:

随机种子生成子模块,用于生成随机种子;

配置信息和数据包生成子模块,用于按照预置测试用例约束采用预置测试用例和所述随机种子,生成配置信息和数据包。

在本发明的一种优选实施例中,还可以包括如下模块:

数据转换模块,用于将所述配置信息和数据包转换为符合所述可执行文件格式的配置信息和数据包

第一输出结果生成模块202,用于在所述可执行文件中依据所述配置信息和数据包生成第一输出结果;

在本发明的一种优选实施例中,所述第一输出结果生成模块202可以包括如下子模块:

第一输出结果计算子模块,用于在所述可执行文件中采用所述符合可执行文件格式的配置信息和数据包,计算第一输出结果;

输出结果保存子模块,用于将所述第一输出结果保存到指定的文件中。

第二输出结果生成模块203,用于在所述验证环境中依据所述配置信息和数据包生成第二输出结果;

在本发明的一种优选实施例中,所述第二输出结果生成模块203可以包括如下子模块:

芯片配置子模块,用于采用所述验证环境所需的配置信息配置所述芯片的被测设计;

数据包发送子模块,用于将所述验证环境所需的数据包发送到所述芯片的被测设计中;

第二输出结果计算子模块,用于在配置后的芯片的被测设计中采用所述数据包计算出第二输出结果在本发明的一种优选实施例中,所述第二输出结果生成模块203还可以包括如下子模块:

数据包个数统计子模块,用于统计发送到所述芯片的被测设计中的数据包的个数。

芯片验证模块204,用于采用所述第一输出结果和所述第二输出结果验证所述芯片。

在本发明的一种优选实施例中,所述芯片验证模块204可以包括如下子模块:

输出结果读取子模块,用于读取所述第一输出结果和所述第二输出结果;

输出结果比对子模块,用于将所述第一输出结果和所述第二输出结果进行比对;

芯片验证失败判定子模块,用于若所述第一输出结果和所述第二输出结果不一致,则判定为所述芯片的被测设计验证失败;

芯片验证停止子模块,用于当判断为芯片验证失败时,停止验证所述芯片的被测设计。

在本发明的一种优选实施例中,所述芯片验证模块304,还可以包括如下子模块:

数据包继续比对子模块,用于若所述第一输出结果和所述第二输出 结果一致,则继续将所述验证环境所需的数据包发送到所述芯片的被测设计中;

第二输出结果继续计算子模块,用于在配置后的芯片的被测设计中继续采用所述数据包计算出第二输出结果;

芯片验证成功判定子模块,用于当所述数据包的个数达到预设个数,且所述第一输出结果和所述第二输出结果一致,则判定为所述芯片的被测设计验证成功。

在本发明的一种优选实施例中,所述随机种子可以包括时间信息;所述可执行文件可以为C算法可执行文件。

对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。

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

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

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

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

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

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

以上对本发明所提供的一种基于可执行文件的芯片验证方法和一种基于可执行文件的芯片验证装置,进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用 于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。

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