整数在合成中很好，我一直在使用它们。

我在顶级端口使用std_logic，但在内部我到处都使用范围整数

没关系！

意识到：

• 您首先进行模拟不是吗:) - 整数类型不会在模拟中自动“翻转” - 超出您为它们指定的范围是错误的。如果您想要翻转行为，则必须对其进行显式编码。
• 它们仅指定从 \$-(2^{31}-1)\$ 到 \$+2^{31}-1\$ （即不是 32 位整数的完整范围，您可以'不要使用 \$-2^{31}\$ 并保持便携），这有时会有点痛苦。如果您需要使用“大”数字，则必须使用unsignedand signed。
• 如果你不限制它们，你有时会得到 32 位计数器，而 less 会做（如果合成器和后续工具不能“看到”它们可以优化位）。

好的一面是：

• 它们比无符号/有符号向量的模拟要快得多
• 它们不会在模拟中自动翻转（是的，它在两个列表中:)。这很方便 - 例如，您会收到早期警告，提示您的计数器太小。

当您使用矢量类型时，您正在使用ieee.numeric_std，不是ieee.std_logic_arith吗？

我integer尽可能使用 s，但如果我明确想要“翻转 n 位计数器”，我倾向于使用unsigned.

Jan Decaluwe 写了整篇关于整数与位向量问题的白皮书。我希望他的答案是尽可能使用整数。 http://www.jandecaluwe.com/hdldesign/counting.html

将整数用于 RTL本身并没有错，但有些人会避免使用整数。这确实是一个关于主观“最佳实践”的问题，您最终必须找出自己喜欢什么。作为对此的帮助，我将分享我对此的经验和想法。

原则上，我赞成使用（受约束的）整数，在编写综合时也是如此。我有时会这样做，但在实践中，我通常坚持signedand unsigned。我会详细说明原因。

无论如何，您将被迫在部分设计中使用矢量化数据类型：

• 几乎没有任何供应商 IP 或第 3 方 IP 将使用integer类型作为端口

• 例如，当通过 BlockRam 发送数据时，即使您推断它并且因此不需要与任何 IP/宏/原语接口，您很可能仍然需要转换为矢量化类型

• 即使以上都不适用，您在某些时候大多需要与其他东西（顶级端口，如果没有别的）接口

由于您不能使用integer完整的设计，您可能想一起跳过它，因为：

• 在某些时候，无论如何您都需要进行转换，这integer首先消除了使用的部分意义

• 此外，对于模拟，这些转换通常会在重置之前或在其他时间使用'U'or的向量调用'X'，并且每个此类函数调用都会从包函数中生成警告消息，从而使您的模拟警告/提示变得混乱

使用的缺点integer：

• 与矢量化类型相反，整数没有'U'and 'X'; 我发现这些对模拟非常有帮助。您会看到未初始化的信号如何在设计中传播，如果您在复位后看到大量未初始化的信号，您可能会做出反应。如果使用整数，情况就不会如此。

• 对于整数，在加法或减法时模拟/综合不匹配的风险更大，导致下溢/溢出。（正如其他人已经指出的那样。）

integer我发现确实是一个不错的选择的典型案例：

• 对于您通过chipScope/signalTap等监控的调试信号/计数器。

• 计数器的完全内部表示，永远不会进入或退出您自己的代码。是的，有这样的情况，例如，如果您正在编写一个 FIFO，并且您正在对写入/读取进行航位推算以形成信号full，empty等等almostFull（但是在这种情况下，指针上的算术比航位推算更好。 ..)

我自己的结论：我有时确实使用整数，但很少使用，主要是在上述情况下。我认为使用unsignedandsigned而不是整数的开销并不大，因此通常坚持使用它们。