Evgeny_CDАрхитектор (02.04.2012 11:36, просмотров: 637)Зачитал я тут доку по TMS320DM814x, TMS320DM816x и мысль меня посетила. Насчет дримчипа 3.0 http://caxapa.ru/302651.html
В очередной раз убедился, что умом DaVinci не понять :) А что есть сделать так? Пусть есть аццкий SOC 45- нм, в котором есть: * несколько контроллеров памяти DDR* * Аццкий шинный коммутатор L3 128 бит * MMU, прикрученный к шинному коммутатору * специализированные блоки * адаптеры специализированных блоков (ниже) * "просто DSP" * "Просто ARM" Пусть есть блок, который H.264HP. Внутри он аццки сложен, понять его крайне трудно, написать свою прогу почти невозможно. Аминь. Ему надо: * интерфейс ввода * интерфейс вывода * некоторое количество памяти в DDR * некоторое количество полосы пропускания на коммутаторе Адаптер ввода-вывода - это Cortex-M*, который * управляет видеодекодером * добивается того, чтобы данные от декодера были правильно разложены в памяти * даеет системное сообщение спец. блоку - "кадр готов" * вывод - аналогично. Очевидно, что все операции по кодированию/декодированию H.264 сводятся к конфигурироваию некого универсального ядра, а затем кормлению его даными и оттаскивании результата. Причем адептеры ввода-вывода запрограммировать несложно, это даст нужную гибкость в части кастомизации схемы и пр. Решение примерно такое. * спец. блок закрыт, есть только описание интерфейсов его управления и описание требований к системе - сколько памяти, какой приоритет на шине и пр. * у него есть SecretKey, индивидуальный * получаем с сайта производителя за деньги персональную копию ПО спецблока (закриптованную SecretKey) * загружаем ее в память * мапим все нужны ресурсы через MMU коммутатора * программируем сопроцессоры IO * конфигурируем спецвычислитель * запускаем все в работу У нас получается черный ящик, из которого в память валится поток H.264. Далее на "просто ARM" под удобной ОСькой пишем все необходимое, можно "просто DSP" в качестве сопроцессора поиспользовать. Мне кажется, это единственный способ расширить рынок для таких монстровых чипов, и одновременно привнести в широкие массы контроллерщиков настойщий high-tech. Можно идею модифицировать. Как мы знаем, практическим пределом скорости по диф паре на pcb сейчас является 10 Гбит/сек. Или 1 Гбайт/сек, что очень даже достаточно для многого. Делаем host чип * контроллеры памяти * шинный коммутатор с MMU * "просто процессоры и DSP" * контроллеры 10G IO, с прямыми выходами на порты коммутаора Делаем приферийные чипы по вкусу. Удобно делать сборки на одной подложке - периферийный чип + его локальная память. В силу кардинального уменьшения числа IO пинов можно перейти на BGA 1.27мм - и корпуса будут большие (чтобы паковать супер-чипы и сборки), и паять|разводить будет самое то. Теперь смотрим на описание LatticeECP4 -> и понимаем, что народ подумал примерно о том же :) Там на 10G порты стоит аппаратный ускоритель для Serial RapidIO, а этот протокол изначально создан для описываемых задач. Наверное, как-то так в будущем микроконтроллерщики и помирятся с супер-чипами....
В очередной раз убедился, что умом DaVinci не понять :) А что есть сделать так? Пусть есть аццкий SOC 45- нм, в котором есть: * несколько контроллеров памяти DDR* * Аццкий шинный коммутатор L3 128 бит * MMU, прикрученный к шинному коммутатору * специализированные блоки * адаптеры специализированных блоков (ниже) * "просто DSP" * "Просто ARM" Пусть есть блок, который H.264HP. Внутри он аццки сложен, понять его крайне трудно, написать свою прогу почти невозможно. Аминь. Ему надо: * интерфейс ввода * интерфейс вывода * некоторое количество памяти в DDR * некоторое количество полосы пропускания на коммутаторе Адаптер ввода-вывода - это Cortex-M*, который * управляет видеодекодером * добивается того, чтобы данные от декодера были правильно разложены в памяти * даеет системное сообщение спец. блоку - "кадр готов" * вывод - аналогично. Очевидно, что все операции по кодированию/декодированию H.264 сводятся к конфигурироваию некого универсального ядра, а затем кормлению его даными и оттаскивании результата. Причем адептеры ввода-вывода запрограммировать несложно, это даст нужную гибкость в части кастомизации схемы и пр. Решение примерно такое. * спец. блок закрыт, есть только описание интерфейсов его управления и описание требований к системе - сколько памяти, какой приоритет на шине и пр. * у него есть SecretKey, индивидуальный * получаем с сайта производителя за деньги персональную копию ПО спецблока (закриптованную SecretKey) * загружаем ее в память * мапим все нужны ресурсы через MMU коммутатора * программируем сопроцессоры IO * конфигурируем спецвычислитель * запускаем все в работу У нас получается черный ящик, из которого в память валится поток H.264. Далее на "просто ARM" под удобной ОСькой пишем все необходимое, можно "просто DSP" в качестве сопроцессора поиспользовать. Мне кажется, это единственный способ расширить рынок для таких монстровых чипов, и одновременно привнести в широкие массы контроллерщиков настойщий high-tech. Можно идею модифицировать. Как мы знаем, практическим пределом скорости по диф паре на pcb сейчас является 10 Гбит/сек. Или 1 Гбайт/сек, что очень даже достаточно для многого. Делаем host чип * контроллеры памяти * шинный коммутатор с MMU * "просто процессоры и DSP" * контроллеры 10G IO, с прямыми выходами на порты коммутаора Делаем приферийные чипы по вкусу. Удобно делать сборки на одной подложке - периферийный чип + его локальная память. В силу кардинального уменьшения числа IO пинов можно перейти на BGA 1.27мм - и корпуса будут большие (чтобы паковать супер-чипы и сборки), и паять|разводить будет самое то. Теперь смотрим на описание LatticeECP4 -> и понимаем, что народ подумал примерно о том же :) Там на 10G порты стоит аппаратный ускоритель для Serial RapidIO, а этот протокол изначально создан для описываемых задач. Наверное, как-то так в будущем микроконтроллерщики и помирятся с супер-чипами....