[Flip-fl0p 4]

1 час назад, [email protected] сказал:

На счет ModelSim согласен с Вами, там все гораздо быстрее получается. И да, дизайн ModelSim убогий и нелогичный. Vivado только начал осваивать.

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

Раз уж тут все так весело понеслось)) еще один вопрос не по теме. Вопрос к опытным разработчикам ПЛИС.
Что же выбрать на перспективу VHDL, Verilog или System Verilog? Стандартный ответ о Си подробности Верилогов, его лаконичности и консерватизма VHDL становится ясно из учебников и большинства статей о ПЛИС. Интерисует больше о перспективности... и кто из них более оптимален с чтоки зрения используемых ресурсов ПЛИС. Может еще какие особенности? 

Сам пишу на VHDL, мне он больше всего нравится. Но сейчас в процессе освоения SystemVerilog.  В плане синтеза - оба языка примерно равны по возможностям(хотя это неточно, т.к я только в процессе изучения SystemVerilog). Однако в плане тестирования SystemVerilog сильно уходит вперед. 
Немаловажным фактором при работе на VHDL является то, что поддержка VHDL в софте сделана крайне убого, ибо все что генерируется автоматически - поддерживает только один тип (std_logic/std_logic_vector).
Согласен, cофт не знает с каким типом порта будет соединияться генерированный HDL. Так-же можно простить то, что генерированные IP ядра не понимают цельночисленные типы (integer, natural, positive) из-за их ограничений. Допустим можно понять, почему отказались от типа bit/bit_vector - его применение может привести к ошибкам моделирования, т.к не хватает в нем неинициализированного значения,и при симуляции IP ядро может работать неправильно. Но почему всё генерируется только в std_logic/std_logic_vector а не в std_ulogic/std_ulogic_vector - для меня загадка. Но и фиг с ним. Это мелочи на самом деле, если я вставляю генерированные IP ядра в свои HDL описания.
Гораздо хуже обстоит то, что например пресловутый block design не умеет в VHDL2008. На дворе 2019 год...  Но это ещё пол беды. Почему при автоматической генерации "прокладок" для пользовательских HDL описаний, которые были вставлены в block design - не генерируется автоматитческое преобразование типов к целевому IP ядру ? Странно это. Сдается мне, что разработчики Vivado - тайные ненавистники VHDL. Ибо если даже обратить внимание на генерированные файлы, то у верилоговских файлов даже выравнивание текста есть, в отличии от VHDL 

А вообще как мне кажется начинать правильнее с VHDL - он приучит думать правильно.

[[email protected] 0]

5 minutes ago, Flip-fl0p said:

Сам пишу на VHDL, мне он больше всего нравится. Но сейчас в процессе освоения SystemVerilog.  В плане синтеза - оба языка примерно равны по возможностям(хотя это неточно, т.к я только в процессе изучения SystemVerilog). Однако в плане тестирования SystemVerilog сильно уходит вперед. 
Немаловажным фактором при работе на VHDL является то, что поддержка VHDL в софте сделана крайне убого, ибо все что генерируется автоматически - поддерживает только один тип (std_logic/std_logic_vector).
Согласен, cофт не знает с каким типом порта будет соединияться генерированный HDL. Так-же можно простить то, что генерированные IP ядра не понимают цельночисленные типы (integer, natural, positive) из-за их ограничений. Допустим можно понять, почему отказались от типа bit/bit_vector - его применение может привести к ошибкам моделирования, т.к не хватает в нем неинициализированного значения,и при симуляции IP ядро может работать неправильно. Но почему всё генерируется только в std_logic/std_logic_vector а не в std_ulogic/std_ulogic_vector - для меня загадка. Но и фиг с ним. Это мелочи на самом деле, если я вставляю генерированные IP ядра в свои HDL описания.
Гораздо хуже обстоит то, что например пресловутый block design не умеет в VHDL2008. На дворе 2019 год...  Но это ещё пол беды. Почему при автоматической генерации "прокладок" для пользовательских HDL описаний, которые были вставлены в block design - не генерируется автоматитческое преобразование типов к целевому IP ядру ? Странно это. Сдается мне, что разработчики Vivado - тайные ненавистники VHDL. Ибо если даже обратить внимание на генерированные файлы, то у верилоговских файлов даже выравнивание текста есть, в отличии от VHDL 

А вообще как мне кажется начинать правильнее с VHDL - он приучит думать правильно.

К сожалению, в связи с тем что только осваиваю ПЛИС, не все понял. Надеюсь в ближайшее время смогу полностью постичь о чем Вы написали. Но Ваши настроения по поводу VHDL уловил))

На Ваш взгляд какой язык выглядит более перспективным. Лазя по интернету складывается ощущение, что VHDL медленно уступает место Verlog и System Verilog (возможно мне только показалось). Ну соответственно почему Вы выбрали SV, а не просто Verilog? В чем их отличия?

[Flip-fl0p 4]

3 часа назад, [email protected] сказал:

К сожалению, в связи с тем что только осваиваю ПЛИС, не все понял. Надеюсь в ближайшее время смогу полностью постичь о чем Вы написали. Но Ваши настроения по поводу VHDL уловил))

На Ваш взгляд какой язык выглядит более перспективным. Лазя по интернету складывается ощущение, что VHDL медленно уступает место Verlog и System Verilog (возможно мне только показалось). Ну соответственно почему Вы выбрали SV, а не просто Verilog? В чем их отличия?

SV выбрал по одной простой причине - SV по возможностям гораздо ближе к VHDL, чем Verilog. В частности перечисляемые типы, удобные для описаний автоматов, тип logic. Но не это главное. У SV гораздо больше возможностей для написания тестов. А тестирование и верификация, как правил, занимают гораздо большую часть времени разработки. Да и SystemVerilog - это фактически тот-же verilog.

[[email protected] 0]

1 minute ago, Flip-fl0p said:

SV выбрал по одной простой причине - SV по возможностям гораздо ближе к VHDL, чем Verilog. В частности перечисляемые типы, удобные для описаний автоматов, тип logic. Но не это главное. У SV гораздо больше возможностей для написания тестов. А тестирование и верификация как правильно занимают гораздо больше часть времени разработки. Да и SystemVerilog - это фактически тот-же verilog.

Ну, пожалуй у меня последний вопросик: По объему изучения эти языки большие? сравнимо, грубо, с Си (Си++) или что-то среднее меджу Си и ассемблер?

[Flip-fl0p 4]

2 часа назад, [email protected] сказал:

Ну, пожалуй у меня последний вопросик: По объему изучения эти языки большие? сравнимо, грубо, с Си (Си++) или что-то среднее меджу Си и ассемблер?

К сожалению я С/С++ почти не владею. Был институтский курс. Но на практике я его никогда не применял. 

Если сравнивать VHDL с SystemVerilog - то y последнего гораздо больше по объему стандарт (~1300 страниц) в то время как у VHDL ~200 страниц. Однако как тут многие говорили, и как я убедился на практике, у SystemVerilog стандарт написал более простым языком и очень много примеров. Но я пока не освоил SystemVerilog, поэтому объективно оценить этот язык я не могу.

[gosha-z 3]

3 hours ago, [email protected] said:

Ну, пожалуй у меня последний вопросик: По объему изучения эти языки большие? сравнимо, грубо, с Си (Си++) или что-то среднее меджу Си и ассемблер?

А вот путать языки программирования и языки описания оборудования не стОит. Равно как и сравнивать их не совсем корректно.

[Alex77 4]

Я не Гуру. Мои пять копеек.

1 - не надо путать "берега": блок-дизайн и язык описания схемы. Одно есть надстройка на другим. И для упрощения автоматизма блокдизайна "пожертвовали" типами данных.

2 - если выбирать из сей троицы - то SV. По моиму ИМХУ:

vhdl - громоздкое описание (много букв, мало "смысла")

verilog - это бета версия SystemVerilog. Например в SV более точно описано что и как инициализируется. Уточнены виды данных (переменные и цепи) и типы данных (те диапазон значений). Продвинутое тестирование. итд итд

Так что мой выбор SV.

3 - а если посмотреть со стороны: все три языка идут "лесом", на фоне новых плис (для "аля ИИ") там наверно будут писать только на чемнибудь похожем на С++.

другими словами (если проводить аналогии с программированием) это как АСМ и ЯВУ. Для толстых плис ЯВУ, а там где требуется "полировка" по ресурсам/быстродействию там vhdl/sv.

 

[[email protected] 0]

Спасибо всем за помощь!

[andrew_b 17]

Кстати, когда-то в узких кругах было такое выражение: "Читайте доки, они рулез". Сейчас полез в ug1118-vivado-creating-packaging-custom-ip.pdf, там прямо написано:

Цитата

The IP packager does not support VHDL-2008.

 

[SII 0]

Если говорить про синтез, то лучше использовать, например, Precision, а не штатный XST. Правда, подцепить его к Vivado не так-то просто (мне сходу не удалось, поэтому забил пока что: всё равно почти всё, что делаю, можно сделать в ISE, а она в большинстве случаев работает куда лучше, чем Vivado, и не годится лишь в случаях, когда нужно иметь дело с последними ПЛИСинами, которые в ISE просто не поддерживаются). В частности, Precision без проблем "кушает" VHDL 2008 в полном (вроде как) объёме.

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

Что касается языка... Качество "кода", т.е. используемые ресурсы ПЛИС вообще никак не зависят от языка, ибо компиляторы переводят что VHDL, что Verilog в некий внутренний формат, и дальнейшая генерация идёт уже из этого формата. Уметь читать на всех этих языках надо обязательно. Ну а на чём писать, зависит от требований работодателя или от личных пристрастий. Я, например, предпочитаю именно VHDL за более строгий и чёткий синтаксис, нормальную модульность и т.д. Хотя Верилог, похоже, более популярен (скорей всего, из-за той самой псевдопохожести на Си -- хотя похожест сразу кончается, когда вместо ожидаемых { } в Верилоге видишь типично паскалевские begin-end, а { } хоть и есть, но употребляются в совсем другом смысле).

[des00 25]

VHDL, Verilog, SVerlog .....все это выбор улиток, нужна скорость разработки, берите HLS (с) - это с семинара xilinx  сегодняшнего)

[lexx 0]

Используя HLS вы все отдаёте на исполнению синтезатор. Я не говорю, что это плохо, возможно получаемя схема будет гораздо больше и в случае ECO(ASIC) небольшими изменениями тут уже не обойдёшься. Но это сильно снижает минииальный уровень разработчика и ускоряет процесс дизайна.