Я либо упустил, либо Вы не указывали - машина связывается с интернетом каким-либо образом? Интересует в контексте возможности перехвата управления удалённо.
В таком случае правильнее было бы говорить о GLS(Gate level simulation) как этапе верификации, а не о STA.
Плюс, imho, в вашем сообщении цифровой и аналоговый маршрут смешался — не совсем понятно как Вы связываете STA+констрейны(цифровой маршрут) и экстракцию паразитов(аналоговый маршрут).
1. Вообще я не очень понимаю смысл делать объектно-ориентированный тестбенч без использования библиотеки OVM/UVM и т.к. многие базовые вещи в ней уже есть и не нужно делать свой велосипед. Ну в вашем случае всё получилось статичным, а не динамичным. Так не делают, потому что при сборке тестбенча из нескольких UVC вы не сможете это всё подключить. Ну и библиотеку не сможете использовать, т.к. там для этого есть специальный базовый класс ovm_env/uvm_env.
2. Честно говоря не соглашусь. Потому что по сущности этих мониторов не будут отличаться друг от друга. А в более сложных интерфейсах у вас будет большое дублирование кода, т.к. операция записи от операции чтения как правило не очень сильно отличается. Если хочется отделить одни транзакции от других, то наверно проще поставить второй экземпляр scoreboard, но подключить его иначе (expected брать из модуля, observed из окружения).
Касательно более сложных проектов. Вот пример OVM монитора и UVM монитора. На мой взгляд там все очень наглядно выглядит.
3. В этом будет свой смысл, когда вы будете делать reuse готовых модулей(UVC). И вместо того, чтобы соединять в тестбенче интерфейс, DUT и модуль с ассершенами, вы будете подключать только интерфейс и DUT. Вероятность ошибки сильно снижается. В итоге вы получаете уже отлаженный интерфейс, который нужно лишь подключить и использовать.
В любом случае успехов вам в освоении выбранной профессии!
Хорошая статья, этой темы практически нет на хабре.
Возникло несколько вопросов:
1. Не думали портировать всё на UVM?
2. Для чего необходимо разделять мониторы на два?
3. Не думали засунуть ассершены в интерфейс?
Мы первое издание печатали. Разделили на 3 части — получился неудобный, жутко скрипучий и тяжеленный монстр. По моим впечатлениям книга не пригодна для печати из-за существующей верстки.
Я сталкивался с двумя проявлениями — inside и динамические массивы. Первое выяснилось в ходе прототипирования модуля, второе случайно сам выяснил. Вообще, нашел вот табличку со списком поддерживаемых конструкций. Есть почти все, но почему-то не упоминаются классы и вещи связанные с constrained random verification.
где ж была ваша статья 3 года назад?) Очень хорошая подборка, спасибо вам большое, сам освежил некоторые тонкие моменты и младшим коллегам показал.
И хотел бы задать вопрос. Возможно я что-то упустил, но в своей практике столкнулся с очень ограниченной поддержкой SV конструкций САПРом от альтеры. Если это так, то в чем вы тогда моделируете? Сам я Занимаюсь разработкой ASICов и тут таких проблем нет.
Я либо упустил, либо Вы не указывали - машина связывается с интернетом каким-либо образом? Интересует в контексте возможности перехвата управления удалённо.
Плюс, imho, в вашем сообщении цифровой и аналоговый маршрут смешался — не совсем понятно как Вы связываете STA+констрейны(цифровой маршрут) и экстракцию паразитов(аналоговый маршрут).
Ну в общем-то любому дизайн-центру связанному с цифровой разработкой. МЦСТ, Байкал, Элвис, Миландр, Iva tech, Текон и другие.
Понятное дело используется не всё сразу и не во всех проектах. Но в целом — джентльменский набор.
2. Честно говоря не соглашусь. Потому что по сущности этих мониторов не будут отличаться друг от друга. А в более сложных интерфейсах у вас будет большое дублирование кода, т.к. операция записи от операции чтения как правило не очень сильно отличается. Если хочется отделить одни транзакции от других, то наверно проще поставить второй экземпляр scoreboard, но подключить его иначе (expected брать из модуля, observed из окружения).
Касательно более сложных проектов. Вот пример OVM монитора и UVM монитора. На мой взгляд там все очень наглядно выглядит.
3. В этом будет свой смысл, когда вы будете делать reuse готовых модулей(UVC). И вместо того, чтобы соединять в тестбенче интерфейс, DUT и модуль с ассершенами, вы будете подключать только интерфейс и DUT. Вероятность ошибки сильно снижается. В итоге вы получаете уже отлаженный интерфейс, который нужно лишь подключить и использовать.
В любом случае успехов вам в освоении выбранной профессии!
Возникло несколько вопросов:
1. Не думали портировать всё на UVM?
2. Для чего необходимо разделять мониторы на два?
3. Не думали засунуть ассершены в интерфейс?
И хотел бы задать вопрос. Возможно я что-то упустил, но в своей практике столкнулся с очень ограниченной поддержкой SV конструкций САПРом от альтеры. Если это так, то в чем вы тогда моделируете? Сам я Занимаюсь разработкой ASICов и тут таких проблем нет.