Необходимо ли удалить все предупреждения в Verilog или дизайн VHDL? Почему или почему нет?
В (обычном) программном обеспечении я работал в компаниях, где gcc опция - Стена используется для показа всех предупреждений. Затем с ними нужно иметь дело. С нетривиальным дизайном FPGA/ASIC в Verilog или VHDL там часто много много предупреждений. Я должен волноваться обо всех них? У Вас есть какие-либо определенные методики для предложения? Мой поток главным образом для FPGAs (Altera и Xilinx в особенности), но я предполагаю, что те же правила относились бы к дизайну ASIC, возможно более из-за неспособности изменить дизайн после того, как это создается.
Обновление 29.04.2010: Я первоначально думал о синтезе и P&R (Место и Маршрут) предупреждения, но предупреждения моделирования допустимы также.
4 ответа
Вот мой взгляд из мира ASIC (99% Verilog, 1% VHDL).
Мы стараемся исключить все предупреждения из наших файлов журналов, потому что в целом мы интерпретируем предупреждения как средство, говорящее нам, что нам не следует ожидать предсказуемых результатов.
Поскольку существует множество типов инструментов, которые могут генерировать предупреждения (моделирование / отладчик / линтер / синтез / проверка эквивалентности и т. Д.), Я сосредоточу это обсуждение на предупреждениях компилятора симулятора .
Мы анализируем предупреждения и разделяем их на две основные группы: те, которые, по нашему мнению, не повлияют на результаты нашего моделирования, и другие, которые могут повлиять на результаты.Во-первых, мы используем параметры инструмента, чтобы явно включить как можно больше предупреждений. Для первой группы мы затем используем параметры инструмента, чтобы выборочно отключить эти предупреждающие сообщения. Для второй группы мы исправляем исходный код Verilog, чтобы исключить предупреждения, а затем преобразовываем предупреждения в ошибки. Если позже в этих категориях появятся какие-либо предупреждения, мы заставим себя исправить их, прежде чем нам будет разрешено моделировать.
Исключением из приведенной выше методологии является сторонний IP, чей код Verilog нам не разрешается изменять.
Этот метод довольно хорошо работает для моделирования RTL, но становится намного сложнее, когда мы запускаем моделирование гейта с использованием SDF с обратной аннотацией. Просто не хватает времени на анализ и устранение буквально миллионов предупреждений. Лучшее, что мы можем сделать, - это использовать сценарии (Perl) для анализа файлов журнала и классификации предупреждений.
Таким образом, мы делаем все возможное, чтобы исключить предупреждения, но это не всегда практично.
Вот что я делаю для справки. Я проверяю все файлы журналов с помощью инструмента (ов).
Для Altera Quartus II, который включает отчеты о карте, подгонке и объединении. Я также включаю опцию Design Rule Check (DRC) и проверяю этот файл. Для некоторых сообщений, которые легко исправить, например порт отсутствует в экземпляре или неверная постоянная ширина, я исправляю их. Я смотрю на другие. Для тех, которые находятся в ядрах, например несоответствие ширины, потому что я намеренно не использую полный вывод, я помечаю их как подавляемые в файле .srf. Я подавляю только определенные сообщения, а не все «похожие сообщения», поскольку могут быть другие, в настоящее время или в будущем, которые являются проблемами.
Я написал сценарий, который применяет набор регулярных выражений к файлу журнала, чтобы отбросить строки, которые, как я знаю, в порядке. Это помогает, но вы должны быть немного осторожны с регулярными выражениями - что jwz сказал о них:)
Самая важная причина, о которой я могу думать, - это несоответствие моделирования и синтеза. Инструменты синтеза делают много оптимизаций (как они и должны), и если вы оставляете лазейки в своем дизайне, вы напрашиваетесь на проблемы. Обратитесь к IEEE 1364.1-2002 для получения подробной информации о стандарте синтеза.