[OparinVD 0]

Доброго дня!

В нашем проекте в последнее время на флаг подняли тему про "модульное тестирование". Смысл в том, что пришла пора построить взрослую верификацию, в связи с чем мы находимся на распутье. Я так понимаю, флагманом в отрасли является UVM, но начав копаться в теме, наткнулся на OSVMM, есть смысл на него смотреть? Привлекает, конечно, тем, что, как видится, цена входа существенно ниже, т.к. под синтез мы пишем именно на VHDL. Но не покидает ощущение, что это несколько суррогатное решение...  С SV я пока на "вы", так писал несколько testbench-поделок без ООП и читал книжки. Нужно принять волевое решение, в какую сторону копать, что посоветуете?

 

[Raven 8]

Так все-таки модульное тестирование (unit testing), или интегральное?

UVM - это больше про интегральное, а для Unit Testing есть свои подходы и фреймворки.

[one_eight_seven 3]

Если по-взрослому, то UVM. Никакого OSVMM в "по-взрослому" просто не существует. В общем-то как и VHDL - встречается, конечно, но в следовых количествах, и работать с ним никто не хочет, хоть это и более чем возможно.

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

On 7/14/2023 at 11:40 PM, Raven said:

Так все-таки модульное тестирование (unit testing), или интегральное?

UVM - это больше про интегральное, а для Unit Testing есть свои подходы и фреймворки.

Простите, а интегральное - это что за зверь такой?

Изменено 15 июля, 2023 пользователем one_eight_seven

[OparinVD 0]

"Модульное тестирование" - это пожалуй не очень удачный термин. У нас сейчас в принципе не достаточное покрытие на всех этапах. Мы как разработчики от себя конечно стараемся выдать проверенный продукт, но этого становится мало. Для начала хочется просто обмазаться авто-тестами для отдельных компонентов для ci/cd, а потом углубиться до чего-то более интеграционного

[one_eight_seven 3]

Так это вопросы вообще из разных областей.

CD - это (псевдонепрерывно) иметь ответ на вопрос: Мы можем сделать поставку прямо сейчас? И да, вы правильно определили, что для него нужен набор автотестов.

А методология верификации (UVM, например) - это способ создания таких тестов. В стандартизованной манере, используя уже наработанную вами и другими кодовую базу. И она очень помогает, если вы собираетесь изменять и развивать тестбенч, а особенно, если вы собираетесь брать уже существующий объём кода и как-то объединять и синхронизировать его с другим большим объёмом кода, в том числе и  не вашего производства. Но он окупит себя если вы правда собираетесь по-серьёзному заниматься верификацией - создавать отдел, писать документацию, покупать тулы (VCS, Xcelium, Questa) и VIP'ы (скорее всего - от тех же сименсов, синопсисов, каденсов), нанимать верификаторов, которые уже знают UVM, или растить своих. Если всего этого нет, если новый сотрудник пойдёт в верификацию не из верификаторов, а из дизайнеров, которые решили проверить свой же дизайн, а потом обратно пойдут дизайнить - такой путь может оказаться погибельным, да и не нужно это всё полутора землекопам.

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

Изменено 16 июля, 2023 пользователем one_eight_seven

[yes 5]

3 hours ago, one_eight_seven said:

CD - это (псевдонепрерывно) иметь ответ на вопрос: Мы можем сделать поставку прямо сейчас? И да, вы правильно определили, что для него нужен набор автотестов.

я бы поговорил о необходимости CD в нашем "бизнесе".
по любому - есть зарезервированное место (дата) в шатле или дата тэйпаута. то есть вопрос - зачем нужны промежуточные деливери на временном интервале от какой-то первой сборки до того самого тэйпаута. то есть какие-то силы и трудозатраты на поддержание этого конвеера непрерывной сборки нужны. опять же приходится больше мудрить с ветками в контроле версий, слияниями и т.д. то есть поддерживать "мастера" в всегда готовом состоянии.

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

у меня нет четкого понимания, нужно или нет это самое CD и прочие отработаные на софте подходы - agile и подобное шаманство.

------------

по поводу применения SV тестов к VHDL RTL - по моему никакой проблемы нет - у кэйденса была генерилка автоматом переходника с VHDL в SV, да и самому написать на питоне/авке/перле и т.п. не проблема, в каких-то простейших случаях - если порты только std_logic, std_logic_vector можно вообще просто вставить VHDL дизайн в SV тестбенч. дополнительных денег за миксед симуляцию, по-моему, сейчас никто не берет.
на VHDL много RTL пишут, особенно в европе. всякое высоконадежное железо большие фирмы только VHDL никакого verilog-а. (мое мнение - это дурь, но это есть).

но для тестов SV однозначно лучше VHDLя. часто применяется SV+C++ (наверно и VHDL имеет какой-то интерфейс к C, никогда не пользовал, но предполагаю, как и все в VHDL, этот интерфейс разработан для наказания разработчика, чтобы жизнь не казалась малиной)

нужно ли UVM - тут два, по моему, подвопроса - нужны ли сотни верификаторов для проекта (ну как муравьи, которые вроде как тащат большую добычу каждый в свою сторону, но все-таки затаскивают в муравейник). то есть первое назначение UVM для вот этой "муравьиной" организации. то есть некий стандарт как разделить работу на независимые части и распараллелить.
второй вопрос - появятся ли какие-то стандартные VIP для верификации - они все предполагают использование в UVM-е (ну по сути это те же самые муравьи, только часть работы сделана посторонними разработчиками - распараллелена на оутсорс)

какой-то исключительной сложности в UVM нету, но если нет опыта в ООП, то понять вообще зачем это все нужно (нафига козе баян) так сразу не получится. поэтому если основная идея - "саморазвитие", а условий с верификаторами и VIP не предвидится, то лучше написать тестбенч по SV-шным книжкам (они старые но еще годные - по памяти напишу авторов Бержерон (латинецей точно не осилю сейчас), Spear ... - они есть на фтп. там такая самодельная UVM на минималках разбирается

 

[Raven 8]

On 7/16/2023 at 12:55 AM, one_eight_seven said:

Простите, а интегральное - это что за зверь такой?

 

Имеется в виду тестирование модуля в составе системы или подсистемы, "в сборе", а также самой этой системы или подсистемы. Например, с помощью unit testing вы проверили функционал AXI-to-APB bridge в отдельности, а теперь встроили его в SOC и проверяете прохождение транзакций через этот мост, и весь прочий его функционал (до которого можно дотянуться) в составе системы - вот это я и назвал интегральным тестированием.

[one_eight_seven 3]

14 hours ago, Raven said:

Имеется в виду тестирование модуля в составе системы или подсистемы, "в сборе", а также самой этой системы или подсистемы. Например, с помощью unit testing вы проверили функционал AXI-to-APB bridge в отдельности, а теперь встроили его в SOC и проверяете прохождение транзакций через этот мост, и весь прочий его функционал (до которого можно дотянуться) в составе системы - вот это я и назвал интегральным тестированием.

Да, понятно, просто ошибка или опечатка в терминологии. Интеграционное. Нет, UVM - это не больше для интеграционного, это и для 'unit' - level. Только здесь его принято называвть Standalone IP verification, Standalone Subsystem Verification, думаю, мысль понятна.

 

14 hours ago, yes said:

по любому - есть зарезервированное место (дата) в шатле или дата тэйпаута. то есть вопрос - зачем нужны промежуточные деливери на временном интервале от какой-то первой сборки до того самого тэйпаута. то есть какие-то силы и трудозатраты на поддержание этого конвеера непрерывной сборки нужны. опять же приходится больше мудрить с ветками в контроле версий, слияниями и т.д. то есть поддерживать "мастера" в всегда готовом состоянии.

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

Касательно веток. Это не обязательно. Если есть CD, то тот, кто за него отвечает будет готов вырвать руки каждому, кто делает ветки. Потому что это форменное вредительство. Исключения бывают, но они  кратковременны.

И второе заблуждение - Мастер должен всегда быть в работоспособном состоянии. Тот, кто это сказал - немного не в себе. У мастера одна цель - единая кодовая база для всех. Все должны строить свой код на основе мастера и как можно скорее вливать его обратно в мастер. (если у вас CD и контроллируемая среда, контроллируемые разработчики. В OpenSource такое конечно не пройдёт.)

 

[dxp 34]

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

И второе заблуждение - Мастер должен всегда быть в работоспособном состоянии. Тот, кто это сказал - немного не в себе. У мастера одна цель - единая кодовая база для всех. Все должны строить свой код на основе мастера и как можно скорее вливать его обратно в мастер.

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

[OparinVD 0]

On 7/16/2023 at 9:23 PM, one_eight_seven said:

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

Тестирование в железе у нас есть, но не покидает ощущение не прикрытого зада :) У нас есть отдел тестирования, и они тестируют готовую прошивку на наборе прямых тестов. Есть сравнительное тестирование (тоже в железе) с версией софтовой реализации той же задачи. Поднимать отдел для верификации - это скорей не про нас. Будем сами переключаться с дизайна на верификацию. В качестве первого шага, вероятно, переложим существующие тесты с железа в симулятор, а в будущем снабдим каждый свой ipcore тестбенчем, который будет запускаться при необходимости перед сборкой, чтобы заранее выявить, что где-то порылась собака. С одной стороны хочется, чтобы тест был достаточно полным, чтобы спать спокойно, с другой стороны есть понимание, что мы вряд ли освоим кунг-фу в полном объеме. А в чем видится погибельность такого пути?

On 7/17/2023 at 1:40 AM, yes said:

я бы поговорил о необходимости CD в нашем "бизнесе"

Тут да, в полном смысле CD конечно нет. Есть git-lab, есть скрипты сборки, но полная сборка триггерится только вручную, ибо трёх-часовую имплементацию не назапускаешься на каждый чих. Есть желание, чтобы в рамках CD хотябы запускался симулятор.

[one_eight_seven 3]

8 hours ago, dxp said:

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

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

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

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

 

4 hours ago, OparinVD said:

А в чем видится погибельность такого пути?

Огромный пласт новых знаний. Большинство работы вы не делали просто никогда, и для этой работы не просто другие тулы (кстати, гораздо более дорогие), но ещё и совершенно другой синтаксис. А какие бонусы? Если не создавать отдел, который будет на фулл-тайм заниматься этим, если не покупать готовые VIPы, то бонусов-то нет.

Чтобы UVM просто собрать нужны тулы другого уровня. (VCS, XCELIUM, Questa Prime) А что вы получите от UVM - только систему фаз, ну и плюс управление рандомизацией и возможность написать нормально функциональное покрытие, но это не от UVM, это от более полной поддержки SV в этих тулах. Без специалиста по UVM в команде вы его всё-равно вполне не освоите в нормальные сроки. Дело тут не в том, что это сложно, объёмно, и прочее раздувание щёк, просто в опыте работы и в понимании на практике что почему и зачем делается. Хотя бы первый тестбенч лучше сосбрать вместе с мастером, а ещё парочку - хотя бы ревью сделать. Иначе это будет неоправданно долго.

Да и для того, что вы описали - UVM не особо нужен, тут больше нужна поддержка ограничений рандомизации и функционального покрытия. И простой class-based testbench, хотя бы по книжкам того же Криса Спира.

[OparinVD 0]

1 hour ago, one_eight_seven said:

тут больше нужна поддержка ограничений рандомизации и функционального покрытия

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

Я читал SystemVerilog For Verification и пробежал несколько быстрых гайдов по uml, и у меня сложилось впечатление, что uvm это "экранизация" по Крису Спиру. Отсюда и родилась идея попробовать uml, чтобы вручную не реализовывать те классы, которые в книжке описаны, а взять что-то готовое, где всё уже увязано между собой... ошибаюсь?

[one_eight_seven 3]

Не знаю. В вашем симуляторе есть прекомпилированная UVM? Если нет, то, скорее всего, нет поддерживаемых языковых конструкций. Если есть, то пользуйтесь. много проблем просто не возникнет из-за того, что они уже решены. Но много - наоборот,- возникнет, потому что это большая база чужого кода, и в ней надо ориентироваться.

[OparinVD 0]

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

[dmitry-tomsk 0]

20 minutes ago, OparinVD said:

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

hls  генерирует тестбенчи с использованием uvm , так что вивадо должен поддерживать