Вопросы по надежности, Регистрация ошибок Опции

[alxkon]

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

Столкнулся с такой задачей - плата на 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. Как максимально надежно и параноидально оформить решение что бы наверняка защелкнуть сигналы ошибок + прочитать и сбросить их после? Теоретически и клок может сбоить

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

Сообщение отредактировал antsu88 - Jun 25 2015, 12:33

[EvgenyNik]

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

[alxkon]

А если так: модуль общения по 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.

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