work我的同行们对使用当前工作库的名称（指向当前库的别名）而不是显式地使用名称（例如）存在一些担忧mylib。
例如，如果您引用同一库中的另一个设计单元，您可以这样做：
my_inst : entity work.my_design
或者
my_inst : entity mylib.my_design
我觉得使用work更灵活，因为它不依赖于您将设计编译到的库的名称。您可以重命名mylib为myawesomelib，它仍然有效。
我能想到的一个明显的例子work是，如果您通常将设计单元和测试平台编译到同一个库中。那么，在您的测试平台中，通过 引用您的 UUT（设计）始终是安全的work。
一个缺点是，如果（如上例所示）my_design不再位于同一个库中，设计将停止工作；如果使用throughmy_design的其中一个或任何设计被分离，则该设计将被破坏并且必须更新参考。my_designwork
work使用显式库名称还有其他明显的缺点吗？在分层使用的情况下，work是否可能会混淆哪个库是“当前工作库”？
例如：
mylib1
(top_design.vhd)
...
my_inst1 : entity mylib2.my_design
...
mylib2
(my_design.vhd)
...
my_inst2 : entity work.my_sub_design
...
work编译 top_design.vhd 时，所包含设计中的引用是否存在混淆mylib2？或者既然my_design.vhd已经编译进去mylib2就没有混乱了？
脚注：永远不要将你的库命名为 work。
哦，工作。我如何恨你？让我来计算一下。
components在多个地方声明。这些component声明经常发生冲突！请，请，请使用图书馆！他们在那里是有原因的。它使您的代码更加有组织、灵活和可移植。
组织
库应该位于其自己的文件夹中。我喜欢将所有内容都放在一个顶级文件夹下，例如 UART。在它下面有 4 个目录：build、source、sim、docs。这样，您的模拟和文档都可以与库代码一起传输！这是多么甜蜜啊！您无需担心在哪里可以找到那个愚蠢的 UART sim，您总是知道它在哪里。顺便说一句，这意味着自检测试平台是强制性的！我的立场一点也不差。
灵活便携
如果您正在为一个项目编写代码，您就会做出假设。“哦，我的时钟是 25 MHz，所以我可以将其设为常数。” 但是，如果您为库编写代码，您就会意识到自己做出了错误的假设。在 UART 示例中，您需要使波特率generic不是一个常数。这使您的代码更加灵活并且更易于其他人使用。
打包文件
每个库应该有一个包文件。您的所有组件都应包含在此包文件中。这样，如果你的实体发生变化，你只需要更新包文件中的组件即可。包文件应包含该库中使用的所有常量、函数和过程。同样，这允许您在一处进行更改。
结论
库是制作深思熟虑的、可重用的、易于移植的代码的方法。当我看到所有代码都编译成工作时，我感到畏缩。