alexdsp
-
Постов
82 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные alexdsp
-
-
Никаких проблем! У меня вот доска для ATF697F (жаль, что не для FF :) ) на столе лежит.
Кстати, в 20-х числах тренинг по оным планируется.
Подробности можно в личке обсудить.
Интересно. Цены примерные на ATF697FF подсказать можете? Ну и на ATF697F тоже за компанию было бы неплохо узнать.
-
Да, девайс интересный... спасибо. Единственно, закрадываются подозрения, что реально начать с ним работать будет очень проблематично.не спасет отца российской демократии?Особенно ATF697FF?
-
Но когда появятся радстойкие версии SmartFusion2 (в следующем году) и Igloo2 Xilinx придется потесниться.
Хотелось бы спросить насчёт SmartFusion2. Что там будет с внутренним хард-ядром ARM? Оно тоже будет аппаратно затроировано на уровне триггеров , как и остальная логика?
Просто очень нужно SEU защищённое процессорное ядро живучее с TID 100 крад или лучше. Можно ли уже отлаживаться на SmartFusion2 или Igloo2 с последующей миграцией на радхард версию? Опять, же... если она ещё будет эта версия... и когда.
Сейчас встаёт проблема выбора. Видел отчёты реальных людей с тестами, где RTPA3 уже от 20 крад физически дохнут. Накрывается charge-pump цепи, да так, что уже невозможно ни стереть, ни пепепрошить. RTPA3 отпадает. ProASICplus устарел, да и мало подходит для проекта. По SmartFusion2 и Igloo2 радиационных данных пока не нашёл. Меня склоняют к индустриальному Virtex-у, и аргументов против у меня уже не хватает. В идеале, если бы индастриал Igloo2 переносили хотя бы 100 крад дозы, имело бы смысл поднапрячься с софт-троированием стороннего софт-ядра и т.д...
-
На тему набрёл поиском. Хочу попробовать Quectel L20, а как-то с документацией в сети оказалось негусто. Насколько я понял, там есть OpenCPU, хотелось бы с SDK тоже разобраться досконально.
Подскажите пожалуйста, где находится нормальная документация и всё остальное?
Сайт Quectel как-то подозрительно пуст...
-
LVDS-сигнал должен был выходить с пинов LVDS97n, LVDS97p,
а после разводки получилось LVDS97n, LVDS96p.
Очень просто, дело в том, что в циклоне выходы LVDS имеют "неправильный" уровень и должны корректироваться резисторами, это в соотв. аппнотах написано, надеюсь они у вас есть, иначе вообще LVDS работать не будет.
В вашем случае, я бы просто назначил на рабочие выходы (LVDS97n, LVDS96p при LVDS) тип LVCMOS, а в самом проекте, рабочий сигнал подал на тот вывод, который в LVDS был прямым, а на второй диф. вывод подал бы инверсию, и всё. Это абсолютно эквивалентно и никак не повлияет ни на что.
Другое дело, если бы вы ошиблись в разводке диф. входа LVDS приёмника, тут бы уже ничего нельзя было исправить.
-
Задача следующая - подобрать подходящий процессор для быстрого выполнения операций над числами, представленными в формате 64-bit floating point (double precision floating point).
Ноги растут из результатов проведенной симуляции перемножения двух операндов на ADSP201 "Тигровая Акула" - аж 58 тактов (64 x 64) versus по-моему 5 тактов (32 x 32). Тут возникло два варианта - поассемблировать критические участки или поискать камни с поддержкой 64-bit. Относительно первого подхода пока сложно что-либо сказать, т.к. программировать лень, да и обязанности мои скорее связаны с построением вычислительной системы под заданный алгоритм, нежели с решением никому непонятной задачи никому непонятным способом (определение программиста :) ). Буду признателен, если кто-нибудь выскажется про целесообразность написания эмуляции врукопашную.
Что касается второго направления, то тут на глаза попался TMS320C67 (надеюсь обозвал правильно). Вообщем новый процессор с поддержкой double-precision floating point. При ближайшем рассмотрении правда оказалось, что есть только возможность перемножить floating-point числа 32 x 64 (а не полноценные 64 x 64). Т.е. быстро перемножить наверное тоже не получится. Ко всему прочему пока нет соответствующего софта (CodeComposer вроде как кличут), способного промоделировать выполнение алгоритма на данном кристалле. Точнее сказать в той версии, что есть у меня, о поддержки этого нового процессора ни слова.
Есть еще RM7000C от PMC-Sierra. Впринципе подходит, но пока напрягают его возможности ввода/вывода (мультиплексированная шина, хоть и 64-разрядная; нет контроллера внешней динамической памяти...)
Может есть еще альтернативные варианты? Any suggestions are welcomed.
А Freescale не рассматривали?
Например MPC5200B. 400MHz, double precision FPU и прочее. Не DSP, но всё же PowerPC, да и энергопотребление вообще скромное.
Я лично с ним дела не имел, но когда-то бегло просмотривал документацию. На мой взгляд очень достойный чип. Интересно ваше мнение.
-
Есть такая штука как резонантный фильтр, подробности по ссылке
http://www.research.scea.com/research/pdfs...rmath_GDC02.pdf
KPAH
Большое спасибо за ссылку. Очень документ порадовал (хотя такой метод генерации синуса я знал и раньше).
0FF/2 А есть ли ещё что-нибудь в этом же духе, т.е. в виде справочника по разным методам, алгоритмам и прочее?
-
DCT это собирательное название алгоримта, во всех ревизиях стандарта mpeg оно разное, мне больше нравиться avc дкт :)
RLE основа на которой живут baseline энкодеры, в avc трансформировалось в CAVLC.
Да и Хаффман не плохо поживает в Theora.
Но вот хилая реализация DCT такое гавно!!!, ощущение что сделано индусом наспех, лиш бы отвезались.
Посмотрел бегло AVC. Впечатление такое, что разработчикам стандарта очень хочется перейти на DWT, но вот начальство не позволяет :))
Этот метод похож на блочный DWT 16х16, но только почему-то там опять DCT :). DWT же ЛУЧШЕ! Правда, только в случае неиспользования RLE. Там всякие "зигзаги" не прокатят. Видимо поэтому этот вариант и не прошёл.
Прежде чем перейти на DWT схемы, я сделал кодек типа JPEG для BF на DCT. Потом "тупо" заменил DCT 8x8 на блочный вэйвлет Хаара 8х8. Так, ради смеха. И о чудо! При равном битовом потоке, визуально картинка стала лучше, не так сильно "рассыпается" на "квадратики". Точнее, эти квадратики имеют не такую ярко выраженную блочность, так как они не все размера 8х8, а встречаются 4х4, 2х2. Из таких кирпичиков изображение и "мостится". Это при сильном квантовании. А при слабом - лослесс он и есть лослесс на вид :) Весь прикол в том, что при вычислении вэйвлета Хаара не происходит ни одного умножения, только сложения и вычитания. Беда только в том, что тут оказывается малоэффективен RLE, другие свойства у преобразования.
Потом я стал экспериментировать с другими вэйвлетами, более устойчивыми к ошибкам квантования, а потом уже придумал полноэкранную схему с низким трафиком. Так вот, на мой взгляд, при прочих равных условиях, у DCT нет ни малейшего шанса составить конкуренцию DWT. При прочих равных. Другое дело, DWT нужно брать конечно же не Хаара, а что-нибудь из высоких порядков Добеши или аналогичных биортогональных. Другое дело, на PC их считать довольно трудно и по времени вычисления они проигрывают схемам с DCT. Может поэтому их и избегают, а может ещё по каким причинам сложно поддающимся анализу... На DSP картина выравнивается. Быстрое DWT намного более регулярный алгоритм, чем быстрое DCT. Для быстрого вычисления DCT существует много разных схем - одна "корявее" другой. По крайней мере, на BF я просто запарился с этой несимметрией. Для вычисления DWT применяется (в реальных устройствах) в основном две схемы - лифтинговая и дерево Молла. В общем - дело вкуса. У каждой из них есть свои преимущества. У лифтинговой - меньше умножений, но некоторая кривизна присутствует. Дерево Молла - для современных DSP очень гармоничная и гибкая схема (IMHO).
Я просто хочу ещё раз сказать, что я имел возможность сравнить обе технологии (DCT vs DWT) при равных условиях. И результат сравнения был сильно не в пользу DCT.
Единственный аргумент "против" - это то о чём вы уже упоминали: "нестандартность". Против этого уже не попрёшь, конечно...
-
Хмм вот тут вы сильно ошибаетесь, есть стандарты, у стандартов есть имя.
Если есть 2 железки на одной вы указываете кодек © солянка сборная моя, на второй © mpeg4.10
(avc) support, то как вы думаете какое решение вы продадите быстрее ?
Да будут люди которые купят у вас и то и другое, но второе решение купят больше, т.к. это стандартный кодек, результат работы которого можно посмотреть любым mpeg4.10 совместимым декодером. А что бы просмотреть ваше решение человек должен купить вашу систему (как минимум ваш декодер).
Тут я вас прекрасно понимаю. Но мы то как раз разрабатываем законченное изделие, а не технологию. Продаваться будет изделие, поэтому мы вправе навязать своё решение потребителю, благо оно не уступает продукции конкурентов. И блэкфин был выбран как раз из-за суммарной дешевизны платформы. Конкуренты, в принципе не могут сжимать 704x576 - 25 fps в многоканальном режиме. У них применяются аппаратные кодеки, рассчитанные на ограниченное количество каналов (1-4), и весьма ограниченный fps и (видимо) плохо поддающиеся масштабированию. Я (скоро) смогу. То есть 20 fps уже есть. Была ревизия алгоритма - будут и 25 fps.
dryadae
У S3E двадцать встроенных умножителей 18x18=36 бит, способных работать на частоте в 300 Мгц. Всё - за 30 баксов, не считая тех АЛУ, которые создаются на генераторах функций...А это - достаточно много. Плюс - возможность конвейеризировать всё это без лишних задержек. Так, по крайней мере, я это себе вижу.Специфика таких дизайнов в FPGA в том, что эти ваши умножители будут очень жёстко привязаны к своей функции внутри блока и будут быстро расходоваться на каждое мало-мальски необходимое умножение, или вы полностью утонете в мультиплексорах и связанных с ними регистрах конвейеров. Плюс ОЧЕНЬ высокая сложность такой реализации. Есть немало проектов видео-сжатия в FPGA , бодро начавшихся несколько лет назад и продолжающихся до сих пор в стадии пре-альфа. И пока вы будете смаковать потенциальную, гипотетическую возможность разработки HDTV кодека на S3E или Stratix-е - корейцы при помощи китайцев испекут ASIC на 90 нанометрах. И куда вы потом денете ваш дизайн, да ещё жестко привязанный к вашим 20 умножителям и архитектуре Spartan? Уж не говоря о том сколько времени вы будете его делать. Понятное дело, такое же можно сказать и обо мне. Мол тоже, к блэкфину привязался - неотвяжешься. Да, именно так, но есть и отличие: 1) всё уже сделано и отлично видны перспективы развития моего кодека. Перспективы хорошие. Частоты процессоров растут, а потребление падает. Потом. Сжатие я сделал в одиночку за полгода. Такой же проект на FPGA я даже не знаю, не возьмусь оценить сколько времени у меня уйдёт, несмотря на мой очень немаленький опыт программирования FPGA. (Правда, я использую Альтеру) Я даже не смогу гарантировать конечный результат, который бы был коммерческим. Возможно, (такое нынче встречается) у вас очень сильная команда FPGA дизайнеров, каждый из которых по совместительству хороший математик, и вы справитесь. Возможно. Всякое бывает. На нашей фирме (меня ещё тут не было) тоже был хороший FPGA дизайнер, и он не справился. А начиналось всё очень радужно. Оценки были как у вас. Звучали слова "умножители", "мегагерцы" и прочая патетика, но проект не поместился в нужную микросхему. Никак. А микросхема бОльшего размера не помещалась в бюджет разрабатываемого девайса. Тоже никак. Ну... можно было (что и было предложено) подождать новой серии спартанов. Начальство эту новость восприняло без энтузиазма. А делался всего-навсего обыкновенный JPEG.
Самое разумное для вас - это поискать аналогичные решения в предложениях конкурентов, чтобы не оказаться в такой же ситуации. Чтоб было понятно - а реализуемо это в принципе или нет? Когда я начинал выбор платформы, я перелопатил много информации в интернете об аналогичных продуктах: в основном - библиотеки, где обычно сказано какие параметры достигаются, какой fps при каком разрешении, на какой тактовой и прочее... Это мне сильно помогло. Хотя, я тоже сильно рисковал, так как исходил из предположения, что всё равно смогу сделать немного лучше. :)
Пока - да. В референсном дизайне от Xilinx скорость DCT составляет 140 Мгц (S3E), RLE - 100, а Хаффмана вообще 70Вот вы сами как себя ощущаете когда произносите подряд три слова: DCT, RLE, Huffman? :)
Технологии - то ведь отсталые, отсталее некуда. Да и Хаффман-то небось статитечский... И никакие примочки их уже не спасут IMHO.
-
Но у Блакфина - весьма ограниченная степень параллелизма (максимум два ME одновременно у BF561). FPGA, на первый взгляд, именно этим и подкупают, однако тут вступает в дело память...
Зато результат достигается быстро и недорого в сравнении с FPGA. Опять же, где есть такие FPGA стоимостью $25, которые делают 4 одновременно 16х16=>32 MAC-а на частоте 600МГц ?
А ведь блэкфин - это самое что ни есть бюджетное решение. А ведь есть ещё Tigersharc, есть продукты от TI типа DM642 и проч...(по TI я не спец.), и в этом случае изделие на FPGA совсем делается неконкурентным (может быть, разве что в военном применении, где цена вообще значения не имеет). Ну... ещё вариант, если вы решили печь ASIC. Тогда такое стремление можно оправдать.
Ещё раз зацитирую...
Но у Блакфина - весьма ограниченная степень параллелизма (максимум два ME одновременно у BF561).Это с чего вы так решили? Ну... тогда следуя аналогии получится, что bf53х - только одну!? :)
Посмотрите в сторону инструкции процессора SAA. Эта инструкция за один такт обрабатывает 8 пикселей. В двух ядрах - их соответственно будет 16.
И вообще, нахрена козе баян, а сжатию - МЕ?
Даёшь полноэкранные трансформации! Нет блочным алгоритмам! Урррааа! :)
В общем... делать сжатие на FPGA вы меня не уговорили ;)
-
понятно, спасибо я так и думал,
больше всего памяти как раз multi reference ME и жрет, но если искать best mathc то подобное решение (с однократной загрузкой кадра) есть и для МЕ :)
На ассемблере для blackfin? В режиме сжатия дающее 25 fps (хотя бы CIF)?
-
Арифметика такая.
Сначала полукадры пишутся при помощи DMA в SDRAM. Полукадр занимает 1440*288=414720 байт
Теперь трафик SDRAM самого алгоритма.
Для ч/б компоненты при разрешении 704*288 полный трафик SDRAM алгоритма составляет примерно 550 Кб из которых 405 - это собственно, чтение этого полукадра обратно из SDRAM. Неплохо, правда !? :))
Да... добавлю. Везде, внутри каждого банка SDRAM доступ ведётся ТОЛЬКО по последовательным адресам. Никакого рандома! То есть, будем считать, что про пречарджи и рефреши можно временно забыть :)
Примерно столько же трафика уйдёт на Cb и Cr компоненты.
То есть, цветной полукадр "скушает" 405(PPI DMA) + 550(Y) + 550(Cb,Cr) = примерно 1.5 Мбайт трафика.
При сжатии обоих полукадров цифра удваивается. То есть, сжатие 704х576 в цвете порождает трафик 3 Мбайта.
Что же нам может предложить самый "хилый" из блэкфинов bf531? SDR шину шириной 16 бит и SCLK=133МГц => 266 Мбайт/сек что в конечном итоге даёт 266/3 = 88 fps
Ну, в реальности, всё таки будут потери на переходы и смены банка, пречарджи и рефреши и пр.
Думаю, что тут мой предел по трафику при PAL video 704х576 будет где-то в пределах 50 fps, а мне всего-то нужны какие-то 25 :)
В общем, в железе так оно и есть. Я утилизирую меньше половины пропускной способности шины и полностью упираюсь в ядро процессора.
-
Хмм а не могли бы вы озвучить алгоритм категорию используемого вами алгоритма ?
Я правильно понимаю что вы использовали бинарный арифметический MQ (без деления) кодер ? А вы использовали контекстную адаптацию ? если да то контексты сами расчитывали ?
А вы расматривали реализацию MJPEG ? сравнивали с вашей системой ?
Или у вас одним из критериев выбора было отсутствие лицензионных отчислений ? :)
Арифметический кодек - не бинарный MQ :) Наиболее близким аналогом является range-coder , но только внешне. Кодер полностью сделан и оптимизирован для процессоров BF.
Да, кодер адаптивный. Контексты расчитывает сам.
Ещё раз повторюсь. Целью было не "победить" JPEG и остальных, а сделать "много" кадров в секунду при прочих адекватных характеристиках. Я прекрасно понимаю, что может быть другие алгоритмы в чём то и превосходят мой, но по скорости на семействе блэкфинов они и рядом не лежат с моим. Вот и всё. :)
Да. Полная лицензионная чистота - залог крепкого экономического здоровья :)
А можно табличку (хотя бы с точностью %20) Разрещение - пропускная способность памяти.Позже. Надо посчитать. Но если навскидку, то сейчас я далеко не упираюсь в память. При 60 fps на цветном 352х288.
-
Я имел в виду только исполняемый файл декодера для PC (если, конечно, такой существует).
Это всё понятно. Только вот на энтропийное кодирование тоже значительная (скорее всего, бОльшая) часть ресурса расходуется...
Декодер, разумеется существует, но по тем же причинам выложить я его не могу. Хотя, могу сразу оговориться, что в рамках общей радужной картины с моим кодеком, декодирование - самая ресурсоёмкая часть. К сожалению, разжатие примерно втрое медленнее чем сжатие благодаря специфике арифметического кодирования. Но так как разжатие преимущественно осуществляется на PC, то высокая тактовая частота PC-шных процессоров делает своё дело исправно. И там и тут реалтайм достигается.
Именно. БОльшая часть. Даже при сжатии. При разжатии просто значительно бОльшая часть.
БОльшая не только по вычислительному ресурсу, но и по сложности вычислений. Существенно сложнее чем все эти вэйвлеты, пускай даже самые хитрые.
-
Значит, вейвлет полнокадравоый... ладно
Да, я нашёл способ делать полноэкранный вейвлет (любых порядков) БЫСТРО и не упираться в трафик памяти (в разумных пределах конечно), поэтому могу себе позволить отказаться от блочных алгоритмов вообще.
Речь шла о пространственной частоте, актуальной для DCT. Но коль скоро нет, то - нет.Смысл вопроса заключался в том, что каждое полуполе выглядет по горизонтали нормальным, а по вертикали - сжатым в два раза; следовательно, к вертикальной частоте алгоритм должен быть более критичным, чем к горизонтальной. Отсюда - Intra и inter-блоки, и zigzag-ордеринг. Просто было интересно, как это вещи решаются в вейвлетах.
Несимметрия по вертикали и горизонтали решается очень просто. Автоматически. Просто правильно строится дерево Молла и всё. В результате, после первой итерации пространственные частоты выравниваются. Видимо, поэтому это я как проблему и не воспринял.
Единственное для чего нужен зигзаг, так это для адекватной работы RLE. И ВСЁ!
Энтропийному кодеру RLE не нужен, и более того в предельном случае, последовательность обхода вообще не важна.
а хотелось бы в целом знать весь потенциал технологииВесь потенциал технологии раскрывается в процессоре BF561, у него и шина 32 бита, и два ядра на 600 Мгц.... красотааа! :)
А, секьюрити... Тогда понятно, почему вопросы траффика и мобильного питания не актуальны.На самом деле они актуальны. Но также актуально сделать РЕАЛЬНУЮ ВЕШЬ которая превосходит конкурентов по многим показателям. По энергопотреблению мы уже сейчас ДАЛЕКО обходим продукцию конкурентов, здесь блэкфин очень хорош. Трафик уменьшить тоже можно, но НЕЛЬЗЯ урезать функционал и качество в угоду этому трафику. Везде есть разумный компромисс.
Почему же? Можно ведь накапливать данные с фронта и среза в 32-битном регистре... а затем - выдавать на шину. То же самое и при записи, задержка - один цикл. Пожалуй, единсвтенная реальная несовместимость - дифф. клоки, но ведь буфер-то всё стерпит, разве не так? 8)Это всё правильно, но BF просто НЕ МОЖЕТ породить больше данных на шине, также как и принять их, какая бы быстрая DDR ни была. Моё мнение здесь однозначно, при правильном программировании встроенного контроллера SDRAM, результат будет выше чем с внешними примочками. У BF хорошая шинная архитектура, позволяющая довольно свободно манипулировать внешним трафиком, обеспечивая максимальную утилизацию шин, и эту ситуацию можно только ухудшить.
-
Как уже тут говорили, BF не умеет делать "burst" при чтении
И тут есть мааленькая неточность, ну.. обманул немного. Контроллер SDRAM у BF так устроен, что он МОЖЕТ формировать бёрст на нечётное слово, но на большее он не способен. То есть - это даёт выигрышь при чтении двойного слова против двух чтений слов в отдельности. Но это так... будем считать, что не умеет.
Можно в общих чертах - какой (если используется) алгоритм motion estimationУлыбнуло :) Для полноэкранной трансформации (каковой является применяемый у меня вэйвлет) не нужно делать оценку движения. Она нужна только в блочных алгоритмах, где размер исследуемой области очень мал и нужно найти корелляцию между этими областями. У меня же трансформация ведётся по всему видео массиву, а не по отдельным его кусочкам типа DCT 8х8.
сколько в работе задействуется памяти (в т.ч и внешней), задействуются ли прерывания и, если да, насколько активно; какое питание - батерея, или сеть? И, главное, насколько низким может быть итоговый битрейт?Да, кстати... как критичен Ваш поток к ошибкам связи?
Для примера, алгоритм спокойно умещается во внутреннюю память BF531 + внешняя SDRAM 16Мб. Внешняя память ДОЛЖНА быть 4-х банковой.
По остальным вопросам, кратко, так как в общем-то в них и заложен ответ: прерывания задействованы самым оптимальным образом, питание - гибридное, сеть, но есть переключение на батарею.
ОЧЕНЬ низким битрейт быть у меня не может в силу нескольких причин. Сами понимаете, мой алгоритм был создан мною исходя из конкретных особенностей архитектуры процессора для обеспечения производительности в первую очередь. То есть - я должен сжимать CIF не особо напрягаясь. Затем - я должен также сжимать и полный PAL (скоро будет 25 fps). И при всём при этом иметь хорошее качество картинки (конкурентное) и всё такое прочее... Поэтому я вынужден был искать компромиссы и придумывать новые эффективные методы. От DCT я отказался. Правда, написал кодек для BF. От межкадровогого сжатия - тоже, так как это планировалось сделать в следующем этапе работы (было бы слишком сложно и непредсказуемо делать всё и сразу).
В данный момент на CIF(352x288 в цвете) как правило размер кадра при довольно сильном сжатии и как следствие - среднем качестве картинки не может быть меньше 5 кбайт (я это конечно могу изменить, но не буду, так как для нас это приемлимо). Разумеется, алгоритм полностью управляемый параметрически, я могу задать даже режим CBR указав желаемый объём кадра и система будет пытаться выполнить мои требования в реалтайме. То есть это мегабит в секунду. В будущем будет и межкадровое сжатие, там будет поток меньше на "спокойных" сценах, но не сейчас. В проекте очень много и других составляющих кроме сжатия - сеть, жёсткий диск и прочее... Но даже сейчас получилось лучше чем JPEG.
Как любой энтропийный алгоритм - к ошибкам критичен. Защищать нужно на транспортном уровне, что мы и делаем.
704x576 - это по отдельным полям (704x288), или уже после деинтерлейса (если, конечно, он есть)? Как, кстати, Вы боретесь с высокой вертикальной частотой?Сжимаются два смежных полукадра 704х288 независимо, и как следствие - нет никакого интерлейсинга (если конечно правильно обратно выводить на экран) :)
Про высокую верт. частоту не понял юмора что то... :) Зачем с ней бороться-то? С какой частотой кадры приходят, с такой их и жмём. Если не успеваем, то поступаем наиболее оптимальным образом. Грамотно пропускаем полуполя, на фоне запускаем новый захват, синхронизируемся на первое поле и так далее и тому подобное...
То есть 30 fps для PAL - это, по-Вашему, реально?Более чем реально, но... PAL - это 25 fps :)
Вот это уже действительно интересно. Как много в вашем проекте используется обращений к памяти? (Мб/с)В нашем проекте 9 процессоров, 32 PAL камеры и прочее, и если сложить весь трафик.....уухх :))
Да и почему мост должен быть обязательно ASYNC? Ведь, кажется, буферная схема SDRAM с одним тактом ожидания ничему не противоречит, и может быть реализована даже на CPLD... впрочем, стоимость CPLD с таким числом выводов будет явно завышенной.Ничему не противоречит, но и ни зачем не нужна. DDR-то к ней не прикрутишь...увы...
-
Stanislav
Разумеется кодек полностью нестандартный, но и не "open source".
А по поводу картинок, то соотношение размер/качество примерно эквивалентно тому что получается при JPEG сжатии благодаря тому, что у меня нет возможности на сложное статистическое оценивание материала в реальном времени, в отличие от JPEG кодеков на PC со значительно более толстыми процессорами. Но благодаря более прогрессивной трансформации и энтропийному сжатию (против Хаффмана у JPEG) ситуация выправляется. Разве что характер искажений при сильном квантовании у нас разный. JPEG рассыпается "квадратиками" (DCT), а у меня появляется "акварельность", более сильная размытость картинки (fullscreen wavelet). Психовизуально - второй вариант лучше.
vetal
На сколько я понимаю DDRх16@85MHz(2 слова за период)=SDRх32@85Mhz(1 слово за период). Или я не прав?Экономия в уменьшении количества сигналов требующих трассировки, за счет более эффективного использования сонхронизации.
В целом, всё верно, но только к сожалению, у современных блэкфинов нет контроллера DDR, а применение моста ASYNC -> DDR на FPGA приведёт к "уполовиниванию" пикового трафика, так как обмен по асинхронной шине ведётся (эффективно) на половинной частоте шины. А DDR как раз и хорош этим самым "пиковым" трафиком, ради чего весь "сыр-бор" разгорелся.
-
Результаты впечатляют....Покадровый полноэкранный вэйвлет, сжатие оригинальным арифметическим кодеком.Видео и производительность:
Сжатие цветного 352x288 - немногим более 50 fps плюс 10 процентов вычислительного ресурса свободны
Сжатие цветного 704x576 примерно 20 fps
Скорость можно ещё поднять процентов на 10 если убрать встроенную обработку видео (шумопонижение, многоточечный детектор движения и по мелочам)
Скоро начну делать новый алгоритм базирующийся на текущем. Всё уже продумано, но в железе пока не тестировал. Предварительный расклад таков. По отношению к вышенаписанному, скорость поднимается от 1.5 до 2-х раз при остальных неизменных параметрах...
Скажите, а межкадровую обработку делать не планируете?
Планирую, но уже в третьей ревизии.
Помимо сжатия в проекте ещё очень много составляющих которые нужно реализовать.
А по сжатию, надо лишь натянуть режим 704x576 в цвете до 25 fps, и это будет карашо! :)
-
dryadae
Добавлю немного своего мнения.
Для начала уточню: 1) Я делал собственные алгоритмы сжатия для BF. 2) Они работают в железе.
По поводу подключения внешней DDR через FPGA. Если вы задумали это делать через асинхронную шину, то сразу надо понимать то, что весь обмен по ней происходит на эффективной частоте SCLK/2 (так как вствляется один такт принудительного "setup"), то есть пиковый трафик будет вдвое меньше чем на SDRAM. Как уже тут говорили, BF не умеет делать "burst" при чтении, но если всё заранее спроектировать, то чтение можно перевести на DMA.
Вот пример моей системы, как образец что может BF, а чего не может.
ADSP-BF532 393 MHz, внешняя SDRAM 131 MHz
Покадровый полноэкранный вэйвлет, сжатие оригинальным арифметическим кодеком.
Видео и производительность:
Сжатие цветного 352x288 - немногим более 50 fps плюс 10 процентов вычислительного ресурса свободны
Сжатие цветного 704x576 примерно 20 fps
Скорость можно ещё поднять процентов на 10 если убрать встроенную обработку видео (шумопонижение, многоточечный детектор движения и по мелочам)
Скоро начну делать новый алгоритм базирующийся на текущем. Всё уже продумано, но в железе пока не тестировал. Предварительный расклад таков. По отношению к вышенаписанному, скорость поднимается от 1.5 до 2-х раз при остальных неизменных параметрах.
При всём этом хочу напомнить, что этот процессор имеет всего-лишь 16-разрядную шину и не умеет делать "burst" по чтению. Видите, на самом деле всё не так уж и страшно :)
-
Объясняю.
Мне необходим инструмент разработчика (Ethernet Development Kit) для изучение работы c TCP/IP.
Такие киты могут состоять из микроконтроллера (или DSP, CPLD, FPGA) и "общаться" с Ethernet-контроллером(например, RTL8019AS), находящимся рядом. Их большое множество и выбрать без предварительной работы с ними невозможно (не известны заранее плюсы и минусы).
Поэтому я и обращаюсь к сообществу форумчан с просьбой поррекомендовать тот или иной кит. Его характеристики, возможности, цены.
А задачи, которые предстоит решить разнообразны - передача данных между несколькими микроконтроллерами посредством LAN; передача данных с контроллера на копм и обратно.
Пока меня интересует сторона электроники, а прием/передача данных по LAN с компа - проблема программистов.
Пытался доходчиво объяснить.
А если совсем по-простому:
Научиться передавать пакет от одного контроллера к другому. Для начала без CRC, затем с его проверкой, проверкой коллизий и т.п.
Опять же, можете поконкретнее рассказать о ваших предпочтениях?
Кит посоветовать несложно, ну вот например: ADDS-BF537-EZLITE Супер Кит! Правда хорошо посоветовал?! Большего и пожелать-то трудно, но....
Вы меня конечно же спросите, а что такое ADSP? А как его программировать, и пошло поехало...
В любом случае, я точно вам скажу, что лёгкого старта не получится, и всё равно ПРИДЁТСЯ изучить что же такое этот Ethernet.
Поэтому, для начала советую почитать спецификацию на Ethernet, лучшего документа вы не найдёте, плюс книжки. Их масса. То чем пользовался я когда писал свою ethmac корку -
Тим Паркер, Каранжит Сиян "TCP/IP Для профессионалов. 3-е изд" Большая такая книга в твёрдой жёлтой обложке. Издательство "Питер"
У. Ричард Стивенс "Протоколы TCP/IP. Практическое руководство" Издательство "BHV" Мягкая обложка в стиле типичном для этого издательства.
Обе книжки хорошо дополняют друг друга и очень толковые.
Также в интернете есть много открытых исходников IP стеков (lwIP, OpenTCP, uIP и проч.) и плат на микроконтроллерах с Ethernet, их просто море, и гугл здесь лучший помошник.
-
Решение очень простое. В EE197 прямо об этом и сказано, нужно обнулить lcX (или убедиться что там ноль).
r0 = 0;
lc0 = r0;
lc1 = r0;
Дальше можно загружать lcX без всяких задержек чем угодно.
Предварительно, разумеется lc0,lc1 сохраняются в удобном месте.
-
У меня всё решилось подтягиванием RXER резистором к земле. Он ДОЛЖЕН быть нулём при старте. К MDIO я даже не прикасаюсь, всё по дефолту. Сейчас всё работает как положено, пакеты и принимаются и передаются.
-
133 трудно задать без оверклокинга, или я чегото недопонимаю ....
Что касаемо топологии - то работает и без резисторов. Для чего: длины шины данных, стробы данных клок и управляющие менее полутора дюйма и выровнены, адреса получились длиннее и не выровнены ...
adsp-bf532:
400Mhz - core clk
400/3 = 133Mhz - system clk
по даташиту
на 133 у меня работает без резисторов, правда в 4х слоях.
У меня частоты аналогичные, но на шине кроме SDRAM ещё и FPGA торчит. Резисторов нет (только на клоке). Работает на 2-х слойке.
-
Old Nick
Много времени прошло и многое подзабылось. Сейчас я уже давно не занимаюсь этим проектом, но кое-что ответить могу.
>> По моим наблюдениям, SRC успешно "отключается" установкой соответствующего volume control в
>> пложение "максимум". Проверено в режиме file1.wav -> USB-AUDIO device -> SPDIF->SPDIF_input
>> ->file2.wav. Совпадает побитно, не считая сдвига. Разумеется, не следует лить 48kHz.wav -> 44.1
>> USBaudio.
Возможно так оно и есть, но не в моём случае. У меня дефолтовая частота дискретизации была 88.2 КГц, поэтому при работе в режимах 48,96 SRC работает всегда, но при 44.1 SRC хоть и работает тоже, но уже по другому алгоритму, по сути не SRC, просто фильтрация с децимацией, что даёт такое высокое качество при прослушивании типового аудио (CD,mp3 и т.д.) Это был мой компромисс. Более того, на честные 96 КГц у меня просто не хватало памяти на FIFO внутри чипа, поэтому и были выбраны 88.2. Позже я понял, что поступил правильно.
>> 1.Под какими разливами мелкософта удается получить свыше 16бит и какими средствами и
>> проблемами, помимо упомянутых?
Этого я с уверенностью сказать не могу, нужно экспериментировать. Поскольку этот проект у меня заглох в силу того, что устройство оказалось никому не нужным (кроме, разумеется меня). В конференциях я видел посты о том, что в ВинХР реализована 24битность, но я уже это не проверял.
>> 2.Хватает ли фифо на "слабых" машинах и активно используемой мышкой/клавиатурой на том же хабе?
Я свою плату включал в USB порт всегда как единственную и про хабы ничего не скажу. Но ни при какой загрузке системы (тем более при активности мышки и прочее) никаких артефактов звука я не наблюдал. Например, при записи CD/DVD, копировании больших потоков данных, сильной активности сети, игрании в игрушку и прочее, звук абсолютно чистый и не прерывающийся. Этой платой я сам пользуюсь и её работой очень доволен. Единственное, я так и не смог запустить её под Линукс, там в ALSA нет SRC как такового и дальше разбираться я не стал.
Объём буферов на плате у меня асолютно минимальный, то есть на 1 миллисекунду звука по два пинг-понг буфера, и всё.
>> 3.Правильно ли я понял, что Вы использовали VCXO (vco с кварцем)? Какая надобность именно в управляемом генераторе?
Да, у меня VCXO с PLL которой я хитро управляю. Это нужно только из за кривости встроенного драйвера usbaudio в MSwin. Ну не хотят они правильно реализовать адаптивный режим работы, поэтому пришлось пользоваться синхронным. Способ конечно, сомнительный, но пока я ещё не встречал ни одной материнки у которой бы нестабильно шли SOF пакеты (к ним я привязан).
С наступающим!
поставил Libero 10, хочу бросить какашки в актел
в Среды разработки - обсуждаем САПРы
Опубликовано · Пожаловаться
Процессор замечательный, понимаю, 1 Мрад - это круто, но вики сообщает следующее - "Стоимость RAD750 сравнима со стоимостью RAD6000 и начинается от 200 тыс. долларов США (в ценах 2002 года)", что кагбэ несколько неприемлемо...