[视频]Sigrity技术好帮手 – 如何创建IBIS-AMI模型

Allegro Sigrity SI Base是嵌入到Allegro平台的高速信号电路板和IC封装的信号分析解决方案。您只要在原本熟悉线路图或PCB布线环境下指定一个信号或一个差分对，它的物理性质如层的结构和网络的拓扑结构就可以像模型一样被萃取出来进行了时域的模拟分析。

此段视频将介绍基于Allegro Sigrity SI Base，建立和验证您的千兆位高速串行总线，并达到业界标准。

视频将在Sigrity老司机的操作下，演示如何创建IBIS-AMI模型而无需具备任何程序设计技能。

IBIS-AMI IBIS 即”Algorithmic Modeling Interface”。

IBIS AMI模型范围

上图所示为一端自最首至最末的通信通道；其中绿色的部份占通道的大部份，是以如传输线模形所表示的PCB绕线、及用S参数所表示的导孔或连接器等组成的被动通道部份；其两端、以粉红色区块表示的部份即以IBIS表示的模拟前端；这些前端部份直接与通道连接；除这两者之外,在TX的最前级、及RX的最后面则是各种等化电路。这些电路现常以AMI模型来描述。之前所述的几个部份组合在一起，则可用以描述通信通道整体并加以仿真或分析。由此可见，AMI实则是和IBIS的部份一起运作以提供等化模型的（也就是说，若无等化电路，则无使用AMI模型的需要）。实务上来说，在一会与AMI共同运作的IBIS模型里，会看到如下图所示之数行描述，即会指向所使用的几个AMI模型成分：含各类模型参数、以纯文字档表示的.ami档案、编译出来的二进制文件.dll(on windows)或.so(on linux),以及编译此二进制文件所使用的编译环境等等。

为什么需要使用AMI:

对于系统整体性的分析，若欲为结果做一量化的描述，一般最常用的是眼图里的眼高及眼宽、以及依此所能推算出来的误码率(Bit Error Rate, or BER)或bath tub curve，要能形成眼图，则需有很多的位元信号响应在时域上围着周期中心重叠起来。在分析完整的通信通道时，不论是以原Transistor之缓冲器设计抑或是其IBIS模型，在时域上要仿真数以百万计的位元信号（才能得到想要的低BER)都是要需时甚久的。即便如此，得到的BER数据也极其有限而常需要以外插的方式来推算实际值。除了以仿真为手段外，另一种能得到波形以形成眼图的方式是直接合成。 速度远比进行仿真快得多。 IBIS模型因其设计上的限制并无法让我们如此做。除了能在极短时间内算出许多位元波形的速率考量外，下列数者也是发展AMI的原因：

• 业界标准：纯欲以高速在短时间内得到很多位元波形的目的而言，也是有其它商家特有的高阶语言（如Matlab)可满足这需求的；但如此一来建模工程师便等同限制了使用其模形客户的分析工具；除此之外，这样建出的模型也无法用其它模拟器来加以验证。为了能让IC及EDA业者均有能交换使用的模型标准，如AMI的模型规格实有其必要。
• 分析速率：如之前所述，需要一能在短时间内得到数以百万计位元响应的方法及模型。
• 扩充弹性：其实在AMI之前，IBIS委员会也曾经用Bus Hold或Driver Schedule等的关键字来试图在IBIS内加入等化器的有关描述。甚至在IBIS V4.0中，也有用以Verilog-A为代表的高阶语言来扩充以关键字为主的IBIS模型的弹性。但执行起来，前述两关键字的使用极其僵化，而Verilog-A又是直译的语言，远比不上用C/C++来编译的语言弹性更高且能保护智财，因而有AMI之倡议。
• 知识产权保护：等化器设计电路常是IC公司极欲保护的智财，故一以编译（编来的档案是二进位档）为主、不易被反向导出原设计的建模即有存在的必要。

什么是 IBIS AMI

在谈过AMI的模型范围及其需求背景之后，我们来谈谈倒底什么是AMI及其组成部份：

对IBIS AMI建模者的角度而言： IBIS AMI即三个您需提供实际执行的函式定义表头 (header .h file)，这三个函式即Init, GetWave 及Close:

• AMI_Init: 这个函式必需有实际执行码，它的功能就好比物件导向语言里Constructor的角色。若输入AMI模型的是长串的位元输入，则AMI规格允许它们被分成好几小段分别被作为输入并执行。也就是说，程式码里有很多资料结构可能重覆地(在不同的位元输入段落）里被使用，故Init函式提供一可在一开始之初便初始化这些资料结构的地方。其次，若通信渠道为线性且非时变(Linear, Time-Invariant or LTI)，则在Init函式里便可对模拟器所提供的渠道突波响应(Impulse Response)做直接的计算而可略过GetWave函式的实际执行。
• AMI_Close:　这个函式必需有实际执行码，它的功能就好比物件导向语言里Destructor的角色。其功能是在模拟结束之际，为之前已分配的资料结构之记忆空间释放回底层的作业系统。
• AMI_GetWave:　这个函式的执行可有可无。若含EQ在内的通信渠道为非线性或具时变性，则将无法透这一个突变响应便用波形叠加(Superposition)的方式直接合成并算出BER,在这种情况下，则必需执行GetWave，一长串的位元信号会依序或分段地传进模型，而后GetWave便一段段地将其做计算并输出结果波形，模拟器最后才将这些波形再组合起来以组成时域波形并进行叠合(Folding)以产生眼图。

对IBIS AMI使用者的角度而言：IBIS AMI是由以下三个档案组成的模型：

• IBIS file: 这即类比前端的部份，且需有一”[Algorithmic Model]”的描述以指向下面两个档案，　即.ami及.dll/.so档。
• .ami file: 这是一纯文字叙述的参数档案。建模者将模形参数外显供用户调整的部份均在此处。例如下图中即示出一含有四个tap的等化器设定；可以看到各个tap的比重参数均以数字实际标示出来，且用户也可加以更改。除此之外，其它的模型参数、诸如是否有GetWave函式的支持等等也包括在此档。模拟器一旦透过最上层的IBIS档案读到这.ami档后，其便知将如何跟最底层的二位元档(.so/.dll)进行资料交换。
• .dll/.so file:这即编译出来的档案，要注意的是这两者也跟用户作业系统是３２或６４位元有关。若您是使用６４位元的作业系统，则也必需要用６４位元的.dll或.so档案才能透过模拟器进行分析。

IBIS AMI的使用场景：

IBIS AMI的建模者无法预见其建出的模型如何被使用，然而模型本身便限制了其适用的场景。 AMI的使用场景有分为Statistical及Empirical两种模式；若GetWave函式没有在.dll/.so里支持的话，则这个模型将只能透过Statistical模式运作。也就是说：通信渠道将假设为线性非时变，一个突波响应即可用来导出所有的BER。相较之下，一个有GetWave函式支持的AMI模型在Statistical及Empirical两个模式里都可被使用而不一定要有渠道是线性且非时变的假设。下图简示了两模式运作的不同：

Statistical flow:　在此模式下，渠道为线性且非时变，故可用一个突波响应来以superposition的方式合成数个或更多的位元的真实响应。也就是说，模拟器提供被动渠道部份的突波后，TX 及RX的模型即可在Init里将自身的转换函式与其做卷积(convolution)来做如peak distortion analysis般的计算来得到BER。

Empirical flow:　在这模式下，渠道为时变或非线性，模拟器会产生长串的位元序列并与被动渠道做卷积，其结果会再被分成数小段，每一段会与TX 或RX的GetWave函式做运算，最终结果再由模拟器重组成长串时域波形而算出眼图或BER。

在实务上，因为TX, RX的模型可能由不同的IC厂家所提供，故不同组合下会有更多运作上的限制。读者可参阅IBIS规格文件里第十章的部份来了解更多的细节。