Всем добрый день.

Возник такой вопрос.
Можно ли в принципе считать из FPGA конфигурационный код (bitstream) в процессе работы устройства? Именно в процессе работы, не останавливая функционирование устройства.

Спасибо за ответы.

У Xilinx можно остановить FPGA, считать и запустить FPGA работать дальше (насколько мне подсказывает мой склероз). Называлась фича - Read Back.
Но смотрел я на это довольно давно, как сейчас у 7й серии - не знаю

Наверное, можно прочитать что-то через Selectmap.

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

В целях борьбы с SEU (одиночными событиями), а точнее для их выявления, Xilinx как минимум 7 серии (не уверен насчет Virtex-6, но вроде тоже) поддерживает чтение конфигурации на лету (без остановки устройства) и сравнение вычитанного по маскированному битстриму (маска закрывает пользовательские регистры и прочие подобные вещи).
Так что физически это возможно (в тех чипах, которые поддерживают такое вычитывание). Что дальше делать со считанными данными - совершенно отдельный вопрос.

Интересно, а есть подробности? Кто-то пробовал? Что такое SEU?

SEU

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

Делал очень давно на Vitrex 4, система рабочая) Readback делается с помощью ICAP, считанные данные прогоняются через файл маски, который генерирует сапр, затем считаем CRC и сравниваем с оригинальным. Чип при этом останавливать не надо

Спасибо за ответы.

Я всегда считал (поправьте, если это не так), что конфигурационная память в FPGA устроена вроде длинного сдвигового регистра, в который вдвигается битрстрим.
Если это так, то как физически возможно прочитать битстрим из этого регистра не останавливая устройство?

Приветствую
Если в первом приближении то сдвиговый регистр и конфигурационная память это две разные сущности - поэтому сначала копируется состояние конф. памяти в регистр а потом уж сдвигается наружу - ну а сама конфигурация при этом не меняется.
Удачи! Rob.

У Xilinx есть хорошее описание явления и готовое IP core на эту тему:
https://www.xilinx.com/support/quality/sing...ent-upsets.html

Кстати, считается, что контроль SEU нужен не только в околорадиационных отраслях, но и для любых высоконадежных применений, в которых ПЛИСы работают 24/7/365 без переконфигурации.

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

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

А смысл этого? - важно знать не поломалось ли что уже после загрузки прошивки в FPGA. Чтобы если что не так включать красный алярм и перегружать оную.

А целостность того что грузится проверяется при загрузке автоматом.

Удачи! Rob.

Можете привести ссылки, почему так считается? То есть я так понимаю, что при применении SEM мы улучшаем MTBF за счет того, что появляющиеся ошибки в конфигурации сами собой корректируются? А на сколько часто они могут вообще возникать, если не брать во внимание радиацию?

Защита от злоумышленника, который захочет путем подмены прошивки провести свои манипуляции с вашей системой.

Ссылок на нормативы у меня нет, но можно посмотреть на документацию к телекомовским (google: cisco seu) или датацентровским железкам (Fusion-io KB777). Судя по их информации - такие ошибки крайне редки, но все-таки случаются.
Тут еще важно, что SEM-контроль производителя ПЛИС отвечает только за статическую часть конфигурации. Контроль четности в пользовательских регистрах, RAMах и прочем - головная боль авторов прошивки. Fusion-io, например, при детектировании даже исправленного SEU советуют перезагружать сервер по питанию при первой возможности - просто кабы чего не вышло. Также по их же информации, SEU-контроллер позволяет ловить возможную неисправность железа, когда конфигурация ПЛИС начинает сыпаться по каким-то не самым космическим причинам.

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

Для этого есть криптование битстрима и расшифровка оного при загрузке по ключу внутри FPGA.

Удачи! Rob.

Всем добрый день.

Возвращаясь к первоначальному вопросу темы.
Меня интересует, как устроена конфигурационная память FPGA. Толком никаких подробностей найти не получается (по крайней мере, в документации Altera).

Простой вопрос. Вот, например, 4-входовой LUT конфигурируется 16-разрядным двоичным словом на выполнение конкретной функции.
Где хранится это слово? Реально в структуре FPGA существует 16-разрядный регистр, хранящий эти 16 разрядов и закрепленный за конкретным LUT-ом? Этот регистр, это часть конфигурационной памяти? Или этот регистр отделен от конфиг. памяти, и значения копируются в него в процессе конфигурирования из конфиг. памяти?

Спасибо за ответы?

Насколько разобрался, есть SRAM ячейка, от которой сигнал идет к проходному транзистору (pass transistor), который работает ключом.
Как устроена SRAM ячейка — информации достаточно много вплоть до транзисторного уровня.
Поищите по запросу: fpga interconnect transistor level

Да
Да
Нет

Спасибо за ответы.
Хорошо, регистр, настраивающий LUT, является частью конфигурационной памяти.
А как, собственно, организована конфигурационная память? По адресному принципу или она представляет собой сдвиговый регистр?

По адресному. У Xilinx был аппнот с описанием процесса конфигурации.

Посмотрите сюда:
https://www.xilinx.com/support/documentatio...ack-capture.pdf
https://www.xilinx.com/support/documentatio...nfiguration.pdf (глава 9)
https://www.xilinx.com/support/documentatio...ries_Config.pdf (глава 5)