Скоротіть затримку з розумінням звіту Xilinx Synthesis

Я програмую набір інструкцій 8051 у VHDL у Xilinx. Після написання логіки та генерації звіту синтезу я побачив, що затримка 13.330ns (частота 75.020 МГц) з рівнями логіки = 10.

Це значення набагато менш (частота), і мені потрібно це зробити, але я не можу зрозуміти, що/де затримка використовується узагальнюючий звіт.

Це частина доповіді, яка говорить про терміни:

=========================================================================
Timing constraint: Default period analysis for Clock 'clk_div1'
  Clock period: 13.330ns (frequency: 75.020MHz)
  Total number of paths/destination ports: 156134/3086
-------------------------------------------------------------------------
Delay:               13.330ns (Levels of Logic = 10)
  Source:            SEQ/alu_op_code_1 (FF)
  Destination:       SEQ/alu_src_2L_7 (FF)
  Source Clock:      clk_div1 rising
  Destination Clock: clk_div1 rising

  Data Path: SEQ/alu_op_code_1 to SEQ/alu_src_2L_7
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     FDE:C->Q             40   0.591   1.345  SEQ/alu_op_code_1 (SEQ/alu_op_code_1)
     LUT4:I1->O            2   0.643   0.527  ALU1/ci32_SW0 (N2251)
     LUT4:I1->O            1   0.643   0.000  ALU1/adder_comp/C11_F (N1292)
     MUXF5:I0->O           3   0.276   0.531  ALU1/adder_comp/C11 (ALU1/adder_comp/C1)
     MUXF5:S->O           12   0.756   0.964  ALU1/adder_comp/C21 (ALU1/adder_comp/C2)
     LUT4:I3->O            8   0.648   0.760  ALU1/ans_L<5>104 (ALU1/ans_L<5>104)
     LUT4:I3->O           17   0.648   1.054  ALU1/ans_L<7>95_SW0 (N264)
     LUT4:I3->O            1   0.648   0.000  SEQ/alu_src_2H_and000055_SW3_F (N1304)
     MUXF5:I0->O           1   0.276   0.423  SEQ/alu_src_2H_and000055_SW3 (N599)
     LUT4_D:I3->O         15   0.648   1.049  SEQ/alu_src_2L_mux0005<7>121228 (N285)
     LUT4:I2->O            1   0.648   0.000  SEQ/alu_src_2H_mux0007<6> (SEQ/alu_src_2H_mux0007<6>)
     FDE:D                     0.252          SEQ/alu_src_2H_1
    ----------------------------------------
    Total                     13.330ns (6.677ns logic, 6.653ns route)
                                       (50.1% logic, 49.9% route)

Чи може хтось пояснити, що відбувається?

4
Які у вас часові обмеження?
додано Автор user597225, джерело

3 Відповіді

Декілька визначень:

  • Затримка воріт: для введення викликати зміни на виході блоку
  • Чиста затримка: час для отримання сигналу для наступного блоку

13.33ns складається з двох частин. 6.677ns затримки Gate і 6.653ns Net затримки

Головним чинником затримки воріт є те, наскільки складна функція міститься в конусі логіки. Головним чинником чистої затримки є те, скільки речей керуються сигналами.

Кожен рядок у звіті говорить про один логічний блок. Таким чином, перша рядок alu_op_code_1 зареєстрована, і час, який він бере від C-шпильки (Clk), до Q-шпильки (вихід). У фанатному стовпці вказано, скільки логічних блоків приводів Q-шпильки. У цьому випадку це 40, тому мережева затримка досить висока. Цілком зрозуміло, що для звичайно використовуваного регістру, наприклад, коду операційної системи ALU, є високий підсилювач.

Ми також можемо розглянути шлях в цілому і побачити, що він виходить з коду операцій в SEQ, в ALU. через суматор, повертається до блоку SEQ і, врешті-решт, перетворюється в інший регістр під назвою alu_src_2H_1. Що це шлях, я не можу тобі сказати. Це може зробити лише хтось із джерелом, і тоді це є прикладом спроби з'ясувати, яка логіка знаходиться між цими двома регістрами.

Те, що я трохи заплутаюсь, полягає в тому, що цей шлях виглядає таким, що він відповідає часу (13.33ns - це ціль), але ви кажете, що вам потрібно "покращити його". Чому?

3
додано
Немає взаємних відносин, але певні імена у звіті відповідають вашим джерелам. Зазвичай це початкова точка, кінцева точка та імена блоків, які ви пропускаєте. Це схоже на пошук асемблера з компілятора C. Деякі назви співпадають, інші створюються компілятором.
додано Автор Paul S, джерело
У мене є вихідний код. Я намагаюся запитати, що, розглядаючи зведений звіт, чи можна мені дізнатись, яка частина мого коду є повільною (іншими словами, де найбільша затримка), щоб я міг працювати над цим і збільшити частота
додано Автор Saurabh, джерело

Перегляньте імена у звіті та порівняйте їх із вихідним кодом.

В принципі, ви маєте лише комбінаційну логіку, що протікає в екземплярі "SEQ" з коду ALU op до вихідного сигналу ALU "alu_src_2L":

Джерело: SEQ/alu_op_code_1 (FF)   Місце призначення: SEQ/alu_src_2L_7 (FF)

Дивлячись на деталі, ви можете побачити, що на цьому конкретному шляху більшу частину часу використовується у вашому ALU "ALU1", і саме в логіці суматор/порівняння "adder_comp". Якщо ви хочете мати меншу затримку в цьому шляху, вам доведеться або оптимізувати логіку, так і скоротити шлях з іншим реєстром (і зробити інший дизайн ще працювати з цією зміною).

3
додано

По-перше, при написанні HDL або адаптації HDL для FPGA, це дійсно коштує зрозуміти ваші конкретні можливості та обмеження FPGA. Xilinx робить відмінну роботу, що документує кожну модель FPGA. Дивлячись на блоки LUT4 та MUXF5, ваша сім'я FPGA може бути Spartan 3? Вивчаючи таблиці, ви можете побачити, які апаратні конструкції дуже ефективні для реалізації і які потребують більшої кількості ресурсів. Взагалі, чим ближче апаратна карта до того, що насправді на чіпі, тим швидше вона буде виконуватись і менша площа, яку вона буде займати.

Наприклад, Xilinx LUT також може використовуватися як регістр зсуву, тобто вам не потрібно використовувати фліпфлоп у фрагменті. Це призведе до дуже помітного поліпшення, якщо ви переконаєтеся, що ваші регіонами зсуву прив'язані до LUT. XST намагається максимально ефективно використовувати ваш HDL, щоб визначити ці ефективні відображення, але часто існують дурні речі, які заважають цим ефективним відображенням, наприклад, сигнал включення, який перевіряється перед сигналом скидання. Переконайтеся, що ви вивчаєте висновок синтезатора, а також місце та маршрут, щоб знайти випадки, коли ви можете покращити відображення на вашому FPGA. Документація Xilinx наводить приклади VHDL та Verilog, які XST може використовувати для виведення більш ефективних компонентів. Іноді часто простіше просто просто інсталювати компонент безпосередньо. І для складних компонентів - це UNIMACRO і майстер COREGEN, які виробляють дуже ефективне обладнання.

Для крайнього прикладу, спеціально написаний мікроконтроллер PicoBlaze для використання архітектур Xilinx FPGA. Можливо, було б корисно вивчити вихідний код PicoBlaze, щоб побачити приклади цього ефективного відображення.

По-друге, якщо ваш комбінаційний логічний шлях занадто довгий, він обмежуватиме вашу максимальну тактову частоту. Крім перезапису вашого коду, щоб краще покращити його на FPGA або переписати, щоб усунути непотрібні апаратні ресурси, ви також можете вставити фліп-флоп (регістри) десь посередині вашого комбінаційного логічного ланцюга. В архітектурі комп'ютера це називається конвеєрним процесом і збільшить кількість циклів за інструкцією. Наприклад, PicoBlaze використовує два цикли для кожної інструкції. Intel Pentium 4 мав близько 17 циклів за інструкцією. Якщо ви розумні, тоді ви можете написати свій ЛПВЩ таким чином, що ви починаєте обробку однієї інструкції, одночасно закінчуючи обробку останньої інструкції. Це означає, що для кожної інструкції (латентності) все одно буде потрібно 2 тактові цикли, однак ви зможете вийти з однієї інструкції на цикл (пропускна спроможність). Більшість мікроконтролерів, таких як 8051 і PicoBlaze, стосуються латентності, і більшість мікропроцесорів, таких як архітектура x86, стосуються пропускної спроможності.

1
додано