VHDL：架构命名和解释

注意：我使用的是Xilinx的ISE，并且具有可与之配合工作的FPGA板（带有开关和指示灯等），到目前为止，我已经整理了一些简单的项目。同时，我正在阅读一些教程，以为自己的工作打下基础。

我已经看过参考资料中提到的各种实体及其体系结构，但是命名常常令人困惑。通常，而不是“建筑RTL的。”或“建筑结构的...”我会看到“架构富的......”，甚至“建筑拱形的......”

我意识到（迟来地）架构名称与实体命名一样任意，尽管有样式指南建议可以使用更一致的命名约定来避免此问题。这使我想到了几个问题：

• 看一个实体，如何在没有架构名称提示的情况下确定正在使用的实际架构模型？RTL，行为，结构……它们看起来与我的学习者的眼睛非常相似（假设我所看到的示例实际上是正确命名的）。一个简单但显而易见的示例将在这里有所帮助（或指向一个示例）。

• 如果为单个实体指定多个架构（据我所知是可能的），您是否只是在同一文件中为架构指定了不同的名称或...？

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

编辑：还有一个：

• 看起来RTL和行为之间是有区别的，但是如上所述，我在所看到的示例中并没有真正看到它（通常我只看到一种定义的体系结构）。一种架构比其他架构更常见吗？

我一直在寻找的是一个全面而又简单的多组件项目（小组件），使用最佳实践（正确的命名，并非全部都塞入一个文件等）编写，但是我还没有找到。我发现精心制作的示例项目对于阐明基本原理和最佳实践非常有用。如果您知道这样的示例项目，我也将感谢您提供指向该示例项目的指针。（如果没有别的，也许一旦我弄清楚了，我就可以分享自己的一个...）

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

您不能-在实例化或配置架构时，可以指定架构（如果要选择的架构不止一种），或者将为您选择默认架构。

如果为单个实体指定多个架构（据我所知是可能的），您是否只是在同一文件中为架构指定了不同的名称或...？

您给他们起不同的名字。它不必位于同一文件中（实际上，VHDL关心的程度远小于您可能想到的文件中的内容）

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

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

我经常将a1所有可综合的内容用作架构

• rtl 对许多读者而言，这意味着比我撰写本文时要低的水平。
• behavioural 通常对某些读者来说是不可合成的
• synth 由合成器用于其模型（否则我将使用该模型）

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

如果我实际上有一个以上的体系结构，我倾向于用冗长的名称命名它们（例如hard_multipliers，lut_multipliers对于实例化（或不实例化）MUL18块的过滤器）。

通常，您只有一种架构，所以没关系。好的实体名称更为重要。

看起来RTL和行为之间是有区别的，但是如上所述，我在所看到的示例中并没有真正看到它（通常我只看到一种定义的体系结构）。一种架构比其他架构更常见吗？

这是历史悠久的-您以前不能合成“行为”代码（在某一时刻包括加法！），因此您创建了一个RTL版本，该实例化加法器等。（据我所知-自从大约1999年开始VHDLing以来，我一直在编写行为（但仍可综合）代码！）

以下是架构类型：

行为的：

一般注意事项：

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

Xilinx具体说明

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

结构：

一般定义

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

Xilinx Xpecific笔记

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

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

RTL：

RTL最终在FPGA上实际放置了什么。因此，这是定义系统行为的可综合代码，由代码层次结构组成：
底层是可综合行为，其中定义了信号行为的本质，​​高层是结构性的，其中如果可以的话，将行为组件捆绑在一起以创建一个大型的顶层“框图”。

到多种架构：

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

这本书非常方便，并且很好地详细介绍了这类内容。

关于如何通过具有独特的行为和结构模型或仅将它们混合在一起来完成事情，没有硬性规定。通常，在大型固件设计中（或在共享和重用代码的大公司中），区分两者以简化事务很有用，但是归根结底，这取决于您的工作。

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

更重要的是，您必须了解在当前的asic / fpga技术中可合成的内容以及不可合成的东西，而这与体系结构模型无关。

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

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

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

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