[Golikov 0]

Всем привет!

 

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

 

reg [3 : 0] State;

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

 

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

default: State <= 0;

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

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

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

Короче в целом обязано ли быть состояние default везде, или нет?

[tdocs.su 0]

Запросто может влететь. Поэтому дефолт нужен обязательно. Хоть понятно будет, куда автомат свалился.

[Golikov 0]

С дефолтом как раз не будет, он перейдет в IDLE или понятное состояние.

Свалиться тоже не понятно, насколько часто(вероятно)? Потому что если этот автомат может легко влететь в состояния которого нет, то любой автомат может легко пойти не по своей программе, что несколько странно...

[iosifk 3]

С дефолтом как раз не будет, он перейдет в IDLE или понятное состояние.

Свалиться тоже не понятно, насколько часто(вероятно)? Потому что если этот автомат может легко влететь в состояния которого нет, то любой автомат может легко пойти не по своей программе, что несколько странно...

Да просто все здесь...

Мы не рассматриваем нейтроны и прочие излучения.

А вот при разработке процессоров, которые тоже являются автоматами, проводится привязка всех (!) входных сигналов к частоте ядра.

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

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

А что касается "вероятности", то тут так: года в телефонной станции сбрасывается междугородка, то бухгалтер материт связистов...

А когда Саяно-Шушенская ГЭС один раз за весь срок работы... то...

Так что вот...

 

[Golikov 0]

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

[Pavia 0]

iosifk

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

 

Golikov A.

Сам я новичёк, только недавно начал осваивать ПЛИС поэтому могу и заблуждаться.

 

Есть надёжность, а есть устойчивость. Так вот это два разных понятия. В первым вы повышаете надёжность к примеру аппаратно меняя тип микросхемы.

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

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

С другой стороны надо исходить из принципа достаточности.

 

Что касается частиц и излучения. Если для вас это критично, то рассматривать стоит. Лично я для себя этот вопрос проработал. Так вот в ПЛИС заложена уже защита, от излучения и частиц. Да и в бытовых условиях их энергии не высоки. Так что бояться их не стоит.

 

Зато вот стоит опасаться "гонки сигналов". В литературе про автоматы она описана. Если доверять разработчикам софта компиляции для ПЛИС, то в соответствии со стандартами на HDL они должны были выбрать время работы так что-бы регистр обновлялся менее чем за 1 такт. И как следствие никаких гонок не может быть.

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

 

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

 

И самая большая проблема это человеческий фактор. Вернее единственная. При написании программ человек пишет и многократно переписывает участки кода. И может чисто машинально сделать ошибку перейдя не в то состояние. Так что вот из-за этого и стоит обрабатывать не определённые состояния.

Изменено 21 мая, 2014 пользователем Pavia

[iosifk 3]

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

А еще забыл написать про сторожевую собаку... Она же лает иногда. А кто проверяет почему она это сделала в каждом конкретном случае?

Пренебрегать я не советую.

Пример. Ставил я когда-то в 90-х телефонные станции. А городские линии под трамвайными рельсами ловили наводку. Так вот именно эта линия и шла к директору завода...А от наводки на станцию внутренний телефон начинал звякать.. И он категорически отказывался переходить на другую линию с другим номером... Как Вам это? И при любом сбое на фирму шла бумага... А теперь представьте, что такую же станцию поставили бы в другом городе. Так на поисках сбоев фирму можно было бы разорить...

 

[RobFPGA 27]

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

 

При разработке любых схем, а особенно цифровых - надо в первую очередь выработать в себе правило - НЕ НАДЕЙСЯ на чужого дядю (зачастую индусского) - хочешь спать спокойно - делай все ЯВНО и ПОНЯТНО (ну и налоги заплати :) ).

К тому же явное указание состояния default, а также различные варианты case, casex ... помогают при синтезе оптимизировать логику FSM что также может добавить вам минут сладкого сна.

 

Успехов! Rob.

[Golikov 0]

Вот!... то есть все за то чтобы default скорее был, чем не был...

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

 

Другое дело что часть автоматов у меня самовостанавливающихся, то есть их внешним сигналом затягивает в начальное состояние, и вот что делать с дефалтами для них....

 

Буду завтра пересматривать проект на предмет дефалтизации автомата....

 

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

[tdocs.su 0]

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

 

При разработке любых схем, а особенно цифровых - надо в первую очередь выработать в себе правило - НЕ НАДЕЙСЯ на чужого дядю (зачастую индусского) - хочешь спать спокойно - делай все ЯВНО и ПОНЯТНО (ну и налоги заплати :) ).

К тому же явное указание состояния default, а также различные варианты case, casex ... помогают при синтезе оптимизировать логику FSM что также может добавить вам минут сладкого сна.

 

Успехов! Rob.

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

Насчет налогов - их надо оптимизировать :)

 

А еще забыл написать про сторожевую собаку... Она же лает иногда. А кто проверяет почему она это сделала в каждом конкретном случае?

Пренебрегать я не советую.

Пример. Ставил я когда-то в 90-х телефонные станции. А городские линии под трамвайными рельсами ловили наводку. Так вот именно эта линия и шла к директору завода...А от наводки на станцию внутренний телефон начинал звякать.. И он категорически отказывался переходить на другую линию с другим номером... Как Вам это? И при любом сбое на фирму шла бумага... А теперь представьте, что такую же станцию поставили бы в другом городе. Так на поисках сбоев фирму можно было бы разорить...

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

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

 

Мораль: существуют т.н. внешние воздействующие факторы, которые тоже надо учитывать :)

[Golikov 0]

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

Насчет налогов - их надо оптимизировать

 

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

 

 

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

 

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

 

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

 

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

 

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

 

 

[tdocs.su 0]

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

Убили наповал! :)

 

Если автомат меняет состояния так, как мы ему говорим, то нам - развлекухи ради - имеет смысл убедиться в том, что он меняет их именно так, как мы ему сказали, а никак иначе. Для этого существует отладка. Чтобы не быть голословным - Отладка программы (Program debug) по ГОСТ 19.004-80 - Обнаружение, локализация и устранение ошибок в программе вычислительной машины [из п. 9 ГОСТ 19.004-80] Про тестирование и испытания даже упоминать не смею. Отладка позволяет также проверить правильность архитектуры проекта без долгого анализа поведения системы :)

 

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

 

[iosifk 3]

Убили наповал! :)

 

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

Немного добавлю.

Как мы все знаем, любая деятельность - это риск.

Так вот какой у Вас, Андрей, критерий этого риска? Как Вы ведете разработку и как относитесь к риску?

 

[Golikov 0]

Убили наповал! :)

 

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

 

 

 

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

Не только были услышаны и внимательно прочитаны, но и обдуманы, последние 2 абзаца несколько другие нежели в начале, и с учетом сказанного....

 

 

Так вот какой у Вас, Андрей, критерий этого риска? Как Вы ведете разработку и как относитесь к риску

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

 

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

 

 

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

 

 

[tdocs.su 0]

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

Не только были услышаны и внимательно прочитаны, но и обдуманы, последние 2 абзаца несколько другие нежели в начале, и с учетом сказанного....

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

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

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

Тока я не понял, что вы понимаете под архитектурой.

Прочее понятно:

Риск по ГОСТ 53114-2008 - Влияние неопределенностей на процесс достижения поставленных целей.

Примечания:

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

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

Риск часто выражается в терминах комбинации последствий события или изменения обстоятельств и их вероятности.

 

Перемежающийся отказ по ГОСТ 27.002-89 - Многократно возникающий самоустраняющийся отказ одного и того же характера [из п. 3.14 Таблицы 1 ГОСТ 27.002-89]

 

Терминология хромает, поэтому и не можем понять друг друга. Правильно я аргументировал? :)