Как сделать вывод из сводного отчета

Я закодировал архитектуру 80c51 на VHDL, используя xilinx. Пытаясь увеличить тактовую частоту, я конвейеризировал все инструкции 80c51. Инструкции удалось выполнить по желанию, например. когда обрабатывается 1-я инструкция, извлекается вторая инструкция.

Тем не менее, я получаю только немного более высокую тактовую частоту (около +/- 10 Гц), несмотря на создание глубины конвейера 3, из отчета о синтезе. Я понял, что узкое место связано с одной операцией, указанной в сводном отчете, но я не мог понять сводного отчета.

Могу я спросить, что пытается сделать путь данных от «SEQ/decode_3 до SEQ/i_ram_addr_7»? (Из моего предположения я делаю вывод, что используется случай, когда оператор проверяет более 100 соответствующих кодов операций, но не уверен, что это узкое место. Но я не знаю)

Следовательно, мои единственные 2 запроса:

Во-первых, возможно ли, что конвейерная обработка не увеличивает тактовую частоту, а тестбенч — единственный способ объяснить снижение таймингов?

Во-вторых, как я мог определить, какой путь в моем коде является узким местом от «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 кода операции.

Ниже приведен 1 такой случай при декодировании кода операции, который является инструкцией mov. Существует около 100+ опкодов (100+ инструкций), что означает, что в этом операторе case более 100 операторов when.

случай OPCODE

--MOV A, Rn
, когда "11101000" | "11101001" | "11101010" | "11101011" | "11101100" | "11101101" | "11101110" | "11101111" => case de_state - это когда 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. Я был бы признателен за любую форму помощи. Благодарю вас!


person Ice    schedule 13.11.2012    source источник


Ответы (2)


Поскольку вы используете Xilinx, я полагаю, у вас также есть доступ к PlanAhead? Попробуйте «Анализ сроков/дизайн плана этажа (PlanAhead)» (в разделе «Реализация проекта» -> «Место и маршрут»).

PlanAhead должен открыться и дать вам представление о результатах времени внизу. Выберите критический путь (тот, который имеет наименьший запас), щелкните его правой кнопкой мыши и выберите «Схема», чтобы открыть графическое представление задействованных примитивов. Затем вы можете щелкнуть правой кнопкой мыши примитивы и выбрать «Расширить конус» -> «На флопы», чтобы также увидеть окружающие компоненты.

Это должно помочь вам лучше понять, какие сигналы задействованы. Попробуйте проследить входные и выходные сигналы до кода VHDL и сосредоточьтесь на этом пути для оптимизации.

person sonicwave    schedule 13.11.2012
comment
Спасибо за ответ, sonicwave. Я открыл место и маршрут -> PlanAhead. Однако я не смог найти представление результатов хронометража в нижней части PlanAhead, вероятно, этой вкладки нет по умолчанию. Могу я спросить, как мне получить представление о результатах хронометража в PlanAhead? Благодарю вас! - person Ice; 13.11.2012
comment
В моей версии он отображается по умолчанию, но попробуйте «Инструменты» -> «Время» -> «Время отчета» в PlanAhead и посмотрите, поможет ли это вам. При отображении схемы пути флопы на каждом конце пути (должны) соответствовать именам сигналов в вашем проекте. Найдите в своем коде назначения самого правого сигнала триггера, где значение зависит от самого левого сигнала триггера, и попробуйте начать оптимизацию с него. - person sonicwave; 14.11.2012

Только из этой информации хороших ответов не будет; мы можем только догадываться, какой исходный код создал это оборудование.

Но понятно, что нужно изучить источник, выдвинуть гипотезу, почему он тормозит, принять меры по исправлению проблемы и протестировать решение.

И повторять до тех пор, пока достаточно быстро.

Мое предположение, учитывая ваш намек на то, что есть оператор case для декодирования кодов операций...

одна из рук что-то вроде:

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

Проблема в том, что часто два выражения взаимосвязаны, поэтому они оцениваются в одном и том же цикле. Примером решения может быть предварительное вычисление адресного выражения (т. е. в предыдущем цикле) в регистре и переписывание ветви case как:

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

Если вы угадали, результат будет немного быстрее, и вам нужно исправить еще одно (похожее) узкое место. Повторяйте до тех пор, пока достаточно быстро...

Но без источника И временного анализа не ждите более конкретного ответа.

РЕДАКТИРОВАТЬ: опубликовав часть исходного кода, картина стала немного яснее: у вас есть два вложенных оператора Case, каждый из которых довольно большой. Вам явно нужно упрощение...

Я отмечаю, что только 2 из внутренних ветвей корпуса назначены на i_ram_addr, однако временной анализ показывает огромный и сложный мультиплексор на i_ram_addr; ясно, что есть много других ветвей case, которые вносят свой вклад в i_ram_addr...

Я бы посоветовал вам обрабатывать i_ram_addr отдельно от основного оператора Case и написать самую простую машину, которую вы можете генерировать только для i_ram_addr. Например, я хотел бы отметить, что рука case OPCODE эквивалентна:

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

и спросите, как просто вы можете получить декодер только для i_ram_addr. Вы можете обнаружить, что многие другие руки case делают очень похожие вещи с i_ram_addr (первоначальные разработчики 8051 ухватились бы за возможность упростить логику!). Инструменты синтеза могут быть весьма умны в упрощении логики, но когда все становится слишком сложным, они могут упустить возможности.

(На этом этапе я бы закомментировал назначения i_ram_addr и оставил остальную часть декодера в покое)

person user_1818839    schedule 13.11.2012