[one_eight_seven 6]

Да, прекомпилированная библиотека есть. Почему бы не пользоваться?

Но меня насторожили два момента

1. Написано, что constrained random поддерживается, и в примере приведено как использовать рандом без ограничений. То есть, именно конструкция constraint не приведена. Это, конечно, не значит, что её нет. Просто как-то странно

2. бегло ничего не удалось найти по ковергруппам, и прочим прелестям функционального покрытия. Что снова не значит, что этого нет.

[Raven 11]

15 hours ago, OparinVD said:

что-то новое сейчас осваивать вряд ли возьмёмся, будем прикручивать вивадовский xsim, а он вроде из коробки знаком с uvm

Сдается мне, что это будет скорее одно мучение, без гарантированного выхода чего-то полезного. Берите в руки VCS или QuestaSim, читайте туториалы о выстраивании UVM тестбенча (вдобавок к упомянутым книгам и мануалам), ну и постепенно его выстраивайте. После набора критической массы процесс пойдет. По крайней мере, все затраченные усилия не пропадут.

Вот, кстати, неплохой ресурс по UVM/verification:

• http://www.testbench.in/

[dxp 65]

13 часов назад, one_eight_seven сказал:

Ведь при вашем подходе зачем вообще тестировать? Ведь идеальные сущности могут сразу писать код так,  что в мастере всё работает, верно? Или люди всё-таки будут совершать оишбки - с этим ничего не поделать, и лучшее, что можно сделать - это как можно быстрее исправить эти ошибки? Задача CD - как можно быстрее  показать ошибку.

Речь не про то, что всё работает в продукте, а про то, что оно не ломается на сборке. Когда ломается на сборке -- это просто мешает остальным работать с этой базой.

13 часов назад, one_eight_seven сказал:

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

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

И это простой случай, который лечится на раз -- и диагноз сразу ясен, и метод лечения тривиален. А бывают варианты похуже, когда при слиянии конфликты возникают, неправильное разрешение которых ломает логику работы. Поэтому в нашей группе мы делаем заливку в общую ветку только через merge request: к записи в эту ветку имеет доступ один человек, он, получив MR, просто запускает прогон: общий функциональный тест, цель которого выявить ошибки типа "отсутствует файл", правильность соединения модулей на топе, какое-то минимальное тестирование проекта в сборе, идёт тест недолго, после чего проект запускается на синтез -- идёт проверка целостности другим тулом. PnR не делается, т.к. это долго и на этом этапе не  нужно, т.к. цель -- обеспечить целостность кодовой базы, чтобы любой член группы мог в любой момент взять из общей ветки топ и стоить на нём свою фичеветку, будучи уверенным, что его работа не станет колом, из-за чужих ошибок.

Описанное -- это ещё не  CI. CI идёт следом по цепочке -- там полная сборка и расширенный набор тестов (в перспективе и в железе на стенде). Здесь же главное -- не сломать сборку и тем самым не тормозить работу других членов группы.

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

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

[Raven 11]

4 hours ago, dxp said:

Речь не про то, что всё работает в продукте, а про то, что оно не ломается на сборке. Когда ломается на сборке -- это просто мешает остальным работать с этой базой.

....

Элементарная дисциплина -- нерабочие, непроверенные на целостность собираемости правки не попадают в общую базу, которая является стартовой точкой для новых фич/фиксов для всех членов группы.

+1. Даже не понимаю, как может в голову прийти иное. К MR должна прилагаться ссылка на успешные логи/прогоны (возможно, запущенные в CI вручную):

• сборки проекта
• некоторого минимального набора тестов - sanity tests, smoke tests - называют по-разному.
• если MR фиксит баг или добавляет feature - то еще и успешный лог теста на этот баг или feature

[one_eight_seven 6]

Quote

+1. Даже не понимаю

О, а вот это, НАКОНЕЦ, правильная мысль.

Так попробуйте понять, поумнеть, а не настаивать на своём неправильном непонимании, и транслировать его как единственно верное. Вот вам ещё для размышления. Merge Request,  Pull Request - это не для CD. Это для Open source.

[Raven 11]

8 minutes ago, one_eight_seven said:

Вот вам ещё для размышления. Merge Request,  Pull Request - это не для CD. Это для Open source.

Это никто и не утверждал. Просто MR/PR хорошо укладывается в процедуру работы больших коллективов разработчиков.

10 minutes ago, one_eight_seven said:

О, а вот это, НАКОНЕЦ, правильная мысль.

Так попробуйте понять, поумнеть, а не настаивать на своём неправильном непонимании, и транслировать его как единственно верное.

Я полностью открыт для просветления. Поясните, пожалуйста, конкретнее, как по вашей методе предполагается противостоять тем проблемам, о которых выше поведал @dxp.

[dxp 65]

MR, кстати. необязательная вещь, вполне несложно и руками сливать, тут нужно просто аккуратность и некоторая дисциплинированность. Это может делать любой член команды самостоятельно. Но люди неидеальны, и всегда хватает раздолбаев, которые регулярно будут ломать общую кодовую базу -- не по умыслу, по недосмотру/лени. Если каждый участник группы перед заливкой выполняет вот такой проверочный прогон, то всё ок. Проблема в том, что на практике этого не происходит -- люди забывают, а некоторые забивают на это (в open-source это просто непреодолимая проблема в принципе). Поэтому ограничение  по записи в общую ветку является просто предохранительной мерой. В итоге, в базе всегда лежат хорошие комиты, и история этой ветки не замусорена горбатыми комитами, а красиво подчёркивает фичи/фиксы с помощью комитов слияния.

Ну, а MR используется просто потому, что оно есть в софте -- как средство уведомления и как средство слияния. Безо всяких проблем сливать можно и руками (git merge --no-ff -e <branch> всего-то делов). И вообще, для этой операции и человек-то не нужен -- можно скрипт написать, который будет брать MR, прогонять, если успех, сливать в общую ветку. Но мы пока не достигли ощущения необходимости автоматизации на таком уровне. 

[Amurak 0]

On 7/19/2023 at 10:11 AM, Raven said:

+1. Даже не понимаю, как может в голову прийти иное. К MR должна прилагаться ссылка на успешные логи/прогоны (возможно, запущенные в CI вручную):

• сборки проекта
• некоторого минимального набора тестов - sanity tests, smoke tests - называют по-разному.
• если MR фиксит баг или добавляет feature - то еще и успешный лог теста на этот баг или feature

Да на такое нужна отдельная верификатошная с личным датацентром.

[Raven 11]

2 hours ago, Amurak said:

Да на такое нужна отдельная верификатошная с личным датацентром.

А кто сказал, что будет легко? 🙂 Хотя начинать можно с нескольких верификаторов и 1 сервера. Кстати, проверочные сборки/тесты участники процесса на таком начальном этапе могут на своих машинах делать, если они у них не совсем чахлые.

[kirill70674 5]

В 18.07.2023 в 19:00, OparinVD сказал:

что-то новое сейчас осваивать вряд ли возьмёмся, будем прикручивать вивадовский xsim, а он вроде из коробки знаком с uvm

Гиблое это дело - XSIM... Не знаю как с VHDL, но некоторые синтезируемые конструкции из SystemVerilog этот симулятор не переваривает, и что там написано в тестбенче - уже не имеет значения, поскольку проект не компилируется. QuestaSim так же знаком с UVM из коробки и подобных проблем с ним не было.

[kirill70674 5]

В 18.07.2023 в 22:33, Raven сказал:

Сдается мне, что это будет скорее одно мучение, без гарантированного выхода чего-то полезного. Берите в руки VCS или QuestaSim, читайте туториалы о выстраивании UVM тестбенча (вдобавок к упомянутым книгам и мануалам), ну и постепенно его выстраивайте. После набора критической массы процесс пойдет. По крайней мере, все затраченные усилия не пропадут.

Вот, кстати, неплохой ресурс по UVM/verification:

• http://www.testbench.in/

Про критическую массу... Без готовых VIPов накопить её действительно не просто, но не невозможно. Для разработки простых (отрабатывают какой-то один сценарий записи/чтения) VIPов, допустим для семейства AXI4, при использовании определённый литературы, достаточно 1.5-2 месяцев(личный опыт). Когда доморощенные VIPы готовы, построить UVM-тестбенч - вопрос умения перенести идеи из книжек в текстовый редактор.

Но главный вопрос тут - зачем? Зачем заморачиваться с UVM на ПЛИС, ведь как отметил коллега выше, есть возможность потестить прошивку в скорейшем времени на реальной железке...

Здесь, я думаю, нужно смотреть:

1. Долгоиграющий ли проект или нет
2. "Какова цена лжи?", всмысле отказа

 Если проект не на год и не на два, и (или) цена отказа, напрмер, - уничтоженное изделие (в котором ПЛИС - явно не самый дорогой компонент), если отказ ПЛИС приведёт к выведению изделия из строя (черевато внеплановыми командировками), то ответ очевиден - подходить к верификации нужно серьёзно.

И речь тут не о "настоящей UVM с VIPами от Cadence, Mentor и т.п.". Давайте взглянем правде в глаза - не будет этого повсеместно, тем более в отделах по разработке на ПЛИС. Речь о том, чтобы хоть как-то понизить вероятность отказа, увеличить масштабируемость и максимизировать переиспользуемость наработок. Применение UVM даёт определённые гарантии как минимум по последним двум пунктам. Первый пункт зависит, конечно, от того кто пишет и как, UVM тут - серьёзное подспорье.

Итог: Использование UVM - это "игра в долгую".

Основная литература (должно хватить для первых боевых тестов):

1. Ray Salemi - The UVM Primer. An Introduction to the Universal Verification Methodology (к ней прилагается репозиторий с рабочими примерами https://github.com/raysalemi/uvmprimer. Примеры из книжки - школьные, т.е. хороши для понимания принципов, но не для реальной практики)
2. UVM Cookbook (от Siemens, тут изложены основные принципы работы основных компонентов и организация тестбенча в целом. С этой книжкой уже можно создавать что-то боевое)

[des00 25]

ИМХО не боги горшки обжигают, на простом уровне освоить UVM с нуля дело месяца-двух, литература приведена выше, принципы построения там общие с AVM, OVM, VMM. До кучи есть вот такой ресурс UVM – ClueLogic краткая выдержка из некоторых, не совсем очевидных моментов UVM

[Кнкн 5]

1 hour ago, des00 said:

ИМХО не боги горшки обжигают

Скажите, пожалуйста, имеет ли смысл использование Portable Stimulus (PSS) ?

 

[des00 25]

23 minutes ago, Кнкн said:

Скажите, пожалуйста, имеет ли смысл использование Portable Stimulus (PSS) ?

 

это к гуру, свои uvm тесты я делал полностью самостоятельно, без VIP и всего такого. Да, это примитивизм, но мне было достататочно, очень редко ошибка уходила в железо. В основном это были не покрытые тестами конфигурации, которые при добавлении нужного сценария показывали эту ошибку и позволяли быстро все локализовать)

[OparinVD 0]

Не стал отдельную тему заводить

Порекомендуйте, пожалуйста, какой симулятор взять  с фтп, чтоб был полноценный, был совместим с vivado 2022.2, желательно работал под убунтой, ну и самое важное - с рабочей таблеткой ))