Jump to content
    

Какой язык учить?

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

+1

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

20100621_5.gif

 

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...