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

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

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

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

Пара слов (от непрофессионала): По сути ModelSim и так уже наличиствует в ISE. Хотя вроде бы в усеченной и специализированной версии (могу ошибаться, т.к. с ISE серьезно не работал). Это типа продукт кооперации фирм-производителей САПР. Вообще ModelSim - одно из самых популярных средств моделирования (а с недавних пор еще и продвинутой верификации). Synplify принято считать лидером в области оптимизации HDL-описания. Identify можно использовать для внутрикристальной отладки. Однако в ISE 8 вроде как появился аналогичный продукт - ChipScope.

Modelsim и встроенный симулятор ISE - это две большие разницы. Это становится понятно, если попробовать воспользоваться тем и другим. Симулятор ISE - это "Modelsim для бедных".



У каждого из синтезаторов есть свои плюсы и минусы. Но есть такое понятие, как привязанность к какому-либо средству разработки. Например, если человек работая с Actel привыкнет к Synplify, то с большой вероятностью ему уже не захочется изучать XST или Precision. И т.п.



Chipscope работал еще с 6-й версией ISE. Но его трудно сравнивать с Identify, который является более интеллектуальным средством, т.к. позволяет не просто пронаблюдать временную диаграмму внутренних сигналов, но и производить отладку с возможностью удобной установки точек останова.

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

Цена ISE - $2500. Все можно с его помощью сделать. Но гораздо удобнее применять специализированные продукты. Например, ввод проекта и его моделирование (хошь схематик, хошь HDL) - ActiveHDL. Его цена - $10000. Синтез - Synplify. Его цена, по-моему, $4500 для Xilinx и $9000 для нескольких производителей ПЛИС (могу ошибаться). ISE используется только для трассировки ПЛИС. Разница в цене соответсвует разнице в удобстве и быстроте выполнения проекта.
Для отладки проекта в большинстве случаев хватает ChipScope - $500. Identify стоит на порядок дороже, если не больше.
Поэтому, если проект не очень большой, напрягают с лицензионностью и нет денег, то - ISE. В остальных случаях - см. выше. Если разрабатывать систему на кристале или близкую к ней, то это совсем другая ценовая и весовая категория и одним ISE не отделаешься. Раньше я пытался с помощью Foundation разрабатывать 1600 млн. вентилей. Быстро понял, что сделаю проект как раз к пенсии.

А можно привести парочку примеров, почему дополнительные продукты удобнее чем средства ISE?

В чем лично для вас был выигрыш от применения других программ?

Для ребят,которые LEON сделали вот в чём выйгрыш( взято из описания на grlib.pdf):
XST generates netlists with roughly the same timing as Synplify,
but with approximately 20% more gates.

Не хило

Успел до пенсии

Ну это было сразу понятно.
Меня больше интересует какие преимущества другого программного продукта перед Foundation позволили ускорить процесс разработки?

Вот почитай. А то долго расписывать.

Ссылка про ActiveHDL

Ну начнём с написания кода.Графический редактор в Foundation никакой. Значит время отладки и написания кода стремится к бесконечности.
далее.Синтез.Ну кроме того,что уже было написано про XST, можно добавить,что он плохо поддерживает всякие извращённые конструкции,которые позволяют сделать код универсальным и легко настраиваемым.Опять же экономия времени разработки и места в ПЛИС.
А ваще- зачем спрашивать?Возьмите и попробуйте сами.

Jools, огромное спасибо! Очень кстати.

Ну если я буду пробовать сам абсолютно всё, мне жизни не хватит
Иногда сильно экономят время повествования других людей о своем опыте. Форумы, насколько я знаю, создавались и для этих целей тоже.

Вот теперь я действительно буду пробовать!

Я до сих пор пользуюсь Foundation, но только для поддержки старых проектов. Если делаешь с нуля, то даже и не думай, почему это лучше другие проги использовать. Сразу переходи на HDL и на проверенные связки продуктов, например, ActiveHDL + Sinplify Pro + ISE. Опосля поймешь. Уж поверь опыту, если не моему, то остальных соконфетников. Не пожалеешь.

Вот!!! Вот оно!!! То, что я ждал так долго!
Прочь сомнения!
Уже запасся ActiveHDL и ISE. Остался Sinplify Pro.

Спасибо!

К сожалению, с Альдеком поработать еще не успел...

Поэтому вопрос к тем, кто уже много чего попробывал - можете поделится ЛИЧНЫМ мнением по как по сравнению с hdldesigner'om (который в FPGA Advantag'е идет).
Вопрос по удобству ввода проекта и его симмуляции (про синтез тут уже много осуждалось и даже общие выводы есть)

* По сообщениям на форуме, обзорам и личному опыту с хдлдезайнер + модел сим склоняюсь, что в Альдеке этот этап более "Юзер-френдли"

А фирмы Sinplicity есть свой пакет? (не Premier ли зовется)
Знаю есть здесь, кто под эту фирму программит, но на форуме ничего не видел.
Хотя я могу ошибатся про САПР от этой фирмы...

Основная линейка продуктов - synplify.
Большинство тех, кто работает с Actel, синтезирует в нем, т.к. он предоставляется бесплатно.
Altera в своих отчетах по бенчмаркам оговаривает, что синтез был в synplify.

Глянул на сайте Synplify Premier - это для ввода проекта.
Про удобства с вышеназваными пакетами, кто-то может выразить свое мнение?!
А как/в чем происходит моделирование(симуляция/отладка)?



Про Альтеру это хорошее замечание (вопрос как рассматривать - свой не такой "производительный" или для унификации сравнения, а наверно оба )

Не, это развитие pro и объединение его с amplify - физический синтез, топологическое размещение дизайна и прочие прибамбасики для выцарапывания максимальной частоты.
Для ввода проекта, кроме алдека и хдлдизайнера, знаю еще Visual Elite от Summit design - по крайней мере его можно использовать, т.к. и интернете встречаются краки.

не подумайте что я тут побычить хочу - мнe понастоящему инересно мнение вот по какому поводу.
не кажется ли публике что такие вещи как HDL-designer приводят к деградации разработчика - что-то на подобие того как это происxодит при общение с Дельфи или Висжуал Студио - когда разработчик начинает играть в кубики и мнеогие даже уже не представляют что реально происxодит под этими обложками - и то что подобние рода штуки приводят к привыканию когда разработчик уже просто подсажен на продукт. я вот просто всегда вс: писал ручками а вот сейчас появилась возможность пересесть на ХДЛ-дезигнер думаю стоит или вполне лучше обходиться хорошим текстовим редактором
каковы главные прeимущества?

и еще одно замечание - если пишите в Верилоге не советую использовать Симплифай - они давно забили на поддержание синтаксиса ап-ту-дэйт и роются только в оптимизации ресурсов и подержки новых кристаллов

Несколько консервативный подход.
Насколько я правильно понимаю этот вопрос, главное преимущество (если в полной мере освоить возможности подобных упрощающих жизнь продуктов) - это уменьшение времени разработки, ну и людям не дают сойти с ума от переизбытка информации.
Чем дальше движется прогресс, тем сложнее технологии и конечные продукты. Никуда не деться. Скоро задачи сатнут крайне сложными и все делать ручками с нуля уже не удасться. И одному человеку это будет не под силу. Командная работа с разделением труда.
Кто-то думает об оптимальной начинке кубиков, а кто-то правильным образом расставлет кубики. А дальше - кубики станут начинкой еще больших кубиков. И те кто двигает кубики сейчас начнет кричать, что это приводит к деградации разработчика.

IMHO, на стадии обучения всякого рода САПР - зло. Блокнот и карандаш для ввода проекта, ручное моделирование по дельта-циклам, описание проекта вплоть до уровня вентилей - вот что необходимо начинающему HDL'исту Пару сотен автоматов собрать голымим руками тоже не повредит. Но в дальнейшем при реальной работе этот процесс чреват обилием никому не нужных ошибок (не алгоритмических, а из разряда очепяток). Лично Я поступаю так - генерю остов автомата в HDL-Дизайнере, а доводку делаю руками. Так и количество глупых ошибок сокращается и тотального подсаживания на софт не происходит. А вообще лень - двигатель прогресса!

100% истина! Обязательная прорисовка временных диаграм на бумаге! Ни один САПР за нас это не сделает. А функциональное моделирование - это проверка ляпов типа 2*2=10.

Для временных диаграмм (их рисования) есть замечательные программы типа Timing Designer, Timing Tool, TimeGen, которые уже обсуждались на форуме. Они гораздо удобнее бумаги и ластика.

Не обращал внимания Попробую.

На Телесистемах была тема по поводу программ для рисования временных диаграмм:
"http://telesys.ru/wwwboards/fpga/265/messages/18371.shtml"

Здесь трудно сказать. На вкус и цвет, как известно... Лично я предпочитаю не пользоваться всякими такими тулзами - описание делаю только на языке. Так максимальная гибкость и управляемость. И чем интенсивнее и больше работаешь с текстом, языком, тем лучше рука набита, увереннее поддается контролю текстовое описание. Тут еще хороший редактор рулит.

Что касается дополнительних средств, то без них не обходится. Но тут опять же на вкус и цвет. Я предпочитаю, например, те же автоматы состояний рисовать в Visio, который по уровню работы с графикой дает сто очков любому HDL рисователю. Конечно, Visio не может потом сгенерить из диаграммы код, но это, имхо, не самый большой недостаток - по готовой схеме набросать код - самая простая и быстрая часть работы.

Кстати, то же самое касается и временнЫх диаграмм. Посмотрел несколько специализированных программ (в т.ч. скачал вчера по ссылке с фтп редактор от NI, совершенно не проникся. Возможно, этот инструмент крут тем, что интегрируется с какими-то другими тулзами оной фирмы, но сам по себе совершенно не впечатлил). Какая-то простая программка, afair, TimeGen уже больно убогой показалось. Еще мельком посмотрел более крутую вещь (название могу попутать), вроде, Timing Designer, но ниасиил. В том же Visio вполне удобно временнЫе диаграммы рисовать. Как показывает опыт, основное время уходит не на собственно рисование, а на обдумывание и придумывание. Зато в полный рост рулит внешний вид - чем оно красивше выглядит, тем быстрее приходит понимание. Опять же, гибкость полная при рисовании - какие хочешь элементы (и как хочешь), такие и добавляешь. В отличие от специализированных продуктов. Прошу воспринимать эти слова не как наезд на спец. инструменты, возможно, чего-то не понимаю. Разъясните?


О! А чего там еще делать? Стандарт 2001 он поддерживает, что еще надо? Баги исправлять? Это дело, конечно, нужное, но, во-первых, возможно, они не знают о тех багах, которые Вам анноят, во-вторых, возможно, считают, что это не фатально и пока может подождать, т.к. и так есть над чем работать.

А так оно постепенно начинает поддеживать SystemVerilog. Хотя бы пока на уровне некоторых синтаксических конструкций. Т.е. работают.

to dxp
разделяю мнение по 1 пункту - сам думаю так же
п 2: вы наверное пока не сталкивались, но на самом деле V2к1 поддерживается на уровне V95 плюс половина из того что есть в 2001 для синтеза. синтезируемое подмножество SV поддержено процентов на 5 отсилы

Во-первых, зачем делать двойную работу? Кроме того, эти два представления нужно как-то синхронизировать между собой, поддерживать актуальные версии. Но это даже мелочь. Так можно сделать проект для себя. А если проектом должны пользоваться другие разработчики? А если им понадобится что-то изменить?
Далее. Закодировать машину на 74 состояния (реальный пример) вручную, и не допустить ни одной ошибки чисто по невнимательности (например, в приоритетах) очень сложно. Здесь же половину работы делает HDL-Designer. Разработчик занимается только полезной логикой, не думая о тупиковых состояниях и т.п. Небольшой пример - исключаю одно состояние (нажатием Delete) – автоматически меняются приоритеты остальных.
Многие выступают против использования графического представления (я не о “рисовании схем”, а всё о том же HDL-Designer-e), приводя примеры как просто объединять модули в тексте. А если количество instance-ов - тысяча? Да, наверное, в небольшом проекте на подготовку понадобится немного больше времени при работе с графической оболочкой для HDL, чем в чистом тексте, но мере роста проекта в многочисленных исходниках просто перестанешь ориентироваться (особенно по прошествии времени!)

А что из синтезируемого подмножества V2001 Синплифай не поддерживает?


Да, я поэтому и не дергаюсь. Хотя те же классы были бы очень кстати. Подождем.

Я не утверждал, что мое предпочтение лучше. Это просто мое предпочтение. Проект я всегда виду от текста, а не от графики. Так, как уже сказал, гибче и надежнее. Что-то поменять в тексте - беру и меняю. А корректировать сгенеренный машиной текст считаю неправильным путем - изменять всегда надо исходник, т.е. графику, если от нее пляска.

Графическое представление мне нужно исключително для личного понимания - не могу удержать в голове слишком много информации. А схему переходов печатаю на бумаге - да хоть А1 формата, если она большая, и она всегда перед глазами. Зато ее графический вид я могу выполнить как мне угодно. Не знаю, как у Вас, а у меня основное время уходит не на рисование и не на набор текста, а на придумывание. Если схема выглядит некрасиво, "страдает мое эстетическое восприятие" (с) не помню, кто, кажется ReAl.

Что касается машины на 74 состояния, то графическое представление такого автомата для удобства и оперативности работы вряд ли лучше, чем case(State) ... Что касается запрещенных состояний, то для этого есть всякие default. Кроме того я для каждого состояния завожу именованную константу и присвоение состояния делается только этим. При уделения состояния в первую очередь удалается эта констатнта (компилятор сразу выдаст ошибку, если где-то будет ее использование), т.ч. это еще и в известной степени вопрос стиля.

Кстати, еще про 74 состояния. Количество состояний - не мера сложности. Это мера объема. А сложность - это не объем, а количество перекресных связей. И автомат на дюжину состояний но с морем связей между состояниями может оказаться куда сложнее, чем здоровенный автомат, но с простыми цепочными переходами. Кстати, большие КА, как правило, от того и большие, что в них много цепочных переходов... Ладно, это уже совсем в сторону...

Помимо того, что сказано про "большие" КА (когда в тексте проще сделать очепятки) мое мнение, что из графического описания синтезатор сделает стандартную схему, которую он сможет еще и оптимизировать(по произовдительности/ресурсам).

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

Я имел ввиду, что текстовое описание сгенереное из графики будет стандартное. Связка генератор из графики -> синтезатор в пределе одно пакета, по логике, должна быть оптимизирована => синтезатору будет проще разложить сгенерированое текстовое описание в "стандартные" блоки.

А вот текст не всегда можно так идеально написать (идеально в смысле для конкретного синтезатора)

Теперь понятно. Хм, не знаю, не встречался с такой проблемой. КА всегда оформляю в виде case(...) ..., синтезатор (Синплифай) всегда обнаруживает в этом КА, о чем радостно сообщает, что, дескать, обнаружена FSM. Тем более, что я там еще обычно encoding задаю (чаще всего onehot). Не знаю, как надо написать, чтобы синтезатор это не распознал.

Я писал более обще по Идее:
В veriog можно так описать КА, что синтезатор, может, просто так, не развести на макс частоту/мин ресурсы.
А вот в описав в графике - скомпилированое текстовое описание будет всегда высококачественное для данного пакета (быть может при этом в графике в жертву качественности текстового описания урезаны "лишние" возможности Verilog'a, при сразу текстовом описании).

Согласитесь?
Ведь можно так описать в тексте КА, что, как Вы сказали, синтезатор его поймет, но вот у синтезатора не получется его качественно оптимизировать.

Ну, не знаю. Не сталкивался с трудностями. Смотрел, в частности, как генерит КА Альдек, примерно также. Несколько более многословно, но это нормально для машинносгенерированого текста. С имплементацией тоже все в порядке - с Синплифаем полное понимание. Во всяком случае трудности с времянками возникали совсем не здесь. Я даже запрещал ему FSM Explorer включать (достаточно было FSM Compiler'а), потому что тот занимался излишними оптимизациями, я потом испытывал дополнительные трудности при отладке (в SignalTap'е), когда искал триггеры, описывающие состояния. Да и откуда взяться траблам, когда мой текст по сути и смыслу мало отличается от сгененернного прогой?

Я как раз писал в общем смысле (статистически при написании людьми).
Я, наоборот, не имел ввиду лично Вас, вы уже писали, что у Вас "рука набита".
А вот когда рука не набита, в графике в этом плане не ошибешься

[quote name='dxp' date='May 19 2006, 08:34' post='114684']
[quote name='CaPpuCcino' post='114542' date='May 18 2006, 21:49']
п 2: вы наверное пока не сталкивались, но на самом деле V2к1 поддерживается на уровне V95 плюс половина из того что есть в 2001 для синтеза. [/quote]
А что из синтезируемого подмножества V2001 Синплифай не поддерживает?

первое что приходит на ум - это ужасная поддержка generate - она здесь на самом базовом уровне, второе - поддержание иерархии проекта на уровне синтаксиса языка, третье кошмарная работа с параметрами функции, ещё можно добавить индексирование полей регистров по переменной вычисляемой на этапе компиляции- это только то что сразу пришло на ум, а если подумать то много ещё нюансов всплывёт
из СВ вообще поддерживается только новое связывание портов и уточнение always блоков - из того что действительно полезно не поддерживается ничего - даже такая простая вещь как перечисляемые типы удобные для state machines - которые поддерживаются тем же симплифаем в синтаксисе ВХДЛ

вот у кого рука не набита - он то её и никогда не набьёт. а тот кто кодирует дисциплинированно и со стилем вряд ли создаст менее эфективный код - вопрос только в скорости ввода - кто любит водить мышькой и щёлкать по разным полям ввода может и выиграет. но вот выиграет ли он если ему придётся переходить на другой графический пакет - вот это меня беспокоит

Вы вообще-то делали БОЛЬШИЕ проекты? Вы пробовали понять почему схематик почти вымер? В схематике сидит одно тупое старичьё с второстепенными проектами, у них всегда на готове обоснование почему надо сидеть в схематике третьего фоундейшена.
Когда я что-то проектирую, я придумываю КАК что-либо должно работать и пишу это на верилоге.
Если бы я сидел на схематике, тоя должен был бы: 1) придумать КАК должно работать нечто, 2) понимание КАК должно работать перевести в примитивы схематика, то есть сделать лишнее действие.

Речь вообще-то шла не о схематике, а о графическом представлении конечных автоматов.
Насчет схематики полностью согласен - геморрой с ней еще тот.

Большие это какие?
А что, синтезаторы все делают как надо?
Кстати писание на HDL, IMHO, тоже можно приравнять к переводу понимания "как должно работать" в примитивы.

А как иначе-то? Что написано, то и делают(работа у них такая).

Пример большого проекта - в одном кристаллле пара микроконтроллеров, развитый алгоритм управления, примерно 1Кслов команд. Управление на десяток ЦАПов, на АЦП, на полсотни реле и силовые ключи.
Примерно описан в статье "Микропроцессор своими руками - 3".
Кто хочет попробовать в "картинках" - напишите, когда нарисуете хотя бы четверть.

Объем чипа не всегда определяет сложность проекта. Можно сделать фильтр обалденной разрядности и порядка и забить им большой кристалл. А бывает что и не очень большой кристалл, но в проекте много логических связей и сложный алгоритм. Вот тогда и приходится все "крутить" по месту.
Так что для сравнения могу сказать, что либо микроконтроллеры, либо автомат на более чем 200 состояний. Вот как Вы это будете все рисовать в "картинках"?
А для текстового описания я сделал свой программный инструмент, который в вериложный файл вставлял куски кода в зависимости от того, что я запрограммировал для микроконтроллера. Например 1 кликом можно выбрать объем памяти команд. Ну и добавлял "прошивку" и дату версии. И это очень удобно.
А еще посмотрите мою статью "Между ISE и ViewDraw". Там тоже описан программный инструмент, которым из нет-листа я сразу генерил вериложный файл с пинами, портами, буферами и т.д.
Очень полезно, когда пинов 400 и более.
Удачи!

Если Вы писали вообще про схематик, то это уже избитая тема...

А вот если про схематик КА (что менее вероятно), то я думаю уже многие согласились, что в графическом описании КА больше преимуществ, чем недостатков.

Мое ИМХО я бы вообще всё писал на Verilog'e (комментить проще) + если проект большой - разделение на "глобальные" функциональными блоки. Но получается удобней (и продуктивней!) КА оформлять в графике.

Ну еслиб я мог написать "Уважаемый верилог поставь триггер", и он бы ставил, я б согласился
Как сказал уважаемый druzhin, выигрыш HDL состоит в том, что можно не отвлекать на то, как реализовывать на основе примитивов. Набросал поведение, а синтезатор сам пусть думает, как это воплотить в жизнь. Здесь и всатет вопрос, а то ли он делает, что имелось в виду.

Конечно то.
А если не то,то всегда можно посмотреть,что он там насинтезил.На крайняк замоделировать то,что насинтезил.Ну,или самое тупое- сделать прошивку,залить в железо и искать причины почему не работает.Благо встоенные логические анализаторы облегчают такую отладку.

Я имел в виду, всегда ли синтезаторы адекватно синтезируют HDL описание. А то может так ссинтезируют, что после разводки шедевра по кристаллу схема не будет работать и на 30 МГц, хотя планировалось 50.


Или затратят слишком много ресурсов.

Я примерно так и делаю :"Уважаемый вхдл поставь триггер" и он появляется.


Синтезаторы синтезируют на столько корректно, на сколько корректно описана схема.

Шутка: можно сходить к хирургу и выпрямить руки, тогда и rtl, прямой будет(всерьез не воспринимать)

От синтезатора мало что зависит. Все упирается в человека.

Если вы в квартусе(схема) поставите триггер на вход D подадите '1', на clk тактовую, а выход q податите на выход, то квартус просто посадит q на '1'.