IBIS-AMI: 模型架构分析

前言:

在前篇贴文, 我们大致探讨了有关IBIS-AMI模型的几种相关角色及其所需要的考量;在这篇文章中,我们以建模工程人员的角度来研究几种可能的建模流程及其利币。先申明的是本文中所提到的几种其它商用程式范例均以在网上可合法公开取得的资料为准, 所参考到的文章已列于本文之末。

IBIS-AMI模型:

不论欲建为其建模的SERDES设计是多么的精巧复杂,最终要做的事仍是要以C语言将其以合乎AMI API的三到五个函式(取决于要支援的IBIS SPEC.)写出来并以编译器在相对应的系统上做出.dll/.so的格式。要先说明的是API虽必需以C语言写出,但其中的运作(即函式叫进来后是怎么算出SERDES结果的)并不以C语言为限。比如说用户可以用matlab写出其中的计算并以p-code, 可执行码或函式库的形式与外包的C语言进行资料交换。不论如何,这套程序所要进行的工作仍然是如何能将SERDES的运作转成相对应的源码(source codes), 在此之上,另要考量的则是如何做才能使得产出的程式跑得快、算得准、容易维护又延伸性佳。

IBIS-AMI应用程式界面

为达此目的,一种相对简单的建模流程是利用程式自原始设计自动地将源码产生, 也就是所谓由上而下(Top-down)的设计流程。

由上而下的建模流程:

一般硬件的设计流程都是由上而下的:一开始是做布线规画(floor planing),然后必需有的各功能以方块图的方示表之,在此阶段,各方块图内的细节先不是重点,要求的是各功能区块间的行为互动、资料交换标准、及时域或譟声的预算或容忍值等等。在这之后各设计人员或团队才分开并针对每一个功能区块做实体上的设计。最后把所有的设计整合起来做最后的整体分析或仿真。以此设计流程而言, 一般会有可编辑原理图(schematic)的软件让设计人员把现有函式库或样版(template)编辑并接连起来, 而每一个区块也常是各自有其阶层性(hierarchical), C/C++源码产生是由软件将每一层的设计逐层逐级地产生。

要将设计转成源码, 如果顺利的话一般是设计人员先右击各功能区块且设定要外显(expose)的参数及名称或变量范围, 然后透过一程式产生模组来将设计转出对应的C/C++源码。就IBIS-AMI而言因其不仅有功能上的要求,在API函式的名称及参数上也有规范, 故常还要另外有一个AMI专门的外挂来进行这些动作。

就这种程序而言, 用户只要专注在SERDES的设计就可以了而毋需去考虑产出软件的内容细节及品质。因为这两家公司在业界也算有名,所以一般可相信以这些源码做出的模型在实际运作后也能产生和原设计几乎近似的结果。

电脑产生的源码:

由电脑或程式自动产生的源码, 可以看到软件”很忠实”地如原理图般一阶一阶地把它们串起来了,但坦白而言, 可读性、维护性及延展性可能都不高,其次,不论如何为这些程式做更动或调整, 下回当再次将设计右击鼠标产出源码时,所更改的这些部份又都将被覆写而白作工了。也就是说,这种由上而下的建模方式在下端(即已产出的AMI模型)做的改变更动大概都无法回溯置回原始(上方)的设计里。

我对这种由上而下的AMI建模方式的看法是:

  • 适合给有所有原始设计、且又不想管CODE的工程师用
  • 由这些程式自动转出的程式:
    • 应能算出准确的结果,(如果不是的话就麻烦大了… 因为不会有最原始的程式码可供查验侦错)
    • 运作起来跑不快, 至少以目前所见的情形都会是如此
    • 结果源码可读性不高…无法强制依某种coding guideline来产出, 所以并不容易维护及做长久性的支援
    • 由上而下是单向式的, 改变的源码无法回头标注在原始设计中,所以下回再次产生源码时可能就又被覆写过去了。

由下而上的建模流程:

若是以软件架构的眼光来看AMI建模的需求,又会做如何的设计流程呢?猜想应是会和由SERDES工师师来做不同, 一般而言, 可能会做如下般:由下而上(bottom-up)式的规划:

  1. 首先, 先定义出AMI建模中常会用到的几种功能区块, 诸如
    • FFE: Feed-forward equalizer, LTI, Time or frequency domain
    • LPF: Low pass filter, LTI, freqeuncy domain
      • CTLE, Bassel, filter based IIR/FIR etc
    • DFE: Decision feedback equalizer, NLTV/digial, time domain only
    • CDR: Clock data recovery, NLTV/digital, time domain only
    • Coder: various coding page
      • 64b66b, 8b10b etc
    • PRBS: Pseudo random bit stream, PRBS7, 10, 15 etc
    • AFE: analog front end to convert pulse to shape with Rt/Ft/Swing etc
  2. 其次, 就这些区块为透过OO的要求针对AMI来做设计:先定义出软件界面、基础类别及要以虚拟函式来执行的相关运作等。
  3. 而后,针对不同的区块进行实作, 并在上层要连结起来的阶层以”更优雅”一点的方式整合
  4. 这点可算做加分题:可顺便考量更进阶的外加功能(诸如加密, 为不同CTLE或FFE组态做切换的设定等等)可如何地透过.ami档来进行等

因为这些源码是手动写出来的…而非机器程式一贯作业产生的, 所以在可除错性、程式易读及可维护性、以及可延伸性上应都有更好的结果,再加上适当的说明文件, 这些模型可视为是公司软件智财的一部份而有其价值且可长久使用。

在运作准确性的要求上:

  • 这些源码应尽量不要是为单一设计而做, 所以不应有hard coded数字的情况发生,所有设定应尽量参数化以供自动优化用
  • 可透过sweep, lest-squared-error based fit, 或其它的优化方法以取得一组能和原始硬件设计效能最近似的参数供模型使用, 也就是说, 以此法得出的模型,不能假设其必然准确,而需另下功夫才能达到这要求。

我对这种由下而上的AMI建模方式的看法是:

  • 适合给懂得OO又对软件编程有兴趣的工程师使用
  • 因为大都是人手工写出的软件:
    • 需另下功夫以先确保软件品质,而后再求精确性
    • (做得对的话),应会跑得更有效率
    • (做得对的话),会更易维护并延伸
    • 可重复使用性高(软件的本质),长久而言应更具经济效益。

资料表单式的AMI建模:

综上所述, 两种AMI建模的流程都各有利币,难道不能有两全其美的方法吗?

当然是可能的…但并不相对简单, 究竟即便是工程师也各有分工专业,这也就是为什么提到AMI建模时需要软硬件相关知识,再加上DSP, 科学或工程计算等等的跨领域背景要求了。

大致上来说, 我认为如果能将两种不同流程里的短处减至最少,则就有近似两全其美的条件;比如说, 当我有机会找到其它EDA厂商的AMI元件库时,很高兴地发现其实它们的设计也都如bottom-up或软件模组的思维一般是很有完整性的, 之所以会在由上而下流程走过后产生令人不敢恭维的源码是因为SystemVue(Simulink大概也一样)这套软件给一般设计使用(就像CPU一样, 什么都能做),也就是说, 它们的设计理念是:我们可将任何设计转出相对应的源码, 转出后的品质等是其次的考量。

既然要改变大公司现有软件应用领域大不易,则从另一方面来思考, 我们也可从现有的很多(开源等)DSP或滤波器函式库来做运用而非重新发明轮子般地从头做起, 在这些已经过较多测试函式库上再以软件工程的思维(而非广义的自动软件产出)来做AMI的建模应是更易着手的方案。所幸的是这类的开源函式库很多,其实就连上述两套体体里也处处可见运用这类公用函式连的踪迹。更有甚者, 很多的AMI功能其实都可先编译出来, 再事后透过外显的.ami档案来将各功能加以组合, 从这观点来看, 就像是以datasheet/spec来将已做好的AMI模型透过.AMI来自动产出一样。

最近其它先进所发表的一些文章, 及以诸如我等较小EDA公司所订出的AMI建模方案都是朝这个方向进行, 也因此更能证明这个折衷方案是能得兼由上而下及由下而上两不同流程优点的一可行方式。

参考文件:

2015 DesignCon paper: [HERE]
2016 IBIS Summit paper: [HERE]
2016 DesignCon paper: [HERE]

Leave a Reply

Your email address will not be published. Required fields are marked *