[1891ВМ12Я 0]

Любопытно, и сколько же времени топикстартер убил на поиск такой ошибки?

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

[Inanity 1]

Любопытно, и сколько же времени топикстартер убил на поиск такой ошибки?

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

 

Да, если честно сказать не так то и много, мне повезло. Проблема с implicite wire была давно, я тогда где-то день просидел, коллега помог. Проблема с пропавшей шиной случилась недавно. Часа 3 всматривался в правильный код и не мог понять в чём дело. Когда chipscope тоже не смог найти мою шину я заподозлил что-то неладное и полез в схематик. Warning, связанный с этой шиной звучал дословно так:

-- Line 244: Assignment to fifo_data_count ignored, since the identifier is never used

 

Т.е. в модуле верхнего уровня есть друг с другом общающиеся модули А и В. Шина fifo_data_count соединяла эти модули. Я так понимаю, что парсер увидел, что в модуле назначения эта шина (ошибочно) назначена как выход, а не вход и с чистой совестью её выпилил.

 

Я свою ошибку осознал, но с логикой работы компилятора я не согласен. Поскольку этот warning, извините, крайне неинформативен. Далеко ходить не надо, вот к примеру (проект в ISE 14.7), фирменная сгенерированная корка PLL. У PLL есть вывод LOCKED, который я при настройке ядра отключил. В итоге в логах вижу следующий warning:

-- Line 130: Assignment to locked_int ignored, since the identifier is never used

 

Казалось бы, всё верно, в шаблоне корка написана так, что где-то внутри этот порт есть, на нём висит провод locked_int, но из топового модуля LOCKED не торчит и соответственно у меня он никуда не подключен, оттуда и warning на висящий в воздухе locked_int. Но извините меня! Две ситуации генерирующие warning одно и того же типа и содержания нельзя назвать одинаковыми! Компилятор verilog не проверяет направление портов модулей и лично я это считаю просчётом.

Изменено 10 мая, 2016 пользователем Inanity

[yuravg 0]

Есть же LINT средства для HDL. Используйте на этапе написания кода, тогда большинства ошибок не будет.

Подскажите, чем сами пользуетесь или что рекомендовали бы?

Изменено 10 мая, 2016 пользователем yuravg

[des00 25]

Есть действительно хорошие примеры таких программ?

 

Подскажите, чем сами пользуетесь или что рекомендовали бы?

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

[FatRobot 0]

Из свободных

Verilator

 

Из платных

Cadence HAL

Atrenta Spyglass. C 2015 - Synopsys Spyglass

Synopsys Leda

 

Lint надо аккуратно настроить под ваши внутренние стандарты, которые, скорее всего, далеки от rmm. Это потребует некоторого времени. Но вариант 'разглядывать чужой код и 'отрывать руки', который здесь указывался, еще более затратный, не применим в больших командах/проектах, и обычно практикуется локальными царьками.

 

Подскажите, чем сами пользуетесь или что рекомендовали бы?

[yuravg 0]

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

Из свободных

Verilator

....

 

Спасибо

[ConstHw 0]

По теме топикстартера

 

Не понятно, почему спор Verilog-VHDL относится к разряду религиозных. Религиозные споры применительно к IT это когда за каждой стороной есть своя объективная правда, свои преимущества. Matlab не дает проверить результат присвоения if (a=B), потому что это плодит ошибки. Зато медленнее работает. C не проверяет границы массивы, зато быстрее работает. Функциональное vs ООП.

В каждом подобном случае есть объективные достоинства и недостатки.

 

Вопросу декларирования переменных тоже посвящено куча работ. Можно объявлять все переменные в одном месте, как в С и Паскале. Можно объявлять по месту использования, как в SystemVerilog или C++. Можно вообще не объявлять как в Питоне или Матлабе. У каждого такого подхода есть плюсы и минусы.

 

То что верилог по умолчанию считает недекларированным сигнал однобитным ваером это костыль. Костыль, который разработчики языка воткнули туда 100 лет назад, когда моделировали gate level схемы из чугуна и сосновых досок и соединять триггер с элементом И без объявления ваера было действительно удобно. Сейчас эта конструкция плодит ошибки и ничего больше. Если вы поднялись с уровня моделирования гейтов, то эта особенность дает ровно 0 преимуществ и переодически добавляет ошибки.

 

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

 

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

 

Это никакие не милые особенности и уж тем более глупым высокомерием кажутся выпады "сперва научись писать без ошибок дурак". Это проблемы языка, которые прекрасно решены в SystemVerilog. То есть разработчики стандарта как раз понимали все. Отрицать наличие проблемы и кичиться возможность стрелять в ногу так же осмысленно и разумно, как радоваться что ваш любимый САПР падает каждый час обеспечивая вам необходимый перерыв в работе и заставляет вовремя сохраняться и вообще учит ответственности.

 

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

 

Вот советы о том, как писать код без ошибок

http://www.viva64.com/ru/b/0391/

А вот методика тестирования

https://en.wikipedia.org/wiki/Unit_testing

 

Они не противоречат другу другу, не исключают, а дополняют.

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

[1891ВМ12Я 0]

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

Не понятно, почему спор Verilog-VHDL относится к разряду религиозных.

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

[FatRobot 0]

Ключевой момент, конечно. Вас бы в комитет по стандартизации. Уж вы бы там навели шороху.

 

Язык сам по себе должен давать ...

 

[ConstHw 0]

Не приписывайте мне пожалуйста мне какие то свои мысли, что я против тестов.

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

При том, что подобная примитивная ошибка может быть отловлена еще при прогоне компилятора.

 

Приведите пожалуйста какой нибудь пример, где "лаконичность и удобство" в экономии одной строчки объявления повысила читаемость кода. Не в смысле сейчас тут напишите синтетический пример "было 4 строчки стало 3", а какой нибудь реальный проект в котором эта особенность что то реально улучшила. ОпенКорс, Analog Devices, Xilinx корки и проч.

Изменено 13 мая, 2016 пользователем ConstHw

[Maverick_ 15]

Прошу халивар не развивать на многие страницы...

Модератор

[FatRobot 0]

В больших проектах само rtl-описание составляет примерно 5-10% ресурсов. Поэтому все эти рыдания на тему о сравнениях и выборе языка не стоят и ломаного сентаво. Выбор языка для rtl диктуется лишь корпоративным стандартом. А обсуждения, что лучше, где строчек больше, кто и что должен - признак исканий себя и малого опыта.

 

Сложно поверить, что яоп будет ограничивающим фактором при смене или выборе работодателя. Иными словами, если работодатель вам вдруг скажет писать на том, что вам на данный момент не по нраву, то вы, конечно, сперва немного побалагурите для порядка. Потом спрячете ваши веские аргументы и ваше авторитетнейшее мнение туда, где им должно быть, откроете файл с расширением .v (или .vhd. я, признаться, не уловил, против чего вы выступаете) и, помолясь, начнете писать. Ведь так?

[Maverick_ 15]

Приведите пожалуйста какой нибудь пример, где "лаконичность и удобство" в экономии одной строчки объявления повысила читаемость кода. Не в смысле сейчас тут напишите синтетический пример "было 4 строчки стало 3", а какой нибудь реальный проект в котором эта особенность что то реально улучшила. ОпенКорс, Analog Devices, Xilinx корки и проч.

например многопортовый сумматор - на vhdl параметризируемый многопортовый сумматор описывается сложнее и в сделать описание на vhdl чтобы поместилось в один экран не удалось :(

PS я сам пишу на vhdl.

[ConstHw 0]

Fat Robot да ну зачем мне в комиссию, там сидят гораздо более компетентные специалисты, которые еще 10 лет назад выпустили стандарт на SV который учитывает все эти проблемы. И 20 лет зада выпустили стандарт VHDL так же свободный от указанных проблем. Мне хватает.

 

По поводу лаконичности, вот несколько примеров с AD, люди декларируют wire потому что это повышает читаемость.

https://github.com/analogdevicesinc/hdl/blo...axi_dmac.v#L247

https://github.com/analogdevicesinc/hdl/blo...ata_mover.v#L85

 

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

Примеров, когда необъявленный ваер приводил к ошибке вроде достаточно.

 

Maverick хотелось бы все таки пример где "wire по умолчанию" давал преимущество. А какая именно конструкция на VHDL занимала больше места? Ваш пример кстати написан на SV, многомерные массивы, типа logic и $clog2 это все из стандарта SV.

Изменено 13 мая, 2016 пользователем ConstHw

[Maverick_ 15]

Maverick хотелось бы все таки пример где "wire по умолчанию" давал преимущество. А какая именно конструкция на VHDL занимала больше места? Ваш пример кстати написан на SV, многомерные массивы, типа logic и $clog2 это все из стандарта SV.

это не моя реализация, а уважаемого Bad0512

 

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

adder_tree_vhdl.rar