Synplify vs все остальные, Чего-то стал Synplify портиться ... Опции

[v_mirgorodsky]

На данный момент используем в проекте Cyclone EP2C8F256. Для синтеза используем Synplify версии 8.5. В большинстве случаев результаты синтеза неудовлетворительные Synplify не имеет временных параметров моделей памяти и не умеет нормально синтезировать аппаратные умножители. В результате получаются, мягко говоря, странные результаты синтеза. Последующая имплементация в целевую микросхему с туго затянутыми параметрами многое исправляет, однако далеко не все. Таким образом получается дизайн, который не разгоняется до своей нормальной рабочей частоты. Приходится в Quartus генерить все примитивы и вставлять их в RTL код, что уменьшает его переносимость и добавляет проблем при отладке.

Не знает ли кто, как бороться с этой напастью ? Может поменять синтезатор ? На какой ? У кого какие впечатления от менторовских продуктов ? Если я правильно помню, у них их два. Чем они отличаются друг от друга ?

[v_mirgorodsky]

vetal

@W:MT246 : blah_blah.vhd(95) | Blackbox synplicity_altsyncram5_r_w_blah_blah is missing a user supplied timing model. This may have a negative effect on timing analysis and optimizations (Quality of Results)
Это сообщение с вариациями можно видеть всякий раз, когда устанавливаешь память в дизайн. При этом этот идиот считает, что этот самый BlackBox имеет чуть ли не константный выход и выполняет оптимизацию - ретайминг и пайплайнинг исходя из этого предположения. При этом начисто игнорирует факт использования/отсутствия выходного регистра внутри самого блока памяти. С констраином
"block_ram,no_rw_check" - знаком. Однако работает он только для Xilinx, для Altera надо ставить "M4K,no_rw_check". Теперь об памяти с ассинхронным выходом и внешней линейке регистров по выходу. Quartus, по возможности, "втягивает" их внутрь блока памяти, что приводит к значительному приросту скорости и уменьшению внешней логики. А пробовал ли кто раздельно управлять енейблами входного и выходного регистров памяти? Или память с разной шириной по разным портам? В большинстве случаев Synplify рассказывает, что блок памяти слишком сложный и заменяет его на туеву хучу регистров и потом плачет, что дизайн не помещается в кристалл.

А чего стоит вот такой варнинг:
@W:BN116 : blah_blah.vhd(95) | Removing sequential instance mem_38 of view:PrimLib.dff(prim) because there are no references to its outputs
хотя все выходы памяти использованы и работают, что было подтверждено симуляцией и работой реального устройства.

Или такой случай. Строили мы гистограмму непрерывно поступающих данных. По выходу памяти с выходным регистром стоит mux 3-в-1, 18-ти разрядный сумматор с единицей и после сумматора mux 2-в-1, короче сумматор с насыщением. При начальном продумывании схемы был собран макет арифметики между регистрами. Ретайминг запретили, засинтезировали и имлементировали - скорость работы схемы более 150MHz. Написали блок, поставили реальную память - меньше 130. Просто в первом случае Synplify ответственно подошел к синтезу этой логики, а во втором посчитал память константным выходом, показал при синтезе скорость около 180MHz и расслабился. Скоростные параметры выходного регистра памяти позволяют ему функционировать на частотах до 180MHz - т.е. дело в неряшливом синтезе.

К слову сказать, для Xilinx Spartan 3E скорость работы блока не превышает 86MHz В приципе не могу понять такую разницу в скорости Код полностью RTL, никаких проблем при синтезе под Spartan не было.


Mad Makc

Уложить умножитель в сам DSP блок нет никаких проблем. Только вот попробуйте попереключать знаковые/беззнаковые умножения на ходу, поиспользовать внутренние входные и выходные регистры самого умножителя с их енейблами и все станет понятно. Умножитель, как ассинхронную структуру, он использует, регистры к ней прилепит внешние и покажет скорость порядка 62MHz, хотя реально дизайн разгоняется до 162MHz. Было бы не обидно, что он так делает, если бы он остальную часть схемы возле умножителя синтезировал в соответствии с заданными временными требованиями, а так он говорит, что 62MHz - это предел и не оптимизирует расположение остальных компонентов схемы, что результируется в проблемах при имплементации дизайна в кристалл. Пока Quartus не умел делать ресинтез и ретайминг приходилось эти цепи выносить в игнор, разгонять остальную часть схемы и лишь после этого получался приемлемый результат.

P.S. Для тех, кто не знает - 162MHz - это предельная частота работы умножителей в EP2C8F256. Просто было необходимо разогнать эту часть схемы по максимуму.

---------------------------------------------------------------------------------------------
Я понимаю, что начальный вопрос, возможно, показался чайниковским, однако проблемы с синтезом c Synplify все же существуют и решений для них Synplicity не предлагает. Эта лабуда уже тянется несколько последних версий Synplify. Каждый раз когда я скачиваю новый билд, я надеюсь, что все уже поправили, однако при запуске все оказывается также плохо, как и в предыдущих версиях. Вот потому и возникла идея перейти на сопоставимый по качеству синтеза продукт, но не глюкавый, как Synplify.

Потому и спрашиваю о менторовских продуктах. Может у них получше с выше описанными аспектами, а качество синтезированного кода сопоставимо ?

А чем плохо сразу в Квартусе разводить - у него сейчас далеко не плохие результыты работы?

Quartus очень погано синтезирует VHDL. Все еще не умеет распознавать RTL описание памяти, имеет проблемы с функциями и разрадностями параметров. Проект после Quartus'а занимает обычно больше места и работает намного медленнее. Однако Quartus по уже синтезированному нет-листу очень неплохо справляется с доводкой до требуемых параметров по скорости, ретаймингом и ресинтезом ассинхронных цепей. Так и работаем - синтезируем Synplify, потом затягиваем параметры Quartus'у по самое немогу и получаем приемлемый результат. К сожалению, глюки Synplify мешают картине быть совсем идеальной, однако такой подход себя оправдывает.

С ужасом ожидаю полной сборки проекта - по прикидкам чип будет забит процентов на 90