Известно, что связка QuartusII с ModelSim не очень гармонична, поскольку КВА позволяет некоторые конструкции с нарушением стандарта. Проект, собранный в КВА для отработки в ModelSim требует правки в тех местах, где этот "волюнтаризм" допущен. Этот прием применяет мое начальство, чтобы очистить код от обильного количества Варнингов. В итоге в проекте только 2 варнинга.
Вполне разумный ход.
НО...
На шаге симуляции начальство визжит от как резаное! Дескать в окне Transcript(ModelSim)сыпятся предупреждения типа


Это все характерно для момента разгона модели, когда идет первичная инициализация сигналов...
Но задача звучит так,- этого не должно быть!!!! А речь идет о сдаче дизайна в архив.

Что посоветуете?

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

Simulate/runtime options/ message severity/ галочка vhdl warnings
Должно помочь именно с этим!

Спасибо! Ай да молодец!...

Можно конечно голову в песок и нет проблемы...
Но лучше разберитесь, может быть не зря оно так визжит насчет Х'ов,
мало ли, что вы там рассчитываете.

http://infocenter.arm.com/help/topic/com.a...ilog_X_Bugs.pdf

Дело конечно не в Моделсиме.
Квартус "знает", что после инициализации регистры и триггера будут по "исходному"...Обычно выходы - по нулям... А Моделсиму об этом никто не сказал. И он не понимает состояния каких-то регистров-триггеров, у которых нет сброса... Напишите начальное значение для этих сигналов...
Если используете сигнал захвата от PLL, то можно в тестбенче вместо PLL сделать такой сигнал и добавить его к сбросу... Можно сделать внутренний блок, сбрасывающий проект в исходное...
У Ксайлинкса есть примитив, который переводит проект в рабочее состояние после загрузки. Наверняка у Альтеры тоже что-то такое есть... Только я такой примитив обычно копирую в ту деректорию, где веду отладку и там "подрезаю" ему время задержки...
В верилоге есть "force". Т.е. можно принудительно заставить какие-то сигналы в тестбенче принять определенное значение. А потом их релизнуть...

Вообще нормальный симулятор должен это понимать исходя из типа данных.
В SV есть тип данных bit, который может быть либо 0, либо 1, Х состояния вовсе не предполагается.
При начале симуляции (zero time) переменные типа bit будут гарантированно иметь определенное состояние - 0.
То есть, используя bit для синтезируемой логики можно уйти от проблемы X'ов на симуляции.

Можно инициализировать перемены при объявлении, но это противоречит многим стандартам кодирования.
Мотивируется тем, что можно получить различный результат при моделирование RTL и netlist.

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

Резюме.
В использование продвинутых симуляторов и языков есть определенный резон.
X'ы на симуляции не стоит недооценивать, так как это могут быть проблемы не только симулятора, но и самой схемы.

У меня ушки на макушке...
Выгреб кучу проблем с установками, но мне, после Xiulinx, было необычно переводить часть сигналов на асинхронный (Альтеровский) сброс. Выявил отсутствие начального сброса в некоторых местах.
В итоге сократил на 2\3 число предупреждений.
Теперь при симуляции стало меньше красного цвета.. )))

Нет предела совершенству!