А как Вы опишете в графике generate, при чём на пару сотен модулей внутри?

никто ведь не запрещает использовать вложения bsf в bsf.

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

ТОП, в нем несколько основных блоков, порты, PLL и как правило мультиплексоры для тестовых выводов.
в основных разделах свои bsf со своим дальнейшим расширением. у них допустимо добавление параметров, поэтому меняющиеся разрядности шин при правильной организации проблемы не составляют.

в итоге очень удобная и наглядная визуализация структуры проекта.
минусы конечно тоже свои есть... но удобство в этом есть вполне определённое.

А если нужно не добавить разряд в шине, а добавить новую шину и вывести её с нижнего уровня на топ?
перерисовывать всю иерархию так ведь? ну что ж ..очень удобно...главное при деле

Это пока единственный минус, который нам реально мешает. Хотя генерэйт на верхних уровнях обычно не требуется. Т.к. описывает просто соединение блоков, а не их поведение.

В коде это тоже не очень красиво и не очень быстро. Да и в графике не так трудно подправить один порт.
У нас была необходимость выводить сигналы не напостоянно, а при отладке. Тогда мы, чтобы не переделывать графику, временно дописывали нужные порты прямо в коде. Когда отладка заканчивалась, достаточно было перегенерировать код из схемы - и всё возвращалось на пути своя.
А чтобы выводить сигналы напостоянно - это нам не требовалось, т.к. в сложных проектах необходимо заранее продумывать интерфейсы стыков между блоками

Это всё "детские" болезни. Пройдёт.


Когда модулей будет реально много, то никакой наглядности там не будет. Наглядность получается, когда можно выделить функционально законченные блоки и показать их связи, причём блоков должно быть в пределах десятка, иначе всё это "размывается", загромождается и сам чёрт ногу сломит. Поэтому куда реальнее набросать структурную схемку проекта (или его частей, которые этого заслуживают) в каком-нить редакторе вроде Visio, и по ней уже писать код. А в Top'е просто описать межсоединения модулей. Только делать это аккуратно, с отступами. И, кстати, поиск (и замену) в тексте делать куда удобнее и средства для этого более развитые.

а уж до чего ляпота смотреть в системе контроля версий кто и что делал %)

Не вижу проблем смотреть то же самое для графики. Средства Mentor типа HDL Designer позволяют это делать. Осталось дождаться нормальной графики для SV.
Ох не люблю я холивары, но всё же...
Для себя остановился на таком подходе - верхний уровень иерархии - всегда графика. Кол-во блоков на верхнем уровне должно соответствовать структурной схеме конфигурации ПЛИС.
Далее - на усмотрение разработчиков этих блоков. При правильном структурированном подходе глубина иерархии 12 - не так уж и страшно.

Согласен. И именно при таком условии мы это используем.

Все тут правы. )
видно что все люди не по одному десятку проектов написали.

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

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

по поводу "добавить в иерархию шину".. такое бывает редко если проведён тщательный предварительный анализ.
во все вложения заранее добавляю тестовую шину, для быстрого вывода произвольных данных наверх.

что удобного?
не надо в разных местах менять иерархию(и в проекте и в сопроводительной визио). она всегда актуальная и наглядная в BSF.
конфигурация графически вставленных PLL и других мег также наглядно видна.
всё же графика позволяет довольно удобно анализировать проект и искать проблемы.

но вообще сейчас новые мелко-проекты стараюсь начинать с кода а не bsf, дабы оценить возможности "тёмной" силы )
удобства от этого окнечно тоже есть свои.

Ещё один минус графического ввода - это привязка к конкретному специализированному инструменту. Например, Active-HDL. А я вот слез с него с третьей попытки (о чём не жалею ни разу) на квесту - и чтоб я делал, если бы у меня часть проектов были в графике?

Если действительно хочется generate в графике, то посмотрите на HDL Designer - он позволяет делать if generate и loop generate специальными рамочками. Изврат редкий, но работает ;-)

Мне вот реально не хватает в графике (как квартуса, так и HDL Designer) возможности комментирования. Не в смысле написать поясняющий текст, а в плане "закомментировать" участок кода (картинки), так, чтобы она никак не обрабатывалась синтезатором, но была легко доступна при необходимости.

alexadmin, можно отключать входы/выходы такого блока. тогда квартус, например, выкинет блок из проекта при оптимизации.

dxp, на основе графики можно сгенерировать код. делов на пол часа и проект переделывается полностью с графики на код.
активHDL вообще очень вроде любил всякие генерации кодов на основе графики. (я кстати когда-то студентом стажировался в Алдеке =) )

Странный пост. Вы же сами написали, что " HDL Designer - он позволяет делать if generate и loop generate специальными рамочками. " Вот возьмите, обведите картинку рамочкой и поставьте IF const_1 = 0 GENERATE .
Вот вам и комментирование участка кода.
Нередко, для того, чтобы сделать универсальный IP блок необходимо по пол схемы через if generate делать. И ничего. А если кому-то понадобится чистый код - он генерится автоматом.
Вообще вопрос удобства настолько индивидуален, что спорить об этом бесполезно. Лучше делиться тонкостями работы с тем или иным САПРом.

Неравнозначно. Конструкции внутри рамочек условной генерации обрабатываются как обычный код. Т.е. синтаксически неверная картинка вызовет ошибку компиляции (генерации VHDL/Verilog текста). Ровно то же самое, как кусок некорректного кода попытаться в VHDL огородить с помощью IF false GENERATE, вместо того, чтобы закомментировать через "--".