Вопрос по Difference-Based Partial Reconfiguration Опции

[Sergey'F]

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

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

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

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

[Sergey'F]

Спасибо!

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

[DmitryR]

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

[Sergey'F]

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

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

[Shtirlits]

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

[Sergey'F]

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

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

[Shtirlits]

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

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