FPGA *

Я продолжаю описывать создание I2C-контроллера на Verilog. В предыдущих статьях мы протестировали ядро контроллера который выполняет атомарные функции работы с шиной в т.ч. в пограничных ситуациях типа clock stretching и пр. Теперь необходимо разработать управляющий контроллер для этого ядра, чтобы выполнять необходимые нам функции, но уже на следующем уровне абстракции и стать на шаг ближе к нашей цели - к рабочему коду I2C Controller который мы будем использовать с EEPROM и OLED SSD1306, а далее все это переиспользуем в Zynq и подключим к Linux. 

Всем заинтересовавшимся - добро пожаловать под кат!

Регулярный слет сообщества FPGA-инженеров и им причастных пройдет 26 мая в 19 часов в формате онлайн-трансляции. В программе вечера пять докладов: о Yosys, SystemRDL, Edge AI и анализе вейвформ с LLM. Подробности о темах и спикерах — под катом. А регистрация — по ссылке.

Если вам интересно как выглядит работа Vivado на одноядерном ARM процессоре с частотой 1.8 ГГц, и 2 Гб ОЗУ, то я вам это покажу, и расскажу, как я запустил и успешно прошил плату (ДА! Собрал проект и прошил).

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

Я задал вопрос про язык описания и верификации аппаратуры SystemVerilog. На это кандидат сказал, что он еще не освоил SystemVerilog, вписал его в резюме на будущее, но вообще использовал Verilog-95 и немного Verilog-2001.

“Нет проблем”, - сказал я и задал вопрос по Verilog-95: “приведите примеры гонок (race conditions) при использовании верилога”.

На это кандидат сказал, что вообще его опыт был больше связан с VHDL. “Блин, как он выкрутился” - подумал я, ведь в VHDL нет гонок как в верилоге из-за дизайна языка.

По результатам написания прошлой статьи у нас получился объемный модуль для реализации функций низкоуровневого управления шиной I2C, который формирует управление линиями SCL/SDA, поддерживает мониторинг шины, ведет передачу и прием данных. В этой статье я предлагаю организовать полноценное вдумчивое тестирование всего что получилось.

Всем заинтересованным - добро пожаловать под кат! 🙂

В этой статье я хочу рассказать о том, как я запускал собственную базовую станцию мобильной связи (4G и 2G) при помощи относительно дешевого SDR-трансивера.

Наконец-то нашлось вдохновение и время вернуться к старой статье, в которой я изобретал I2C Master Controller, но так и не довел задачу до логического конца. Спустя почти три года много воды утекло, появилось множество возможностей и ряд компетенций и я хотел бы реанимировать решение этой задачи и продолжить рассказ. Перечитав старый материал, я сформулировал обновленную группу задач: переделать I2C Master Controller, снабдив его функциями, которых не было в первой версии, типа clock stretching и burst-режима при этом сопроводив это детальным описанием процесса реализации и объяснением почему были предприняты те или иные действия. После все это воплотить сначала в симуляции, а потом и на реальном железе, с использованием EEPROM и OLED-дисплея SSD1306.

Вобщем, всем неравнодушным к теме цифровой схемотехники, ПЛИС и шине I2C - добро пожаловать под кат! :)

В этой статье дана инструкция для выполнения фазовой синхронизации в FMComms5 от Analog Devices и реализации метода пеленгации, использующего эту функцию. Оценочная плата FMComms5 обеспечивает высокую точность фазовой синхронизации. В этой статье рассказывается, как выровнять фазы двух приемопередатчиков AD9361 с помощью специальной программной библиотеки libad9361, созданной на основе инфраструктуры ввода-вывода libiio. Фазовое выравнивание необходимо для многих радиолокационных систем, таких как пеленгаторы и когерентные системы MIMO.

Исходный код GNURadio, на котором основан этот пример, был изначально разработан доктором Шрикантом Пагадараи и доктором Трэвисом Коллинзом при финансовой поддержке компании Ettus Research [1]. Недавно доктор Коллинз портировал его на платформу FMComms5, добавив документацию. В настоящее время код доступен по адресу github.com/tfcollins/gr-doa в ветке adi. Этот код распространяется по лицензии GPL3. Реализация на FMComms5 обеспечивает такую же производительность, как и предыдущая работа [1]. Технический документ из [1] также был дополнен авторами оригинальной статьи информацией о FMComms5 и стратегии его внедрения.

«Брус-16» — это новая игровая приставка. За полтора месяца мы спроектировали ее архитектуру, а также создали виртуальную машину, компилятор и аппаратную реализацию на FPGA. Специально для Брус-16 написано более 10 игр. Если вам интересны “серьезные” темы системного программирования, компьютерных архитектур и цифровой схемотехники, а также темы “несерьезные” – разработка игр в духе ретро-инди, демосцена и эстетика минимализма, то читайте дальше. Кстати, картинка выше состоит ровно из 64 прямоугольников. Это важно. Впрочем, обо всем по порядку!

Разработчики FPGA часто сталкиваются с необходимостью внедрения в свой проект софт процессора. Когда-то давно мы могли использовать проприетарные Altera NIOS или Xilinx MicroBlase. Но время идет. В последние годы наблюдается устойчивый тренд перехода производителей ПЛИС в сторону поддержки архитектуры RISC-V.

RISC-V это открытая, расширяемая и бесплатная архитектура набора команд (ISA), которая не требует лицензионных отчислений. Оба FPGA вендора Altera и Xilinx уже довольно давно предлагают и активно разрабатывают поддержку RISC-V в своих новых продуктах, теперь это уже софт процессоры NIOS V и MicroBlase V.

Однако, зачем использовать всё ещё проприетарные ядра, если можно использовать Open Source?

В этой статье я сравниваю два Open Source RISC-V микропроцессора:
1) picorv32 от компании YoSys (https://github.com/YosysHQ/picorv32) и
2) scr1 от Syntacore (https://github.com/syntacore/scr1)

Что буду сравнивать? Производительность софт ядер и занимаемые ресурсы в FPGA.
Как правильно сравнить? Использовать единую тестовую программу написанную на языке C, например Dhrystone, и скомпилированную в бинарный файл, или HEX файл и запускаемую в двух архитектурно одинаковых SOC, но с разными ядрами RISC-V.

Я, автор , независимый исследователь, разработчик SCADA системы Gatherlog А так же автор комплекса по разработке Промышленных Контроллеров под названием 3o|||sheet..

Типичный настольный компьютер конца 90-х имел 8-16 мегабайт ОЗУ, работал на частоте 100-300 МГц и потреблял порядка 150 Вт, из которых половина приходилась на монитор. Типичная операционная система тех лет (Windows 98) официально требовала для своей работы 16 мегабайт ОЗУ. Это считалось несколько расточительным по сравнению с Windows 95, которая требовала 4 мегабайта ОЗУ вместе с браузером (и даже глянцевые журналы верстались на компьютерах с 4 мегабайтами ОЗУ, в среде PageMaker 5.0). В те же времена ещё оставались многочисленные пользователи ретро-машин, которые решали все свои задачи, имея от 128 килобайт до 1 мегабайта ОЗУ (математические и бухгалтерские расчёты, работа с текстовыми и графическими документами, переписка в Fido, чаты в BBS, компиляция ПО, трассировка печатных плат, написание курсовых и дипломных работ и разнообразные компьютерные игры).

Современный настольный компьютер имеет 8 и более гигабайт ОЗУ, работает на частоте 3 и более ГГц (4 и более ядер) и потребляет 300 Вт. Современная операционная система Ubuntu 26 официально требует не менее 6 гигабайт ОЗУ и 2 ядер по 2 ГГц [1]. При этом пользовательский функционал практически не расширился. Также известно, что на 2-3 порядка увеличились размеры отдельных программ (например, Microsoft Word, Adobe Photoshop, Adobe Reader, ACDSee, Opera, Nero, Skype и их аналоги) и окружений (Java, .NET, DirectX, OpenGL, причём речь не про видеопамять).

Сегодня беспроводные системы распространены повсеместно, и количество беспроводных устройств и сервисов продолжает расти. Разработка полноценной радиочастотной системы — это комплексная задача, требующая междисциплинарного подхода, при этом наиболее важной ее частью является аналоговый радиочастотный интерфейс. Однако наличие интегрированных радиочастотных приемопередатчиков, таких как AD9361, значительно упрощает решение радиочастотных задач в подобных проектах. Эти приемопередатчики обеспечивают цифровой интерфейс для цепочки аналоговых радиосигналов и позволяют легко интегрировать их с ASIC или FPGA для обработки в основной полосе частот. Процессор основной полосы частот (BBP) позволяет обрабатывать пользовательские данные в цифровой среде между конечным приложением и приемопередающим устройством. Конструкцию процессора основной полосы частот также легко спроектировать с помощью инструментов системного моделирования, таких как Simulink. Однако начинающему пользователю может быть трудно понять и дополнить эту часть головоломки системы связи. Эта статья представляет собой скромную попытку спроектировать и реализовать простой радиочастотный процессор основной полосы частот для системы беспроводной связи. Проект реализован на платформе AD-FMCOMMS2-EBZ и Xilinx® ZC706 с использованием эталонной конструкции FPGA AD9361.

В первом разделе этой статьи подробно описаны общие принципы проектирования процессора основной полосы частот. Этот раздел представляет собой в основном теоретическое введение в тему. Во втором разделе рассматривается фактическая аппаратная реализация процессора основной полосы частот на базе эталонной платы FPGA AD9361 от Analog Devices. Отмечается, что основная цель разработки — максимально упростить конструкцию и продемонстрировать быструю передачу данных по беспроводной связи в лабораторных условиях. Использование радиочастотного спектра сопряжено с соблюдением нормативных требований и другими последствиями.

Привет, Хабр! Меня зовут Алина, я руковожу группой модульной верификации в YADRO. Свой путь в отрасли я начинала со схемотехники и разработки RTL под FPGA. На Хабре даже есть моя статья про использование опций синтеза в Vivado, написанная еще до того, как различные стратегии на основе AI стали нормой. В черновиках лежит вторая часть той статьи, где я делаю вид, что понимаю математику, которая лежит в основе синтеза цифровой схемы из RTL :) Однако тот текст так и остался черновиком, а я ушла в верификацию и работаю в ней уже больше шести лет.

Скорость верификации IP-компонентов зависит не только от верификаторов. Чтобы ее увеличить, ряд полезных практик в свою работу могут внедрить и соседние команды — управления проектами, RTL-дизайна и архитектуры. Далее в статье я такими практиками поделюсь.

Получил письмо от декана азербайджанского университета ADA University в Баку с просьбой распостранить информацию, что они нанимают большое количество преподавателей. Декан кстати из России, уроженец Дагестана. В университете у них висят портреты как западных деятелей, так и российских - Чехова, Менделеева итд. Многие из преподавателей - азербайджанцы, которые ездили учиться в США и вернулись поднимать родину. Но есть и много иностранцев. Из студентов процентов 70% владеют русским, но 30% не владеют, плюс есть толика иностранных студентов, поэтому официальный язык всего английский. Но во время моего семинара два года назад мы переходили на русский по необходимости, как и разумеется студенты говорят на азербайджанском друг с другом и владеющим азербайджанским преподавателям.

Может начать рисовать комиксы против проповедников ИИ, которые говорят "не смотри в генерируемый код, просто проверяй его в тестовом стенде"? Ниже первый эксерсиз.

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

В тесте было около 10 тысяч транзакций. Я удвоил их количество - все тут же взорвалось - переполнение очереди - утеря данных - ошибка проверки против написанной вручную транзакционной модели.

А ведь если поставить такой блок в реальное устройство, там накрутится за полчаса триллион транзакций (гигагерц - миллиард в секунду - умножить на 20 минут по 60 секунд = 1200 миллиардов).

Это что же - поставить в чип двести триллионов D-триггеров для flop-based FIFO которое оно сгенерило? А если рассматривать худший сценарий работы за сутки - ставить квадриллион D-триггеров? Это чип размером с приусадебный участок.

Сделал в LinkedIn пост на английском:

Привет! Меня зовут Андрей, я занимаюсь верификацией аппаратного обеспечения в YADRO. В разработке цифровых устройств (GPU, CPU, AI-ускорители) большое внимание уделяют трактам обработки данных (datapath). Архитекторы создают эталонные модели блоков на языках высокого уровня (C/C++), чтобы быстрее проводить архитектурные исследования и отладку алгоритмов. Конечная реализация выполняется на RTL (Verilog/SystemVerilog). 

После реализации в виде RTL-кода всегда хочется проверить соответствие итогового дизайна оригинальной модели — здесь помогает формальная верификация. Если вам повезло работать в крупной полупроводниковой компании с доступом к коммерческим инструментам формальной верификации, можно подумать о проверке логической эквивалентности между C и RTL-кодом.

Один из популярных инструментов для такой проверки — это Jasper C2RTL App в составе платформы Cadence JasperGold. В этой статье мы рассмотрим, как работает C2RTL, из каких этапов состоит процесс верификации с ним, как формируются проверки (ассерты) и с какими ограничениями сталкиваются инженеры.

Смена технологической области кажется рискованным шагом: новые термины, другая инженерная культура и ощущение, что придется начинать почти заново. Но на практике переход может оказаться гораздо более плавным.

Меня зовут Любовь Молчева, я руководитель группы unit-верификации дивизиона разработки полупроводниковых продуктов YADRO. До этого вся моя карьера была связана с программной разработкой и тестированием. Перейдя в верификацию полупроводников, я обнаружила, что многие управленческие и инженерные навыки остаются нужными, а требования новой роли во многом совпадают с уже накопленным опытом. В этой статье разберу, какие навыки из software оказываются полезны в hardware, с какими сложностями сталкиваешься в первые месяцы и как выстроить погружение в новую область без ощущения, что начинаешь карьеру с нуля.

Я решил продолжить обзор bladeRF 2.0 micro xA9 через рассмотрение списка проектов, которые наиболее ярким образом демонстрируют возможности данного SDR в реальных применениях. Многие из этих вариантов прямо или косвенно базируются и обусловлены возможностями данного SDR. Перебирая все упоминания проектов с поддержкой bladeRF, я пришел к выводу, что bladeRF 2.0 micro xA9 лучше всего раскрывается там, где нужны не просто прием и декодирование, а широкий захват, передача, full duplex, MIMO, FPGA и кастомные GNU Radio/Soapy/libbladeRF сценарии. Самые сильные и практически ценные направления рассмотрим ниже. Но обо всем по порядку. 

Всем заинтересовавшимся — добро пожаловать под кат =)

Привет! Меня зовут Данил, я разрабатываю прикладное ПО для радиочастотных систем YADRO. В этой статье я расскажу об одном из вариантов сбора данных AXI-Stream для обработки на CPU, рассмотрю в этом контексте возможности и требования блока AXI DMA, а напоследок порассуждаю о когерентности кешей и о том, что на самом деле здесь требуется от драйвера ядра.