Следует ли удалить все предупреждения в дизайне Verilog или VHDL? Почему или почему нет? - PullRequest
4 голосов
/ 27 апреля 2010

В (обычном) программном обеспечении я работал в компаниях, где опция gcc -Wall используется для отображения всех предупреждений. Тогда с ними нужно разобраться. С нетривиальным дизайном FPGA / ASIC в Verilog или VHDL часто появляется много предупреждений. Должен ли я беспокоиться обо всех из них? У вас есть какие-то конкретные методы, чтобы предложить? Мой поток в основном для FPGA (в частности, Altera и Xilinx), но я предполагаю, что те же правила будут применяться к дизайну ASIC, возможно, в большей степени из-за невозможности изменить дизайн после его создания.

Обновление от 29.04.2010: Первоначально я думал о синтезе и предупреждениях P & R (Place & Route), но предупреждения симуляции также действительны.

Ответы [ 6 ]

10 голосов
/ 27 апреля 2010

Вот мой взгляд на мир ASIC (99% Verilog, 1% VHDL).

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

Поскольку существует много типов инструментов, которые могут генерировать предупреждения (имитация / отладчик / линтер / синтез / проверка эквивалентности и т. Д.), Я сосредоточу это обсуждение на компиляторе симулятора предупреждений.

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

Исключением из вышеприведенной методологии является сторонний IP, чей код Verilog мы не можем изменять.

Этот метод довольно хорошо работает для моделирования RTL, но становится намного сложнее, когда мы запускаем моделирование гейта с использованием обратно аннотированного SDF. Просто не хватает времени для анализа и устранения буквально миллионов предупреждений. Лучшее, что мы можем сделать, - это использовать скрипты (Perl) для разбора файлов журнала и классификации предупреждений.

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

3 голосов
/ 27 апреля 2010

Вот что я делаю, для справки.Я проверяю все файлы журналов с помощью инструмента (ов).

Для Altera Quartus II, который включает в себя карту, отчеты о подгонке и объединении.Я также включаю опцию Design Rule Check (DRC) и проверяю этот файл.Для некоторых сообщений, которые легко исправить, например, отсутствует порт в экземпляре или неправильная постоянная ширина, я исправляю их.Другие я смотрю.Для тех, которые находятся в ядрах, например, несоответствие ширины, потому что я не использую преднамеренный полный вывод, я отмечаю их как подавляемые в файле .srf.Я подавляю только конкретные сообщения, а не все «подобные сообщения», поскольку могут быть и другие, или сейчас, или в будущем, которые являются проблемами.

2 голосов
/ 02 июня 2010

Самая важная причина, которую я могу придумать, - это несоответствие симуляции и синтеза. Инструменты синтеза делают много оптимизаций (как и положено), и если вы оставляете лазейки в своем дизайне, вы напрашиваетесь на неприятности. Обратитесь к IEEE 1364.1-2002 за подробной информацией о стандарте синтеза.

2 голосов
/ 27 апреля 2010

Я написал скрипт, который применяет набор регулярных выражений к лог-файлу для удаления строк, которые, как я знаю, «в порядке».Это помогает, но вы должны быть немного осторожнее с регулярными выражениями - что jwz сказал о них:)

1 голос
/ 16 июня 2017

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

Например, некоторые инструменты синтеза выдают предупреждение, если определен Verilog parameter, и при создании экземпляра модуля не назначено значение. Для меня это предупреждение - всего лишь совет по использованию localparam. Желательно подавить его по его идентификатору (например, LINT-01).

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

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

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

0 голосов
/ 07 октября 2016

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

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

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

...