对许多人来说，LSI、VLSI这些名词，已如同真空管这个名词一般走入了历史。现在的IC设计这个领域，大家朗朗上口的都是SoC(System-on-Chip)、Embedded CPU、Embedded Memory这些名词。随着IC设计愈趋于复杂，验证工作也如恶梦般地困扰着工程师们。本文主要探讨在SoC的设计中，验证工作所必须面对的问题与解决的方法。

RTL阶段为成败关键

由于逻辑合成工具和自动布局绕线工具的使用，使得整个IC设计流程变得非常顺畅。只要RTL阶段的设计验证工作能确实无误，完全合乎规格书所规范的功能，那么整个设计个案几乎可以说已经完成了一大半。根据相关的研究数据，目前多数的IC设计个案中，RTL阶段的设计验证工作占了整个设计流程约60%～80%左右的时间；而且绝大多数的资源也都放在设计验证工作上，会造成如此大的比重不外乎是由于IC越设计越大和Embedded IP core的使用。

IC设计更复杂化

IC越设计越大，设计者需要验证的功能也越来越多；加上各式各样不同领域的应用规格、数据管理、网络、无线通信，使得IC的规格也越来越复杂。目前IC设计工程师所面对的设计复杂度是10年前的100倍以上，虽然有逻辑合成工具来加速设计工作，但是如恶梦般的验证工作却依然尚未自动化。

面对千奇百怪的应用规格，IC设计工程师无法利用现有的硬件描述语言或程序语言，去开发其Testbench在检查工作上；而必须靠人工的方式，去分析判断仿真结果的数据与时序是否与规格书一致。最重要的是，没有相关的数据让IC设计工程师了解功能验证的涵盖率是否足够？规格书中的所有功能是否都有达成？一些Corner Case是否有考虑到？甚至对于Error Case来说，IC设计工程师的设计是否反应得宜？所以如何将白纸黑字的规格书转变成IC，不仅要做的对，也要做的完全；这是科学，也是艺术。

Embedded IP Core的应用

再来是Embedded IP Core的使用。这些IP Core也许是旧设计的延用，也许是由IP供货商提供；但无论如何，这些IP Core对IC设计工程师来说都是一个比较难以摸索，难以掌握的部分。因为它们未曾在目前的系统应用环境中被验证过，当这些IP Core包含在整个SoC设计中时，增加了设计验证工作的困难，因为当设计仿真有问题时，IC设计工程师很难去判断到底是自己本身新的设计有问题？新的设计与IP Core之间的接口有问题？抑或是IP Core本身就有Bug？

工作界线模糊

另外一个造成设计验证工作无法顺利完成的原因是，"设计工作"与"验证工作"的分工问题。有些公司基于人力问题的考虑，往往是设计工程师兼验证工程师，工程师根据规格书去完成设计工作。同一个工程师同时完成TestBench去验证自己的设计，试想如果这位设计工程师对规格书内的某一条规格有所误解(尤其是用英文写成的规格书)，造成他的设计和TestBench都是错的，但仿真的结果却是合乎他的"预期"，于是一个有问题的IC就流出去了，解决这个问题的方法只有将"设计工作"与"验证工作"真正分工。目前已经有些IC设计公司开始实施这样的分工，由验证工程师开发TestBench去验证设计工程师的RTL设计，如此才不会造成有球员兼裁判的盲点。

IC设计流程改革重点

关于之前所提到的设计复杂度越来越高的问题，IC设计工程师不能再仰赖传统的方法，必须要朝三个功能去改善：

更自动化的方式开发TestBench(Automatic Testbench Generation)，仿真过程自动检查相关数据、时序---(Data Protocal Checking)，自动收集并分析功能涵盖信息(Functional Coverage Information)。

有了这三个改善功能的主要好处是，开发TestBench自动化后，验证工作的生产力便提升了。有了功能涵盖信息，IC设计工程师很容易知道那些功能没有被验证到，并加以改进，则IC验证的质量便有所保证。而要解决验证工作的困难，IC设计工程师就必须了解，开发TestBench是一件专门的工作，不再是附属于设计工作旁的一个小环节。

如同当初的逻辑合成和自动布局绕线一般，开发TestBench也必须要自动化，并往高阶描述语言方向发展。高阶描述语言的好处在于其可读性，有利于不同之间的流通，维护上也比较容易。至于要使用何种高阶描述语言来开发TestBench？Verilog HDL和VHDL有其不足之处，所以很多设计工程师才会使用像C、C++之类的程序语言去开发TestBench。

当然，有些EDA公司认为必须要新开发一种专门描述TestBench的高级语言。像最近才在美国NASDAQ公开上市的EDA公司「Verisity」，便提出了一个非常适合描述TestBench的高级语言"e-Lanuage"。并且将部分语法Donate给OVI这个组织，期望能使"e"更通行于IC设计领域。

至于Embedded IP Core对于验证工作的影响，有些IP供货商的解决方式便是将Interface Protocal Checking和Functional Coverage的功能内含在此IP Core的Model中。当验证工程师在仿真整个SoC设计时，便很容易得知新的设计与IP Core之间的接口是否有问题？由功能涵盖率(Function Coverage)的数据，我们也可以判断仿真工作是否足够？那些功能没有验证到？

例如ARM就提供了ACT(AMBA Compliance Testbench)的功能。ARM是全世界IP core的主要供货商之一，该公司也提出了一套用于SoC内部数据总线的标准接口AMBA。为了确保ARM的客户在开发AMBA相关的周边组件时，不会有兼容性不合的问题。ARM与Verisity合作，将Interface Protocal Checking和Functional Coverage的功能包含在内，如此当设计工程师在使用ARM的IP core时，就更容易掌握。

结论

最后必须强调的一点是，在SoC的领域中，验证工作的份量绝对不比设计工作还要来得轻松。因为IP Core的大量被使用，新的设计其所占的比例可能变得很小；但是要验证的却会是整个系统的整合部分，其复杂度可想而知。因此，验证工作的自动化和验证质量的提升，当然是目前IC设计流程的改革重点。(本文作者任职于茂积电子)