one_eight_seven 3 18 июля, 2023 Опубликовано 18 июля, 2023 · Жалоба Да, прекомпилированная библиотека есть. Почему бы не пользоваться? Но меня насторожили два момента 1. Написано, что constrained random поддерживается, и в примере приведено как использовать рандом без ограничений. То есть, именно конструкция constraint не приведена. Это, конечно, не значит, что её нет. Просто как-то странно 2. бегло ничего не удалось найти по ковергруппам, и прочим прелестям функционального покрытия. Что снова не значит, что этого нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Raven 8 18 июля, 2023 Опубликовано 18 июля, 2023 · Жалоба 15 hours ago, OparinVD said: что-то новое сейчас осваивать вряд ли возьмёмся, будем прикручивать вивадовский xsim, а он вроде из коробки знаком с uvm Сдается мне, что это будет скорее одно мучение, без гарантированного выхода чего-то полезного. Берите в руки VCS или QuestaSim, читайте туториалы о выстраивании UVM тестбенча (вдобавок к упомянутым книгам и мануалам), ну и постепенно его выстраивайте. После набора критической массы процесс пойдет. По крайней мере, все затраченные усилия не пропадут. Вот, кстати, неплохой ресурс по UVM/verification: http://www.testbench.in/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 34 19 июля, 2023 Опубликовано 19 июля, 2023 · Жалоба 13 часов назад, one_eight_seven сказал: Ведь при вашем подходе зачем вообще тестировать? Ведь идеальные сущности могут сразу писать код так, что в мастере всё работает, верно? Или люди всё-таки будут совершать оишбки - с этим ничего не поделать, и лучшее, что можно сделать - это как можно быстрее исправить эти ошибки? Задача CD - как можно быстрее показать ошибку. Речь не про то, что всё работает в продукте, а про то, что оно не ломается на сборке. Когда ломается на сборке -- это просто мешает остальным работать с этой базой. 13 часов назад, one_eight_seven сказал: Первый человек влил, пайплайн упал. все об этом знают. Ошибку исправили, снова влили, пайплан прошёл - значит починили, работаем дальше, не прошёл - чиним дальше. А то, что вы рассказываете - это лишь замедлить работу и всё-равно получить весь тот же геморрой, но плюсом к тому, ещё и разошедшуюся кодовую базу, и вместсо решения одной проблемы, одновременно решать две или три. Первый человек влил вчера вечером, а сегодня он в отпуске. Сборка сломалась потому, что человек недосмотрел и забыл просто исходный файл добавить в реп -- человек, в общем-то, квалифицированный и ответственный, но недосмотрел, бывает. Теперь (сегодня) его физически нет (уехал на Алтай), проект не собирается из-за отсутствия файла в репе. Вся остальная команда (8 человек) не может пользоваться этой кодовой базой -- приходится извращаться, откатываться на предыдущие стабильные комиты. И это простой случай, который лечится на раз -- и диагноз сразу ясен, и метод лечения тривиален. А бывают варианты похуже, когда при слиянии конфликты возникают, неправильное разрешение которых ломает логику работы. Поэтому в нашей группе мы делаем заливку в общую ветку только через merge request: к записи в эту ветку имеет доступ один человек, он, получив MR, просто запускает прогон: общий функциональный тест, цель которого выявить ошибки типа "отсутствует файл", правильность соединения модулей на топе, какое-то минимальное тестирование проекта в сборе, идёт тест недолго, после чего проект запускается на синтез -- идёт проверка целостности другим тулом. PnR не делается, т.к. это долго и на этом этапе не нужно, т.к. цель -- обеспечить целостность кодовой базы, чтобы любой член группы мог в любой момент взять из общей ветки топ и стоить на нём свою фичеветку, будучи уверенным, что его работа не станет колом, из-за чужих ошибок. Описанное -- это ещё не CI. CI идёт следом по цепочке -- там полная сборка и расширенный набор тестов (в перспективе и в железе на стенде). Здесь же главное -- не сломать сборку и тем самым не тормозить работу других членов группы. А то, как процесс встаёт колом, я повидал. В других подразделениях (программеры) исповедуют как раз описанный вами подход: все без ограничений льют в общую ветку и регулярно ломают сборку. Бывало, что не могли неделями привести в стабильное состояние -- одни багованные фичи накладывались на другие и разгрести это оказывалось не так просто. Коллега, который с этим работал, в итоге за три недели не дождавшись стабильного топа общей ветки, просто взял какой-то старый комит и пилил временно на основе него -- ему не нужны были эти новые правки, которые ломали сборку. Матерился, конечно. Если бы у них был вот этот этап предварительной проверочной сборки (просто на собираемость), когда проблема обнаруживается ещё до вливания кода в общую ветку и борьба с ней идёт в локальной фичеветке, то этого безобразия просто не было бы. Элементарная дисциплина -- нерабочие, непроверенные на целостность собираемости правки не попадают в общую базу, которая является стартовой точкой для новых фич/фиксов для всех членов группы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Raven 8 19 июля, 2023 Опубликовано 19 июля, 2023 · Жалоба 4 hours ago, dxp said: Речь не про то, что всё работает в продукте, а про то, что оно не ломается на сборке. Когда ломается на сборке -- это просто мешает остальным работать с этой базой. .... Элементарная дисциплина -- нерабочие, непроверенные на целостность собираемости правки не попадают в общую базу, которая является стартовой точкой для новых фич/фиксов для всех членов группы. +1. Даже не понимаю, как может в голову прийти иное. К MR должна прилагаться ссылка на успешные логи/прогоны (возможно, запущенные в CI вручную): сборки проекта некоторого минимального набора тестов - sanity tests, smoke tests - называют по-разному. если MR фиксит баг или добавляет feature - то еще и успешный лог теста на этот баг или feature Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
one_eight_seven 3 19 июля, 2023 Опубликовано 19 июля, 2023 · Жалоба Quote +1. Даже не понимаю О, а вот это, НАКОНЕЦ, правильная мысль. Так попробуйте понять, поумнеть, а не настаивать на своём неправильном непонимании, и транслировать его как единственно верное. Вот вам ещё для размышления. Merge Request, Pull Request - это не для CD. Это для Open source. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Raven 8 19 июля, 2023 Опубликовано 19 июля, 2023 · Жалоба 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 34 19 июля, 2023 Опубликовано 19 июля, 2023 · Жалоба MR, кстати. необязательная вещь, вполне несложно и руками сливать, тут нужно просто аккуратность и некоторая дисциплинированность. Это может делать любой член команды самостоятельно. Но люди неидеальны, и всегда хватает раздолбаев, которые регулярно будут ломать общую кодовую базу -- не по умыслу, по недосмотру/лени. Если каждый участник группы перед заливкой выполняет вот такой проверочный прогон, то всё ок. Проблема в том, что на практике этого не происходит -- люди забывают, а некоторые забивают на это (в open-source это просто непреодолимая проблема в принципе). Поэтому ограничение по записи в общую ветку является просто предохранительной мерой. В итоге, в базе всегда лежат хорошие комиты, и история этой ветки не замусорена горбатыми комитами, а красиво подчёркивает фичи/фиксы с помощью комитов слияния. Ну, а MR используется просто потому, что оно есть в софте -- как средство уведомления и как средство слияния. Безо всяких проблем сливать можно и руками (git merge --no-ff -e <branch> всего-то делов). И вообще, для этой операции и человек-то не нужен -- можно скрипт написать, который будет брать MR, прогонять, если успех, сливать в общую ветку. Но мы пока не достигли ощущения необходимости автоматизации на таком уровне. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Amurak 0 19 июля, 2023 Опубликовано 19 июля, 2023 · Жалоба On 7/19/2023 at 10:11 AM, Raven said: +1. Даже не понимаю, как может в голову прийти иное. К MR должна прилагаться ссылка на успешные логи/прогоны (возможно, запущенные в CI вручную): сборки проекта некоторого минимального набора тестов - sanity tests, smoke tests - называют по-разному. если MR фиксит баг или добавляет feature - то еще и успешный лог теста на этот баг или feature Да на такое нужна отдельная верификатошная с личным датацентром. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Raven 8 19 июля, 2023 Опубликовано 19 июля, 2023 · Жалоба 2 hours ago, Amurak said: Да на такое нужна отдельная верификатошная с личным датацентром. А кто сказал, что будет легко? 🙂 Хотя начинать можно с нескольких верификаторов и 1 сервера. Кстати, проверочные сборки/тесты участники процесса на таком начальном этапе могут на своих машинах делать, если они у них не совсем чахлые. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kirill70674 5 20 июля, 2023 Опубликовано 20 июля, 2023 · Жалоба В 18.07.2023 в 19:00, OparinVD сказал: что-то новое сейчас осваивать вряд ли возьмёмся, будем прикручивать вивадовский xsim, а он вроде из коробки знаком с uvm Гиблое это дело - XSIM... Не знаю как с VHDL, но некоторые синтезируемые конструкции из SystemVerilog этот симулятор не переваривает, и что там написано в тестбенче - уже не имеет значения, поскольку проект не компилируется. QuestaSim так же знаком с UVM из коробки и подобных проблем с ним не было. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kirill70674 5 20 июля, 2023 Опубликовано 20 июля, 2023 · Жалоба В 18.07.2023 в 22:33, Raven сказал: Сдается мне, что это будет скорее одно мучение, без гарантированного выхода чего-то полезного. Берите в руки VCS или QuestaSim, читайте туториалы о выстраивании UVM тестбенча (вдобавок к упомянутым книгам и мануалам), ну и постепенно его выстраивайте. После набора критической массы процесс пойдет. По крайней мере, все затраченные усилия не пропадут. Вот, кстати, неплохой ресурс по UVM/verification: http://www.testbench.in/ Про критическую массу... Без готовых VIPов накопить её действительно не просто, но не невозможно. Для разработки простых (отрабатывают какой-то один сценарий записи/чтения) VIPов, допустим для семейства AXI4, при использовании определённый литературы, достаточно 1.5-2 месяцев(личный опыт). Когда доморощенные VIPы готовы, построить UVM-тестбенч - вопрос умения перенести идеи из книжек в текстовый редактор. Но главный вопрос тут - зачем? Зачем заморачиваться с UVM на ПЛИС, ведь как отметил коллега выше, есть возможность потестить прошивку в скорейшем времени на реальной железке... Здесь, я думаю, нужно смотреть: Долгоиграющий ли проект или нет "Какова цена лжи?", всмысле отказа Если проект не на год и не на два, и (или) цена отказа, напрмер, - уничтоженное изделие (в котором ПЛИС - явно не самый дорогой компонент), если отказ ПЛИС приведёт к выведению изделия из строя (черевато внеплановыми командировками), то ответ очевиден - подходить к верификации нужно серьёзно. И речь тут не о "настоящей UVM с VIPами от Cadence, Mentor и т.п.". Давайте взглянем правде в глаза - не будет этого повсеместно, тем более в отделах по разработке на ПЛИС. Речь о том, чтобы хоть как-то понизить вероятность отказа, увеличить масштабируемость и максимизировать переиспользуемость наработок. Применение UVM даёт определённые гарантии как минимум по последним двум пунктам. Первый пункт зависит, конечно, от того кто пишет и как, UVM тут - серьёзное подспорье. Итог: Использование UVM - это "игра в долгую". Основная литература (должно хватить для первых боевых тестов): Ray Salemi - The UVM Primer. An Introduction to the Universal Verification Methodology (к ней прилагается репозиторий с рабочими примерами https://github.com/raysalemi/uvmprimer. Примеры из книжки - школьные, т.е. хороши для понимания принципов, но не для реальной практики) UVM Cookbook (от Siemens, тут изложены основные принципы работы основных компонентов и организация тестбенча в целом. С этой книжкой уже можно создавать что-то боевое) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 21 июля, 2023 Опубликовано 21 июля, 2023 · Жалоба ИМХО не боги горшки обжигают, на простом уровне освоить UVM с нуля дело месяца-двух, литература приведена выше, принципы построения там общие с AVM, OVM, VMM. До кучи есть вот такой ресурс UVM – ClueLogic краткая выдержка из некоторых, не совсем очевидных моментов UVM Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Кнкн 5 21 июля, 2023 Опубликовано 21 июля, 2023 · Жалоба 1 hour ago, des00 said: ИМХО не боги горшки обжигают Скажите, пожалуйста, имеет ли смысл использование Portable Stimulus (PSS) ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 21 июля, 2023 Опубликовано 21 июля, 2023 · Жалоба 23 minutes ago, Кнкн said: Скажите, пожалуйста, имеет ли смысл использование Portable Stimulus (PSS) ? это к гуру, свои uvm тесты я делал полностью самостоятельно, без VIP и всего такого. Да, это примитивизм, но мне было достататочно, очень редко ошибка уходила в железо. В основном это были не покрытые тестами конфигурации, которые при добавлении нужного сценария показывали эту ошибку и позволяли быстро все локализовать) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
OparinVD 0 22 июля, 2023 Опубликовано 22 июля, 2023 · Жалоба Не стал отдельную тему заводить Порекомендуйте, пожалуйста, какой симулятор взять с фтп, чтоб был полноценный, был совместим с vivado 2022.2, желательно работал под убунтой, ну и самое важное - с рабочей таблеткой )) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться