привет, Алексей! вообще-то я думаю, что здесь это будет оффтопик, потому что область в которой может использоваться данная технология относительно узкая - встроенные системы. и к вопросам глобального прорыва в вычислительной техникe (как это предполагают реконфигурируемые системы) отношения не имеет.
под статической адаптацией я имею ввиду адаптацию архитектуры процессора (c последовательной интерпритациeй команд) под определёный круг задач (список задач, определённых назначением встроенной системы) - это мы можем себе позволить именно из-за того что система встроенная и на звание универсальной выч. системы (сыстем общ. назначения) не претендует. статическая - потому что настройка архитектуры происxодит на этапе компиляции и методы статического планирования кода служат в этом хорошим подспорьем - статическое планирование мы можем себе позволить по тем же причинам - система встроенная и вместо отдельой заливки - конфигурации ФПГА или откомпилированной программы АRМ/MIPS/8051 (что кому больше по душе) заливаем смесь конфигурации процессора адаптированного под приложение и кода. чем важно еще статическое планирование - так это опять вытекает из требований встроенной системы - уменьшением ресурсов на динамический планировщик и следовательно уменьшением энерго потребления. а цели такого подхода опять же не в прорыве показателей производительности (хотя и на это можно расчитывать) а всего лишь в формализации/автоматизации методов проектирования встроенных систем малой тиражности - т.е. ФПГАшных
что думаешь?

Тут есть нюанс чтобы ответить, какую пользу принесет динамическая реконфигурация, нужно точно определить область ее применения.

Реконфигурация выч. блока в горячем режиме для выполнения операции, микрооперации или для выполнения алгоритма (БПФ или обратное преобразование)
конечно позволяет экономить место, да и разрядность повысить и кол-во блоков запихнуть побольше (хе-хе вам надо 100 adder'ов? в обычном проце?), только я думаю есть нехилая проблема наладить обмен этих блоков данными (за 1 такт), иначе особо эффективность не повысишь. Ну а если обеспечить распаралеливание (многопоточность) вычислений (помните всем блокам своих данных надоть...) и реконфигурацию в зависимости от того что нужно... тогда это имеет смысл и в центральный процессор запихивать, а так реконфигурация для обычных ПК имеет смысл наверно только для GPU поскольку там можно много сложных алгоритмов накрутить для реалистичной графики, а для обычного процессора...
Ну а для спец. применений..., над этим я думал когда с ПЛИС начал работать года 2 назад... Это надежность))) Сбой блока ЧЧЧ?, но проблем, перешить блок ЯЯЯ (резервный) или блок ЕЕЕ (с понижением нагрузки или заменой), для цифровых систем с общей шиной это хорошо, но мне интересно как это решить, если применять для сетей распределения сигналов, если не ставить I/O на каждый блок?
Разве что определять кол-во требуемого резерва через графы в зависимости от требуемой надежности и резервирования, а потом все учитывать...
Ну наговорил, нунаговорил... выложил, что в голову полезло..
А за реконфигурацией наверно будущее_

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

Надо же, можно сказать ``коллега'' Я сейчас, в рамках своего дипломного проекта, занимаюсь схожей проблемой, но приложение несколько иное (параллельные вычисления в ЦОС (пока ориентируюсь только на это)). Планирую заниматься этим дальше в аспирантуре, если возьмут конечно же

Всё украдено `до` нас
 Programmable_Multi_Core_DSP_2007.pdf ( 251.97 килобайт ) Кол-во скачиваний: 775
 Deterministic_Parallel_Processing_2005.pdf ( 425.11 килобайт ) Кол-во скачиваний: 403


но на мой скромный взгляд параллельные вычисления - это из другой оперы, нежели Reconfigurable Computing

Как вариант - динамическое изменение частоты DCM ПЛИС тоже делается с помощью динамической реконфигурации кристалла (в некоторых документах из начальной подборки идет речь именно о такой методике). Применений для этой технологии не только в ЦОС, но и во многих других областях полно, наверное...

увы мне, в теме слаб, а она очень интересна. может кто подскажет новичку (опять новичку ) возможна ли реконфигурация в таком виде: берем текущую прошивку, нужную прошивку, вычисляем diff, и проливаем лишь отличающиеся /адреса ячейки хз чего/? ну и ресет кристалла - и вперед. в свое время технологию откатали, хоть и на другой совсем задаче. Объясню - для моих задач меня вполне устроит время обновления прошивки целого кристалла 1 мс. Целиком за ето время хотя бы миллионник не залить, а вот дифами думаю было бы можно.

Либо по другому: может быть просто есть кристаллы которые можно залить полностью за 1 мс по параллельному интерфейсу ?

Я думаю, автомат, который конфигурирует ПЛИС, устроен как сдвиговый регистр. И никак в середину этого регистра не влезть.

У Xilinx возможно. У него конфигурация заливается блоками (у S3E например, блок - 96 байтов). Минимальная единица заливки - блок
Другой вопрос, что при изменении исходной схемы может поменяться ВСЯ прошивка, и размер diff'ов будет больше, чем новая полная прошивка

м. нарыл отличный констрейн
Range of Locations
The basic UCF syntax is:
INST “instance_name” LOC=location:location {SOFT};

да и даже если б не нарыл. Там есть констрейн закрепить элемент в конкретный слайс. Далее я так понимаю механизм простой: крепим пограничный (граница неизменяемая часть/изменяемая) опорный элемент в опорный фиксированный слайс, и delay-ами тупо притягиваем изменяемую часть в минимальное пространство вокруг опорного слайса. И молимся)))

А кстате где-нибудь можно нарыть структуру файлика прошивки ? Ети блоки их можно расковырять прямо в bit файле, или нужно генерить какой специальный файл ?

У Xilinx'а вообще можно закрепить часть прошивки и перегенерировать только другую часть, но для этого дезайн должен быть устроен специальным образом. (Равно как и с использованием LOC констрейна). Т.ч. если допустимо проектировать дезайн таким образом, то диф. конфигурация может сработать.
Он описан в документации по сонфигурированию каждого конкретного семейства.
Для Virtex6 - Virtex-6 FPGA Configuration User Guide (UG360), Chapter 6: Configuration details.
Для Spartan3/3E - Spartan-3 FPGA Family Advanced Configuration Architecture (XAPP452)
Для SpartanSA - Spartan-3 Generation Configuration User Guide (UG332), Chapter 17: Configuration Details

PS. Еще у меня есть Perl'овый скрипт, который декодирует .bit файлы. Пока поддерживаются S3,S3E и V6

Очевидно, если кристалл заполнен достаточно сильно, а не состоит из блочков "висящих" на некотором расстоянии друг от друга, то добиться малого размера diff файлов не получится не так ли ?

Угу

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