[anatolich 0]

Вот такой простой код

process(clock)

begin

if clock = '1' and clock'event then

enable_mem <= enable_in;

end if;

end process;

Пробую поведенческое моделирование

В ncsim если enable_in появляется синхронно с клоком то на этом же клоке меняется enable_mem.

А в Modelsim если enable_in появляется синхронно с клоком то enable_mem меняется на следующем клоке.

В железе работает по ncsim-у

 

Подскажите, пожалуйста, что можно сделать?

[andrew_b 16]

Покажите, как формируете сигналы для триггера.

[iosifk 3]

Вот такой простой код

process(clock)

begin

if clock = '1' and clock'event then

enable_mem <= enable_in;

end if;

end process;

Пробую поведенческое моделирование

В ncsim если enable_in появляется синхронно с клоком то на этом же клоке меняется enable_mem.

А в Modelsim если enable_in появляется синхронно с клоком то enable_mem меняется на следующем клоке.

В железе работает по ncsim-у

 

Подскажите, пожалуйста, что можно сделать?

Моделсим показывает так, как должно быть. А в железе не происходит вот это - "enable_in появляется синхронно с клоком"

 

[anatolich 0]

Получается в ncsim и modelsim - разные модели поведения

 

код такой

clock <= not clock after 5 ns;

enable_in <= '0', '1' after 105 ns, '0' after 115 ns;

[andrew_b 16]

Получается в ncsim и modelsim - разные модели поведения

 

код такой

clock <= not clock after 5 ns;

enable_in <= '0', '1' after 105 ns, '0' after 115 ns;

У вас асинхронные сигналы. То, что они появляются в один и тот же момент времени, не значит, что они синхронные.

Формируйте enable_in не сам по себе, а по clock.

[Gorby 6]

У вас асинхронные сигналы. То, что они появляются в один и тот же момент времени, не значит, что они синхронные.

Формируйте enable_in не сам по себе, а по clock.

 

До кучи не забудьте, что:

enable_mem <= enable_in;

НЕ БЫВАЕТ.

 

А вот так - запросто:

enable_mem <= enable_in after 3nS;

 

 

[SM 0]

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

 

А в реальности, это метастабильное состояние называется.

[Gorby 6]

А в реальности, это метастабильное состояние называется.

 

Вы совершенно правы, но я немного о другом: если записать вот так

enable_mem <= enable_in;

в симуляторе, а затем использовать enable_mem в этом же процессе для чего-то еще, то можно (при определенных обстоятельствах) нарваться на неприятный сюрприз, связанный с тем что присваивание произошло "мгновенно". ПРоблема не столь очевидна, ибо в Менторе "тоже не дураки сидят" и в пределах одного процесса система вроде моделирует нормально. Но как только вы попытаетесь передать enable_mem через повторитель, логику с нулевой задержкой или просто провод, он уже будет принадлежать следующему такту модельного времени. И вот тут - .опа. Выход- либо всегда моделировать реальные схемы (временнОе моделирование - долго, скучно), либо вставлять хоть одну пикосекунду, но задержку во все "идеальные" присваивания. Это - не метастабильность, это принципиальная проблема симулятора, у которого возможен триггер с задержкой срабатывания 0.

[SM 0]

Вы совершенно правы, но я немного о другом: если записать вот так

enable_mem <= enable_in;

в симуляторе, а затем использовать enable_mem в этом же процессе для чего-то еще

Нет. Это не тот случай. В этом случае все четко определено. Без разночтений

А этот случай, это если написать где-то в одном процессе формирование двух сигналов, абсолютно синхронных (можно и в разных процессах), а использовать потом оба в другом (третьем) процессе, причем один из них в событии, а второй как входное данное