[v_mirgorodsky 0]

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

 

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

[Kopart 0]

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

 

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

 

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

Идет в комплекте с нормальной средой разработки - FPGA Advantage

[MadMakc 0]

Synplify не имеет временных параметров моделей памяти

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

и не умеет нормально синтезировать аппаратные умножители.

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

[vetal 0]

Synplify не имеет временных параметров моделей памяти

Имеет, смотрите внимательнее.

В любом случае синтезатор выдает лишь ориентировочные задержки, т.к. задуржки на 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";

[maior 0]

А у меня синплифай верий 8.4 и выше (последний 8.5.1 не пробовал

- нету) просто вылетают во время компиляции с идиотскими сообщениями

о невразумительных ошибках. Пришлось вернуться к 7.7.1.

[Builder 1]

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

[v_mirgorodsky 0]

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 :( В приципе не могу понять такую разницу в скорости :maniac: Код полностью 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 :(

[oval 0]

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

 

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

По опыту использования разных средств синтеза, могу сказать, что разница между результатами вряд-ли будет значительной. 10-15% причем как в лучшую сторону, так и в худшую. Поэтому:

1. в очередной раз в Вашем случае обращаемся к разделу "Designing with Altera" документа Synplicity FPGA Synthesis Reference Manual и смотрим, что он поддерживает и как.

2. смотрим в проект, и сопоставляем, как должно быть и как есть на самом деле.

 

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

 

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

 

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 :( В приципе не могу понять такую разницу в скорости :maniac: Код полностью 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 :(

 

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

[des00 25]

2 v_mirgorodsky

 

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

 

Removing sequential instance mem_38 of view:PrimLib.dff(prim) because there are no references to its outputs

вот это очень часто симплифай выдает на те регистры/блоки которые "втягиваються" в хардварные макросы.

Для хилых синтезил маки с бехавор описания ложилось на 300МГц (-10).

И вообще пользуйте конфигруации. Я уже говорил в соседней теме, симуляемся/дебажимся на бехаворе, а итогово собираем хардварные макросы.

[v_mirgorodsky 0]

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

 

В ходе обсуждения возникло несколько вопросов.

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

 

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

[vetal 0]

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

С сигналами signa и signb не получится, т.к. это будет уже не примитив, а функционально сложный блок.

 

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

[v_mirgorodsky 0]

vetal

 

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

[vetal 0]

vetal

 

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

 

Synplify 8.5.1(местный).

Семейство CII, ep2c8f256i8.

код:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity mult_test is
    port (
    clock    : in std_logic;
    aclr    : in std_logic;
    ena        : in std_logic;
    data_a    : in std_logic_vector(8 downto 0);
    data_b    : in std_logic_vector(8 downto 0);
    result    : out std_logic_vector(data_a'left +data_b'left+1 downto 0)
    );
end mult_test;

architecture rtl of mult_test is
    signal data_a_reg        : std_logic_vector(data_a'range);
    signal data_b_reg        : std_logic_vector(data_b'range);
    signal mult_result_reg    : std_logic_vector(result'range);
begin

    result<=mult_result_reg;
    process(aclr,ena,clock)
    begin
        if (aclr='0') then
            data_a_reg<=(others=>'0');
            data_b_reg<=(others=>'0');
            mult_result_reg<=(others=>'0');
        elsif (ena='0') then
            null;
        elsif (clock'event and clock='1') then
            mult_result_reg<=unsigned(unsigned(data_a_reg)*unsigned(data_b_reg));
            data_a_reg<=data_a;
            data_b_reg<=data_b;
        end if;
    end process;
end rtl;

[sazh 7]

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: там описание отличное от Вашего.

[vetal 0]

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.

 

Посмотрел в рекомендациях xilinx и altera: там описание отличное от Вашего.

Тоже самое.

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