Почему не хватает родных САПР для ПЛИС?, Зачем нужны Active-HDL, Riviera, ModelSym, Synplify, Identify... Опции

[kst]

Из форумов понял что разработчики ПЛИС помимо родных САПР Altera (Quartus) и Xilinx (ISE) используют и другие программные продукты.
Подскажите пожалуйста, почему не хватает родных?
И какое ПО сейчас используют для разработки ПЛИС Xilinx?

Начинал я работать с Altera_вскими ПЛИСами в Quartus, в прошлом году пришлось пересесть на Xilinx в Foundation 4.2i (по требованию заказчика). Все делал в схемотехнике. На VHDL писал лишь отдельные блоки. И хватало всех средств каждой из этих САПР для полного цикла разработки: кодирование -> функциональная симуляция -> синтез -> имплементация -> временная симуляция. Как-то и не задавался вопросом, можно ли еще какие-то продукты использовать.

Теперь предстоит делать прошивку ПЛИС Viretx4 SX. Причем все нужно делать на VHDL. Достал ISE 8.1. А он, по отзывам коллег, устраивает демонстрации с маршем протеста. Вешает машину, долго думает и прочее. По отзывам в форумах понял, что сведущие люди помимо этих САПР используют еще и другое ПО, например Active-HDL, Riviera, ModelSym, Synplify, Identify и др.
Я могу, конечно, уйти с головой в изучение докумнетации на каждый из этих продуктов, чтоб выяснить их плюсы и минусы и решить стоит мне ими заниматься или нет, но мне все таки хотелось бы услышать пару слов от профессионалов, почему используются дополнительные программы и какие бы они порекомендовали для использования?

[Timmy]

Скрестим шпаги, мистер?
В чем корявость и глючночть?
Или Вы достигли такого уровня, что Вам не хватает синтезатора в ISE
и без некоторых преимуществ Synopsys как синтезатора Вам жизнь серая?
По пунктам, пожалуйста с исходниками...
Иначе Ваши мысли считаю трепом.

Я часто использую альтернативный способ описания асинхронного ресета. Традиционно делается так

Код

if rst = '1' then
  <что-то инициализировали>
elsif rising_edge(clk) then
  <последовательные операторы>
end if;

Однако можно и так:

Код

if rising_edge(clk) then
  <последовательные операторы>
end if;
if rst = '1' then
  <что-то инициализировали>
end if;

Во втором случае не требуется инициализировать по ресету все регистры, управляемые процессом, и вообще он более соответствует логике асинхронного ресета. Так вот XST во втором случае создаёт неправильный, нерабочий код, что в простых случаях легко можно видеть по RTL view. Создание кода, несоответствующего исходнику - это мегабаг для любого компилятора. Sinplify в подобном поведении никогда замечен не был.

И на тему корявости. Например, описываем процессор, у которого ALU с явно описанной системой мультиплексоров(а иначе невозможно получить нормальный дизайн) и предопределённой в соответствии с мультиплексорами системой кодов операций.

Код

constant ALU_ADD:alu_opcode_t := "0X00";
constant ALU_SUB:alu_opcode_t := "0X01";
constant ALU_AND:alu_opcode_t := "001X";
constant ALU_OR:alu_opcode_t := "011X";

constant OP_ADD:opcode_t := "00000000";
constant OP_SUB:opcode_t := "00000001";
constant OP_AND:opcode_t:= "01100000";
constant OP_OR:opcode_t := "01100010";
...
-- и декодер
case opcode is
when OP_ADD=>alu_op <= ALU_ADD;
when OP_SUB=>alu_op <= ALU_SUB;
when OP_OR=>alu_op <= ALU_OR;
when OP_AND=>alu_op <= ALU_AND;
when others=> alu_op <= (others=>'X');
end case;

В таком случае Sinplify совершенно правильно отобразит младший бит opcode на младший бит alu_op. И второй бит opcode на третий из alu_op. А вот XST, не обращая внимания на расставленные 'X'(он воспринимает их, как нули), накрутит такой логики, что мама не горюй, что фактически не позволяет под ним использовать обобщённое описание декодера, без катастрофического падения perfomance.

[анатолий]

Synplify идет на 2-4 года впереди ISE по расширению возможностей распознавания разных идиом.
Когда ISE не делал retiming, Synplify его уже делал - и повышал этим частоты в 1,1 - 1,7 раз.
И сейчас Synplify делает это лучше.
Опять же, в Synplify не проходит несоответствие разрядностей в выражениях - типичная ошибка, проходящая в ISE.
Кроме того, Synplify варнингами показывает, где написание текста корявое и требует исправления для красивости.
Наконец, Synplify рисует значительно красивее и компактнее картинки после синтеза - очень
квалифицированная иллюстрация, напр., для студентов.

Если делается IPCore, то его требуется проверить на синтез на всех популярных синтезаторах, включая Synplify.

Другое дело, Synplify рассчитан на все ПЛИС, а ISE - на свои собственные.
И поэтому ISE кое-какие синтезы удаются лучше, например, линии задержки на SRL16.

[Bad0512]

Я часто использую альтернативный способ описания асинхронного ресета. Традиционно делается так

Код

if rst = '1' then
  <что-то инициализировали>
elsif rising_edge(clk) then
  <последовательные операторы>
end if;

Однако можно и так:

Код

if rising_edge(clk) then
  <последовательные операторы>
end if;
if rst = '1' then
  <что-то инициализировали>
end if;

Во втором случае не требуется инициализировать по ресету все регистры, управляемые процессом, и вообще он более соответствует логике асинхронного ресета. Так вот XST во втором случае создаёт неправильный, нерабочий код, что в простых случаях легко можно видеть по RTL view. Создание кода, несоответствующего исходнику - это мегабаг для любого компилятора. Sinplify в подобном поведении никогда замечен не был.

Я думаю, что создать "правильный" код по такому корявому исходнику - просто невозможно. Ваш код описывает не асинхронный ресет, а какую-то весьма странную нестабильную систему. Простой вопрос : что произойдёт если ресет и фронт тактового сигнала придут в один и тот же момент времени? Ваша схема ответа на этот вопрос не даёт. В нормальном описании побеждает ресет, на то он и асинхронный.
И это соответствует логике работы базового элемента FPGA. Так что синтезатор тут ни при чём, учите матчасть... Ну а то обстояетельство, что Sinplify переваривает даже такой корявый код, ни о каких преимуществах не говорит.

[des00]

Простой вопрос : что произойдёт если ресет и фронт тактового сигнала придут в один и тот же момент времени? Ваша схема ответа на этот вопрос не даёт.

хммм, разве в стандарте на VHDL уже отменили требование по последовательное исполнение операторов в процессе ?

[Bad0512]

хммм, разве в стандарте на VHDL уже отменили требование по последовательное исполнение операторов в процессе ?

В таком случае (судя по описанию) получается что клок имеет приоритет над "якобы асинхронным" ресетом. Как это ляжет в железо? Да и ляжет ли вообще?
Code templates придумали неслучайно. Именно для того, чтобы не наступать на подобные грабли. Первое описание всеми синтезаторами трактуется одинаково, второе -
весьма странная конструкция, которая (по моему мнению) вообще не должна синтезироваться корректно.

[des00]

В таком случае (судя по описанию) получается что клок имеет приоритет над "якобы асинхронным" ресетом. Как это ляжет в железо? Да и ляжет ли вообще?

это с каких это пор ? при последовательном исполнении операторов сверху вниз и при той модели присвоения сигналов, которая указанна в стандарте VHDL, сигнал сброса, в сабжевом коде, имеет более высокий приоритет, т.к. исполняется последним.

ЗЫ. в V, SV абсолютно тоже самое. В некоторых случаях это очень хороший способ описания логики, на форуме SM выкладывал как-то оччень интересные и красивые сорцы демонстрирующие это.

[sazh]

при последовательном исполнении операторов сверху вниз и при той модели присвоения сигналов, которая указанна в стандарте VHDL, сигнал сброса, в сабжевом коде, имеет более высокий приоритет, т.к. исполняется последним.

А красота то в чем?
В том что с ног на голову описание поставлено. (а потом для верности в rtl просмотрщик заглянуть, чтоб в правильности реализации по стандарту убедиться и ухмыляться, когда соратник в xst большую фигу наблюдает.)
И для этого еще дополнительно Synplify докупать?

[des00]

А красота то в чем?

найдите сорцы SM на эту тему и сами убедитесь.

[анатолий]

хммм, разве в стандарте на VHDL уже отменили требование по последовательное исполнение операторов в процессе ?

Поддерживаю.
У языка есть очень четкая семантика, определяемая стандартом.
И симулятор, и синтезатор должны подчиняться этой семантике,
кроме случаев, когда объекты с таким поведением не синтезируются в принципе.

А идиомы, рекомендуемые фирмой - это от ее убогости с 1 стороны
и для обучения новичков по методу "делай как я" с 2 стороны.

[sazh]

и для обучения новичков по методу "делай как я" с 2 стороны.

Код

Как только я познакомился с языком VHDL и ПЛИСами, я понял, что это как раз то, чего мне с детства не хватало. Было сделано несколько проектов, пришел опыт. Но интерес к языку всё возрастал. Интерес толкал жонглировать операторами языка при реализации разных штучек, не нужных в работе, но оригинальных в исполнении и эффектных в функционировании. VHDL и ПЛИС - это как кисти и мольберт для художника. VHDL стал моим хобби. Хорошо, когда работа - хобби, а хобби - работа.

[анатолий]

Можно и не докупать Synplify. Можно все задачи решить на Webpack'e.
Я в детстве увлекался вырезанием по дереву - и все ножичком, даже то, что можно токарным станком было.
Но как только добрался до токарного станка, стамесок, рубаночков - сразу пошло и качество, и скорость.
То же самое - с другими инструментами и в другой отрасли.

[jojo]

Synplify не нужен, чтобы писать хороший код. А с хорошим кодом достаточно XST.
Кроме того, основные проблемы в ISE с размещением, где ничто уже не поможет, кроме головы.

[RobFPGA]

Приветствую!

Synplify идет на 2-4 года впереди ISE по расширению возможностей распознавания разных идиом.
Когда ISE не делал retiming, Synplify его уже делал - и повышал этим частоты в 1,1 - 1,7 раз.
И сейчас Synplify делает это лучше.

Почти всегда лучше - но так обидно бывает что на каких-то вроде мелочах обламывает вусмерть

Из последних "приколов" если например порты в VHDL объявит типа record то ISE создает имена отдельных портов соединяя имя record с именами полей в record а вот Synplify нет - будет тебе просто шина с именем как у record Хотя в SystemVerilog для interface тот же Synplify нормально имена создает - бардак какой то . На днях Synplify отказался модуль на Verilog вставлять в модуль на VHDL на его (Synplify ) взгляд какое-то несоответствие а какое - не сознается !!! Блин переписал все по новой - проверил каждый порт - в ISE, ActivHDL, Modelsim - все нормально а Synplify - "Unbound component aurora of instance u_aurora " падла!

Удачи! Rob.

[sazh]

Но как только добрался до токарного станка, стамесок, рубаночков - сразу пошло и качество, и скорость.

Позволю себе привести описание уважаемого Oldring.
Хотелось бы узнать оценку сообщества (по стилю (красоте, читаемости) описания)
в контексте данного обсуждения (той или иной поддержки стандарта синтезаторами).

Код

library ieee;
use ieee.numeric_bit.all;

entity in_out_flag is
    port(
        in_flag : in bit;
        
        out_clk : in bit;
        ena_out_flag : out bit
    );
end in_out_flag;

architecture Behavioral of in_out_flag is
-- На S6 схема получается проще, если начальное состояние триггера
-- с задействованной асинхронной установкой равно 1
    signal shift_reg : bit_vector( 1 to 4 ) := (others => '1');
begin

process( in_flag, out_clk )
begin
    if rising_edge( out_clk ) then
        shift_reg <= shift_reg srl 1;
    end if;
    
    if in_flag = '1' then
        shift_reg( 1 ) <= '1';
    end if;
end process;

ena_out_flag <= shift_reg( 3 ) and not shift_reg( 4 );

end Behavioral;

[ViKo]

... при последовательном исполнении операторов сверху вниз и при той модели присвоения сигналов, которая указана в стандарте VHDL, сигнал сброса, в сабжевом коде, имеет более высокий приоритет, т.к. исполняется последним.
ЗЫ. в V, SV абсолютно тоже самое ...

Приоритет имеет первый оператор, не последний. Сначала проверяется подходящее условие для него, а уж потом, если условие не выполняется, выполняются следующие операторы.

Написать сначала проверку фронта такта, а потом сброса... можно, и, наверное, все скомпилируется, в обход логики описания. А может быть, и нет... Не вижу ни одной причины нарушать приоритеты сигналов, заданные в железе ПЛИС.

Вот тут http://electronix.ru/forum/index.php?showt...st&p=764559 я когда-то "пошутил" с сигналами такта и сброса.