实施 FOR-LOOP 和 FOR-GENERATE 之间的实际区别是什么?什么时候使用一个比另一个更好?

What is the practical difference between implementing FOR-LOOP and FOR-GENERATE? When is it better to use one over the other?

假设我必须在 std_logic_vector 上测试不同的位。是实现一个单独的进程,为每个位进行 for 循环,还是使用 for-generate 实例化 'n' 个进程,每个进程测试一位?

会更好吗?

FOR 循环

my_process: process(clk, reset) begin
  if rising_edge (clk) then
    if reset = '1' then
      --init stuff
    else
      for_loop: for i in 0 to n loop
        test_array_bit(i);
      end loop;
    end if;      
  end if; 
end process;

生成

for_generate: for i in 0 to n generate begin
my_process: process(clk, reset) begin
  if rising_edge (clk) then
    if reset = '1' then
      --init stuff
    else
      test_array_bit(i);
    end if;
  end if; 
end process;
end generate;

这种情况对 FPGA 和 ASIC 实施有何影响? CAD工具容易处理什么?

编辑: 只是添加我给一个帮助者的回复,使我的问题更清楚:

例如,当我 运行 一段代码在 ISE 上使用 for 循环时,综合摘要给了我一个公平的结果,花了很长时间来计算所有内容。当我重新编码我的设计时,这次使用 for-generate 和几个进程,我使用了更多的区域,但该工具能够更快地计算所有东西,我的计时结果也更好。那么,这是否暗示了一条规则,即使用 for-generates 总是更好,代价是额外的面积和更低的复杂性,或者这是我必须验证每一个实现可能性的情况之一?

第一个片段相当于以下内容:

my_process: process(clk, reset) begin
  if rising_edge (clk) then
    if reset = '1' then
      --init stuff
    else
      test_array_bit(0);
      test_array_bit(1);
      ............
      test_array_bit(n);
    end if;      
  end if; 
end process;

而第二个将为每个 i 生成 n+1 进程 ,连同重置逻辑和所有内容(这可能是一个问题逻辑将尝试驱动来自不同进程的相同信号)。
通常,for 循环是顺序语句,包含顺序语句(即每次迭代都按顺序在前一次之后执行)。 for-generate 循环是并发语句,包含并发语句,例如,这就是您如何使用它来创建一个组件的多个实例。

假设复位和测试函数中的逻辑相对简单(例如,相邻位之间没有交互),我希望两者生成相同的逻辑。

了解由于整个 for 循环在单个时钟周期内执行,综合将展开它并为每个输入位生成一个单独的 test_array_bit 实例。因此,综合工具很有可能为两个版本生成相同的逻辑 - 至少在这个简单的例子中是这样。

在此基础上,我(略微)更喜欢 for ... loop 版本,因为它本地化了程序逻辑,而 "generate" 版本将其全球化,将其置于 process 之外样板。如果您发现 loop 版本更容易阅读,那么您会在某种程度上同意。

然而,教条式的风格并不值得,您的实验说明了这一点:loop 综合到劣质硬件。综合工具是复杂且不完美的软件,例如高度优化的编译器,并且存在许多相同的问题。有时他们错过了 "obvious" 优化,有时他们进行了复杂的优化(例如在软件中)运行速度变慢,因为它增加的大小破坏了缓存。

因此,最好尽可能以最简洁的风格编写,但要有一定的灵活性来解决工具限制和偶尔出现的真实工具缺陷。

不同版本的工具会消除(偶尔会引入)此类缺陷。您可能会发现 ISE 的 "use new parser" 选项(对于 Spartan-6 之前的部件)或 Vivado 或 Synplicity 可以做到这一点,而 ISE 的旧解析器则不能。 (例如,从过程中传递信号,旧的 ISE 版本有严重的错误)。

修改示例并查看综合是否可以"get it right"(产生相同的硬件)最简单的情况,并重新引入复杂性,直到您发现哪个构造失败,这可能是有益的。

如果您通过这种方式发现了一些具体的东西,那么值得在此报告(通过回答您自己的问题)。 Xilinx 过去鼓励通过其 Webcase 系统报告此类缺陷;最终他们甚至被修复了!然而,在过去的一两年里,他们似乎已经停止了。