Привлекает позиционирование как контроллеров повышенной надежности, знакомое ядро, хорошая производительность, темп. диапазон. Пугает то, что только вчера о них услышыл и тут тишина. И вкратце, что такое lockstep dual core ?

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

У Вас какое-то стойкое и трудно-объяснимое наукой отвращение от Freescale.
Травма детства, если не секрет?

Защитная реакция на некоторых рекламщиков (уж больно навязчивые). Хотя и в самом деле - серые они какие-то, скучные

А сам-то Freescale причем?
У нас, например, остались вполне положительные впечатления от всех PowerQUICC, ColdFire (да и не только).

Сейчас АРМ все же в почете. Из фрискейла поработал начиная с HC08, HC11, DSP56Fxx. На последнем терпение лопнуло - неудобные среды программирования, поддержки производителя ноль, не шибко прямая на мой взгляд архитекура, жуткие отладки

По поводу поддержки позволю себе не согласиться.
По крайней мере касательно CPU поддержка была на высоком уровне как
от Freescale так и от их российского представительства. Про DSP не скажу,
единственное, Freescale сами признали, что касательно DSP уделяли мало внимания
мелким\средним клиентам (основные пользователи их DSP - военные и телеком).
Обещали исправиться
С точки зрения архитектуры и соотношения цена/производительность, мне лично кажется, что Freescale выглядит более чем достойно.

Ну ладно, все же по теме хотелось бы отзывы.

Работая с Freescale вообще никогда не нужна была тех. поддержка. Только по молодости один раз обращался. И ответ, кстати, получил. А проблема, как потом оказалось, была в собственной некомпетентности.
В тех. поддержку в принципе трудно обращаться поскольку надо собрать кучу фактических материалов и еще их оформить в доступном виде. Т.е. доказать компетентность.
А иначе никто отвечать не будет. И правильно будут делать.

Но Freescale абсолютный лидер по качеству софта для своих микроконтроллеров особенно что касается Kinetis.

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

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

--------------

ну и поверпц очень годная архитектура была, я уже лет 7-8 не пользовал, но до сих пор положительные воспоминания (ну и периферию всегда в мотороле годную делали - программисты до сих пор требуют - сделайте так как было в РРС)

Тут у вас подмена понятий - надежность v.s. безопасность.

Надежность - это число сбоев/отказов за период времени.
А безопасность - это когда при сбоях или отказах система в целом выполнила недопустимую операцию.
Так вот локстеп надежность не повышает, даже наоборот. А вот безопасность системы с такими наворотами - выше. Но для того что бы это по настоящему заиграло вам необходимо будет еще выполнить все требования safety manual в ПО и построении системы в целом.

Да, верно. Но как-то пока не очень представляю как безопасноть растет. Вообще неясно - как определяется сбой мастер процессора ? Похоже действительно, не нужно это пока нам. OK. Хотя все равно интересно

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

ECC опять же есть на все типы встроенной памяти. CRC на всех коммуникационных каналах. Самотестирование аппаратное. Что это все как не средства повышения надежности?

А вот безопасность она только от софта зависит.
И вот этого софта и нет открытого, и дешеветь оно не будет.
И это убивает весь интерес.

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

Надежность - свойство объекта сохранять во времени в установленных пределах значения всех параметров,
характеризующих способность выполнять требуемые функции в заданных режимах,
условиях применения, технического обслуживания, хранения и транспортирования.
(ГОСТ 27.002-89)

Надежность и безопасность вообще из разной оперы.
Устройство может быть надежно и опасно (AK-47, например)

P.S.
И кажется мне, что слово safety в контексте программирования больше соответствует надежности а не безопасности.

Я так понимаю, что речь идет не о том, что устройство должно при обнаружении отказа продолжать нормально работать, а, скорее, лучше пусть отрубается совсем, или выдает error на ножку, которая, в свою очередь, отрубит например силовое питание клапанов или движков. Как-то так. То есть не "делай во чтобы то ни стало" а "не можешь делать - лучше отрубись". Не знаю как это по ГОСТ звучит =)

+1. Если ты не Боинг, или, на худой конец, НАСА - они тебя просто не замечают. С дистрибуцией была таже фигня.

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

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

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

Вообще многие приблуды Hercules ориентированы на снижение рисков в процессе разработки, а не в процессе эксплуатации.
Соответственно гаражным разработчикам будут непонятны и неприемлемы.

Вы сферического коня в вакууме обсуждаете, впрочем как и я. По Вашей логике - стоп-краны в поездах не нужны, кнопки Стоп красные на механизмах - это только для гаражей. Лучше скажите, что делает Техас при обнаружении fault на одном из ядер ? Если передает управление другому, то какие вопросы ? Это именно мера повышения надежности в процессе эксплуатации. Причем в случае , допустим, станка - лучше и остановить процесс по возможности. В случае стимулятора - работать на другом, выбора нет. Всем понятно, что надо проектировать девайса так, чтобы (длинный список ляляля, удовлетворить который, надо полагать, могут только процессоры от одного известного производителя в комплекте с софтом от него же + полная смена разработчиков на кошерных) Причем тут разработка вообще неясно - второе ядро как датчик ЕМС что-ли работает ? Мажорирование ячеек в радиационно-стойких ПЛИС Актеля - тоже для комфорта разработчиков ?

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




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

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

Так вот, в этом случае можно сделать этот вентиль на одном микроконтроллере и 2-х последовательных вентилях (а не какая нибудь троированная система). Процедура открытия будет состоять из трех фаз. 1- открытие перового вентеля, 2- диагностика системы и 3 фаза - открытие второго вентиля. Таким образом при нормальной работе без сбоев оба вентиля откроются, и функция выполнена правильно. При сбое, PC шагнул на команды открытия первого вентиля не регламентировано, например. То первый вентель откроется, но на этапе диагностики сбой будет обнаружен и второй вентиль не откроется. А у системы будет внутренний сигнал ошибки. Обычно в этом случае самолет уже сажают на ближайший. Если в результате сбоя шагнули на открытие второго вентиля, и открыли его - то первый вентиль закрыт, опять таки аварии не устроим.
Так вот локстеп позволяет сократить время диагностики до единиц тактов, вместо более сложный процедур самодиагностики
и подтверждения на более высоком уровне. Кроме того самодиагностика позволяет обнаружить отказы, а сбои она не показывает. А интенсивность сбоев примерно в 1000 раз больше чем интенсивность отказов на земле.

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

На схеме их инвертора выход ошибки идет сразу на сброс и никаких там самодиагностик.
Самодиагностика там отдельная тема.

Lock-step, ИМХО, не мера повышения надежности, а средство идентификации места возникновения ошибки (CPU или шина например ).
Благодаря этому в частности TI могут определить уровень SIL системы куда входит контроллер и прикинуть риски.

Там весь разговор крутится вокруг оценки рисков. А цифры по надежности у них в закрытых доках.
Мелким разработчикам вся эта тема вообще до фонаря.

А сценарий с вентилем мне кажется надуманным.

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

"Есть работы где обычная схемотехника защищается ECC" - перл!

http://www.cs.york.ac.uk/rts/docs/DAC-1964...FILES/P0705.PDF

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

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

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