Средства и методы разработки

+1. Т.е. если мы делаем ядро для контроллера, у которого из периферии только небыстрые UART, I2C и SPI, то "обычный микроконтроллер" почти всегда победит. Но стоит только добавить простейший захват видео и сжатие хотя бы JPEG, как все резко меняется. Простой пример. Пусть это будет некий охранный контроллер, который имеет видеокамеру. И его задача - сохранить в памяти видео 30 сек до и 5 минут после некоего события. Аппаратный ускоритель H.264 - это круто, но геморройно. Хоть в FPGA, хоть на кристалле. Это лицензирование, закрытые дрова и проч. В общем, только для толстых пацанов. В варианте иерархически-параллельной обработки, который я описал, берем SD карточку и пишем на нее постоянный поток с камеры либо несжатый, либо JPEG. С глубиной хранения 30 сек. Если подсчитать, то какой-нибудь 16G SD карточки хватит надолго исходя из ресурса хотя бы 1к циклов на сектор. Поток 27Мбайт/сек, как минимум, ощутим для любой SoC. Но в иерархически-параллельном варианте сохранение потока можно сделать с минимальной нагрузкой на систему. Не понадобились 30 сек - ну и хрен с ними, стерли. Понадобились - ок, можно пережимать хоть в H.265 в "нереальном времени" 1:10. Т.е. если кто-то быстро полез в видеоархив - выдаем ему несжатый поток. Если он полез туда через час - мы уже все пережали в H.264 Это довольно тупой пример, он просто призван показать, что идеология FPGA применима только при подходящей методологии разработки. Если FPGA проектировать как "контроллер на LPC1XXX", то толку будет мало. Это как в С++ - если там писать на С, то тогда и компилить надо С компилером.