Уменьшите задержку, понимая отчет Синтеза Xilinx
Я программирую набор команд 8051 в VHDL в Xilinx. После написания логики и генерации сводного отчета я увидел, что задержка составляет 13,330 нс (частота 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)
Может кто-нибудь объяснить, что происходит?
3 ответа
Посмотрите на имена в отчете и сравните с вашим исходным кодом.
По сути, у вас есть только комбинационная логика, передаваемая в экземпляре "SEQ" из кода операции ALU в выходной сигнал ALU "alu_src_2L":
Источник: SEQ/alu_op_code_1 (FF) Назначение: SEQ/alu_src_2L_7 (FF)
Рассматривая детали, вы можете видеть, что в этом конкретном пути большую часть времени используется в вашем ALU "ALU1", а именно в логике сумматора / сравнения "adder_comp". Если вы хотите иметь меньшую задержку на этом пути, вам придется либо оптимизировать логику, либо сократить путь с помощью другого регистра (и заставить остальную часть проекта по-прежнему работать с этим изменением).
Несколько определений:
- Задержка затвора: для входа, чтобы вызвать изменение на выходе блока
- Чистая задержка: время для сигнала, чтобы добраться до следующего блока
13,33 нс состоит из двух частей. Задержка 6,677 нс и задержка 6,653 нс
Основным фактором задержки затвора является то, насколько сложная функция содержится в конусе логики. Основным фактором в чистой задержке является то, сколько вещей управляются сигналами.
Каждая строка в отчете говорит об одном логическом блоке. Итак, первая строка alu_op_code_1 записывается, и время, которое требуется от контакта C (Clk) до контакта Q (выход). В столбце разветвления указано, сколько логических блоков блокирует приводы Q-pin В этом случае это 40, поэтому чистая задержка довольно высока. Вполне понятно, что обычно используемый регистр, такой как код операции ALU, имеет большой размах.
Мы также можем посмотреть на путь в целом и увидеть, что он идет из кода операции в SEQ в ALU. через сумматор обратно в блок SEQ и, в конечном итоге, в другой регистр с именем alu_src_2H_1. Что это за путь, я не могу вам сказать. Только тот, у кого есть источник, может сделать это, и тогда возникает попытка понять, какая логика находится между этими двумя регистрами.
Что меня немного смущает, так это то, что этот путь выглядит так, как будто он соответствует времени (цель - 13,33 нс), но вы говорите, что вам нужно "усилить его". Зачем?
Во-первых, когда вы пишете HDL или адаптируете HDL для FPGA, это действительно окупается, чтобы понять возможности и ограничения вашей конкретной FPGA. Xilinx отлично справляется с документированием каждой модели FPGA. Глядя на блоки LUT4 и MUXF5, ваше семейство FPGA может быть спартанским 3? Изучая таблицы данных, вы можете увидеть, какие аппаратные конструкции очень эффективны для реализации, а какие требуют больше ресурсов. В целом, чем ближе аппаратная часть отображается к тому, что на самом деле находится на чипе, тем быстрее она будет работать и тем меньше будет занимать область.
Например, Xilinx LUT также можно использовать в качестве регистра сдвига, что означает, что вам не нужно использовать триггеры в срезе. Это приводит к очень заметному улучшению, если вы убедитесь, что ваши сдвиговые регистры сопоставлены с LUT. XST старается изо всех сил с вашим HDL выводить эти эффективные сопоставления, но часто существуют глупые вещи, которые мешают этим эффективным сопоставлениям, такие как сигнал разрешения, проверяемый перед сигналом сброса. Убедитесь, что вы изучили выходные данные синтезатора, а также место и маршрут, чтобы определить случаи, когда вы можете улучшить отображение на вашей FPGA. В документации Xilinx приводятся примеры VHDL и Verilog, которые XST может использовать для определения более эффективных компонентов. Иногда часто проще просто создать экземпляр компонента напрямую. А для сложных компонентов есть UNIMACRO и мастер COREGEN, которые производят очень эффективное оборудование.
В качестве крайнего примера, микроконтроллер PicoBlaze был написан специально для использования преимуществ архитектуры Xilinx FPGA. Было бы полезно изучить исходный код PicoBlaze, чтобы увидеть примеры этого эффективного отображения.
Во-вторых, если ваш комбинационный логический путь слишком длинный, он ограничит вашу максимальную тактовую частоту. Помимо переписывания кода, чтобы лучше отобразить его на ПЛИС, или переписывания, чтобы исключить ненужные аппаратные ресурсы, вы также можете вставить триггеры (регистры) где-то в середине вашей комбинации комбинационной логики. В компьютерной архитектуре это называется конвейерной обработкой и приведет к увеличению количества циклов на инструкцию. Например, PicoBlaze использует два цикла на инструкцию. В Intel Pentium 4 было около 17 циклов на инструкцию. Если вы сообразительны, вы можете написать свой HDL так, чтобы начать обработку одной инструкции и одновременно завершить обработку последней инструкции. Это означает, что для выполнения каждой команды (задержки) все равно потребуется 2 такта, но вы сможете удалить одну инструкцию за цикл (пропускную способность). Большинство микроконтроллеров, таких как 8051 и PicoBlaze, связаны с задержкой, а большинство микропроцессоров, таких как архитектура x86, связаны с пропускной способностью.