rapidio测试(rapidio总线)

目前市场上可见的产品基本都是国外公司的产品。2008 年 9 月，德州仪器公司发布了一款可实现速度达 30Gbps 双向点对点数据传输速率的四通道 SerDes 芯片 TLK3134，该芯片集成时钟抖动清除器，支持每串行通道 600Mbps 至 3.75Gbps的宽泛数据带宽，可以灵活地配置为 XAUI 或 10G FC 收发器。而另一家为通信、工业和消费类等应用领域提供模拟接口器件的厂商Avago Technologies 在 2009年宣布在 40nm CMOS工艺上实现 25Gbps SerDes，而其在 2007 年发布的基于65nm CMOS 工艺的 17Gbps SerDes，每条通道的工作速率高达 12.5 Gbps，截止 2009 年底，Avago Technologies 的 SerDes 产品的出货量已到达 9500 万通道。除了性能优异的独立 SerDes 芯片，市场上还有大量 SerDes IP 核产品。 随着光纤在通信中的应用，信道可以承载的通信速率已经可以达到GHz，从而使得接收端的接收速率成为限制通信速率的主要瓶颈。因此高速时钟数据恢复电路的研究是目前通信领域的研究热点。目前时钟数据恢复电路主要是模拟IC和数字IC，其频率已经可以达到几十GHz。而由于FPGA器件的可编程性、低成本、短的设计周期以及越来越大的容量和速度，在数字领域的应用逐渐有替代数字IC的趋势，已经广泛作为数字系统的控制核心。三大 FPGA生产厂商都在自己的高端 FPGA 中集成了 SerDes 硬核，Lattice 公司于 2009 年 3月推出内嵌 SerDes 的 FPGA 产品，该产品工作于3.2Gbps 的速率时，每个通道功耗额定为90mW。Xilinx 公司开发的 SerDes 收发器 IP 核 Rocket IOTM，也被广泛地用于其高端FPGA中，为广大用户提供了兼容XAUI，PCI Express，Serial RapidIO 等规范的 FPGA 解决方案，获得了市场的良好反响。SerDes硬核作为高端FPGA的冲击市场的有力武器，而对于低端FPGA来说，软的SerDes不失为一种非常好的研究方向。由于上面的原因，许多利用低端FPGA实现的高速通信系统中必须使用额外的专用时钟数据恢复IC，这样不仅增加了成本，而且裸露在外的高速PCB布线使还会带来串扰、信号完整性等非常严重的问题。如果可以在中低端FPGA上实现高速时钟数据恢复电路，则可降低成本且提高整个电路系统的性能。Lattice对于其低端的FPGA中实现softSERDES的研究相对其他FPGA生产厂商更为丰富，其在低端FPGA产品中对于高速串行通信的研究是其在进入市场后立刻取得较好市场的一个重要条件，其他FPGA厂商在低端FPGA中涉及高速串行口的设计较少，主要来自第3方公司对其进行的设计验证，但在通信速率一般都不高。 Lattice在其ECP2中实现了softSerDes，由于受到其IO没有差分信号的限制，而单极性信号在高于100MHz是噪声过大，所以其测试是在同一块板上200MHz的CDR测试。

如果你的cpu env将会作为另一个更大level的一个agent组件，情况就变得有点糟糕了； 如果你的cpu env将会例化很多个，用在一个更大level的环境里，情况就变得更糟糕了；如果你的pcie driver被作为一个component单独用在一个大环境的很多地方，且分布于树形结构的不同深度的话，简直是噩梦！再假如，目前我有一个环境，有10个pcie driver，其中5个作为sub component用在5个cpu agent里面，另外5个pcie driver单独作为sub component用在top env（前面的5个cpu agent包含于top env中）里面。我现在想吧cpu agent里面的3个pcie driver换成rapidio driver，剩下的2个保持pcie driver不变；top level里面的5个pcie driver也有相似的需求，如果是用方法（1）改代码，那你的测试平台将会很糟糕，不具有任何可扩展性，容易出错等等....... 不同的需求回很多，因为需求永远是在变化的，我们需要一种方法来很好的适应这种变化，factory机制就可以做到。
1.factory的需求来源 我们的测试平台一般都是通过component来组织成一个层次化的树形结构的，测试平台做什么事情取决于各个包含在其中的函数或者任务。总有一些时候，我们希望改变现有的处理机制或者流程。举例来说，我有一个通用的CPU总线的测试平台，在上层看来（软件同事们），这个东西对他们开放的接口就是两个：read（address，length），write（address，data），他们不管下面是PCIe还是RapidIO。假设目前的底层接口形式是PCIe总线，也就是说这个CPU agent中的的driver是一个PCIe的driver；有一天CPU换了，底层接口形式也跟着换成了RapidIO总线，那之前的CPU总线的测试平台能不能除了换个RapidIO的driver，其它不变？如果测试平台做的够好，应该是这个结果。但是怎么个换法？（1）把cpu agent.sv找到，改代码,至少有一个地方需要如下改改pcie_driver drv； ---》 rapidio_driver drv;（2）其他更好的方法？测试平台不用动，只需要在testcase中说明我现在希望用RapidIO driver来替换PCIe的driver。我们当然喜欢第二种。当然如果你的cpu env是一次性的，第一种方法也不错，如果是那样的话就与UVM思想相违背了，也会挨你继任同事的骂。如果你的cpu env将会作为另一个更大level的一个agent组件，情况就变得有点糟糕了；如果你的cpu env将会例化很多个，用在一个更大level的环境里，情况就变得更糟糕了；如果你的pcie driver被作为一个component单独用在一个大环境的很多地方，且分布于树形结构的不同深度的话，那方法（1）简直是噩梦！再假如，目前我有一个环境，有10个pcie driver，其中5个作为sub component用在5个cpu agent里面，另外5个pcie driver单独作为sub component用在top env（前面的5个cpu agent包含于top env中）里面。我现在想吧cpu agent里面的3个pcie driver换成rapidio driver，剩下的2个保持pcie driver不变；top level里面的5个pcie driver也有相似的需求，如果是用方法（1）改代码，那你的测试平台将会很糟糕，不具有任何可扩展性，容易出错等等.......不同的需求回很多，因为需求永远是在变化的，我们需要一种方法来很好的适应这种变化，factory机制就可以做到。2.我心目中的UVM factory的演进2.1 使用继承来解决2.1.1 前提：（1）有一个基类叫做cpu_bus_driver，所以的cpu总线的driver都从这个base class继承（2）cpu_bus_driver中定义一系列的总线操作，而且这写总线操作对它的任何继承者来说都是充分的：get_transfer（）：得到此次cpu操作类型（read or write），地址，长度，写数据drive_bus（）：把读写操作转化成最后的signal level的信号get_response（）：返回读数据或者写是否成功的响应（如果需要的话）当然这些函数都是virtual的。（3）cpu_bus_agent中这样实例化了driverclass cpu_bus_agent ;.......cpu_bus_driver driver ;function build();. .......driver = new("driver");. ........endfunction（4）测试平台的层次结构是：cpu_env.cpu_agent.cpu_drivercpu_env在cpu_base_test中实例化。2.1.2 方法step1：定义新类：new_cpu_bus_driverclass new_cpu_bus_driver extends cpu_bus_driver ;........定义自己的get_tranfer, drive_bus, get_response函数endclassstep2：替换原有的类。因为不能修改cpu_env及其一下各层次的代码，所以只能在testcase中进行替换：class cpu_test1 extends cpu_base_test ;new_cpu_bus_driver new_driver ;......new_driver = new("new_driver");cpu_env.cpu_agent.cpu_driver = new_driver ;.......endclass2.1.3效果没有修改任何cpu env及其一下层次的代码。2.1.4问题（1）上面标示的蓝色粗体为关键代码，但是这个语句的执行时间点需要精确把控。如果太早，则在运行cpu_agent.build()之后cpu_agent中的driver又会被重置为cpu_bus_driver而不是new_cpu_bus_driver；如果太晚，则可能cpu agent可能已经用cpu_bus_driver运行了一段时间了，然后才会切换成new_cpu_bus_driver，这样回导致前面的错误操作。最佳时间点显然是在所有的build phase之后，任何connection phase之前。（2）开发testcase的人需要准确的知道cpu env的层次结构，也就是说需要知道xxx.xxx.xxx.xxx形式，很显然这是个缺点；（3）如果有100个cpu driver需要替换，那么就需要100次cpu_env0.xxx.xxx.old_driver = new_driver ;....cpu_env99.xxx.xxx.old_driver = new_driver ;如果你觉得这个也不是问题，因为层次结构很规整嘛；那还有更麻烦的：old_driver被单独用到了一些地方而不是只用在了cpu agent里面，比如A_env.xxx.xxx.old_driver，B_env.xxx.old_driver，C_env.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.old_driver......那你准备怎么办？而且这种情况下缺点（2）的影响会更恶劣!2.2 第一次改进使用查找表来记录每个对象是否需要被替换。2.2.1 缺点的本质：（1）需要准确的时间点的本质原因是testcase不知道driver时候被创建的确切时间！所以需要找个最保险的时间点，那就是在所有的组件都创建之后，但是又不能早于connection phase，幸好uvm提供了各个phase的管理，否则这个问题解决起来就特别棘手！我们选择的时间点过于保守了，最合适的时间点就是在需要被创建的时候就做替换！也就是说每个对象的new函数调用处就是最佳的替换时间点。（2）需要知道层次结构的本质是在testcase层次以下没有任何东西来记录每个对象的路径!如果有这么一个地方，它记录了所有存在于环境中的对象的路劲，那么我只需要对它说，把你的记录里面每个driver对象都换成new driver。我只想对这个记录中心提供如下信息：1）我需要替换所有的driver，无论它分布于何处，它的层次路劲如何2）把driver替换成new driver.其余的交给记录中心来完成，我不想知道怎么做。2.2.2 缺点的改进（1）怎么样才能在每个对象new的时候就能够做替换呢？首先，我们需要知道的一条重要的限制就是new函数返回的对象永远都是它声明的类类型的对象！也就是说 ：A a_obj ；=》任何时候我们调用a_obj = new；返回的对象永远是A类类型的，不可能是其他类，连A的继承类也不可能！就是注意点彻底的告诉我们，需要一种方法（假设叫create方法）来代替new函数，当我调用它的时候，它不是100%返回A类型，而是视情况而定，什么情况？那就是：当我不像替换A的时候它返回A类类型的对象；当我想用A的派生类A1替换A的时候它能返回A1类类型的对象；当我想用A的派生类A2替换A的时候它能返回A2类类型的对象..........我们不应该在这里用new，而是用create！（2）很明显，我们需要数据库来记录每个对象的基本信息第一个数据库的每个条目可能如下：层次路径 对象类型“a.b.c.obj1” A“a.b.obj2”B“a.b.obj3”A第二个数据库的每个条目可能如下：原对象的类型 希望被替换成的类型AA1BB2CC(也就是不替换)这种数据结构用关联数据再合适不过！2.2.3 实现对于缺点1的改进，按照我们的分析，应该做如下改变：a) 在cpu agent中创建driver的时候不用new函数，用另外一个叫做create的函数，用这个函数取代new函数。问题来了，这个create函数应该放在哪里？具有神马性质？首先，这个create函数可以放在cpu driver类及其子类中；或者外面。我们假设放在cpu driver类及其子类中。其次，既然能够取代new函数，那么必须不能针对于某一个具体对象，不然不能够调用；所以create应该是静态的。再则，我们的主要目的是需要这个函数视是否需要被替换的情况而来产生出对应的对象。达到这个目的可有很多种方法，最直观的一种是：在create之前我去中心数据库查一下先，如上述的第二个数据库，如果目前查到这样一条条目：/“原对象类型 cpu_bus_driver”，"需要替换"，“替换成的对象类型 new_cpu_driver”/,那么我就可以知道虽然实在调用cpu_bus_driver的create函数，但是实际上是想让我生成cpu_bus_driver的继承类new_cpu_bus_driver！对应缺点2的改进需求，我们可以建立一个数据库中心，取名叫做factory，它的核心内容就是若干个map，每个map中的条目都是为create函数来服务的。好了，基于上述的分析，我们写出如下的伪代码：class cpu_bus_driver ;.......virtual function cpu_bus_driver create_object();cpu_bus_driver me ;me = new ;return me ;endfunctionstatic virtual function cpu_bus_driver create();cpu_bus_driverkey;key = new ;new_driver = factory.create_object(factory.lookup(key));return new_driver ；endfunctionendclassclass new_cpu_bus_driver extends cpu_bus_driver;.......virtual function cpu_bus_driver create_object();new_cpu_bus_driver me ;me = new ;return me ;endfunctionstatic virtual function cpu_bus_driver create();new_cpu_bus_driverkey;key = new ;用key作为键字去factory的数据库中查出替换条目，得知想不需要替换factory利用查得的结果，生成一个new_cpu_driver对象给我，叫做 new_driverreturn new_driver ；endfunctionendclassclass factory ；cpu_bus_driver override_map [cpu_bus_driver] ;function cpu_bus_driver lookup(cpu_bus_driver key);return overrride_map[key];endfunctionfunction cpu_bus_driver create_object(cpu_bus_driver override_obj);return override_obj.create_object();endfunctionendclass好了，举例来说明一下具体的工作过程：a）声明一个 cpu_bus_driverdriver；b）调用 driver = cpu_bus_driver::create();b1）key = new ；////key是cpu_bus_driver类的b2）factory.lookup（key）；////返回一个new_cpu_bus_driver信息b3）factory.create_oject(new_cpu_bus_driver);b4）调用new_cpu_bus_driver::create（）；b5）new_cpu_bus_driver::create()调用new_cpu_bus_driver的new函数生成一个new_cpu_bus_drive类型的对象赋给driver经过上诉调用后driver就不是它声明是的cpu_bus_driver类型的一个对象了，而是一个地地道道的new_cpu_bus_drive类型的对象了，唯一一点的遗憾就是这个对象是用父类的句柄hold住的。2.3 第二次改进细心的朋友可能已经注意到上述实现的一个问题就是，factory的override map的键字是一个cpu_bus_driver的对象，而我的cpu_bus_driver类型的对象可能很多，举例来说如果override map中的cpu_bus_driver键字是一个叫做 “张三”的，很明显，如果我随意创建一个新的cpu_bus_driver类型的对象“李四”，虽然他们都是cpu_bus_driver类型的，但是用“李四”去查factory的override map时，就会查不到任何条目！这个就是2.2的实现中的一个问题！如何改进？很自然我们想到一种解决方案:用一个全局的众所周知的cpu_bus_driver对象去做键字。这个对象是给factory的override map专用的，不做他用，假设“张三”就是这样一个对象。这样一来问题就解决了，任何时候只要是想查询cpu_bus_driver类型的override条目，我只需要用 factory.override_map[“张三”]来查询即可！这个解决方案看起来好多了，也解决问题了，但是记得有一个前提就是：记得在进行任何查找override map[“张三”]之前，确保这个条目已经存在！看到这里，大家可能已经马上就想到了UVM中的factory register，没错！就是要向factory中注册！注册越早越好！2.4 第三次改进在第二次改进中，我们提议用一个众所周知的全局对象来向factory注册，然后用这个注册的全局对象来作为override map的查询的key来得出是否需要替换成别的子类的结论。这没有任何问题，但是不优美！原因有如下几点：（1）比如我有一个类叫做tcp_pkt，我希望我可以创建一个叫任何名字的tcp_pkt的对象，而不是叫“张三”的名字我不能取，因为这个“张三”被factory专用！在一个大型的环境中，会有很多个用户定义的类类型，比如除了tcp_pkt，还有ip_pkt，udp_pkt，还有其它方面的如ethernet_driver，ethernet_monitor.........假设设计中有100个类类型，那我岂不是要记着100个“张三”，“王三”，“李三”.......这些factory专用对象！（2）性能和效率太差！为什么这么说呢？如果我定义的类很复杂，那么这对象势必需要专用很大的内存，而每个类都需要一个factory专用对象，这些对象一直存在着[因为在override map随时都有可能需要lookup]，所以内存不释放！既然问题分析了，那就要找出对策了！问题在哪里？想一个问题：factory的override map里需要的最根本的信息是什么？没错，那就是类型而非一个具体对象！factory只想知道也只需要知道在我的override map里面有一个条目的含义是类型A需要不需要替换成A的子类，如果有，是A1还是A2还是其它.....我不像知道A里面是什么，有什么，做什么！很显然，我们想factory的override map里面注册的东西过于饱含信息量了！叫好比说，我在你家看到你的电视机我很喜欢，我也想去买一个，我其实只想让你告诉[注册]我电视机的型号[类型]，但是你却给我这个电视机[对象]让我抱着它去商场里比对这个实物电视去买！不错，我这样是能买到这个牌子的电视机，但是这样做是不是最好的办法呢，显然不是的。但是systemverilog有一个关键字叫做type，如果我声明以下一条语句：type a_type；那么我希望能够这样来操作这个a_type变量：if（a_type == int）......if（a_type == uvm_component）.....a_type = uvm_object; .......它就是type operator，也就是type操作符！我么可以使用诸如 var type(uvm_component)my_component这样的声明语句，也可以使用如下负责的判断语句：bit [12:0] A_bus, B_bus;parameter type bus_t = type(A_bus);case (type(bus_t))type(bit[12:0]): addfixed_int #(bus_t) (A_bus,B_bus);type(real): add_float #(type(A_bus)) (A_bus,B_bus);endcase那就是我们的facotyr中的lookup函数必然会有这样的结构所表达的含义：case（type（lookup key））type（cpu_bus_driver）: .......type（tcp_pkt）：.......type（A）：...............endcase注意，我指的是用这case语句结构表达的含义的本质，而不是说用case语句来表达！所以回到那两点问题上来，这两个问题的本质就是：（1）注册对象的全局性，换句话说有唯一性的需求；（2）信息的必要性，换句话说不要信息过量；所以，有一个最普通不过的方法来做就行了，怎么做呢？（1）tcp_pkt的“张三”对象你不希望我留着专用，那好，我给tcp_pkt变身一下，再定义一个新的类型叫做tcp_pkt_wrapper，而这个tcp_pkt_wrapper类型不会被任何的用户代码所用到，那么只要我生成一个tcp_pkt_wrapper的singleton不就行了，那么即不会影响用户使用tcp_pkt[你现在可以创建一个对象叫做“张三”等其它任何名字了]，也满足唯一性的要求了！（2）那么透过tcp_pkt_wrapper能不能也把信息不要过量也一并满足了呢？这个wrapper再合适不过了，为什么？因为sv可以定义参数化的类类型，我把这些tcp_pkt，cpu_bus_driver，A等等作为模版参数传给tcp_pkt_wrapper，cpu_bus_driver_wrapper，A_wrapper.....岂不是很好！所以通过sv的type操作符，我们达到了不要信息过量的目的。整合上述两点，以tcp_pkt来说，我们只需要定义这样一个wrapper就达到目的了：class tcp_pkt_wrapper（type T=tcp_pkt）;.......实现singleton.............enclass3UVM/OVM中的factory机制上诉的描述已经基本上把一些本质的东西都提及了，太过细节的东西没有必要在分析下去了；那我们就结合UVM中的factory来看看UVM的factory是如何实现的。（1）任何user defined 的class都是从uvm_object来（2）定义公共的wrapper类，uvm_obect_wrapper，此类的存在是为了提供一个基类，以便作为factoryoverride map的lookup key和 lookup value；根本原因是因为每个参数化类都是一个不同的类型，如果没有一个公共基类，则无法用一个统一类型的句柄来作为override map的lookup key。（3）在（2）的基础上定了模版类 uvm_component_registry和uvm_object_registry，模版参数就是user defined的类。（4）每一个uvm_component_registry#（T）或uvm_object_registry#（T）都会有一个singleton用来作为user definded类型T的轻量级代理和factory的注册。（5）factory有多种override map，用来进行不同override方式的支持，如override by name、override by type、override inst、override type等。（6）当我们使用uvm_object_utils/uvm_component_utils的时候，这些宏的重要作用之一就是利用上述机制像uvm_factory中注册，定义变量type_id，定义函数get_type（）等。看到这里，我最想说的是上述这些就是我对uvm class reference文档里下面这段话的理解，原文是：”the uvm_object_wrapper provides an abstract interface for creating object and component proxies. Instances of these lightweight proxies, representing every uvm_object-based and uvm_component-based object available in the test environment, are requested with the uvm_factory. When the factory is called upon to create and object or component, it finds and delegates the request to the appropriate proxy.“ 引自：asic_wangUVM/OVM中的factory---------个人总结

虵有一篇论文，你可以看看，对提高姿势水平很有帮助
您好，以下论述希望对您有帮助： （来自于电子发烧友论坛，集成电路的发展趋势与设计挑战）伴随着 CMOS 集成电路特征尺寸越来越小，并逐渐逼近物理极限，未来集成电路技术 的发展将沿着按比例缩小(More Moore)和功能的多样化(More than Moore)的两个方向发展。其中"More Moore"即为继续按照进一步缩小的方向发展，该发展方向包括 在空间尺度上继续缩小、并提高集成度的"几何缩小"和 3 维集成、多核结构等不单纯追求 尺寸缩小的"等效缩小"两个方面，其发展总体目标都是为了使 Moore 定律得以继续。而 "More than Moore"则是追求集成系统的多样性，其总体目标是将更多的数字和非数字功能模块集成到系统中。从三个方面分析集成电路的发展趋势与设计面临的挑战:1)、单芯片向机电光异质集成、多功能一体化发展 由于工艺水平不断提升，单片集成的晶体管数目继续快速增长，单片集成度将更高，片上存储容量更大，IO 带宽更高，片上集成外设和应用型 IP 将更加丰富。集成电路上晶体管数目仍将以符合摩尔定律的大约 18 到 24 个月翻一番的指数速度增长。2002 年 Pentium M 的晶体管数量是 2.91 亿个，2007 年 Penryn 的晶体管数量己经发展到 8.2 亿个。2009 年 32 纳米的处理器问世，晶体管数将达到 19 亿个。摩尔定律会继续有效， 这将意味着晶体管密度还会迅速增加，预计到 2030 年，单片集成的晶体管数将达数千亿以 上。晶体管集成数量越多，芯片功能也将越丰富。片上存储器将更大。预计到 2020 年，嵌入式 CPU 与 DSP 片上集成的存储器容量将达50MB 以上，到 2030 年，嵌入式 CPU 与 DSP 片上集成的存储器容量将达数百 MB 以上。 通用 CPU 集成的片上存储器将更大。集成能力和功能密度进一步提高，片上外设和应用型 IP 更加丰富。通过更快(如存储 器的 DDR 接口)、更多的外部接口增加多点处理的实时性;通过更为标准、通用的接口增 加可用性，如 PCI、GPIO、MsBSP 接口;片上将实现大规模片上网络，确保多核之间高效 通讯;通过多芯片的接口(如 RapidIO、HPI、LINKs)增加多机连接的高效性;视频 IP 等。TI 的 BluetoothBRF6150 在 0.5 cm2 的芯片上全面集成了逻辑、内存、模拟、电源/稳压器管理与 RF 功能;单芯片手机解决方案更是将数字基带、内存、逻辑、RF、电源管理、模拟基 带集于一身;视频 DM642 将 10 个 IC 集于一片。随着应用的不断发展，系统需要进一步小 型化，单个 SoC 芯片集成更多器件、更多功能的趋势还将继续。微电子和机械、光器件融为一体，实现异质集成。微电子、光学和 MEMS 的交叉领域 面临未来最大的挑战和机遇。集成电台频率、光传感和信号处理器的智能微系统能够以接近实时的方式将搜集来的数据转化为行动的信息。融合、集成数模电路、光电器件、射频和功 率器件以及传感和微机械为一体的“纳光机电”集成电路芯片有望在 2020 年以前研制成功， 并在 2030年以前实现产业化，成为未来集成电路发展的新的增长点，并为信息产业的发展 带来广阔的发展空间。2)、基于纳米工艺和材料的集成电路芯片将快速发展，基于量子和光计算等非传统计 算机制的新概念集成电路芯片将获得实际应用硅器件采用下一代光刻技术，继续向微细化方向发展。随着特征尺寸的一次次缩小，目前微电子的加工工艺己达到 35nm 水平，漂移速度饱和、沟道杂质起伏等微观物理效应逐渐 显现。预计到 2020 年，工艺水平将达到 11nm，到 2030 年，工艺水平将接近 4nm，硅器件 将达到发展的极限。随着硅技术限制障碍的增大，集成电路芯片将探究采用新电子器件、新结构、新设计系 统和新制造方法，实现低成本、快速和可靠的计算、存储和通信。非传统计算(包括光计算、 生物计算、量子计算等)越来越受到学者的关注以及各国政府财政的资助。2000 年 12 月，英特尔(Intel)公司率先开发出栅极长度为 30 纳米的单晶体管;2001 年 11 月，英特尔宣布己开发出栅长仅为 15 纳米的新型晶体管，同时单个晶体管的实际工作 频率己经达到了 2.63THz。英特尔发布的 15 纳米晶体管采用“耗尽型衬底晶体管(depleted substrate transistor)”的新型结构和绝缘硅技术及“高 k 栅电介质”材料，从而使制造出的芯片 的晶体管数量可以达到现有微处理器的 25 倍，运行速度提高 10 倍。2002 年 12 月，IBM 宣 布了当前世界上最细小的晶体管加工技术。利用该技术生产出的晶体管栅长仅为 6 纳米。能 够以如此之小的尺寸制造出可实际动作的晶体管，意味着芯片的晶体管数量可以达到现有微 处理器的 100 倍以上。多栅晶体管技术是一种新型电路结构技术。传统晶体管是每个晶体管只有一个栅用来控 制电流在两个结构单元之间通过或中断，进而形成计算中所需的“0”与“1”。而多栅晶体管技 术是每个晶体管有两个或三个栅，从而提高了晶体管控制电流的能力(即计算能力)，并降 低了功耗，减少了电流间的相互干扰。目前，英特尔、AMD 和 IBM 公司己分别在实验室成 功开发出多栅晶体管。2003 年 9 月，AMD 公布了采用全耗尽型绝缘硅(Fully-depleted SOI， FDSOI)、硅错、三栅(Tri-Gate)和镇硅金属栅(NiSi)的栅长为 20 纳米的硅晶体管。IBM 则己开始致力于将双栅晶体管技术应用于芯片的生产，其硅错生产工艺等方面的进展会加快 双栅晶体管技术的产品化。英特尔于 2003 年 6 月在实验室实现了栅长为 30 纳米的三栅晶体 管，预计 在 2010 年前后实现三栅晶体管技术的产品化，并逐渐使三栅晶体管成为未来生产 出尺寸更小、处理性能更强的芯片的关键技术。3D 芯片技术是 IBM 公司、Matrix 半导体公司等研发的未来芯片技术。在一块芯片的设 计中，将晶体管封装成两层或三层以上。这种技术通过充分利用立体空间，在差不多同样大 小的芯片里，将数量成倍的晶体管封装进去，缩短了晶体管之间金属连接导线的长度，有助 于增强芯片的性能。纳米材料界己研制出许多新技术。例如双稳态单分子开关，因为许多单分子表现出良好 的双稳态特性，可作为可控开关器件，用作存储器和逻辑器件。碳纳米管也是纳米材料界最 为关注的材料之一，碳纳米管直径只有 1 纳米至 2 纳米，只是硅晶体管尺寸的 1/500。因其超常的能量及半导体性能而被认为最有可能在未来取代硅，成为生产晶体管及微处理器的主要材料。此外，碳纳米管投入运行时产生的热量和功耗都比晶体管要小得多。IBM 科学家 己经研制出世界上最小的计算机逻辑电路——一个由单分子碳组成的双晶体管元件。单电子 晶体管的用途非常广泛，可以用作超高密度存储、超高灵敏度电流计。纳米材料和纳米电子 技术在将物理器件尺寸推到量子极限的同时，也会将器件功耗降低 1-2 个数量级。随着硅光技术的成熟，光计算技术将逐步成熟，开始部分替代目前的单纯硅电计算器件。 光互连技术将更多的在未来集成电路芯片中使用。Intel 在 DARPA 资助下己经开发了能够支 持 340GHz 主频互连的光检测器，能支持超过 100 核以上的处理器实现。另外，非冯.诺依曼体系结构的计算系统，如量子计算和生物计算技术从目前来看仍然 是面向特定应用的计算模式。对于密钥管理、加密解密和海量信息筛选等特定应用，非传统 的计算模式要比传统计算系统高效数个数量级。但特定计算模式的物理器件尚难以大规模制 备，在未来 10-20 年，量子计算和生物计算会突破器件制备和实际应用障碍，在特定领域发 挥作用。工艺发展面临物理极限，新的物理机制将被集成电路芯片所采用。世界各国正在积极推 动技术创新，通过开辟新的技术途径，突破原技术的物理极限限制。超导器件、量子器件、 单电子器件和分子器件的研究，为集成电路的长远发展提供了新的技术增长点。预计到 2030 年在未来 10 到 20 年内，基于纳米管、超导、量子、分子和光计算等新物理机制的新概念集 成电路芯片将获得实际应用，主频可望提升到数百 GHz，并将对信息产业带来革命性的影 响。3)设计方法朝向系统级和纳米尺度物理级两极的发展，成为未来 10-20 年的重要方向 工艺技术的进步为系统设计者提供了更多的资源来实现更高性能的芯片，也导致了芯片 设计复杂度的大幅度增加。一支现代处理器设计队伍动辄几百到几千人，但设计能力的增长还是远远赶不上复杂度提高的步伐，验证能力更是成为芯片设计的瓶颈。 为了应对设计复杂性的挑战，基于平台的设计方法将成为主流技术，针对不同类型的应用领域，都有相应的芯片设计平台。例如，针对无线通信、媒体处理、控制、卫星平台等领 域，都会有成熟的设计平台。随着集成电路复杂度的提升和 SOC 的迅速发展，更方便的支撑 SOC 系统级设计将成为 设计技术发展的重要方向。高层抽象描述语言越来越重要。使用 C、SystemC、systemVerilog 或更高层次的语言进行系统级描述是发展的必然。未来，人们在设计片上系统时，会首先将 应用行为用软件语言描述出来，通过编译映射到硬件资源上，使硬件资源和软件描述一一对 应，从而实现用软件描述一个应用，继而映射出一个硬件结构的设计方法。片上系统调试设 计的自动化设计方法将成为重要的研究方向。未来的调试工具应当像验证工具一样融入片上 系统设计流程，并和其它工具结合起来，实现调试设计自动化。基于片上网络的片上系统调 试和 SOC 的测试技术都有待进一步研究。系统日益复杂，验证系统正确性的难度越来越大，验证技术也越来越重要，从设计后验 证演化到在设计开始就考虑可验证、易验证，以大大提高验证的效率，降低系统验证的难度。 形式验证工具将得到更大的发展和更广泛的应用。随着晶体管数目的增加以及主频的提高，功耗问题越来越突出。现代的通用处理器功耗 峰值己经高达上百瓦。例如， AMD Opteron 是 95 瓦，英特尔的安腾II己超过 100 瓦。如 果功耗超过 150 瓦，无论是芯片的封装还是主板的供电能力，都己经难以为继了。在移动计 算领域，功耗更是压倒一切的指标。因此如何降低功耗的问题己经十分迫切。虽然每个晶体 管的功耗随着特征尺寸的缩小有所减少，但晶体管数目的增加以及主频的提高使得整个芯片 的功耗大幅度增加。此外，纳米级工艺中晶体管的漏电量大幅度增加更对功耗增加起着推波 助澜的作用。在 65 纳米工艺的时候，二氧化硅绝缘层的厚度己经降低至 1.2 纳米，约为 5个硅原子层的厚度，隧道穿越引起的漏电电流急剧增加。如果沿用目前的电路和结构，到2018年左右，微处理器芯片的功耗将超过封装功耗极限(200W/mm2)的4倍(即达到1KW/mm2)。低功耗设计技术，如动态Vt、门控时钟、电源岛、动态电压与频率调整、多 Vt 晶体管、体偏置，将会得到更多的应用。可以预见，在未来的 20 年里芯片工作电压将会 持续降低，超低电压电路技术将在芯片设计中得到广泛应用。必须探索新的结构，通过包括 工艺技术、物理设计、体系结构设计、系统软件以及应用软件设计的共同努力来降低功耗。时钟系统和时钟树的设计将更加复杂。在复杂的芯片系统中，时钟功耗所占的比重超过30%。纳米级芯片上的性能参数(如介电常数、掺杂浓度等)的漂移变化会导致时钟树产生 很大偏差(ClockSkew)，需要结合不同工作环境下的晶体管性能参数变化，对时钟树的结 构进行优化调整，保证在各种工作环境下达到时钟偏差的最小化和均衡化，保证芯片性能的 可靠和稳定。此外，以异步全局信号取代时钟将成为复杂芯片设计的重要方法。全局异步、 局部同步(GALS)将成为重要的设计方法。异步时钟技术的进展取决于商用EDA 工具的 支持，支持异步设计的 EDA 工具将继续得到发展。互连问题更加重要。集成度的提高意味着线宽变窄，信号在片内传输单位距离所需的延 迟也相应增大。在现代的高性能微处理器中，信号在一个时钟周期内传输的距离只相当芯片 尺寸的十分之一左右。导致连线延迟而不是晶体管翻转速度将越来越成为影响处理器主频的 主要因素。需要通过预防(如限制最大线长)、分析及修复等手段防止线间串扰对正确性或 性能的影响，并在信号完整性分析中避免由于过于保守而牺牲性能。CMP 工艺过程中导致 的 互 连 线 金属 厚 度、 宽度 的 偏 离 程度 成 倍增 加， 由 此 引 发的 互 连线 延时 仿 真 误 差可 达15%-30%，这是导致目前 100nm 以下工艺 IC 设计失败的主要因素之一。从上世纪九十年代 开始，集成电路设计方法学发生了以器件为中心的第一代设计转移到以互连线为中心的第二 代设计的变革。可靠性问题日益突出。随着摩尔定律的延续，芯片特征尺寸进一步按比例缩小，在单芯 片上集成数十亿晶体管己成为可能。与此同时，传统的考虑故障容忍的容错方法成本较高， 且其有效性受到失效速率上升的严重影响。统计设计和分析方法将占主导地位。冗余技术与 自修复技术会在设计中得到普遍应用。必须研究使电路和系统从故障中自动恢复的新原理， 从缺陷容忍、故障容忍和差错容忍等方面研究支持芯片高可靠设计的新结构、新方法，从而 提高芯片成品率，降低成本，构造稳定可靠、性能可预测的系统。 可制造性问题将得到更多的关注。器件尺寸减小，会造成纵向电流强度增大，引起热载 流子效应，造成集成电路失效。参数变化的增加，掩膜版制作成本和数据的爆炸式增长，以 及光刻设备的限制为未来集成电路的可制造性设计带来了巨大的挑战。纳米尺度集成电路的 可制造问题突出表现为版图上规则的几何图形无法在硅片上正确地制造。设计规则检查的复 杂性将会增加，设计规则将会演化为一个二重甚至三重的系统。光刻设备的精度限制要求在 设计流程中更直接的考虑刻度增强技术(RET)，如光学邻近效应校正(OPC)和相移掩膜 (PSM)技术等保证芯片能够正确制造。在设计阶段考虑可制造性和成品率问题是解决成品 率下降的有效方法。该方法将会导致一个与最终电路实现结合更加紧密的设计流程，在 RTL 级 的 工 具 中 就 需 要 将RET和OPC的 因 素 考 虑 进 去 。 可 制 造 性 设 计 (DFM:Designfor Manufacturability)和成品率驱动的设计(DFY:Design for Yield)成为新一轮国际微电子学术和 产业竞争的新的制高点。对于目前和将来的设计而言，显式地考虑制造工艺中片内以及片间 的不确定性将势在必行，对制造过程中各种参数变化的考虑应当渗透到设计的每一个步骤。

抖动是应该呈现的数字信号沿与实际存在沿之间的差。时钟抖动可导致电和光数据流中的偏差位，引起误码。测量时钟抖动和数据信号就可揭示误码源。 测量和分析抖动可借助三种仪器：误码率(BER)测试仪，抖动分析仪和示波器(数字示波器和取样示波器)。 选用哪种仪器取决于应用，即电或光、数据通信以及位率。因为抖动是误码的主要原因，所以，首先需要测量的是BER。若网络、网络元件、子系统或IC的BER超过可接受的限制，则必须找到误差源。 大多数工程技术人员希望用仪器组合来跟踪抖动问题，先用BER测试仪、然后用抖动分析仪或示波器来隔离误差源。 BER测试仪制造商需要测量其产品的BER，以保证产品符合电信标准。当需要表征数据通信元件和系统时，BER测试对于测试高速串行数据通信设备也是主要的。 BER测试仪发送一个称之为伪随机位序列(PRBS)的预定义数据流到被测系统或器件。然后，取样接收数据流中的每一位，并对照所希望的PRBS图形检查输入位。因此，BER测试仪可以进行严格的BER测量，有些是抖动分析仪或示波器不可能做到的。 尽管BER测试仪可进行精确的BER测量，但是，对于10-12BER(每1012位为1位误差)精度的网络或器件测试需数小时。为了把测试时间从数小时缩短为几分钟，BER测试仪采用“BERT sCAN”技术，此技术用统计技术来预测BER。 可以编程BER测试仪在位时间(称之为“单位间隔”或“UI”)的任何点取样输入位。“澡盆”曲线表示BER是取样位置的函数。若BER测试仪检测位周期(0.5UI)中心的位，则抖动引起位误差的概率是小的。若BER测试仪检测位于靠近眼相交点上的位，则将增大获得抖动引起位误差的似然性。 抖动分析仪BER测试仪不能提供有关抖动持性或抖动源的足够信息。抖动分析仪(往往称之为定时时间分析仪或信号完整性分析仪)可以测量任何时钟信号的抖动，并提供故障诊断抖动的信息。抖动分析仪也用抖动特性来预测BER，其所用时间比BER测试仪小很多。 抖动测试仪对于测试高速数据通信总线(如光纤通信，SerialATA, Infiniband, Rapidio，每个通道的数据率高达3.125Gbits/s)用的器件是有用的。因为抖动分析仪在几秒内可预测BER，所以，对于生产线测试是有用的，很多ATE制造商根据用户要求，把抖动测试仪安置在测试系统中。 抖动分析仪检测信号沿并测量沿之间的时间。在采集定时数据之后，抖动分析仪执行算法，产生直方图、频率曲线、数据的其他直观图像。这些图像展示干扰信号的线索。靠执行直方图和频率曲线的计算，抖动分析仪把整个抖动分离为随机抖动和确定性抖动。 比如一种确定性抖动，它具有一个特殊源。一个干扰信号相位调制基准信号来产生测量信号中的抖动。抖动分析仪可以计算呈现在抖动中的频率(相位1-4)。一旦知道抖动频率，就可隔离抖动源并减轻抖动影响。若干扰信号的频率对应于其他时钟频率，则用增加EMI屏蔽或其他方法把源隔离就可解决问题。 混合仪器最近，某些测试设备制造商已开发出混合仪器。传统的BER测试仪只给出位误差，现在BER测试仪执行某些抖动分析，甚至有的还包含取样示波器。现在抖动分析仪也包含取样示波器，如Warecrest SIA-3000。这些取样示波器可观察眼图，但它们没有专用取样示波器那样的带宽。现在混合仪器的示波器带宽最高为6GHz。实时和等效时间取样示波器现在提供测量抖动和计算BER的软件。示波器两类示波器证明对于抖动测试和分析是有用的。为了测试通信速度达3.125Gbits/s(在铜线上传输数据，这可能是最高速度)的器件、缆线、子系统或系统，可以用实时取样示波器。它们类似于抖动分析仪，可以测量任何时钟信号的抖动。 为了测量光信号，如OC-192和10Gigabit Ethernet(9.952Gbits/s)或OC-768(39.808Gbits/s)，就需要50GHz~75GHz带宽的取样示皮器(如Agilent数字通信分析仪或Tek通信信号分析仪)。也可在电数据信号中用这些示波器。 宽带示波器对于测试当今所用的最高位率的抖动是有用的。因为它们的低取样率(150ksamples/s或更低)，所以，它们需要重复信号(如PRBS)来建立眼图，它们从眼图可建立抖动直方图。 示波器制造商在其示波器上提供抖动分析软件。 定时误差图是数据流的有效瞬时相位图。它示出抖动包含周期成分。定时误差图的快速傅里叶变换(第3个图线)定标为1MHz/div，显示抖动的频率。此频率可对应于开关电源的时钟频率或来自系统数据缆线中的交扰。 眼图交叉点的直方图显示分布有2个峰。双峰表明确定性抖动，它来自外部干扰(如开关电源)。另一处抖动——随机抖动遵从高斯分析，不能确定它们的源。

一、Mobiveil RapidIO 2.2核仿真操作说明 3 二、基于Xilinx GTX的RapidIO可综合wrapper设计说明 4三、上板调试步骤 43.1 chipsocpe观察RapidIO Outbound和 Inbound接口数据 53.2 SoC系统调试操作说明 5一、Mobiveil RapidIO 2.2仿真操作说明Mobiveil RapidIO源代码需要对其仿真环境进行设置才能完成仿真过程，原因是Mobivieil RapidIO测试激励system verilog代码只能在32位操作系统中运行，且有些操作系统缺少相应仿真运行环境库。具体仿真修改操作如下：1. 建立64位操作系统镜像，选择rhel-server-6.3-x86_64-dvd.iso为操作系统安装所用操作系统镜像。在现有的操作系统下键入以下命令进行操作系统光盘挂载：mount -o loop ~ver7/rhel-server-6.3-x86_64-dvd.iso /home/RHEL6.3/2. 在系统etc/yum/repos.d/目录下建立文件名为rhel6-3.repo的文件，文件内键入以下内容：#[rhel-source]#name=Red Hat Enterprise Linux $releasever - $basearch - Source[6.3image]Name=Red Hat Enterprise Linux 6.3Baseurl=file:///home/RHEL6.3Enable=1gpgcheck=03. 使用如下命令查看VCS和DVE软件缺少的库文件：ldd /export/COREDATA/eda_tools/synopsys/tool_collection/VCS_MX/2011.12/linux/bin/vcs1ldd /export/COREDATA/eda_tools/synopsys/tool_collection/VCS_MX/2011.12/gui/dve/linux/bin/dve.exe4. 在.bashrc中设置库搜索的路径，键入以下RapidIO，VCS，verdi库路径:exportLD_LIBRARY_PATH= $NOVAS_HOME/share/PLI/VCS/LINUX:$RAPIDIO_SO:/export/COREDATA/ eda_tools/synopsys/tool_collection/VCS_MX/2011.12/linux/lib :/export/COREDATA/eda_tools/Novas/novas-201210p3/share/FsdbWriter/LINUXAMD64:5. 搜索缺少的库，键入如下命令：Yum search “X11”。其中X11为需要安装的库名称。6. 安装缺少的库，一般32位库为有i868的标志，安装后能自动解决库的关联问题，例如键入以下命令进行库安装：Yum install libX11.i686 libX11-common.noarch libX11-devel.i6867. 部分.so库操作系统不带有该安装包，需要单独下载安装，安装路径为/home/RHEL6.3/Packages/，比如：Rpm -i /home/RHEL6.3/Packages、 安装完成后，进入rapidIO/dv/rundir文件夹下运行./RUN命令进行仿真，各个仿真功能点命令放在rapidIO/dv/config文件夹下，仿真结果。