Прочитал XAPP290. Не помогло. Основной вопрос такой:

Как ведет себя ПЛИС, если мы делаем ActiveReconfig, то есть в процессе частичной реконфигурации ПЛИС работает?

Допустим, я решил изменить содержимое таблицы перекодировки (не спрашивайте, зачем надо - это раздумья по вариантам проведения НИР ). Схема работает, через данную ТП проходит сигнал. Я ее меняю.
Как синхронизировать с работой схемы факт изменения ТП, чтобы я мог затормозить часть схемы, например, сняв ena с триггеров?
Что будет на выходе ТП в процессе реконфигурации и сколько это продлится?

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

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

Спасибо!

Не подскажете или не ткнете в документацию - как понять, какого объема блок будет переконфигурироваться в таком режиме, если я в FPGA Editor поменяю что-то, например, значения всего в одном LUT?

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

Да, получается, что скорее всего так. Спасибо за информацию.

Отдельные LUT-ы можно переконфигурировать, если использовать их в режиме сдвигового регистра.

Но насколько я понял, обратно их LUTом, реализующим комбинаторную функцию в чистом виде не сделаешь?
Собственно, это нужно по НИР для эмуляции SEU, MEU и прочих ошибок, включая эмуляцию повреждения части схемы относительно незаметным для основной прошивки образом и без вмешательства в исходные коды.

Без вмешательства не выйдет - partial reconfiguration блок надо выделить в отдельный модуль.

Но в XAPP290 расписано, что изменения при difference-based делаются на уровне нетлиста в FPGA Editor напрямую с LUT, блочной памятью или элементами ввод-вывода, и из этого делается частичная прошивка только с указанными изменениями.

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

А описание разностной, кроме как в XAPP290, я нигде толком не нашел. Например, в документации на Virtex5 написано, что переконфигурировать можно на уровне одного конфигурационного блока, а за какой объем ресурсов он отвечает, сколько времени это займет, как грамотно уведомить свою схему об этом процессе - не написано.

Глупости. LUT-это память, входы - адрес чтения. Если "при взгляде сверху" LUT является логической функцией f(Ix), то "при взгляде сбоку" эти входы (Ax) определяют глубину сдвигового регистра. Результат один, разница в способе заполнения памяти.
Ставите компонент SRLC32E/SRLC16 вместо своих LUT-ов, заполняете его исходными значениями вынутыми из LUT-ов синтезированной схемы или из головы. Выход Q31/Q15 и вход D используете для каскадирования, если реконфигурируемых LUT-ов много. Входы A являются аргументами логической функции, выход Q ее значением. Все, схема как была, но теперь ее можно курочить продвигая биты через LUT-ы. Неплохо бы проследить за тем, чтобы цепочки LUT-ов выстраивались в соответствии с размещением, тогда каскадирование сдвиговых регистров использует специально для этого предназначенные провода.
Если схема получается в результате синтеза сложного для понимания текста, ну, чего-то сложнее сумматоров, то будет непросто, так как сначала придется синтезировать эту схему, и, что существенно, разместить, а потом, в соответствии с размещением ихсодной схемы построить новую. Хотя, если не париться экономным использованием проводов, то можно и как попало соединять. Но все равно netlist придется анализировать.