Если вы удалите все предупреждения в вашем дизайне Verilog или VHDL? Почему или почему нет?

Question

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

Обновление 4/29/2010: Я изначально думал о синтезе и P & R (Place & Manuer) предупреждений, но предупреждения о моделировании также действительны.

Answer 1

Вот моя перспектива из мира ASIC (99% Verilog, 1% VHDL).

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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