На мой взгляд это очень перспективная тема. Я сам думаю в эту сторону, НО, мне кажется существующие микросхемы слабо подходят для этих целей, а если и удастся их использовать, то выигрыш будет не высок из-за (наверное) не быстрого переконфигурирования участков fpga. Другое дело разработать свою "fpga" специально ориентированную в эту сторону. Такой процессор наверняка мог бы конкурировать с традиционными CPU. Я думаю на меньших частотах можно было бы выполнять больше задач.

Однако возникает вопрос с чего начинать разработку. Мое мнение (после долгих размышлений) - не с процессора, а с компилятора.
Что бы проект ожил и не умер нужно на процессоре запускать ОС и приложения. Отсюда следует, что видимо нужен компилятор С для последующей компиляции Linux. Возможно имеет смысл взять за основу какой-нибудь открытый проект процессора (чтобы Linux уже на нем работал) и пытаться модифицировать/расширять его систему команд (и компилятор С) так, чтобы появилась возможность конфигурировать части процессора.

Возможно С не самый лучший язык, но это пока единственный способ получить какую-то ОС, так что без него не обойтись

На самом деле если использовать Plan Ahead - там всё достаточно тривиально, делал пошагово по этому документу:
Xilinx Partial Reconfiguration

В ПЛИС есть возможность изменять содержимое памяти, прямо редактируя битстрим.
Редактировать можно своим скриптом.
Если эту память организовать как мультиплексор, то вот и перестройка структуры.
Для исследований годится, а для практики - бред.
Может, 7-е или 8-е поколения ПЛИС будут реализованы как группы островков независимых ПЛИС,
(к этому все идет)
тогда каждый осторовок можно будет прошивать независимо.
А пока - реальное динамическое частичное перепрограммирование - бесполезно.

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

Вы имеете ввиду ситуацию, когда на одно место претендуют сразу несколько блоков? Этой проблемой будет заниматься планировщик. Как именно - пока ещё не знаю.


Я думаю, что тут без эксперимента не обойтись, потому как я не могу даже и прикинуть в чём может случиться выигрыш и будет ли он. В принципе, если верить документации на ПЛИСины - скорость реконфигурирования достигает 66 Мбит/c, если поделить эту величину на 2 (как советовал Shtirlits) получается не такая и удручающая ситуация.


Возможно, стоит взять старый добрый MIPS32. Под него всякого добра навалом (и компиляторы и ОСи). Только не совсем представляю область где может понадобиться динамическая реконфигурация того же MIPSа. Разве что какие-то специализированные задачи. Честно говоря, пока не наткнулся на какие-либо серьёзные исследования перспектив развития динамической реконфигурации, где бы были конкретные примеры - сделали такой-то проект, получили такие-то цифры. Большинство ограничиваются поверхностными оценками или разрабатывают инфраструктуру для обеспечения динамической реконфигурации (например, проект ReCoBus). Поэтому, на мой взгляд, любые проекты (к сожалению, пока только академические) в этой области - уже полезны.


Если не затруднит - разверните свою мысль подробнее.

Речь о том, чтобы варианты конфигурации делать без штатных Place&Route.

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

Что-то выиграть у процессоров общего назначения легче на самых больших FPGA, а у них конфигурационная память большая.

Может для науки лучше сделать "коня в вакууме"?
Игнорировать время конфигурирования, не тратить время на тонкости конкретной архитектуры.
Сделать сколько хочется вариантов схемы, которая будет крутиться только в симуляторе.
Конечно, для чистоты эксперимента лучше схему все же писать в синтезируемом стиле и проверять части в реальном place&route.
Для всего этого не нужно тратить килобаксы на кит с топовой микросхемой или мучаться с младшей моделью, которая непонятно вообще чем лучше какого-то микроконтроллера по производительности.

Т.е. реализовывать place&route алгоритм самому в ПЛИС? Это же безумно сложно. Если не прав - растолкуйте, пожалуйста, подробнее.


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


Первоначально - так и будет, затем хотелось бы получить что-то работающее в железе, т.е. прототип. Меня сейчас интересуют детали технологии, чтобы понять насколько реально реализовать задуманное в принципе и на каком железе.

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