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

Question

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

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

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

Answer 1

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

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

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

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