Уменьшите задержку, поняв отчет Xilinx Synthesis

Посмотрите на имена в отчете и сравните с исходным кодом.

По сути, у вас есть только комбинационная логика, протекающая в экземпляре «SEQ» от кода операции ALU к выходному сигналу ALU «alu_src_2L»:

Источник: SEQ/alu_op_code_1 (FF) Назначение: SEQ/alu_src_2L_7 (FF)

Глядя на детали, вы можете видеть, что в этом конкретном пути большую часть времени используется в вашем АЛУ «ALU1» и, в частности, в логике сумматора/сравнения «adder_comp». Если вы хотите иметь меньшую задержку в этом пути, вам придется либо оптимизировать логику, либо сократить путь с помощью другого регистра (и заставить остальную часть проекта по-прежнему работать с этим изменением).

Несколько определений:

• Задержка ворот: для входа, чтобы вызвать изменение на выходе блока
• Чистая задержка: время для сигнала, чтобы добраться до следующего блока

13.33ns состоит из двух частей. 6,677 нс задержка шлюза и 6,653 нс чистая задержка

Основным фактором задержки вентиля является то, насколько сложная функция содержится в логическом конусе. Основным фактором чистой задержки является то, сколько вещей управляется сигналами.

Каждая строка в отчете говорит об одном логическом блоке. Итак, первая строка регистра alu_op_code_1 и время, которое проходит от вывода C (Clk) до вывода Q (выход). Столбец разветвления показывает, сколько логических блоков управляет выводом Q. В данном случае это 40, поэтому сетевая задержка достаточно высока. Однако вполне понятно, что часто используемый регистр, такой как код операции ALU, имеет большое разветвление.

Мы также можем посмотреть на путь в целом и увидеть, что он идет от кода операции в SEQ к ALU. через сумматор обратно в блок SEQ и, наконец, в другой регистр с именем alu_src_2H_1. Что это за путь, я не могу вам сказать. Это может сделать только тот, у кого есть источник, и тогда нужно попытаться увидеть, какая логика существует между этими двумя регистрами.

Что меня немного смущает, так это то, что этот путь выглядит так, как будто он соответствует времени (цель 13,33 нс), но вы говорите, что вам нужно «усилить его». Почему?

Во-первых, при написании 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 циклов на инструкцию. Если вы умны, вы можете написать свой HDL таким образом, чтобы вы начали обработку одной инструкции и в то же время закончили обработку последней инструкции. Это означает, что для каждой инструкции по-прежнему потребуется 2 такта (задержка), но вы сможете отказаться от одной инструкции за цикл (пропускная способность). Большинство микроконтроллеров, таких как 8051 и PicoBlaze, озабочены задержкой, а большинство микропроцессоров, таких как архитектура x86, — пропускной способностью.