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

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

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

Сообщение отредактировал Sergey'F - Oct 9 2009, 16:24

По сигналу реконфигурации снимается 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 придется анализировать.