Доехало 👊
Если кому вдруг интересно было что там внутри, а то на Амазон оглавления не завезли. Кто-то там даже одну звезду поставить успел - хейтеры ООП наверное.
#book #system_verilog
@positiveslack
Если кому вдруг интересно было что там внутри, а то на Амазон оглавления не завезли. Кто-то там даже одну звезду поставить успел - хейтеры ООП наверное.
#book #system_verilog
@positiveslack
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Astral: Next-gen Python tooling
Давеча изучал современный ландшафт тулов для питона, и чёт впечатлился ребятами из astral.sh. Они с ноги влетели в питон-сообщество, сказали что это вы тут заговно зоопарк тулов развели, вот у нас в расте есть единый Cargo и всё из коробки, сейчас мы вам нормальный тулчейн на расте напишем, и всё летать будет.
Да-да, это гремучая смесь из XKCD#927 и "Rewrite it in Rust" мема.
И самое главное - написали, да так, что за относительно короткий срок пошло терраформирование всего ландшафта, и крупные проекты начали переползать на их линтер-форматтер Ruff. Не говоря уже о мелких, где Ruff теперь считается стандартным выбором. Он покрывает целую пачку аналогов и работает реально быстро (в десятки раз быстрее, если точнее).
В этом году они выкатили UV - инструмент для закрытия другой нужды: менеджмента проекта, зависимостей, окружений и самих питонов. Один тул, чтобы покрыть pip, pipx, poetry, virtualenv и дальше по списку. Они там поглотили в процессе популярный rye, который преследовал похожие цели, и теперь декларируют uv как наследника. Инструмент тоже хайпанул и проходит стадию принятия сейчас.
Ну им осталось сделать лишь blazingly fast (c) тайп-чекер. И всё, дефолтный тулчейн будет готов. Поживем-увидим, выстрелят ли эти ожидания.
P.S. Про КДПВ. Звёзды гитхаба конечно так себе метрика, но на самом деле сейчас они там уже ушли в отрыв - 32k звёзд для ruff, что похоже больше чем у любого другого инструмента для питона.
#python #tool
@positiveslack
Давеча изучал современный ландшафт тулов для питона, и чёт впечатлился ребятами из astral.sh. Они с ноги влетели в питон-сообщество, сказали что это вы тут за
Да-да, это гремучая смесь из XKCD#927 и "Rewrite it in Rust" мема.
И самое главное - написали, да так, что за относительно короткий срок пошло терраформирование всего ландшафта, и крупные проекты начали переползать на их линтер-форматтер Ruff. Не говоря уже о мелких, где Ruff теперь считается стандартным выбором. Он покрывает целую пачку аналогов и работает реально быстро (в десятки раз быстрее, если точнее).
В этом году они выкатили UV - инструмент для закрытия другой нужды: менеджмента проекта, зависимостей, окружений и самих питонов. Один тул, чтобы покрыть pip, pipx, poetry, virtualenv и дальше по списку. Они там поглотили в процессе популярный rye, который преследовал похожие цели, и теперь декларируют uv как наследника. Инструмент тоже хайпанул и проходит стадию принятия сейчас.
Ну им осталось сделать лишь blazingly fast (c) тайп-чекер. И всё, дефолтный тулчейн будет готов. Поживем-увидим, выстрелят ли эти ожидания.
P.S. Про КДПВ. Звёзды гитхаба конечно так себе метрика, но на самом деле сейчас они там уже ушли в отрыв - 32k звёзд для ruff, что похоже больше чем у любого другого инструмента для питона.
#python #tool
@positiveslack
Про мажорные версии
Один реддитор спрашивает про питоний pydantic: "Как же так, библиотека переходит на новую мажорную версию, и теперь оказывается все туториалы устарели, а ChatGPT ещё не знает о новой версии. Что же делать? Как же жить?"
И разработчики такие, которые написали и поддерживают одну из лучших документаций среди питоньих либ, написали миграционный гайд, и всячески пытались "подстелить соломку" для бампа мажорной версии: "Ну да, ну да, пошли мы нахер". Т.е. вариант просто читать документацию как-то не рассматривается в принципе.
И это не первый пост на схожую тему на моей памяти. И всё чаще упоминается ChatGPT при этом всем. Похоже умение вдумчиво читать документацию переходит в разряд элитарных навыков?
И ведь в самом бампе мажорной версии нет ничего такого - это здоровый процесс развития, когда учитываются набитые шишки и дропается легаси.
Сейчас правда он сакрализирован настолько, что разработчики панически боятся бампать мажорную версию. Люди готовы или наслаивать хаки поверх устаревшей архитектуры, либо, что ещё хуже, ломать минорные версии и искать оправдания этому. И всё это подрывает саму идею semver и контракт с юзером о семантике изменений.
Есть даже пост от автора semver на эту тему: Major Version Numbers are Not Sacred. Там кроме всего, ещё и пояснения к тому, что мажорные версии никогда не должны были быть частью маркетинга и обязаны меняться так часто, как требует этого разработка. Рекомендую ознакомиться.
А вообще, можно ведь не мучить ни себя ни юзера ложными ожиданиям, и выбрать альтернативную схему версионирования, чтобы следовать ей до конца. Вон в TeX версия - это число, ассимптотически приближающееся к пи, а бамп - это добавление нового знака после запятой. Это хотя бы красиво.
#dev
@positiveslack
Один реддитор спрашивает про питоний pydantic: "Как же так, библиотека переходит на новую мажорную версию, и теперь оказывается все туториалы устарели, а ChatGPT ещё не знает о новой версии. Что же делать? Как же жить?"
И разработчики такие, которые написали и поддерживают одну из лучших документаций среди питоньих либ, написали миграционный гайд, и всячески пытались "подстелить соломку" для бампа мажорной версии: "Ну да, ну да, пошли мы нахер". Т.е. вариант просто читать документацию как-то не рассматривается в принципе.
И это не первый пост на схожую тему на моей памяти. И всё чаще упоминается ChatGPT при этом всем. Похоже умение вдумчиво читать документацию переходит в разряд элитарных навыков?
И ведь в самом бампе мажорной версии нет ничего такого - это здоровый процесс развития, когда учитываются набитые шишки и дропается легаси.
Сейчас правда он сакрализирован настолько, что разработчики панически боятся бампать мажорную версию. Люди готовы или наслаивать хаки поверх устаревшей архитектуры, либо, что ещё хуже, ломать минорные версии и искать оправдания этому. И всё это подрывает саму идею semver и контракт с юзером о семантике изменений.
Есть даже пост от автора semver на эту тему: Major Version Numbers are Not Sacred. Там кроме всего, ещё и пояснения к тому, что мажорные версии никогда не должны были быть частью маркетинга и обязаны меняться так часто, как требует этого разработка. Рекомендую ознакомиться.
А вообще, можно ведь не мучить ни себя ни юзера ложными ожиданиям, и выбрать альтернативную схему версионирования, чтобы следовать ей до конца. Вон в TeX версия - это число, ассимптотически приближающееся к пи, а бамп - это добавление нового знака после запятой. Это хотя бы красиво.
#dev
@positiveslack
Veryl HDL
Тут @enginegger выгрузил довольно объемный пост с впечатлениями от Veryl. Советую ознакомиться.
Получается, что это довольно смелая фантазия на тему того, как мог бы выглядеть Verilog, если бы он случился недавно - со всем единым джентельменским набором инфраструктуры и нормальным метапрограмированием вместо текстового препроцессора.
Видно очень сильное влияние Rust как на интерфейсы инструментов, так и на сам синтаксис, что хорошо на мой взгляд. Оно так-то и не удивительно, т.к. Veryl ржавый под капотом чуть более чем полностью.
Интересно будет понаблюдать за взлётом или забвением этого проекта. Всё равно это будет быстрее чем подобные фичи заедут в какой-нибудь новый SV стандарт и будут поддержаны😭
Ещё пришла идея, что можно уже сейчас попробовать решить проблемы с менеджментом зависимостей и пакетированием SV через Veryl. Ну т.е. делаем минимальные тонкие обертки для модулей/интерфейсов/пакетов через него, и дальше используем встроенный инструментарий для менеджмента зависимостей такой сущности. Потенциально выглядит чуть менее маргинально чем делать это через pip, например🤔
#veryl
@positiveslack
Тут @enginegger выгрузил довольно объемный пост с впечатлениями от Veryl. Советую ознакомиться.
Получается, что это довольно смелая фантазия на тему того, как мог бы выглядеть Verilog, если бы он случился недавно - со всем единым джентельменским набором инфраструктуры и нормальным метапрограмированием вместо текстового препроцессора.
Видно очень сильное влияние Rust как на интерфейсы инструментов, так и на сам синтаксис, что хорошо на мой взгляд. Оно так-то и не удивительно, т.к. Veryl ржавый под капотом чуть более чем полностью.
Интересно будет понаблюдать за взлётом или забвением этого проекта. Всё равно это будет быстрее чем подобные фичи заедут в какой-нибудь новый SV стандарт и будут поддержаны
Ещё пришла идея, что можно уже сейчас попробовать решить проблемы с менеджментом зависимостей и пакетированием SV через Veryl. Ну т.е. делаем минимальные тонкие обертки для модулей/интерфейсов/пакетов через него, и дальше используем встроенный инструментарий для менеджмента зависимостей такой сущности. Потенциально выглядит чуть менее маргинально чем делать это через pip, например
#veryl
@positiveslack
Please open Telegram to view this post
VIEW IN TELEGRAM
Препроцессор SV как инструмент
Кстати, в процессе изучения sv-bugpoint узнал как можно свести проект любой сложности и структуры к одному SV файлу, т.к. инструменту на вход требовался строго один файл.
Просто прогнать все исходники/файллисты через препроцессор верилятора:
В stdout и получим желаемый файл. Супер просто и примитивно, но признаюсь, не знал что так можно.
Ещё один инструмент для исследования и диагностики в копилку.
P.s. если у кого-то нет верилятора, но есть квеста,
#verilator #tips_and_tricks
@positiveslack
Кстати, в процессе изучения sv-bugpoint узнал как можно свести проект любой сложности и структуры к одному SV файлу, т.к. инструменту на вход требовался строго один файл.
Просто прогнать все исходники/файллисты через препроцессор верилятора:
verilator -E -P [flags, sources] > output.sv
В stdout и получим желаемый файл. Супер просто и примитивно, но признаюсь, не знал что так можно.
Ещё один инструмент для исследования и диагностики в копилку.
P.s. если у кого-то нет верилятора, но есть квеста,
vlog -mfcu -E делает то же самое.#verilator #tips_and_tricks
@positiveslack
позитивслэк
Verilator и UVM [6] Думал сейчас быстро возьму этот первый UVM тестбенч, запущу побольше транзакций и сравню производительность с проприетарными симами. Приключение на 20 минут, ага. Тестбенч оказался кривоват и считай ничего не делал - пришлось на ходу…
Verilator и UVM [7]
Enabling open source UVM verification of AXI-based systems in Verilator
Похоже в вериляторе уже фактически можно делать каноничные UVM окружения с агентами, драйверами, мониторами. В частности, ребята из antmicro подняли простой axi-vip💃
Это стало возможным благодаря недавним улучшениям, посвященным виртуальным интерфейсам, клокинг блокам и рандомизации. Кстати по поводу последнего можно глянуть вот эту статью -- там есть интересные детали того как солвер организовали внутри.
Ну что, теперь даёшь опенсорсный AMBA UVM VIP? Теперь по крайней мере не нужен симулятор за сто-тыщ-мильонов чтобы начать.
#uvm #verilator
@positiveslack
Enabling open source UVM verification of AXI-based systems in Verilator
Похоже в вериляторе уже фактически можно делать каноничные UVM окружения с агентами, драйверами, мониторами. В частности, ребята из antmicro подняли простой axi-vip
Это стало возможным благодаря недавним улучшениям, посвященным виртуальным интерфейсам, клокинг блокам и рандомизации. Кстати по поводу последнего можно глянуть вот эту статью -- там есть интересные детали того как солвер организовали внутри.
Ну что, теперь даёшь опенсорсный AMBA UVM VIP? Теперь по крайней мере не нужен симулятор за сто-тыщ-мильонов чтобы начать.
#uvm #verilator
@positiveslack
Please open Telegram to view this post
VIEW IN TELEGRAM
Antmicro
Enabling open source UVM verification of AXI-based systems in Verilator
Автоматизация вокруг HDL
Ландшафт инструментов сборки, автоматизации и менеджмента HDL проектов очень неравномерный. Причем большая его часть скрыта "под землёй" во внутренних репозиториях компаний, где инструменты и скрипты разрабатываются с нуля внутри под конкретные нужды, боли и инфраструктуру компании.
Ниже я попробовал собрать в кучу то, что можно найти в открытом доступе. Классификацию тут проводить непросто, т.к. какие-то проекты пытаются быть всем, какие-то решить лишь один аспект, какие-то нацелены на FPGA, иные не имеют таких ограничений, и т.д.
Тем не менее, хотелось бы попробовать провести сравнительный анализ в будущем, поэтому если вдруг у вас есть опыт использования чего-либо ниже (или может чего-то, что я забыл), то поделитесь болью или успехом в комментах.
▫️orbit: Package manager and build tool for HDLs [Rust]
▫️bender: A dependency management tool for hardware projects [Rust]
▫️FuseSoC: Package manager and build abstraction tool for FPGA/ASIC development [Python]
▫️Edalize: An abstraction library for interfacing EDA tools [Python]
▫️Hdlmake: Tool for generating multi-purpose makefiles for FPGA projects [Python]
▫️Hog: Hog (HDL-on-git) is a set of Tcl/Shell scripts plus a suitable methodology to handle HDL designs in a git repository [Tcl, Shell]
▫️SiliconCompiler: Modular hardware build system [Python]
▫️Blockwork: An opinionated build environment for EDA projects [Python]
▫️HBS: Build system for hardware description projects, which was created out of frustration with all existing build systems for hardware description [Tcl]
▫️DUH: Suite of tools for packaging reusable hardware components and designs [JavaScript]
▫️Xeda: Cross-platform, cross-EDA, cross-target simulation and synthesis automation platform [Python]
▫️EDA²: Conceptual model for characterising the abstraction layers in Electronic Design Automation projects based on Hardware Description Languages [Python]
▫️LiteX:The LiteX framework provides a convenient and efficient infrastructure to create FPGA Cores/SoCs, to explore various digital design architectures and create full FPGA based systems [Python]
▫️DVSim: An industry-grade EDA tool flow manager / build and run system that strives to achieve a bug-free Silicon [Python]
▫️Hammer: Hammer is a physical design framework that wraps around vendor specific technologies and tools to provide a single API to create ASICs [Python]
#tool
@positiveslack
Ландшафт инструментов сборки, автоматизации и менеджмента HDL проектов очень неравномерный. Причем большая его часть скрыта "под землёй" во внутренних репозиториях компаний, где инструменты и скрипты разрабатываются с нуля внутри под конкретные нужды, боли и инфраструктуру компании.
Ниже я попробовал собрать в кучу то, что можно найти в открытом доступе. Классификацию тут проводить непросто, т.к. какие-то проекты пытаются быть всем, какие-то решить лишь один аспект, какие-то нацелены на FPGA, иные не имеют таких ограничений, и т.д.
Тем не менее, хотелось бы попробовать провести сравнительный анализ в будущем, поэтому если вдруг у вас есть опыт использования чего-либо ниже (или может чего-то, что я забыл), то поделитесь болью или успехом в комментах.
▫️orbit: Package manager and build tool for HDLs [Rust]
▫️bender: A dependency management tool for hardware projects [Rust]
▫️FuseSoC: Package manager and build abstraction tool for FPGA/ASIC development [Python]
▫️Edalize: An abstraction library for interfacing EDA tools [Python]
▫️Hdlmake: Tool for generating multi-purpose makefiles for FPGA projects [Python]
▫️Hog: Hog (HDL-on-git) is a set of Tcl/Shell scripts plus a suitable methodology to handle HDL designs in a git repository [Tcl, Shell]
▫️SiliconCompiler: Modular hardware build system [Python]
▫️Blockwork: An opinionated build environment for EDA projects [Python]
▫️HBS: Build system for hardware description projects, which was created out of frustration with all existing build systems for hardware description [Tcl]
▫️DUH: Suite of tools for packaging reusable hardware components and designs [JavaScript]
▫️Xeda: Cross-platform, cross-EDA, cross-target simulation and synthesis automation platform [Python]
▫️EDA²: Conceptual model for characterising the abstraction layers in Electronic Design Automation projects based on Hardware Description Languages [Python]
▫️LiteX:The LiteX framework provides a convenient and efficient infrastructure to create FPGA Cores/SoCs, to explore various digital design architectures and create full FPGA based systems [Python]
▫️DVSim: An industry-grade EDA tool flow manager / build and run system that strives to achieve a bug-free Silicon [Python]
▫️Hammer: Hammer is a physical design framework that wraps around vendor specific technologies and tools to provide a single API to create ASICs [Python]
#tool
@positiveslack
Забавное в UVM
Обнаружил что в UVM есть класс
И почти угадал. Оказывается, что всё буквально ради сообщения при работе с resource pool, когда ты опечатался и ресурс не был найден:
Т.е. кто-то заморочился же с расстоянием Левенштейна и логикой вокруг на SV ради этого.
Не могу объяснить это чем-то кроме как: "Эй, Стасян, смотри чё могу. Круто же?"
#uvm
@positiveslack
Обнаружил что в UVM есть класс
uvm_spell_chkr, который на самом деле то, что в названии. Начал смотреть зачем нужна проверка правописания? Может чтобы позволять работу с бд, даже при опечатках?И почти угадал. Оказывается, что всё буквально ради сообщения при работе с resource pool, когда ты опечатался и ресурс не был найден:
"%s not located, did you mean %s"
Т.е. кто-то заморочился же с расстоянием Левенштейна и логикой вокруг на SV ради этого.
Не могу объяснить это чем-то кроме как: "Эй, Стасян, смотри чё могу. Круто же?"
#uvm
@positiveslack
Кокотбшное
Пожалуйста обратитесь за помощью, если у вас возникло желание так форматировать код
#meme
@positivelsack
#meme
@positivelsack
Compile-time проверки в SV
Часто расстраивает что в SV нет одного универсального способа организации чекеров в compile-time для проверки корректности параметров любого контейнера. Точнее как, для модулей/интерфейсов варианты есть, а для классов честного варианта совсем нет.
Или есть?
Вот, например, легаси compile-time чекер для модуля:
Ага, текст ошибки здесь это имя неизвестной сущности.
Или вот его более современная версия с "implicit generate" и использованием "elaboration system tasks" :
А что с классами? А они в пролёте😔
Там нельзя использовать generate. Но можно получить близкий эффект в самой-самой ранней точке симуляции - во время присвоения статических переменных. Не compile-time, но мгновенно падающий runtime в нулевой момент времени уже неплохо. Это может выглядеть примерно так:
Суть в том, что мы здесь эксплуатируем процесс присвоения static переменных и заставляем симулятор вызвать наш метод-чекер. И теперь если хоть где либо происходит упоминание класса c неверными параметрами, то симуляция не начнется вообще😏
Если двигаться дальше в сторону от compile-time, то следующей остановкой мог бы быть конструктор класса. Но такое не применить к абстрактным классам, ну и стрелять оно будет уже где-то в процессе симуляции, потенциально далеко от старта. И это уже в общем-то то же самое, что и просто в любом месте процедурного кода сделать проверку.
#system_verilog
@positiveslack
Часто расстраивает что в SV нет одного универсального способа организации чекеров в compile-time для проверки корректности параметров любого контейнера. Точнее как, для модулей/интерфейсов варианты есть, а для классов честного варианта совсем нет.
Или есть?
Вот, например, легаси compile-time чекер для модуля:
parameter FOO_W = 42;
generate
if (FOO_W > 32) begin
foo_w_parameter_must_be_less_or_equal_to_32();
end
endgenerate
Ага, текст ошибки здесь это имя неизвестной сущности.
Или вот его более современная версия с "implicit generate" и использованием "elaboration system tasks" :
parameter FOO_W = 42;
if (FOO_W > 32) begin
$error("FOO_W parameter must be less or equal to 32");
end
А что с классами? А они в пролёте
Там нельзя использовать generate. Но можно получить близкий эффект в самой-самой ранней точке симуляции - во время присвоения статических переменных. Не compile-time, но мгновенно падающий runtime в нулевой момент времени уже неплохо. Это может выглядеть примерно так:
module tb;
class foo #(parameter int FOO_W);
static local bit checker = check();
static local function bit check();
if (FOO_W > 32) begin
$fatal("FOO_W parameter must be less or equal to 32");
end
endfunction
endclass
initial begin
#10 $display("haha, nope %s", $typename(foo#(42)));
end
endmodule
Суть в том, что мы здесь эксплуатируем процесс присвоения static переменных и заставляем симулятор вызвать наш метод-чекер. И теперь если хоть где либо происходит упоминание класса c неверными параметрами, то симуляция не начнется вообще
Если двигаться дальше в сторону от compile-time, то следующей остановкой мог бы быть конструктор класса. Но такое не применить к абстрактным классам, ну и стрелять оно будет уже где-то в процессе симуляции, потенциально далеко от старта. И это уже в общем-то то же самое, что и просто в любом месте процедурного кода сделать проверку.
#system_verilog
@positiveslack
Please open Telegram to view this post
VIEW IN TELEGRAM
Чего-кого-куда в SV
В прошлом посте было упоминание ограничений generate и про разные параметризируемые контейнеры. И как раз в интернетах нашлась вот такая замечательная схема. Не знаю, можно там кружку или футболку себе сделать.
P.S. А вы тоже только сегодня узнали что в SV есть некий config😳 ?
P.P.S. 33. Configuring the contents of a design в стандарте.
#system_verilog
@positiveslack
В прошлом посте было упоминание ограничений generate и про разные параметризируемые контейнеры. И как раз в интернетах нашлась вот такая замечательная схема. Не знаю, можно там кружку или футболку себе сделать.
P.S. А вы тоже только сегодня узнали что в SV есть некий config
P.P.S. 33. Configuring the contents of a design в стандарте.
#system_verilog
@positiveslack
Please open Telegram to view this post
VIEW IN TELEGRAM
Идеальный сетап для верификатора
Обратите внимание на зеркало заднего вида, чтобы видеть подкрадывающегося менеджера с вопросом "когда verification complete?"
#meme
@positiveslack
#meme
@positiveslack