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

Для примера рассмотрим embedded сервак, который что-то раздает или принимает по FTP на FLASH. Вот у нас контроллер Ethernet принял нечто и выставил прерывание. Процессор лезет в него, смотрит, что к чему, и, например, по DMA отсасывает в память принятый пакет. Далее он лезет в память и начинает разбирать пакет. CRC, заголовки, не дай бог еще индианность не та, как в сети... Ура, разобрал. До этого момента каки-либо интеллектуальных действий не было. Все это может сделать быстрый 8 битник, если у него на шине будут ускорители по CRC и пр. Далее включается машина состояний, которая смотрит, что же нам делать с этими данными (если они были в пакете), или какие изменения в машине вызовут пришедшие управляющие поля. Выясняется, что данные нам надо засунуть во FLASH. Мы передаем блок файловой системе, она долго шуршит своими связными списками, потом упакрывает наш блок в ECC, и загоняет в NAND. Все описанное есть чистой воды маразм, и ибо процессор был загружен перекачкой данных, которые ему _КАК ДАННЫЕ_ не важны, и прочими манипуляциями. Вот и получается, что 1Мбайт/сек перфоманса embedded системы по сети - это очень круто! Как это все стоит делать? Есть управляющий процессор. С внешней шиной и DMA. Есть FPGA на этой шине. К ней подрублен Ethernet контроллер (например, по SPI, для экономии пинов, кои для FPGA самый ценный ресурс), SDRAM, NAND FLASH. SDRAM контроллер оптимизирован под блочную пересылку. Также есть куча простых 8 битных процессоров, например, LatticeMico8 µC http://www.lattice …crocontrollermico8.cfm которые зажигают на все свои 50 MIPS (2 такта на команду) в рамках очень маленьких программ, которые живут прямо в набортных блоках памяти. Главное - у них на шине есть все нужные ускорители для манипуляции данными. Оценка цены: самая простая FPGA LatticeXP2 XP2-5 5k LUT, 9 блоков по 16 кбит. 1 такой блок по идее должен два проца обслужить (PicoBlaze такое точно умеет). LatticeMico8 µC занимает 250-300 LUTов такого камня, т.е. порядка 5%. Цена такой плисины LFXP2-5E-5TN144C по каталогу маузер при 100 шт - $12.3 В переводе на обычный язык означает, что по $10 ее можно найти в сотенном опте. Стоит микропроц на обслуживание Ethernet. Принял он прерывание. Дал команду локальному DMA блоку загрузить пакет в локальную буферную память. Дал команду вычислить IP CRC (это можно было сделать при загрузке). Сравнил. Принял решение, если надо - изменил счетчики статистики. Далее начал разбирать пакет и превращать его в структуру, удобную для большого процессора. И отдельно выделил область данных. Дал команду локальному DMA перекачать все это в SDRAM, причем область данных - отдельно, в специальную часть. Выставил прерывание большому процессору. Тот считал регистр на шине - ага, у нас пакет пришел. Дал команду DMA перекачать в память десрипторную часть пакета, без самих данных. Но все дексрипторы, как и сами данные, остались в SDRAM. На готовую струру в памяти большого проца резво набросилась state машина. Быстро приняла решение - например, этот блок данных надо на FLASH. Передала указатель на дескриптор файловой системе. Та посмотрела состояние своих буферов, прошлась по таблицам, и решила - этот пакет в такой-то сектор. Передала управляющую команду мелкому процессору NAND. Управляющая команда - это список дексрипторов блов данных, с указателями в каждом из них (вдруг первый блок читаем не с начала, а последний не до конца; может у нас извращенцы MTU 300 в сети поставили). Мелкий процессор скучковал данные при помощи DMA из SDRAM в локальную память, отECCшил этот блок, перегнал в NAND, как опция - считал обратно, проверил количество ошибок, и выставил флаг - типа команда обработана. Можно уменьшить количество промежуточных кучкований данных, сразу из SDRAM отсылая данные по FLASH. Файловая система помечает десрипторы блоков данных как свободные, и смотрит входной буфер - а что у нас там пришло нового? Все это время, пока мелкие процессоры гоняют данные внутри FPGA, большой процессор занят делом - тщательно принимает решения в области обработки IP пакетов, всякие там разрешения и пр. Причем на это у него много времени, его шины не загружены трафиком. Программу можно писать в автоматном стиле, и при использовани адекватного генератора, пусть даже результирующий код не шибко эффективен, например, каждый узел графа стейт машины - это функция, все это будет разрабатываться и отлаживатья очень быстро. Граф алгоритма перед глазами, сравнить его в RFC - вот и это и будет задача для мозгов программиста, равно как и придумывание изящных алгоритмов. При таком подходе ATxmega даст 10 мбайт/сек сетевого перфоманса, хотя использование ATxmega в данном случае едва ли оправдано. AVR32 куда более правильный выбор :) Теперь касаемо микроконтроллерных фишек. Кайф LatticeXP2 во встроенной загрузочной флеши. Тут даже не так важна защита (что всегда полезно). Тут важно, что из состояние выключено до состояния полной готовности такой плисины проходит несколько мс. Т.е. описанная выше конструкция не противоречит питанию от батарей. По надежности тоже все ок. LatticeXP2 имеет встроенный механизм самотестирования загруженной конфигурации. SDRAM довольно надежная штука, особенно, когда она разведена короткими проводками pin-pin. Ну ECC к SDRAM можно для паранои прикрутить - типа использовать 16 битную, а в системе она будет как 8 битная. Примитивный Хемминг какой. SDRAM дешев. Посему можно не заморачиваться тонким управлением памятью. Фиксированные буфера, их много - вот и весь рецепт успеха. Аналогично, если к USB контроллеру прикрутить такую же шнягу - то и HS USB заработает по полной. Перегибы крайне опасны. Засунуть большой процессор (вредная мечта всех изготовителй FPGA) в плис, заодно и Ethernet контроллер - и к цене FPGA нужно будет пририсовать нолик :)