以下是架构类型：

行为的：

一般注意事项：

• 传统上没有层次结构（只有一个文件，没有实例化组件），尽管这因工具而异。
• 非常快的模拟。
• 定义了信号行为。
• 当行为仅用于模拟时，它可能包含不可综合的代码。用于综合的行为必须自然是可综合的。

Xilinx 具体说明

• 通常核心生成器模型是预综合 .vhd 文件

结构：

一般定义

• 仅实例化组件并将它们连接在一起（分层）。
• 模拟比行为慢。
• 顶层没有真正的信号行为定义。
• 只有可综合的代码。

Xilinx x 具体说明

• 核心生成器模型不考虑时间。
• 通常，核心生成器模型会实例化综合后网表

以上基本上是传统的主要建筑的两种动物。非常常见的是使用“混合”定义，其中包含两者的属性。

右转：

RTL 在一天结束时实际放在 FPGA 上的内容。因此，这是定义系统行为的可综合代码，由代码层次结构组成：
底层将是可综合的行为，其中定义了信号行为的本质，​​而上层将是结构化的，其中如果你愿意的话，行为组件被捆绑在一起以创建一个大的顶级“框图”。

关于多种架构：

架构可以全部在一个文件中，也可以在多个文件中。唯一重要的是首先编译实体，并指定要使用的体系结构。

这本书非常方便，并且很好地详细说明了这种事情。

就拥有不同的行为和结构模型或只是混合它们而言，应该如何做事情并没有硬性规定。通常在大型固件设计中（或在共享和重用代码的大公司中）区分两者以简化问题很有用，但归根结底，它归结为适合您的任何东西。

查看一个实体，如何在没有架构名称提示的情况下确定正在使用的实际架构模型？

您不能 - 当它被实例化或配置时，可以指定架构（如果有多个可供选择），或者将为您选择默认值。

如果为单个实体指定多个体系结构（我理解这是可能的），您是否只是在同一个文件中给体系结构不同的名称或......？

你给他们不同的名字。它不必在同一个文件中（事实上，VHDL 关心的比你想象的文件中的内容要少得多）

架构名称是否仅限于给定实体（也就是说，通过在多个实体上使用相同的架构名称是否存在“命名空间”问题）？

它们被“附加”到一个实体上，因此可以重复使用。

我经常将a1所有可合成的东西用作我的架构

• rtl意味着（对许多读者而言）比我写的要低。
• behavioural通常意味着不可综合（对某些读者而言）
• synth被合成器用作它的模型（否则我会使用它）

a1到目前为止没有冲突，不会引起混淆；）

如果我实际上有多个架构，我倾向于详细地命名它们（例如hard_multipliers，lut_multipliers对于实例化或不实例化 MUL18 块的过滤器）。

很多时候你只有一种架构，所以没关系。好的实体名称更为重要。

RTL 和行为之间似乎存在区别，但如上所述，我在我见过的示例中并没有真正看到它（通常我只看到一个架构被定义）。一种架构比其他架构更常见吗？

这是历史性的——你以前不能综合“行为”代码（其中曾经包括像加法这样的东西！）——所以你创建了一个 RTL 版本，它实例化了加法器等。（据我所知——自从我在 1999 年左右开始使用 VHDLing 以来，我一直在编写行为（但仍然是可合成的）代码！）

首先，现实世界的架构设计不能这样严格分类。为什么要限制自己？您可能想要实例化其他实体并“结构化地”连接它们，但是在这里和那里添加一个过程或并发分配以添加一些“rtl”逻辑，并且可能使用一些“行为”编码模式，以便合成器找出一些您不关心的细节（例如在没有专门实例化具有区域/流水线/性能参数的加法器的情况下添加），所有这些都在同一个架构中。

更重要的是，您必须了解在当前的 asic/fpga 技术中什么是可合成的，什么不是，这与架构模型无关。

一个实体可以以多种方式实现，甚至允许略有不同的行为，因此您可能对同一个实体有多种架构。此外，您可能有一个仅用于仿真的架构（通常是不可综合的），它的仿真速度可能比“真实”版本更快，这在对整个大型设计进行测试时可能会派上用场。你会给这些架构命名，以帮助你记住是什么让它们与其他架构不同，鉴于现实世界设计的混合性质，简单的 bhv/str/rtl 通常是不够的或不准确的。

关于您的具体问题，体系结构声明与实体名称相关联，因此不同实体的同名体系结构不存在命名空间问题。只需为同一实体的架构使用不同的名称。

架构可以驻留在不同的文件中，您只需要确保首先编译实体声明。

您可以在实例化实体或使用配置语句时选择要使用的架构。如果您不这样做，则默认值“通常”是编译器为给定实体声明看到的最后一个架构。