SoC验证技术已经落后于设计和制造能力，如何构建更快更好的设计验证方法是当前最大的问题。
SoC经过近十年的发展，有了广阔的市场。SoC验证研究领域在验证技术、验证方法学、测试码提取、验证描述语言、IP核重用验证、验证流程及验证评估方面取得了长足进步。但总体而言，验证、模拟和验证工作成为整个SoC学科发展的制约瓶颈，是提高设计生产率的障碍。
目前芯片一次投片成功率在35%左右，造成重复投片的主要原因就是验证不够充分。1999年当VSIA举行验证专题会时，许多世界级验证专家得出结论: 验证是件困难的事（hard），几周后又把结论更正为“Verification is not hard，it is very hard”。现在愈来愈达成共识: 单一的设计工具难以解决验证问题，而需要一系列复杂的工具和技术，来减少设计错误数，使之达到可接受的程度。
SoC验证工作比较繁杂。Janick Bergeron给“验证”下的定义是“证明一个设计的功能是否正确的过程”。SoC的验证工作贯穿整个设计流程，从行为级HDL设计，一直到芯片设计定案之前都需要做足够多的验证工作，当前验证工作量已经占整个设计工作量70%左右。
SoC验证研究内容很多，如: IP核/模块级验证、系统级验证、仿真验证、软硬件协同验证、等价性检查、静态时序分析和时序验证、版图验证等。随着验证技术的逐步发展，验证方法由最初的直接测试向量生成（Directed Test Vector Generation），到约束随机测试(Constrainted Random Test)，再到覆盖驱动验证(Coverage driven Verification)，一直到最新的基于断言的验证方法(Assertion-based Verification)，各种验证方法在不断创新发展。
模块/IP核级验证
任何SoC设计均由一系列模块组成。模块可能是自己开发，也可能是重用第三方的IP核。不论哪种情况，在系统集成前做IP核验证工作是必需的。模块/IP核级软性检查(Link Checking)主要检查代码语法、可综合性、变量未初始化、结构化可支持性和端口失配性等; 规范模型检查主要做设计特征遗漏性检查，以在早期发现错误状况。对控制流设计验证效果明显，通过设计文档非正式说明、与设计者非正式沟通等途径抽取特征疑问，逐一验证，消除缺陷。
功能验证主要利用基准测试向量基于事件或基于时钟进行功能验证，如黑盒测试、白盒测试和灰盒测试等; 协议检查主要验证是否违犯总线协议或模块互连约定，按照协议逐一检查并比较结果; 直接随机测试通过随机产生数据、地址、控制等信号检查功能正确性，减少模拟仿真工作量; 代码覆盖率分析主要根据模拟仿真时统计代码被执行数，可以按陈述句、信号拴（Toggle）、状态机、可达状态、可触态、条件分支、通路和信号等进行统计分析，以提高设计可信度。
系统级验证
系统级验证主要确认芯片体系结构满足所赋予的功能/性能要求。系统级设计阶段将用户需求转换成功能/性能要求，并实现行为/功能设计，然后映射到相应的体系结构上（设计输入、硬IP核、软IP核、软/硬件划分、性能分析、总体优化、性价比评估等反复叠代），最后进行系统级验证。
在系统级验证中，往往要构建虚拟目标系统，如中科SoC芯片在实施验证时，将其所有对外接口挂接许多虚拟 IP核，同时编制了BIOS、RTOS及应用测试程序（包括驱动程序）。首先做功能验证，验证是否满足要求; 其次做软硬件性能验证; 第三做系统级基准测试（自顶向下验证策略），抽取特定功能，编制测试向量/程序，定义对错条件，覆盖所有功能，形成基准测试程序（反复迭代），用于模拟仿真。
在复杂SoC设计开发中，模拟仿真占整个验证工程师团队工作量的40％～70%，由于成本和市场压力，寻找灵巧的仿真技术十分迫切。
功能仿真: 主要关注模块-模块（IP核-IP核）间互连验证、系统总线协调性验证和标准规范兼容性验证等，由于复杂度高，可通过事件驱动和加速技术，如硬件加速器、模拟发生器和快速建模试验等来加速和简化仿真工作。
SoC的软硬件接口
SoC的软件平台
基准测试包: 首先搭建SoC整体架构，然后将每一模块（IP核）经基准测试包挂接到系统总线上。这些基准测试包有利于识别缺陷，但它们不是设计工作的一部分，而是为了验证而引入的。基准测试包测试向量来自于IP核供应商、直接随机产生、手工编制，或由系统级测试捕获。
事件驱动仿真: 使用比较普遍，像NC_Verilog、VCS等均支持，但受芯片规模和性能限制。首先设计代码被仿真工具所接受，其次编制基准测试向量（波形或RTL），第三运行仿真，第四通过单步调试，错误定位 、改正后可再次仿真。