FPGA плата моей мечты

Собственно, а чего хотелось бы от FPGA платы?
Помимо возможности доступа к максимуму ресурсов I/O и стандартизированным портам расширения периферии?

Также важным пунктом является наличие набортного JTAG-адаптера и USB-to-UART, а если этим UART (через вспомогательные линии) можно учинять ресет платы (всей или только FPGA-части) - то разработчик такой платы сразу получит статус "золотые руки" от @EmbeDoka (Mojo V3 была очень близка к этому идеалу)

Пожалуй, это всё, с той лишь оговоркой, что стандарт расширения периферии должен быть "дешевым" и "удобным", т.е. всякие FMC и SYZYGY отпадают сразу. Под удобством тут понимается возможность подключения NAND FLASH или какого-нить гипотетического FT601 без каких-либо проблем и велосипедостроения: здесь, увы, отваливается и PMOD.

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

PS: по поводу таких вещей как PCI-E и в целом о доступе к MGT трансиверам на тех чипах, где они имеются, вот такая мега-идея: выводим на USB3/USB-C коннекторы (в них, если надо, и для входного диф.клока найдутся пара лишних линий), а дальше хоть майнеровскими райзерами в хост на PCI-E прокидываем.

Регулярная рубрика "Github"

Как уже писал ранее есть прекрасная фича в виде фильтра по языку, которую как оказалось можно использовать в глобальном поиске к т.н. "топикам", например, для поиска реализаций шифра AES на систем-верилог, сработает такой запрос:

https://github.com/topics/aes?l=systemverilog

paranoid_mode_on

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

Первыми ласточками был спец.грим/рисунки на лице с целью обмануть уже обученную нейронку. Сегодня новый виток борьбы - инструментарий, незаметно модифицирующий изображения лиц для обучения, защищая персоналии от "заноса в базу".

Сам метод использует феномен "состязательных примеров", когда несущественные изменения входных данных могут привести к кардинальным изменениям логики классификации. В настоящее время феномен "состязательных примеров" является одной из главных нерешённых проблем в системах машинного обучения. Конечно, рано или поздно научатся делать "правильный" препроцессинг перед обучением и вычищать эти искажения, а пока этот метод претендует на то, чтобы встроить его на уровне ОС в каждый смартфон, чтобы то, что из смартфона разлетается по сетям нельзя было использовать во вред владельцу. Либо компромиссный вариант - встраивание алгоритма на уровне приложения (тот же телеграм самовольно процессит наши картинки).

В общем, наблюдаем дальше за этой увлекательной битвой, в удивительное время живём!

Об утечке 20ГБ из Интел

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

И это не только про Интел МЕ/АМТ и выпиливание из него "недокументированных" возможностей и добавление интересных фич, но и про то, что железо может стать ближе к народу.

Например, я жажду мельчайших подробностей и технических деталей про такую технологию как CNVi: c некоторых пор, выпускаемые интелом карточки формата NGFF для WiFi+BT работают не по классическим PCIE+USB, а по некоему интерфейсу CNVi (и работают с ограниченным числом чипсетов интел).

Об Intel CNVi

Вся изящность идеи - в её простоте. А именно осуществить максимальную развязку RF PHY и baseband обработки, т.о. на CNVi-сompatible карточке остаются DDC/DUC для работы на нулевой ПЧ, синтезаторы и ADC/DAC, а всё протоколо-зависимое процессится на хосте, для связи с хостом (передачи потоков с/на ADC/DAC) используется низкопотребляющий MIPI DPHY. Для управления используются два UART-подобных интерфейса, работающие на скоростях до ~100Мбит/с.

Увы, это всё что на данный момент известно о технологии CNVi, есть еще некоторые обрывочные упоминания в линуксе, но недостаточные для полноценной картины.

Самые прозорливые уже догадались к чему я веду: CNVi - готовый и дешевый backend для SDR с широченной полосой по входу.

CNVi as SDR

Конечно по диапазону перестройки CNVi-карточка не сможет конкурировать с решениями на базе LimeMicrosystem или AD9361/AD9363, но:

1. 500 рублей - это 500 рублей

2. Никакой пайки RF-тракта вручную, для подключения к ПЛИС используем стандартный M.2/NGFF-разъём, в крайнем случае понадобится простая переходная плата, чтобы MIPI-сигналы завелись в FPGA на правильные ножки

3. Необходимо натурно исследовать диапазоны перестройки ФАПЧ конкретных карточек CNVi (R820T из RTLSDR "разгонялась" до 1700МГц с деградацией шумовых характеристик, при декларируемых в документации 900МГц), также скорее всего потребуется выпаять/замкнуть полосовые фильтры по RF при их наличии.

На одной картинке сразу две тенденции в FPGA:

1. Драматическое падение качества документации: "я не знаю как объяснить как это использовать, но нате вам пример - попробуйте просто добавлять в него свою логику работы, стараясь не сломать работу фичи"

2. Это выдержка из Xilinx РG156 на ~340 страниц, помимо этого есть еще отдельные документы о конфигурации и частичной реконфигурации, в которых тем не менее нет нужных подробностей - FPGA усложняются -> усложняется документация

PS: какой численностью команда необходима чтобы работать с новыми Versal - страшно представить, но уж точно времена FPGA энтузиастов-одиночек проходят..

Проект sed выходного дня

Наконец дошли руки сделать то, что так не хватало в ежедневном рутинном разглядывании серых логов - разукрашку логов вивадо, работающую в рантайм.
Перепробовав некоторое количество вариантов (ccze, awk, multitail), остановился на sed.

Возможности:
◦ Обработка стандартных типов сообщений Вивадо: INFO, WARNING, CRITICAL, ERROR
◦ Подсвечивание вех сборки
◦ Выделение таблиц-репортов

URL:
◦ http://idoka.ru/blog/posts/colorize-fpga-vivado-log/
◦ https://github.com/iDoka/eda-noscripts/blob/master/colorize.log

PS: приветствуются адаптации к другим тулам