one_eight_seven

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

Возможно. Но даже в том описании, что есть, видно, что пытались повторить средствами питона то, что имеется в языке SystemVerilog, даже названия функций взяли те же, что логично. Однако, нет нормального описания как этим пользоваться. Тот самый плюс питона, что документация на него меньше, чем на SV имеет и обратную сторону - весь новый функционал надо документировать, что не делается, и как пользщоваться рандомизацией - разбирайся сам. Приведены только самые тривиальные примеры. А уж понимание авторами таких вещей как "распределение" и "soft/hard constraint" и вовсе заставляет чесаться в самых неприличных местах. Например, форма функции считается авторами функцией распределения. А hard и soft constraint - видом возвращаемого значения, если bool, то это hard, а если численное значение - это soft. и всё бы ничего, но они сами пишут, что это соответствует SV hard/soft constraint'ам. Для справки - soft constraint в system verilog означает, что эти ограничения будут действовать, только если не конфликтуют с указанными позже soft constraint'ами или с любыми hard constraint'ами. hard же, в случае конфликтов просто не разрешится и вернёт ошибку.

Именно для них и используют UVM. Отдельно верифицируют блоки и системы блоков. Дальше соединяют это вместе и выполняют верификацию интеграции, уже на подмножестве тестов. Вы представляете сколько стоит набор масок хотя бы на 45 нанометров? Чтобы выпустить чип, в котором неизвестна работоспособность. И, кстати, когда это железо уже вышло - не видно, что внутри, что именно надо починить. Виден уже только сам факт неработоспособности. Системы прототипирования (haps, boston) крайне дороги, и уместить в них большой проект часто не удаётся - только отдельными частями. Во время верификации на симуляторе - есть полный контроль над агентами шин (формирование откликов, задержек, контроль целостности памяти и т.п.), в железе - нет Во время верификации на симуляторе - удобно собирать покрытие. В железе - нет. Также, во время верификации на симуляторе - прекрасно инжектируются ошибки. В железе - не очень прекрасно. Поддержка SV может быть заявлена, но реально её может не быть. Если правильно помню, такое было в ModelSim 10.1c, но с конкретной версией могу ошибаться. В нём просто не было ни covergroup, ни ограничений рандомизации. Мне попадались отдельные UVM опции - это больше относилось к отладке - запуск отдельных стадий UVM, трассирование транзакций, отдельные менюшки для работы с Register Access Layer, и автоматические генераторы тестов для Register Access Layer. Но сама функциональность SystemVerilog, необходимая для UVM за отдельную цену мне не попадалась.

Нет. Конечно, оно должно быть переведено в тот язык, для которого у вас UVM (он есть на e, SV, SystemC, может ещё на каких, я лично работаю с SV), чтобы дальше работал тестбенч, но само формирование воздействий делаете вы так, как вам удобно. Можете через системный вызов запустить вашу програму, которая генерирует файлы воздействия, и потом эти файлы считать в транзакцию. Можете воспользщоваться межъязыковым интерфейсом и вызвать генератор, как библиотеку. Это да. Но к UVM это уже мало отношения имеет. Но и тут UVM'у есть что предолжить - уже готовая фабрика с возможностью переопределения классов из командной строки без перекомпиляций и СМС.

Так это используется в полный рост в т.ч. и в SV-UVM. Только вот непонятно почему "должна"? Возможность есть. А дальше - кому как удобнее. Есть куча наследия с C/C++ - пожалуйста, есть вам интерфейс с C. Вообще, если вы сравните код на SV и код на SystemC (как раз C++) - то читаемость явно не в пользу последнего.

Воздействие (все настройки, данные и т.п.) описывается в виде класса транзакции (uvm_sequence_item). Настройки, данные и т.п. - это поля транзакции. Каждое воздействие рандомизируется. SystemVerilog предоставляет на уровне языка возможность описать ограничения этой рандомизации. Ограничить можно практически что угодно и как угодно: задать список конкретных значений, и выбирать из них, задать области значений, и настроить их распределение, как и распределение внутри этих воздействий. Но интересное - дальше. Эти ограничения включаются, отключаются и наследуются. И наследующий класс может как задать другие ограничения, так и просто их ужесточить (для, например, направленных тестов).

Если от поля dmac ничего не зависит, то приемлемо. Если от этого поля зависят другие поля при рандомизации, то лучше его ограничить на момент рандомизации, ну или, если оно вам нужно фиксированным, а не рандомизированным (как в примере), то можно задать его значение перед рандомизацией, а саму рандомизацию этого поля - отключить: class_object.variable_name.rand_mode( 0 );

Этой теме очень много лет. Это не просто хайповая тема, а стандарт в индустрии. Облегчит жизнь или нет - понять невозможно. Формировать воздействие сторонним софтом UVM не запрещает. Как и проверять результат сторонним софтом. Проверку сторонним софтом, вообще, в этом случае имеет смысл сделать частью uvm_scoreboard'а А вот формирование воздействий внешним софтом - это вопрос спорный. Я пока не встречал инструмента по формированию рандомизированных воздействий лучше, чем в SystemVerilog. Удобнее сделали разве что в PSS, но PSS мало распространён, и его генераторы, как правило, формируют воздействие на уровне UVM Register Layer. Второе, что крайне удобно - это модель покрытия. Понятно, что её можно сделать и без UVM, на чистом SystemVerilog. Но тут у нас - третье: Третье - если вы делаете UVM тестбенч, то другие инженеры уже понимают, где и что у вас должно находиться, и где искать интересующий их кусок кода.

Лучше переделать uvm_sequence. В принципе, вы можете получить handle к sequence'у через sequencer. Но лучше переделать код так, чтобы необходимое вам поле было в uvm_sequence_item'е. uvm_sequence_item передаётся по ссылке. Поэтому, изменения в них надо делать аккуратно. Т.е. если какие-то модули расчитывают на исходные данные, а вы их поменяли, у вас будут проблемы. В этом случае uvm_sequence_item можно скопировать (если это приемлемое решение).

Зачем? Правда интересно. Ну а прямой ответ на вопрос, собственно, зависит от ответа на это "зачем?". Если вас интересует техническая возможность, то да, конечно это имеет смысл, если есть нужда именно в UVM. SV и ООП просто придётся подтягивать параллельно. Даже плюсы есть у такого подхода - всегда под рукой живой и обоснованный производственной необходимостью пример.

Для изучения? Я быстро бросил эту затею, поскольку слишком много примеров даже не проходит этап элаборации в Xcelium и VCS, ну или компилируется в Questa, но только по той причине, что из элаборации часть проверок перенесенав runtime. А в runtime всё-равно не исполняется и падает с фаталами. Концепции - да, можно подсмотреть, но большинство из них есть в UVM User Guide. Сейчас, когда достаточно уверенно владею UVM, Cookbook уже полезнее (а учебники - наоборот, уже не нужны): как раз смотрю концепции, чтобы освежить память, а как написать код уже и без кукбука ясно.

Для самого начала - Vanessa's guide, uvm primer

Не забудьте сказать процессору о том, куда переложили таблицу векторов. SBC->VTOR P.S. и располагать таблицу векторов нельзя где попало. Нужно выровнять. Не знаю, какой из stm32 имеется в виду, но обычно выравнивание требуется по границе 128 или 256 байт.

А стоило понять, что установка скобок всегда решает напрочь проблему неустановленных скобок. Решает только эту проблему, и никакую другую, но решает. А также стоило заметить, что проблема не надуманная, и она существует в коллективах разработчиков и при поддержке чужого кода. По этой причине её и внесли в MISRA: если проблему можно решить на корню, то разве есть причины её не решить? И разработчики стандарта приняли за многих других решение, которое является обязательным в той области, для которой они принимались.

Мне вот этот классический пример ошибок нравится: if(one) if(two) foo(); else bar(); Тоже встречал. Как правильно сказал выше Сергей Борщ, это делают новички. Но зато код какой читаемый!

Ну вот видите "и многий другой мусор" Скобки ничего не заслоняют. Более того, если после if/else более, чем одна строка, скобки будут всё равно. И не нужно строить из себя инвалида по зрению, который резко слепнет, когда после if/else одна строка, и прозревает, когда их две и больше. Хотя бы по той причине, что для того, чтобы посчитать одна там строка или две - уже надо иметь зрение. Отмазка жалкая и мерзкая.

Вот прямо убрали скобки и код стал рабочим? Или всё-таки проблемы были в другом? Дело в том, что в моём случае я действительно просто добавил скобки, и код стал рабочим.

Да всем понятно, откуда это там и для чего. У меня лично был опыт, когда любители не ставить скобки написали офигенный код, где отступами выделили желаемое, а скобочек не поставили, без скобочек же читаемый код. И всё работало, потому что именно в этот 'else' код у тех ребят не заходил. И сделано это было в библиотеке. А я месяц искал ошибку у себя в коде, который эту библиотеку использовал, а он именно в этот 'else' заходил. И всё в той ситуации было прекрасно: - Была и библиотека которая "годами работала и проблем не было" - "Мы этой библиотекой 7 лет пользуемся, точно у тебя в коде проблема" - месяц моих поисков ошибки у себя в коде, я уже настолько дебильными тестами свой код покрыл, что сам чуть не двинулся. В итоге, когда я залез в код библиотеки, очень быстро нашёл ошибку, поставил скобки и всё заработало. Но, когда показал тем, кто эту библиотеку говнокодил, то их аргументы против скобок были такие же, как и у адептов бесскобочности в этом треде. Причём звучало и фееричное "В моей практике вообще таких проблем никогда не было",- и не смущало, что разборка вообще велась из-за потерянного месяца работы по той причине что именно в их практике это случилось, и именно о том, что случилось разговор и ведётся. Да и вообще: "В моей практике проблем не было".- это как тот анекдот, когда мужик упал с 55 этажа, пролетает мимо 17-го, и думает: "Ну, пока всё не так уж плохо".

Давайте я вас опять поправлю. Обрамление тела if/else в скобки не вызывает ошибку компиляции. Я уже выше просил привести пример такого, и примера привести никто не смог. Наоборот, ошибку компиляции можно получить, одновременно отказавшись от фигурных скобок и криво написав макро. От кривых макро, конечно, нужно отказываться, даже если мы пишем код с фигурными скобками. Но, повторюсь, обрамление тела условного оператора в фигурные скобки не вызывает ошибку компилятора. Хватит уже.

А почему вы мне это адресуете? макро в стиле "срать и мазать" без do..while(0) привёл не я. P.S. И опять же, без do...while(0) проблемы возникают без фигурных скобок, а не при их наличии.

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

Я выше код написал, который компилируется и работает. Он прямо калька с вашего. Т.е. "Поздравляю, господин Соврамши",- вашу правоту он не иллюстрирует, а иллюстрирует как раз обратное. И да, в misra советуют отказываться от function-like macro. Совершенно не имеющим связи с окражающей реальностью бредом он был.

Понятно, стиль кодирования "срать и мазать" может испортить любую идею. Это понятно. Это не установка фигурных скобок компиляцию ломает, а плохое макроопределение. Можно вообще в макро только одну скобку оставить и требовать, чтобы её закрывали явно. Ну и раз уж тема про Misra, почитайте что там написано про function-like macro. P.S.: #include <stdio.h> volatile int dummy = 18; volatile int * p_dummy = &dummy; int something; #define BBB() { int i = *(int*)p_dummy; something = i - (1 << 2); } int main() { int c = 1; if ( c ) { BBB(); printf( "if\n" ); } else { printf( "else\n" ); } return 0; } Кстати, опять же даже так - тоже компилятор не ругается, и всё работает. -Wall -Wextra -pedantic ошибок и предупреждений нет.

И что? Если вы мне не хамите, то можете нести любой бред, а в чувство вас приводить никому нельзя? Разговор идёт про фигурные скобки после if/else, for, и т.п., вы рассказываете, что это вызывает ошибку компиляции. Ну потрудитесь привести формальное обоснование по теме, а не какие-то не относящиеся к делу макроопределения.

Вы трезвы? То, что вы сейчас несёте - это просто за гранью добра и зла. Расскажите, пожалуйста где эта ошибка заложена? Можно вот на этом примере: https://cs.wmich.edu/~gupta/teaching/cs4850/sumII06/The syntax of C in Backus-Naur form.htm А уж особенно интересно как эту чудовищную ошибку синтаксиса C (о которой вообще не известно, подозреваю, никому, кроме вас) решает исключение фигурных скобок.