Карательная электроника: Как нельзя разрабатывать интерфейс скоростной видеокамеры⁠⁠

Кратко в статье будет:

Что же не так в первой же картинке: хоть и выглядит вполне аккуратно, или сказ о наводках и СВЧ чёрной цифровой магии и почему так делать нельзя.

Немного об отладочной плате FPGA и особенностях разработки.

О модуле камеры, её сенсоре, MIPI интерфейсе и как его испортить.

Как сделать связь с ПК в сотни мегабит, менее 100мбит/сек, и как в том числе и тут словить кару.

Внимание: в статье несколько хайрез фоток и видео, много тех терминов и лютого DIY, возможен взрыв мозга!

Итак, начнём с пациента:

Что это на фото?

1. Белая плата - мозги: FPGA плата на базе Artix-7 от Xilinx, подключена к ПК по micro USB для прошивки и отладочных логов

2. Мини плата слева сверху - FTDI, обещала "скоростную" связь с компом...

3. Синяя плата справа сверху - сам модуль скоростной камеры с пимпкой "объектива" (извиняюсь за ругательство).

4. Куча проводков от ардуины.

Требовалось:

Захватить видеопоток с камеры и послать на ПК как есть, без сжатия но в RGB, при этом достичь максимального количества кадров в секунду (в идеале несколько сотен).

Что за зверь это, FPGA плата?

Это процессор или миникомп как "малинка"?

Нет!

Но, она, как и процессор, может исполнять алгоритм, считать и управлять чем-нибудь.

По сути FPGA - это набор блоков памяти, отдельных битов памяти и простых, проще сложения, логических элементов с управляемыми связями. А связями всего этого набора можно произвольно управлять софтом по своему желанию.

Стоп! А как же тогда оно считает? исполняет алгоритм и управляет?

А тем, что специальный софт разбивает алгоритм, написанный на Си подобном языке, на отдельные блоки:

массивы размещает в большие блоки памяти,

переменные разбивает на биты и размещает в отдельные аппаратные биты,

вычисления, даже такие простые как инкремент разбивает на сотни и тысячи логических функций, для сложных использует готовые аппаратные блоки.

И потом всё это соединяет вполне реальными физическими связями. И работает всё это на частотах в несколько сотен мегагерц.

По сути алгоритм превращается в реальную и очень комплексную электрическую схему. Это настолько низкоуровневое программирование, что даже "ниже" не только ассемблера, но и машинных кодов и чёрт побери перфокарт!

100-200 Мгц медленно? и зачем нужны такие заморочки? Если есть обычная малинка или одноплатные ПК х86 на которых винда крутится.

И нет, это не медленно и есть задачи, где не возможно обойтись без FPGA физически.

Первая фишка:

в том что это не проц, который исполняет алгоритм шаг за шагом. Это куча связанного "железа" которая исполняет весь алгоритм одновременно! Тотальное 100% распараллеливание алгоритма, даже если в нём несколько сотен тысяч строк кода!

Это даёт возможность такой магии, как сортировка массива за ноль тактов (например, в фильтре шума).

А ещё даёт возможность самому проектировать эмуляторы старых консолей и они будут работать в точности, нет, ТАК В ТАК, так-же как и их аппаратные дедушки, даже даёт возможность сэмулировать баги, и разные аппаратные нестабильности например в звуке чип-тюна ZX-Spectrum.

А ещё это и чудовищное быстродействие: делать расчёты на 66 Мгц быстрее чем Core i7 на 3700 МГц? запросто! Именно поэтому ASIC (некоторые их виды - FPGA с предзаказанными, не изменяемыми связями) так полюбились всеми майнерами.

Вторая принципиально непобедимая фишка:

время реакции - раз всё работает параллельно и можно реагировать с нереальной скоростью, в десятки а порой единицы наносекунд. Робототехника, автопрома и оружейка - без FPGA и ASIC (захардкоженный FPGA) никак.

Третья фишка:

можно реализовать любую периферию, любой интерфейс самому при помощи исходного кода, и если ты написал сам всё с нуля, включая интерфейсы, то это 100% переносимо, ну не мечта ли? Но с большими оговорками, и можно "отстрелить себе ногу", что я и сделал в интерфейсе камеры.

Модуль камеры:

Это плата модуля камеры: сверху чёрный цилиндр объектива, под ним чип сенсора который собственно и видит со всей логикой, который установлен на плате, два стабилизатора питания и разъём 40 контактный.

Характеристики этого модуля:

5 мегапикселей.

"Объектив" полное разочарование: мылит даже на VGA разрешении, света собирает мало, не настраивается фокус. Но для отладки пойдёт.

Чип сенсора выдаёт RAW формат как в профессиональных фотокамерах - в RGB придётся проявлять самому,

Интерфейс параллельный MIPI, он примитивный: каждый такт синхросигнала выдаёт 12 бит данных пикселя, с парой статусных сигналов "конец строки" и "конец кадра".

Для настройки юзает двух проводной последовательный I2C.

Коннектор - 40 пиновый, двухрядный с шагом 2.56мм, как в старых жестяках.

Казалось бы всё просто особенно для FPGA...

"Отстрел ноги"

Но чтоб достичь максимальной скорости надо выдать камере максимальную частоту в ~100Мгц (а с гармониками до гигагерца), от которой камера и тактируется, которая в свою очередь даёт ответный синхросигнал обратно в FPGA с сырыми данными изображения.

А это очень быстро, даже слишком быстро и было наивно с моей стороны надеется, что можно отдельными проводками соединить и ничего за это не будет...

Будет!

Во первых:

В стародавние времена, когда у жестяков был широченный ParallelATA 40 пиновый коннектор и такой-же шлейф, то этот 40 жильный шлейф работал только до частот 30-60МГц, а далее уже нужно было использовать особый магический 80 жильный шлейф с чередованием земель. И это не спроста: на таких частотах взаимные наводки очень сильно влияют и портят сигнал. Но в этой связке его использовать нельзя т.к. на основной FPGA плате нет такого же 40пинового разъёма, а негодяи из Xilinx ради маркетинга (ну и чтоб продавать только их доп платки по конской наценке) и несовместимости запилили 4 группы по 12 контактов в два ряда.

Во вторых:

Длинна ардуино-проводов разная да и на самой плате очень сильно различается длинна дорожек, а это критично на таких скоростях, и если даже не из за скорости света, то из за разной индуктивности - которая усиливает взимные наводки, разносит их по разным фазам ещё сильнее и превращает полезный сигнал в "кашу".

В третьих:

маркетологи посчитали что при помощи платы "всего" за 100 баксов нельзя давать заниматься серьёзными вещами. И поэтому два из четырёх 12 контактных коннекторов GPIO подключили через много килоомные резисторы тем самым зарезав частоту и "завалив форнты" (когда тактовая нарастает не слишком быстро чип камеры, из за шумов может не понять время переключение, это было одно или несколько).

Не делайте так! Не надо пытаться ардуино-проводками подключать такие быстрые (свыше 30 МГц и многобитные интерфейсы)

Попытки профиксить и прочие бесполезные трепыхания

1. Тактовая пикселей MIPI что выходит из камеры оказалась в разы шумнее: это тактовая из FPGA которая набрала по пути до камеры шумы, а потом вернулась из камеры в FPGA набрав ещё шумов на обратном пути. Пришлось затактироваться внутренней частотой внутри FPGA что генерится и выдаётся наружу и игнорировать синхронную с данными от камерами возвращающуюся обратно частоту самих данных.

Фейл: чип камеры при каждом старте настраивается чуток по разному и поэтому выходящая из него тактовая тоже на пару наносекунд то отстаёт то опережает.

Адский Костыль: Нужно вручную подстраивать каждый раз при каждом включении задержку.

2. Фейл: Взаимные шумы: так как лежит на первой картинке (плата связи рядом с платой камеры) не работает! В линке с ПК проскакивают лишние байты или он теряет байты.

Адский Костыль:

приходится буквально на пару сантиметров отгибать в сторону камеру вот так:

Чёртов бубновый шаманизм!

3. Мини Фейл: Ардуино проводки - они норовят отскачить при любом неосторожном движении любой платы! Это, просто, очень и очень не удобно, надо ОЧЕНЬ аккуратно всё двигать.

Костыль: расковырял иголкой разъём чтоб лучше держалось ... помогло мало но вроде помогло.

4. Связь с ПК при помощи модуля FTDI2232H оказалось не настолько крутой как её рекламировала фирма.

Фейл: скорость вместо 480 мегабит оказалась всего в 100 мегабит, т.к. внутри ФТДИхи два канала и они прибиты гвоздями, уже 240мегабит, USB не умеет в 100% пропускной, уже 200Мегабит, а чип не сразу видит такт записи а через пол дополнительного такта: вот тебе и 100 мегабит. Заморачиваться и собирать из двух каналов один не стал - драйвер фтди перемашивает рандомно пакеты и байты не говоря где начало пакета, а где конец.

5. Так-же производитель камеры обманул: вместо 150 фпс оказалось 128 фпс - только на  такую скорость удалось настроить. Сам сенсор на такой скорости оказался очень тёмным, а чуствительность красного и синего канала настолько низкой что её пришлось домножать на х2 - х3 вместе с шумами и добавочно делать полноценное шумо-подавление.

Что дополнительно было разработано

Т.к. камера выдаёт сырой рав-поток как в проф камерах, то его надо обрабатывать как это делают тулзы цифровой проявки такие как Adobe Light room.

Для этого запилил на верилоге свой видеопроц:

в нём и MIPI приёмник, и свой i2c контроллер и такие страшные слова как:

- баланс белого,

- гамма-коррекция,

- коррекция дин. диапазона (после гаммы чёрный усиливается и становится серым - это надо фиксить),

- шумодав (где сортируется за 0 тактов в медианном фильтре),

- кроп и ресайз,

- усиление и коррекция цветов (синий и красный оказались очень слабыми).

схемка для пущего "устрашения" (to NN это выход в фтди, и спойлер темы будущей статьи ;):

Итог и что получилось сделать:

Оно заработало:

слева рендеринг на ПК при помощи OpenCV и С++ (на нём же писал и отлаживал RTL код для верилога и переносил как есть в верилог),

а справа отладочная консоль из FPGA в формате VT100 с цветами и свистелко-перделками  (терминал с printf, текстом и преобразованием чисел в текст и пр. реализовано всё это аппаратно на FPGA при помощи той же логики и такой-то матери), да я люблю красиво, дорого и богато особенно в отладке.

Расшифровка видео:

В первую секунду видна первичная инициализация и пуск камеры с логом адресов и значений команд записи регистров настроек в камеру по I2C.

Далее я ручками, посылаю текстовые команды в FPGA (лексический интерпретатор команд тоже сам сделал, тоже на логике) и настраиваю яркость и чёртову фазу сигналов, видно что после подстройки фазы обильный "розовый снег" исчезает.

После я машу перед камерой древним смартом с настроечной таблицей цветов.

всплывшие косяки:

1. т.к. хоть камера и работает в режиме 128 фпс, но по скорости FTDI подвела и только 64 кадра в сек посылается в ПК, в среднем каждый второй кадр пропускается.

2. есть местами мусор в виде снега и цветных кластеров (показаны красными стрелочками)

3. сам модуль камеры на такой скорости оказалось полным разочарованием: мутная картинка, и шумов много т.к. ISO задран к небесам.

Использованные ресурсы чипа:

блочной BRAM памяти больше всего ушло на буфер для одного кадра.

Ушло примерно 200 часов моего времени на разработку, из них 150 на видео проц (raw --> rgb).

Вывод:

Не делайте так! Не надо пытаться ардуино-проводками подключать такие быстрые (свыше 30 МГц и многобитные интерфейсы). Именно поэтому профессионалы порой недолюбливают ардуинщиков за такие дикие сопли с ардуино-проводками.

А отладить камеру и ip-корку (аппаратная либа) видеопроца я всё-таки смог. Благо сам алгоритм разработал и верифицировал формально и математически, а на FPGA только проверил, что оно в принципе работает и понял что надо копать в сторону само синхронных синфазных LVDS гигабитных интерфейсов без тактовой и всего этого замороча с шумами.

На этом всё, вот в завершение фотка с топологией чипа (светлосиним заюзанные аппаратные ячейки), зачем? незнай, просто красивый город как из сим-сити вышел.