Skip to main content

Сдвиг парадигмы «блогерства»

Какое-то время назад осознал, что нет времени на посты в блоге, но в то же время формат постов в твиттере (140 знаков) не всегда позволяет раскрыть полностью и донести инженерную мысль.

Захотелось попробовать экспериментальный для меня формат авторского канала в телеграм.

Впредь новые записи и апдейты здесь:  ссылка и альтернативная ссылка

Читать далее

Каналы полезной информации и дайджест мира ASIC/FPGA

Аннотация

Для тех кто давно в теме FPG/A/SIC или просто по работе/хобби связан с проектированием на ПЛИС (или СБИС) удобно под рукой иметь агрегатор полезностей и советов, чем тратить время на самостоятельный сёрфинг по LinkedIn/Twitter/WikiChip/SemiWiki/etc..

В качестве инициативы, сделали с  единомышленниками пару каналов для агрегации интересных проектов и полезных советов (из собственной проектной практики и из сети). Детали о каналах ниже.

  

IP-cores

Пополняемая коллекция СФ-блоков на языках Verilog/VHDL для реальзации на ПЛИС/СБИС. Подавляющее большинство блоков — опенсорсные и допускающие свободное использование. Помимо СФ-блоков периферии и интерфейсов есть процессорные ядра (розлива таких пивзаводов как MIPSopen, RISC-V, etc) а также отдельный класс библиотек примитивов (в том числе для упрощения кросдоменных переходов) и алгоритмические ядра (ЦОС, нахождение и коррекция ошибок с CRC/ECC).

Что уже можно найти в канале по периферийным IP-ядрам:

DisplayPort, HDMI, DVI, VGA, HMC (Hybrid Memory Cube), DDR3, PCI-E + DMA, NoC, Interconnect, FX2LP (CY7C68013), FX3, FT2232, AXI4, PonyLink, HyperBUSUSB2 (ULPI), USB3 (PIPE), RNG, TRNG, MIPI DSI, MIPI CSI, HyperRAM, will be continue…

Язык канала — английский, организован удобный поиск по #хештегам (язык, тип СФ-блока/периферии, вендор ПЛИС (если применимо)).

 

Адресtelegram:ipcores

Альтернативный адресt.me/ipcores

 

FPG[A]SIC

 Основная направленность канала — Design Automation, т.е. отказ от GUI в пользу скриптов для автоматизации рутинных действий, 

Помимо этого в канале сейчас можно найти полезную информацию по таким темам как: полезные советы по EDA-инструментарию (Cadence/Synopsys, Vivado, Quartus, Yosys, ICEstorm, Verilator, Icarus Verilog, etc), примеры скриптов для автоматизации EDA, трюки по использованию специфичных tcl-команд, недокументированные/малоизвестные возможности тулов, HLS (High level synthesis) инструментарий с открытыми исходными кодами, NN/ML-фрейворки (нейросети и машинное обучение) для ПЛИС, скрипты автоматической сборки datasheets, подходы к использованию свободного инструментария формальной верификации, надстройки и плагины HDL для текстовых редакторов и IDE, свободные книги по тематике FPGA и HDL, советы по настройке Lint’еров, тонкости версионирования в git проектов FPGA & ASIC, трюки по сведению таймингов (лучшии выжимки из Ultrafast Methodology), реверсинжиниринг ПЛИС и используемых форматов представления данных (в т.ч. парсинг битстримов), свободные трансляторы Python -> HDL, продвинутые методики BROM/DSP folding/multi-pumping, подходы работы с партишинами и частичной реконфигарацией (partitions and partial recunfiguration), clock conversion and constraining, HDL tips and tricks, example to use DNA-protection, etc.

Язык канала — английский, организован удобный поиск по #хештегам (вендор ПЛИС/EDA, функционал, язык).

 

Адресtelegram:fpgasic 

Альтернативный адресt.me/fpgasic

Читать далее

USB-to-SPI bridge

[WiP] Использование моста USB-to-SPI MCP2210 в Линукс

Введение

   Задача состояла в том, чтобы из под десктопного линукса иметь возможность работать с SPI-интерфейсом внешних чипов, притом желательно это делать стандартным механизмом через устройство /dev/spiХ, причем решить эту задачу максимально беспроблемно без свистопляски с пересбором ядра и дров, а поскольку, если это не SBC (Single Board Computer), а десктопное детище архитектуры x86 без набортного контроллера SPI Master, то от соблазна подобрать что-то из конвертеров SPI-to-USB никуда не деться, а их существует некоторое количество.

Кандидаты USB-to-SPI 

•  CP2130 от Silicon Labs

•  MCP2210 от Микрочипа

•  FT232H от FTDI (или что-то иное подходящее от FTDI) 

   В итоге гонку выиграл MCP2210, хотя под CP2130 тоже имелись какие-то варианты решения:  https://www.silabs.com/documents/public/software/CP2130_SDK_Linux.zip и  https://github.com/Henneberg-Systemdesign/cp2130 .

MCP2210

   Некто Daniel Santos разработал линукс-драйвер для этого моста, базирующийся в то же время на более раннем драйвере https://github.com/MathewKing/mcp2210-linux от Mathew King. На данный момент драйвер умеет отправлять и получать ответы для большинства настроечных команд (настройка параметров шины SPI, управление чипом, и т.д.), чтения/записи пользовательского EEPROM и отправки/приема непосредственно сообщений SPI. Однако надо учитывать, что при работе через спецификацию устройства spidev многие вызовы через ioctl не поддерживаются и захардкожены с помощью функции fake_config().

   Без знания заранее конфигурации платы (схемотехники) с чипом MCP2210 автонастройка SPI невозможна. MCP2210 может быть сконфигурирована при начальном запуске скрипта настройки (индивидуальная настройка каждой линии ввода-вывода), для хранения этих настроек на стороне устройства идеально подходит пользовательский EEPROM размером 256 байт. Система авто-конфига получила название Creek, все настройки за исключением имени драйвера протокола и прочих строковых переменных занимают для хранения 5 байт EEPROM. Минорный функционал настроек реализован через вызовы ioctl из пользовательского окружения.

Установка

Шаг 1

Установка ядра 4.15 (ядро называется kernel-ml, доступно в репозитарии elrepo-kernel) на CentOS 7.

Шаг 2

Сборка и установка драйвера mcp2210 под linux:

 Установка правил UDEV и скрипта, который перепривязывает к конкретному устройству новый драйвер:

 Шаг 3

Тест драйвера:

 Считывание конфига:

 Материалы

Все изменения в udev-rules, создающие девайс, доступный из-под пользователя, доступны в моём форке: https://github.com/iDoka/mcp2210-linux

Читать далее

GitStats — замечательная статистика для git-репозитория

GitStats

Heikki Hokkanen написал классную штуку — GitStats. Эта утилита снабжает нас человекочитаемой статистикой из репозитория гит. Конечно какую-то статистику можно получить из командной строки, но это не идёт ни в какое сравнение с визуальным представлением в виде пары графиков и диаграмм.

Утилита GitStats использует CSS для для отображения стиля, шагающего в ногу со временем, и позволяет проводить глубокую кастомизацию внешнего вида финальных отчетов. Собственно, предлагаю ознакомиться с моим форком GitStats: https://github.com/iDoka/gitstats/ . К сожалению, большинство форков страдало лишь изменением файла стилей, однако существенная часть информации формируется, используя gnuplot (против которого лично ничего против не имею). Итак, помимо, полюбившихся мне шрифтов (PT family, Oswald, Montserrat) и цветовой гаммы был подвергнут изменениям вывод графиков через gnuplot, а именно:

• заменен тошнотворный красный для графиков на #00D2FF (другой прекрасный кандидат на эту роль: #14D2C8)

• заменен и уменьшен размер шрифта

• для итогового графика применено сглаживание (графика и шрифты)

• автошкалирование чиcел на осях графика: 18000 → 18k

• ..и наверняка что-то сломал в процессе изменений

Использование

В простейшем случае запуск осуществляется как:

 Например, при запуске из корня репозитария, если хотим иметь репорт в doc/gitstats (эту папку можно добавить в .gitignore):

 Кастомные настройки передаются через ключ -с, так например можно передать иное имя проекта (по умолчанию берется имя репо) и свой файл стилей, например:

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

 

CLI «GitStats»

Daniel Kvist также пользуется GitStats, но настолько сильно любит командную строку, что написал пару замечательных алиасов для гит, для вывода разукрашенной истории коммитов в консоль. Для этого в файл ~/.gitconfig необходимо добавить следующую секцию:

 Для использования: набрать в консоли git lg или git lg2

 

Читать далее

Не все полиномы одинаково полезны или почему CRC32 давно не тот

Терминология

Часто под CRC подразумевают две разные вещи:

  • Cyclic Redundancy Code — применяется в помехоустойчивом кодировании для обнаружения и исправления ошибок

  • Cyclic Redundancy Check — использование циклических кодов в качестве хэш-функции для проверки целостности принимаемых даных

Поскольку большинство современных проводных каналов связи обладают достаточными характеристиками для поддержания хорошего BER, то зачастую достаточно убедиться в том, что сообщение не искажено во время прохождения по внешнему каналу, а для этого достаточно использования циклических кодов в качестве контрольных сумм (перезапрос «бракованного» кадра как правило  в большинстве интерфейсов происходит на более высоком протокольном уровне). 

Критерии качества

Качественным критерием оценки контрольной суммы является вероятность возникновения коллизии — т.е. необнаружения искажения данных: подразумевается искажение данных таким образом, что подсчитанный CRC (от искаженных данных) совпадет с референсным CRC (либо одновременно исказятся и CRC и данные в канале передачи). Причём, чем длиннее сообщение, тем больше вероятность появления коллизии — больше возможностей для того чтобы «звёзды совпали», поэтому часто выбор длины полинома для подсчёта CRC соотносят с размером пакета, к которому этот CRC применяют. 

Для этого ввели такой термин как Расстояние Хэмминга (Hamming Distance, HD) или Метрика Минковского — она служит некоей метрикой различности двух объектов (в нашем случае — двух пакетов: переданного и принятого). В терминах CRC, HD — это минимально возможное число бит сообщения, инверсия которых может привести к коллизии (необнаружению повреждения сообщения). Так, например в стандарте CAN (от Bosch GmbH) используемый полином вкупе с длиной сообщений обеспечивает HD=6, что означает, что не существует никаких комбинаций 1-, 2-, 3-, 4- и 5-битных ошибок (здесь ошибка — инверсия передаваемого бита в сообщении), которые не были бы необнаруживаемыми, но существует как минимум одна комбинация 6-ти битной ошибки, которую невозможно обнаружить с помощью используемого полинома CRC.

Также необходимо отметить, что на правильность выбора полинома для того или иного протокола (и получения конкретного значения HD) зависит и скорость передачи информации — характер ошибок и их динамика может сильно меняться (например, за счет увеличения скорости передачи — появляться пачки ошибок), вот для примера какие цифры фигурируют в знакомых мне протоколах:

Связь скорости передачи, длины сообщения и выбора степени полинома CRC

Дань традициям 

В большинстве стандартизированных протоколов используются контрольные суммы CRC, однако часто используемые в них стандартизованные полиномы не являются самыми эффективными в терминах эффективного расстояния Хэмминга (HD), в [1] затрагивается вопрос на всю глубину: большинство стандартов в плане обнаружения ошибок не столь эффективны, как могли бы быть, из-за того, что используется полином для контрольной суммы, однажды выбранный на этапе утверждения стандарта. 

Наиболее яркий пример — стандарт на Ethernet-пакеты IEEE 802.3, который использует самый популярный 32-разрядный полином, но в то же время, использование иных 32-разрядных полиномов (CRC32C, CRC32K, etc) позволило бы достичь лучших показателей (в терминах HD) в различных диапазонах длин передаваемых сообщений, посмотрим на таблицу:

CRC32 hamming distance comparison

Видно, что стандартный полином CRC32 на пакетах свыше 372 байт имеет  HD=4, в то время как CRC32K на пакетах до 2045 байт имеет HD=6, А если оперировать Jumbo-фреймами, то CRC32C на пакетах до 16 КБайт обеспечивает HD=4 (в то время как стандартный CRC32 обеспечивает HD=4 при длине пакета до 11,5 КБайт). Т.о. видно, что если есть возможность отойти от стандарта (например, создание своего полностью кастомного оборудования для стандартных протоколов, которое работает только во внутренней собственной инфраструктуре) следует воспользоваться этой возможностью — в случае стандартного Ethernet можно сделать модификацию под какой-нибудь Industrial Ethernet с CRC32C/CRC32K, снизив вероятность необнаружения ошибки или увеличив размер пакета по отношению к стандартному, не снижая при этом имеющегося HD.

Мораль

Не только при конструировании новых протоколов обмена, но и при реализации стандартных полезно сверяться прежде всего не со стандартами, а с работами, подобными Best CRC Polynomials, особенно если специфике вашей работы свойственно выжимать максимум из возможного и где цена необнаружения ошибки высока  (Aerospace/Aircraft, Industrial, Automotive). 

Следующим призывом будет там где это возможно писать на верилоге модули CRC, конфигурируемые не параметрами, а в процессе работы (on-the-fly). Это легко реализуется (в первую очередь — с минимальными аппаратными затратами), если вычислять CRC через последовательную реализацию (LFSR), а не по 4/8/N-бит за такт.

Тест на внимательность

В заголовке статьи использована картинка с LFSR, реализующим 24-битный CRC на verilog (из BLE), а не CRC32 из IEEE 802.3 как могло показаться.

Литература

  1. Philip Koopman, Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks

  2. Блейхут Ричард. Теория и практика кодов, контролирующих ошибки [Theory and Practice of Error Control Codes] — М.: Мир, 1986.

  3. Richard W. Hamming. Error-detecting and error-correcting codes, Bell System Technical Journal 29(2):147-160, 1950. 

Читать далее

Эффективное оборудование для майнинга коинов или не так страшен ASIC: особенности реализации

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

Классифицируем особенности реализации ASIC для майнинга биткоина либо аналогичных криптовалют на несколько категорий (заранее отмечу, что особенности реализации призваны в том или ином виде оптимизировать себестоимость майнинг-чипов и по максимуму поднять удельную (на чип) производительность):

Архитектура

Поскольку современные фермы должны быть масштабируемы, то всегда предусмотрена возможность каскадирования в daisy chain  нескольких сотен/тысяч чипов (наиболее распространенный интерфейс для внешних коммуникаций — SPI).

RTL-кодирование

При разработке ASIC-майнеров часто отказываются от верилог-кодирования, отдают предпочтение новомодным метросексуальным JS-фреймворкам, поэтому этот раздел под NDA пустой.

Физический дизайн и топология

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

Список используемых ухищрений:

  • Использование современного техпроцесса, обеспечивающего баланс требований по предельному быстродействию ячеек и их динамическому потреблению (TSMC HPP/HPM/HPC+)  — утечки в статике на числодробилке работающей 24/7 мало кого волнуют
  • Активное использование технологии DVS (Dynamic Voltage Scaling) для того чтобы у одного и того же ASIC было два профиля тепловыделения: режим максимальной производительности (т.н. турбо) для использования с активным охлаждением и стандартный режим производительности для пассивного охлаждения. Так или иначе это маркетинговые названия не отражающие физическую суть, а суть в том, что turbo — это может быть работа на пониженном Vcore (например, 0.85В вместо стандартных 0.9В для TSMC 28nm), а standart — работа на сверхнизком Vcore (0.78В для  TSMC 28нм). Сделано это с целью уложиться в TDP используемых корпусов
  • В каких-то экзотических реализациях отказываются от тактовых деревьев и синхронного дизайна в целях уменьшения тепловыделения/потребления
  • Из аналоговых блоков используют разве что ФАПЧ для получения высокой частоты тактирования внутри кристалла. Чипы майнера, выполненные по современным технологиям 40..16нм работают на частотах от 1 ГГц и выше, из-за проблем с целостностью цифрового сигнала такую частоту сложно завести на чип снаружи. Пожалуй, в рамках оптимизации стоимости это чуть ли не единственный аналоговый блок, необходимый для дизайна ASIC-майнера.

Корпусирование

Тут две основные тенденции: максимальное удешевление корпусирования и эффективный отвод мощности от кристалла, каким образом этого достигают?

WireBond

Небольшое число ног и отсутствие высокоскоростных интерфейсов позволяют использовать доступную и недорогую разварку кристалла по технологии WireBond.

WireBond-кристалл, разваренный на массивные lane для ввода питания ядра и отвода тепла

Эффективный отвод мощности

Минимальное число ног и тут играет на руку, также как и использование последовательных интерфейсов для коммуникации с фабрикой хеш-блоков. Активно использующиеся массивные lane для ввода питания ядра и земли (для подвода к чипу большого тока с низким падением напряжения) служат и для второй функции: большой пятак земли выполняет еще и важную функцию отвода тепла от кристалла (эти решения очень напомнили мне ноу-хау последного десятилетия от InternationalRectifier  в их SMD-корпусостроении MOSFET-ов).

 Большой пятак земли и питания ядра должет быть запаян на соответствующие специально спроектированные полигоны для отвода тепла от кристалла

 

Проектирование на уровне системы и иные ухищрения

 Поскольку чип представляет собой достаточно регулярную структуру фабрики блоков по расчету хешсум, то часто разработчики вносят в схему возможность байпаса произвольных блоков и механизм BIST (самотестирования). Это преследует сразу две DFT-цели:

  • Экономия на производственном тестировании (поскольку почти всю площадь кристалла занимают блоки расчета хешсумм)
  • Увеличение выхода годных (бракованные по результатам самотеста блоки расчета хешсум не используются в работе — в принципе это практически та же самая техника, что используется при тестировании и отбраковке больших массивов накристальной SRAM, только тут еще и на eFuse съэкономили)

Выводы

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

Читать далее

Автоматическое уведомление о появлении радиодеталей на Digikey

Описание проблемы

Понадобилось тут как-то отслеживать появление некоторых позиций на Digikey (в эту же группу входят всякие кастомные разъёмчики от SAMTEC, например, под мезонин FMC) и в какой-то момент это надоело делать, открывая периодически сохраненную ссылку, а уж коль скоро не пристало последние годы заниматься Design Automation, то и тут пришлось в очередной раз сесть за «клавикорд».

ТЗ на проблему и черновик решения

NB!  Несмотря на богатый API Digikey [https://api-portal.digikey.com/] с удобным интерфейсом и кучей примеров начиная с bash & php и заканчивая Go & Swift [https://api-portal.digikey.com/node/3287], в первую очередь задал себе цель показать мощь и изящество инструментов для DOM-парсинга страниц и принципа «каждой задаче — свой инструмент».

Для решения поставленной задачи используем так ненавистный ЕЕ-сообществом и так любимый мной за быстрый старт (минимум кодинга) и множество примеров интерпретируемый язык PHP. Помимо самого интерпретатора нам понадобится библиотека PHP Simple HTML DOM Parser[http://simplehtmldom.sourceforge.net/], которая распарсит любой HTML с фиксированной структурой легко и непринуждённо, впрочем понадобится она номинально, поскольку устанавливать самому ничего не надо — она скачивается автоматически из мейкфайла, если отсутствует в директории запуска скрипта. 

На входе скрипта должны быть партнамберы электронных компонентов, которые нам надо периодически пробивать на наличие у поставщика, но мне удобнее давать конкретную ссылку, поэтому в файле partnumber.list будет просто список URL-адресов наблюдаемых компонентов в формате: каждый URL с новой строки (лишние пробелы в начале и в конце строк удаляются внутри скрипта).

На выходе скрипта желаем получить уведомление о появлении у поставщика компонентов из списка в partnumber.list в удобном для нас формате:

  • в виде письма на email
  • в виде сообщения в телеграм-клиенте
  • в виде push-уведомления на смартфоне, например через ранее обозреваемое приложение PushOver: http://idoka.ru/pushover-notifications-on-gadgets/

В самом теле сообщения хотим видеть что за компонент (партнамбер) появился, его количество в наличии и стоимость (в US$, для кого интересно в рублях — можно запрашивать через API текущий курс и пересчитывать налету).

Сам скрипт будем пускать по cron с подходящим нам периодом.

Подробности решения

Тут всё достаточно просто и лаконично: парсим файл со ссылками и запускаем цикл foreach. Далее, получив страницу через curl, используем всю мощь Simple HTML DOM Parser, а именно, нам надо найти в исходнике страницы якоря следующих элементов: партнамбер, количество в стоке и цена за 1 шт.

Партнамбер

Партнамбер можно вытянуть из нескольких мест файла, остановимся на одном, а именно:

Из этого кода следует, что нам надо сообщить simplehtmldom, что надо извлечь партнамбер из уникального для текущей страницы сочетания: содержимое тега h1, у которого атрибут  itemprop установлен в значении «model»:

Количество

В нотации simplehtmldom запишем действие «найти содержимое тега span с id=dkQty»: 

Цена

На языке simplehtmldom это означает найти содержимое тега span с якорем itemprop в значении price: 

 Также перед этим не лишним было убедиться что это единственный элемент на странице (обычно присутствуют оптовые цены за 10, 25, 50, 250шт, но у них другие якоря).

Итог работы скрипта

Возможные альтернативные применения

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

  • динамика изменения цены на компонент
  • отслеживание популярности компонента через отслеживание изменения количества в стоке
  • инверсная задача: отслеживание опустошения складских запасов (чтобы те, кто запасся заранее знали когда из под полы можно начать приторговывать. #лопата #смеяться #шутка)

Скачать

 

Листинг исходника

https://github.com/iDoka/digikey-cool-stuff/blob/master/digikey-stock-watcher.php

 

 

 

Читать далее