one_eight_seven

И? Где требованиеп в ACCESS держать PENABLE высоким? То, что PENABLE можно поднимать только в ACCESS state - это есть. А обратное? Это насколько надо не дружить с логикой, чтобы "не раньше, чем через один такт", понимать как "обязательно всегда через один такт"?

Это согласно какой спецификации? В AMBA даже близко нет такого требования

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

И как там, в радужном мире, где живут пони и какают радугой? Если инвестируют, когда ты заявляешь, что пользуешь агиле, то будешь заявлять, и заниматься очковтирательтсвом, что пользуешь. Посмотрите игропром и необходимость сотрудничать со Sweet Baby Inc, чем занимаются все крупные компании, и посмотрите, приносит это доходы или убытки. То же самое с индустрией кино и анимации. То же самое в технических монопольках.

Да. И даже state of agile об этом уже начал говорить. А это - коммитет, где все занимаются тем, что на этой инфоцыганщине зарабатывают. А те, кто с этим работает давным давно уже открыто обо всём говорят. Единственная вещь, которая ни у кого не вызывает отторжения - это CI/CD, но вот проблема - это не Agile. Его туда приписали для очковтирательства, но его можно легко приписать и к любой не-agile технологии.

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

У вас там что, 2012? Даже создатели агиле и скрума уже избегают этих слов, как полностью себя дискредетировавших.

Конечно. Вед в скрам - не про управление изменениями, не про учёт изменений, хотя основные претензии - именно про это. Вообще на моей практике нет никаких проблем с тем, чтобы внести изменения в требования, основные проблемы с тем - как бить по рукам тем, кто их хочет внести, как угомонить этих генераторов новых требований. И как потом ткнуть им в нос их изменения - когда почему они были сделаны, и как возражения были проигнорированы.

Протокол разногласий придумали задолго до дебильной терминологии, и задолго до того, как waterfall, не имеющий ничего общего с имеющимися практиками и стандартами разработки на второй страничке той самой книги. И, конечно же - до того, как влажные фантазии начали с ним сравнивать

Нет, скорее сегодня - это взять только понятное из Scrum (оно же - плохое и перечислено ниже), криво его применять и пользоваться JIRA. Ничего из этого не имеет ничего общего ни с управлением проектами, ни с выполнением задач, ни, тем более, - с управлением изменениями в требованиях. Кстати, сам scrum - весьма неплох, даже хорош, надо всего лишь убрать из него спринты, скрам-мастера, продакт овнера, бэклог, спринт ревью, упоминания подотчётности (accountability) и обязательств (commitment), ну и сертификацию. Что тогда плохого останется в скрам?

QIS - маршут для visualizer, собирает qwave.db

угу. и модификатор final на класс. Я тоже против тривиальных методов, но всё-таки это какой-никакой, но задел на будущее.

Да всем можно. Код так более читаем для большинства людей. Плюс не надо думать и запоминать правила - всегда пишешь одинаково, и думаешь о том, как правильнее назвать. Если занимаешься интересными вещами, то заниматься подсчётом строк, вспоминать как по разному оформлять одинаковые по своей сути сущности - отвлекает. Поэтому, в библиотеках, да и во многих программах просто пользуются минимальным набором правил. по оформлению. Типа всё константное - ALL_CAPS_SNAKE (и-то не обязательно), всё остальное - lower_case_snake, или вообще всё - lower_case_snake Код может быть написан читаемым и в lower_case и в CamelCase, в стиле кодирования важнее другие вещи - правильное именование, объединение того, что должно быть объединено, и разделение разных сущностей по естественным границам, малые методы, делающие одно действие, понятно и явно написанные; комментарии, описывающие намерение или предупреждающие о чём-либо, а не реализацию (будто реализацию из кода не видно)

Это вы не поняли, что буковка e перед eEN1 или eEN2 - вообще ничего не поменяет. Более того, вы и читать не умеете. Я же сказал, компилятор - выругается, программист увидит, и поправит: test.cpp: In function ‘int main()’: test.cpp:12:13: error: ‘EN0’ was not declared in this scope 12 | int i = EN0; | ^~~ test.cpp:12:13: note: suggested alternatives: test.cpp:8:5: note: ‘B::EN0’ 8 | EN0, EN1 | ^~~ test.cpp:4:5: note: ‘A::EN0’ 4 | EN0, EN1 | ^~~ avi@mob:~/test$ Ещё раз призываю эволюционировать, сначала самому попробовать что-то сделать, а не постить влажные фантазии с апломбом гуру.

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

А зачем их отличать? Что то - константа, что другое. Вам - нет. Человеку, который будет этот код открывать - да. А не надо сразу понимать насколько она тривиальная и из чего она состоит. Важно - что она делает, и как ей пользоваться. Если инженер занимается поддержкой кода, то ему важно - как легко её найти, и да - ему будет важно знать, что внутри. Так он пойдёт в реализацию. Если ему надо использовать - то он посмотрит в API. А тут для человека в теме - rx_lane_injector - что-то инжектирует в RX Lane. Смотрит какой тип - понятно, что инжектирует пакеты. Английским по белому же написано. Уже понятно для чего это нужно. Ну и раз оно что-то делает, то это явно класс - есть же поведение. Но если надо узнать API, или поддерживать - то в определение - а там видно, что это класс, и видно, что это UVM компонент. Те, кто занимается верификацией из этого уже много чего вынесут - это основная библиотека. Это как вам std::string - уже всё понятно, и что нужно, и какие методы есть, и как этим пользоваться.

класс и структура - это одно и то же. enum - ALL_CAPS. по хорошему, нет никакой разницы, что перед глазами - класс, юнион, енум, если им даны правильные названия, из которых понятно за что они отвечают и что они делают. А если нужны подробности - то всё-равно пойдёшь в объявление, а там, например: ethernet_channel_packet_injector rx_lane_injector; вроде уже понятнее. Если нужно ещё конкретику, тогда идёшь в определение, а там и вовсе нет сомнений class ethernet_packet_injector: public uvm::uvm_component { ... }

Да они все одинаковые. Нет среди них тех, кто лучше или хуже. Все - хуже)

А почему бы ему ментор переименовывать в PCB? У ментора основной набор продкутов был куда шире. Целый набор продуктов Questa, Catapult, Tessent, Calibre, конечно же. И все они не имеют ничего общего с PCB. А вот Mentor Graphics на Siemens - вполне себе поменяли.

Через systemc. А systemc - через uvmc к любому симулятору, ну или можно через вендорозависимые TLI или UVM-ML.

Пустые места OpenOCD по умолчанию тоже пропускает, если брать elf в качестве источника. Но именно пустые области памяти, а не те, которые заполнены единицами намеренно - в коде. А переписывать только несовпадающие места - это зависит от того, написано это в драйвере флэш памяти в OpenOCD, например, я, когда писал драйвера всегда делал так, чтобы пользователи всегда использоовали полное стирание памяти при прошивке, и очень часто заказчикам этого хватало, и они после не улучшали. Хотя, я не щупал самую последнюю версию OpenOCD, поэтому со 100% вероятностью утверждать не буду, может там есть уже более аккуратная версия работы с flash, но скорее всего до сих пор так, как я описываю.

Да. В OpenOCD есть команда verify_image, по результатам которой можно определить, требуется ли прошивка.

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

Если правильно помню, то "безопасность" Rust - это решение гонок при доступе к памяти. То, что в C++ тоже уже давно решённая проблема, но не средсствами языка, а архитектурно. В C++ это вообще проблема только для программистов с низкой квалификацией, которые даже не знают, что такая проблема была, и что решение - уже давно есть. Ещё пара вещей, которую решает rust - это использование после освобождения и переполнение буфера. В C++ тоже решается с помощью fortify и санитайзерами. Никакого волшебства.

Как правило, все вендоры у меня нормально конвертировали, если схема проходит xml lint. Могло не хватать каких-то полей. И даже баги находили, которые вендор потом правил. Но на моей памяти, проблема была не в cadence, а в инженерах, которые не умеют читать.