[CaPpuCcino 0]

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

<{POST_SNAPBACK}>

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

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

что думаешь? :)

[tegumay 4]

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

 

Реконфигурация выч. блока в горячем режиме для выполнения операции, микрооперации или для выполнения алгоритма (БПФ или обратное преобразование)

конечно позволяет экономить место, да и разрядность повысить и кол-во блоков запихнуть побольше (хе-хе вам надо 100 adder'ов? в обычном проце?), только я думаю есть нехилая проблема наладить обмен этих блоков данными (за 1 такт), иначе особо эффективность не повысишь. Ну а если обеспечить распаралеливание (многопоточность) вычислений (помните всем блокам своих данных надоть...) и реконфигурацию в зависимости от того что нужно... тогда это имеет смысл и в центральный процессор запихивать, а так реконфигурация для обычных ПК имеет смысл наверно только для GPU поскольку там можно много сложных алгоритмов накрутить для реалистичной графики, а для обычного процессора...

Ну а для спец. применений..., над этим я думал когда с ПЛИС начал работать года 2 назад... Это надежность))) Сбой блока ЧЧЧ?, но проблем, перешить блок ЯЯЯ (резервный) или блок ЕЕЕ (с понижением нагрузки или заменой), для цифровых систем с общей шиной это хорошо, но мне интересно как это решить, если применять для сетей распределения сигналов, если не ставить I/O на каждый блок?

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

Ну наговорил, нунаговорил... выложил, что в голову полезло..

А за реконфигурацией наверно будущее_

[tegumay 4]

Это немного офтоп, но к идее -

В одной книге по фантастике весь народ покупал на рынке металлоболванку,

а потом деньги платили за улучшение функциональности и допрошивку, хочешь интеллектуальный холодильник или печку с мегаразогревом?

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

[sebl 0]

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

 

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

[ClockworkOrange 0]

приложение несколько иное (параллельные вычисления в ЦОС (пока ориентируюсь только на это)).

Всё украдено `до` нас

Programmable_Multi_Core_DSP_2007.pdf Deterministic_Parallel_Processing_2005.pdf

 

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

[dadya_vovan 0]

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

 

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

[a123-flex 0]

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

 

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

[ViKo 1]

Целиком за ето время хотя бы миллионник не залить, а вот дифами думаю было бы можно.

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

[xvr 12]

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

У Xilinx возможно. У него конфигурация заливается блоками (у S3E например, блок - 96 байтов). Минимальная единица заливки - блок

Другой вопрос, что при изменении исходной схемы может поменяться ВСЯ прошивка, и размер diff'ов будет больше, чем новая полная прошивка :(

 

[a123-flex 0]

У Xilinx возможно. У него конфигурация заливается блоками (у S3E например, блок - 96 байтов). Минимальная единица заливки - блок

Другой вопрос, что при изменении исходной схемы может поменяться ВСЯ прошивка, и размер diff'ов будет больше, чем новая полная прошивка :(

 

м. нарыл отличный констрейн

Range of Locations

The basic UCF syntax is:

INST “instance_name” LOC=location:location {SOFT};

 

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

 

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

[xvr 12]

м. нарыл отличный констрейн

У 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

 

[a123-flex 0]

У 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 файлов не получится не так ли ?

[xvr 12]

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

Угу :unsure:

 

[a123-flex 0]

Угу :unsure:

 

[aser 0]

Если закон Мура будут двигать и дальше,

то в рамках закона выживут универсальные мультиропроцессоры, память и ПЛИС.

Так что тема ветки - неизбежная.

Сейчас ведутся работы по стандартизации интерфейсов виртуальных модулей и

общей шины для них.

Когда эти интерфейсы устаканятся, тогда можно будет говорить о реконфигурируемых вычислениях на всех углах.

Возможно, Xilinx, Altera, договорятся и выпустят ПЛИСы, поддерживающие эту стандартизацию.

Вот, уже есть сдвиги, что стандартизируют фиксированную и плавающую запятую,

которые станут синтезируемыми в полный рост.