Здравствуйте!

Столкнулся с такой задачей - плата на Cyclone V GX с NIOS-II и uCOS-2
С главной платой она общается по SPI, имеется также один сигнал для индикации наличия ошибок.
Теоретически возможны ошибки по:SEU, PLL lock
Более вероятны ошибки в софте - есть 3 WDT на Авалоне подключены к НИОСу для 3х важных тасков
Есть также внешний WDT, обновляется счетчиком, который делит системную, тоесть сработает он только после длительного пропадания тактовой.
Кроме разной переферии есть еепром на i2c.

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

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

Пытаюсь понять:
1. Есть ли метод сохранить даные в ФПГА (без переделывания плат) даже после реконфигурации если питание не выключалось? Вроде бы есть 256 бит для ключа шифровки, но есть ли к нему доступ, да и батарейку ставить нельзя. Буду курить аппноты, но пока не понятно...

2.Пришла мысль - если нельзя сохранить даные при реконфигурации, то при простом ресете логики и NIOS можно определить и сохранить ресеты вачдогов и PLL, а SEU - методом исключения.

3. Как максимально надежно и параноидально оформить решение что бы наверняка защелкнуть сигналы ошибок + прочитать и сбросить их после? Теоретически и клок может сбоить

Буду рад любым подсказкам на эту тему.

А если так: модуль общения по SPI делаете внешним для НИОСа, т.е. самописным и, скажем так, аппаратно-независимым от глюков в софт-процессорной части. Там же прикручиваете кольцевой fifo-буфер, куда скидываете через, допустим, порт PIO НИОСа код текущей операции. Важное дополнение - главный должен уметь блокировать запись в этот fifo (проводничок кинуть enable к плисине). Если главный видит флажок ошибки, то блокирует дальнейшую запись в буфер и по SPI выгребает "историю", а уж потом репрограммит плисину.
Но начал бы я с того, что установил бы триггер-защёлку в ПЛИС на сигнал ошибки. Вдруг, у Вас просто гонка нулей-единиц в логике, а Вы заморачиваетесь зря.

Мне кажется, ловить сбои в ПЛИС - гнилая затея. Просто потому, что сбоит в первую очередь SDRAM, а затем логика. Контролировать SDRAM с прошивкой, отвечающей за конфигурацию вентилей ПЛИС вы не можете. Т.е. в случае сбоя может просто поменяться конфигурация ПЛИС, и вы с большой вероятностью этого даже не заметите. Наверняка есть серьезные исследования по этому поводу - надо искать, но как правило выявление SEU/SET делают аппаратно в ASIC, а не в ПЛИС.
Едниственное что приходит в голову - это троировать логику с мажорированием(и детектрованием сбоя). Только в этом случае вы хотябы услышите звон, что что то не так.

Интересная идея - можно вставлять "метки" в определенные функции и выводить их в этот буфер. Это для контроля за исполнением софта на Ниосе


Да, Вы правы о SEU. Задача выяснить причину сбоя.
Тут есть 2 типа ошибок в устройстве, я классифицирую их, не вдаваясь в подробности, на 2 категории:
1. фатальные - SEU и PLL lock. Как следствие лучше переконфигурировать всю FPGA.
2. нефатальные: ошибка в софте Ниоса или внешнего переферийного устройства (например EEPROM) подключенного к FPGA. Ресет Ниоса и уведомление главного модуля.

В случае 1 логика в FPGA будет с большой вероятностью неработоспособной и само FPGA не сможет детально уведомить другой модуль об источнике возникшей ошибке через SPI.
Для этого можно использовать только CRC Error пин для SEU и обычный IO для PLL lock error. Поскольку железо смастерили от балды и после этого задумалисъ как отлавливатъ ошибки, естъ только один сигнал из FPGA к главному модулю. и сейчас он зашарен между CRC Error, PLL lock и вачдогами Ниоса через комбинаторное ИЛИ. Что приемлимо только для для ошибок в НИОСЕ и PLL lock ошибки. Если возникнет CRC error нет никакой гарантии что в следствии ошибки ИЛИ не станет другим элементом и что сигнал ошибки дойдет до главного. Ставить триггер после ИЛИ нет смысла ибо неизвестно как он поведет себя при сбое PLL. Текущее решение в принципе никудышнее.

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

Вариантов с переделкой есть два - отдельные 2 IO пина на CRC Error и PLL lock, без логики между пином и хардверными модулями SEU Detection и PLL. И один зашареный пин для ниосовских вачдогов. Второй - мелкий и дубовый CPLD который будет следить за FPGA и строчить доносы главному модулю по SPI/I2C + interrupt.

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

Понимаю.

Ну смотрите: перезагруз конфигурации в любом случае должен осуществляться внешним вотчдогом, будь это отдельный чип (CPLD или просто вотчдог - бывают такие микросхемы), или вотчдог софтверный - в ЦПУ. Сама ПЛИС себя не перезагрузит. Вотчдог контролирует активность ПЛИС - значит его надо постоянно перезапускать. И если ПЛИС "замрет", перезапуска не будет, и вотдог сработает - перегрузит ПЛИС. Что такое, ПЛИС "замрет": это либо срабтал самопальный детектор внутри, либо настолько побилась конфигурация, что логика вырабатывания импульсов для вотчдога прокисла, либо ПЛИС и вовсе потеряла прошивку - в этом случае ее выводы перешли в тристейт (вроде обычно так делается при отсутствии прошивки).
Итого, вам нужна одна линия, с подтяжкой в лог. уровень "ошибки", а на другом конце линии - вотчдог. И чтобы ПЛИС постоянно его перезапускал.

жесткий колхоз :-) но, както так

Спасибо! Приблизительно такие же идеи, ничего экстра не получить - при реконфигурации любые флаги пропадут.

С небольшой. Подавляющее большинство памяти задействовано под коммутаторы и сбой в них далеко не всегда приводит к отказу схемы.
Далее: ПЛИС сама себя сбросить может, вотчдог внутри тоже есть. Посмотрите на функцию remote update. Может какие регистры внутри этой функции сможете приспособить под хранение флагов.
Еще вариант хранить флаги в SDRAM. Хоть память и ненадежная, но можно задублировать флаги много раз.