В субботу прошло первое занятие Школы Синтеза Цифровых Схем. Записалось 650 человек в 15 городах России и Беларуси, пришли 400 (250 офлайн и 150 онлайн). Российский флаг на мониторе нарисован комбинационной логикой FPGA (первое что пришло в голову рисовать студентам сразу в двух кластерах). Вообще обычно на первом занятии мигают светодиодами, но мы решили пойти дальше и показали им как рисовать картинки. Для этого два счетчика формируют X и Y, а задача студента - реализовать функцию RGB (X, Y).

Из-за наличия зоопарка плат, версий Windows и Linux, а также EDA софтвера, глючных программаторов, и при этом свежих и недотестированных bash-скриптов, возникла ситуация полного ада, особенно у онлайн-пользователей (преподаватели на местах героически справлялись). Возникла ошибка, которая меня реально удивила. И не только меня:

В первой части статьи мы остановились на шаге 8 (Напомню, звучал он как “Формализация и дизайн”). Давайте с него и начнем: разделим этот шаг на несколько и распишем, что же происходит дальше, когда канва игровой идеи и список референсов у вас уже имеется.

Подчеркну, что в разных командах и в работе над разными играми (мобилки, ААА, браузерные платформеры, VR и т.п.) эти пункты могут отличаться. Сказывается как особенности платформы, для которой пишется игрушка, так и специфика жанра и аудитории. Могут появляться дополнительные шаги, что-то поменяется местами или вовсе будет пропущено. Поэтому не воспринимайте это как 100% руководство к действию, скорее как совет при ответе на вопрос “А что делать дальше?”. Надеюсь, многим из вас это действительно будет полезно=)

Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал.

Был отпуск и решил что-нибудь взять почитать. Наткнулся на книгу "Джоэл о программировании". Выбрал ее.

Изначально думал, что это самая обычная скучная книжка: написана на определенную тему, полно воды, много терминов и др. Спустя 2 главы свое мнение поменял. И вот почему.

Чтобы написать продолжение предыдущей статьи мне пришлось перечитать множество материалов, имеющих отношение к теме. Я так и не нашел пример хоть какой‑то практической задачи, определяющей хоть какие‑то детали, имеющие отношение к возможности распараллеливания. По большому счету все пишут о том, что распараллеливание улучшает производительность, и это в общем‑то все к чему нужно стремиться с невнятными оговорками о том, что при этом можно получить кучу проблем.

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

Мне кажется нельзя считать что вы до конца понимаете концепцию многопоточности (Multithreading/ Concurrency) если вы не понимаете когда (для каких задач) ее можно и/или нужно использовать на однопроцессорной машине, 2-х процессорной, N‑процессорной машине и от чего это зависит.

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

В то же время в отрасли немало специалистов с практическим багажом, которые уже решают прикладные задачи проектирования цифровой логики, но в смежных с разработкой ASIC областях — например, FPGA инженеры. Мы заметили, что у нас в компании нередким стал кейс, когда в команду приходят специалисты с опытом в FPGA-разработке, довольно быстро включаются в задачи проектирования ASIC и потом целиком уходят в эту смежную область, ведь маршруты проектирования и инструменты похожи.

Мы решили систематизировать этот опыт и превратить его во внутренний курс переподготовки из FPGA-дизайнеров в ASIC. Если вы тоже задумывались о том, чтобы начать проектировать IP-блоки для ASIC, прочитайте эту статью. Мы поговорили с нашими инженерами, которые самостоятельно прошли путь от цифрового синтеза под FPGA к проектированию ASIC о том, какие знания и опыт для этого нужны, и в чем разница в построении процессов и устройстве работы команд. И, кажется, нашли много плюсов перехода в эту смежную область. 

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

Когда я вижу у недавнего выпускника в резюме какой-то из протоколов в котором используется valid/ready, например AXI или AHB, я прошу его спроектировать блок, у которого на входе два числа A и B, а на выходе их сумма. Разумеется не просто написать SUM=A+B, а еще и поставить valid/ready сигналы на каждый из A, B, SUM, чтобы A и B могли приходить в разное время, а также чтобы блок ждал, если SUM не может быть передана другому блоку сразу.

Некоторые не справляются. Грустно смотреть на человека, который потратил 6 лет своей жизни (4 года в бакалавриате и 2 года в магистратуре) и океан денег на образование - и не может сложить два числа и бьется как угорь на сковородке. То блок не работает когда числа приходят в разное время, то создатель забывает снять valid, и блок на 2+2 выдает не 4, а 4-4-4-4-4-4-4... То числа складываются не попарно, а просто записываются в регистры и на выход идет их текущая сумма, хотя количество аргументов A и B не совпадает. То не отрабатывается backpressure и результаты теряются, то (после того как кандидат написал страницу кода на верилоге) блок работает на половинной производительности, то есть не может принимать поток чисел подряд, а ожидает между ними пропуски (gaps). Короче ведет себя как ChatGPT.

На reddit большое комьюнити, которое посвящено vim: neovim, vim, vimplugins, vimporn. И чтобы не пропускать какие-то интересные вещи, которые случаются в мире vim, я накидал bash-скрипт. Скрипт выводит топ-5 лучших постов за год по каждому сабредиту. В статье будет сам скрипт, а также я своими словами расскажу о каждом посте, который попал в топ.

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

Изнуряющие тренировки отнимают много времени и сил. Зато потом, когда понадобится применить своё искусство,  тело сделает всё само — «на автомате». А ценные ресурсы мозга будут освобождены для решения более важных задач — стратегического планирования, принятия ключевых решений, поиска новых возможностей. И, конечно, для творчества.

А что же программисты?...

FIFO – ключевая концепция в хардварном дизайне. Понимание работы FIFO необходимо, в частности, для понимания протокола valid/ready, который в свою очередь необходим для организации flow-control как внутри цифровых блоков так и на межблочном уровне.

К сожалению по данной тематике очень мало литературы. Да и что говорить, микроархитектурные концепции достаточно сложно освоить по книгам. Понимание данных концепций это по сути выработка хардварной интуиции приходящая с практикой.

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

Поскольку тренажер является "фронтендом" для HDL симулятора то на самом симуляторе исполняется реальный, синтезируемый SystemVerilog который можно посмотреть и даже поменять его функциональность.

Мы так привыкли к типам, что редко задаёмся вопросом, что же они такое на самом деле? А главное - почему возникла необходимость в их использовании? Этот поверхностный обзор сделан для того, чтобы продемонстрировать, как типы и другие связанные абстракции являются следствием из обобщения условий различных задач.

Я работаю в MacOS, почти не использую Finder и все время провожу в консоли. Именно поэтому стараюсь сделать работу из консоли как можно более удобной.

Относительно недавно мне на глаза попалась утилита FZF. И уже через неделю стала незаменимой.

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

Я с удивлением обнаружил, что об этой программе нет ни одной статьи на хабре, кроме некоторых упоминаний вскользь. Я решил восполнить этот пробел. Если вы уже знаете о FZF, то статья скорее всего покажется вам неинформативной, а всем остальным добро пожаловать

Мягкое удаление (soft deletion) — это популярная в энтерпрайз разработке стратегия удаления, когда вместо физического стирания та или иная запись помечается как удаленная, а потом фильтруется во всех запросах на чтение. Применение мягкого удаления может быть оправдано целым набором требований: аудит, возможность восстановления удаленных записей, а иногда необходимо уметь удалять данные, при этом сохраняя на них ссылки из других записей… 

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

Если вдруг кто не знает, Anki - это бесплатная opensource программа для запоминания слов (и не только). Есть версии под декстоп и мобилы. Она довольно популярна при этом имеет интуитивно-НЕпонятный интерфейс. Мне понадобилось много лет, чтобы понять, насколько она крута, т.к. базовые статьи и туториалы этого не описывают. А многие люди используют ее даже не понимая ее возможностей.

Впервые про Anki я услышал много лет назад. Может быть 10 или больше, точно сказать сложно. Прочитал здесь на Хабре, что есть такая крутая штука как интервальное повторение, и что Anki как раз такая программа, которая использует этот механизм. Помню что в статье рассказывалось только про версию под декстоп.

В этой статье я хочу рассказать о практическом опыте нативной компиляции production приложения, написанного на Kotlin со Spring Boot, Gradle с использованием GraalVM . Начну сразу с минусов и плюсов самой возможности нативной компиляции и где она может быть полезна, и дальше перейду уже непосредственно к процессу сборки под MacOS и Windows.

В конце статьи я более подробно расскажу о проекте и почему возникла такая необходимость, учитывая довольно много ограничений и подводных камней поддержки нативной компиляции как со стороны Spring Boot, та и со стороны GraalVM.

Возможно, кто-то из читателей помнит мою серию публикаций о графической библиотеке OpenSceneGraph. Уже на тот момент, в общем-то было понятно, что использование OpenSceneGraph в 2018 году мало оправдано из-за того, что OpenGL, на котором основан OpenSceneGraph потихоньку сдает свои позиции. В феврале 2016 года орган по стандартизации OpenGL Khronos group, выпускают приемника OpenGL - Vulkan API версии 1.0. Производители оборудования в общем-то почти сразу стали добавлять в драйверы своей аппаратуры поддержку нового API. По крайней мере, актуальная на тот момент GeForce GTX 970 уже имела таковую поддержку (про более старые серии аппаратуры ничего сказать не могу).

Не смотря на то, что OpenSceneGraph таки получил поддержку OpenGL 3.x (и ваш покорный слуга собирал его с таковой поддержкой), разработчикам этой библиотеки стало понятно, что огромное количество внутренних проблем OpenGL делает его поддержку бесперспективной. Поэтому, в конце мая 2018 года стартовала разработка новой графической библиотеки VulkanSceneGraph, ориентированной исключительной на Vulkan API. 13 ноября 2022 года состоялся официальный релиз VulkanSceneGraph-1.0, а совсем недавно, 31 августа 2023 выпустили VulkanSceneGraph-1.0.9.

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

Этот обзор посвящен открытому проекту компьютера My4TH по информации от разработчика: Авторский сайт проекта:

My4TH (произносится как "мой четвертый") - это четвертый домашний компьютер без процессора после MyCPU, MyNOR и TraNOR. Автор хотел и построил максимально простой компьютер с дискретным процессором, использующим как можно меньше элементов и компонентов, под управлением операционной системы Forth.