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”庫。相反，在例化較低層時，始終應指定要使用的庫。

這樣做有點費事，但通常會給你想要的行為。