Skip to main content

Каналы полезной информации и дайджест мира 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

Альтернативный адресipcores [1] | ipcores [2]

 

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 

Альтернативный адресfpgasic [1] | fpgasic [2]

читать...

Не все полиномы одинаково полезны или почему 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. 

читать...

Установка и использование Icarus Verilog в линукс на примере CentOS 7

Установка iVerilog

С последним икарусом пришлось немного попотеть, как обычно бывает, в репах дистрибутива древняя как еда мамонта версия, а сборка из исходников падает из-за старого gcc, если вкратце — надо установить последний devtoolset и и зависимости в лице gperf:

 Теперь  можем собирать икарус с верилогом, особенности, после клонирования переключаемся на метку версии v10_1, при сборке передаём компиляторы опции, позволяющие оптимизировать код под инструкции конкретного процессора, на котором идёт сборка, ну и затем собираем сборку в четыре потока:

Установка просмотрщика дампа GTKwave 

 iVerilog установлен. Докучи поставим GTKwave для просмотра дампов, гененируемых iVerilog’ом, тут всё просто — ставим из репо EPEL:

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

Соорудим конфиг файл, которым будем настраивать окружение CLI на запуск и работу с iverilog:

Настраиваем окружение командой (обратите внимание на пробел после точки):

Компилируем исходники (здесь и далее — куски из мейкфайла), указывая в конце командной строки список из RTL & TB:

  • -g2005-sv — указываем какой версии верилога соответствуют исходники
  •  -Irtl — перечисляем инклюд-директории
  •  -D$(DEFINE) — передаем дефайны
  • -s tb — указываем имя топ-модуля
  • -o $(PROJECT).vvp — задаём путь и имя выходного файла

Запускаем моделирование (lxt2 — рекомендованный формат записи дампа, он прогрессивный и со сжатием):

Работа с дампом

Открываем записанный дамп в GTKwave:

gtkw — это формат txt-подобного конфига для GTKwave (SaveFile в терминах GTKwave), его первичный вид можно получить открыв дамп и настроив GTKwave по своему вкусу, а потом дав команду «Write Save File» из меню.

Пример открытого дампа с преднастроенным файлом gtkw:

GOST-R34.12-2015 L-stage

 

Пример файла gtkw:

Также GTKwave поддерживает tcl-подобные скрипты, но нормальных гайдов по нему не попадалось, а жаль — думаю там более вменяемый синтаксис (памятуя о tcl-скриптах для модельсима).

читать...

[opensource]: Мои скрипты для EDA/CAE/CAD

Приведенное ниже — описание к коллекции моих EDA-скриптов для работы с тулами для ASIC и FPGA

Конвертор из UCF в XDC

Конвертирует для ПЛИС Xilinx привязки ножек и стандартов из формата ucf (Xilinx ISE) в новый формат xdc (Xilinx Vivado). Использование:

В текущей директории появится файл FILENAME.xdc.

Пример входного ucf-файла

Пример сгенеренного утилитой xdc-файла

(далее…)

читать...

[opensource]: Аппаратный криптодвижок ГОСТ 28147-89

Что такое движок по ГОСТ 28147-89?

Реализация на верилоге советсткого стандарта симметричного шифрования, который был рассекречен в 1989г. В стандарте применяется шифрование с 256-битным ключом над 64-битным блоком данных за 32 раунда.

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

Возможности

  • RTL и тесты написаны на верилоге
  • Реализация шифровщика/дешифровщика как единого блока
  • Поддержка режима EBC
  • Реализация алгоритма ГОСТ 28147-89 оптимизированная по использованию минимума ресурсов
  • Реализация криптования/декриптования 1 блока за 32 такта
  • Поддержка следующих типов S-box (имена даны в соответствии с RFC4357):
    • id-GostR3411-94-TestParamSet
    • id-Gost28147-89-CryptoPro-A-ParamSet
    • id-Gost28147-89-CryptoPro-B-ParamSet
    • id-Gost28147-89-CryptoPro-C-ParamSet
    • id-Gost28147-89-CryptoPro-D-ParamSet
    • id-tc26-gost-28147-param-Z
    • также поддерживается S-box из ГОСТ Р34.11-94 из CryptoPro

(далее…)

читать...

[WiP][opensource]: Аппаратный криптодвижок ГОСТ P34.12-2015 aka «Кузнечик»

Что такое аппаратный Кузнечик (ГОСТ P34.12-2015)?

Реализация на верилоге свежего российского крипто-стандарта, который (почему-то?) получил второе имя «Кузнечик». О чём стандарт: симметричное шифрование, 256-битный ключ, 128-битный блок данных, 10 раундов.

 

Текущий статус

Написана и проверена поведенческая верилог-модель стадий S и R.

Особенности

  • Verilog HDL для RTL и тестовых стимулов
  • Реализация шифровщика/дешифровщика как единого блока
  • Поддержка режима EBC

Планируемые доработки

  • Поддержка следующих режимов поточного шифрования: CBC, CFB, OFB (возможно CTR)
  • Добавление AXI4-Stream для потокового шифрования
  • Добавление параллельной шины для конфигурации/статуса (АМВА АРВ-like?) в составе СнК
  • Возможность предзагрузки рассчитанного для всех раундов ключа
  • Параллельная сверка работы с моделью на Си (механизм DPI)
  • Различные реализации: критерии «минимальная площадь» и «максимальная производительность»

(далее…)

читать...

Установка Xilinx ISE на линукс на примере CentOS 7

Дано

  • HW: 16GB RAM + 256GB SSD
  • CentOS 7
  • ISE 14.7

Установка

  1. Отключаем SElinux
  2. Распаковываем:  tar -xf xxx.tar
  3. Ставим в /soft/Xilinx, запуская  ./xsetup

Драйвера

Настройка

(далее…)

читать...