[nckkm 0]

2Shtirlits

 

Интересуюсь в исследовательских целях.

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

 

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

 

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

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

 

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

[Sujan 0]

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

 

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

Xilinx Partial Reconfiguration

[aser 0]

В ПЛИС есть возможность изменять содержимое памяти, прямо редактируя битстрим.

Редактировать можно своим скриптом.

Если эту память организовать как мультиплексор, то вот и перестройка структуры.

Для исследований годится, а для практики - бред.

Может, 7-е или 8-е поколения ПЛИС будут реализованы как группы островков независимых ПЛИС,

(к этому все идет)

тогда каждый осторовок можно будет прошивать независимо.

А пока - реальное динамическое частичное перепрограммирование - бесполезно.

 

[MIX@ 0]

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

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

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

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

 

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

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

 

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

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

 

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

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

 

В ПЛИС есть возможность изменять содержимое памяти, прямо редактируя битстрим.

Редактировать можно своим скриптом.

Если эту память организовать как мультиплексор, то вот и перестройка структуры.

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

[Shtirlits 0]

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

 

Скорость конфигурирования оценивается в зависимости от нужд.

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

 

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

 

Может для науки лучше сделать "коня в вакууме"?

Игнорировать время конфигурирования, не тратить время на тонкости конкретной архитектуры.

Сделать сколько хочется вариантов схемы, которая будет крутиться только в симуляторе.

Конечно, для чистоты эксперимента лучше схему все же писать в синтезируемом стиле и проверять части в реальном place&route.

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

 

[MIX@ 0]

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

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

 

Скорость конфигурирования оценивается в зависимости от нужд.

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

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

 

Может для науки лучше сделать "коня в вакууме"?

Игнорировать время конфигурирования, не тратить время на тонкости конкретной архитектуры.

Сделать сколько хочется вариантов схемы, которая будет крутиться только в симуляторе.

Конечно, для чистоты эксперимента лучше схему все же писать в синтезируемом стиле и проверять части в реальном place&route.

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

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

[Shtirlits 0]

Дело в том, что в этой штуке заранее нельзя сказать ни размер реконфигурируемого блока ни частоту реконфигурации.

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

FPGA имеет смысл только при ясном понимании с чем вы имеете дело и с какой целью.