[AntonB 0]

Посоветуйте материал для изучения UVM ?

[one_eight_seven 0]

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

[Кнкн 1]

13 hours ago, AntonB said:

Посоветуйте материал для изучения UVM ?

uvm_cookbook от Mentor

 

[one_eight_seven 0]

1 hour ago, Кнкн said:

uvm_cookbook от Mentor

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

Сейчас, когда достаточно уверенно владею UVM, Cookbook уже полезнее (а учебники - наоборот, уже не нужны): как раз смотрю концепции, чтобы освежить память, а как написать код уже и без кукбука ясно.

Edited July 15, 2021 by one_eight_seven

[attaboy 0]

Вот например https://fpga-systems.ru/publ/napravlenie/verifikacija/uvm_obshhie_svedenija_i_organizacija_metodologii/57-1-0-132

Плюс там ещё есть несколько стримов по этой теме.

[Tpeck 0]

А без знания SV и ООП имеет смысл начинать разбираться в данной теме или нет?

[one_eight_seven 0]

3 minutes ago, Tpeck said:

А без знания SV и ООП имеет смысл начинать разбираться в данной теме или нет?

Зачем? Правда интересно.

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

Edited July 15, 2021 by one_eight_seven

[Tpeck 0]

6 minutes ago, one_eight_seven said:

Зачем? Правда интересно.

 

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

Формирую тестовое воздействие сторонним софтом, читаю из файла, записываю в файл. Проверяю результат сторонним софтом.

PS или это просто хайповая тема, как system generator от Matlab лет 8-10 назад.

[RobFPGA 11]

Приветствую!

6 minutes ago, Tpeck said:

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

IMHO если вы разработчик, а не верификатор. Если работаете один или в маленькой команде без разделения обязанностей то UVM только усложнит вам жизнь особенно в начальный период. 

 

Удачи! Rob.

[one_eight_seven 0]

Этой теме очень много лет. Это не просто хайповая тема, а стандарт в индустрии.

Облегчит жизнь или нет - понять невозможно. Формировать воздействие сторонним софтом UVM не запрещает. Как и проверять результат сторонним софтом.

Проверку сторонним софтом, вообще, в этом случае имеет смысл сделать частью uvm_scoreboard'а

А вот формирование воздействий внешним софтом - это вопрос спорный. Я пока не встречал инструмента по формированию рандомизированных воздействий лучше, чем в SystemVerilog. Удобнее сделали разве что в PSS, но PSS мало распространён, и его генераторы, как правило, формируют воздействие на уровне UVM Register Layer.

Второе, что крайне удобно - это модель покрытия. Понятно, что её можно сделать и без UVM, на чистом SystemVerilog. Но тут у нас - третье:

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

Edited July 15, 2021 by one_eight_seven

[Tpeck 0]

4 minutes ago, RobFPGA said:

IMHO если вы разработчик, а не верификатор. Если работаете один или в маленькой команде без разделения обязанностей то UVM только усложнит вам жизнь особенно в начальный период. 

А вы используете его?

[AntonB 0]

4 минуты назад, one_eight_seven сказал:

Я пока не встречал инструмента по формированию рандомизированных воздействий лучше, чем в SystemVerilog.

Ну как по мне, то cocotb в этом плане неплох

[Tpeck 0]

4 minutes ago, one_eight_seven said:

Этой теме очень много лет. Это не просто хайповая тема, а стандарт в индустрии.

 

Последний год она как-то на слуху. 

5 minutes ago, one_eight_seven said:

А вот формирование воздействий внешним софтом - это вопрос спорный. Я пока не встречал инструмента по формированию рандомизированных воздействий лучше, чем в SystemVerilog. Удобнее сделали разве что в PSS, но PSS мало распространён, и его генераторы, как правило, формируют воздействие на уровне UVM Register Layer.

А что понимается в индустрии под рандомизированными воздействиями?

6 minutes ago, one_eight_seven said:

Второе, что крайне удобно - это модель покрытия. Понятно, что её можно сделать и без UVM, на чистом SystemVerilog. Но тут у нас - третье:

Третье - если вы делаете UVM тестбенч, то другие инженеры уже понимают, где и что у вас должно находиться, и где искать интересующих их кусок кода.

В общем  - имеет смысл хотя бы понять, что это такое и с чем его едят. Спасибо.

[RobFPGA 11]

Приветствую!
 

2 minutes ago, Tpeck said:

А вы используете его?

Сейчас нет  - года 3-4 назад были попытки  освоить.  Но  не потянули. :(.   Но  некоторые идеи UVM  используем в своих  тестах.  

 

Удачи! Rob.

[AntonB 0]

Вообще мне кажется что через всякие FLI, VPI и DPI верификация уже должна переходить на C++, C и тд