[RobFPGA 27]

Приветствую!

28 minutes ago, des00 said:

это ошибка, но это ошибка этого автомата, не приводящего к ошибке в системе, при корректном проектировании.

Ошибочное состояние  автомата  это уже ошибка системы (ведь такой автомат не выполнил заданный функционал)  - тут  вопрос лишь  в том на сколько катастрофически будет такая ошибка для системы в целом.
Да есть смысл усложнять систему когда источник угроз ошибок не контролируется (например из за радиации).  Но сознательно идти на внесение неконтролируемых ошибок и потом пытаться с ними бороться ...     

Удачи! Rob.

[des00 25]

44 minutes ago, RobFPGA said:

Ошибочное состояние  автомата  это уже ошибка системы (ведь такой автомат не выполнил заданный функционал)  - тут  вопрос лишь  в том на сколько катастрофически будет такая ошибка для системы в целом.

угу, также как и ошибка внутренних триггеров CDC это уже ошибка всей системы)) я же специально указал, что КА у ТС это и есть CDC, т.е. устройство специально спроектированное для работы со внутренними ошибками. Это его задача. Не надо сравнивать это с другими управляющими структурами.

Quote

Да есть смысл усложнять систему когда источник угроз ошибок не контролируется (например из за радиации).  Но сознательно идти на внесение неконтролируемых ошибок и потом пытаться с ними бороться ...    

ну зачем это надо ТС, только ему знать. Он дал пояснения по этому вопросу.

[RobFPGA 27]

Приветствую!

1 minute ago, des00 said:

угу, также как и ошибка внутренних триггеров CDC это уже ошибка всей системы)) я же специально указал, что КА у ТС это и есть CDC, т.е. устройство специально спроектированного для работы со внутренними ошибками. Это его задача. Не надо сравнивать это с другими управляющими структурами.

В стандартном CDC  внутренние "ошибки" контролируется  так как структура CDC для этого специально рассчитана. И вы зная параметры и требования можете  управлять вероятностью распространения такой ошибки за пределы CDC.
В  FSM TC такое  в общем случае невозможно.  Множественные цепи (c различными неконтролируемыми задержками) от источника асинхронного сигнала  до различных синхронных получателей не дают вам возможности предсказать куда и когда свалится  такой FSM.
Функция синтеза  safe-coding лишь автоматом добавляет логику детектирования и выхода из ошибочного недопустимого состояния (если это не сделано ручками). Но ни как не добавляет CDC функционал.
Да  и метастабильность такой автомат не уберет - раз асинхронный вход  напрямую приходит на входы регистров состояния FSM, а куда (и с каким fanout  ) идут выходы такого FSM... только TC и виднее.

23 minutes ago, des00 said:

ну зачем это надо ТС, только ему знать

Ему же и крутить барабан ....   Надеюсь только он не лифтовое оборудование  разрабатывает ... 

Удачи!  Rob.

[Plain 168]

41 минуту назад, RobFPGA сказал:

не лифтовое оборудование  разрабатывает

Да не, стандартная история с жабоудушением — нет места, нет ног и т.п. — чтобы тупо вывести из STM тактовый сигнал.

[des00 25]

7 hours ago, RobFPGA said:

В  FSM TC такое  в общем случае невозможно. 

Это не общий случай. 

7 hours ago, RobFPGA said:

Множественные цепи (c различными неконтролируемыми задержками) от источника асинхронного сигнала  до различных синхронных получателей не дают вам возможности предсказать куда и когда свалится  такой FSM.

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

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

[xvr 12]

12 hours ago, des00 said:

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

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

 

Если неправильные переходы автомата для ТС допустимы, то можно считать, что всё ок

[RobFPGA 27]

Приветствую!

5 hours ago, des00 said:

давайте положим что вы бесусловно правы ...

Лучше уж продолжим, не хочется быть всегда правым (надоело   )

5 hours ago, des00 said:

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

Мы же сейчас не обсуждаем  класс  "самосинхронных" решений которые  работают без общего клока и в общем случае не реализуются  на базе стандартного FPGA, а требуют специфического железа?    
В таком случае мне не понятно определение "самосинхронного автомата"  Ведь даже если такой  автомат смог вернутся в состояние бывшее перед сбоем, то как может он "выполнить программу" если он потерял такты на эти кульбиты? 
 

12 minutes ago, xvr said:

Давайте уточним - такой автомат действительно будет работать как CDC цепь, и метастабильность за его пределы не выйдет.

 Метастабильность не выйдет если параметры триггеров целевой FPGA, и частот сигнала и тактовой дадут вам адекватное время MBTF.  Но даже для современных FPGA  для одного триггера эта цифра будет приемлемой лишь при достаточно низких частотах.

 

Удачи! Rob.

[dvladim 0]

7 часов назад, RobFPGA сказал:

Ведь даже если такой  автомат смог вернутся в состояние бывшее перед сбоем, то как может он "выполнить программу" если он потерял такты на эти кульбиты? 

Автомат с гарантированным выходов в исходное состояние. Например JTAG TAP и выход по 5 единицам в TEST LOGIC RESET.

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

[RobFPGA 27]

Приветствую!

15 minutes ago, dvladim said:

Автомат с гарантированным выходов в исходное состояние.

Это понятно (для этого и ресет есть)  но вопрос  в том что вы ожидаете по входному сигналу переход  из состояния  S1 в S2  а автомат валится в Serror ....  Все - сигнал потерян  реакции на событие  нет (тормоз на лифте не сработал),  хорошо хоть автомат не повис и  сам в Sidle вышел   (можно будет поднять лифт назад и попробовать еще раз  )

23 minutes ago, dvladim said:

Т.е. если кодирование этих ближайших состояний отличается 1-м битом, то все безопасно (но это не точно)

Это  точно что "это не точно".  А как быть если  переходов из текущего состояния более 2?   
Gray  удобен при преимущественно последовательных переходах  так как позволяет минимизировать мощность переключения.
И  да  - только при последовательном изменении кода на входе, gray в CDC получается однозначно передавать такой код через клоковые домены при любом соотношении частот. 
А  вот передавать рандомные  данные  через gray смысла нет - так  как на выходе будем получать и ошибочные коды.  

 

Удачи! Rob.

[iosifk 3]

05.06.2021 в 12:13, Nagisa сказал:

источник STM32F407, тестирование показало, что он меняет состояние на порту за 1 такт внутренней частоты 162MHz (понятное дело, что есть оговорки)к. 

Читаю огромную переписку по поводу тому как надо сделать автомат чтобы вывернуть ему интимное место и сделать кое из чего пулю.

Ну при этом вот что хочу сказать.

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

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

[vt313 0]

13 часов назад, RobFPGA сказал:

Приветствую!

Это понятно (для этого и ресет есть)  но вопрос  в том что вы ожидаете по входному сигналу переход  из состояния  S1 в S2  а автомат валится в Serror ....  Все - сигнал потерян  реакции на событие  нет (тормоз на лифте не сработал),  хорошо хоть автомат не повис и  сам в Sidle вышел   (можно будет поднять лифт назад и попробовать еще раз  )

Это  точно что "это не точно".  А как быть если  переходов из текущего состояния более 2?   
Gray  удобен при преимущественно последовательных переходах  так как позволяет минимизировать мощность переключения.
И  да  - только при последовательном изменении кода на входе, gray в CDC получается однозначно передавать такой код через клоковые домены при любом соотношении частот. 
А  вот передавать рандомные  данные  через gray смысла нет - так  как на выходе будем получать и ошибочные коды.  

 

Удачи! Rob.

На вскидку, не представляю, куда может неправильно перейти этот автомат. 

[xvr 12]

12 minutes ago, vt313 said:

На вскидку, не представляю, куда может неправильно перейти этот автомат. 

Ну например вместо STATE_STM_FLAG->STATE_STM_WAIT может улететь куда угодно (этот переход в Грей не ложится)

[vt313 0]

14 минут назад, xvr сказал:

Ну например вместо STATE_STM_FLAG->STATE_STM_WAIT может улететь куда угодно (этот переход в Грей не ложится)

Как? Кодирование тут никакой роли не играет. 

[dvladim 0]

23 часа назад, RobFPGA сказал:

Это понятно (для этого и ресет есть) 

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

23 часа назад, RobFPGA сказал:

А как быть если  переходов из текущего состояния более 2?

Поэтому я говорил о конкретном автомате, а не об общем случае.

23 часа назад, RobFPGA сказал:

А  вот передавать рандомные  данные  через gray смысла нет

Если на выходе (после gray или как-нибудь еще) данные отличаются 1-м битом, то проблем не предвидится.

 

PS. Вообще есть ощущение, что все это можно сделать и без такого автомата состояний.

[RobFPGA 27]

Приветствую!

22 minutes ago, dvladim said:

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

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

22 minutes ago, dvladim said:

Если на выходе (после gray или как-нибудь еще) данные отличаются 1-м битом, то проблем не предвидится.

Я же не зря указал что данные на входе в gray "рандомные"   А в рандомных данных отличия последовательных слов в среднем в половине битов.  
Поэтому  на таких данных (да и на всех других кроме линейных) gray CDC не работает. 

 

Удачи! Rob.