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< /strong>
在此示例中，有三个文件，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< /strong>
此示例将显示假设“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 中对他们的工程进行设置。
结论:< /strong>
选择 VHDL 文件的库名时应小心。 虽然名为“work”的库是许多工程公用的库名，但该工具处理这个库名的方式与处理其他库名的方式略有不同。 如果将顶层文件编译到不同的库中并引用“work”，那么它就不会从名为“work”的物理库中获取行为。 如果这不是所期望的，就可能会导致混乱的行为。
我的建议是永远不要使用“work”库。 相反，在例化较低层时，始终应指定要使用的库。
这样做有点费事，但通常会给你你想要的行为。
