Jump to content
    

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

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

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

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

Share this post


Link to post
Share on other sites

15 hours ago, OparinVD said:

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

4 hours ago, dxp said:

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

....

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

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

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

Share this post


Link to post
Share on other sites

Quote

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

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

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

Share this post


Link to post
Share on other sites

8 minutes ago, one_eight_seven said:

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

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

10 minutes ago, one_eight_seven said:

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

2 hours ago, Amurak said:

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Про критическую массу... Без готовых 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, тут изложены основные принципы работы основных компонентов и организация тестбенча в целом. С этой книжкой уже можно создавать что-то боевое)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

1 hour ago, des00 said:

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

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

 

Share this post


Link to post
Share on other sites

23 minutes ago, Кнкн said:

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...