[SM 0]

И чё тут тесбенчу симулить-то? Это прекрасно делает STA анализатор.....

 

То, что если резет НЕ ПРИВЯЗАН к клоку, и где-то возникла метастабильность из-за этого, и схема спроектирована правильно, то она все равно должна работать корректно.

 

Беда в том, что в моделяторе в регистр запишется "X", что не соответствует физической реальности в устройстве, в котором переход из состояния, которое в резете, в новое состояние задержится на один такт, при этом схема (если она правильная) будет работать корректно, а в моделяторе расползется "X"

[topor_topor 0]

То, что если резет НЕ ПРИВЯЗАН к клоку, и где-то возникла метастабильность из-за этого, и схема спроектирована правильно, то она все равно должна работать корректно.

 

Беда в том, что в моделяторе в регистр запишется "X", что не соответствует физической реальности в устройстве, в котором переход из состояния, которое в резете, в новое состояние задержится на один такт, при этом схема (если она правильная) будет работать корректно, а в моделяторе расползется "X"

чёто неочень понял....

1) Ошибку, при которой асинхронный сброс не привязан к клоку может выловить STA анализатор (только обяснить ему надо что сигнал RESET таки асинхронен остальной части схемы).

2) Коректно спроектированная схема с асинхронным ресетом - это та, где на любом входе FF.RN (кроме синхронизатора конечно) никогда не бывает никаких метастабильностей и Х.

Как есчё по вашему можно "правильно спроектировать схему", чтобы она работала корректно, если на произвольном тригере из-за проблем с ресетом возникла метастабильность?

3) Записанный Х в регистре - какраз очень соответствует физической реальности, а именно - метастабильному состоянию (оно кстати очень даже может длится более такта клока).

[SM 0]

Как есчё по вашему можно "правильно спроектировать схему", чтобы она работала корректно, если на произвольном тригере из-за проблем с ресетом возникла метастабильность?

 

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

 

Ну а в частностях бывают еще различные нюансы.

 

 

А что касается метастабильного состояния - не может оно длиться больше такта клока в данном случае. Если интересно, могу даже рассказать, почему в данном случае это именно так (рассмотрев схему вплоть до транзисторов).

 

Кстати, для моделирования этих процессов в ASIC скорее надо применять уже моделяторы транзисторного уровня, типа synopsys NanoSim, а не логические. Они не знают состояния "X", а оперируют реальными состояниями, выраженными в вольтах напряжения :). Правда, я в таких случаях чаще доверяюсь опыту, проверяя правильность схемы вручную.

[ViKo 1]

Однажды создал модуль сброса, его и использую (кое-где :rolleyes:). Особой необходимости не чувствую, но и не мешает.

module Reset_m (
  input    bit        res_ext,    //!< External reset (knob, port)
  input    bit        no_lock,    //!< PLL no locked reset
  input    bit        res_cmd,    //!< MCU command reset
  input    bit        clks,        //!< Slow Clock
output    bit        res_int        //!< Internal wide device reset
);
  bit            rest;        //!< Reset start
  assign rest = res_ext || no_lock || res_cmd;
  
  bit        [1:0]    ress;        //!< Reset sequence
  always_ff @(posedge rest, posedge clks) begin
    if (rest) ress <= '1;
    else ress <= {ress[0], 1'b0};
  end
  assign res_int = ress[1];

endmodule : Reset_m

 

[topor_topor 0]

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

Ну а в частностях бывают еще различные нюансы.

 

А что касается метастабильного состояния - не может оно длиться больше такта клока в данном случае. Если интересно, могу даже рассказать, почему в данном случае это именно так (рассмотрев схему вплоть до транзисторов).

Интересное решение....

Помоему в этом случае будет так:

1) " в этом случае он либо не изменится, оставшись в состоянии резета, либо изменится корректно, либо останется в метастабильном состоянии до следующего такта и Х побежит по всей схеме"

2) Может конечно для вашего устройства и не проблема, но в общем случае, нехорошо если часть модулей схемы "останеться в состоянии резета", а другие "перейдут в другие корректные"....

3) А что касается метастабильного состояния - МОЖЕТ оно длиться больше такта клока.

Длительность метастабильного состояния какраз схемой на уровне транзисторов и определяется (в том числе и паразитными ёмкостями, и .т.д).

Это время от клока никак не зависит и очень даже может быть более периода (при быстром клоке).

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

 

 

 

 

 

 

Однажды создал модуль сброса, его и использую (кое-где :rolleyes:). Особой необходимости не чувствую, но и не мешает.

правильное решение

 

[ViKo 1]

Были бы у Альтеры входы с триггерами Шмитта, то и метастабильных состояний не было бы (для этих входных сигналов). Увы, есть только у MAX.

http://www.altera.com/support/kdb/solution...91998_7070.html

[SM 0]

2) а не должно допускать такое на уровне алгоритма работы устройства - инициирование всех процессов в такой системе должно происходить от одного регистра - и пока он не скажет "да" - всякие там стробы, разрешения, и т.п., не генерируются. Ну, либо, задержка выхода из резета на один такт не должна влиять на работу системы по алгоритму ее работы, например, если у каждого модуля есть свой выход валидности данных. Тут вариантов есть много.

 

3) В данном КОНКРЕТНОМ случае метастабильности по removal/recovery она не может длиться больше такта, так как сам следующий такт физически стабилизирует состояние за счет распространения корректного уровня со входа через открытый ключ.

[topor_topor 0]

Были бы у Альтеры входы с триггерами Шмитта, то и метастабильных состояний не было бы. Увы, есть только у MAX.

http://www.altera.com/support/kdb/solution...91998_7070.html

Тригер Шмидта от метастабильности не спасает.

Он спасает от медленного фронта, и помех на уровнях с малой амплитудой.

Даже если идеальный фронт снятия ресета произойдёт на активном фронте клока - тригер может стать метастабильным.

[SM 0]

Были бы у Альтеры входы с триггерами Шмитта, то и метастабильных состояний не было бы (для этих входных сигналов).

Были бы, никуда не делись бы. Для любого триггера шмитта можно подобрать такое воздействие, что он окажется в среднем состоянии :) :) Может, это кажется странным и в это не верится, но это так. Да и метастабильности возникают несколько глубже, чем на входных буферах.

[topor_topor 0]

2) а не должно допускать такое на уровне алгоритма работы устройства - инициирование всех процессов в такой системе должно происходить от одного регистра - и пока он не скажет "да" - всякие там стробы, разрешения, и т.п., не генерируются. Ну, либо, задержка выхода из резета на один такт не должна влиять на работу системы по алгоритму ее работы, например, если у каждого модуля есть свой выход валидности данных. Тут вариантов есть много.

 

3) В данном КОНКРЕТНОМ случае метастабильности по removal/recovery она не может длиться больше такта, так как сам следующий такт физически стабилизирует состояние за счет распространения корректного уровня со входа через открытый ключ.

2) да и при этом всё должно работать после глобального "да", с учётом что каждый модуль может случайно стартовать с состояния RESET или STEP1....

можна систему построить так, но это сложно думать и только ресурсозатраты...

не проще, ли дать чистый ресет и в нужное время?

 

3) тут я не очень понял... о каком входе и открытом ключе речь? Вы говорите об одном и том-же тригере который попал в метастабилтьность?

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

да и чё при этом с комбинаторикой на его выходе будет и как долго? У вас есть где про ето почитать с полной научной выкладкой?

И даже если предположить что это правда (следующий такт удаляет метастабильность), то как минимум Х продержится HOLD время и испортит следующий тригер....

[Golikov 0]

насчет 3 все просто.

 

у вас один триггер на выходе имеет что-то странное.

 

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

[SM 0]

не проще, ли дать чистый ресет и в нужное время?

Проще, но не всегда эффективно по ресурсам и/или скорости схемы. Смотря что в приоритете у разработчика.

 

3) тут я не очень понял... о каком входе и открытом ключе речь?

Вы говорите об одном и том-же тригере который попал в метастабилтьность?

 

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

 

 

И еще - не всегда и не во всех схемах есть работающий клок в момент снятия и подачи резета.... Причем далеко не во всех... Конкретный пример - TRST у JTAG-а.

[topor_topor 0]

насчет 3 все просто.

 

у вас один триггер на выходе имеет что-то странное.

 

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

Не согласен. Если на тригер подать константу 0.5 и клок, то тоже получим метастабильность на выходе.

 

 

Проще, но не всегда эффективно по ресурсам и/или скорости схемы. Смотря что в приоритете у разработчика.

 

 

 

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

 

 

И еще - не всегда и не во всех схемах есть работающий клок в момент снятия и подачи резета.... Причем далеко не во всех...

и чё при этом с комбинаторикой на его выходе будет и как долго? У вас есть где про ето почитать с полной научной выкладкой?

И даже если предположить что это правда (следующий такт удаляет метастабильность), то как минимум Х продержится HOLD время и испортит следующий тригер....

 

то что клока долго нет после ресета - так это решает вообще все проблемы, которые мы обсуждаем тут :) От только обычно он есть.

[ViKo 1]

Были бы, никуда не делись бы. Для любого триггера шмитта можно подобрать такое воздействие, что он окажется в среднем состоянии :) :)

Да. Представил: триггер в 0, на вход подан сигнал около уровня верхнего порога переключения. Вот и неопределенность, перекидываться в 1, остаться в 0, или повисеть "между небом и землей".

[SM 0]

и чё при этом с комбинаторикой на его выходе будет и как долго? У вас есть где про ето почитать с полной научной выкладкой?

И даже если предположить что это правда (следующий такт удаляет метастабильность), то как минимум Х продержится HOLD время и испортит следующий тригер....

Почитать есть, но не дам... NDA от фабов SMIC и TSMC не позволяет, а все это придатки к их технологическим либам, включая и схематику их конкретных триггеров.

 

не испортит следующий триггер, он выходит из метастабильности за <= половины стандартного его времени clock-to-output (так как проходит по своей хар-ке полпути только, не 0->1, а 0.5->1 грубо говоря), это раз, а два - вероятность того, что второй триггер схватит метастабильность от первого уже как правило выходит за единицу в 10^8 лет, что, собственно, с той же вероятностью может случиться и в синхронизаторе того же резета. Об этом, естественно, надо помнить, и при работе с асинхронным сбросом, и при построении синхронизатора.

 

 

то что клока долго нет после ресета - так это решает вообще все проблемы, которые мы обсуждаем тут :) От только обычно он есть.

Это да, только это приведет к тому, что из-за синхронизатора синхронный резет (поставленный "на автомате" по привычке) не сработает :)