如何从综合报告中推导出结论

Question

我使用Xilinx用VHDL编写了80c51体系结构。为了增加时钟频率，我对所有80c51指令进行了流水线处理。例如，在处理第一个指令时，第二个指令被获取。

然而，尽管我创建了3个流水线深度，但合成报告显示时钟频率只略有变高（大约+/-10Hz）。我发现瓶颈是由合成报告中指定的一个操作引起的，但是我无法理解合成报告。

我想问一下，“SEQ/decode_3到SEQ/i_ram_addr_7”的数据路径试图做什么？ （根据我的猜测，我推断使用了case和when语句来检查100多个相关操作码，但不确定是否是瓶颈。但我毫无头绪）

因此，我唯一的两个问题是：

首先，流水线处理是否可能不会增加时钟频率，而测试台是解释时间减少的唯一方法？

其次，我如何推断代码中从“SEQ/decode_3到SEQ/i_ram_addr_7”哪条路径是瓶颈？

感谢能帮助解答我的疑惑的任何人！

Timing Summary:
---------------
Speed Grade: -4

   Minimum period: 12.542ns (Maximum Frequency: 79.730MHz)
   Minimum input arrival time before clock: 10.501ns
   Maximum output required time after clock: 5.698ns
   Maximum combinational path delay: No path found

Timing Detail:
--------------
All values displayed in nanoseconds (ns)

=========================================================================
Timing constraint: Default period analysis for Clock 'clk'
  Clock period: 12.542ns (frequency: 79.730MHz)
  Total number of paths / destination ports: 113114 / 2670
-------------------------------------------------------------------------
Delay:               12.542ns (Levels of Logic = 10)
  Source:            SEQ/decode_3 (FF)
  Destination:       SEQ/i_ram_addr_7 (FF)
  Source Clock:      clk rising
  Destination Clock: clk rising

  Data Path: SEQ/decode_3 to SEQ/i_ram_addr_7
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     FDC:C->Q            102   0.591   1.364  SEQ/decode_3 (SEQ/decode_3)
     LUT4_D:I1->O         10   0.643   0.885  SEQ/de_state_cmp_eq002111 (N314)
     LUT4:I3->O            7   0.648   0.740  SEQ/de_state_cmp_eq00711 (SEQ/de_state_cmp_eq0071)
     LUT4:I2->O            3   0.648   0.534  SEQ/i_ram_addr_mux0000<0>11111 (N2301)
     LUT4:I3->O            1   0.648   0.000  SEQ/i_ram_addr_mux0000<0>11270_SW0_SW0_F (N1284)
     MUXF5:I0->O           1   0.276   0.423  SEQ/i_ram_addr_mux0000<0>11270_SW0_SW0 (N955)
     LUT4_D:I3->O          6   0.648   0.701  SEQ/i_ram_addr_mux0000<0>11270 (SEQ/i_ram_addr_mux0000<0>11270)
     LUT3_L:I2->LO         1   0.648   0.103  SEQ/i_ram_addr_mux0000<7>221_SW2_SW0 (N1208)
     LUT4:I3->O            1   0.648   0.423  SEQ/i_ram_addr_mux0000<7>351_SW1 (N1085)
     LUT4:I3->O            1   0.648   0.423  SEQ/i_ram_addr_mux0000<7>2 (SEQ/i_ram_addr_mux0000<7>2)
     LUT4:I3->O            1   0.648   0.000  SEQ/i_ram_addr_mux0000<7>167 (SEQ/i_ram_addr_mux0000<7>)
     FDE:D                     0.252          SEQ/i_ram_addr_7
    ----------------------------------------
    Total                     12.542ns (6.946ns logic, 5.596ns route)
                                       (55.4% logic, 44.6% route)

=========================================================================
Timing constraint: Default OFFSET IN BEFORE for Clock 'clk'
  Total number of paths / destination ports: 154 / 154
-------------------------------------------------------------------------
Offset:              8.946ns (Levels of Logic = 6)
  Source:            rst (PAD)
  Destination:       SEQ/i_ram_diByte_1 (FF)
  Destination Clock: clk rising

  Data Path: rst to SEQ/i_ram_diByte_1
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     IBUF:I->O           444   0.849   1.392  rst_IBUF (REG/ext_int/fd_out1_0__or0000)
     BUF:I->O            445   0.648   1.425  rst_IBUF_1 (rst_IBUF_1)
     LUT3:I2->O            4   0.648   0.730  ROM/data<1>1 (i_rom_data<1>)
     LUT4:I0->O            1   0.648   0.500  SEQ/i_ram_diByte_mux0000<1>17_SW0 (N1262)
     LUT4:I1->O            1   0.643   0.563  SEQ/i_ram_diByte_mux0000<1>32 (SEQ/i_ram_diByte_mux0000<1>32)
     LUT4:I0->O            1   0.648   0.000  SEQ/i_ram_diByte_mux0000<1>60 (SEQ/i_ram_diByte_mux0000<1>)
     FDE:D                     0.252          SEQ/i_ram_diByte_1
    ----------------------------------------
    Total                      8.946ns (4.336ns logic, 4.610ns route)
                                       (48.5% logic, 51.5% route)

=========================================================================

---

为了更加具体，我将给出一个1操作码解码阶段示例代码片段。

以下是编码mov指令的1种情况。大约有100个操作码（100个指令），这意味着该case语句有100多个when语句。

case OPCODE is

--MOV A, Rn
when "11101000" | "11101001" | "11101010" | "11101011" | "11101100" | "11101101" | "11101110" | "11101111" => case de_state is when E7 =>

              de_state <= E8;

          when E8 =>


              de_state <= E9;

          when E9 =>


              de_state <= E10;
          when E10 =>
              --Draw PSW
              i_ram_addr <= xD0;
              i_ram_rdByte <= '1';

              de_state <= E11;
          when E11 =>
              --Draw from Rn
              i_ram_addr <= "000" & i_ram_doByte(4 downto 3)& opcode(2 downto 0);
              i_ram_rdByte <= '1';

              de_state <= E12;

          when E12 =>
              --Place into EDR
              EDR <= i_ram_doByte;
              --close rdByte
              i_ram_rdByte <= '0';

          when others =>

          end case;

我希望你能更好地理解我的 VHDL 代码。感谢任何形式的帮助。谢谢！

- Ice

Answer 1

仅凭这些信息，我们无法得出好的答案；我们只能猜测是什么源代码导致了这个硬件。

但很明显，您需要检查源代码，假设为什么它运行缓慢，采取措施纠正问题，并测试解决方案。

并且重复此过程，直到速度足够快。

根据您暗示有一个用于解码操作码的情况语句，我的猜测是其中一个分支可能是：

when <some expression involving decode>  =>
   address <= <some address calculation>;

问题在于，这两个表达式通常是相互关联的，以便在同一个周期内进行评估。一个示例解决方案是将地址表达式预计算（即在上一个周期），并将 case 分支重写为：

when <some expression involving decode>  =>
   address <= register;

如果你猜对了，结果会稍微快一些，并且你需要修复另一个（类似的）瓶颈。重复这个过程，直到达到足够快的速度...

但是，没有源代码和计时分析，不要期望得到更具体的答案。

编辑：发布了部分源代码后，情况变得更清晰了： 你有两个嵌套的Case语句，每个都相当大。显然，你需要进行一些简化...

我注意到只有内部case部分中的2个赋值给i_ram_addr，然而计时分析显示了一个巨大而复杂的mux在i_ram_addr上；显然还有很多其他的case部分为i_ram_addr贡献项...

我建议你可能需要单独处理i_ram_addr，并编写最简单的机器来生成i_ram_addr。 例如，我会注意到OPCODE case arm相当于：

if OPCODE(7 downto 3) = "11101" then ...

问一下如何获得仅针对 i_ram_addr 的解码器，简化逻辑。您可能会发现许多其他情况与 i_ram_addr 做类似的事情（原始的 8051 设计师会抓住简化逻辑的机会！）。合成工具在简化逻辑方面可以非常聪明，但当事情变得过于复杂时，它们可能会错过机会。

（在这个阶段，我会注释掉 i_ram_addr 的赋值，并保持其余解码器不变）

- user1818839

Answer 2

由于您正在使用Xilinx，我假设您也可以访问PlanAhead？请尝试“分析时序/平面图设计（PlanAhead）”（在“实现设计”->“放置和路由”下）。

PlanAhead应该会打开，并在底部给出您的时序结果视图。选择关键路径（最少松弛度的路径），右键单击它并选择“原理图”，这将呈现所涉及基元的图形视图。然后，您可以右键单击基元并选择“展开锥形”->“到Flops”以查看周围组件的视图。

这应该有助于您更好地了解所涉及的信号。尝试跟踪输入和输出信号到您的VHDL代码，并专注于该路径进行优化。

- sonicwave

---

谢谢您的回复，sonicwave。我已经打开了Place & Route -> PlanAhead。然而，在PlanAhead底部，我找不到时序结果视图，可能默认情况下该选项卡不存在。请问如何在PlanAhead中检索时序结果视图？谢谢！ - Ice

在我的版本中，默认情况下会显示出来 - 但请尝试使用Tools->Timing->Report Timing in PlanAhead，看看是否有帮助。当显示路径的原理图时，路径两端的触发器（应该）对应于设计中的信号名称。在代码中寻找最右侧触发器信号的分配位置，其中值取决于最左侧触发器信号，并尝试从那里开始优化。 - sonicwave