[Alexandr 0]

Использую ISE 6.3 и ModelSim 5.8

Проблема вот в чем. Написал код на VHDL. Провел функциональное моделирование. Все нормально. Запускаю временное (которое Simulate Post-Place & Route VHDL Model) и в некоторых местах появляются красные полоски вместо сигналов. По их месту и характеру понимаю, что пропадает один импульс. Ввожу дополнительный контакт в порт, подключаю его к этой цепи, чтобы посмотреть когда он пропадает И..... Все нормально работает, все красные линии исчезают и критическая цепь выглядит как надо. Убираю контакт из порта - все как прежде не работает. Что делать? Ваше мнение.

[andrew_b 14]

От того, что некая цепь то появится, то исчезнет, меняется временная картина внутри кристалла. Если всего лишь один провод так влияет, то надо что-то исправлять в кон^H^H^Hдизайне.

[vetal 0]

'X' обычно проявляются когда проблеммы с начальными условиями(set,reset e.t.c.).

[Alexandr 0]

Не поверите - дело оказалось вот в чем. В проекте есть несколько процессов, все синхронные, тактируются одним CLK. Однако часть процессов для удобства работают по переднему фронту CLK, часть по заднему. Сделал все процессы по переднему и все заработало . Видимо это какое-то ограничение ISE или ModelSim, потому как более ничего не менял. Может кто объяснит в чем дело?

[Кнкн 5]

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

<{POST_SNAPBACK}>

 

В общем и целом, при тактировании от одного фронта запас

временной устойчивости схемы больше - может дело в этом ?

[vetal 0]

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

 

Alexandr:

Если не сложно попробуйте 2 оставшихся варианта: все по срезу и с точностью до наоборот базовой версии.

[Кнкн 5]

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

<{POST_SNAPBACK}>

 

Модели триггеров могут проверять нарушения

hold/setup и реагировать на них выдачей 'X'

Это, конечно, зависит от библиотеки.

Алтеровская так делает, а как у Xilinx не знаю.

[3.14 0]

У Xilinx точно так же (симулируем то наверное в одном и том же).

 

Если моделируете в VHDL, можно выключить детектор метастабильности (ключики ModelSim), правда весь проект не будет анализироваться на метастабильность.

Если Verilog, тогда надо прикручивать констрейн ASYNC_REG к "проблемным" регистрам.

[Alexandr 0]

To vetal

Попробовал тактировать все по заднему фронту. :( Красные линии появились практически во всех цепях. Аж страшно стало.

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

 

To 3.14

Если моделируете в VHDL, можно выключить детектор метастабильности (ключики ModelSim), правда весь проект не будет анализироваться на метастабильность.

 

Использую VHDL. А как выключить детектор метастабильности, можно поподробнее?

[3.14 0]

Ищите галку "Global disable of X-generation for simulation" в настройках ModelSim.

[vetal 0]

Попробовал тактировать все по заднему фронту. :( Красные линии появились практически во всех цепях. Аж страшно стало.

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

Странности какие-то. Думаю, что дело тут в библиотете.

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

[Genn 0]

Не поверите - дело оказалось вот в чем. В проекте есть несколько процессов, все синхронные, тактируются одним CLK. Однако часть процессов для удобства работают по переднему фронту CLK, часть по заднему. Сделал все процессы по переднему и все заработало  . Видимо это какое-то ограничение ISE или ModelSim, потому как более ничего не менял. Может кто объяснит в чем дело?

<{POST_SNAPBACK}>

 

На самом деле, при таком построении проекта никакого криминала нет, и ModelSim здесь не виноват (временную модель то генерит ISE). Однако не ясен один момент: устанавливаете ли Вы временные ограничения при трансляции проекта в кристалл или нет. Поскольку Ваш проет работает только одной тактовой частоты, то выполнение этих ограничений (с вероятностью 99%) автоматически даст положительный результат. При трансляции в кристалл анализируется как поведение тактовой частоты, так и поведение логики итриггеров, включая анализ hold/setup. Ниже прилагаю фрагмент ucf-файла для Fт=10МГц.

 

# --------------------------

# FROM:TO TIME-SPECs

# --------------------------

# FROM:TO стиль временных ограничений может быть использован для определения путей между

# группами. ПРИМЕЧАНИЕ: Ключевые слова: RAMS, FFS, PADS, and LATCHES определены предварительно

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

TIMEGRP RFFS = RISING FFS ("*"); // создает группу триггеров, работающих по фронту RFFS

TIMEGRP FFFS = FALLING FFS ("*"); // создает группу триггеров, работающих по срезу FFFS

TIMESPEC TSF2F = FROM : FFS : TO : FFS : 50 ns; // Триггеры, работающие по одинаковому перепаду

TIMESPEC TSR2F = FROM : RFFS : TO : FFFS : 25 ns; // фронт к срезу

TIMESPEC TSF2R = FROM : FFFS : TO : RFFS : 25 ns; // срез к фронту

[BSV 0]

Предыдущий оратор, наверно прав. Вы просто превышаете частотные ограничения при моделировании - попробуйте уменьшить частоту при временном моделировании (относительно той, что выдал ISE), например, в 2 раза. Или можно попробовать не цеплять SDF-ы (я иногда этим пользуюсь - при этом не учитывается большинство задержек, а схема - такая же, как будет в кристалле). Если все заработает - то боритесь с задержками.

 

Вот если в проекте несколько тактовых сигналов (не связанных), тогда при временном моделировании просто необходимо отключать "детектор метастабильности" ((С) 3.14, как это точно в моделсиме называется на память не скажу). Поскольку иначе при пересечении клоковых доменов начинают возникать X-ы, даже, если применять асинхронные FIFO, подтверждения и т.п.

[Yra 4]

А вживую проект с красными линиями работает?

У меня было что- то подобное - оказалось дело в оптимизаторе : не понравился ему фрагмент при синтезе - выкинул, и заодно весь кусок, подключенный к выходу этого фрагмента.

Бывает красное появляется, если много комбинаторики в одном месте (типа правильная информация появляется не сразу на выходе асинхронного АЛУ)

Что касается переднего и заднего фронтов - использую и то и другое (в основном для "одновременного" обращения к ОЗУ с двойным доступом) всё работает.

Кстати, даёт какойто выигрыш манипуляция с настройками моделсима (я использую всё "по умолчанию" из- за незнания и из-за неуверенности, что мои изменения приведут к лучшему).

[kas 0]

Использую ISE 6.3 и ModelSim 5.8

Проблема вот в чем. Написал код на VHDL. Провел функциональное моделирование. Все нормально. Запускаю временное (которое Simulate Post-Place & Route VHDL Model) и в некоторых местах появляются красные полоски вместо сигналов. По их месту и характеру понимаю, что пропадает один импульс. Ввожу дополнительный контакт в порт, подключаю его к этой цепи, чтобы посмотреть когда он пропадает И.....  Все нормально работает, все красные линии исчезают и критическая цепь выглядит как надо. Убираю контакт из порта - все как прежде не работает. Что делать? Ваше мнение.

<{POST_SNAPBACK}>

 

Наложить временные ограничения.

 

Думаю конструкция PERIOD на clk здесь будет вполне уместна.

 

И еще, для того чтобы посмотреть внутренние сигналы при моделировании вовсе не обязательно вводить дополнительные порты. Там есть окно workspace, если в это окне поставить курсор на Ваш блок (по умолчанию UUT), то в окне Objects должны появиться все сигналы, которые есть внутри блока.