[Oldring 0]

1) конфигурации, ни разу не использовал

 

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

 

а вот отсутствие препроцессора это плохо. условной компиляцией через if generate много не сделаешь (и до кучи :) там else нету)

 

И не надо. Сишный препроцессор - очень сильная и опасная штука. Мне до сих пор generate хватало. Else - да, не было, но это не очень сильное ограничение. В 2008 будет.

 

всегда в коде закоментированные блоки, откоментированные блоки

 

Редактор комментирует группу строк - нормально.

 

2) требование component->use->package лишней писанины (я знаю, что в 98(?) стандарте можно инстанциировать entity, но это же не путь тру-VHDL)

 

Давно можно. Что есть тру-VHDL - это спор философский.

 

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

 

Поясните. Не понял совсем, какой именно тупик. Давно для счетчиков пользую в основном целочисленные типы.

 

Все эти пакеты - это расширение языка, которое каждый может написать под себя. Как в каждом нормальном языке. Знаете ли, при написании каждой мало-мальской программы немало времени тратится на написание инструментария, облегчающего написание этой программы. В смысле, библиотек. Это - нормально, альтернатива - Бейсик, который всегда лучше знает, что тебе нужно. :)

 

4) убогий ввод-вывод, каждый пишет свою библиотеку

 

То же самое. В 2008 вроде бы расширили.

У каждого свои требования.

 

5) отсутствие иерархических путей (через .) и полезных системных функций

 

Для доступа внутрь чужих модулей? Для отладки? Иерархические имена есть, но доступа к кишкам нет, верно.

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

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

 

6) resolved и unresolved логику (ну типа библиотеки рассматриваем как часть языка, ведь чистый VHDL вообще ни для чего не годен)

 

Хорошо что есть. Категорически не люблю использовать resolved типы. Для всего, кроме шин, resolved считаю вредными: для большинства сигналов более одного драйвера - это ошибка.

 

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

 

7) была какая-та муть с дразверами - верилог-симулятор добавляет все драйвера в стек событий, а у VHDL этого нет - там просто убивается старый драйвер, ну и вообще с delta циклом у верилога гораздо продуманей все, а в SV даже стандартизовано (в VHDL аналога #0 нету)

ну и еще наверно можно придумать....

с необходимостью разделения на signal и variable можно поспорить

 

Как раз дельта-циклы были стандартизованы в VHDL очень хорошо с самого начала.

В отличие от Верилога (насколько мне известно), в VHDL результат симуляции никогда не зависел от порядка исполнения процессов. Активные процессы могут исполняться хоть параллельно без побочных эффектов. До тех пор, правда, пока программист не начинает пытаться использовать на свой страх и риск shared variables, добавленных в VHDL не помню когда. :)

Отсюда и отличие signal-variable, так как нужно отличать изменение значения только в следующем дельта-цикле от изменения значения сразу.

 

Что такое #0?

[gosu-art 0]

А кто нить нибудь использует БЛОКи при синтезе?

[Shtirlits 0]

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

Шутка.

Не использую.

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

[Des333 0]

Мне стыдно, но я не знаю, что такое блоки. :)

Не просветите?

[Shtirlits 0]

http://www.cs.umbc.edu/portal/help/VHDL/concurrent.html

 

PS: работал чудо-дизайн с блоками в modelsim 6.6a и ISE 11.5. К block statement претензий не было.

[des00 25]

Мне стыдно, но я не знаю, что такое блоки. :)

Не просветите?

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

[yes 6]

по пунктам не осилю,

 

кажется очень несерьезым

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

 

это проходит, когда один человек (ну или маленькая группа: "гуру"+пара подмастерьев) и соответствующий размер дизайна

 

а когда взрослые проекты, несколько групп, использование чужих IP или собственного кода через пару лет,

когда необходимо найти/нанять кого-то кто сможет быстро вникнуть в проект, а не во "внутренние фирменные библиотеки"

тогда стандартизация библиотек не менее важна, чем стандартизация языка, имхо

и за всякие "хитрости" типа индусского/китайского кода (включая свои библиотеки) в реализации бить по рукам исполнителя беспощадно :)

 

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

но стандартизация тестбенчей, всяких драйверов, агентов, скоребордов стоит того

все-равно эти сущности присутствуют в проектах, но нужно совершить некоторое усилие и от хоме-брю реализации перейти на стандартизованое

 

ну и повторюсь : верификация она в сотни раз трудоемчее дизайна, поэтому SV, имхо, безальтернативен на 95%

возможно, что альтернатива SC (это отдельная тема), но ни в коем разе VHDL

 

Отсюда и отличие signal-variable, так как нужно отличать изменение значения только в следующем дельта-цикле от изменения значения сразу.

 

Что такое #0?

 

в Verilog такого разделения нету, а описать ту же конструкцию без проблем, как так? получается избыточность в VHDL

 

в SV пошли еще дальше (прогресс, однако :)) и отказались от reg/wire - там теперь есть тип logic (ну или bit, что тоже актуально для экономии памяти)

 

#0 это конструкция чтобы детерминировать поведение shared variable - переместить исполнение в последний момент дельтацикла, я ее не одобряю, но она есть

 

и по-моему variable VHDL она не имеет отношения к дельта-циклам, это некоторая специальная "мгновенная" сущность и проблемы с VHDL-ными дельта-циклами (процессами и сигналами, а не variable) начинаются в VHDL-ных тестбенчах, а в RTL коде в силу требований на синтезируемость их нету. но я с VHDL-ными тестбенчами имел мало дела - может не умею готовить

 

[Oldring 0]

это проходит, когда один человек (ну или маленькая группа: "гуру"+пара подмастерьев) и соответствующий размер дизайна

 

а когда взрослые проекты, несколько групп, использование чужих IP или собственного кода через пару лет,

когда необходимо найти/нанять кого-то кто сможет быстро вникнуть в проект, а не во "внутренние фирменные библиотеки"

тогда стандартизация библиотек не менее важна, чем стандартизация языка, имхо

и за всякие "хитрости" типа индусского/китайского кода (включая свои библиотеки) в реализации бить по рукам исполнителя беспощадно :)

 

Слушайте, во "взрослом программировании" давно эти же задачи решены. И Верилог, как мне кажется, как раз для RAD не лучший вариант.

 

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

но стандартизация тестбенчей, всяких драйверов, агентов, скоребордов стоит того

все-равно эти сущности присутствуют в проектах, но нужно совершить некоторое усилие и от хоме-брю реализации перейти на стандартизованое

 

ну и повторюсь : верификация она в сотни раз трудоемчее дизайна, поэтому SV, имхо, безальтернативен на 95%

возможно, что альтернатива SC (это отдельная тема), но ни в коем разе VHDL

 

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

 

в Verilog такого разделения нету, а описать ту же конструкцию без проблем, как так? получается избыточность в VHDL

 

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

 

По поводу #0. Это, видимо, стырили из VHDL postponed процессы.

 

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

[Intekus 0]

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

ИМХО, это (блок) - что-то типа самого verilog'а; в некоторых случаях даже несложный модуль логически распадается на подсхемы, сильно связанные "внутри" каждой - и тогда:

глобальные соединения - wire / reg / logic

wire / reg / logic подсхемы#0
always подсхемы#0

wire / reg / logic подсхемы#1
always подсхемы#1

...

wire / reg / logic подсхемы#n
always подсхемы#n

Просто для наглядности - чтоб переменные / сигналы и использующий их код были рядом. А в VHDL переменные / сигналы обязательно должны идти перед begin-end архитектуры - поэтому так организовать код можно, только выделив каждый кусок в блок.

А в SV с наглядностью ещё проще чем в чистом V: переменные вообще могут объявляться локально :)

#0 это конструкция чтобы детерминировать поведение shared variable - переместить исполнение в последний момент дельтацикла, я ее не одобряю, но она есть

По-моему, #0 смещает стоящее за ней после всех дельта-циклов (т. е. симуляционных аналогов отработки слоёв комбинационной логики без задания конечных задержек), когда все переменные уже "утрясутся", и смулятор будет готов двигать модельное время вперёд к следующему запланированному событию. В этом и логика конструкции #0 - "сдвинуть модельное время на 0" - выполнить все предшествующие этому дельта-циклы, но само текущее время пока не менять. Или я неправильно понял понятие "дельта-цикл"?