Залил свою архивную подборочку материалов по
реконфигурируемым машинам.

reconfig.rar

Пообсуждаем?

А что тут обсуждать ? У этой темы сейчас есть только одно применение - аппаратные акселераторы разного софта. Причем каждая контора делает свое и закрытое - отсюда вывод : пока не появятся открытые стандарты (библиотеки, API и т.д.) это все будет красивой и дорогой игрушкой для избранных.

T.e. Ты считаешь. что это абсолютно бесперспективно.
Понятно. Что же, жди пока тебе принесут его на блюдечке.
Без обид. Мне просто не нравится что большинство российских
разработчиков ждет манны небесной и идет вслед за китайцами в плане исследований.

Неужели это даже не инетересно с точки зрения принципов?
Или сдесь уже все точки расставлены?

Я отнюдь не считаю что это бесперспективно. Наоборот, за этим будущее вообще всех вычислений. Просто существующая база (читай FPGA) не позволяет сделать эту технологию распространенной и дешевой.
Максимум что ты можешь сейчас сделать - профилировать свою программу и выделить из нее особо емкие (в смысле времении и объема) куски кода, которые можно будет реализовать аппаратно (в том числе и программно многократно перезагружая при этом аппаратный ускоритель - реконфигурируя). Т.е. изначально ограниченное хотя и очень интересное решение. А вот если бы было стандартное (в определенном смысле) железо и умный компилятор для него (точнее компилятор совмещенный с синтезатором) то ...
Я не жду блюдечка, и мне тоже не особо приятно следовать за нашими желтыми братьями , но мне не хватит образования сделать что-то в этой области самому, к сожалению
А тема эта очень интересна и я думаю она будет очень быстро развиваться в ближайшем будущем.

Я бы не говорил что все будущее за этим.
И существующая база FPGA уже может быть применена для этих задач.
И я бы сказал что уже давно ее применяют! Почитайте материалы.

Эта технология не призвана затыкать дырки в существующих вычислительных архитектурах.

Реконфигурируемая архитектура вычислительного процесса, или реконфигурируемая вычислительная модель это нечто иное. Это иной подход к архитектрному проектированию вычислительных систем, который отличен от традиционного.

Все зависит от применения, если спец вычислитель (портативный тугодум), то самое оно, правда тогда надо и еще прогу которая будет прошивки для спец применения генерить под конкретный процесс...

Ну или перестраиваемые и саморезервируемые системы,но конструктора съедят тогда, - обеспечить коммутацию всех каналов управления...
хотя вроде америкосы в F-22 чего-то такое замутили... хз

всё это фантастика из металлопластика, настоящие ковбои делают вот так : http://www.tensilica.com/products/xtensa_LX.htm
архитектура Xtensa

Ну а мне подобные изыскания очень даже по душе, одно время даже был полон решимости уйти с работы и снова податься в аспирантуру
Не получилось статейку апликейшен со Spartan3 прикрепить, потом залью на FTP.

ага - я вот примерно этой вопроснёй сейчас и занимаюсь и почти что в аспирантуре

2 CaPpuCcino
А какие-нибудь результаты уже имеете?
На какой ОС экспериментируете?

чтоб не вводить вас в заблуждениеб скажу чем именно я занимаюсь - я вижу 2 варианта развития событий - это динамическое реконфигурирование и статическая адаптация - вы как я понимаю были заинтригованы первым вариантом - я когда-то по совету духовного наставника господина aosp тоже направился по направлению динамического реконфигурирования - однако в ближайшее время похоже в эту сторону разработки двигаться будут вряд ли из-за отсутствия технической базы (и даже с учётом того что технология движется - соотношение быстродействия памяти конфигураций и памяти данных/команд останется неприемлимым или реализация динамической реконфигурации будет слишком дорога, может стоит подождать магнитных а не электрических машин ) поэтому я сейчас занимаюсь статически адаптируемыми процессорами для встроенных систем - идея в общем-то та же -- автоматическая адаптация функциональных блоков под алгоритм, но философия другая - встроенные системы имеют ограниченный список исполняемых приложений за жизненный цикл - значит можно вытащить процесс адаптации на этап компиляции - а вот результатов показать не могу - пока особо нечего
p.s. пожалуйста не забудьте cкинуть статью - интересно почитать

Куды-то залито ?

на фтп в паблике

На самом деле грань между "статаической адаптицией" и динамической реконфигурацией очень такая зыбкая... Все дело всего лишь в точке зрения.
С одной стороны – RECONFIGRABLE FABRIC - это ПЛИС с перестраиваемой структурой, с другой стороны АЛУ процессора это тоже своего рода RECONFIGRABLE FABRIC, которая на вход принимает конфигурационные данные в качестве операндов. Понятна идея?
Все это очень умозрительные дефиниции, особенно при определении слов
КОМАДЫ, ДАННЫЕ применительно к какому либо функциональному преобразователю.

Я это все к чему... пусть ув. Сергей детально опишет идею своей СТАТИЧЕСКОЙ адаптации, введя свои определения в предмет исследований.

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

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

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

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

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

Всё украдено `до` нас
Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

но на мой скромный взгляд параллельные вычисления - это из другой оперы, нежели 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, договорятся и выпустят ПЛИСы, поддерживающие эту стандартизацию.
Вот, уже есть сдвиги, что стандартизируют фиксированную и плавающую запятую,
которые станут синтезируемыми в полный рост.

Xilinx разработала Jbits для этого, а вот Altera что-то никак не подтянется