Evgeny_CD, Архитектор (15.06.2011 12:47, просмотров: 287) ответил Evgeny_CD на ну а теперь добавим ко всем этому возможность быстрой реконфигурации FPGA - и, как тут уже писали, "здравствуй, skynet". Т.е. при переключении задач в ОСи переключаем и конфигурацию FPGA, и каждая задача живет в оптимальной среде.
Вообще реконфигурируемый сопроцессор – это сильная штука, если так разобраться. Пусть у нас будет набор базовых сущностей сопроцессора:
• Блочная память со всеми нужными интерфейсами (просто память на шине, FIFO и т.д.)
• Распределенная память
• Умножители
• АЛУ
• Способ создания соединений между всем этим хозяйством
Пусть у нас будет удобный САПР, который позволит из этих блоков создать некий спецвычилитель, и мы тут же получим его описание:
• Сюда пхать данные, отсюда отсасывать
• Латентность такая-то
Пусть у нас будет микропрограммируемый автомат, которые осуществляет пересылки межу разными частями памяти с простым преобразованием данных: свапы всякие, индианность, выравнивание и пр.
Пусть у нас будут симулятор и компилятор, которым можно дать описание обоих блоков, и они тут же научатся их юзать. В иделе у нас должны быть команды для сопроцессоров в потоке команд основного процессора, которые передаются ему, и обрабатываются с известной фиксированной латетностью. Тогда компилер может создать очень совершенный код.
Пусть у нас будет правильно написанная программа:
• Вся обработка данных разбита на модули
• Связи между модулями просты и понятны
• Модули можно независимо менять без изменения текста остальной программы
Запускаем прогу на симуляторе и видим – сколько и какой памяти сожралось, сколько тактов ушло.
Если нас чего-то не устраивает, то делам модель сопроцессора, пишем прогу для автомата-манипулятора памятью, заменяем один из модулей на обертку для нашего сопроцессора, пересобираем проект и смотрим – что изменилось.
Можно также все это отскриптовать,и сделать эдакий «монте-карло»:
• У нас есть несколько вариантов каждого модуля
• Прогоняем все комбинации модулей через сборку-симуляцию, и строим графики метрик. После чего глазками оцениваем графики и находим оптимум.
Фишка в сильном распараллеливании процессов:
• Проц программирует сопроцессоры и делает свою универсальную часть работы
• Программируемое DMA грамотно шароебится по шинам и раскладывает данные
• Сопроцессор с оптимальной конфигурацией оптимально решает целевую задачу.
При синхронизации латентности всего хозяйства будет очень кошерно.
Лично мне совершенно понятно, как написать такую модульную программу (желающие смотрят старые посты по VMDL), и системных проблем для создания такого САПРа при использовании современных средств разработки типа Python или C# не вижу (скорость современных процов позволяет забить на накладные расходы высокоуровневых штучек – если оно позволяет быстро писать рабочий код – то затраты окупятся).
Вопросы:
• Почему пока так никто не сделал?
• Я увидел будущее? Так уже делают, но еще не выпустили на рынок?
• Критика подхода?