使用 VHDL 中的 “work” 库

VHDL 的一个强大功能是用库来组织 RTL 的不同部分。 通过使用库,不同的设计人员可以做这个工程中自己负责的那部分工作,而不必担心会在命名方面与其他设计师发生冲突。在例化期间,这可以通过手动指定要使用的库或者通过配置语句来完成。

例如,已经在一个名为“my_lib1”的库中创建并编译了一个名为“bottom”的实体。

编译到任何库中的顶层可以轻松地通过直接实体例化来引用底层:

u0 : entity my_lib1.bottom port map (in1 => in1, out1 => out1);

通过采用上面的编码方式,需要哪个版本的底层就显而易见了。 “my_lib1”库中的版本是正确无误的版本。

一个常见的误解与何时使用名为“work”的库有关。 许多设计师将“work”用作库,假设它与其他库一样,是一个物理库。 但情况并非如此。名为“work”的库在 VHDL 中的用法比较特殊。

它不是一个物理库,实际上它指的是“当前库”。

当一个文件被编译到一个特定的库中,然后被告知从“work”中获取逻辑时,它不会在名为“work”的物理库查找,而是会在例化的文件被编译到的库中查找。 这一点可以通过几个例子来展示。

示例#1

在此示例中,有三个文件,top.vhd、bottom1.vhd 和 bottom2.vhd。 Top.vhd 是设计中的顶层,例化了一个名为“bottom”的实体。 底层的两个文件都有一个名为“bottom”的实体。 在 bottom1.vhd 中,有一个输出是由一个通过反相器过驱动的的输出。 在 bottom2.vhd,中,输出直接由输入驱动。

顶层被编译到名为 y_lib1、bottom1.vhd 的库中(也在 my_lib1 库中),而且,bottom2.vhd 在名为 my_lib2 的库里。

在顶层,例化看起来类似于以下内容:
u0 : entity work.bottom port map (in1=> in1, out1 => out1);

查看详细视图,该示意图如下所示:

这正是我们期待看到的结果。 更重要的是,当使用相同的建立运行仿真时,波形图如下例所示:

接下来,如果 top.vhd 文件的库从 my_lib1 转换到 my_lib2,则对详细视图所做的更改如下所示:

并且,仿真波形图也会发生变化:

这正是我们预期的结果。 因为 top.vhd 文件在 my_lib2 中,并且在实体例化中使用了“work”,所以它将从 my_lib2 中获取底层。

示例#2

此示例将显示假设“work”是物理库所带来的危险。 这是与示例 #1 类似的测试。 在此示例中,top.vhd 和 bottom1.vhd 将被编译到“my_lib1”库中,bottom2.vhd 将被编译到名为“work”的库中。

与前面的示例一样,顶层例化底部,如下所示:
u0: entity work.bottom port map (in1 => in1, out1 => out1);

这个设计的详细视图类似于以下示例:

仿真如下所示:

因此,即使 bottom2.vhd 已被编译为一个名为“work”的物理库,并且顶层由“work”库例化了底部,但该工具仍然会使用 bottom1.vhd 中与 top.vhd 编译到同一个库中的行为。

Vivado 默认库:

默认情况下,将 VHDL 文件输入 Vivado 工程时,该工具会将这些文件放入一个名为“xil_defaultlib”的库中。 这样做的原因是让只使用库的用户能够轻松地将旧的工程移植到 VHDL 中,同时还能帮助设置有更多组合结构的用户以恰当的方式在 Vivado 中对他们的工程进行设置。

结论:

选择 VHDL 文件的库名时应小心。 虽然名为“work”的库是许多工程公用的库名,但该工具处理这个库名的方式与处理其他库名的方式略有不同。 如果将顶层文件编译到不同的库中并引用“work”,那么它就不会从名为“work”的物理库中获取行为。 如果这不是所期望的,就可能会导致混乱的行为。

我的建议是永远不要使用“work”库。 相反,在例化较低层时,始终应指定要使用的库。

这样做有点费事,但通常会给你你想要的行为。

推荐阅读