Доехало 👊
Если кому вдруг интересно было что там внутри, а то на Амазон оглавления не завезли. Кто-то там даже одну звезду поставить успел - хейтеры ООП наверное.
#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
🔥17❤1
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
5🔥11
Про мажорные версии
Один реддитор спрашивает про питоний 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
🔥9🥱1
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
🔥9
sv-bugpoint
Интересный тул от antmicro для автоматической бисекции SV кода и выделения минимальных баг-репродьюсеров в EDA тулах.
TL;DR
EDA-тулы несовершенны (особенно опенсорс), и когда их натравливают на большие и тяжелые кодовые базы, то они могут ломаться. Проблема в том, что хорошо бы зарепортить баг, но сначала надо потратить существенные усилия чтобы извлечь маленький сниппет кода на десяток строк, который надежно бы его воспроизводил и не нарушил никакое NDA.
Пример из статьи: есть UVM тестбенч, который вместе с UVM 37к строк, но его вериляция повисает намертво. Руками такой стог сена ворошить несколько трудоёмко. Тул сократил код до 200 строк, из которых потом инженер сделал 11. Баг зарепорчен и пофикшен.
Я сам подобного наелся вдоволь пока писал свой svjson - нет ничего увлекательнее, чем играть в Шерлока с верилятором, пытаясь выяснить какая конструкция на этот раз ему не понравилась из последнего диффа на много строк.
На практике
Проверил пример из репозитория. На входе исходный код Caliptra + тестбенч -- это 100к строк. Тул за 40 минут и 8000 итераций ужал до 28 строк🤔
В целом звучит довольно неплохо, т.к. когда в очередной раз ни с того ни с сего видишь что-то типа
то хочется закрыть ноутбук и пойти воздухом подышать. А так, поставил код на усушку-утряску, вернулся, результат быстро осознал, зарепортил баг, все счастливы.
Статья, гитхаб
#verilator #tool
@positiveslack
In this article we introduce sv-bugpoint, an open source tool for finding minimal subsets of SystemVerilog designs that pinpoint the real cause of bugs or gaps in SystemVerilog tools.
Интересный тул от antmicro для автоматической бисекции SV кода и выделения минимальных баг-репродьюсеров в EDA тулах.
TL;DR
EDA-тулы несовершенны (особенно опенсорс), и когда их натравливают на большие и тяжелые кодовые базы, то они могут ломаться. Проблема в том, что хорошо бы зарепортить баг, но сначала надо потратить существенные усилия чтобы извлечь маленький сниппет кода на десяток строк, который надежно бы его воспроизводил и не нарушил никакое NDA.
Пример из статьи: есть UVM тестбенч, который вместе с UVM 37к строк, но его вериляция повисает намертво. Руками такой стог сена ворошить несколько трудоёмко. Тул сократил код до 200 строк, из которых потом инженер сделал 11. Баг зарепорчен и пофикшен.
Я сам подобного наелся вдоволь пока писал свой svjson - нет ничего увлекательнее, чем играть в Шерлока с верилятором, пытаясь выяснить какая конструкция на этот раз ему не понравилась из последнего диффа на много строк.
Как работает sv-bugpoint:
▫️Сначала склеиваем все исходники в один input.sv файл
▫️Делаем "лакмусовую бумажку" - скрипт, которому на вход подаётся этот файл, и он внутри воспроизводит баг и имеет логику сравнения (лога, вейвов и т.д.), чтобы понять что баг всё еще воспроизводится при изменении исходника.
▫️ Запускаем инструмент и даём ему input.sv и скрипт. И он начинает итеративно редуцировать исходник.
▫️▫️Перегоняет исходник через slang в синтаксическое дерево и отпиливает ветки от него
▫️▫️Сохраняет результат в новый файл SV и прогоняет скрипт, чтобы быть уверенным что баг на месте
▫️▫️Повторяет последние шаги до тех пор пока исходный файл не похудеет на порядки
▫️ Получаем минимальный баг-репродьюсер, который, скорее всего, инженер может сжать ещё сильнее после анализа.
На практике
Проверил пример из репозитория. На входе исходный код Caliptra + тестбенч -- это 100к строк. Тул за 40 минут и 8000 итераций ужал до 28 строк
В целом звучит довольно неплохо, т.к. когда в очередной раз ни с того ни с сего видишь что-то типа
%Error Internal Error ../V3Fork.cpp Variable's lifetime is unknown.
то хочется закрыть ноутбук и пойти воздухом подышать. А так, поставил код на усушку-утряску, вернулся, результат быстро осознал, зарепортил баг, все счастливы.
Статья, гитхаб
#verilator #tool
@positiveslack
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17✍2
Препроцессор 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
🔥16
позитивслэк
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
🔥16
Автоматизация вокруг 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
🔥14🤯4✍1
Забавное в UVM
Обнаружил что в UVM есть класс
И почти угадал. Оказывается, что всё буквально ради сообщения при работе с resource pool, когда ты опечатался и ресурс не был найден:
Т.е. кто-то заморочился же с расстоянием Левенштейна и логикой вокруг на SV ради этого.
Не могу объяснить это чем-то кроме как: "Эй, Стасян, смотри чё могу. Круто же?"
#uvm
@positiveslack
Обнаружил что в UVM есть класс
uvm_spell_chkr, который на самом деле то, что в названии. Начал смотреть зачем нужна проверка правописания? Может чтобы позволять работу с бд, даже при опечатках?И почти угадал. Оказывается, что всё буквально ради сообщения при работе с resource pool, когда ты опечатался и ресурс не был найден:
"%s not located, did you mean %s"
Т.е. кто-то заморочился же с расстоянием Левенштейна и логикой вокруг на SV ради этого.
Не могу объяснить это чем-то кроме как: "Эй, Стасян, смотри чё могу. Круто же?"
#uvm
@positiveslack
😁16🔥11
Кокотбшное
Пожалуйста обратитесь за помощью, если у вас возникло желание так форматировать код
#meme
@positivelsack
#meme
@positivelsack
😁21😭6🤯4
VCD Viewer из LLM
Не мог не поделиться этим. Просто прочитайте, посмотрите картинки и осознайте😰
Решил не пересказывать, а просто переслать как есть
Питон файл и vcd файл прикладываю в коментах. Просто положите в одну папку и запустите.
P.s. да, к этому финальному файлу не прикасался человек, всё до последней буквы вышло из o3.
#vcd #llm
@positiveslack
Не мог не поделиться этим. Просто прочитайте, посмотрите картинки и осознайте
Решил не пересказывать, а просто переслать как есть
o3-mini просто разносит.. очень быстро генерит.. за полчаса переписки нафигачил такой вот VCD viewer
<картинка 1 с сигналами>
При этом сначала он даже VCD формат не до конца понимал. Но скушал пару примеров и осилил... Фильтрацию сигналов, кусор добавляю отдельными запросами
0 правок
На python.. все runtime ошибки отправляю ему
В общем виджет для gtkwave можно теперь за пол дня сгенерить..
<картинки 2 и 3 с запросом и реализацией выделения сигналов>
Если научиться разбивать архитектуру сложного софта на компоненты по 10k строк кода, то по сути уметь писать код уже не нужно
думаю за пол дня можно полностью повторить gtkwave
С одной попытки
<картинки 4 и 5 с запросом и реализацией зума>
Питон файл и vcd файл прикладываю в коментах. Просто положите в одну папку и запустите.
P.s. да, к этому финальному файлу не прикасался человек, всё до последней буквы вышло из o3.
#vcd #llm
@positiveslack
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯15✍6🔥4😁3🤔1
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
✍7🔥4🥱1
Чего-кого-куда в 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
🔥6✍5
Идеальный сетап для верификатора
Обратите внимание на зеркало заднего вида, чтобы видеть подкрадывающегося менеджера с вопросом "когда verification complete?"
#meme
@positiveslack
#meme
@positiveslack
😁30🔥29