Однородные вычислительные системы

alone · Post by **alone** » 01 Oct 2013 01:26

Технология дошла до последнего витка - 14 нм. Дальше пути "влоб" нет. Предлагаю сосредоточиться на давно забытом направлении - однородных вычислительных системах, которые могут дать и больше скорость, и меньше потребление.

По сути надо выделять задачам не время процессора, а площадь. Сейчас новые ПЛИС могут дать до 2 млн ЛЕ и уже прошиваются по частям (у Altera). Программы надо писать на верилоге.

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

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

Кто-то должен этим заняться. Как я понял, большим фирмам пофиг. С чего начать? Для начала разбираться, как работать с этой перепрошивкой по частям.

Жаль, что из меня плохой железячник. Только идей лопата^Wпалата.

vinxru · Post by **vinxru** » 01 Oct 2013 01:40

C# или Java должны проще переводится на ПЛИС, так как код там гораздо проще. То есть нет неожиданных зависимостей, адресной арифметики и т.п.

И насколько я знаю, ПЛИС давно уже ставят в суперкомпьютеры. Как раз, что бы быстрее считать простые вещи.

alone · Post by **alone** » 01 Oct 2013 02:28

Конверторы даже уже написаны: http://en.wikipedia.org/wiki/C_to_HDL

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

На самом деле: зачем вообще поток команд? Вся схема решения задачи вместе со статическими переменными и массивами (за исключением динамических) должна лежать в самом процессоре. Обращения к внешней памяти и системные вызовы должны проходить через арбитр.

MC68k · Post by **MC68k** » 01 Oct 2013 02:29

у соседей забанили, да? :3

alone · Post by **alone** » 01 Oct 2013 02:40

У соседей другие темы и другие люди.

http://en.wikipedia.org/wiki/High-perfo ... _computing - там один сайт сдох, другой пустой. Интересно узнать наработки...

alone · Post by **alone** » 01 Oct 2013 03:59

Самая дешёвая плисина с частичной реконфигурацией стоит $37.76 - 5CEBA2F23C8N (IC CYCLONE V E FPGA 484FBGA). Реконфигурируемые области можно задавать: http://www.altera.com/devices/fpga/stra ... onfig.html

Shaos · Post by **Shaos** » 01 Oct 2013 15:17

реконфигурируемые области это типа частично подливать прошивки?
у xilinx это тоже появилось недавно
это не интересно т.к. требует конкретного чипа и конкретной версии софта от производителя чипов

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

P.S. См. Open Architecture FPGA

HardWareMan · Post by **HardWareMan** » 01 Oct 2013 19:36

У нас тут кто-то даже делал имитацию сего на дискретах. Помните синхрогенератор для компьютера с дешифратором на основе ОЗУ? Процессор сам мог программировать его. С другой стороны, обычное SRAM-based FPGA + навесной проц (или внутренний, как у некоторых моделей Cyclone V) = дают реконфигурируемую систему. У нас такая в дендекартридже.

b2m · Post by **b2m** » 01 Oct 2013 22:43

HardWareMan wrote:обычное SRAM-based FPGA + навесной проц

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

Shaos wrote:на FPGA ведь есть распределённое ОЗУ

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

Shaos · Post by **Shaos** » 01 Oct 2013 23:00

b2m wrote:
Shaos wrote:на FPGA ведь есть распределённое ОЗУ
В том-то и проблема, что ОЗУ для конфигурирования - это такое-же узкое место, как и процессор. Вся мощь параллельной работы убьётся таким вот узким местом.

ну оно ведь распределённое

т.е. это много маленьких озушек раскиданных по камню...

b2m · Post by **b2m** » 01 Oct 2013 23:08

Тут скорее подошёл бы некий симбиоз ОЗУ и процессора. Т.е. чтобы мы для каждой ячейки могли бы задавать некую функцию, зависящую от байтов/слов по соседству. Сколько ячеек, столько и простейших процессоров.

HardWareMan · Post by **HardWareMan** » 01 Oct 2013 23:47

b2m wrote:
HardWareMan wrote:обычное SRAM-based FPGA + навесной проц
Речь о том, чтобы отказаться от процессора, а программы реализовывать в виде частичной конфигурации FPGA. Нужен стандарт на конфигурирование произвольных частей FPGA, иначе опять будет "кто в лес, кто по дрова".

Навесной процессор имелся в виду именно для конфигурирования FPGA, а не для исполнения задач. Там в теории можно навесить CPLD с единственной функцией: брать конфу из ПЗУ (если старт холодный) или ОЗУ (если старт теплый или реконфиг). Само ОЗУ заполняет задача, которой требуется изменение конфигурации. Разве это сложно реализовать?

b2m · Post by **b2m** » 02 Oct 2013 03:53

Несложно, но хочется чтобы FPGA могла сама себя частично переконфигурировать, т.е. загрузить программу. Можно, конечно, сделать пару десятков FPGA, а одной из них дать возможность конфигурировать другие, так сказать отвести ей роль ядра ОС. Но всё равно, заливать конфу надо будет полностью, одна программа - одна микросхема.

MC68k · Post by **MC68k** » 02 Oct 2013 04:45

а что же топикстартер? а то получается - вбросил и затаился.

Shaos · Post by **Shaos** » 02 Oct 2013 06:38

HardWareMan wrote:
b2m wrote:
HardWareMan wrote:обычное SRAM-based FPGA + навесной проц
Речь о том, чтобы отказаться от процессора, а программы реализовывать в виде частичной конфигурации FPGA. Нужен стандарт на конфигурирование произвольных частей FPGA, иначе опять будет "кто в лес, кто по дрова".
Навесной процессор имелся в виду именно для конфигурирования FPGA, а не для исполнения задач. Там в теории можно навесить CPLD с единственной функцией: брать конфу из ПЗУ (если старт холодный) или ОЗУ (если старт теплый или реконфиг). Само ОЗУ заполняет задача, которой требуется изменение конфигурации. Разве это сложно реализовать?

а зачем заливать через процессор, если FPGA из внешней памяти без всяких процов умеет заливаться?