基于扫描的DFT对芯片测试的影响

系统分类: 测试测量   |    用户分类:    |    来源: 转贴

叫板ARM、MIPS，可配置处理器走向何方？

与市场上大名鼎鼎的ARM、MIPS相比，Tensilica（泰思立达）公司还是个小角色。其位于北京南湖东园博泰国际40平米左右的办公室里，只有寥寥数人。初次见到其中国区代表李冉，显得形单影只。让人不禁联想到ARM中国区总裁谭军2002年时的样子。

　　与ARM所做的固定架构处理器不同的是，Tensilica力推 “可配置处理器”的概念。这个并不为中国大多数工程师所熟知的技术，在ARM几乎成了代名词的IP圈里，却公然称“性能更高，应用更广”。

　　然而，不可否认的是， ARM仍然占有相当市场份额，“可配置”这样一个全新的技术，究竟能否撬开中国市场？

固核也可调，可配置多余？

　　中国的IP商业模式，ARM是第一人。因此，其强大的市场份额得益于大众市场对其熟识度和由此形成的开发工程师社群，杰得微电子董事长欧阳合博士曾说过“我知道其它内核供应商的解决方案能提供比ARM更低的功耗，但对我们而言，选用ARM可更容易找到熟练软件开发工程师，从而更快地完成软件开发任务。”同时，20年前由美国斯坦福大学John Hennessy博士开发出来的MIPS架构，随着时间的推移已经发展成为面向嵌入式应用的领先高端处理器架构，并在很多领域已经成为事实标准。但因在中国没有如ARM一样庞大社群做支撑，自从2007年收购Chipidea之后，内部管理、处理器发展相对比较动荡。在2008年8月，该公司宣布将在完成压缩成本1.031亿美元后，裁员15%。 即便这样，对于市场处于襁褓期的“可配置处理器”而言，却也是不得不提的劲敌之一。

　　而且，在我们惯有的概念中，因为面市时间的缘故，各就各位，不同产品针对不同功能似乎是理所当然，固定架构刚好也满足了这种需求。提到“可配置”反而显得过于“烦琐”。

　　然而，随着20世纪70年代第一代处理器的诞生，其技术飞速发展。早期处理器因面积大、功能简单等瓶颈已被抛入历史，同时，处理器的面积越来越小，承载的东西越来越多，竞争越来越追求创新、差异化。那么，突破处理器不能修改的局限，使企业能量身设计自己产品的需求，便为“可配置处理器”带来了机会。

　　其实，可配置概念早在90年代中期就已诞生，关注的公司并不只有Tensilica一家，很多国外公司都在发展这项技术。但在实际过程中却遇到了困难，什么样的功能可以定制？针对不同应用又该如何扩展？这样一系列的问题导致当时的产品只允许用户在最简单的层次上通过选择菜单来实现，但初期的形态成功造就了一批可配置处理器公司，如Tensilica、ARC、Stretch、PACT XPP、IpFlex、Rapport、IBM Cell和Morphing Machines等。

　　同时，这样的新鲜市场，ARM当然也不会轻易放弃，也曾经尝试往可配置处理器方向发展，李冉认为“最终效果并不理想。”然而，在近日接受记者的采访中，谭军表示ARM也关注可配置处理器，但对可配置处理器的应用领域更多聚焦在移动调制解调器（Modem）中，因为移动解决方案的多波段、多模需要更多的差异化，而对于已经比较通用的控制领域，固定体系结构更符合市场情况。因此，竞争的焦点仍然集中在可配置与固定体系结构上。

　　顾名思义，可配置处理器希望能使客户根据需要定制处理器。如果想要低功耗，可以通过平衡处理器的结构，把不需要的东西都去掉；如果需要高性能，还可以根据需要增加乘法器数量。然而，ARM也是可调的，其处理器内部有很多要素：包括一套基本的指令集、很多的存储接口，这些接口有很多的参数，ARM能够改变其中有限的参数，但硬核是改不了的。

　　与Tensilica看好多核心技术不同，MIPS强调的是多执行绪优势，并认为它是未来处理器的发展趋势。但是ARM似乎也不以为然。多核心和多执行绪是不同的技术，侧重点不同。多执行绪是有意义的，但其意义只是针对一些特殊应用，例如网络。而且多执行绪带来的好处是有限的，但是带来的处理器设计复杂性、功耗面积开销，以及软件除错的复杂性增加都是非常明显的。而Tensilica则坚定地认为，多核心是其发展方向。

　　众所周知，任何一个体系架构在最初设计时是强调某一方面需求的：MIPS最初针对工作站，着重性能；ARM针对低功耗、便携产品。当然，初衷不同，架构侧重点自然也不一样。然而，产品的架构兼容又是厂商提供产品时必须考虑的问题。这个时候的兼容性就成了厂商的“包袱”，因为如果要保证兼容性，就需要在相对比较稳定的架构下进行设计，即使发现原来的架构有或多或少不便，商家也不会轻易放弃原有架构，其间牵扯到用户接受时间、软件重新编译等等。ARM在ARM9、ARM11之后，又推出了Cortex系列，便可窥见一斑。“因为ARM原来的架构不合适，这种架构没有办法保证兼容性，”李冉分析。对此，谭军也坦言，是因为原来的架构很难实现差异化，而Cortex系列则是专门为应用而定制的。可见，固定体系结构的厂商也在行动，只是方式不一样罢了。

　　因为，随着后PC时代对处理器架构的需求却是千变万化的，有人需要低功耗，有人需要高质量音频，有人就要处理基带，没有一个固定体系结构的CPU可以完全满足这些变化。“ARM虽然也做许多其他东西，但还以处理控制功能为主；DSP厂商也许强调某类应用，但终归没有办法实现差异化的目标。体系结构的变化总是根据实际需要发展而变化的。

可配置固化，妥协？扩张？

　　既然这种变化是必然的，为什么不将其变成一个根据需要定制的处理器体系结构呢？

　　正是看到了这种需求，硅谷的计算机体系结构和芯片专家克里斯?罗文（Chris　Rowen）开发出可配置处理器技术，并于1997年创建了Tensilica公司。初识Tensilica的人不会将这样一个温婉的名字和硬生生的电路扯上关系，但解释起来很简单。“‘Silica’指‘硅’，‘Ten’指‘Tensile’，即可延展，二者联合，刚好构成了Tensilica初创时的理想——设计一款灵活、可扩展的硅。

　　一个完整的可配置处理器工具集包括一个预先定义好的处理器核和一个设计工具环境两部分。其中，可扩展处理器可以让系统设计人员能够为处理器增加指令，原先的处理器体系结构设计人员从来没有考虑过或者想象过这些指令。添加高度量身定做的指令能够非常适合特殊的应用，使得可配置处理器在性能上可以同RTL设计方法相匹敌，同时得到预先经过验证的IP（知识产权）的优势。同时设计工具环境允许设计人员对基本处理器核进行大幅度修改以满足特殊应用的需求。典型的配置形式包括添加、删除和更新存储器、外部总线宽度、总线握手协议以及公共的处理器外设部件。“如果安插一个处理器用40%的工作量，软件工作量可能要占60%，”李冉介绍。

　　然而，相比SoC设计最发达的北美和日本，固核似乎正符合中国的特征，一个新兴的对立概念被市场接受终归不是一件容易的事。被客户的接纳程度、对专业技术的掌握、应用实例的支持都是个问号。可配置处理器在中国似乎没法使得其厂商赚的满钵金。于是，面对着仍然固定体系架构大施拳脚的市场，可配置处理器厂商也按捺不住了。

　　Tensilica先后于2006年、2007年推出了第一代、第二代Diamond（钻石）系列处理器。Diamond处理器的推出，更多地像是一种妥协，对固态体系结构的妥协。然而，李冉却不这么认为，他称Diamond使原来从不使用可配置处理器的厂商了解Tensilica，并使Tensilica有机会在市场上第一次提供硬核。这也成为Tensilica以自己的方式向客户推销他们熟悉的方案，从而扩大了客户群。

　　其创始人 Chris Rowen认为，“所有的客户都希望他们的产品与竞争性产品相比具有差异性，Diamond系列可以帮助他们从软件方面实现这一点，而这正是在亚太地区和中国从事SoC设计的人员所熟悉的方案。” 诚然，国外公司的设计经验一般而言要高于国内设计公司，而Tensilica已经在国外有了很多成功案例。其中包括例如思科利用200颗Tensilica 的可配置处理器内核做成的SPP路由芯片，并用于2003年就开始在其产品中销售。同时Tensilica在日本、欧洲也有很多客户。但是因为这些客户都是差异化的产品，而差异化往往意味着比较封闭、不通用。而客户想要学习Tensilica的案例，会发现找不到太多的资料做参考。而ARM是通用的，通用意味着很多人使用它做芯片，因此学习、试验都很容易。差异化的策略在国外已经取得了比较好的效果，获得了比较大公司的认可。但是还是有大部分的客户习惯传统的方式，直接使用定制好的IP，这种情况更多集中在亚太区。

　　“如果连ARM都不知道怎么用，怎么去推广可配置处理器呢？”李冉一下子道出了问题的关键。当大家对可配置的概念还有一些疑虑：包括对技术的熟悉，需要多长时间能掌握，自动化生成是否可靠或者项目时间表是否允许等，固定架构处理器依然是不二选择。

　　Diamond处理器也正瞄准了这个市场，该系列处理器涵盖了从低端CPU到高端CPU，从音频、视频到通讯基带DSP等各个方面。其中音、视频方案是钻石系列比较突出的应用，HiFi2音频处理器已经应用在英特尔针对互联网络CE终端设备的处理器CE3100(此前CE3100处理器被称为Canmore)。当然Tensilica通用CPU在知名度上还与已经在业界打拼多年的ARM、MIPS有很大差距，

　　然而，差异化一向是可配置处理器技术的卖点。正是由于差异化，早在2004年底，LG公司在短短6个月的时间里，就研发出世界首款DMB数字多媒体广播手机，即世界第一台DMB手机，正因为使用了可Tensilica的配置处理器技术。2007年，新岸线（Nufront）公司选用Tensilica的 Xtensa可配置技术，成功实现了高性能和超低功耗（第三方手机电视国标功耗测试结果为30mw）的T-MMB手机电视基带芯片，并最终在TSMC一次量产成功。新岸线是做TMMB的，此前没有做过SOC。而传统意义上做SOC首先需要找一个RISC CPU ，再放一些硬件逻辑。但他们不擅长写RTL，但算法和软件的能力很强，这就需要一款高性能，低功耗的DSP来完成这个功能，评估后，“我们用1/10的频率就可以做到同样的性能，”李冉至今提起来还不时地流露出激动的神情。因为Tensilica的体系结构可变，不但可以把冗余的配置去掉，还可以添加所需的架构特征。最后的芯片在40M的频率就可以跑下来，而功耗只有30mW，而竞争对手的芯片可能需要150M的频率。当时新岸线的后端设计，没有几家服务公司敢接，因为对时间表要求太严格了，这么短的时间要做出这个芯片是不可能的。“最后Synopsys的销售胆子比较大些，接下了这个项目，”李冉笑称。从设计到生产到量产，所有参与的人都觉得是“神话”。

　　与固定体系结构的ARM专注于便携领域、MIPS占据数字电视领域市场相比，可配置处理器的应用似乎更“上得厅堂，下得厨房”，从高端的网络处理器、手机音视频到相对比较低端的MP3、MP4等都有涉及。可配置处理器的应用并不像ARM那样集中，而是更多地应用在ARM、或者DSP不能解决的领域，高端不足矣养活一个产业，因此，低端也是其瞄准的方向。比如CISCO用200个Tensilica内核制成的网络处理器、ATI用两个处理器做的手机里的音视频、Intel下一代MID产品，Epson用处理器快速搭建的打印机芯片。其中，更多的应用集中在网络通讯、便携多媒体，同时也在不断扩展。

　　然而，正如Intel的成功源于其抓住了处理器这根救命稻草，ARM的成功更多归功于便携市场一样，某一个突出的应用领域会带领一批企业的崛起。同时如Dram之类的应用也会拖垮一批企业。可配置处理器这样分散的、无所不能的应用，在带来分散风险的好处同时，能否争得一席之地，还是让人不免有些疑问的。

　　ARM谭军更是直接指出，处理器架构的可配置，更多地是一个芯片对应一个系统厂商的产业链，如果系统厂商需要另外一个芯片厂商提供的产品，代码则需要重新改写，所以市场是可配置处理器遇到的较大问题。

　　李冉也坦陈：“可配置处理器技术所占的市场份额依然很小。如果要获得市场认可，是‘需要一些与众不同的地方的’”。

工艺与设计的鸿沟

　　单从Tensilica亚太区的销售额来看，固定体系结构的Diamond仍比较多。李冉也坦陈：“在对你的体系结构没有了解的情况下，推可配置处理器是一个很困难的事情。”相信这是大多数可配置处理器厂商在中国的境况。盘子小，自然各个分食者赚钱也相对困难。但是这些都是很动态的事情，一旦产生某个新兴应用，非可配置处理器不可，一下子扭转乾坤也不无可能。市场调研公司Semico Research曾预估，2005～2010年固定体系架构与可配置处理器的年成长率分别为10%与40%，可配置处理器增长速度远远高于固定处理器，在2010年时，使用可配置处理器核的soc器件出货量可望达10亿颗。

　　而使得李冉更津津乐道的是Tensilica可配置处理器自动产生的处理器RTL代码的功能。该功能可以和现在的SOC设计流程无缝结合，用于逻辑综合。处理器产生器还可建立与产生的处理器相匹配的系统软件。

 　　“我觉得SOC是未来发展方向，”李冉强调。SOC一般指芯片里比较高级的、复杂的芯片，将一些原来有分立器件的系统都集成起来。早在两、三年前，行业巨头Intel并不认可 SOC，认为SOC太复杂了，开发起来很困难，甚至在2006年把XScale生产线卖给Marvell。但他们后来也改变了看法。因为不管集成度、面积、功耗等，SOC都可以很好的实现，但是IC设计本身也面临着很多竞争：随着芯片规模越来越大，工艺以摩尔定律成长，设计能力的弱势就显现出来，其中有很多因素：包括设计难度越来越大、EDA工具发展远远落后于工艺的发展。

　　“就像造了一个很大的船，货物却没有那么多”李冉说。我们需要往船上放一箱箱设备，但是这个设备生产速度很慢（设计人员设计速度非常慢），对产能的应用很不充分，这是个问题。工艺很好，可以集成很多晶体管，但是用RTL、Verilog语言设计很慢。如何能够快速设计成了业内公认的难题，也有很多公司从不同角度去解决这个问题，EDA公司在努力，很多初创公司也在努力。

　　Tensilica也是其中之一。依靠自动产生的处理器RTL代码功能，可以帮助较大程度缩短设计时间。比如用硬件写一个MMP（移动多媒体中断呢），验证一般要花费三个月时间，还有很多其他模块；而用Tensilica整个出来也就用这么短的时间，一般而言可以提高4~5个月，但是产生的芯片要大一些。

　　在这个成本为先的市场，芯片面积的增大，意味着成本的增加。对此，李冉解释，由于工艺变得集成度越来越高，成本的增加就没有那么显著。如果是在一个很差的工艺，一下子多几个平方毫米的硅面积的话，成本就会很高，但是如果工艺很高，多出零点几平方毫米的硅面积，成本的增加不是那么显著。但是由于现在没有更好的方法，EDA公司也没有革命性的突破，大家也在不断探索更好、更快、有效的ESL设计方法，来解决目前遇到的设计周期长，验证困难的问题。

在铲平的世界中……

　　正如当DOS是主流平台时，名不见经传的微软能够一跃成功，很多事情的成功是需要一些历史机遇的。ARM恰恰抓住了这个机遇，但在中国的IP授权市场上，可配置处理器技术及厂商还是后来者。

　　而且ARM所提出的在一个“铲平的世界”中提供服务的思想也深入人心。首先是专利授权费用，这是客户采用ARM专利时一次性付给ARM的费用；其次是按照一定比例收取客户产品的版权费，即客户每卖出一片芯片，就收取同等比例的费用。对于资金并不是很充裕的本土企业似乎第二项政策显得尤为重要。

 　　“这也正是IP商业模式本身的意义所在，”李冉解释，因为随着半导体产业的分工越来越细，一个大的半导体公司囊括从头到尾设计的做法已越来越难。而且，单一公司的技术，因为竞争的原因，只能在企业内部使用。而IP则保证了世界的平等，不论大公司、小公司，都有机会参与竞争。

　　同时，“IP的价值在于Layout（设计），”该公司亚太区总监黄启弘在他的个人博客中写道。以帮助工程师更快开发性能更高、功耗更低的自主知识产权设计为使命的可配置处理器正在中国努力成长。但正如新生儿的成长要经历很多坎坷一样，一个新的技术最终获得大众市场的认可，并不是一件很容易的事。而最终可以检验的，唯有时间。

系统分类: 资源共享   |    用户分类:    |    来源: 转贴

可配置处理器将逐渐取代硬连线处理器

今天的便携式电子正经历着在性能增强和设备融合方面日益加剧的螺旋式变化。从前只能拍照的数码相机，现在不仅分辨率提高了四倍，而且还能摄像以及播放MP3文件。如今的手机拥有蓝牙技术及彩屏，也可以拍照并播放MP3文件。所有这类性能增强的窍门在于，必须了解消费者也期望这些新型设备的电池寿命能够得到延长。

　　有一种方法可以使设计人员既能提供附加功能，而又不影响其功率预算，即从传统的硬连线处理器转向可配置、可扩展的处理器。硬连线处理器要求设计人员使系统适应处理器的要求，结果通常形成一种不够优化的系统。而采用可配置、可扩展的处理器，诸如ARC国际公司的产品，设计人员能使处理器满足应用需求，最终获得即可提供附加特性，又能降低功耗的系统。

     图1：带与不带定制扩展与接口的ARC

     600处理器扩展指令及所测指令数比较。

     　　本文将分析可配置处理器在为设计人员减少系统功耗方面所能提供的自由度。选项一般分成三类：可配置性，或者说挑选标准处理器特性的能力；可扩展性，或者说为处理器增加独特的专用设计资源的能力；可根据具体应用调整的存储器。

　　可配置性 　　可配置性是减少传统处理器功率的最显著的方式。固定配置处理器必须包含一组可满足其90%潜在客户群要求的特性。这意味着对于除了最复杂的应用以外的所有应用，处理器都会包含一些不需要的资源。

　　与此相反，可配置处理器是从提供通用计算所需的最小功能开始，然后设计人员再从特性表中挑选所需的其他功能，这样就只增加系统必要的部分。例如，缓存大小、复杂指令、DSP资源、存储器管理单元(MMU)、定时器以及中断特性等，全都能在需要时增加，不需要时去掉。因此这种附加控制总能获得更小、更低功耗、更低成本的设计。

　　与几种运行相同标准音频编解码器(如AAC或MP3)的常见处理器架构相比，这种可配置性能够提供具有相当可观的尺寸和功率的节省。

　　所有这三种处理器都能提供完全相同的音频处理，可支持任何MPEG音频标准。不过ARC 600处理器的功耗及面积比其他两种处理器要小很多，因为它已针对音频处理应用进行了最佳配置。另一个优势在于，ARC 600处理器还具有音频扩展性能，这使其能在比硬连线处理器内核更低的频率上执行标准音频处理。

　　可扩展性 　　前面提及的音频扩展是一个理想的例子，虽不太明显，但可扩展性也许是提供功率优化系统的更为强大的工具。可扩展性使设计人员能够分析应用的软件需求，并为那些被软件运行占用大部分系统时间的部分提供硬件加速指令/特性。其结果通常是减少了整个系统的工作频率并直接降低了功耗。

　　例如，联网应用可能一秒钟需要检查50万次输入数据包的头文件，以确保数据完整性，还要将数据包分类。此时要求处理器执行循环冗余校验(CRC)计算、提取几个位字段，并将所提取的数据与一组选项进行比较。每检查一个头文件，这种处理就要用到多达60条典型的RSIC指令。

　　而采用可扩展处理器，一条定制指令就能在一个时钟周期内同时完成所有这些检查。因此，对于同样的应用，需要占用一个典型RISC引擎大约3千万个周期(50万个数据包头文件x每个头文件60个周期)，而在可扩展处理器上则仅需50万个周期。所以对于功率敏感的应用，可配置处理器系统在更低的时钟频率(29.5 MHz)上能获得同样的性能。这种频率的减少又可转变为整个系统逻辑功率的节省。

　　存储器优化

     图2：音频处理器比较显示出ARC

     600、ARM946及MIPS 4k处理器的尺寸，

     以平方毫米为单位，采用0.18微米工艺、

     包括所需存储器在内。

     　　在大多数IC的功率预算中，存储器访问占主导地位，尤其当存储器资源在片外时。鉴于此，在低功率设计中，用可配置处理器进行存储器优化受到特别关注。采用可配置、可扩展的处理器，有多种方法可减少高功率的片内和片外存储器访问。

　　最直接的例子就是削减处理器内存。系统中的每个高速缓存器都能够准确地调整到应用软件所需的大小。运行在ARC 600上的AAC音频编解码器就是一个很好的范例分析。指令缓存器的大小可由用户选择，容量在2k到32k字之间。

　　ARC还提供软件剖析工具，可使用户快速评价不同大小的高速缓存器的命中率。当在ARC 600处理器上运行AAC解码器时，ARC公司的Metaware剖析工具显示，32k字节指令缓存（I-cache）的命中率大约为99.9%。

　　在一个相同的但只带有2k字节指令缓存的ARC 600处理器上运行相同的解码器，缓存命中率可达99.1% 左右。缓存越小，每次缓存访问所需的功率就越低。不过，较小的缓存也会导致更多的高功率外部存储器访问。99.1%的缓存命中率导致的功率节省可以平衡增加的0.8%外部存储器访问产生的功率消耗，从而可为该应用提供一种功率优化解决方案。

　　定制指令被认为是提高性能的一种方法，它也是减少存储器访问的关键。一个数据包校验的例子可表明，定制指令如何减少通往指令存储器的通信量。典型的RISC处理器将不得不从指令缓存中取回大约60条指令，每次都需要消耗标记RAM和指令RAM的有效存取功率。

　　定制指令能够取代这60条指令，只需要一次RAM访问。根据代码位置及缓存大小，可能还需要访问片外RAM，而不仅是指令缓存，这进一步增加了采用硬连线处理器内核所需的功率。

　　头两个例子都集中在指令存储器的功率节省方面，而可配置处理器在数据转移方面也能提供同样的功率优势。数据缓存可以像指令缓存那样通过按钮改变容量大小，因此在应用剖析后优化缓存大小方面，两者享有同样的优势。　 （来源　电子工程专辑）

系统分类: 资源共享   |    用户分类:    |    来源: 转贴

可配置处理器应用日趋红火

系统分类: 资源共享   |    用户分类:    |    来源: 转贴

可配置处理器的承诺

阅读完EET三月刊的一篇文，‘十大热门技术点亮未来半导体发展之路’。其中，可配置处理器位居第九。回想2005年Tensilica公司初进入中国，可配置概念开始传播之路，颇感慨。愿籍此平台，与中国市场的朋友更多分享我们所致力于传播的技术。

可配置处理器的承诺

SOC设计中日益增多的规模庞大的RTL设计模块增大了众所周知的“SOC设计代沟”问题，而且这种代沟每年都在扩大。设计代沟的出现体现在芯片复杂度的爆炸性增长和设计人员设计效率的某种程度上的缓慢式增长。高性能、低功耗系统（例如使用长寿命电池的移动电话、四百万象素的数码相机、快速和廉价的彩色打印机、数字高清电视HDTV和三维3D视频游戏）的设计趋势提高了SOC设计的规模，同时也增大了SOC设计的代沟。

硬线RTL设计的芯片有许多吸引人的特点，如芯片面积小、功耗低并且吞吐量高。然而，RTL设计方法由手工设计，芯片的门数非常大。这种设计方法设计困难、验证困难且速度慢，并且对于复杂的设计问题扩展性能很差。现在可以采用可配置处理器来代替这种复杂的RTL设计方法。

何为可配置处理器？

一个完整的可配置处理器工具集包括一个预先定义好的处理器核和一个设计工具环境，这个设计工具环境允许设计人员对基本处理器核进行大幅度修改以满足特殊应用的需求。典型的配置形式包括添加、删除和更新存储器、外部总线宽度、总线握手协议以及公共的处理器外设部件。

作为可配置处理器的一个重要子集，可扩展处理器可以让系统设计人员能够为处理器增加指令，原先的处理器体系结构设计人员从来没有考虑过或者想象过这些指令。添加高度量身定做的指令能够非常适合特殊的应用，使得可配置处理器在性能上可以同RTL设计方法相匹敌，同时得到预先经过验证的IP（知识产权）的优势。可配置处理器能够以RTL代码的方式交付用户，RTL代码可以综合成现场可编程门阵列FPGA或者片上系统SOC。最好的可配置处理器还可以产生与硬件匹配的软件开发工具，软件开发工具反映了通过设计人员定义的体系结构扩展而增加的硬件指令。

一个可配置处理器能够实现与那些RTL功能紧密匹配的数据通路操作。等价的数据通路采用基本处理器定点整数流水线的方式实现，再加上执行部件和其它由芯片体系结构设计师添加的与特殊应用目标相关的功能。

例如，Tensilica的指令扩展语言TIE（一种简化的Verilog版本）就是一个设计工具，它允许系统开发人员针对不同的应用去扩展Tensilica的Xtensa 32位处理器体系结构。TIE语言以指令语义和编码的方式对数据通路功能的高级描述进行优化。与RTL相比，采用TIE语言进行描述既简单又精练，因为它略去了所有的时序逻辑描述，包括状态机描述、流水线寄存器描述以及初始化序列。这些复杂的东西实际上是由固件进行开发的。

用TIE语言描述的处理器新指令和寄存器都可以被固件程序员通过相同的编译器和汇编器所看到，且以处理器基本指令集和寄存器集作为目标。处理器数据通路中的所有操作时序均由固件进行控制，这通过处理器现有的取指令、译码和执行机制来完成的。状态机固件通常是由C或者C++这样的高级语言写成的，因为定制微处理器体系结构可以为系统提供高性能。

系统分类: 资源共享   |    用户分类:    |    来源: 转贴

可配置处理器作为RTL设计的一种选择

作为RTL设计方法的一种替代，可配置处理器和传统RTL设计方法一样采用相同的数据通路结构，如深度流水、并行执行部件、专用任务状态寄存器和与本地和全局存储器相连接的数据总线。这些扩展的处理器能够保持相同的高计算吞吐量，并和典型的RTL设计一样支持相同的数据接口。

然而，可配置处理器对数据通路的控制和RTL设计方法相比是截然不同的。对处理器数据通路而言，一个周期一个周期的控制机制体现在处理器的固件执行方式，但对硬线状态转换而言是不固定的，如图2所示。程序的控制流判决发生在分支指令；访问存储器以加载和存储操作方式实现；计算则是通用处理器和专用处理器计算操作的时序实现。

从RTL硬线状态机转移到采用固件进行控制的可配置处理器有许多重要的含义：

l        灵活性：芯片开发人员和系统架构师可以只根据固件就可以修改一个模块的功能，即使在产品交付后也可以这么做。

l        基于软件的开发：芯片开发人员能够以相对较快的速度和较低成本的软件工具就可以实现大多数芯片的特性。

l        更快、更完整的系统建模：对于一个一千万门的芯片设计，即使采用最快的基于软件的逻辑仿真器，其仿真速度也不会超过每秒几个时钟周期。相比较而言，运行在扩展处理器上的固件仿真器在执行指令集仿真时其仿真速度则可达到每秒上百万条指令。

l        控制和数据一体化：没有一个现代系统会仅仅包含硬线逻辑。总是要有软件在处理器上运行。将基于RTL功能的模块移到处理器内将剔除在控制处理和数据处理之间的人为隔阂。

l        市场化时间：将系统中关键的功能模块从RTL移到可配置处理器简化了SOC的设计时间、加速了系统建模、加快了完成整个芯片硬件的速度。基于固件的状态机可以很容易地进行修改，因为该设计方式对硬件的实现细节不是一成不变的。

l        设计效率：尤其重要的是，将基于RTL的设计转移到专用处理器，这种方式极大地提高了工程师团队的设计效率。因为这种设计方式与RTL开发方式相比既节省了人力又节省了系统验证的时间。

基于处理器的设计方法通过改变软件而不是改变硬件所带来的好处一点也不夸张。可配置处理器减少了状态机设计的风险，不再采用那种难于设计、难于验证的状态机逻辑模块设计方法，而是采用预先定义好的、验证好的的处理器核和应用程序固件。

关键：自动化硬件和软件生成

第一个可配置处理器诞生于二十世纪九十年代中期，它有一个缺点：一旦指令添加到处理器后没有一种自动化的方法来确保软件开发工具能够使用那些指令。因此，那些选择使用可配置处理器的用户就不得不用手工方法来修改软件开发工具。

早在一九九九年，Tensilica公司引入了它的第一个Xtensa处理器，该处理器有一个重要的发明，即自动化产生芯片硬件和软件。芯片设计人员可以通过基于因特网的浏览器来说明芯片的配置选项。一些新加的、由设计人员定义的指令就自动地通过Xtensa处理器产生器集成到系统中，产生了一个经过验证的硬件实现以及经过裁减的处理器芯片版本，包括了所有可能的软件开发工具。这些软件开发工具包括编译器、调试器、指令集仿真器以及更多的软件工具。软件工具能够正确地和配置选项相匹配，并且不需要额外的工作来匹配软件工具和处理器。

Tensilica公司的Xtensa处理器及其能够自动化产生硬件和软件的技术在业界引起了强烈反响。超过75多家公司正在利用Tensilica公司的Xtensa处理器设计片上系统SOC。他们其中的许多家公司还使用了多个Xtensa处理器，有些设计采用了一个处理器的多个拷贝来执行相同的任务，而其它设计则利用Xtensa处理器的不同裁减版本来执行芯片上的多种不同任务。

在软件开发时采用可配置处理器

现在让我们来看一下当前用于开发嵌入式应用的软件开发过程。图3表示一个典型的嵌入式应用软件的开发流程。设计工作不是从处理器开始，而是从算法开始。应用程序开发人员一般从高级设计工具和诸如C或者C++这样的高级语言开始，他们可能需要购买采用这些高级语言已经开发好的算法。高级编程语言和其它类型的开发包允许开发人员建立、测试和验证基本的算法思想、较小的独立算法和子算法，采用一些工具来处理这些与处理器体系结构无关的算法。

下一步，开发人员将这些用C语言写的主要算法和子算法转换成一种方便的、与处理器独立的应用程序代码。然后在PC或者工作站上运行基于C的仿真，以证明经过重新编写的代码算法能够按照理想的要求运行。在将子算法和其它应用软件模块集成到一起后，整个程序（现在采用C或者C＋＋编写）可以重新编译，作为目标处理器，得到的应用程序代码经过测试和检查。

如果开发团队非常幸运的话，经过编译的算法代码可以按照理想速度执行。然而，为了满足工程性能指标，一旦选定某个固定ISA（指令集体系结构）处理器之后，应用程序团队通常必须将代码中的关键部分转换成人工可调的汇编代码。软件开发团队一般必须将汇编代码手工映象到处理器。否则，对于指定的嵌入式应用而言，所选定的处理器可能成本太高、速度太快或者功耗太大。汇编代码开发人员必须仔细将代码中的变量与系统中现有的寄存器进行吻合比较，因为对于一个固定指令集体系结构而言，如果现有的寄存器证明不够的话，那么是没有办法为处理器增添更多的寄存器的。

系统分类: 资源共享   |    用户分类:    |    来源: 转贴

可配置处理器环境下的异构多核结构的设计与实现

关键字： 可配置处理器  异构多核  Tensilica 

近年来，高性能多处理器的设计在体系结构中开始占据越来越重要的位置。多处理器结构的出现，降低了对于指令级并行的要求，取而代之的是对于线程级并行的研究1]。对于特定应用来说，异构结构是更好的选择。异构结构处理器有着不同的结构和处理能力，可以根据应用程序本身的特点，将其不同部分分配在不同的处理器上执行，以提高执行的效率，加快执行的速度。

本文所要讨论的就是一种异构多核结构的设计及其实现。本文以Motion-JPEG的视频解码程序作为应用，设计了一个拥有3个处理器的异构多核结构。该结构是在Tensilica的XTSC[2]平台下实现的，并且移植使用了轻量级操作系统内核—Mutek[3]。在下面的章节里，本文首先提出了异构多核的详细设计方案，然后介绍了此方案在仿真平台上的具体实现步骤和结构细节，最后通过在异构多核上运行程序，将得到的数据结果进行分析和比对，验证了此结构的有效性。

2.异构设计方案

本文所设计的异构多核结构利用了可配置处理器和指令集扩展方法。首先配置需要的处理器，然后根据所要执行的多线程应用程序的特点进行有方向性的指令集扩展，从而得到预想中的异构多核结构。

该结构是一种类似于主从式的异构多核结构。下面是此结构的简单示意图。

该结构中，有一个主核(Master Core)，它包含了所有的指令集(ISA1,ISA2,ISA3...)。另外还有一些辅助核(Supporting Core)，这些处理器虽然各自包含不同的指令集。可以明显看出，指令集ISA1是大家所共有的，另外每个辅助核都还拥有属于自己的独特的指令集（ISA2，ISA3...），因此，我们把ISA1称为“基础指令集”，而ISA2，ISA3，等都称为“扩展指令集”。不同核之间指令集包含关系，可以参考下图示意：

在图【1】中并没有指定共有多少个辅助核，因为这是可变的，可以根据不同的需求来决定最终的结构。这也正是此结构的可扩展性所在。另外，每一个处理器都拥有自己cache，所有的处理器通过片上总线连接起来，并且共享一块内存[4][5]。

图1 异构多核设计方案

3.实现异构多核方案

3.1 配置生成XTSC Core

在已经实现的异构系统中，采用了如下配置的Tensilica XTSC Core：

五级流水线结构，采用Xtensa ISA LX2.1指令集，32位指令字，32个通用寄存器（32位），16k指令及数据Cache，支持计时器和中断，支持指令预取。

3.2 Mutek与Motion JPeg

3.2.1 Mutek

Mutek是被移植到了异构多核平台上的类Linux操作系统，拥有轻量级内核，仅包含必要的系统功能。由4个部分组成，而在被移植的Mutek操作系统中，最关键的是调度部分，它需要处理异构多核中程序的调度问题。

图2 异构指令集包含关系

3.2.2 Motion JPeg

Motion JPeg是视频编解码的一种协议，其解码程序的实现中包含着6个代码模块，模块之间是串行关系，代表了一帧图像的整个解码流程。下面是Motion Jpeg解码程序的基本模块图，描述了6个模块之间的关系：

由于程序在解码过程中，相邻帧之间不存在相关性，因此其复杂度相比于其他的视频编码格式（如H.264）要降低了不少，换来的是更高的并行性。

3.3 结构实现及结果分析

3.3.1异构结构确定及实现

图3 Motion Jpeg解码模块图

由图【3】可知，Motion Jpeg拥有6个模块，我们首先按照模块将其划分为6个线程，在PC机上运行并分析结果，发现IDCT和CONV部分是最耗时的，它们加起来超过了程序运行总时间的80%（见图【6】左），而其他线程则相对比较平均。基于此特点，我们选用了一个3核的异构结构，其中两个辅助核分别运行IDCT和CONV线程，而另外的4个模块合并为一个线程，放在主核上运行，结构的示意图如下。此结构与之前设计部分所提到的结构框架基本相同，只是在共享内存之上添加了一个Arbiter，避免了多核因同时访问内存而可能造成的错误。

图6 Motion Jpeg TIE指令扩展前（左图）后（右图）线程执行时间比例图。

对于此结构需要重点解释的是扩展指令集。我们采用TIE（Tensilica Instruction Extension）定义一些新的扩展指令，其中每一条扩展指令在功能上都等同于一些基础指令的合集，而其运行时间又比这些基础指令要短的多。

如图【4】所示，三个核都共享ISA1，这XTSC Core本身的基础指令集。Core #1还包含ISA2指令集，这是针对IDCT做的指令集扩展：IDCT中有大量的行列乘加运算，我们把这部分的代码提取出来，把原来循环中嵌套的多个乘加操作替换成了TIE指令，保证了每个循环只需要4个周期就可以完成，而不是原来的上百个周期。

图4 异构多核结构

类似的， Core #2包含了针对于CONV的ISA3指令集：CONV部分包含了对图像中颜色信息的处理，原来的代码中需要使用多重循环嵌套的方式来实现，我们将循环中可以并行的部分抽取出来，分别用TIE的指令实现，使得新编写的CONV线程代码中减少了循环的层数，且每次循环所消耗的时间也缩短了。

图【5】说明了Motion Jpeg中每个线程到异构系统中每个处理器上的映射关系：

图5 线程到处理利器映射关系

3.3.2 结果分析比对

我们将指令扩展后的Motion Jpeg程序在此异构结构上运行，得到了下面的各部分运行时间统计比例图。

可以明显看出在使用TIE后，处理IDCT和CONV的时间比例大幅减少。程序运行总时间也缩短为原来的40%。我们还针对执行IDCT和CONV部分的辅助核进行了数据统计：

从表1可以看出，通过指令扩展，CONV部分执行的加速比超过了3倍，而IDCT部分的加速比几乎达到了4倍。

表1 IDCT Core (Core #1)及CONV Core (Core #2)执行数据统计

为了检验我们对于Motion Jpeg程序划分的正确性，我们将其进行了另外的两种划分：a）一种将IDCT单独作为一个线程，剩下的部分全部作为一个线程（共2线程），使用Master Core + Supporting Core #1的结构；b）另一种将IDCT和CONV分别作为两个线程，把Demux、VLD和IQ/ZZ以及LIBU分别作为两个线程（共4线程），使用Master Core + Supporting Core #1 & #2 + XTSC Core的结构。各自运行改造过的Motion Jpeg，与c）前文所述结构比较，得到如下的数据（其中的门数信息由Tensilica仿真器提供）：

表2 Motion Jpeg不同线程划分的执行结果比较

从表2中可以看到，对于线程划分少的情况（a），占用的硬件资源最少，但解码率也最低；而线程划分最多的情况（b），解码率很高，同时占用硬件资源也很高；综合下来，性价比最高的正是前文所述的结构。

最后，我们还将此异构结构与一个“超级同构结构”（含有3个主核）、一个单核的Master Core以及一个未经过TIE扩展的XTSC Core进行了对比。下面是结果数据比较：

表3 不同结构运行Motion Jpeg结果对比

从表3中的数据可以看出，同构结构确实得到了很好的执行效果，但它占用的硬件资源非常庞大，几乎是异构结构的1.5倍；而单核的Master Core虽占用资源少，但其解码效果相比异构结构要差很多，单核XTSC Core的性价比虽然不错，但是解码率太低。因此从性价比和解码率方面综合权衡，异构多核结构拥有绝对的优势。

4.结论

本文描述了一种针对某一类应用的异构多核结构的设计方案，以及其在Tensilica平台上的实现。并且通过在该结构上运行指令扩展优化后的Motion Jpeg程序，将得到的数据与指令扩展前的程序以及同构多核的执行情况分别进行比较，显示出了该异构多核结构在实际应用中的高效执行能力。

陈劭 付宇卓

上海交通大学微电子学院

系统分类: 资源共享   |    用户分类:    |    来源: 转贴

基于可配置处理器的嵌入式系统ESL设计需求

关键字： 可配置处理器，嵌入式系统，ESL设计 

* 算法设计与实现

* 行为级综合

* SoC架构设计、仿真及分析

* 构建虚拟系统原型

* 功能-架构协同设计

算法设计工具允许用户对算法进行描述、仿真，并且可以生成算法实现流程的代码描述。比如Mathworks的Matlab和Simlink就是这种工具。目前大部分的工具是使用面向数据流或数据密集型算法进行建模，但是也有一些工具，如Mathworks的StateFlow，允许用户使用有限状态机对控制逻辑进行描述，并可实现自动生成C代码。

行为级综合工具是新一代基于C/C++或SystemC开发的工具，专门为满足算法和软件工程师而非硬件工程师的设计需要而开发的。由于使用C/C++，因此仿真速度比使用传统的RTL方法有了10~1000倍的显著提高。这也为系统硬件、软件和算法的联合仿真开辟了一条新道路。

用户通过SoC的架构设计工具使用传统总线，标准嵌入式处理器库(如MIPS或ARM)，以及其他的一些组件(如存储器，特殊的硬件模块和外设等)来构建SoC系统。之后便可以对整个设计进行仿真，通常使用SystemC或C/C++描述的指令集仿真器(ISS)和外围硬件模块联合仿真。这样便可分析得到一些系统级的特性，如总线负荷、竞争，内存访问，处理器负荷等。这些工具可以从CoWare，ARM，Synopsys等公司得到。

虚拟系统原型工具提供单核或多核SoC平台的仿真模型，可以以数十MHz的速度仿真实际系统。系统架构师需要在这样的平台上运行大量的测试序列，并得到系统性能分析的结果，软件开发人员也可在接近实际的仿真模型中测试他们的嵌入式软件。

但现今提供的商业ESL工具没有一种可以在更早的阶段帮助工程师决定系统的基础架构，例如决定整个系统需要使用处理器的数量和种类；需要设计专门的通信机制还是使用传统的分级总线；如何将应用程序划分成多个任务，并分配到不同的处理器上运行；如何有效的探索各种可能的设计方案等。现在的SoC架构设计工具和ISS要在体系架构确定后才有用武之地。

今天的设计要比上世纪90年代末处理器加硬件模块的结构复杂许多。从最小、最简单的手持无线设备到标准的、带有语音视频处理功能的蜂窝电话，直至非常复杂的电子设备，当今的技术已经可以把多颗处理器、多片存储器、复杂的片上通信总线网络，以及由相当可观的硬件模块组成的协同工作子系统集成到一颗SoC中。同时应用软件也愈加复杂，数百万行代码组成的系统软件已是司空见惯了。因此，使用传统方法进行体系结构设计变得日益困难，这一切都使得ESL设计方法学变得越来越必要。尤其是当可配置处理器代替传统的固定指令集处理器，可能的设计方案越来越多时更是如此。

定制指令集处理器(ASIP)

基于特定应用定制指令集处理器(ASIP)，这一概念在嵌入式系统设计中变得越来越重要。ASIP的设计方法学和开发工具也在学术界和IP设计领域被提及，并且许多商业的ESL工具已经提供了类似的处理器和协处理器综合工具。处理器的指令集大都采用一种中间形式进行描述。Tensilica提供的XPRES工具也提供这样的功能，由Tensilica定义的TIE语言描述的，并且工程师可以应用这种语言，进一步手动优化处理器的特定配置。

如果SoC的设计是要通过单颗CPU实现，也许再增加一些硬件加速器来提升性能，那么现在的这些工具和设计方法论就已经足够了。但事情并非如此简单，如今已有很多的SoC设计使用了至少两颗处理器(一颗是做控制的RISC，另一颗是进行数据处理的DSP)，并且下一代SoC设计正朝着6~10颗处理器这一方向前进。在这种情况下，目前显然缺乏设计方法论和工具来支持这样的设计。

使用可配置处理器搭建MPSoC系统

当使用多颗处理器尤其是使用可配置处理器来设计SoC时，将会遇到一些关键问题，包括：

* 一个或一组应用需要使用多少颗处理器

* 应如何配置、扩展这些处理器

* 处理器采用同构方式还是异构方式

* 处理器之间如何通信？采用标准总线，还是片上网络(NoC)，采用点到点方式，或是多种方式的组合。

* 如何选择正确的并行模式，是流水线还是多线程？

* 工程师如何从应用程序中提取可并行执行的任务？又怎样分解他们？

* 在可配置处理器，多处理器，新的通信架构以及内存选择等多种可供选择的技术下，如何能得到多种设计方案并进行对比？

* 在90nm以下的工艺流程上，如何从10个处理器的设计扩展到100个，甚至1000个处理器？

如今EDA供应商所提供的ESL工具还不足以解决这些问题。可配置处理器IP厂商的工具提供了以下流程帮助工程师进行设计：从已有的应用程序或算法的软件代码开始；分解成多个同步处理进程；将各个进程分别映射到已经优化过的处理器上，这些处理器之间有着理想的通信网络；迭代处理器定义和进程映射；分析处理器间通信网络的需求；设计并行控制和调度模块；涉及通信网络(包括存储器、总线、队列等)；分析结果并且迭代其他可能的配置；反复迭代优化直至实现满足设计需求的MPSoC系统；实现软件/硬件的具体设计。

这种自上至下、以应用需求为驱动的设计流程，在一些MPSoC子系统的应用设计中是非常适合的。尤其是当需要一个全新的功能，或者之前的系统设计方案不足以支持新标准应用程序的开发时，这种从设计需求和应用程序的特征出发进行设计的方法，往往可以得到最优的解决方案。使用这种方法定义系统的体系架构时，通过模拟、分析，并迭代得出使用处理器的种类和数量，内存的层次结构以及通信子系统等等是非常有效的。

MPSoC ESL解决方案的功能

MPSoC ESL设计方法需要提供很多功能，这些需要包含在集成开发环境(IDE)中，如系统建模，程序映射，各种设计方案对比，以及对可配置处理器的配置修改。

IDE是最引人注目的部分。Eclipsez作为一个开源软件，对扩展已有的软件工具、器件、调试软件都有很好的支持，而这些功能可以使得MPSoC ESL设计在更抽象的层次上进行。比如可以在Eclipse中加入处理器创建、扩展的用户配置界面，将用户的配置转化成基于某种特定语言描述的指令扩展，之后交给外部的特定编译器进行编译。因为这一扩展被编译成RTL级的描述，在这种意义下可以使用IDE定制和实现一个软硬件系统。

IDE软件提供的项目编辑功能可以支持设计输入、修改、映射到特定处理器等操作。同时还要能够配置处理器、内存、通信接口、总线以及外设等设备，用以搭建一个完整的系统。IDE还需要支持系统级仿真，可以装载处理器的ISS，能够装载整个系统的仿真模型，静态或动态的追踪系统级上发生的事件，能统计处理器的执行状况并记录数据，并通过图形界面向用户显示。并需提供分析工具，使得用户可以方便得到传输延迟、资源竞争、处理器等待、内存的使用状况，以及处理器数据读取的平衡状况等系统级信息。

IP的参数(meta-data)和一些临时信息需要使用标准的格式来存储。近来XML格式被广泛的使用到工具中，如Mentor Graphics的Platform Express等等。基于XML格式排版的文件很容易被扩展，解析和生成，所以是一种描述存储系统架构和参数的极具吸引力的方法。

有了系统架构的信息，也有了标准格式的ISS模型，便可以生成系统仿真模型用于系统测试。许多已有的ISS支持在SystemC环境中运行，这样便可以和总线模型、内存模型、硬件模块模型、外设模型等其他系统模型在事务级上进行互联、仿真。TLM在ESL方法论中是一个非常重要的概念，但到目前为止还没有为TLM上的互操作定义标准。由于没有一个可用的OSCI TLM标准，考虑到OSCI工作的不透明性质和其缺乏一个发展的路线图，ESL世界里的系统仿真必须继续依赖于IP提供商提供的可供互联的适配器和用户自己对“事务”这一概念的理解。

快速功能仿真，有时也被称为“虚拟系统原型”，是对周期精确型的TLM模型的重要补充。周期精确型的TLM模型允许对系统运行时的细节进行分析，每秒钟只能运行数千个周期或再多一些，而快速功能仿真则可以数百万个周期每秒的速度运行，这对软件的开发有着特别的意义。

可配置处理器是高性能MPSoC系统的核心，通过扩展指令的自动生成技术使得在设计的最后阶段仍可修改系统配置。通过在设计的早期阶段自动生成的配置和扩展ISA，可将最初的任务映射到这个处理器上，当处理器发生变化，任务需要重新被映射时，该过程可以快速反复迭代进行。通过手动对设计进行改善，最终可以通过提高进程效率，从而降低处理器频率，达到设计目标。自动生成的软件工具链(包括编译器、ISS、调试器和IDE扩展功能模块)允许对处理器的每一个修改都可以反映到整体系统中。

本文小结

复杂的多颗可配置处理器组成的嵌入式系统设计对现今的ESL工具提出了更高的要求，这些需求似乎更像是应该由IP供应商来提供，而不是EDA工具厂商。虽然仍可以使用通用的ESL工具，但具体的流程和特定工具都将是与所使用的IP直接相关的。

作者：Grant Martin

Tensilica公司

系统分类: 资源共享   |    用户分类:    |    来源: 转贴

Linux下用GDB调试程序

转自：http://www.bloghome.cn/posts/46382

说明：
    习惯了windows下的编程，也习惯了windows下的调试，而最近在为suse Linux下的一个程序新增一个功能后发现程序运行有问题，于是不得不转而去研究一下Linux下的调试技术。刚开始接触的时候感觉想到别扭，就那么一个命令行，太不直观，而且也不熟悉GDB该怎么用。后来不得不找到一篇Linux调试方面的文章看，对照着练习了一下，慢慢有些上手了，而且发现Linux下的调试是另外一番新的体验，感觉虽然不如windows下的直观，但是GNU使用熟练后一点都不比VC麻烦，虽然作为视窗软件的VC有着视窗天然的直观优势，但命令行下的GNU也有命令行自身的优势：操作快捷，可以用脚本实现一系列动作，可以提高调试效率。下面就把这篇很不错的文章转过来，以便让更多的人看到。


正文：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

GDB是一个强大的命令行调试工具。大家知道命令行的强大就是在于，其可以形成执行序列，形成脚本。UNIX下的软件全是命令行的，这给程序开发提代供了极大的便利，命令行软件的优势在于，它们可以非常容易的集成在一起，使用几个简单的已有工具的命令，就可以做出一个非常强大的功能。

于是UNIX下的软件比Windows下的软件更能有机地结合，各自发挥各自的长处，组合成更为强劲的功能。而Windows下的图形软件基本上是各自为营，互相不能调用，很不利于各种软件的相互集成。在这里并不是要和Windows做个什么比较，所谓“寸有所长，尺有所短”，图形化工具还是有不如命令行的地方。

用GDB调试程序

GDB概述
————

GDB是GNU开源组织发布的一个强大的UNIX下的程序调试工具。或许，各位比较喜欢那种图形界面方式的，像VC、BCB等IDE的调试，但如果你是在UNIX平台下做软件，你会发现GDB这个调试工具有比VC、BCB的图形化调试器更强大的功能。所谓“寸有所长，尺有所短”就是这个道理。

一般来说，GDB主要帮忙你完成下面四个方面的功能：

1、启动你的程序，可以按照你的自定义的要求随心所欲的运行程序。
2、可让被调试的程序在你所指定的调置的断点处停住。（断点可以是条件表达式）
3、当程序被停住时，可以检查此时你的程序中所发生的事。
4、动态的改变你程序的执行环境。

从上面看来，GDB和一般的调试工具没有什么两样，基本上也是完成这些功能，不过在细节上，你会发现GDB这个调试工具的强大，大家可能比较习惯了图形化的调试工具，但有时候，命令行的调试工具却有着图形化工具所不能完成的功能。让我们一一看来。

一个调试示例
——————

源程序：tst.c

1 #include
2
3 int func(int n)
4 {
5 int sum="0",i;
6 for(i=0; i
7 {
8 sum+=i;
9 }
10 return sum;
11 }
12
13
14 main()
15 {
16 int i;
17 long result = 0;
18 for(i=1; i<=100; i++)
19 {
20 result += i;
21 }
22
23 printf("result[1-100] = %d \n", result );
24 printf("result[1-250] = %d \n", func(250) );
25 }

编译生成执行文件：（Linux下）
hchen/test> cc -g tst.c -o tst

使用GDB调试：

hchen/test> gdb tst <---------- 启动GDB
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-suse-linux"...
(gdb) l <-------------------- l命令相当于list，从第一行开始例出原码。
1 #include
2
3 int func(int n)
4 {
5 int sum="0",i;
6 for(i=0; i
7 {
8 sum+=i;
9 }
10 return sum;
(gdb) <-------------------- 直接回车表示，重复上一次命令
11 }
12
13
14 main()
15 {
16 int i;
17 long result = 0;
18 for(i=1; i<=100; i++)
19 {
20 result += i;
(gdb) break 16 <-------------------- 设置断点，在源程序第16行处。
Breakpoint 1 at 0x8048496: file tst.c, line 16.
(gdb) break func <-------------------- 设置断点，在函数func()入口处。
Breakpoint 2 at 0x8048456: file tst.c, line 5.
(gdb) info break <-------------------- 查看断点信息。
Num Type Disp Enb Address What
1 breakpoint keep y 0x08048496 in main at tst.c:16
2 breakpoint keep y 0x08048456 in func at tst.c:5
(gdb) r <--------------------- 运行程序，run命令简写
Starting program: /home/hchen/test/tst

Breakpoint 1, main () at tst.c:17 <---------- 在断点处停住。
17 long result = 0;
(gdb) n <--------------------- 单条语句执行，next命令简写。
18 for(i=1; i<=100; i++)
(gdb) n
20 result += i;
(gdb) n
18 for(i=1; i<=100; i++)
(gdb) n
20 result += i;
(gdb) c <--------------------- 继续运行程序，continue命令简写。
Continuing.
result[1-100] = 5050 <----------程序输出。

Breakpoint 2, func (n=250) at tst.c:5
5 int sum="0",i;
(gdb) n
6 for(i=1; i<=n; i++)
(gdb) p i <--------------------- 打印变量i的值，print命令简写。
$1 = 134513808
(gdb) n
8 sum+=i;
(gdb) n
6 for(i=1; i<=n; i++)
(gdb) p sum
$2 = 1
(gdb) n
8 sum+=i;
(gdb) p i
$3 = 2
(gdb) n
6 for(i=1; i<=n; i++)
(gdb) p sum
$4 = 3
(gdb) bt <--------------------- 查看函数堆栈。
#0 func (n=250) at tst.c:5
#1 0x080484e4 in main () at tst.c:24
#2 0x400409ed in __libc_start_main () from /lib/libc.so.6
(gdb) finish <--------------------- 退出函数。
Run till exit from #0 func (n=250) at tst.c:5
0x080484e4 in main () at tst.c:24
24 printf("result[1-250] = %d \n", func(250) );
Value returned is $6 = 31375
(gdb) c <--------------------- 继续运行。
Continuing.
result[1-250] = 31375 <----------程序输出。

Program exited with code 027. <--------程序退出，调试结束。
(gdb) q <--------------------- 退出gdb。
hchen/test>

好了，有了以上的感性认识，还是让我们来系统地认识一下gdb吧。

使用GDB
————

一般来说GDB主要调试的是C/C++的程序。要调试C/C++的程序，首先在编译时，我们必须要把调试信息加到可执行文件中。使用编译器（cc/gcc/g++）的 -g 参数可以做到这一点。如：

> cc -g hello.c -o hello
> g++ -g hello.cpp -o hello

如果没有-g，你将看不见程序的函数名、变量名，所代替的全是运行时的内存地址。当你用-g把调试信息加入之后，并成功编译目标代码以后，让我们来看看如何用gdb来调试他。

启动GDB的方法有以下几种：

1、gdb
program也就是你的执行文件，一般在当然目录下。

2、gdb core
用gdb同时调试一个运行程序和core文件，core是程序非法执行后core dump后产生的文件。

3、gdb
如果你的程序是一个服务程序，那么你可以指定这个服务程序运行时的进程ID。gdb会自动attach上去，并调试他。program应该在PATH环境变量中搜索得到。

GDB启动时，可以加上一些GDB的启动开关，详细的开关可以用gdb -help查看。我在下面只例举一些比较常用的参数：

-symbols
-s
从指定文件中读取符号表。

-se file
从指定文件中读取符号表信息，并把他用在可执行文件中。

-core
-c
调试时core dump的core文件。

-directory
-d
加入一个源文件的搜索路径。默认搜索路径是环境变量中PATH所定义的路径。

GDB的命令概貌
———————

启动gdb后，就你被带入gdb的调试环境中，就可以使用gdb的命令开始调试程序了，gdb的命令可以使用help命令来查看，如下所示：

/home/hchen> gdb
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-suse-linux".
(gdb) help
List of classes of commands:

aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
data -- Examining data
files -- Specifying and examining files
internals -- Maintenance commands
obscure -- Obscure features
running -- Running the program
stack -- Examining the stack
status -- Status inquiries
support -- Support facilities
tracepoints -- Tracing of program execution without stopping the program
user-defined -- User-defined commands

Type "help" followed by a class name for a list of commands in that class.
Type "help" followed by command name for full documentation.
Command name abbreviations are allowed if unambiguous.
(gdb)

gdb的命令很多，gdb把之分成许多个种类。help命令只是例出gdb的命令种类，如果要看种类中的命令，可以使用help 命令，如：help breakpoints，查看设置断点的所有命令。也可以直接help 来查看命令的帮助。

gdb中，输入命令时，可以不用打全命令，只用打命令的前几个字符就可以了，当然，命令的前几个字符应该要标志着一个唯一的命令，在Linux下，你可以敲击两次TAB键来补齐命令的全称，如果有重复的，那么gdb会把其例出来。

示例一：在进入函数func时，设置一个断点。可以敲入break func，或是直接就是b func
(gdb) b func
Breakpoint 1 at 0x8048458: file hello.c, line 10.

示例二：敲入b按两次TAB键，你会看到所有b打头的命令：
(gdb) b
backtrace break bt
(gdb)

示例三：只记得函数的前缀，可以这样：
(gdb) b make_ <按TAB键>
（再按下一次TAB键，你会看到:）
make_a_section_from_file make_environ
make_abs_section make_function_type
make_blockvector make_pointer_type
make_cleanup make_reference_type
make_command make_symbol_completion_list
(gdb) b make_
GDB把所有make开头的函数全部例出来给你查看。

示例四：调试C++的程序时，有可以函数名一样。如：
(gdb) b 'bubble( M-?
bubble(double,double) bubble(int,int)
(gdb) b 'bubble(
你可以查看到C++中的所有的重载函数及参数。（注：M-?和“按两次TAB键”是一个意思）

要退出gdb时，只用发quit或命令简称q就行了。

GDB中运行UNIX的shell程序
————————————

在gdb环境中，你可以执行UNIX的shell的命令，使用gdb的shell命令来完成：

shell
调用UNIX的shell来执行，环境变量SHELL中定义的UNIX的shell将会被用来执行，如果SHELL没有定义，那就使用UNIX的标准shell：/bin/sh。（在Windows中使用Command.com或cmd.exe）

还有一个gdb命令是make：
make
可以在gdb中执行make命令来重新build自己的程序。这个命令等价于“shell make ”。

在GDB中运行程序
————————

当以gdb 方式启动gdb后，gdb会在PATH路径和当前目录中搜索的源文件。如要确认gdb是否读到源文件，可使用l或list命令，看看gdb是否能列出源代码。

在gdb中，运行程序使用r或是run命令。程序的运行，你有可能需要设置下面四方面的事。

1、程序运行参数。
set args 可指定运行时参数。（如：set args 10 20 30 40 50）
show args 命令可以查看设置好的运行参数。

2、运行环境。
path

3、工作目录。
cd

4、程序的输入输出。
info terminal 显示你程序用到的终端的模式。
使用重定向控制程序输出。如：run > outfile
tty命令可以指写输入输出的终端设备。如：tty /dev/ttyb

调试已运行的程序
————————

两种方法：
1、在UNIX下用ps查看正在运行的程序的PID（进程ID），然后用gdb PID格式挂接正在运行的程序。
2、先用gdb 关联上源代码，并进行gdb，在gdb中用attach命令来挂接进程的PID。并用detach来取消挂接的进程。

暂停 / 恢复程序运行
—————————

调试程序中，暂停程序运行是必须的，GDB可以方便地暂停程序的运行。你可以设置程序的在哪行停住，在什么条件下停住，在收到什么信号时停往等等。以便于你查看运行时的变量，以及运行时的流程。

当进程被gdb停住时，你可以使用info program 来查看程序的是否在运行，进程号，被暂停的原因。

在gdb中，我们可以有以下几种暂停方式：断点（BreakPoint）、观察点（WatchPoint）、捕捉点（CatchPoint）、信号（Signals）、线程停止（Thread Stops）。如果要恢复程序运行，可以使用c或是continue命令。

一、设置断点（BreakPoint）

我们用break命令来设置断点。正面有几点设置断点的方法：

break
在进入指定函数时停住。C++中可以使用class::function或function(type,type)格式来指定函数名。

break
在指定行号停住。

break +offset
break -offset
在当前行号的前面或后面的offset行停住。offiset为自然数。

break filename:linenum
在源文件filename的linenum行处停住。

break filename:function
在源文件filename的function函数的入口处停住。

break *address
在程序运行的内存地址处停住。

break
break命令没有参数时，表示在下一条指令处停住。

break ... if
...可以是上述的参数，condition表示条件，在条件成立时停住。比如在循环境体中，可以设置break if i="100"，表示当i为100时停住程序。

查看断点时，可使用info命令，如下所示：（注：n表示断点号）
info breakpoints [n]
info break [n]

二、设置观察点（WatchPoint）

观察点一般来观察某个表达式（变量也是一种表达式）的值是否有变化了，如果有变化，马上停住程序。我们有下面的几种方法来设置观察点：

watch
为表达式（变量）expr设置一个观察点。一量表达式值有变化时，马上停住程序。

rwatch
当表达式（变量）expr被读时，停住程序。

awatch
当表达式（变量）的值被读或被写时，停住程序。

info watchpoints
列出当前所设置了的所有观察点。

三、设置捕捉点（CatchPoint）

你可设置捕捉点来补捉程序运行时的一些事件。如：载入共享库（动态链接库）或是C++的异常。设置捕捉点的格式为：

catch
当event发生时，停住程序。event可以是下面的内容：
1、throw 一个C++抛出的异常。（throw为关键字）
2、catch 一个C++捕捉到的异常。（catch为关键字）
3、exec 调用系统调用exec时。（exec为关键字，目前此功能只在HP-UX下有用）
4、fork 调用系统调用fork时。（fork为关键字，目前此功能只在HP-UX下有用）
5、vfork 调用系统调用vfork时。（vfork为关键字，目前此功能只在HP-UX下有用）
6、load 或 load 载入共享库（动态链接库）时。（load为关键字，目前此功能只在HP-UX下有用）
7、unload 或 unload 卸载共享库（动态链接库）时。（unload为关键字，目前此功能只在HP-UX下有用）

tcatch
只设置一次捕捉点，当程序停住以后，应点被自动删除。

四、维护停止点

上面说了如何设置程序的停止点，GDB中的停止点也就是上述的三类。在GDB中，如果你觉得已定义好的停止点没有用了，你可以使用delete、clear、disable、enable这几个命令来进行维护。

clear
清除所有的已定义的停止点。

clear
clear
清除所有设置在函数上的停止点。

clear
clear
清除所有设置在指定行上的停止点。

delete [breakpoints] [range...]
删除指定的断点，breakpoints为断点号。如果不指定断点号，则表示删除所有的断点。range 表示断点号的范围（如：3-7）。其简写命令为d。

比删除更好的一种方法是disable停止点，disable了的停止点，GDB不会删除，当你还需要时，enable即可，就好像回收站一样。

disable [breakpoints] [range...]
disable所指定的停止点，breakpoints为停止点号。如果什么都不指定，表示disable所有的停止点。简写命令是dis.

enable [breakpoints] [range...]
enable所指定的停止点，breakpoints为停止点号。

enable [breakpoints] once range...
enable所指定的停止点一次，当程序停止后，该停止点马上被GDB自动disable。

enable [breakpoints] delete range...
enable所指定的停止点一次，当程序停止后，该停止点马上被GDB自动删除。

五、停止条件维护

前面在说到设置断点时，我们提到过可以设置一个条件，当条件成立时，程序自动停止，这是一个非常强大的功能，这里，我想专门说说这个条件的相关维护命令。一般来说，为断点设置一个条件，我们使用if关键词，后面跟其断点条件。并且，条件设置好后，我们可以用condition命令来修改断点的条件。（只有break和watch命令支持if，catch目前暂不支持if）

condition
修改断点号为bnum的停止条件为expression。

condition
清除断点号为bnum的停止条件。

还有一个比较特殊的维护命令ignore，你可以指定程序运行时，忽略停止条件几次。

ignore
表示忽略断点号为bnum的停止条件count次。

六、为停止点设定运行命令

我们可以使用GDB提供的command命令来设置停止点的运行命令。也就是说，当运行的程序在被停止住时，我们可以让其自动运行一些别的命令，这很有利行自动化调试。对基于GDB的自动化调试是一个强大的支持。

commands [bnum]
... command-list ...
end

为断点号bnum指写一个命令列表。当程序被该断点停住时，gdb会依次运行命令列表中的命令。

例如：

break foo if x>0
commands
printf "x is %d\n",x
continue
end
断点设置在函数foo中，断点条件是x>0，如果程序被断住后，也就是，一旦x的值在foo函数中大于0，GDB会自动打印出x的值，并继续运行程序。

如果你要清除断点上的命令序列，那么只要简单的执行一下commands命令，并直接在打个end就行了。

七、断点菜单

在C++中，可能会重复出现同一个名字的函数若干次（函数重载），在这种情况下，break 不能告诉GDB要停在哪个函数的入口。当然，你可以使用break 也就是把函数的参数类型告诉GDB，以指定一个函数。否则的话，GDB会给你列出一个断点菜单供你选择你所需要的断点。你只要输入你菜单列表中的编号就可以了。如：

(gdb) b String::after
[0] cancel
[1] all
[2] file:String.cc; line number:867
[3] file:String.cc; line number:860
[4] file:String.cc; line number:875
[5] file:String.cc; line number:853
[6] file:String.cc; line number:846
[7] file:String.cc; line number:735
> 2 4 6
Breakpoint 1 at 0xb26c: file String.cc, line 867.
Breakpoint 2 at 0xb344: file String.cc, line 875.
Breakpoint 3 at 0xafcc: file String.cc, line 846.
Multiple breakpoints were set.
Use the "delete" command to delete unwanted
breakpoints.
(gdb)

可见，GDB列出了所有after的重载函数，你可以选一下列表编号就行了。0表示放弃设置断点，1表示所有函数都设置断点。

八、恢复程序运行和单步调试

当程序被停住了，你可以用continue命令恢复程序的运行直到程序结束，或下一个断点到来。也可以使用step或next命令单步跟踪程序。

continue [ignore-count]
c [ignore-count]
fg [ignore-count]
恢复程序运行，直到程序结束，或是下一个断点到来。ignore-count表示忽略其后的断点次数。continue，c，fg三个命令都是一样的意思。

step
单步跟踪，如果有函数调用，他会进入该函数。进入函数的前提是，此函数被编译有debug信息。很像VC等工具中的step in。后面可以加count也可以不加，不加表示一条条地执行，加表示执行后面的count条指令，然后再停住。

next
同样单步跟踪，如果有函数调用，他不会进入该函数。很像VC等工具中的step over。后面可以加count也可以不加，不加表示一条条地执行，加表示执行后面的count条指令，然后再停住。

set step-mode
set step-mode on
打开step-mode模式，于是，在进行单步跟踪时，程序不会因为没有debug信息而不停住。这个参数有很利于查看机器码。

set step-mod off
关闭step-mode模式。

finish
运行程序，直到当前函数完成返回。并打印函数返回时的堆栈地址和返回值及参数值等信息。

until 或 u
当你厌倦了在一个循环体内单步跟踪时，这个命令可以运行程序直到退出循环体。

stepi 或 si
nexti 或 ni
单步跟踪一条机器指令！一条程序代码有可能由数条机器指令完成，stepi和nexti可以单步执行机器指令。与之一样有相同功能的命令是 “display/i $pc” ，当运行完这个命令后，单步跟踪会在打出程序代码的同时打出机器指令（也就是汇编代码）

九、信号（Signals）

信号是一种软中断，是一种处理异步事件的方法。一般来说，操作系统都支持许多信号。尤其是UNIX，比较重要应用程序一般都会处理信号。UNIX定义了许多信号，比如SIGINT表示中断字符信号，也就是Ctrl+C的信号，SIGBUS表示硬件故障的信号；SIGCHLD表示子进程状态改变信号； SIGKILL表示终止程序运行的信号，等等。信号量编程是UNIX下非常重要的一种技术。

GDB有能力在你调试程序的时候处理任何一种信号，你可以告诉GDB需要处理哪一种信号。你可以要求GDB收到你所指定的信号时，马上停住正在运行的程序，以供你进行调试。你可以用GDB的handle命令来完成这一功能。

handle
在GDB中定义一个信号处理。信号可以以SIG开头或不以SIG开头，可以用定义一个要处理信号的范围（如：SIGIO-SIGKILL，表示处理从SIGIO信号到SIGKILL的信号，其中包括SIGIO，SIGIOT，SIGKILL三个信号），也可以使用关键字all来标明要处理所有的信号。一旦被调试的程序接收到信号，运行程序马上会被GDB停住，以供调试。其可以是以下几种关键字的一个或多个。

nostop
当被调试的程序收到信号时，GDB不会停住程序的运行，但会打出消息告诉你收到这种信号。
stop
当被调试的程序收到信号时，GDB会停住你的程序。
print
当被调试的程序收到信号时，GDB会显示出一条信息。
noprint
当被调试的程序收到信号时，GDB不会告诉你收到信号的信息。
pass
noignore
当被调试的程序收到信号时，GDB不处理信号。这表示，GDB会把这个信号交给被调试程序会处理。
nopass
ignore
当被调试的程序收到信号时，GDB不会让被调试程序来处理这个信号。

info signals
info handle
查看有哪些信号在被GDB检测中。

十、线程（Thread Stops）

如果你程序是多线程的话，你可以定义你的断点是否在所有的线程上，或是在某个特定的线程。GDB很容易帮你完成这一工作。

break thread
break thread if ...
linespec指定了断点设置在的源程序的行号。threadno指定了线程的ID，注意，这个ID是GDB分配的，你可以通过“info threads”命令来查看正在运行程序中的线程信息。如果你不指定thread 则表示你的断点设在所有线程上面。你还可以为某线程指定断点条件。如：

(gdb) break frik.c:13 thread 28 if bartab > lim

当你的程序被GDB停住时，所有的运行线程都会被停住。这方便你你查看运行程序的总体情况。而在你恢复程序运行时，所有的线程也会被恢复运行。那怕是主进程在被单步调试时。

查看栈信息
—————

当程序被停住了，你需要做的第一件事就是查看程序是在哪里停住的。当你的程序调用了一个函数，函数的地址，函数参数，函数内的局部变量都会被压入“栈”（Stack）中。你可以用GDB命令来查看当前的栈中的信息。

下面是一些查看函数调用栈信息的GDB命令：

backtrace
bt
打印当前的函数调用栈的所有信息。如：

(gdb) bt
#0 func (n=250) at tst.c:6
#1 0x08048524 in main (argc=1, argv="0xbffff674") at tst.c:30
#2 0x400409ed in __libc_start_main () from /lib/libc.so.6

从上可以看出函数的调用栈信息：__libc_start_main --> main() --> func()


backtrace
bt
n是一个正整数，表示只打印栈顶上n层的栈信息。

backtrace <-n>
bt <-n>
-n表一个负整数，表示只打印栈底下n层的栈信息。

如果你要查看某一层的信息，你需要在切换当前的栈，一般来说，程序停止时，最顶层的栈就是当前栈，如果你要查看栈下面层的详细信息，首先要做的是切换当前栈。

frame
f
n是一个从0开始的整数，是栈中的层编号。比如：frame 0，表示栈顶，frame 1，表示栈的第二层。

up
表示向栈的上面移动n层，可以不打n，表示向上移动一层。

down
表示向栈的下面移动n层，可以不打n，表示向下移动一层。

上面的命令，都会打印出移动到的栈层的信息。如果你不想让其打出信息。你可以使用这三个命令：

select-frame 对应于 frame 命令。
up-silently 对应于 up 命令。
down-silently 对应于 down 命令。

查看当前栈层的信息，你可以用以下GDB命令：

frame 或 f
会打印出这些信息：栈的层编号，当前的函数名，函数参数值，函数所在文件及行号，函数执行到的语句。

info frame
info f
这个命令会打印出更为详细的当前栈层的信息，只不过，大多数都是运行时的内内地址。比如：函数地址，调用函数的地址，被调用函数的地址，目前的函数是由什么样的程序语言写成的、函数参数地址及值、局部变量的地址等等。如：
(gdb) info f
Stack level 0, frame at 0xbffff5d4:
eip = 0x804845d in func (tst.c:6); saved eip 0x8048524
called by frame at 0xbffff60c
source language c.
Arglist at 0xbffff5d4, args: n="250"
Locals at 0xbffff5d4, Previous frame's sp is 0x0
Saved registers:
ebp at 0xbffff5d4, eip at 0xbffff5d8

info args
打印出当前函数的参数名及其值。

info locals
打印出当前函数中所有局部变量及其值。

info catch
打印出当前的函数中的异常处理信息。

查看源程序
—————

一、显示源代码

GDB 可以打印出所调试程序的源代码，当然，在程序编译时一定要加上-g的参数，把源程序信息编译到执行文件中。不然就看不到源程序了。当程序停下来以后， GDB会报告程序停在了那个文件的第几行上。你可以用list命令来打印程序的源代码。还是来看一看查看源代码的GDB命令吧。

list
显示程序第linenum行的周围的源程序。

list
显示函数名为function的函数的源程序。

list
显示当前行后面的源程序。

list -
显示当前行前面的源程序。

一般是打印当前行的上5行和下5行，如果显示函数是是上2行下8行，默认是10行，当然，你也可以定制显示的范围，使用下面命令可以设置一次显示源程序的行数。

set listsize
设置一次显示源代码的行数。

show listsize
查看当前listsize的设置。

list命令还有下面的用法：

list ,
显示从first行到last行之间的源代码。

list ,
显示从当前行到last行之间的源代码。

list +
往后显示源代码。

一般来说在list后面可以跟以下这们的参数：

行号。
<+offset> 当前行号的正偏移量。
<-offset> 当前行号的负偏移量。
哪个文件的哪一行。
函数名。
哪个文件中的哪个函数。
<*address> 程序运行时的语句在内存中的地址。

二、搜索源代码

不仅如此，GDB还提供了源代码搜索的命令：

forward-search
search
向前面搜索。

reverse-search
全部搜索。

其中，就是正则表达式，也主一个字符串的匹配模式，关于正则表达式，我就不在这里讲了，还请各位查看相关资料。

三、指定源文件的路径

某些时候，用-g编译过后的执行程序中只是包括了源文件的名字，没有路径名。GDB提供了可以让你指定源文件的路径的命令，以便GDB进行搜索。

directory
dir
加一个源文件路径到当前路径的前面。如果你要指定多个路径，UNIX下你可以使用“:”，Windows下你可以使用“;”。
directory
清除所有的自定义的源文件搜索路径信息。

show directories
显示定义了的源文件搜索路径。

四、源代码的内存

你可以使用info line命令来查看源代码在内存中的地址。info line后面可以跟“行号”，“函数名”，“文件名:行号”，“文件名:函数名”，这个命令会打印出所指定的源码在运行时的内存地址，如：

(gdb) info line tst.c:func
Line 5 of "tst.c" starts at address 0x8048456 and ends at 0x804845d .

还有一个命令（disassemble）你可以查看源程序的当前执行时的机器码，这个命令会把目前内存中的指令dump出来。如下面的示例表示查看函数func的汇编代码。

(gdb) disassemble func
Dump of assembler code for function func:
0x8048450 : push %ebp
0x8048451 : mov %esp,%ebp
0x8048453 : sub $0x18,%esp
0x8048456 : movl $0x0,0xfffffffc(%ebp)
0x804845d : movl $0x1,0xfffffff8(%ebp)
0x8048464 : mov 0xfffffff8(%ebp),%eax
0x8048467 : cmp 0x8(%ebp),%eax
0x804846a : jle 0x8048470
0x804846c : jmp 0x8048480
0x804846e : mov %esi,%esi
0x8048470 : mov 0xfffffff8(%ebp),%eax
0x8048473 : add %eax,0xfffffffc(%ebp)
0x8048476 : incl 0xfffffff8(%ebp)
0x8048479 : jmp 0x8048464
0x804847b : nop
0x804847c : lea 0x0(%esi,1),%esi
0x8048480 : mov 0xfffffffc(%ebp),%edx
0x8048483 : mov %edx,%eax
0x8048485 : jmp 0x8048487
0x8048487 : mov %ebp,%esp
0x8048489 : pop %ebp
0x804848a : ret
End of assembler dump.

查看运行时数据
———————

在你调试程序时，当程序被停住时，你可以使用print命令（简写命令为p），或是同义命令inspect来查看当前程序的运行数据。print命令的格式是：

print
print /
是表达式，是你所调试的程序的语言的表达式（GDB可以调试多种编程语言），是输出的格式，比如，如果要把表达式按16进制的格式输出，那么就是/x。


一、表达式

print和许多GDB的命令一样，可以接受一个表达式，GDB会根据当前的程序运行的数据来计算这个表达式，既然是表达式，那么就可以是当前程序运行中的const常量、变量、函数等内容。可惜的是GDB不能使用你在程序中所定义的宏。

表达式的语法应该是当前所调试的语言的语法，由于C/C++是一种大众型的语言，所以，本文中的例子都是关于C/C++的。（而关于用GDB调试其它语言的章节，我将在后面介绍）

在表达式中，有几种GDB所支持的操作符，它们可以用在任何一种语言中。

@
是一个和数组有关的操作符，在后面会有更详细的说明。

::
指定一个在文件或是一个函数中的变量。

{}
表示一个指向内存地址的类型为type的一个对象。


二、程序变量

在GDB中，你可以随时查看以下三种变量的值：
1、全局变量（所有文件可见的）
2、静态全局变量（当前文件可见的）
3、局部变量（当前Scope可见的）

如果你的局部变量和全局变量发生冲突（也就是重名），一般情况下是局部变量会隐藏全局变量，也就是说，如果一个全局变量和一个函数中的局部变量同名时，如果当前停止点在函数中，用print显示出的变量的值会是函数中的局部变量的值。如果此时你想查看全局变量的值时，你可以使用“::”操作符：

file::variable
function::variable
可以通过这种形式指定你所想查看的变量，是哪个文件中的或是哪个函数中的。例如，查看文件f2.c中的全局变量x的值：

gdb) p 'f2.c'::x

当然，“::”操作符会和C++中的发生冲突，GDB能自动识别“::” 是否C++的操作符，所以你不必担心在调试C++程序时会出现异常。

另外，需要注意的是，如果你的程序编译时开启了优化选项，那么在用GDB调试被优化过的程序时，可能会发生某些变量不能访问，或是取值错误码的情况。这个是很正常的，因为优化程序会删改你的程序，整理你程序的语句顺序，剔除一些无意义的变量等，所以在GDB调试这种程序时，运行时的指令和你所编写指令就有不一样，也就会出现你所想象不到的结果。对付这种情况时，需要在编译程序时关闭编译优化。一般来说，几乎所有的编译器都支持编译优化的开关，例如，GNU 的C/C++编译器GCC，你可以使用“-gstabs”选项来解决这个问题。关于编译器的参数，还请查看编译器的使用说明文档。

三、数组

有时候，你需要查看一段连续的内存空间的值。比如数组的一段，或是动态分配的数据的大小。你可以使用GDB的“@”操作符，“@”的左边是第一个内存的地址的值，“@”的右边则你你想查看内存的长度。例如，你的程序中有这样的语句：

int *array = (int *) malloc (len * sizeof (int));

于是，在GDB调试过程中，你可以以如下命令显示出这个动态数组的取值：

p *array@len

@的左边是数组的首地址的值，也就是变量array所指向的内容，右边则是数据的长度，其保存在变量len中，其输出结果，大约是下面这个样子的：

(gdb) p *array@len
$1 = {2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40}

如果是静态数组的话，可以直接用print数组名，就可以显示数组中所有数据的内容了。

四、输出格式

一般来说，GDB会根据变量的类型输出变量的值。但你也可以自定义GDB的输出的格式。例如，你想输出一个整数的十六进制，或是二进制来查看这个整型变量的中的位的情况。要做到这样，你可以使用GDB的数据显示格式：

x 按十六进制格式显示变量。
d 按十进制格式显示变量。
u 按十六进制格式显示无符号整型。
o 按八进制格式显示变量。
t 按二进制格式显示变量。
a 按十六进制格式显示变量。
c 按字符格式显示变量。
f 按浮点数格式显示变量。

(gdb) p i
$21 = 101

(gdb) p/a i
$22 = 0x65

(gdb) p/c i
$23 = 101 'e'

(gdb) p/f i
$24 = 1.41531145e-43

(gdb) p/x i
$25 = 0x65

(gdb) p/t i
$26 = 1100101

五、查看内存

你可以使用examine命令（简写是x）来查看内存地址中的值。x命令的语法如下所示：

x/

n、f、u是可选的参数。

n 是一个正整数，表示显示内存的长度，也就是说从当前地址向后显示几个地址的内容。
f 表示显示的格式，参见上面。如果地址所指的是字符串，那么格式可以是s，如果地十是指令地址，那么格式可以是i。
u 表示从当前地址往后请求的字节数，如果不指定的话，GDB默认是4个bytes。u参数可以用下面的字符来代替，b表示单字节，h表示双字节，w表示四字节，g表示八字节。当我们指定了字节长度后，GDB会从指内存定的内存地址开始，读写指定字节，并把其当作一个值取出来。

表示一个内存地址。

n/f/u三个参数可以一起使用。例如：

命令：x/3uh 0x54320 表示，从内存地址0x54320读取内容，h表示以双字节为一个单位，3表示三个单位，u表示按十六进制显示。


六、自动显示

你可以设置一些自动显示的变量，当程序停住时，或是在你单步跟踪时，这些变量会自动显示。相关的GDB命令是display。

display
display/
display/

expr是一个表达式，fmt表示显示的格式，addr表示内存地址，当你用display设定好了一个或多个表达式后，只要你的程序被停下来，GDB会自动显示你所设置的这些表达式的值。

格式i和s同样被display支持，一个非常有用的命令是：

display/i $pc

$pc是GDB的环境变量，表示着指令的地址，/i则表示输出格式为机器指令码，也就是汇编。于是当程序停下后，就会出现源代码和机器指令码相对应的情形，这是一个很有意思的功能。

下面是一些和display相关的GDB命令：

undisplay
delete display
删除自动显示，dnums意为所设置好了的自动显式的编号。如果要同时删除几个，编号可以用空格分隔，如果要删除一个范围内的编号，可以用减号表示（如：2-5）

disable display
enable display
disable和enalbe不删除自动显示的设置，而只是让其失效和恢复。

info display
查看display设置的自动显示的信息。GDB会打出一张表格，向你报告当然调试中设置了多少个自动显示设置，其中包括，设置的编号，表达式，是否enable。

系统分类: 资源共享   |    用户分类: 无分类    |    来源: 转贴

该用户于2009/3/29 9:43:03编辑过该文章

OVM实现了可重用的验证平台

关键字： SystemVerilog  OVM  事务交易级 

随着深亚微米工艺技术日益成熟，基于IP复用的IC设计方法广泛采用，集成电路芯片的规模越来越大，这对集成电路验证技术和方法学提出了很大的挑战。就如芯片设计一样，验证平台的可重用性也成为了验证工程师所关注的焦点。

在高级验证方法学(AVM)和通用可重用验证方法学(URM)的基础上，Mentor Graphics和Cadence共同推出了业界第一个通用、开放的验证方法学OVM；OVM为验证工程师提供了丰富的类库和高级验证技术，实现验证平台从模块级到系统级的重用，公司内外的重用，并且可以在多个厂家的仿真验证平台上运行。

可重用的验证平台

搭建一个高级的验证平台有很多要求，其中一个主要的要求就是要让验证平台可重用。验证平台的可重用性体现在以下几个方面：模块级验证到系统级验证的重用，同一个项目下不同测试环境的重用，在公司内部不同项目之间的重用，在不同公司之间的重用；从重用对象的角度来看，存在着验证组件的可重用、事务激励和产生算法的可重用等等。

OVM提供了事务交易级的架构，借助这些事务交易级的接口，可以搭建模块化，可重用的验证组件；它的类库可以帮助使用者创建约束随机的激励和序列，搜集和分析功能覆盖信息，包括断言在内的可配置和层次性管理的验证环境；其中基于Factory Pattern的对象生成方式，验证平台架构的动态构建，动态的参数配置，激励产生与验证架构分离和测试作为验证的顶层等高级技术使得可重用的验证平台更易实现。

验证平台架构的动态构建

在验证中经常遇到一个可重用性的难题就是需要及时调整特定的验证平台环境，对DUT应用一系列新的功能测试。通常，我们通过修改已有验证平台中特定的验证组件源代码，得到一个新的验证环境。例如，通过用一个注错功能的驱动器去替换通用的驱动器。这很容易就可以通过面向编程语言的技术，在例化原驱动器的位置上添加代码，例化一个注错功能的驱动器，从而扩展基类环境到一个新的环境。假如两个驱动器接口都是兼容的，那么验证环境的其他部分的代码便可以保持不变。

传统上，基于类的层次化对象产生创建是通过对象的构造函数new()来实现的。高层次的组件通过调用低层次组件的构造函数，创建低层次组件的对象。这种方法限制了创建对象的灵活性，因为对象的类型在编译的时候就已经确定了。另外，我们需要维护两个不同的验证环境，虽然我们可以通过面向编程技术使原有的代码得到重用，但是我们更加希望整个验证架构也能够重用；也就是说，我们希望可以不改动任何原有的代码，而调整其内容从而实现一个验证架构的重用。在OVM中我们可以通过Factory Pattern的方法来实现的。

Factory Pattern是一个很出名的面向对象的编程技巧，Factory是一个可以动态创建对象的类。它的主要好处是可以在特定的时刻创建特定的对象。Factory不是层次化验证架构中的一部分，而是处于层次化结构之外。OVM提供了一个Factory可以创建任何类型的事务交易或者任何验证组件，只要事前他们在Factory做过注册。Factory提供类型重写可以动态的改变所创建对象的类型。在OVM中我们通过ovm_factory来实现，见代码段1：

　　class my_env extends ovm_env;

　　 drv d1,d2;

　　…..

　　 function void build();

　　　　…… //build the rest of the environment

　　　　d1=new(“d1”,this); //explicit constructor:new()

assert($cast(d2,create_component(“drv”, “d2”))); // factory method: create_component //create an object of drv type

endfunction

　　…

　　endclass

我们从上面的代码可以看到d1和d2采用不同的例化和构造方式。d1这个对象是通过调用其构造函数来实现的，这限制了可重用性。相反，Factory的create_component()方法返回了一个drv类的对象并且赋给了d2。这两段代码都是一个drv的例化对象被创建，但是Factory提供了更大的灵活性，因为它可以在my_env类以外对其进行控制，也就是其上层的ovm_test例化中进行操作，从而可以从Factory中返回一个期望类型的组件给drvier的例化对象，如代码段2：

class err_test extends ovm_test;

my_env env;

function void build();

ovm_facotry::set_type_override(“drv”,“err_driv”); //factory type override meotod

env=new(“env”);

….

endfunction

…

endclass

set_type_override()方法告诉Factory：一旦验证环境通过create_component()要求一个drv基类对象的时候，请为其返回一个err_drv类的例化对象。在Factory中也可以针对特定的例化对象做类型修改。这个机制使得一个相同的验证环境类可以被例化到多个测试中，每一个测试都可能要求一个不同类型的driver的扩展，但是环境的代码没有改变。这个环境本身是一个可重用和上下文相关的(取决于测试如何控制Factory去生成相应类型的对象)。当在各个层次的build()阶段都采用这种的方式，每个上层的组件通过Factory去创建一个子组件的例化对象，那么任何一个组件就可以通过类似的方式来指定需要的类型。

动态的配置机制

传统的基于类的层次化验证环境中使用构造函数的参数来配置验证平台。例如验证平台的架构，参数设置(数组的大小和常数)，操作模式(错误注入和调试)是可以通过这个方法来配置的；但是在层次复杂的结构中，这种方法使用起来变得困难而且很难添加新的参数。

OVM支持内置动态的配置机制，来实现结构化属性和运行时参数的配置，从而避免通过构造函数的参数来传递信息。一个高层次的组件可以设置配置信息，这些信息被对应的低层组件的获取后使用。每个可配置的组件负责在合法的时刻去获取自己的配置信息：结构化配置信息，例如多少个子模块可以被例化，可以通过build()这个阶段来控制；运行时的信息，例如在总线周期之间需要等待多少个状态才注错，可以通过组件的build()或者configure()阶段来实现，他们也可以在run()这个阶段来实现。OVM提供了一个API来实现这个配置信息的设置和获取的过程。如代码段3：

class drv extends ovm_threaded_component;

　　local int delay;

　　virtual function void build();

　　 if(get_config_int(“numdly”,numdly)) //get the configuration from the global table

set_delay_length(numdly);

　　endfunction

　　virtual task run();

　　…

case(state)

　　 DONE:begin

　　 if(get_config_int(“numdly”,numdly))

　　 if(numdly<=10)

　　 set_delay_length(numdly);

　　 else ovm_report_error(“Driver”,”ILLEGAL length sepcification”);

　　 state="IDLE";

　　 IDLE:begin

　　 if(delay==0)

　　 state="GO";

　　 …

　　　endcase

….

endtask

　　endclass

配置信息可以通过高层的组件来指定，而常常由顶层的验证环境或者顶层的测试来决定；通过set_config_*()，配置也可以对一个特定例化上实现；配置信息可以直接的被制定为整数或者字符串的值，但是有些比较复杂的需要封装在一个ovm_object的对象中通过使用set_config_object()方法来实现。代码段4是一个例子，测试将配置driver中的延迟时间：

代码段4：

　　class dly_test extends ovm_test;

　　 virtual function void build()

　　 set_config_int(“env.d1”,”numdly”,5);

　　 …..

　　 endfunction

　　…

　　endclass

在OVM中这些配置是通过一个全局的查找表来实现的，其为验证平台提供了可重用性。第一，对组件的配置信息独立于自身的构造函数，这使得测试可以更灵活的根据其他配置信息或者随机地去为还未被例化组件配置信息。使用者还可以通过使用通配符来在多个组件中对多个参数做配置。组件自主获取其配置信息可以让组件保证无论在那种情况下都要被合法的配置。如果其中有不匹配的地方，组件作为一个仲裁者，会要求恰当的配置。

测试作为验证的顶层

标准验证平台的结构中有一个顶层的模块(top)，在顶层模块中例化了DUT(alu)，DUT接口(alu_if)和一个顶层的类(test_env)；顶层的类(test_env)即验证环境中包含了验证平台的所有组件，可以在这个架构中应用的SystemVerilog技术例如约束随机数的产生和功能覆盖率。

图1 标准验证平台的顶层结构

在标准的验证架构中，如图1所示，顶层的对象是一个环境类，其中嵌入了激励产生器。这限制了添加和修改测试的灵活性。

将激励生成算法从验证平台的结构中分离出来，这样可以让我们将一个测试的类(test)作为顶层的对象而不是一个环境的类(env)。

图2 测试作为验证的顶层

如图2所示，test_MAC是我们的测试，它是一个类，其中包含四个成员：

1.一个sequence(MAC_sequence)，其可以生成一系列事务交易；在这个例子中，事务交易通过sequence生成，是一个实现了乘累加算法的激励序列。

2.一个验证环境(t_env)，其例化包含了各种验证组件。

3.Factory的重写，可以为MAC的测试动态地创建一个验证环境。

4.配置信息，可以为MAC的测试动态地配置验证环境。

相对于标准的验证平台，测试作为验证的顶层在添加和修改测试上提供了很大的灵活性。每个测试可以定义它自己特定的配置信息，在编译完所有的测试和验证组件之后，每个测试可以不用重新编译就能运行，因为每个测试在它运行的时候可以动态的创建和配置验证架构。

采用了这种方法，上述例子可以根据不同的应用被配置到特定的测试中，包括选择特定的记分板，给测试指定一个合适的衡量机制，选择一个特殊的事务处理器或者配置一个可预测的结果。在某些情况下，整个层次化的模块可能被代替，例如激励生成模块，分析模块和监视模块。从而，同一个验证环境(test_env)能够被不同的测试(test)多次重用，动态创建和配置。

激励产生与验证架构分离

图3 标准的激励产生模块

就如我们前面所说的激励产生、事务交易在验证平台中的验证组件――激励产生器中创建生成；如图3所示，在我们的例子中driver是一个事务处理器，可以接受ALU的事务交易，例如加、减操作，将其分解送入到ALU的管脚级的端口中。在DUT和事务处理器之间通过虚接口(virtual interface)来实现。

激励生成算法被嵌入在产生器的类中：stimulus_gen，这种接口限制了修改测试的灵活性。为了添加或者修改测试，产生器的对象需要被另外一个产生器代替，从而需要重新配置和重新编译。除了支持上述方法，OVM推荐了另外一种方法：把激励生成的算法模块从验证平台的结构中分离出来，从而在添加和修改测试上提供更大的灵活性。

图4 层次化的激励产生模块

在图4中，生成事务交易的算法包含在一个sequence对象中：MAC_sequence，这不是一个结构化的验证组件，而是存在于验证架构以外。OVM提供了sequence，在验证架构以外来生成事务交易。整个激励层次由一个sequence (MAC_sequence)，一个sequencer和一个事务交易器driver组成。sequencer同步了MAC_sequence和driver之间的通信。

作者：钟文枫

　　应用工程师

　　Mentor Graphics

　　ahan.mail@g mail.com

系统分类: 资源共享   |    用户分类:    |    来源: 转贴