| LPM的来历 | LPM的来历
说到LPM（Library of Parameterized Modules），就一定要谈谈EDIF（Electronic Design Interchange Format）。EDIF文件是EDA厂商之间和EDA厂商与IC厂商之间传递设计信息的文件格式。LPM最初是作为EDIF标准的附件出现的。
EDIF和LPM的标准化过程：
1988年，ANSI/EIA-548: Electronic Design Interchange Format (EDIF), Version 2.0.0。
1990年，LPM标准提出，供EIA审核。
1993年，EIA 618: Electronic Design Interchange Format (EDIF) Version 3 0 0 Level 0 Reference Manual，LPM作为EDIF标准的附件，成为EIA的一个过渡标准。
1995年，EIA PN 3714: Library of Parameterized Modules (LPM) Version 201。
1996年，EIA-682: EDIF Version 400 (EIA-682-96) Electronic Design Interchange Format。
1999年，EIA/IS-103A: Library of Parameterized Modules (LPM) Version 2.0。
从年代上看来，88年到90年前后恰好是半定制设计风格超越全定制设计风格，成为VLSI芯片设计主流的时期。LPM标准的提出可能正是响应了半定制设计的需求。
EDIF文件是EDA工具之间传递信息的标准格式。画过电路原理图和PCB的朋友一定知道，原理图文件绘制完毕后需要“生成网表”，进行PCB布局布线之前先要“引入网表”，这样才能建立原理图文件和PCB文件之间的“逻辑映射关系”。EDIF文件就是网表文件的一种格式。在很多情况下，原理图文件中的模块图形和PCB文件中的“封装”是一一对应的，这种“物理映射关系”就是通过“库文件”建立的。“库文件”包含了原理图模块的名称和图形，也包含了封装文件的名称和图形，这样一来，“物理映射关系”就建立起来了。在不同的EDA工具之间，比如Protel和Cadence还有PowerPCB，逻辑映射关系是很容易互相通用的，但是由于支持不同的“库文件”，物理映射关系往往就建立不起来。
在IC设计领域（包括PLD设计），EDIF文件就遇到了类似的问题：综合工具和实现工具必须达成一致。在LPM标准提出之前，这一点很难实现，毕竟IC设计领域存在太多的实现工艺和EDA工具。
在LPM标准提出之前，对于某些逻辑的描述没有统一的标准，描述方法都是工艺相关（Technology dependent）的，所以综合工具生成的EDIF文件不具备可移植性。在采用了LPM标准之后，对于LPM库中包含的逻辑，所有的综合工具都采用同一种行为描述方法，生成相同的EDIF文件，实现设计输入和网表的正确映射；实现工具包含各自工艺库与LPM库之间的唯一映射关系，从而能够“读懂”包含LPM描述的EDIF文件，实现网表和工艺实现之间的正确映射。这样一来，EDID文件在不同的实现工具之间移植就不成问题了。（LPM并不是唯一的解决方法，比如现在的EDA工具之间往往互相支持对方特定的库文件和网表格式，尤其像Synplicity这样的专业EDA公司，同时支持许多公司的器件和网表格式和宏单元；而Altera和Xinlinx就不能互相支持）
在这一过程中体现的原理是：通过增加一个映射层次，把一次映射关系转化为两次映射关系，两次映射关系的中介——包含LPM描述的EDIF文件——就具备了可移植性。
借来一幅图，可以更清晰地表述上述内容，不过需要细看才能看懂：
![]()
LPM标准的提出还解决了设计者面临的图形输入法可移植性差和HDL输入法硅片利用效率低的两难困境。
采用图形输入方法可以很精确地描述底层实现细节，综合工具不需要推测设计者的意图就能很准确地生成EDIF文件，效率很高。但是由于包含了硬件实现细节，只有专用的实现工具（布局布线工具）才能“读懂”这样的EDIF文件。这样一来，就需要设计输入（原理图）工具——综合工具——实现工具严格一致，带来了图形描述文件的可移植性问题。
采用HDL输入方法避免了从门级描述硬件细节，只要综合工具——实现工具达成一致就不存在HDL文件（设计输入文件）的可移植性问题。但是对于同一个逻辑功能，缺乏统一的描述方法，最后的实现效率取决于综合工具，实现效率往往不如图形输入方法。
通过采用LPM标准，设计输入工具、综合工具、实现工具对于同一个逻辑功能在不同抽象层次的描述达成了共识：设计输入工具调用LPM模块，综合工具或者实现工具保证和实现LPM模块描述的逻辑功能和实现工艺之间的唯一映射。从可移植性角度看来，由于在设计输入阶段不需要涉及具体实现工艺，LPM输入法具备与HDL输入法同等的可移植性；从实现效率看来，由于综合工具或实现工具采用了最佳的映射，LPM输入法具备与图形输入法同等的高效率。LPM兼具了HDL输入法和原理图输入法的优点，而避免了二者各自的缺点。
采用LPM设计方法，可以带来四点好处：
1. 设计文件具备独立于实现工艺的可移植性。
2. 保证最佳的实现效率。
3. 保证设计工具之间的互操作性。
4. 可以完成几乎所有设计需要的逻辑描述。
其中后两点在今天看来还是有问题的：Altera和Modelsim之间就不能实现LPM模块的自动同步，Modelsim需要在仿真Altera的LPM模块前编译Altera的专用仿真库；采用LPM模块完成所有的逻辑描述还是有点儿累的（相对于HDL来说）。
LPM包含25个基本模块，可以通过配置参数实现各种数据宽度的逻辑功能和多种不同的功能特性。
| CONST | INV | AND | OR | XOR | | LATCH | FF | SHIFTREG | RAM_DQ | RAM_IO | | ROM | DECODE | MUX | CLSHIFT | COMPARE | | ADD_SUB | MULTIPLER | COUNTER | ABS | BUSTRI | | FSM | TTABLE | INPAD | OUTPAD | BIPAD |
LPM标准的价值在于是否有足够多的EDA厂商采用这一标准，从而保证最佳的互操作性。早在1993年，Altera就支持LPM标准；在1995年年底之前，主要的EDA厂商也都会支持LPM标准；据1995年的说法，Xilinx也将会在“近期”支持这一标准。
从上面一段文字看来，LPM标准确实有历史了，基本上是10年前的事。EDA技术的更新换代非常迅速，10年前的HDL综合效率问题在今天看来已经不是主要矛盾。但是从提高资源利用效率和保证代码质量角度看来，LPM仍然不失为一种有效的设计输入方法，仍然有其用武之地。（既省去了手工编写代码的工作量，还保证了最优的结构映射，何乐而不为呢？）
原本想写Altera的Megafunction在设计输入中的用法，随着不断查找资料才领悟到LPM不等于Megafunction（Megafunction是LPM的超集），接下来就写了很多关于LPM的内容。关于LPM和Megafunction的用法，下一篇再说吧。
背景资料：
EDIF的网站，现在可能不存在了，幸好有人做了镜像。
EDIF Input File (.edf) Definition
Library of Parameterized Modules (LPM)
|
|
楼主
标题置顶
标题高亮
