Jump to content

    

alexdsp

Свой
  • Content Count

    82
  • Joined

  • Last visited

Community Reputation

0 Обычный

About alexdsp

  • Rank
    Частый гость
  • Birthday 08/17/1969

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

1119 profile views
  1. Процессор замечательный, понимаю, 1 Мрад - это круто, но вики сообщает следующее - "Стоимость RAD750 сравнима со стоимостью RAD6000 и начинается от 200 тыс. долларов США (в ценах 2002 года)", что кагбэ несколько неприемлемо...
  2. Интересно. Цены примерные на ATF697FF подсказать можете? Ну и на ATF697F тоже за компанию было бы неплохо узнать.
  3. Да, девайс интересный... спасибо. Единственно, закрадываются подозрения, что реально начать с ним работать будет очень проблематично.
  4. Хотелось бы спросить насчёт SmartFusion2. Что там будет с внутренним хард-ядром ARM? Оно тоже будет аппаратно затроировано на уровне триггеров , как и остальная логика? Просто очень нужно SEU защищённое процессорное ядро живучее с TID 100 крад или лучше. Можно ли уже отлаживаться на SmartFusion2 или Igloo2 с последующей миграцией на радхард версию? Опять, же... если она ещё будет эта версия... и когда. Сейчас встаёт проблема выбора. Видел отчёты реальных людей с тестами, где RTPA3 уже от 20 крад физически дохнут. Накрывается charge-pump цепи, да так, что уже невозможно ни стереть, ни пепепрошить. RTPA3 отпадает. ProASICplus устарел, да и мало подходит для проекта. По SmartFusion2 и Igloo2 радиационных данных пока не нашёл. Меня склоняют к индустриальному Virtex-у, и аргументов против у меня уже не хватает. В идеале, если бы индастриал Igloo2 переносили хотя бы 100 крад дозы, имело бы смысл поднапрячься с софт-троированием стороннего софт-ядра и т.д...
  5. На тему набрёл поиском. Хочу попробовать Quectel L20, а как-то с документацией в сети оказалось негусто. Насколько я понял, там есть OpenCPU, хотелось бы с SDK тоже разобраться досконально. Подскажите пожалуйста, где находится нормальная документация и всё остальное? Сайт Quectel как-то подозрительно пуст...
  6. Очень просто, дело в том, что в циклоне выходы LVDS имеют "неправильный" уровень и должны корректироваться резисторами, это в соотв. аппнотах написано, надеюсь они у вас есть, иначе вообще LVDS работать не будет. В вашем случае, я бы просто назначил на рабочие выходы (LVDS97n, LVDS96p при LVDS) тип LVCMOS, а в самом проекте, рабочий сигнал подал на тот вывод, который в LVDS был прямым, а на второй диф. вывод подал бы инверсию, и всё. Это абсолютно эквивалентно и никак не повлияет ни на что. Другое дело, если бы вы ошиблись в разводке диф. входа LVDS приёмника, тут бы уже ничего нельзя было исправить.
  7. А Freescale не рассматривали? Например MPC5200B. 400MHz, double precision FPU и прочее. Не DSP, но всё же PowerPC, да и энергопотребление вообще скромное. Я лично с ним дела не имел, но когда-то бегло просмотривал документацию. На мой взгляд очень достойный чип. Интересно ваше мнение.
  8. KPAH Большое спасибо за ссылку. Очень документ порадовал (хотя такой метод генерации синуса я знал и раньше). 0FF/2 А есть ли ещё что-нибудь в этом же духе, т.е. в виде справочника по разным методам, алгоритмам и прочее?
  9. Посмотрел бегло 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. Единственный аргумент "против" - это то о чём вы уже упоминали: "нестандартность". Против этого уже не попрёшь, конечно...
  10. Тут я вас прекрасно понимаю. Но мы то как раз разрабатываем законченное изделие, а не технологию. Продаваться будет изделие, поэтому мы вправе навязать своё решение потребителю, благо оно не уступает продукции конкурентов. И блэкфин был выбран как раз из-за суммарной дешевизны платформы. Конкуренты, в принципе не могут сжимать 704x576 - 25 fps в многоканальном режиме. У них применяются аппаратные кодеки, рассчитанные на ограниченное количество каналов (1-4), и весьма ограниченный fps и (видимо) плохо поддающиеся масштабированию. Я (скоро) смогу. То есть 20 fps уже есть. Была ревизия алгоритма - будут и 25 fps. dryadae Специфика таких дизайнов в FPGA в том, что эти ваши умножители будут очень жёстко привязаны к своей функции внутри блока и будут быстро расходоваться на каждое мало-мальски необходимое умножение, или вы полностью утонете в мультиплексорах и связанных с ними регистрах конвейеров. Плюс ОЧЕНЬ высокая сложность такой реализации. Есть немало проектов видео-сжатия в FPGA , бодро начавшихся несколько лет назад и продолжающихся до сих пор в стадии пре-альфа. И пока вы будете смаковать потенциальную, гипотетическую возможность разработки HDTV кодека на S3E или Stratix-е - корейцы при помощи китайцев испекут ASIC на 90 нанометрах. И куда вы потом денете ваш дизайн, да ещё жестко привязанный к вашим 20 умножителям и архитектуре Spartan? Уж не говоря о том сколько времени вы будете его делать. Понятное дело, такое же можно сказать и обо мне. Мол тоже, к блэкфину привязался - неотвяжешься. Да, именно так, но есть и отличие: 1) всё уже сделано и отлично видны перспективы развития моего кодека. Перспективы хорошие. Частоты процессоров растут, а потребление падает. Потом. Сжатие я сделал в одиночку за полгода. Такой же проект на FPGA я даже не знаю, не возьмусь оценить сколько времени у меня уйдёт, несмотря на мой очень немаленький опыт программирования FPGA. (Правда, я использую Альтеру) Я даже не смогу гарантировать конечный результат, который бы был коммерческим. Возможно, (такое нынче встречается) у вас очень сильная команда FPGA дизайнеров, каждый из которых по совместительству хороший математик, и вы справитесь. Возможно. Всякое бывает. На нашей фирме (меня ещё тут не было) тоже был хороший FPGA дизайнер, и он не справился. А начиналось всё очень радужно. Оценки были как у вас. Звучали слова "умножители", "мегагерцы" и прочая патетика, но проект не поместился в нужную микросхему. Никак. А микросхема бОльшего размера не помещалась в бюджет разрабатываемого девайса. Тоже никак. Ну... можно было (что и было предложено) подождать новой серии спартанов. Начальство эту новость восприняло без энтузиазма. А делался всего-навсего обыкновенный JPEG. Самое разумное для вас - это поискать аналогичные решения в предложениях конкурентов, чтобы не оказаться в такой же ситуации. Чтоб было понятно - а реализуемо это в принципе или нет? Когда я начинал выбор платформы, я перелопатил много информации в интернете об аналогичных продуктах: в основном - библиотеки, где обычно сказано какие параметры достигаются, какой fps при каком разрешении, на какой тактовой и прочее... Это мне сильно помогло. Хотя, я тоже сильно рисковал, так как исходил из предположения, что всё равно смогу сделать немного лучше. :) Вот вы сами как себя ощущаете когда произносите подряд три слова: DCT, RLE, Huffman? :) Технологии - то ведь отсталые, отсталее некуда. Да и Хаффман-то небось статитечский... И никакие примочки их уже не спасут IMHO.
  11. Зато результат достигается быстро и недорого в сравнении с FPGA. Опять же, где есть такие FPGA стоимостью $25, которые делают 4 одновременно 16х16=>32 MAC-а на частоте 600МГц ? А ведь блэкфин - это самое что ни есть бюджетное решение. А ведь есть ещё Tigersharc, есть продукты от TI типа DM642 и проч...(по TI я не спец.), и в этом случае изделие на FPGA совсем делается неконкурентным (может быть, разве что в военном применении, где цена вообще значения не имеет). Ну... ещё вариант, если вы решили печь ASIC. Тогда такое стремление можно оправдать. Ещё раз зацитирую... Это с чего вы так решили? Ну... тогда следуя аналогии получится, что bf53х - только одну!? :) Посмотрите в сторону инструкции процессора SAA. Эта инструкция за один такт обрабатывает 8 пикселей. В двух ядрах - их соответственно будет 16. И вообще, нахрена козе баян, а сжатию - МЕ? Даёшь полноэкранные трансформации! Нет блочным алгоритмам! Урррааа! :) В общем... делать сжатие на FPGA вы меня не уговорили ;)
  12. На ассемблере для blackfin? В режиме сжатия дающее 25 fps (хотя бы CIF)?
  13. Арифметика такая. Сначала полукадры пишутся при помощи 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 :) В общем, в железе так оно и есть. Я утилизирую меньше половины пропускной способности шины и полностью упираюсь в ядро процессора.
  14. Арифметический кодек - не бинарный MQ :) Наиболее близким аналогом является range-coder , но только внешне. Кодер полностью сделан и оптимизирован для процессоров BF. Да, кодер адаптивный. Контексты расчитывает сам. Ещё раз повторюсь. Целью было не "победить" JPEG и остальных, а сделать "много" кадров в секунду при прочих адекватных характеристиках. Я прекрасно понимаю, что может быть другие алгоритмы в чём то и превосходят мой, но по скорости на семействе блэкфинов они и рядом не лежат с моим. Вот и всё. :) Да. Полная лицензионная чистота - залог крепкого экономического здоровья :) Позже. Надо посчитать. Но если навскидку, то сейчас я далеко не упираюсь в память. При 60 fps на цветном 352х288.
  15. Декодер, разумеется существует, но по тем же причинам выложить я его не могу. Хотя, могу сразу оговориться, что в рамках общей радужной картины с моим кодеком, декодирование - самая ресурсоёмкая часть. К сожалению, разжатие примерно втрое медленнее чем сжатие благодаря специфике арифметического кодирования. Но так как разжатие преимущественно осуществляется на PC, то высокая тактовая частота PC-шных процессоров делает своё дело исправно. И там и тут реалтайм достигается. Именно. БОльшая часть. Даже при сжатии. При разжатии просто значительно бОльшая часть. БОльшая не только по вычислительному ресурсу, но и по сложности вычислений. Существенно сложнее чем все эти вэйвлеты, пускай даже самые хитрые.