[andrew_b 15]

А объявить модуль? ))

direct instantiation

[dxp 53]

UPD. Меня вот begin/end в верилоге бесят. ну чем им С-шные {} не понравились... Тем, что такой же оператор объединения сигналов? Ну и что, оно и там и тут одновременно смотрелось бы на отлично!

+1

 

UPD2. Хотя, конечно, кому как... Людям с крепкой непробиваемой психикой, возможно, с VHDL очень даже комфортно.

Видел программу на С, там самом главном заголовке начиналось так:

...
#define begin {
#define end   }
...

Ну, и далее по тексту программы можно представить, как она выглядела. :)

[Maverick_ 15]

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

PS мое мнение здесь все зависит от внутренних предпочитаний и/или производственной необходимостью (если принят какой-то язык как основной и является обязательным в использовании)

PS PS холивар на эту тему не однократно поднимался. ТС, если интересно воспользуйтесь поиском...

[alexadmin 0]

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

 

Ну тут совет только один - физкультура по утрам, прогулки на свежем воздухе, достаточный сон

[SM 0]

достаточный сон

Так целыми днями сплю после плодотворной работы :) :) У меня, так сказать, вахтовый метод, сразу нахрапом взять все в круглосуточном режиме, а потом отдыхать

[Мур 1]

Если учесть, что 80% времени мы работаем в симуляторе,- технологии отладки серьезно влияют на качество продукта. SV в этом смысле самый продвинутый! Там все вкусности...

[SM 0]

Если учесть, что 80% времени мы работаем в симуляторе...

 

Это ведь когда в симуляторе, а когда и нет... По своему личному опыту, при работе именно с FPGA, 99% всей отладки происходит в реальном железе по ходу дела, без всяких симуляторов, с выводом нужных потоков данных и выводом тест-сигналов на тест-пины или через какие-то интерфейсы, и с их анализом осциллографом, лог. анализатором, и др. методами (ну просто реально быстрее в разы, чем писать тест-бенч на каждый чих). И лишь не более 1% случаев требуют симуляций, когда ну совсем не понятна причина неработоспособности, обычно же по косвенным признакам все быстро понимается, где ошибка. Много симуляций было в начале пути (и вот там они реально нужны, для понимания, что и как), потом они как-то сами по себе стали лишними, все без них эффективно запускается.

 

Бесконечные симуляции и долгие и сложные тестбенчи начинаются уже для ASIC, чтобы получить наборы тест-векторов с максимальным покрытием для тестирования годен/не годен, а для FPGA симуляции отходят на стопятидесятый план...

[Мур 1]

Это ведь когда в симуляторе, а когда и нет...

Это общепринятая статистика. Не я её придумал...

[SM 0]

Это общепринятая статистика. Не я её придумал...

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

[sazh 5]

а не по разработчикам

 

А рулить такими разработчиками есть хоть какая нибудь возможность?

 

[SM 0]

А рулить такими разработчиками есть хоть какая нибудь возможность?

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

 

Разумеется, если Вы производите устройство, а не пишете IP-ядра на продажу без привязки к железякам, там 100% симуляций, но это и совсем другая тема, таких контор раз два и обчелся.

[Golikov 0]

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

 

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

[Мур 1]

 

Сложность проектов разная. Проверить себя всегда стоит...

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

[SM 0]

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

 

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

 

Но! Если цель - железо, а не продажа модуля, то все равно потом:

- подключать к ногам

- запихивать в готовое железо

- отлаживать, чтобы оно там не глючило

- писать тест-софт, или делать тест-девайс, или и то и это для готовой продукции.

 

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

[fpgaz 0]

Симуляцию во многих случаях никакими осциллографами и логическими анализаторами не заменишь в силу физических ограничений.

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

Пустил тестбенч и пошел спать, а он в это время гоняет схему под нагрузкой при внешних возмущениях. Лепота!

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

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

А осциллографы и анализаторы - это обязательно, но для финальных проверок и успокоения.