Массив векторов -> Сдвиговый регистр Опции

[dxp]

CaPpuCcino, спасибо за подробный ответ.

++,--,+=,/= и т.д. как вы парвильно заметели блокирующие операторы и пользоваться ими нужно в блоках с блокирующими присваиваниями - в СВ это по прежднему так; например ++ в тактируемых блоках я использую только в циклах for (int i ; i<n; i++)
ну а в комбинаторных always_comb пользоваться можно спокойно

Да, я уже разведал этот момент - к сожалению, блокирующие. Блокирующие в таком варианте тоже, конечно, нужны, но и о неблокирующих аналогах тоже можно было бы позаботиться. Не знаю, кому как, а мне анноит писать very_long_name <= very_long_name + ..., хотя редактор с комплешнами тут сильно облегчает жизнь. Да и читабельность была бы лучше у вариантов very_long_name++ и very_long_name += .... Ну, да ладно, ничо не поделаешь.

вообще мне СВ вполне радует - с удовольствием пользуюсь им как при синтезе (typedef, struct, enum, union, interface, void function ...) так и в тестбенчах (+ program, class, rand, ref, class mainbox, array[], array[$]) очень хочется еще внедрить randsequence, constrain и assertion в повседневную жизнь и уже морально созрел - но на практике пока руки не доходят (надеюсь в ближайшем будущем)
периодически на форуме встречаю скептические мнения по поводу СВ, но без какой-либо конкретики - я пока ничего настораживающего в СВ не заметил (как-нить нужно будет поинтересоваться по поводу чего конкретно этот скепсис - любопытно)

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

на данный момент вижу некоторые препятствия в сипользовании СВ:
при синтезе: малое количество синтезаторов нормально поддерживающих СВ

Тут лед, имхо, уже тронулся.

(по поводу Синплифая я уже неоднократно высказывал своё "фе" - ребята конкретно обленились/до смешного/) - из известных мне это ментор и синопсис (пользуюсь первым - однако качество самого синтеза /по плотности упаковки и быстродействию/ ментора и синплисити к сожалению не сравнивал - как-нибудь нужно протестировать)

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

P.P.S.: а вот ещё о наболевшем , пользуясь случаем хочу заметить любителям сравнения СВ с СистемЦ - основная область применения СЦ (IMHO)- моделирование(высокого уровня ), и особенно привлекательна область software/hardware моделирования. спускаться к уровню РТЛ по моим наблюдениям не очень удобно - появляется грамоздкость конструкций на подобие ВХДЛ. поэтому-то к СЦ как можно наблюдать основные синтезаторные компании интереса пылкого не проявляют (года 2 уже)

СЦ, имхо, вполне сносно тянет на синтезируемый язык. Вообще, имхо, язык описания аппаратуры можно сделать на базе практически любого развитого языка программирования - добавить средства параллельности (процессы), события (для поведенческого описания), учесть некоторые нюансы, связанные с этим - типа блокируюих и неблокирующих присваиваний. Преимущества СВ тут перед СЦ проистекают из того, что СВ строится на базе уже готового популярного языка Верилог, для которого полно средств синтеза. Для СЦ это все надо написать, развить. Дорого, а при наличии альтернатив в виде СВ, очевидно не кажется особенно рентабельным. Кроме того, СЦ - это С++, а С++ сам по себе язык очень непростой, его выучить хорошенько - это попотеть надо и опыт плотной работы с ним иметь хотя бы года два-три. Для РС-программистов это не проблема, а вот для инженеров-"аппаратчиков" картина более тусклая. В то время как В и СВ - языки достаточно простые сами по себе - народ на них посадить проще.

[CaPpuCcino]

СЦ, имхо, вполне сносно тянет на синтезируемый язык. Вообще, имхо, язык описания аппаратуры можно сделать на базе практически любого развитого языка программирования - добавить средства параллельности (процессы), события (для поведенческого описания), учесть некоторые нюансы, связанные с этим - типа блокируюих и неблокирующих присваиваний. Преимущества СВ тут перед СЦ проистекают из того, что СВ строится на базе уже готового популярного языка Верилог, для которого полно средств синтеза. Для СЦ это все надо написать, развить. Дорого, а при наличии альтернатив в виде СВ, очевидно не кажется особенно рентабельным. Кроме того, СЦ - это С++, а С++ сам по себе язык очень непростой, его выучить хорошенько - это попотеть надо и опыт плотной работы с ним иметь хотя бы года два-три. Для РС-программистов это не проблема, а вот для инженеров-"аппаратчиков" картина более тусклая. В то время как В и СВ - языки достаточно простые сами по себе - народ на них посадить проще.

agree
есть ещё одно очень важное преимущество в СЦ - возможность вести проект от самой маковки системного уровня до синтезируемого РТЛ в рамках единого(!) языка. однако когда спускаешься до РТЛ уровня меня всё-таки отпугивало обретаемая тяжеловесность конструкций SC на этом уровне и мне было проще проводит mixed simulation с заменой блоков РТЛ уровня верилоговским описаловом (хотя конечно это дело наверное привычки и лености мозгов)
однако мы всё дальше в оффтоп