验证层次一样平常包括UT、BT、IT、ST、EMU/FT。
验证经理卖力端到端芯片的验证事情，以是对验证的分层有一个全局清晰的认识。而且确保分层之后，验证出的工具没有遗漏。
部门现在侧重组件化的运作，以是项目成立起就天然就有一定的任务田划分。组件任务田即被组件领走，其自己会完成组件内的分层，即组件BB，组件模块，组件子系统，对应的验证分层便是组件UT、BT、IT或者组件FT/EMU。
以是，经由组件方案之后，剩余便是芯片顶层，公共BB，以及组件之间的合营的验证内容了。
芯片顶层 ：包括端到端场景，功能，以及性能，即多个子系统之间耦合的功能或对外呈现的系统性的芯片规格。这个是芯片集成验证的重点，一样平常有CORE层的集成验证和少量基于chip的st验证。
公共BB ：多个子系统之间运用的BB。一样平常还是有某个组件的人卖力验证，对应有公共BB的UT或者虽模块BT的验证，其他组件重用。
顶层逻辑：散落在子系统之外的逻辑，该类逻辑包括chip io，mpi、时钟、复位、dft等。这个也是集成验证的重点，一样平常有方案专项验证。
按照历史的项目和上述的认识，一样平常验证分层如下：
1、 子系统UT、BT、IT、EMU/FT。
2、 公共BB的UT。
3、 系统验证ST（core层）、系统集成验证（chip层）、集成验证的FT/EMU版本。
4、 专项验证：寄存器专项、crg专项、io专项、dft专项、ip专项，mem专项，mbist专项。
5、 由于一样平常认为的专项都只是针对功能，不针对业务，以是专项之外会有剖析是否带业务的专项验证，比如时钟运用方案的专项验证，顶层系统运用的dfx验证等。
6、 系统验证除了从顶层FS之外，还有部分隐蔽在子系统之间的，须要子系统识别出来的功能，也是须要系统验证来担保。这层验证一样平常通过验证需求表单来掩护，由集成验证来反标。
作为验证经理兼VSE，一样平常希望：
子系统的验证覆盖范围尽可能大些。因此，SE在做芯片逻辑架构在划分的时候要只管即便做到功能内聚，顶层的散逻辑只管即便少。
如果项目公共的逻辑较多，也是希望能够内聚，并由专人卖力验证。
验证完成任务田划分之后，还有一个主要的事情便是理清楚各层验证活动所须要的验证环境。对应解释如下：
1、 子系统UT、BT、IT、EMU/FT。一样平常组件方案子系统的UT/BT/IT/EMU/FT版本的验证环境，EMU/FT项目组会轻量化跟踪。
2、 公共BB的UT。随任务组件方案UT环境。
3、 系统验证ST（core层）、系统集成验证（chip层）、集成验证的FT/EMU版本。VPL/VSE方案验证ST环境，包括core层和chip层。
4、 专项验证：寄存器专项、crg专项、io专项、dft专项、ip专项，mem专项，mbist专项。专项验证有的利用的环境有独立的验证环境，大部分会基于ST的集成环境做开拓。
5、 由于一样平常认为的专项都只是针对功能，不针对业务，以是专项之外会有剖析是否带业务的专项验证，比如时钟运用方案的专项验证，顶层系统运用的dfx验证等。该类验证活动一样平常基于ST开展。
6、 系统验证除了从顶层FS之外，还有部分隐蔽在子系统之间的，须要子系统识别出来的功能，也是须要系统验证来担保。这层验证一样平常通过验证需求表单来掩护，由集成验证来反标。该类验证活动一样平常基于ST开展。
以是，集成验证须要特殊把稳两点：
第一个是集成验证对下贱验证环境的依赖关系。
第二个是顶层专项功能和业务专项对ST验证环境的依赖关系。
验证分层之以是主要，是由于其对芯片验证组的活动运作和终极的质量收敛具有主要浸染：
其一、芯片验证组的验证操持就基于验证分层后的各活动开展，跟踪和验证收敛。
其二、集成验证的完备性，则按照验证分层完成正芯片的验证反标和完备性的输出。
