work库在VHDL中的特殊用法

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”库。  相反，在例化较低层时，始终应指定要使用的库。 

　　审核编辑：汤梓红