本技术属于数字芯片领域,涉及一种用于集成电路芯片验证的通用验证系统,其顶层代码目录包括bin目录、lib目录和pub目录,所述通用验证系统的每个验证平台的目录包括tb目录、env目录、testcases目录、etc目录、inst.fl目录;在仿真开始后,收集每个etc目录下的所有配置信息,然后根据用户指定要仿真的验证用例,选取相应的测试用例所继承的编译参数进行验证平台的编译;编译完成后,再添加用户指定的仿真参数进行仿真;仿真完成后,根据build中指定的检查规则对仿真的log文件进行检查,判定验证用例是否通过。本发明具有统一的验证环境、灵活的测试用例管理、实时的验证结果展示、学习成本低、资源利用高、跨模块协作、统一参数管理、通用性强等优点。
背景技术
在集成电路(IC)芯片的前端验证过程中,现有的验证技术,大多是针对一种特定的接口或者特定验证场景的验证。例如公开号CN118503165A所公开的“数据交织处理方法、AXI VIP设备、装置及介质”,该发明针对的是使用amba(高级处理器总线架构)接口的验证模块;公开号CN118503161A所公开的“一种使用总线地址快速访问寄存器的方法”,该发明针对的是扫描寄存器的场景。
由于不同层次有不同的模块,都是分别由不同的工程师负责的,开发过程中很少有考虑各个层级之间相互复用其他人开发完成的代码的,或者由于没有统一的规范,每个工程师开发的验证平台各有特点,难以相互复用。
在现有技术,每个验证平台多是由一个单独的makefile(用于管理项目构建过程的工具)进行管理,或者每个验证平台有一套单独的脚本文件管理,没有统一的规划。
现有技术的主要缺陷如下:
1、验证环境的统一性不足
缺陷描述:不同项目和模块使用不同的验证环境和工具配置,导致代码难以复用。验证人员之间的沟通和协作成本高,同一问题在不同验证阶段反复出现。
解决方案的局限性:虽然一些验证平台尝试提供统一的验证环境,但由于设计复杂性和项目特定需求的差异,统一环境难以完全适用。现有工具缺乏灵活性,无法适应多样化的验证需求。
2、代码变更管理不善
缺陷描述:设计人员上传错误代码导致原本通过的测试用例再次失败,增加了验证工作量和不必要的重复劳动。
解决方案的局限性:现有的代码版本控制系统虽然能管理代码变更,但缺乏自动化错误检测和智能分析功能,无法提前发现和预防错误代码的上传。
3、测试用例管理的复杂性
缺陷描述:测试用例数量庞大且复杂,现有系统在测试用例的分类、管理和执行方面缺乏灵活性,导致回归测试效率低下。
解决方案的局限性:尽管一些测试管理工具提供了基本的分类和管理功能,但在大规模和复杂项目中,这些工具难以处理所有测试用例的灵活分类和优先级调整,导致测试效率不高。
4、验证结果的透明度和实时性不足
缺陷描述:验证人员难以及时获取仿真结果并进行分析,缺乏统一的平台来汇总和展示验证结果。
解决方案的局限性:一些工具提供了结果汇总和展示功能,但通常数据更新不及时,缺乏实时性,无法满足快速迭代和反馈的需求。
5、学习成本高
缺陷描述:新加入的验证工程师需要花费大量时间学习和熟悉现有系统,人员流动时,工作交接成本高。
解决方案的局限性:虽然一些公司提供培训和文档支持,但复杂的验证环境和工具配置仍然需要大量的学习时间和实践经验,无法快速上手。
6、效率和资源消耗问题
缺陷描述:仿真和调试需要大量的计算资源和时间,特别是在早期设计阶段,运行复杂的仿真任务时,往往会遇到长时间的等待和大量的错误分析。
解决方案的局限性:现有的仿真加速工具和高性能计算资源虽能提高效率,但高昂的成本和资源限制使得许多公司无法全面采用,导致资源分配不均。
7、验证覆盖率不足
缺陷描述:确保验证覆盖率是一个重大挑战,特别是在大规模设计中,现有的仿真和验证工具难以保证全面的验证覆盖率,导致潜在的设计缺陷难以被发现。
解决方案的局限性:尽管形式化验证和其他先进验证技术能提高覆盖率,但它们的复杂性和资源需求使得这些技术难以大规模应用,尤其是在资源有限的项目中。
基于此,提出本发明。
实现思路