多芯片联合仿真时，经常会碰到库文件重复的问题。
场景回放一般是这样的：
项目组A开发了IC_A，项目组B开发了IC_B。然后，验证团队接收到了IC_A和IC_B的联合仿真任务。IC_A有可能基于自己的库开发，IC_B也基于项目B的库文件开发。这里说的库文件，有可能是类似于fifo、ram这样的库，也可能是不同的厂家库。
此时，就会出现库文件重复的问题。解决方案只有两种：
1、 统一使用某个项目的库，前提条件是，两个项目的库文件完全一致；
2、 分别使用各自的库文件，如IC_A使用项目A的库文件，IC_B使用项目B的库文件。
其中，两个项目的库文件完全一致的条件是很难达到的，原因可以分析如下：
1、 不同的厂家库，内容不一致；
2、 相同的厂家库，不同工艺，内容不一致；
3、 不同的项目，在设计fifo、ram时，有可能存在细微差别，但文件名重名。
一般情况下，当涉及到多芯片联合仿真时，受限于很多条件，不会采用统一使用某个项目的库文件的解决方案1；更常见的方式是采用分别使用各自的库文件，即采用方案2。
当我们采用方案2时，就需要使用libmap的技术。
libmap是Verilog 的标准，可参考《IEEE 1364-2005》的第13章，讲解的非常详细。
当然，这次为了写公众号文章，我才真正了解到这个特性是Verilog的标准，而非EDA厂商特有的特性。因此，S家的vcs.pdf里描述的非常简单，通篇能搜索到libmap的地方仅有两处；而C家就要好很多，在Elaborating.pdf里，有详细的描述，基本赶得上IEEE的描述了。
当然，如果要学习的话，我推荐大家还是使用IEEE标准学习。
我们回到开篇的问题，解决多芯片联合仿真的库文件重复问题的方案：
1、 将不同项目的库文件编译成不同库，如项目A的库编译为lib_a，项目B的库编译为lib_b；
2、 让不同的芯片使用各自的库，如IC_A使用lib_a.fifo，而IC_B使用lib_b.fifo。
Step1
我们需要定义一个（或多个）libmap的文件。本文暂时以1个libmap文件为例。
说明：
L1：将${proj_a}/lib目录下所有verilog库文件作为lib_a；
L2：将${proj_b}/lib目录下所有verilog库文件作为lib_b；
L4：定义一个config为lib_cfg（config可以有多个）；
L5：定义顶层文件为tb_top（顶层文件可以有多个层次）；
L6：另tb_top.IC_A_u下的fifo_u使用lib_a；
L7：另tb_top.IC_B_u下的fifo_u使用lib_b；
L8：结束这个config，注意此处没有分号。
Step2
我们需要了解，生成库lib_a、lib_b是编译环节实现的。
如上图，标准中说，若文件没有匹配任何的库文件路径，则将被编译如默认的“work”库。这句话从侧面印证了生成库是编译环节实现的。而“-y”实现的是“search forunresolved module references in directory 'libdir'”的功能，该动作是在elaboration环节实现的。因此，-y是解决不了多芯片的库文件重复问题的。
由于生成库的动作是在编译环节实现的，因此，所有需要区分库的文件（如lib_a、lib_b中的文件），都必须加入filelist，在编译环节参与编译。
step3
告知编译器，我们使用的libmap文件，以及顶层。
L3：告知编译器，我们使用的libmap文件路径（可以有多个libmap文件）；
L4：告知编译器，我们的libmap的顶层配置（应该在多libmap时更体现价值）。
到这个阶段，我们在技术上已经是可以解决多芯片联合仿真的库文件重复问题了。因此，当小G同学得到答案后，就欣然行动了起来，非常勤奋的！
“勤奋”，Why？
因为我目前给的解决方案是基于instance的，有多少个库文件的instance，就要写多少行，而且必须首先要有库文件的instance列表！
我目前不知道这是否就是最终的解决方案。我还需要继续尝试，例如让IC_A下的所有例化都使用lib_a，让IC_B下的所有例化都使用lib_b。这样，工作量就会大量减少了。预知后事如何，您只有加入“IC验证工程师交流群”才能知道了。
非常欢迎您在“IC验证工程师交流群”讨论（推荐），或者在公众号留言（查看不及时）。扫描下方的二维码，可加入“IC验证工程师交流群”。
本文为原创，转载请注明出处：IC验证工程师
联系客服
