[tdocs.su 0]

Копаем глубже:

[b]if(a>b) ...; else if(a<b) ...;[/b]

Есть ли гарантия того что "из-за сбоя" не выполнятся обе ветви (a>b) и (a<b)?

Подобный код заведет Вас в такие дебри, что и не выберетесь никогда оттуда. Только case - исключительно case!

 

 

Если бы я так считал, то не затевал бы тему.

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

дописать пустой дефалт, то есть

default: begin end;

?

а не равно ли это его отсуствию?

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

[Golikov 0]

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

 

1. ISE на возврат в начальное состояние из default: не увеличивает числа переходов обнаруженного автомата, и я не знаю как проверить не выкидывает ли он эти переходы в ходе оптимизации. Сейчас мне кажется что выкинет, зачем делать переходы, которых не может быть? С самого начала темы я отмечал что ISE находит автоматы и изменяет их по своему пониманию.

 

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

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

[olegras 0]

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

Тем более что диагностический блок - это тоже автомат?.. :rolleyes:

[tdocs.su 0]

1. ISE на возврат в начальное состояние из default: не увеличивает числа переходов обнаруженного автомата, и я не знаю как проверить не выкидывает ли он эти переходы в ходе оптимизации. Сейчас мне кажется что выкинет, зачем делать переходы, которых не может быть? С самого начала темы я отмечал что ISE находит автоматы и изменяет их по своему пониманию.

 

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

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

Ох... Я хорошо перекусил и выпил винца, потому соображаю сейчас туговато, зато настроение хорошее :) Вот ссылка на мою древнюю статью по автоматам, которую написал, еще помня войну с самими автоматами - интервал между войной с автоматами, статьей и текущим моментом - примерно по 10 лет. Вот - http://tdocs.su/4199

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

Досадно то, что у меня даже дельфийский код 20-летней давности в архиве хранился, но поганая винда вдруг начала проверку терабайтного внешнего диска и грохнула весь архив с 1994 года... :(

 

По 2. Не надо! Влетел в непонятку - отфиксируйте непонятку, потом проще будет разобраться, что это было - сохраните "хвост" в буфере и переходите на реинициализацию.

[Golikov 0]

Чую мне тоже надо винца чтобы понять:))) где я сохраню хвост то и чем? Как сказали выше сделать еще один автомат который будет следить за маловероятными событиями и где-то хранить хвосты?

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

 

П.С. почитал вашу статью, не могу не отметить что статья мне ОЧЕНЬ не понравилась... ни по стилю, ни по содержанию, уж извините... осилил до начала Пушкина, не заслужил поэт такого, как и ООП смысл которого от автора ускользнул...

[Sefo 0]

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

 

Увы, не поможет. Если проблемы с таймингом, то защититься невозможно - ошибки совершенно непредсказуемы в общем случае. А если и предсказуемы, то практически не поправимы. Ничего кроме устранения проблем с таймингом путем изменения Place & Route, дизайна (например, введение pipeline) или понижения тактовой частоты не поможет.

 

Вот меня вдруг обеспокоил такой момент. Делаем конечный автомат, полностью определенный. то есть из любого его состояния по любому входному воздействию есть переход в заданное состояние. Состояний у автомата допустим 9. Значит регистр с состоянием 4 битный

 

reg [3 : 0] State;

case(State)
   0: ...
   1: ...
   ...
   8: ...
endcase

 

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

default: State <= 0;

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

Делает ли он что-то с неописанными состояниями?

Какова вероятность что из-за каких-то внешних факторов автомат влетит в эти состояния, и куда они его приведут?

 

 

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

 

 

По конкретному вопросу определенности за ночь не появилось...

 

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

 

1) Автомат может оказаться не в том состоянии в самом начале - если не используется сигнал сброса и нет указаний синтезатору обеспечить строго определенное состояние триггеров этого автомата

 

2) Автомат может оказаться не в том состоянии если он неправильно описан. Все, что находится внутри case и влияет на состояние автомата, в конечном счете, преобразуется в некую комбинаторную логику. Выходом этой логики является значение следующего состояния автомата, которое защелкивается регистрами. Входами для этой логики являются: текущее значение состояния автомата + все сигналы, которые определяют направление перехода (управляющие сигналы).

 

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

 

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

 

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

 

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

 

Хотелось бы выслушать мнение уважаемой публики, по поводу последних 2 абзацев

 

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

 

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

 

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

 

Подозреваю, что default следовал после всех возможных состояний. В этом случае экономии быть и не должно - доп. состояние требует доп. логики. Вы попробуйте объединить default с каким-нибудь "нейтральным" состоянием, типа IDLE. Вот тогда объем логики должен уменьшится.

 

 

 

[Golikov 0]

Вот, спасибо за длинный текст!

 

Мое последние исследование показало что наличие default как пустого, так и с переводом всех состояний в IDLE, средой игнорируется, Ни число состояний ни число переходов автомата не меняется по сравнению с вариантом когда default нету, это я по логам что мне ISE пишет заключаю. Что там в железе из ЛУТов собралось сил проверить не хватило.

Более того среда еще меняет мою нумерацию состояний на свою, по коду грея измененную, то есть на самом деле ISE достаточно внимательно относится к автоматам)...

 

 

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

 

Еще раз спасибо за ответ.

 

 

[petrov 6]

Мое последние исследование показало что наличие default как пустого, так и с переводом всех состояний в IDLE, средой игнорируется, Ни число состояний ни число переходов автомата не меняется по сравнению с вариантом когда default нету, это я по логам что мне ISE пишет заключаю.

 

Смотрите опции вашего синтезатора, обычно это называется навроде safe implementation(восстановление из неопределённых состояний в начальное) и по умолчанию выключено.

 

[tdocs.su 0]

Чую мне тоже надо винца чтобы понять:))) где я сохраню хвост то и чем? Как сказали выше сделать еще один автомат который будет следить за маловероятными событиями и где-то хранить хвосты?

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

 

П.С. почитал вашу статью, не могу не отметить что статья мне ОЧЕНЬ не понравилась... ни по стилю, ни по содержанию, уж извините... осилил до начала Пушкина, не заслужил поэт такого, как и ООП смысл которого от автора ускользнул...

Каждому - свое.

[Golikov 0]

Смотрите опции вашего синтезатора, обычно это называется навроде safe implementation(восстановление из неопределённых состояний в начальное) и по умолчанию выключено.

есть такая буква, и там есть отсылка к такому документу

http://www.xilinx.com/support/documentatio..._4/xst_v6s6.pdf

где написано

Safe Finite State Machine (FSM) design is a subject of debate. There is no single perfect

solution.

Так что вот.... при этом написано что

XST detects and optimizes the following by default:

– Unreachable states (both logical and physical)

– Related transition logic

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

 

Спасибо за наводку, пойду почитаю еще этот полезный документ)

 

----

как забавно там как раз про космические лучи и альфа частицы сказано%) что для таких случаев надо делать safe implentation, чтобы недостижимые состояния не оптимизировались и свелись к состоянию восстановления (начальному, ресетному или указанному).

[iosifk 3]

Кстати, вспомнил, что входные сигналы на автомат должны быть обработаны пр CDC...

и у них не должно быть дребезга. Дребезг по входным сигналам может загнать автомат в задницу...

[tdocs.su 0]

Кстати, вспомнил, что входные сигналы на автомат должны быть обработаны пр CDC...

и у них не должно быть дребезга. Дребезг по входным сигналам может загнать автомат в задницу...

См. личку :)

[Golikov 0]

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

[petrov 6]

Кстати, вспомнил, что входные сигналы на автомат должны быть обработаны пр CDC...

и у них не должно быть дребезга. Дребезг по входным сигналам может загнать автомат в задницу...

 

Помню свой первый автомат приёмник RS-232, было полной неожиданностью что он иногда зависает, про метастабильность ессно ничего не знал. :)

 

 

[tdocs.su 0]

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

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

ЗЫ. И, кстати, не поленюсь сказать Вам за статью огромное спасибо :)