Оказывается Ookla по-тихому выкатила терминальную версию Speedtest (работает на макбуке, убунту, редхате и даже на Raspberry Pi 😱).

На контрасте с веб-версией есть такой занимательный (и полезный в диагностике) параметр как Packet Loss.

PS: с моим интернетом явно что-то не так 😬
@embedoka

DIY ADAS (advanced driver assistance system)

Изобилие опенсорца, работающего на железе класса Jetson Nano и позволяющего реализовать базовый функционал ADAS (forward collision warning, lane departure warning, traffic sign recognition and overspeed warning) и наличие огромного количества предобученных моделей для ADAS вселяет оптимизм в том, что это реализуемо в рамках DIY как ретрофит.

Только вот что печалит: доступность дешевых камер только класса Raspberry Pi. Если можно было бы помечтать, то я бы хотел найти проект реверс-инжиниринга DVR (какого-нить массового зяоми, например) со специальной матрицей, спроектированной под авторегистраторы и соответствующим процессором обработки (обеспечивающих достойный ДД и резкость картинки). Т.о. идея состоит в том, чтобы каким-то образом забирать с DVR уже обработанную "красивую" картинку и пихать её в нейронки Jetson Nano.

Самый очевидный способ вытащить это из DVR - стримить по WiFi сразу в h264/h265/AV1, на Jetsonе аппаратно распаковывать и процессить. Сомнения два:
▫️ не загнётся ли на DVR чип WiFi от непрерывного стриминга (врядли он на это рассчитан был - возможны периодические отвалы из-за перегрева
▫️latency этого всего мероприятия (а именно WiFi-стека помноженного на 2). В этом смысле есть специализированный WiFi - вживую не видел, но вероятно это чипы на базе Broadcom'a (Apple в своих спеках на CarPlay приводит требования к latency WiFi - следовательно на практике такого достичь тоже возможно).

Неочевидные способы получения стрима с существующих DVR требуют реверс-инжиниринга и хирургии. Притом, что забирать сырой поток с матрицы по MIPI не так интересно - там как раз прелесть в связке CMOS sensor + SoC, которая делает нужный процессинг (и управление матрицей, что немаловажно).

Гипотетически, можно пробовать хачить прошивку DVR (по аналогии как это делают, например для IP CAM на базе HiSilicon), не попадались ли кому такие проекты?!

@embedoka

DIY ADAS part II

Поковырял я тут модельки от 70mai (саббренд зяоми): на сайте комиссии FCC можно посмотреть на внутренности модель1 и модель2 (наиболее массовые dashcam). Для вайфай там используется RTL8189FTV (802.11bgn SDIO Network Interface). К нему есть инструкция по заведению на линуксе.

Варианты:
▫️ делаем (на FPGA?) эмуляцию RTL8189FTV - т.е. ответного SDIO девайса и с минимальной задержкой получаем пакеты, разжимаем и скармливаем в инференс (при условии известного протокола стриминга по вайфай)
▫️У модели2 на фото видно маркировку процессора HiSilicon Hi3556-V100 (там, кстати, есть и USB и даже PCI-E) и память типа NOR - собственно идея поковыряться с прошивкой, чтобы альтернативным способом стрим выводить - например на слот uSD карты.

Что думаете, парни?
Какой вариант более жизнеспособный?

@embedoka

Hi3556-V100 HD Mobile Camera SoC

ну это прям топчик! я не знал, что так можно :)

AV1 вышел настолько чудовищно-монстроузным (особенно для кодирования), что гугл сделал СБИС для ютуба (оптимизация и ускорение обработки загружаемого видео). Вот уж действительно кому своя ноша не тянет.

@embedoka

Организаторы конференции FPGA-Systems 2021.1, на которой в прошедшую субботу я выступил с докладом "про крипту", выложили запись выступления и слайды доклада.

Тем кто присутствовал или смотрел онлайн - надеюсь доклад был полезен, c удовольствием приму обратную связь в ключе что можно было бы сделать лучше (надеюсь это не моё последнее выступление по FPGASIC).

Если кто-то не смог присутствовать или посмотреть онлайн трансляцию - это можно сделать сейчас, задать вопросы по технической стороне можно в комментариях к этой записи (только, пожалуйста, не провокационные 🙏🏻).

@embedoka

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

Вот замечательный пример симбиоза двух технологий, которые еще лет 10 назад выглядели бы как из фантастического рассказа:
▫️adaptive embeddable FPGA
▫️open ISA for expandable CPU core

Ребята замутили такую крутую штуку как расширение набора инструкций SoC на базе RISC-V за счёт встраивания реконфигурируемой области с eFPGA (просто взрыв мозга от крутости идеи)!!

Замысел грандиозен, но и реализация должна быть под стать (быть не менее грандиозной), ведь она тянет за собой не только статичную поддержку со стороны тулчейна, но и динамическую - ведь налету можно залить новую схему в ПЛИС и это будет "уже совсем другой RISC-V".

@embedoka

PS: к слову сказать нечто похожее у меня тоже возникало в форме идеи-предложения при участии в проектировании SoC на базе RISC-V: на интерфейс CPU к ускорителю подключать не фиксированную логику, а eFPGA от FlexLogix (тулчейн не задевается) + небольшой кусок eFPGA на внешние пины для обеспечения создания периферийных интерфейсов не существующих на сегодняшний момент либо если требования к ним не могут быть сформированы на этапе разработки SoC.

Есть отдельный вид RTL-кода:
это код написанный настолько нечеловекопонятно, что выглядит будто он сгенерён машиной:

1) без комментариев
2) минимум поведенческого описания
3) больше похож на нетлист
4) максимально неинформативные имена сигналов и сущностей

На гитхаб такое часто встречается, увы.

У меня появилась идея для линтера, который запускается, например, в пре-коммит хуке:
проверка уровня документированности исходников в зависимости от типа файла:
1) топ-левел RTL (номинальное комментирование)
2) RTL-мясо (метрика с соотношением % кода и комментариев + метрика уровня "распределенности комментариев" по коду)
3) тестбенчи (???)

Под эту задачу наверное хорошо бы зашёл какой-нить ML NLP движок, который был бы обучен на плохих и хороших комментариях, ибо стандартные движки линтеров имеют формальные правила и проверки правил

@embedoka

тогда раскрою мысль более подробно для чего разработчику ПЛИС чрезвычайно желательно иметь несколько версий тулов:

когда работаешь с проектами с утилизацией категории "almost full" и пытаешься сначала догнать, а потом и перегнать конкурентов, то однажды с удивлением обнаруживаешь, что блок А оптимальнее (по ресурсам) синтезируется в туле версии Х, а блок Б в версии У, и начинаешь писать в tcl монстра:

делаем синтез поблочно в апостериори-"оптимальных" версиях, выписываем нетлист, и топ уже собираем из нетлистов в (желательно) последней версии тула.

ЗЫЖ так подозреваю, что в неозвученных специфических кейсах сценарий (для вивдо) также вполне рабочий

@embedoka

Уж не знаю к какой категории стоит отнести данную заметку:

1️⃣ ученый изнасиловал журналиста
2️⃣ больше хайпа богам хайпа!
3️⃣ слабаки! забыли такие ингредиенты как блокчейн и ML!
4️⃣ чего прицепился - люди делают что-то полезное!
5️⃣ мы просто глупцы и неспособны постичь того, что реально необходимо для развития беспилотников на текущем этапе 🤷‍♂️

источник
@embedoka

DIY chip for $10k

Теперь на Efabless появилась возможность делать чипы по SkyWater 130нм без требования опенсорсить дизайн. Честно говоря не знаю насколько ценник дешевле/дороже TSMC 130нм через MPW Европрактики.

Что предлагают за 10 000 долларов?
10mm^2 и 100 QFN или 300 WCSP чипов
(WCSP можно увеличить до 1000шт, доплатив $20 за чип).

Кстати, в заметке интересный термин: TaaS - Technology as a Service.

@embedoka