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

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

Mentor Presicion RTL Senthesis - сопоставим с Synplify. Правда есть мнение на форуме, что он в объемных проекта все таки уступает.
Идет в комплекте с нормальной средой разработки - FPGA Advantage

А как вы установили, что Synplify не имеет временных параметров моделей памяти?

На счёт умножителей - сходите на сайт Synplify ->support -> Knowledgebase. Там попросят регистацию.Зарегестрироваться можно без проблем.В этой "базе знаний" есть несколько топиков про умножители альтеровские и как их в DSP блоки пихать.Может чем поможет.

Имеет, смотрите внимательнее.
В любом случае синтезатор выдает лишь ориентировочные задержки, т.к. задуржки на LUT соизмеримы с задержками на соединениях.


Читайте документацию. Особенно раздел "Altera Constraints and Attributes", "Stratix, Cyclone, and Hardcopy DSP Block Inference". На чистом hdl без аттрибутов далеко не продвинитесь.
PS:attribute syn_ramstyle of mem : signal is "block_ram,no_rw_check";

А у меня синплифай верий 8.4 и выше (последний 8.5.1 не пробовал
- нету) просто вылетают во время компиляции с идиотскими сообщениями
о невразумительных ошибках. Пришлось вернуться к 7.7.1.

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

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

По опыту использования разных средств синтеза, могу сказать, что разница между результатами вряд-ли будет значительной. 10-15% причем как в лучшую сторону, так и в худшую. Поэтому:
1. в очередной раз в Вашем случае обращаемся к разделу "Designing with Altera" документа Synplicity FPGA Synthesis Reference Manual и смотрим, что он поддерживает и как.
2. смотрим в проект, и сопоставляем, как должно быть и как есть на самом деле.

Если синтезатором, что-то желаемое не поддерживается, то, увы, рассказываем, что хотим получить, "ручками".

Еще могу порекомендовать освоить средства физического синтеза, к примеру, Magma Palace. Позволяет получить 3-5% экономию ресурсов кристалла + 10-20% прирост частоты.



Компонент synplicity_altsyncram5_r_w_blah_blah не является технологическим примитивом Cyclone, а является, насколько я понимаю, макросом LPM. Тем не менее, в поставке Synplify имеется соответствующая библиотека макросов. Подключив эту библиотеку, Synplify получит возможность анализа времен для данного макроса. Однако, не все LPM макросы поддерживаются. Список можно найти в документации.

2 v_mirgorodsky

я понимаю ваши проблемы, сам с ними столнулся, а именно если симплифай инферит что то хардварное то все ок, он учитывает времянку, если же нет, то считает что элемент не обладает таймингами. НО сама симплисити предлагает решение сей проблемы, вы можете прописать констрейны таймингов на хардварные макросы.

Removing sequential instance mem_38 of view:PrimLib.dff(prim) because there are no references to its outputs
вот это очень часто симплифай выдает на те регистры/блоки которые "втягиваються" в хардварные макросы.
Для хилых синтезил маки с бехавор описания ложилось на 300МГц (-10).
И вообще пользуйте конфигруации. Я уже говорил в соседней теме, симуляемся/дебажимся на бехаворе, а итогово собираем хардварные макросы.

Synplicity FPGA Synthesis Reference Manual и так стоит в закладках И его внимательное изучение не всегда помогает избежать проблем

В ходе обсуждения возникло несколько вопросов.
1. А как подключить Synplify библиотеки временных параметров для аппаратных макросов? На пример, где указать что в проекте используется та же altsyncram или что-то подобное? des00 буду очень признателен за ссылку на тему, в которой это обсуждалось.

2. Кто и как борет проблему окончательной сборки проекта из VQM модулей? Мы попытались поставить два VQM'а в проект, так Quartus нашел в них одинаковые имена элементов и сказал, что это лажа. Пришлось открывать нетлист и ручками патчить имена. Однако такой подход вряд ли можно назвать оптимальным для больших проектов. В то же время создать из нескольких VQM один большой VQM Synplify не умеет В то же время VQM'ы созданные самим Quartus не содержат пересекающихся имен.

1. Вчера специально попробовал: unsigned и signed умножители с регистрами на входе и выходе, сигналом clock enablr и асинхронным сбросом - все синтезируется как по маслу.
С сигналами signa и signb не получится, т.к. это будет уже не примитив, а функционально сложный блок.

2. Прочитайте про аттрибуты syn_tco,syn_tpd и syn_tsu. При правильном описании черного ящика он будет нормально конвееризироваться. Тоже пробовал, работает.

vetal

А для какого семейства и какая версия Synplify? Мы столкнулись с проблемами при синтезе под Altera EP2C8F256-C8. В то же время под Xilinx или под Stratix синтез проходит без особых вопросов.

Synplify 8.5.1(местный).
Семейство CII, ep2c8f256i8.
код:

To vetal
А в Квартусе на любом кристалле выдает ошибку
Error (10409): VHDL Type Conversion error at mult_test.vhd(32): converted type of object near text or symbol "UNSIGNED" must match std_logic_vector type of target object
Посмотрел в рекомендациях xilinx и altera: там описание отличное от Вашего.

mult_result_reg<=unsigned(unsigned(data_a_reg)*unsigned(data_b_reg)); ->
mult_result_reg<=std_logic_vector(unsigned(data_a_reg)*unsigned(data_b_reg));
Synplify сам догадывается, что unsigned -> std_logic_vector.


Тоже самое.
запихал в synplify кусок кода из quartus_handbook - все синтезируется. Понять не могу как могло не синтезироваться.

Оба-на! А с каких пор стало можно определять сигнал в интерфейсе через другие сигналы того же интерфейса? Modelsim такое не ест:

Model Technology ModelSim SE vcom 6.1d Compiler 2006.01 Jan 23 2006
-- Loading package standard
-- Loading package std_logic_1164
-- Loading package numeric_std
-- Compiling entity mult_test
###### mult_test.vhd(12): result : out std_logic_vector(data_a'left +data_b'left+1 downto 0)

** Error: mult_test.vhd(12): Object 'data_a' cannot be used within the same interface as it is declared.
** Error: mult_test.vhd(12): Object 'data_b' cannot be used within the same interface as it is declared.
** Error: mult_test.vhd(12): No feasible entries for infix operator "+".
** Error: mult_test.vhd(12): Bad expression in left operand of infix expression.
** Error: mult_test.vhd(12): Bad expression in left bound of range expression.
** Error: mult_test.vhd(12): Type error in range expression.
###### mult_test.vhd(14): end mult_test;

** Error: mult_test.vhd(14): VHDL Compiler exiting

Как оказалось - это поддерживают только синтезаторы.
И не надо придираться, цель была – синтезировать умножитель и не более. Тем более код писался в адскую жару.