Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Synchronized reset и разные тактовые
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
vea
Есть каскад из двух регистров для внешнего сброса (обычная схема, как в справке квартуса здесь). Этот каскад тактируется clk1 и (соответственно со схемой) сбрасывать им можно регистры, которые тактируеются также clk1. Как правильно сбрасывать регистры, которые используют clk2, clk3 и т.д.?
Для каждого clkX делать отдельный каскад?
des00
Цитата(vea @ Jan 12 2015, 15:38) *
Для каждого clkX делать отдельный каскад?

да, при этом, если логика на разных тактовых связанная, желателен быть перенос сигнала сброса с каскада на каскад. В порядке возрастания частоты
FakeDevice
Еще есть зависимость от частоты. для пущей стабильности лично я такое только на частотах меньше 100 ставлю. на частотах повыше леплю от 3 регистров.
vea
Цитата(des00 @ Jan 12 2015, 10:49) *
да, при этом, если логика на разных тактовых связанная, желателен быть перенос сигнала сброса с каскада на каскад. В порядке возрастания частоты

Спасибо. Вот так?
Нажмите для просмотра прикрепленного файла
Получается, снятие сброса не будет "одновременным" для разных тактовых? Будет нарастающая задержка, которую надо компенсировать?

Цитата
на частотах повыше от 3 регистров.
Это обязательно? Хотелось бы единообразия.
des00
Цитата(vea @ Jan 12 2015, 15:39) *
Получается, снятие сброса не будет "одновременным" для разных тактовых? Будет нарастающая задержка, которую надо компенсировать?

В сбросе опасен не момент сброса, а момент его снятия. Сброс всех доменов должен идти одновременно, а вот снятие по цепочке. И не надо там ничего компенсировать. Цепочка на рисунке у вас сделана правильно.

Цитата
Это обязательно? Хотелось бы единообразия.

я обычно ставлю 4 ре регистра.


в приложении неплохая статья. изучайте.
FakeDevice
Цитата(vea @ Jan 12 2015, 11:39) *
Это обязательно? Хотелось бы единообразия.

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

Цитата(des00 @ Jan 12 2015, 11:58) *
я обычно ставлю 4 ре регистра.

я обычно ставлю при f<100=2, 100..150=3, 150..200=4, 200..250=5.
но всё это как-то на глазок, что в корне неправильно. Интересно было бы знать, а сколько в действительности-то требуется? т.к. лишняя задержка -- она не всегда приятна.
Где бы посмотреть кривые вероятности метастабильного состояния на выходе в зависимости от частоты и количества регистров при условии, скажем, подачи "самого неудачно сдвинутого" относительно тактов сигнала на входе?
des00
Цитата(FakeDevice @ Jan 12 2015, 16:16) *
Где бы посмотреть кривые вероятности метастабильного состояния на выходе в зависимости от частоты и количества регистров при условии, скажем, подачи "самого неудачно сдвинутого" относительно тактов сигнала на входе?

формула MTBF есть в доках о метастабильности от вендоров плис.
Krys
Цитата(des00 @ Jan 12 2015, 15:22) *
формула MTBF есть в доках о метастабильности от вендоров плис.
При том там считается вполне достаточным использование 2 триггеров, независимо от частоты.
des00
Цитата(Krys @ Jan 12 2015, 18:08) *
При том там считается вполне достаточным использование 2 триггеров, независимо от частоты.

значит мы разные доки читаем, либо делаем разные выводы.
Bad0512
Вот ещё полезная статья от Кена Чапмана до кучи.
toshas
Цитата(des00 @ Jan 12 2015, 12:22) *
формула MTBF есть в доках о метастабильности от вендоров плис.



Причем не все вендоры хотят их афишировать
http://forums.xilinx.com/t5/Virtex-Family-...ery/td-p/476482
vea
Цитата(Bad0512 @ Jan 12 2015, 15:00) *
Вот ещё полезная статья от Кена Чапмана до кучи.

Интересно. И здесь как раз 4 регистра - с указанием, что их число определяет минимальную длину сброса (и только?).
Но основная идея - нет особой необходимости в глобальном сбросе. Насколько это правильно?
В pdf есть ссылка на "Get your Priorities Right – Make your Design Up to 50% Smaller" - там в том числе и про сброс, но с привязкой к конкретной реализацией в кристаллах Xilinx. Насколько это соответсnвует Альтеровским кристаллам?
andrew_b
Цитата(vea @ Jan 12 2015, 16:31) *
Но основная идея - нет особой необходимости в глобальном сбросе. Насколько это правильно?
Основная идея в том, что сбрасывать надо то, что действительно надо сбрасывать.
Например, если у вас есть некие данные, сопровождаемые флагом valid, то сброс нужен только для valid, а для данных не нужен, ведь если valid не активен, то какая разница, какие данные.
FakeDevice
Цитата(toshas @ Jan 12 2015, 15:36) *
Причем не все вендоры хотят их афишировать
http://forums.xilinx.com/t5/Virtex-Family-...ery/td-p/476482


Видимо, причина в том, что со временем ситуация становится потихоньку хуже и хуже. Улучшаются технологии, транзисторы становятся всё менее шумными и за счёт собственных шумов становится сложнее и сложнее выйти из метастабильного состояния.
SM
Цитата(des00 @ Jan 12 2015, 11:58) *
В сбросе опасен не момент сброса, а момент его снятия. Сброс всех доменов должен идти одновременно, а вот снятие по цепочке.


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

А в подавляющем большинстве случаев, если в других доменах нет ничего, чтобы происходило без ведома домена-инициатора (каких-нибудь самостоятельных таймеров, и т.п.), достаточно резетнуть все эти домены асинхронным сигналом, и в домене-инициаторе выдержать задержку, гарантирующую, что в других доменах пройдет по два-три клока, и только потом начинать работать.
des00
Цитата(SM @ Jan 12 2015, 22:27) *
Только цепочка должна быть не тупо с повышением тактовой, а такой, как распространяется сигнал сброса, не привязываясь к частотам, то есть, оттуда, где он генерируется (например в домене "А"), он идет в домены "Б", и "В", а потом, обратно из доменов "Б" и "В", сигнал, говорящий домену "А", что все сбросилось, и можно начинать работать, то есть, снимать сигнал сброса с себя. Вот как-то примерно так. Направление, по большому счету, зависит от того, кто инициирует операцию, и кто на нее откликается - инициатор должен разрешаться только после того, как все остальные домены сбросились, независимо от того, у кого какая тактовая.

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

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

Я стараюсь делать модули во время сброса пассивными во всех смыслах, порой это приводит к наличию дополнительной логики, но зато никаких проблем со сбросами. И как сказал проброс сигнала делаю с низкочастотного домена в высокочастотный. Хотя это не обязательно, но люблю порядок sm.gif
SM
Цитата(des00 @ Jan 12 2015, 19:05) *
Я стараюсь делать модули во время сброса пассивными во всех смыслах,

Вот именно. И получаем простую схему:

1) совершенно АСИНХРОННЫЙ сброс, без всякого проброса чего либо и куда либо. Просто, глобальный резет.
2) Этот сброс, в том числе, запрещает работу всех приемников, таймеров, и прочего, что может словить метастабильность.
3) Инициатор (а он всегда есть, и один, который самый первый из всех), через какое-то время после снятия сброса разрешает работу всего, чего надо, и разрешает уже по каналам управления, которые проброшены через домены, как им следует быть проброшенными. И единственное синхронизированное от сброса место - эта первичная разрешалка. Один бит данных.

А сброс при этом, совершенно асинхронный... И думать о нем не надо.
des00
Цитата(SM @ Jan 13 2015, 00:16) *
А сброс при этом, совершенно асинхронный... И думать о нем не надо.

согласен. я раб привычек доведенных до автоматизма, наверное поэтому и ставлю sm.gif
vea
Цитата(SM @ Jan 12 2015, 19:16) *
Вот именно. И получаем простую схему:

1) совершенно АСИНХРОННЫЙ сброс, без всякого проброса чего либо и куда либо. Просто, глобальный резет.
2) Этот сброс, в том числе, запрещает работу всех приемников, таймеров, и прочего, что может словить метастабильность.
3) Инициатор (а он всегда есть, и один, который самый первый из всех), через какое-то время после снятия сброса разрешает работу всего, чего надо, и разрешает уже по каналам управления, которые проброшены через домены, как им следует быть проброшенными. И единственное синхронизированное от сброса место - эта первичная разрешалка. Один бит данных.

А сброс при этом, совершенно асинхронный... И думать о нем не надо.

Я правильно понимаю, что асинхронный сброс используется только для этого первого блока, а остальные включаются синхронным ENABLE (т.е. в них синхронизированный асинхронный сброс просто не заходит)?
Нажмите для просмотра прикрепленного файла
SM
Цитата(vea @ Jan 13 2015, 15:37) *
Я правильно понимаю, что асинхронный сброс используется только для этого первого блока, а остальные включаются синхронным ENABLE (т.е. в них синхронизированный асинхронный сброс просто не заходит)?


Не совсем.

Во первых, асинхронный сброс (который ни с чем не надо синхронизировать), заходит во все блоки сразу во всех доменах, и их всех асинхронно сбрасывает. Для этого в FPGA придумана единая глобальная линия сброса, и поэтому она там одна (а не пачка, как линий тактовых). И никакого "синхронизированного асинхронного сброса" нет. Он заходит на все сбросы не синхронизированным - прямо Ваш "RESET_n" как он есть. (но! внимание! именно на АСИНХРОННЫЕ входы сбросов всех блоков, которые требуют сброса)

Во вторых, этот самый Enable нужен далеко не всем блокам, и не целиком целиком - Enable нужен конкретным отдельно взятым триггерам, которые на момент снятия RESET-а по каким-то причинам могут иметь на входе состояние, отличное от того, во что они были установлены по RESET, и то, не всем. Например:
- Если это регистр, который записывается по команде из блока-инициатора, то ему отдельный Enable не нужен. Его и так инициатор разрешает только тогда, когда ему надо, и гарантировано, что не сразу после сброса..
- Eсли это таймер, считающий сам по себе с момента снятия резета, с приращением в 1 - то тоже не нужен. Почему? Потому что, при смене его состояния из 0 в 1 худшее, что может произойти, это что он задержится в состоянии 0 на 1 такт из-за метастабильности. Ну и что? От этого никому не холодно и не горячо.
- А вот если это некий сумматор, который прибавляет к значению регистра некий код, не равный 1 (а точнее, не коду с одним разрядом, установленным 1), и этот код может быть таким в момент снятия резета, то вот тут уже нужно разрешение работы, чтобы не было сбоя.

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

UPD:
А вот Enable этот генерируется синхронизирвоанным, как-то так:

reg [2:0] en_ff
always @(posedge clk or negedge RESET_n)
if (~RESET_n) en_ff <= 3'd0;
else en_ff <= {en_ff[1:0], 1'b1};

выход синхронизированного Enable берется с en_ff[2], и подается в необходимые точки, при необходимости, пересинхронизированным на другие клоки и в остальные клок-домены. А цепь асинхронного сброса надо исключить из временнОго анализа через set_false_path, так как Вы сами, схемотехнически устранили все возможности для сбоев.
Krys
Цитата(SM @ Jan 13 2015, 20:25) *
- Eсли это таймер, считающий сам по себе с момента снятия резета, с приращением в 1 - то тоже не нужен. Почему? Потому что, при смене его состояния из 0 в 1 худшее, что может произойти, это что он задержится в состоянии 0 на 1 такт из-за метастабильности. Ну и что? От этого никому не холодно и не горячо.
Идея хорошая. Но есть сомнения. Вот тут (страница 13, второй снизу абзац):
Цитата(des00 @ Jan 12 2015, 14:58) *
в приложении неплохая статья. изучайте.
говорится, что:
Цитата
If the asynchronous reset is released
at or near the active clock edge of a flip-flop, the output of the flip-flop could go metastable and thus the reset state
of the ASIC could be lost.
Это значит, что таймер может и не с нуля начать считать...

SM
Цитата(Krys @ Jan 14 2015, 14:28) *
Это значит, что таймер может и не с нуля начать считать...

Неа, не может, если изучить схему CMOS триггера. Если он сам в нуле, и на входе данных тоже ноль, то, что с ним не делай (кроме асинхронной установки в 1, которая тут не используется), в единицу его никак не загнать. Метастабильное состояние может возникнуть лишь тогда, и только тогда, когда в результате некоего действия ожидается смена состояния. И тогда оно может, как бы, неполностью смениться, что и есть суть метастабильности. А если внешних причин к смене состояния нет, то и метастабильность невозможна.

То есть, автор статьи, скорее всего сознательно, опустил этот нюанс, что для метастабильности недостаточно снять резет невовремя, а надо еще иметь на входе сигнал данных, отличный от состояния в резете. Иначе бы весь смысл его статьи потерялся бы sm.gif sm.gif
Krys
Цитата(SM @ Jan 14 2015, 17:31) *
Иначе бы весь смысл его статьи потерялся бы :) :)
Хотелось бы Вам верить. Ведь так гораздо проще реализовывать. Но вот в статье "уважаемые дяденьки" пишут... и подкинул нам её как эталон "уважаемый товарищ" )))
SM
Цитата(Krys @ Jan 15 2015, 06:24) *
Хотелось бы Вам верить.

А не надо мне верить. Возьмите, и поанализируйте схемы триггеров на транзисторном уровне. Сейчас в доступе есть достаточно и схем, и технологических либ разных фабов. Не первой свежести, но вполне достаточно. Хотя, профессиональному схемотехнику для этого достаточно схему лишь визуально изучить, даже без симуляции.
Krys
Цитата(SM @ Jan 15 2015, 15:58) *
А не надо мне верить. Возьмите, и поанализируйте схемы триггеров на транзисторном уровне.
Во всё вникать и проверять доказательства самому - не хватит времени на всё, это надо было делать ещё в вузе ))) Сейчас проще прислушаться к опыту "старших товарищей".
SM
Цитата(Krys @ Jan 15 2015, 14:18) *
Во всё вникать и проверять доказательства самому

Когда дело доходит до оптимизации, когда надо "впихнуть невпихуемое", еще не тем заниматься приходится...
vea
Цитата(SM @ Jan 15 2015, 14:25) *
Когда дело доходит до оптимизации, когда надо "впихнуть невпихуемое", еще не тем заниматься приходится...

Спасибо за развернутые объяснения.
Пока все-таки буду перестраховываться и пропускать сброс через каскад - меньше шансов наделать ошибок.
vea
Цитата(SM @ Jan 14 2015, 15:31) *
Неа, не может, если изучить схему CMOS триггера. Если он сам в нуле, и на входе данных тоже ноль, то, что с ним не делай (кроме асинхронной установки в 1, которая тут не используется), в единицу его никак не загнать. Метастабильное состояние может возникнуть лишь тогда, и только тогда, когда в результате некоего действия ожидается смена состояния. И тогда оно может, как бы, неполностью смениться, что и есть суть метастабильности. А если внешних причин к смене состояния нет, то и метастабильность невозможна.
В статье Asynchronous & Synchronous ResetDesign Techniques - Part Deux, пункт 7.2 так и говорится: "[...] examine the transistor-level version of the model [...] the circuit was indeed not susceptible to metastability problems if the d-input was low when a reset recovery violation occurred [...]" (речь о втором регистре в каскаде, о третьем-четвёртом даже не говорится).
Цитата(SM @ Jan 12 2015, 20:16) *
Вот именно. И получаем простую схему...
Правда, схемы в этой статье не такие уж и простые.
SM
Цитата(vea @ Jan 20 2015, 15:54) *
the circuit was indeed not susceptible to metastability problems if the d-input was low when a reset recovery violation occurred [...]


Перевожу:

"схема была действительно не восприимчива к проблемам метастабильности, если вход "D" был низким, когда произошло нарушение времени восстановления сброса"

Собственно, именно это утверждаю и я, как и тот инженер, что в этом случае метастабильность невозможна. А все остальное - глюки моделей разных вендоров, а не проблемы железа. Я и под этим подпишусь, вообще, в части метастабильности, почти все модели глючные.
troiden
А вот Xilinx не сответует использовать везде глобальный асинхронный сброс. Мол не дает использовать дополнительный вывод у тех триггеров ячейки, в которые этот ресет не заводится, и увеличивает количество занимаемых ресурсов.
Ну и у некоторых элементов вообще нет входа асинхронного сброса.
SM
Цитата(troiden @ Jan 20 2015, 16:26) *
Мол не дает использовать дополнительный вывод у тех триггеров ячейки, в которые этот ресет не заводится, и увеличивает количество занимаемых ресурсов.

Я не буду спорить, что в каких-то, отдельно взятых, ПЛИС это может оказаться неэффективным из-за их неудачной в этом плане архитектуры. Однако, у всех альтер имеется одна (и только одна) линия глобального сброса (global clear), к которой имеется возможность подключить сброс или предустановку любого триггера матрицы, и, точно также, у lattice (линия называется GSR, и она тоже единственная на весь чип). То есть, такие ПЛИС, где этот подход увеличивает занятость ресурсов - это исключения из правила.

PS
У Xilinx, кстати, тоже есть такой сброс, как и у Lattice, GSR называется... Так что...
troiden
Ситуация, когда надо погасить весь кристалл, значительно реже ситуации, когда надо погасить отдельный модуль. Для отдельного модуля GSR не поможет.
SM
Цитата(troiden @ Jan 20 2015, 16:44) *
Для отдельного модуля GSR не поможет.

У каждого отдельно взятого триггера есть бит конфигурации, подключен он к GSR, или не подключен. И роль GSR - set или reset. Так что, еще как поможет, если это использовать грамотно. Синтезатор подключает к GSR только те триггеры, которые требуют резета по RTL, если используется авто-инферринг сигнала GSR, а не его задание как "жестко гасить все".

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


--------------
UPD: Вот, на картинке - GSR подключен, он асинхронный. И это не мешает использовать еще и LSR для чего-то другого, по желанию синтезатора. То есть, двойная экономия - и на разводке глобального ресета, и еще и на какой-то логике, которую синтезатор может реализовать через LSR в режиме синхронной предустановки в 1 (ну или сброса).
Нажмите для просмотра прикрепленного файла
alxkon
Цитата(SM @ Jan 13 2015, 17:25) *
Не совсем.

Во первых, асинхронный сброс (который ни с чем не надо синхронизировать), заходит во все блоки сразу во всех доменах, и их всех асинхронно сбрасывает. Для этого в FPGA придумана единая глобальная линия сброса, и поэтому она там одна (а не пачка, как линий тактовых). И никакого "синхронизированного асинхронного сброса" нет. Он заходит на все сбросы не синхронизированным - прямо Ваш "RESET_n" как он есть. (но! внимание! именно на АСИНХРОННЫЕ входы сбросов всех блоков, которые требуют сброса)

Во вторых, этот самый Enable нужен далеко не всем блокам, и не целиком целиком - Enable нужен конкретным отдельно взятым триггерам, которые на момент снятия RESET-а по каким-то причинам могут иметь на входе состояние, отличное от того, во что они были установлены по RESET, и то, не всем. Например:
- Если это регистр, который записывается по команде из блока-инициатора, то ему отдельный Enable не нужен. Его и так инициатор разрешает только тогда, когда ему надо, и гарантировано, что не сразу после сброса..
- Eсли это таймер, считающий сам по себе с момента снятия резета, с приращением в 1 - то тоже не нужен. Почему? Потому что, при смене его состояния из 0 в 1 худшее, что может произойти, это что он задержится в состоянии 0 на 1 такт из-за метастабильности. Ну и что? От этого никому не холодно и не горячо.
- А вот если это некий сумматор, который прибавляет к значению регистра некий код, не равный 1 (а точнее, не коду с одним разрядом, установленным 1), и этот код может быть таким в момент снятия резета, то вот тут уже нужно разрешение работы, чтобы не было сбоя.

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

UPD:
А вот Enable этот генерируется синхронизирвоанным, как-то так:

reg [2:0] en_ff
always @(posedge clk or negedge RESET_n)
if (~RESET_n) en_ff <= 3'd0;
else en_ff <= {en_ff[1:0], 1'b1};

выход синхронизированного Enable берется с en_ff[2], и подается в необходимые точки, при необходимости, пересинхронизированным на другие клоки и в остальные клок-домены. А цепь асинхронного сброса надо исключить из временнОго анализа через set_false_path, так как Вы сами, схемотехнически устранили все возможности для сбоев.

Решил поднять старую тему.
Как идеологически верно поступить в таком случае:
Модуль состоит из нескольких Конечных Автоматов (КА), один из них главный управляющий, следит за результатами остальных.
Подчиненные КА следят за внешними (относительно ПЛИС) сигналами, каждый за своим определенным набором.
Главный КА дает разрешение на работу global_en и подчиненные КА начинают работу, есть сигнализация типа busy, done, error,....
В штатном режиме все просто, все КА будут в состоянии idle.
При обнаружении ошибки в работе нужно сбросить все остальные КА в состояние idle (busy = '0' ).
По моему идейно верно было бы установить global_en в '0'. Но такой подход потребует проверку global_en = '0' в каждом стейте, если внешние процессы медленные относительно процессов в ПЛИС и автомат не скоро перейдет в idle. Eсли состояний много то описание КА получается не очень... Другой вариант это главный КА делает локальный внутримодульный синхронный сброс всем подчиненным КА. И это не очень нравится.
Какой подход все же лучше?
Golikov A.
1. Чем вам не нравится сброс от главного автомата?
2. Почему вы не можете global_en проверять каждый такт и перебросить автомат в IDLE как только, так сразу, а не при очередном переходе?

Сигнал сброса может быть из 2 источников объединенных по ИЛИ, тут просится именно такое решение один общий сброс от схемы, и дополнительный сброс от ведущего автомата.
alxkon
Цитата(Golikov A. @ Jun 1 2017, 17:41) *
1. Чем вам не нравится сброс от главного автомата?
2. Почему вы не можете global_en проверять каждый такт и перебросить автомат в IDLE как только, так сразу, а не при очередном переходе?

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

Спасибо за ответ! beer.gif

Честно говоря похоже некая фрустрация, все проблемы от стереотипов в голове. Темные места в подсознании помноженные на ненужный перфекционизм sm.gif

1. Всегда старался строить КА так что бы им не нужен был сброс, кроме начального.
2. Не нравится описание - в каждом стейте нужно проверять, не изящно.

Сделаю с ресетом от главного КА + общий сброс.
Golikov A.
Цитата
Не нравится описание - в каждом стейте нужно проверять, не изящно.


проверяйте после автомата в том же алвайсе, последние условие перекроет все верхние.
можно в начале как дополнительная ветвь else if после сброса

изящно описать то можно многими путямиsm.gif



Цитата
Всегда старался строить КА так что бы им не нужен был сброс, кроме начального.

сброс хорошая вещь, явное приведение блока в определенное состояние, меньше сценариев - выше качество проверки и итоговая надежность
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.