Comments 13
У вашем проекте не используется библиотека OVM, это просто объектно-ориентированный testbench. Но в целом очень не плохо. Не считая того, что эгоистичный аппарат не вернет мне деньги, если я внесу только половину стоимости
ENTER_MONEY:
if (wallet >= product_price) begin
next_state = GIVE_PRODUCT;
end else begin
next_state = ENTER_MONEY;
end
Хорошая статья, этой темы практически нет на хабре.
Возникло несколько вопросов:
1. Не думали портировать всё на UVM?
2. Для чего необходимо разделять мониторы на два?
3. Не думали засунуть ассершены в интерфейс?
Возникло несколько вопросов:
1. Не думали портировать всё на UVM?
2. Для чего необходимо разделять мониторы на два?
3. Не думали засунуть ассершены в интерфейс?
Спасибо!
1. Я здесь не использовал библиотеку OVM, я организовывал проект по схожей с методологией структуре и черпал оттуда основные идеи. Планирую ли я в будущем использовать ее или библиотеку UVM и портировать проект? Возможно.
2. Для Scoreboard нужна информация на основе которой будет рассчитан эталонный выход дизайна, который будет сравниваться с реальным выходом в Checker. По — этому не плохо создать два монитора, один для входа, второй для выхода. Вообще мне разделения на два монитора кажется уместным, поскольку один общий монитор будет выглядеть довольно сложно в подобном проекте или в проекте посложнее.
3. Как по мне всему свое место. Можно их засунуть и в интерфейс, но мне кажется гораздо удобней выделить для них отдельный файл, если их много или они большие. Если их один-два, тогда не вижу проблемы разместить их в интерфейсе.
1. Я здесь не использовал библиотеку OVM, я организовывал проект по схожей с методологией структуре и черпал оттуда основные идеи. Планирую ли я в будущем использовать ее или библиотеку UVM и портировать проект? Возможно.
2. Для Scoreboard нужна информация на основе которой будет рассчитан эталонный выход дизайна, который будет сравниваться с реальным выходом в Checker. По — этому не плохо создать два монитора, один для входа, второй для выхода. Вообще мне разделения на два монитора кажется уместным, поскольку один общий монитор будет выглядеть довольно сложно в подобном проекте или в проекте посложнее.
3. Как по мне всему свое место. Можно их засунуть и в интерфейс, но мне кажется гораздо удобней выделить для них отдельный файл, если их много или они большие. Если их один-два, тогда не вижу проблемы разместить их в интерфейсе.
1. Вообще я не очень понимаю смысл делать объектно-ориентированный тестбенч без использования библиотеки OVM/UVM и т.к. многие базовые вещи в ней уже есть и не нужно делать свой велосипед. Ну в вашем случае всё получилось статичным, а не динамичным. Так не делают, потому что при сборке тестбенча из нескольких UVC вы не сможете это всё подключить. Ну и библиотеку не сможете использовать, т.к. там для этого есть специальный базовый класс ovm_env/uvm_env.
2. Честно говоря не соглашусь. Потому что по сущности этих мониторов не будут отличаться друг от друга. А в более сложных интерфейсах у вас будет большое дублирование кода, т.к. операция записи от операции чтения как правило не очень сильно отличается. Если хочется отделить одни транзакции от других, то наверно проще поставить второй экземпляр scoreboard, но подключить его иначе (expected брать из модуля, observed из окружения).
Касательно более сложных проектов. Вот пример OVM монитора и UVM монитора. На мой взгляд там все очень наглядно выглядит.
3. В этом будет свой смысл, когда вы будете делать reuse готовых модулей(UVC). И вместо того, чтобы соединять в тестбенче интерфейс, DUT и модуль с ассершенами, вы будете подключать только интерфейс и DUT. Вероятность ошибки сильно снижается. В итоге вы получаете уже отлаженный интерфейс, который нужно лишь подключить и использовать.
В любом случае успехов вам в освоении выбранной профессии!
2. Честно говоря не соглашусь. Потому что по сущности этих мониторов не будут отличаться друг от друга. А в более сложных интерфейсах у вас будет большое дублирование кода, т.к. операция записи от операции чтения как правило не очень сильно отличается. Если хочется отделить одни транзакции от других, то наверно проще поставить второй экземпляр scoreboard, но подключить его иначе (expected брать из модуля, observed из окружения).
Касательно более сложных проектов. Вот пример OVM монитора и UVM монитора. На мой взгляд там все очень наглядно выглядит.
3. В этом будет свой смысл, когда вы будете делать reuse готовых модулей(UVC). И вместо того, чтобы соединять в тестбенче интерфейс, DUT и модуль с ассершенами, вы будете подключать только интерфейс и DUT. Вероятность ошибки сильно снижается. В итоге вы получаете уже отлаженный интерфейс, который нужно лишь подключить и использовать.
В любом случае успехов вам в освоении выбранной профессии!
Универсальный — значит избыточный. UVM библиотека требует больших трудозатрат на поддержку сопутствующей инфраструктуры, компонент и т.д… Если у тебя маленькие, не частые проекты с отсутствием стандартных интерфейсов. То использование ОО-методологии(собственно описана в статье) верификации без UVM библиотеки, может занимать сильно меньше времени. Тем более что для неё требуется поддержка со стороны симулятора.
Справедливости ради, в серьезных компаниях повсеместно используют UVM-инфраструктуру.
UFO just landed and posted this here
Ссылку починил.
Вообще тестировалось все связанное с приемом и выдачей автоматом «заказов» и проверка корректного его поведения. В спецификации в статье я раскрыл мало деталей, так ка хотел сделал основной упор на структуру тестбенча, поэтому, если Вам интересно узнать больше подробностей, я могу выслать вам документ где Вы сможете их найти (правда он на украинском)
Вообще тестировалось все связанное с приемом и выдачей автоматом «заказов» и проверка корректного его поведения. В спецификации в статье я раскрыл мало деталей, так ка хотел сделал основной упор на структуру тестбенча, поэтому, если Вам интересно узнать больше подробностей, я могу выслать вам документ где Вы сможете их найти (правда он на украинском)
В ИТМО Шалыто мощно задвигал за верификацию автоматов когда я там учился. У него на сайте много материалов по этой теме http://is.ifmo.ru/verification
С одной стороны тема казалось довольно перспективной — верификация позволяет действительно достичь высоких гарантий качества, а верифицировать автоматы проще чем произвольный код. С другой — программы надо либо сразу делать в виде конечного автомата, либо как-то приводить к этому виду (были там дипломы посвященные этой теме). Но это сложно и неудобно для программ в общем виде.
С одной стороны тема казалось довольно перспективной — верификация позволяет действительно достичь высоких гарантий качества, а верифицировать автоматы проще чем произвольный код. С другой — программы надо либо сразу делать в виде конечного автомата, либо как-то приводить к этому виду (были там дипломы посвященные этой теме). Но это сложно и неудобно для программ в общем виде.
По поводу верификации могу посоветовать cocotb и писать тестбенчи на Python. Открываются широчайшие возможности по моделированию схемы, сокращается время написания тестбенча. Правда моделирование происходит значительно медленней чем просто на System Verilog
Спасибо!
Я как то пробивал игратся с библиотекой MyHDL для Python. Действительно было проще, но скорость подкачивала и я решил двигатся по пути увеличения скорости роботы то-есть изучать System Verilog
Я как то пробивал игратся с библиотекой MyHDL для Python. Действительно было проще, но скорость подкачивала и я решил двигатся по пути увеличения скорости роботы то-есть изучать System Verilog
Sign up to leave a comment.
Верификация конечного автомата