Почему не хватает родных САПР для ПЛИС?, Зачем нужны 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 и др.
Я могу, конечно, уйти с головой в изучение докумнетации на каждый из этих продуктов, чтоб выяснить их плюсы и минусы и решить стоит мне ими заниматься или нет, но мне все таки хотелось бы услышать пару слов от профессионалов, почему используются дополнительные программы и какие бы они порекомендовали для использования?

[maksya]

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

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

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

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

[makc]

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

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

Synplify принято считать лидером в области оптимизации HDL-описания.

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

Identify можно использовать для внутрикристальной отладки. Однако в ISE 8 вроде как появился аналогичный продукт - ChipScope.

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

[papasha]

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

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

[kst]

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

Раньше я пытался с помощью Foundation разрабатывать 1600 млн. вентилей. Быстро понял, что сделаю проект как раз к пенсии.

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

[Mad Makc]

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

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

[kst]

...but with approximately 20% more gates.

Не хило

Сообщение отредактировал kst - May 16 2006, 14:35

[papasha]

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

Раньше я пытался с помощью Foundation разрабатывать 1600 млн. вентилей. Быстро понял, что сделаю проект как раз к пенсии.

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

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

[kst]

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

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

[Jools]

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

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

Ссылка про ActiveHDL

Прикрепленные файлы

 Aldec_ECOMP_2_2005.pdf ( 369.51 килобайт ) Кол-во скачиваний: 269
 Synplicity.pdf ( 435.04 килобайт ) Кол-во скачиваний: 336

 

[Mad Makc]

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

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

[kst]

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

[kst]

А ваще- зачем спрашивать?Возьмите и попробуйте сами.

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

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

[papasha]

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

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

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

[kst]

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

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

Спасибо!

[Kopart]

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

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

Ссылка про ActiveHDL

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

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

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

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

[vetal]

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

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

[Kopart]

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

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

Altera в своих отчетах по бенчмаркам оговаривает, что синтез был в synplify.

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

Сообщение отредактировал NiOS - May 17 2006, 14:04

[Gate]

А фирмы Sinplicity есть свой пакет? (не Premier ли зовется)

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

[CaPpuCcino]

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

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

[kst]

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

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

[maksya]

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

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

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

[papasha]

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

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

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

[makc]

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

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

[papasha]

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

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

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

[kst]

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

[dxp]

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

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

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

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

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

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

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

[CaPpuCcino]

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

[Джеймс]

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

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

[dxp]

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

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

синтезируемое подмножество SV поддержено процентов на 5 отсилы

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

[dxp]

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

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

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

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

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

[Kopart]

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

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

[dxp]

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

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

[Kopart]

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

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

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

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

[dxp]

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

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

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

[Kopart]

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

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

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

[dxp]

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

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

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

[Kopart]

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

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

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

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

[CaPpuCcino]

[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 - которые поддерживаются тем же симплифаем в синтаксисе ВХДЛ

[CaPpuCcino]

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

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

[druzhin]

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

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

[Very_hard]

Вы вообще-то делали БОЛЬШИЕ проекты? Вы пробовали понять почему схематик почти вымер?

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

[kst]

Вы вообще-то делали БОЛЬШИЕ проекты?

Большие это какие?

Когда я что-то проектирую, я придумываю КАК что-либо должно работать и пишу это на верилоге.
Если бы я сидел на схематике, тоя должен был бы: 1) придумать КАК должно работать нечто, 2) понимание КАК должно работать перевести в примитивы схематика, то есть сделать лишнее действие.

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

[vetal]

А что, синтезаторы все делают как надо?

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

[iosifk]

Вы вообще-то делали БОЛЬШИЕ проекты?

Большие это какие?

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

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

[Kopart]

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

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

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

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

[kst]

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

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

[Mad Makc]

Здесь и всатет вопрос, а то ли он делает, что имелось в виду.

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

[kst]

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


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

[vetal]

"Уважаемый верилог поставь триггер"

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

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

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

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

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

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

[kst]

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

Прям одной строчкой? Прям по русски? Фантастика!!!

Синтезаторы синтезируют на столько корректно, на сколько корректно описана схема.
Шутка: можно сходить к хирургу и выпрямить руки, тогда и rtl, прямой будет(всерьез не воспринимать)
От синтезатора мало что зависит. Все упирается в человека.
Если вы в квартусе(схема) поставите триггер на вход D подадите '1', на clk тактовую, а выход q податите на выход, то квартус просто посадит q на '1'.

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

В данной теме выше приводился пример того как синтезатор ISE при разводке схемы на кристале затратил на 20% больше ресурсов, чем синтезатор Sinplify. То есть синтезаторы все-таки делают какие-то ошибки, не оптимально что-то синтезируют. Вот я о чем говорю.

[des00]

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

Очень интересно, а чем это отличается от рисования схем ? то, что вы попросили от синтезатора, то он и собрал, так как вы указали. И проблема максимальной тактовой это проблема в первую очередь разработчика, т.к. синтезировался его код.
Согласитесь что ждать от
pipa(31 downto 0) <= pipaA(31 downto 0) when (signed(pipaA) < signed(pipaB)) else pipab(31 downto 0);
500 МГЦ на virtex4 это просто смещно и виноват в этом не синтезатор, а человек, который вот это написал.

В данной теме выше приводился пример того как синтезатор ISE при разводке схемы на кристале затратил на 20% больше ресурсов, чем синтезатор Sinplify. То есть синтезаторы все-таки делают какие-то ошибки, не оптимально что-то синтезируют. Вот я о чем говорю.

В данном конкретном примере они не делают ошибки, они понимают описание таким образом, каким понимают + у симплифая большая площадь охвата алгоритма минимизации. И не факт что схематичное описание, переведеное в вхдл и скормленое симлифаю даст такой же выйгрышь (ах какой плохой симплифай).

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

[vetal]

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

Уж ответили. Но я повторю - какой rtl, такой и результат.

Схема - структурное описание алгоритма.
RTL - описание алгоритма на уровне регистровых передач.
Разница - в подходе.

[CaPpuCcino]

...после разводки шедевра по кристаллу схема не будет работать и на 30 МГц, хотя планировалось 50.

счастливые вы ребята

[Джеймс]

[quote name='druzhin' date='May 30 2006, 16:47' post='118516']
[/quote]Вы вообще-то делали БОЛЬШИЕ проекты? [/quote]

А Вы вообще-то топик читали? Какой схематик??
Я посмотрю на большой проект, который по объему наполовину будет состоять из объявлений instance-ов с десятками разных параметров ( - а если к проекту нужно вернуться через год?). В HDL Designer-е я даже ни разу не написал слово module, пишу только полезный КОД.

[dxp]

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

Ну еслиб я мог написать "Уважаемый верилог поставь триггер", и он бы ставил, я б согласился

Фраза "Уважаемый верилог поставь триггер" переводится на Верилог следующим образом:

reg trigger;
always @(posedge clk) trigger <= ...;

Но я на другом хотел заострить внимание. При проектировании логики на HDL нужно уйти от понятий "триггер", "счетчик (простой, реверсивный, по модулю эн и т.д.)", "сдвиговый регистр" и т.д. Цель проектирования - получить работоспособный результат. И при вводе описания мне нужен-то (и всегда был нужен), скажем, не счетчик, как таковой, а некое устройство, которое будет выполнять функцию счета. Во времена рассыпухи таких устройств универсальных не было и делали это на триггерах, потом появилсь ИМС счетчиков, из которых лепили более сложные счетчики. Потом возникли ПЛИСы, где появилась возможность исползовать параметризованные блоки - например, lpm_counter, и казалось, что вот это и есть то, что надо - универсальный счетчик на все случаи жизни подходит, другого нечего и желать. И сам факт, что нужен-то не счетчик, а функция счета, как-то остался в стороне. А между тем, именно HDL'ные конструкции и дают возможность описывать именно функциональность. Например, мне нужно подсчитывать что-то, пишу (упрощено, почти псевдокод ):

Код

...
input event;
reg [N-1:0] Count;

always @(posedge clk)
    if(event) Count <= Count + 1;

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

Когда работал еще с AHDL'ем, использовал в полный рост библиотеку LPM, казалось, клевая вещь. Пересевши на Verilog, тоже пытался по привычке использовать LPM, испытал большое неудобство в использовании - все-таки способ инстанцирования объектов в AHDL, имхо, на порядок удобнее и читабельнее, чем в Верилоге. Но скоро понял, что занимаюсь ерундой, что нет никакой необходимости в этих модулях. В итоге, в проектах нет ни одного LPM модуля, в качестве готовых альтеровских модулей использую только блоки памяти, ФАПЧ и умножители - то, что является специализированными аппаратными устройствами ПЛИС.

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

[Kopart]

Когда работал еще с AHDL'ем, использовал в полный рост библиотеку LPM, казалось, клевая вещь. Пересевши на Verilog, тоже пытался по привычке использовать LPM, испытал большое неудобство в использовании - все-таки способ инстанцирования объектов в AHDL, имхо, на порядок удобнее и читабельнее, чем в Верилоге. Но скоро понял, что занимаюсь ерундой, что нет никакой необходимости в этих модулях. В итоге, в проектах нет ни одного LPM модуля, в качестве готовых альтеровских модулей использую только блоки памяти, ФАПЧ и умножители - то, что является специализированными аппаратными устройствами ПЛИС.

Навеяло воспоминания Я также подпишусь под каждым словом этого абзаца

Думаю, для всех кто работал с AHDL, это типичный путь перехода. Может оформить как краткая инструкция к переходу с языка AHDL

[vetal]

солидарен с dxp.

Все, кроме pll, можно без проблемм реализовать на языке. У altera целый раздел посвящен этому в "настольной книге".

[Kopart]

Все, кроме pll, можно без проблемм реализовать на языке. У altera целый раздел посвящен этому в "настольной книге".

хочу уточнить: что синтезаторы уже стали понимать поведенческое описания блоков памяти??? (для Altera?)

Или просто забыли дописать в посте "Все, кроме pll, блоков памяти и специализированых блоков ПЛИС" как у dxp

[dxp]

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

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

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

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

Все, кроме pll, можно без проблемм реализовать на языке. У altera целый раздел посвящен этому в "настольной книге".

хочу уточнить: что синтезаторы уже стали понимать поведенческое описания блоков памяти??? (для Altera?)

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

[vetal]

Проверил(ram) возможные комбинации с регистровым и нерегистровым и пр. выходами/входами - хрумкает так , что за ушами трещит. Проблеммы могут возникнуть тогда, когда целевая архитектура не поддерживает чудо.(На пример в циклоне ram без регистра адреса/данных не получится).

[dxp]

Проверил(ram) возможные комбинации с регистровым и нерегистровым и пр. выходами/входами - хрумкает так , что за ушами трещит. Проблеммы могут возникнуть тогда, когда целевая архитектура не поддерживает чудо.(На пример в циклоне ram без регистра адреса/данных не получится).

А какой синтезатор? Какая ПЛИС?

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

[vetal]

Проверил(ram) возможные комбинации с регистровым и нерегистровым и пр. выходами/входами - хрумкает так , что за ушами трещит. Проблеммы могут возникнуть тогда, когда целевая архитектура не поддерживает чудо.(На пример в циклоне ram без регистра адреса/данных не получится).

А какой синтезатор?

Synplify 8.5.1.
(Проверял на actel apa и altera cyclone)

[dxp]

А какой синтезатор?

Synplify 8.5.1.
(Проверял на actel apa и altera cyclone)

Ок, отличная новость, в следующий раз обязательно попробую поюзать языковое описание - генерация модулей в мегавизарде, особенно, когда надо что-то подправить, честно говоря, достает. Спасибо.

[des00]

А какой синтезатор?

Synplify 8.5.1.
(Проверял на actel apa и altera cyclone)

Ок, отличная новость, в следующий раз обязательно попробую поюзать языковое описание - генерация модулей в мегавизарде, особенно, когда надо что-то подправить, честно говоря, достает. Спасибо.

я не был бы столь воодушевлен,
для хилых к сожалению симплифай не может:
корректно отображать DWC память,
пайплайнить на внутреннем тригере блоки ROM памяти (8.4 по крайней мере),
вставлять аппаратные фифо блоки (виртекс 4)
+ даже если описать память так:

Код

process (clk) is
begin
  if (rising_edge(clk)) then
     if (we) then
        mem(to_integer(wr_addr)) <= wr_data;
     end if;
     if (re) then
        rd_data <= mem(to_integer(rd_addr));
     end if;
  end if;
end process;

все равно сибирается реально вот что

Код

process (clk) is
begin
  if (rising_edge(clk)) then
     if (we) then
        mem(to_integer(wr_addr)) <= wr_data;
     end if;
     rd_addr_int <= rd_addr;
  end if;
end process;
rd_data <= mem(to_integer(rd_addr_int)) when (re);

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

[dxp]

[...]
я не был бы столь воодушевлен,
для хилых к сожалению симплифай не может:
корректно отображать DWC память,
пайплайнить на внутреннем тригере блоки ROM памяти (8.4 по крайней мере),
вставлять аппаратные фифо блоки (виртекс 4)
+ даже если описать память так:

Код

process (clk) is
begin
[...]
end process;

все равно сибирается реально вот что

Код

process (clk) is
begin
  if (rising_edge(clk)) then
[...]
  end if;
end process;
rd_data <= mem(to_integer(rd_addr)) when (re);

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

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

[vetal]

des00:

...

Это из разряда думаю одно, пишу другое .
Данная конструкция должна выглядить примерно так:

Код

internal_async_result:ram_result<=mem(to_integer(rd_addr));
process(clk)
begin
    if (rising_edge(clk)) then
        ...
        if (re) then
            rd_data<=ram_result;
        end if;
    end if;
end process;

Чем правильнее обьяснишь синтезатору, что хоцца получить, тем точнее он это сделает.
А lpm-ы почти тоже самое, только в них подробнейшим обрасом обьясняется генератору "что делать", а при написании rtl об этом часто забывают и пытаются все запихать в одну строчку.

ЗЫ: Повторяюсь, что считаю наезды на синтезаторы необоснованными, они всего навсего выдают результат, который его просили сделать на основании данных, который у него имеются. А просить надо "учиться, учиться и еще раз учиться" С , не останавливаясь на достигнутом.

Больше всего в rtl на vhdl мне нравится возможность создания самоадаптирующихся модулей. Пример:

Код

entity myram is
    port(
    ...
    data    : std_logic_vector;
    ...
    );
...
type mem_type is array(...) of std_logic_vector(data'range);
...

Если подключить в прожект 3 таких модуля и на вход data подключять шины разной ширины, то подключится 3 разных блока памяти. Самое главное - ничего не надо делать для конфигурирования, оно само сконфигурируется. Слабо такое с lpm повторить без использования generate?

[des00]

Данная конструкция должна выглядить примерно так:

Код

internal_async_result:ram_result<=mem(to_integer(rd_addr));
process(clk)
begin
    if (rising_edge(clk)) then
        ...
        if (re) then
            rd_data<=ram_result;
        end if;
    end if;
end process;

ИМХО в корне не верно, вы описываете выходной регистр, с разрешением, работающий по клоку, тогда как в даташите на блоки памяти явно видно, что такого регистра там нет, а есть всего лишь выходная защелка (pipeline регистр не рассматриваем), а вот как раз адресс чтения там проходит через регистр

пр. ug070.pdf стр. 115 Figure 4-5: Block RAM Logic Diagram (One Port Shown)
более того если посмотреть на ds302.pdf стр. 33 Table 39: Block RAM Switching Characteristics
то можно прекрасно увидеть что Clock CLK to DOUT output (without output register) в 2.2 раза медленнее чем с пайплайн регистром, именно потому, что после защелкивания адреса в тригере, требуеться выборка данных в защелку, а в реальной схеме если на выходе памяти стоит например сумматор, то тактовая вообще проседает, кстати если не ошибаюсь у стратикса/стратикса2 те же самые проблемы, а именно отстутвие асинхронного чтения на блочной памяти.

[/code]
Если подключить в прожект 3 таких модуля и на вход data подключять шины разной ширины, то подключится 3 разных блока памяти. Самое главное - ничего не надо делать для конфигурирования, оно само сконфигурируется. Слабо такое с lpm повторить без использования generate?[/size][/color]

Да все правильно, скажу даже более у меня получалось через генерики подключать pipeline регистры (работало только для RAM, для ROM игнорировалось) и инвертировать клоки, и даже синтезировать память описаную через переменные (чего нет в датшите на симплифай), но не получилось никак описать DWC память, несколько стробов записи собранных на 1 BRAM, также есть определенные проблемы повторяемости при реализации памяти в 9, 18, 36 бит (симлифай 7.х) и при мультипексировании потоков данных на памяти.

Я не утверждаю что этим нельзя пользоваться, но в ВХДЛ я решаю эти проблемы с помошью конфигураций (behavior/structure), так можно упростить симуляцию и не беспокоиться за синтез.

[vetal]

Стормозил. я имел в виду, что если нам нужен регистр на выходе или выходе, то его надо и описывать явно.

...
rd_data <= mem(to_integer(rd_addr_int)) when (re);..

Может все же:

Код

..clk..
if (re) then rd_addr_int <= rd_addr;
endif;
...
rd_data <= mem(to_integer(rd_addr_int));

Иначе зыщелка получается.

[Mad Makc]

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

Код

entity block_ram is
    generic(
    AddrBits : integer := 8;
    DataBits : integer := 8
    );
  port( din  : in std_logic_vector(DataBits-1 downto 0);
        addr : in std_logic_vector(AddrBits-1 downto 0);
        clk  : in std_logic;
        we   : in std_logic;
        dout : out std_logic_vector(DataBits-1 downto 0)
   );
end block_ram;

architecture rtl of block_ram is
type mem_array is array (2**AddrBits-1 downto 0) of std_logic_vector(DataBits-1 downto 0);
signal mem : mem_array;
signal addr_reg : std_logic_vector(AddrBits-1 downto 0);
begin

process(clk)
begin
   if (clk'event and clk = '1') then
     addr_reg <= addr;
     if (we = '1') then
       mem(conv_integer(addr)) <= din;
     end if;
   end if;
end process;

dout <= mem(conv_integer(addr_reg));
end rtl;

[des00]

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

Подозреваю что ваш сарказм вызван не внимательным прочтением постов, да и термин "нормально делать блочную память" у каждого свой, на досуге попробуйте заставить симплифай написать вот такую блочную память, БЕЗ использования CLB
2 порта:
1ый порт чения/записи 512х32 бита, 4 строба записи, по каждому на 8мь бит, выход через pipeline регистр, режим работы любой.
2ой порт чтения/записи 2048х8, выход через pipeline регистр, режим работы write_first.

2 vetal

Иначе зыщелка получается.

ug070.pdf стр. 112

Read Operation
The read operation uses one clock edge. The read address is registered on the read port,
and the stored data is loaded into the output latches after the RAM access time.

тот же pdf стр. 115 Figure 4-5: Block RAM Logic Diagram (One Port Shown)

Из этого рисунка следует что адрес чтения/записи "хлопает" в регистре всегда, а операции чтения/записи определяеться сигналами we/ena что в моем коде заменено на we/re. И при чтении данные по стробу храняться в выходной защелке.

В своем примере я привел код, более близкий к реальному устройству bram памяти от хилых и указал, что в симплифае реально при сборке идет по-сути подмена первого кода, на второй. Но при этом нет никаких диагностических сообщений об этом (о расхождении желаемого и действительного) , кроме сообщения об обнаружении bram памяти.

[D-Luxe]

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

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

Интересно зачем нужны одновременно Sinplify Pro + ISE ? Разве одного продукта недостаточно. Если вы используете оба, то как разделяете функции между ними.

В ActiveHDL понятно будет ввод и симуляция дизайна. А вот связка Sinplify Pro + ISE зачем нужна неясно.

[DevL]

Интересно зачем нужны одновременно Sinplify Pro + ISE ? Разве одного продукта недостаточно. Если вы используете оба, то как разделяете функции между ними.

В ActiveHDL понятно будет ввод и симуляция дизайна. А вот связка Sinplify Pro + ISE зачем нужна неясно.

не довелось пока работать с ISE , у меня Quartus ...

но тоже раньше задумывался об этом же - однако быстро понял, вот последний пример
http://electronix.ru/forum/index.php?showtopic=93048

где синтезис от Quartus работал , но одновременно делал проблемы...
Synplify Pro - четко дал понять где именно проблема и решилася она за 5 мин.
( а это только недобольшой хобби проект )

в итоге - многое от недостатков HDL/Verilog, вернее многих неоднозначностей которые могут получиться если их использовать
а других и лучших языков нет

вопросы еще более правильного и компактного синтеза - это я думаю еще бОлее широкая тема...

в Quartusе - переход на Synplify очень прозрачен - один чек бокс и выбор EDIF/VQM

[Timmy]

Интересно зачем нужны одновременно Sinplify Pro + ISE ? Разве одного продукта недостаточно. Если вы используете оба, то как разделяете функции между ними.

XST не поддерживает SystemVerilog, и более корявый и глючный. Интеграция Sinplify в ISE стандартно предусмотрена, и делается элементарно.

[Victor®]

XST ..., и более корявый и глючный.

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

[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 я когда-то "пошутил" с сигналами такта и сброса.

[des00]

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

вы что издеваетесь? Напомню что речь идет про сабжевый код

Код

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

Думаю что сами исправите свою ошибку %)

[ViKo]

вы что издеваетесь?
Думаю что сами исправите свою ошибку %)

А если присваивания блокирующие? Посмотрите, что получается при компиляции следующего кода (я пользуюсь Quartus 9.1 SP2).

Код

module Trigger (input clk, rst_n, in, output out);
  always_ff @(posedge clk, negedge rst_n) begin
    if (clk) out = in;
    if (!rst_n) out = 0;
  end
endmodule

Можете переставить строки в блоке местами %.
ЗЫ. И _ff ему, Quartus'у, нипочем...
ЗЗЫ. Да и неблокирующие присваивания не помогают. Не получается у Quartus'а триггер, а получается - ...!
Похоже, издевка удалась, но не у меня.

[Timmy]

А если присваивания блокирующие? Посмотрите, что получается при компиляции следующего кода (я пользуюсь Quartus 9.1 SP2).

Код

module Trigger (input clk, rst_n, in, output out);
  always_ff @(posedge clk, negedge rst_n) begin
    if (clk) out = in;
    if (!rst_n) out = 0;
  end
endmodule

Этот код вовсе не соответствует шаблону, который я приводил. Оператор "out = in;" тут выполняется не только по фронту clk, но и по фронту rst_n(при условии clk==1), чего допускать нельзя. Как написать полный аналог моего VHDL метода асинхронного сброса на Верилоге, я, честно говоря, даже не представляю. В Верилоге вроде нет функции проверки фронта сигнала, а без неё никак.

[ViKo]

... Как написать полный аналог моего VHDL метода асинхронного сброса на Верилоге, я, честно говоря, даже не представляю. В Верилоге вроде нет функции проверки фронта сигнала, а без неё никак.

Похоже на то.
А des00 сказал "в V, SV абсолютно тоже самое".

[des00]

А если присваивания блокирующие? Посмотрите, что получается при компиляции следующего кода (я пользуюсь Quartus 9.1 SP2).

Код

module Trigger (input clk, rst_n, in, output out);
  always_ff @(posedge clk, negedge rst_n) begin
    if (clk) out = in;
    if (!rst_n) out = 0;
  end
endmodule

Можете переставить строки в блоке местами %.
ЗЗЫ. Да и неблокирующие присваивания не помогают. Не получается у Quartus'а триггер, а получается - ...!

У вас очень интересный способ аргументации.
Вместо того, что бы посмотреть стандарт на HDL, раздел касающийся присвоений сигналов и очередей исполнения. Убедится что в VHDL/V/SV любое присвоение сигнала, без задания временной задержки переопределяет все предыдущие присваивания.
Вы берете синтезатор(!!!!) как истину в последней инстанции, пишете код, который вступает в противоречие как с требованиям самого синтезатора, так и со стандартом на описание синтезируемых конструкций языка V (не знаю есть ли подобный документ для SV).

И предъявляете этот результат как однозначное опровержение того, что стандарты врут. Вам не кажется что вы, пытаясь доказать от противного, идете не по тому пути?

Если идти дальше, насчет вашего кода, то в симуляторе он ведет себя как триггер. А то что вас "напугало" в результатах синтеза, представляет собой классический двухтактный триггер, но без RS звена. И это будет работать, так как вы его описали, как триггер. А то что реализован не на аппаратных DFF, дык надо было стандартам следовать, код писать как рекомендуется.

Похоже, издевка удалась, но не у меня.

Это сообществу решать

А des00 сказал "в V, SV абсолютно тоже самое".

Если бы это было не так то ~40-50 % моих проектов в принципе бы не работали.

Эскизы прикрепленных изображений

 

[ViKo]

У вас очень интересный способ аргументации.
Вместо того, что бы посмотреть стандарт на HDL, раздел касающийся присвоений сигналов и очередей исполнения. Убедится что в VHDL/V/SV любое присвоение сигнала, без задания временной задержки переопределяет все предыдущие присваивания.
...
Если идти дальше, насчет вашего кода, то в симуляторе он ведет себя как триггер. А то что вас "напугало" в результатах синтеза, представляет собой классический двухтактный триггер, но без RS звена. И это будет работать, так как вы его описали, как триггер. А то что реализован не на аппаратных DFF, дык надо было стандартам следовать, код писать как рекомендуется.

Я согласен, что был неправ в первом сообщении. И не доказываю свою правоту любым способом. Просто выясняю истину.
Переопределяет все предыдущие...? Разве блокирующее присваивание дожидается выхода из блока, а не задает сигнал каждый раз, когда выполняется? Посмотрю.
Но уже при проверке в реальном коде выяснилось, что для SV получается не тактируемый триггер, а latch. И временные диаграммы, что Quartus мне нарисовал, триггеру не соответствуют. Чего это у вас in скачет перед "нужными" тактами?

Это сообществу решать

По-моему, вы тоже были неправы, когда сказали, что в V, SV то же самое, что и в VHDL. Зачем что-то решать и кому-то доказывать? Обычные дела. Главное, выяснилось, что в SV конструкция, предложенная Timmy, не работает. Такой результат дискуссии меня устраивает. Надеюсь, что и вас.

upd. Картинку из Квартуса добавил.

Эскизы прикрепленных изображений

 

[Singer]

Уважаемые специалисты, нет ли у кого актуальной информации по порядку цен на одно лицензионное рабочее место на связку
Hdl Designer + Precision RTL + Model Sim SE ?

[Stewart Little]

Уважаемые специалисты, нет ли у кого актуальной информации по порядку цен на одно лицензионное рабочее место на связку
Hdl Designer + Precision RTL + Model Sim SE ?

Обратитесь в Мегратек
Они официальные представители Ментора в России.

[des00]

Уважаемые специалисты, нет ли у кого актуальной информации по порядку цен на одно лицензионное рабочее место на связку
Hdl Designer + Precision RTL + Model Sim SE ?

хмм, ну где то миллиона под 2 %)

[warrior-2001]

хмм, ну где то миллиона под 2 %)

А вдруг это учебное заведение?

Лучше все таки воспользоваться советом Stewart Little.
Да и моделсим не так дорог, в отличие от Questasim.