Доброго времени суток!

С недавних пор заинтересовался сабжевой возможностью, поискал по интернетам и нашёл следующие поддерживающие данную возможность серии FPGA:
Atmel - at40k, at94 (AVR+at40k)
Xilinx - Virtex 4,5,6, Серия XC62XX
Altera - Stratix 5

Собственно, три вопроса/просьбы:
1) Если кто-то владеет информацией - подкорректируйте, пожалуйста, список.
2) Непонятна ситуация с серией XC62XX - выпускается ли она на данный момент? На Xilinx.com в списке продуктов её нет.
3) Кто-нибудь занимался сабжем? На каких чипах? Какие мнения?

Спасибо.

1. Про atmel советую забыть, был злой, написал это: http://uchcom.botik.ru/boris/fpslic/errors/ про fpslic, но система одна и таже.
2. Я слишком молод для xc62
3. Думал, пришел к выводу, что выгоды нет. А если есть, то пользоватья штатными средствами не интересно, лучше разрабатывать свою прошивку, у которой что-то реконфигурируется. Например, у xilinx LUT может быть сдвиговым регистром и памятью. Если задвигать "конфигурацию", а пользоваться как памятью, то будет польза, как минимум, для приложений типа "подобрать ключ".

А вы с какой целью интересуетесь? Производительность at40k и virtex6 представляете как соотносятся?

2Shtirlits

Интересуюсь в исследовательских целях.
Есть академический проект по созданию процессора, у которого в процессе работы изменялся бы функционал аппаратных вычислительных блоков (короче говоря, динамическое перестроение тракта данных).
Покуда проект учебный, то и финансирование осуществляется из моего кармана и позволить себе дорогие ПЛИСы (даже Virtex4) я не могу.
Что до производительности, то она меня не особо волнует, поскольку цель - понять возможность реализации идеи на бюджетных чипах (создание прототипа).
Я как раз присматривался к FPSLIC (хорошо вписывается в задачу, решение с FPGA на 5k вентилей вполне бюджетное), но описанный вами опыт работы с этой штукой меня озадачил. Возможно, с 2004 года что-то поменялось в лучшую сторону? Более не игрались?

Спасибо.

Мне кажется, что у atmel ничего не поменялось, риск налететь на глюки высокий.
Если бы я был бодр и азартен, то решительно начал выбирать себе soft-processor на altera или xilinx, и может быть не только из nios и microblaze.

Динамическое реконфигурирование придумывалось, как я понял, не для повышения производительности, а для удобства обновления прошивок. Например, если часть схемы реализует интерфейс, через который происходит обновление.
Если предположить, что ваш академический проект по подметанию плаца ломом придуман не чтобы вы замучались, а чтобы плац был чистым, то всё должно где-то упереться в производительность или другую экономическую целесообразность.
Например, сейчас мы смотрим mpeg - нужен аппаратный декодер, потом играем в 3d игрушку - нужно что-то там с координатами делать.
Если все так, то потерпеть секунду на реконфигурирование можно, тем более, что остальное приложение тоже должно загрузиться с диска. Начиная с какой-то частоты реконфигурирования выгоды не будет. Попытки повысить производительность сохранив площадь упираются в медленный канал передачи конфигурационной информации.
А пока грузится прошивка ничего не работает! А если бы работало, то может справилось с задачей и на некоторой универсальной прошивке?
Сама же схема обычно имеет доступ к множеству способов скоротной передачи данных.
Возникает соблазн сделать пере-программируемую логику на программируемой логике.
Такие попытки я видел, но их производительность была удручающе низкой, не только из-за накладных расходов, а скорее по причине излишнего упрощения модели.
Если с самого начала не закрывать глаза на детали, а подробно изучить архитектуру включая ресурсы разводки, то есть надежда сделать что-то толковое или бросить эту затею вовремя.

Спасибо за ценные рекомендации. Действительно, многие вещи стоит обдумать полнее.

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

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

Спасибо.

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

Может быть лучше ставить 2-3 микросхемы и их целиком перезагружать.

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

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

Еще вопрос, а если система не однозадачна, как тогда будет выбираться нужная конфигурация? или принцип "кто первый того и тапки"

Спасибо, смеялся!
Была бы у меня атомная станция, я никакие fpga при существующих средствах разработки близко не использовал.

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

Пока вы смеетесь, ПЛИС уже используют в атомной энергетики
http://www.westinghousenuclear.com/Product...S-RRAS-0090.pdf
http://radiy.com/ru/modules/sections/index...le&artid=31

Это оборудование которое реально работает. так что Вы не правы!!!

А еще windows выгодно применять для управления буровыми платформами.
Эти буклеты не имеют отношения к надежности системы и к динамическому реконфигурированию.
Да пара фирм применяет и позиционирует. Но ключевое там цена, а не надежность. Надежность нельзя потрогать, непонятно как продать.

Это два разных, независимых бита:
НАДЕЖНЫЙ - ненадежный
ИСПОЛЬЗУЕТСЯ В АТОМНОЙ ПРОМЫШЛЕННОСТИ - не используется в атомной промышленности

Я Вам еще раз говорю, что ПЛИС применяют в важных для безопасности процессах, и также говорю, что можно, но не обязательно применять частичное реконфигурирование, для таких систем, такой подход может удешевить процесс изменения функционирования, под удешевлением, не только цена, но и уменьшение рисков связанных с реконфигурацией и внесением изменений в продукт. Это как ответ на то, для чего это может пригодиться. А Вы начинаете смешно не смешно.

Да я услышал вас и даже возразил. И нервно хихикаю от ужаса.
Вы не поверите, но есть места, где разрабатывают прошивки в схематике, без симулятора и проект не проверяют анализатором таймингов. Что-то сделали, запустили - вроде работает. Надеюсь, не надо объяснять, почему так делать недопустимо.
От того факта, что так делают не только пионеры на коленке, но и военные с атомщиками лучше не становится. Это не аргумент.

мда я был свидетелем такого явления))) это ужасно. но можете себе представить мое удивление, когда я узнал размер проекта, разработанного таким образом ? Проект портируется в 5 Мегабайт VHDL исходного кода !!!!!! И отлажен без отладчика !!!!! Чем не герои нашего времени ?

Когда я увидел ето ржал как сумасшедший. Сразу вспомнился анекдот: "Лада нанесла новый удар по баварии. При виде новой модели из Тольятти лопнул от смеха директор компании BMW)))".
На том показе меня чуть не съели((

Пробовал на Virtex-4 работает нормально.
Менял функциональность блочка типа АЛУ.
С помощью plan ahead можно сгенерить битстрим для переконфигурирования, он получается маленький, что очень удобно (во флешку влезает целая туча конфигураций).
Вроде реконфигурация с 12 версии ISE нормально поддерживается и соответственно документация есть.

Sujan, расскажите, пожалуйста, более подробно, как что делалось

На мой взгляд это очень перспективная тема. Я сам думаю в эту сторону, НО, мне кажется существующие микросхемы слабо подходят для этих целей, а если и удастся их использовать, то выигрыш будет не высок из-за (наверное) не быстрого переконфигурирования участков 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 имеет смысл только при ясном понимании с чем вы имеете дело и с какой целью.