在制造设计IC的整个流程中，无论是厂商或工程师最不愿听到的一件事，应该是把设计好的IC Tap out出去，而回来的Test Chip 却不能动作；这样的结果对IC设计公司来说，将是计划经费的无形增加、产品的上市时程（Time To Market）被延后，对计划的参与人和设计工程师来说，也将是信誉的受损与沉重的负担。

据一份统计研究报告指出，IC Tap out回来的芯片如果无法正常运作，大致可分为逻辑或功能上的错误、Timing问题、IC制造上的问题以及其他问题，而一颗IC回来不能正常动作，有时会同时有两个以上的Bug，例如同时有Timing以及功能不正确的问题，由(图一)的统计结果可以看到，在逻辑或功能上的错误竟然占了74％左右，这一个高得吓人的比率的确值得大家深思。

《图一 IC／ASIC首次投片失败主因比率》

系统验证的重要性与困难

事实上逻辑或功能上的错误大部分是可以被避免的，而避免这个问题的方法不外乎就是做验证（verification）。验证在字面上看起来简单，却是在整个设计IC的流程中最不被重视，也往往被认为是最麻烦、最无聊的一项任务，但它却占了74％的Tap out fail，也是IC无法动作的主嫌，其原因大概有以下几项：

1.系统验证的工作需要太多的系统应用经验

换一个项目就换一个应用方案，因此永远有K不完的系统应用规格和做不完的验证工作，事实上光是以一个手机的芯片来说，其验证系统若真要架起来大概会要人命，如果再加一些周边的应用接口，可想而知难度有多高。

2.背负重大责任却没成就感

做系统验证的工程师如果没有把功能完整验证，其下场是背负验证不完全、导致IC 功能错误的罪名，就算把IC的功能完整验证，IC Tap out 成功的功劳却只有IC 设计工程师而已，是IC 设计工程师把IC做的那么完美，而验证工程师只有苦劳。

3.大多数系统验证工程师不被上级主管所重视

大多的主管还是停留在早期的IC的研发观念，认为只要有IC 设计工程师就可以把IC做好、做出来。

4.IC的Gate Count越来越大，动辄数百万门逻辑闸

在早期，IC设计公司能做的Gate Count并不大、功能也有限，但在现今SoC的趋势之下，IP随处可寻，数百万门逻辑闸的IC设计也成为大多数公司的领域，当IC的Gate Count大到某一程度，其验证工作也随之复杂且困难。

(图二)正说明若要做好验证工作，当Gate Count慢慢增加，而软件要测的情况以及测试向量却是成指数成长，此时如果IC Gate Count到达一两百万，若还要用以前的验证方法，已经不切实际了。(图三)则说明了IC Gate Count增加对工作站仿真速度的影响，此时工作站也只能验证单个模块的测试，无法执行整个IC的验证，往往许多设计工作分开来测都没问题，但整合在一起就发生了问题，这种情况实在值得深思。然而系统面需要数颗大型FPGA来组合验证，不管在FPGA的分割、编译时间、除错环境及Probing Signal 都是大问题；因此大型Gate Count的IC功能验证的确是一个挑战。

《图二 IC Gate Count的增加与测试向量的暴增》

《图三Design Size对工作站及Emulator的Performance影响》

新一代的系统验证解决方案

针对以上诸多技术面的问题，其症结在于没有一个很好的验证平台以及解决方案，来解决IC Gate Count太大、验证环境不容易建立，以及仿真的速度太慢的问题，要解决这些难题，必须采用新一代的解决方案，以下将以Cadence的Palladium系统验证工具为例，提出各项可行的验证新技术。

CPU Base Emulator的技术及方法

Quickturn本身在早期就有两种实现仿真器（Emulator）的技术，一种为被广泛使用的FPGA架构，另一种则为CPU的架构，由于在早期CPU的频率速度比较慢，因此CPU架构的Emulator在运行速度方面比FPGA架构的仿真器来得慢，但到了这几年，整个局势已经慢慢的改变了，原因是在客户的设计Gate Count越来越大，仿真器要求的速度依然不变，虽然单独一颗FPGA已经可以做到很大的Gate Count，但是它的接脚却无法随着Gate Count的增加而变多，这个特性要应用在仿真器确实有其困难，因为仿真器要求的是在除错的时候，每一点的信号都必须能看得到，然而接脚数目不够，内部的信号就无法送到内存，以便储存侦错时所需要看到的波形，此时FPGA便需要以多任务的方式把信号送到IC外的内存，使用这个方法仿真器的速度会因此而大幅降低，更糟糕的是FPGA 架构的仿真器需要花非常久的时间做编译，而且编译时常常会发生Timing以及Clock处理的问题，导致不是需要重编译就是编译的结果运作不正常。

而Palladium为CPU Base Emulator带来的创新技术包括：

较快速的编译时间（Compile Time）

使用仿真器有一个产能的观念，那就是使用这一台机器需要花多少时间才可以帮用户找到设计的错误，这个时间应该是编译时间、仿真时间与除错时间的总合；当用户找到错误并修正设计之后，必须把设计重新编译一次再来验证修改是否正确，而如果以一个4M的设计来说，在一般的FPGA Compile时间大约需要20个小时，而Palladium却只需１个小时。

Full vision，让Design中每一点都看得到

设计者在使用除错工具时，首求是稳定及正确性，再来应该像是在用软件工具一样，设计中的每一个点都必须要看得到；当用户Debug到一半想要加入新的信号时，不需要再花冗长的时间做重编译。

RTL Debug，并保留RTL信号名称

在Debug时Palladium可以做RTL Debug，不再只是看一堆看不懂的Netlist节点名称，Palladium Compile时会保留RTL的原始信号名称，让设计者不会为了核对信号名称而找了老半天，(图四)为Palladium搭配整合交互式Source Debugger画面。

《图四 Palladium RTL Debug 环境》

让多位用户同时工作

一台仿真器的投资是可观的，由于每一家公司的项目随时在变，不太可能只是为了一个项目而购买一台机器，在成本效益来说并不高，然而站在客户的角度来看，如何提高机台的使用率，也就相对的等于提高了机台的成本效益。Palladium提供Multi User功能，让多位用户能够同时使用一台机器来提高机器的成本效益；Palladium所谓的Multi User Mode是指：在同一个时间只要机台的资源还没有被用完，就可以有第二个人以上连到Palladium放入不同的设计工作，各自做不同的项目除错，各个项目不限定要使用在Simulation Acceleration 或是In Circuit Emulation模式。以一台16M ASIC gate的机台来说，最多可以有16个人同时使用一台机器。

以事件为基础的仿真加速功能

面对现在的设计容量越来越大，设计者要监看的信号也越趋大量与复杂，使用事件基础验证（Transaction Base Verification）是提高设计者效率的方法之一；举例来说，现在的设计大多包含有CPU，而这个CPU也可能同时被使用在不同的项目中，每当设计者要监看CPU对某一个装置或内存做读写时，设计者要一一核对地址、数据、控制信号，而如果使用事件基础验证，将这些重复核对的动作交给计算机来处理，把每一组发出的信号类似一个封包，一些细部的控制信号交由工作站检查，而设计者只需要关心CPU发出的数据是否被周边装置收到了，工作站并以类似封包的方式显示出来，让用户更容易且清楚的看出一组总线上的状态。事件基础验证的功能当然不仅于此，不论对重新使用以及封包间的相对关系等，都有强大的功能，当Palladium操作在Simulation模式下时，当然就可以配合NC-Sim达到事件基础的仿真加速，在这个模式下的速度不但比传统的方式快且有效率，其速度大约每秒最快可以达执行约20KHz。

工作排程（Jobs scheduling）

在前面有提到所谓的机台使用率，如果一台事件基础验证有办法24小时工作的话那使用率绝对是无庸置疑的，然而要提高机台的使用率的困难点是工程师并没有24小时轮班，关于这点Palladium可以提供工作排程（Jobs scheduling）让工程师只要在回家前把需仿真的程序排班起来，隔天早上回来上班的时候，结果就已经在工作站的硬盘中了。

Save and Restore

@内文;用户可以把仿真器停下来并把状态储存到硬盘，操作在仿真加速（Simulation Acceleration）模式可以随时中断工作，方便用户把时间做有效的安排，而使用在ICE模式亦可以跳过初始化动作以及重复性的测试或工作，利用这个功能可以让仿真器适时释放出来让别人使用。

仿真速度与垂直解决方案

一台仿真器需要因应用户不同的需求，而把功能做得非常强大，也为了达到用户的需求仿真器的整个运行速度通常约1MHz左右，因为速度的关系有许多周边的设计并无法正常的动作，例如影像（NTSC、PAL）信号、PCI、AGP接口、Ethernet网络接口等，这些信号接口的速度转换对于第一次使用仿真器的人来说是一个很大的门坎，Palladium提供各种应用的桥接接口，不论是连接Gigabits Ethernet或是ARM、PCI等都有现成的解决方案。

接近真实世界的验证趋势

随着业界趋势发展的脚步，SoC以及IP的发展已经俨然成为兵家必争之地，如果能够有效率适当的使用仿真器，相信这一定能让Design House如虎添翼般的顺利完成这个梦想，试想IP将会由什么型态呈现？RTL code， Netlist 还是Test Chip？这些都有可能，而只要是可合成（Synthesizable）的就能放到仿真器内部，又只要是能接硬件的那就可以以IP子板的方式，插到IP Rack内部与设计案做验证，再以SoC的角度来看，完整的系统验证该是包含软件、硬件以及韧体，以最接近真实世界的方式来验证才是一个好的验证方法。

（作者为Cadence益华计算机资深技术工程师）