[dxp 41]

Всем привет!

 

Возможно, вопрос обсуждался, но мне найти не удалось. Суть в следующем. 

 

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

 

WARNING: [Synth 8-3331] design <...> has unconnected port <...>. 

 

Выглядит угрожающе, но на деле по нетлисту (схематику) видно, что сигналы-то на месте, всё подключено. Анализ показывает, что почти все они относятся к сигналам интерфейсов. И похоже, что синтезатор ругается на сигналы модпортов интерфейса, которые не используется в том или ином модуле. Т.е. насколько понимаю, картина такая: есть интерфейс, у него есть модпорты m0, m1, s0, модпорт m0 подключается к модулю master0, модпорт m1 - к модулю master1, а модпорт s0 - к модулю slave0. Получается, что интерфейс прокинут во все модули, но часть сигналов, которые относятся к другим модпортам, естественно в данном конкретном модуле не подключена - например, в модуле master0 не подключены сигналы модпоротов m1 и s0. Получается, что ругань как бы не по делу.

 

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

[des00 25]

в квартусе абсолютно тоже самое, если судить по нему, то все мои проекты с интерфейсами и с массивами структур, не рабочие)))

[gibson1980 0]

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

[dxp 41]

Благодарю за ответы. Блокировать предупреждения, конечно, вариант, но есть два "но". 

 

1. В виваде это делать, мягко говоря, неудобно - у неё совершенно тупой механизм для этого - либо блокировать именно текущее конкретное, либо по текущему ID. Помниться, в квартусе была куда более продвинутая система - там можно было гибко по маске задавать, т.е. можно было задавить предупреждения на конкретном модуле и/или наборе конкретных сигналов. Я так и делал - отсмотрел, убедился, что ругань не по делу, заблокировал, чтобы не маскировали новые. Иногда всё же там есть предупреждения по делу, поэтому блокировать по ID не хочется.

 

2. Принимая во внимание п.1, получается, что приходится блочить каждое сообщение индивидуально. А т.к. их там тыщи, это порождает конского размера файл проекта (в ква там просто добавлялась маска в отдельный файлик и всё). 

 

Кстати, есть такое наблюдение. Там в логе есть два вида сообщений по виду на одну тему:

 

1. [Synth 8-6014] Unused sequential element <...> was removed.  

2. [Synth 8-3332] Sequential element (<...>) is unused and will be removed from module <...>.

 

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