Проблемы синхронизации при синтезировании дизайна в Verilog

Question

Я работаю над модулем декодера на основе кодов BCH. Проект должен быть реализован на ПЛИС Virtex-7. У меня в основном три блока. Блок вычисления синдрома, блок поиска ошибок и блок поиска ошибок. Блок вычисления синдрома отлично работает на FPGA и работает на тактовой частоте 225 МГц. Я работаю над блоком поиска локатора ошибок, и это дает мне некоторые проблемы с синхронизацией. Проблема, по сути, заключается в следующем:

1) У меня есть модуль, который имеет только регистр. Блок дела имеет 1024 записи. Путь, который терпит неудачу, содержит этот модуль. Если я закомментирую этот модуль, дизайн работает отлично. В реализованном дизайне этот модуль размещен слишком далеко, и из-за этого я получаю огромную сетевую / проводную задержку. Есть ли способ для меня, чтобы модуль на основе кейса был ближе к моему реальному дизайну?

Любая помощь будет оценена. Чистая задержка составляет не менее 60 процентов от общей задержки. Это неприемлемо для проблемы, которую я пытаюсь решить, так как этот декодер должен работать как минимум на частоте 200 МГц

Answer 1

В предыдущем наборе инструментов Xilinx FPGA, который назывался ISE, у вас была возможность варьировать таблицу затрат на размещение (PCT), что приводит к различному расположению логических ячеек, что приводит к различным результатам синхронизации. PCT может быть повторен в разных прогонах реализации (с использованием SmartXplorer), которые останавливались до тех пор, пока не было найдено PCT с действительными результатами синхронизации.

Xilinx отказался от этой стратегии из-за неэффективности больших ПЛИС (как и ваше устройство Virtex 7). Но у вас есть несколько предопределенных стратегий, которые также можно запускать параллельно. Просто откройте Настройки реализации и попробуйте разные стратегии и посмотрите, работает ли одна из них.

Если нет, вы должны оптимизировать свой дизайн на уровне HDL. В целом, конвейерная обработка - это хорошая стратегия, но она сильно зависит от вашего кода. В общем случае вы должны уменьшить большие комбинационные конструкции, и ваш оператор case с 1024 записями является таким кандидатом для большой комбинационной конструкции.

Изменить: См. Xilinx UG904, чтобы получить обзор и краткое описание различных стратегий реализации.