OVM/Advanced OVM/Session4 - Layering Sequences
Приветствую вас на четвертом занятии Продвинутого Курса по ОВМ и УВМ Академии Тестирования. На этом занятии мы поговорим о "многоуровневых последовательностях".
Итак, последовательности обычно выполняются на контроллерах последовательностей. У вас имеется стандартная архитектура открытого тестирования, в которой есть агент с контроллером последовательностей. На каждый контроллер по одному агенту. Операционная среда может определить последовательность по умолчанию, которая будет инициироваться на конкретном контроллере агента. Эта последовательность корректируется основным кодом, обычно кодом теста. Тест может задать другие последовательности, которые вы можете запустить одновременно с последовательностью по умолчанию или даже вместо последовательности по умолчанию. И затем сами последовательности генерируют элементы, посылаемые на драйвер, который в свою очередь преобразует сообщения в сигналы, посылаемые на тестируемое устройство, и получает ответный сигнал, после чего все повторяется.
Особенностью теста является возможность координации несколько последовательностей, запущенных на разных интерфейсах тестируемого устройства одновременно. Поэтому в стандартной операционной среде обычно имеется несколько агентов. Можно задать последовательность по умолчанию для каждого контроллера последовательностей. Тест может задать доп. последовательности, которые будут выполняться на всех агентах, с которыми вы имеете дело. И затем эти последовательности будут создавать сообщения, посылаемые на драйвера, и посылаемые затем на разные интерфейсы тестируемого устройства.
Чтобы координировать эти контроллеры при помощи теста, мы создаем тест, в котором содержатся экземпляры двух заданных последовательностей, располагаем их в виде «вилки» и запускаем эти две последовательности на данном контроллере. Так мы снова определяем путь к контроллеру, на котором начнется выполнение процесса, а именно: environment.my_agent1 или 2.my_sequencer. Это позволяет обеим последовательностям одновременно выполняться на двух контроллерах, подключенных к тестируемому устройству, что, собственно, и являлось нашей задачей. Но из-за того, что сегодня тесты полностью зависят от архитектуры и структуры операционной среды, вряд ли мы сможем использовать их повторно. Например, вы не сможете повторно использовать этот тест в немного другой операционной среде, потому что в тесте содержатся зависимости от основной архитектуры.
Вместо этого мы можем создать тестовую последовательность. Вместо того чтобы тест напрямую инициировал последовательности, мы можем создать тестовую последовательность, имеющую указатель заданного контроллера, на котором будут выполняться эти две последовательности. Из-за того, что тестовая последовательность сама не генерирует элементы, ее не нужно параметризировать, она может быть всего лишь расширением базового типа последовательности. Все, что нам нужно сделать, – это внести указатели обоих контроллеров, чтобы разрешить инициацию этой последовательности в любой среде, если мы хотим, чтобы она находилась под управлением двух контроллеров.
Теперь можно создать тест, который будет использовать эту тестовую последовательность. Итак, в тесте мы создаем экземпляр тестовой последовательности и вносим два указателя контроллеров в эту тестовую последовательность. Таким образом, благодаря тому, что тест определяет, в какой среде он на данный момент запускается, он может передавать эти указатели контроллеров непосредственно в тестовую последовательность. Кстати, сделать это вы должны после создания тестовой последовательности, потому что если тестовая последовательность не было создана, не появятся указатели контроллеров, которые нужно добавить. Итак, мы добавляем эти указатели контроллеров, и теперь все, что нам нужно сделать, - просто запустить тестовую последовательность. Итак, тестовая последовательность запущена. Она не генерирует какие-либо элементы, она может выполняться прямо в тесте, и затем она запускает две последовательности, они будут выполняться на конкретных контроллерах, которые мы только что задали. Итак, все прекрасно работает. Тест кажется достаточно несложным, потому что он выполняет всего одну последовательность. Тест должен добавить некоторые данные, но это нормально.
Путь, который мы задаем для этих указателей контроллеров, на самом деле может находиться в любой точке иерархии. Поэтому в зависимости от того, какая среда готовится при создании экземпляра, мы можем перенести указатель на любой доступный на данный момент контроллер. Даже несмотря на это обе последовательности будут выполняться одновременно. Сама тестовая последовательность при этом не изменяется. Все, что изменяется, - это значение указателя контроллера, который мы используем.
Единственная проблема заключается в том, что все равно остаются некоторые зависимости. Итак, в нашей среде мы запускаем тест и вносим эти два указателя контроллеров. Зависимость в том, что эти два указателя контроллеров в тестовой последовательности. Необходимо помнить, что мы запускаем тестовую последовательность, внутри которой находятся эти указатели контроллеров. Вот лучше б этой зависимости не было.
Конечно, было бы здорово, если б нам удалось избежать этой зависимости. Поэтому то, что нам действительно нужно, - создать среду более высокого уровня, которая бы реализовала только что созданную нами среду, но которая бы создавала видимость того, что среда более низкого уровня - обычный агент. Обычно агенты используют контроллеры, и последовательность, которую вы инициируете, инициируется на этом контроллере внутри агента. Поэтому нам необходимо создать среду, которую бы исходная среда идентифицировала, как агента. Это означает, что виртуальная последовательность должна запускаться на чем-то похожем на контроллер.
Поэтому нам нужно создать что-то подобное. Итак, у нас есть среда, в которой имеются два агента, и мы собираемся создать виртуальный контроллер последовательностей, представляющий собой объект, содержащий указатели контроллеров, которые нам и нужны. Теперь эти указатели контроллеров при помощи последовательности будут указывать на виртуальный контроллер, после чего они в свою очередь будут указывать на любой необходимый участок среды. Поэтому самой среде не требуется фиксирование того, что в последовательность должны быть внесены какие-либо данные. Все, что среде известно, это то, что в ней есть виртуальный контроллер, на котором и запущена эта последовательность. Итак, виртуальная последовательность становится своего рода «компонентным якорем», позволяющим нам настраивать последовательность, чтобы получить любую необходимую информацию, скрыв эти данные от операционной среды.
Итак, виртуальный контроллер представляет собой расширение контроллера ОВМ. Вследствие того, что виртуальный контроллер не генерирует какие-либо элементы, контроллер вообще не нужно параметризировать. Мы создаем его абсолютно таким же способом, как и все остальные компоненты, в нем есть конструктор, а вот сюда мы добавляем указатели контроллеров. Поэтому нам необходимо расширить базовый контроллер. Это всего лишь контроллер. Единственное, в нем есть вот эти два указателя контроллеров, которые мы сейчас и можем добавить. Возникает вопрос: как их добавить? Первое, что нам нужно сделать, это назвать указатели контроллеров, назвать так, чтобы это имело для нас смысл. Например, вместо контроллер1 и контроллер2, назовем их «регулирующий контроллер» и «информационный контроллер», потому что это дает нам обозначение того для чего мы их собираемся использовать, какие типы последовательностей инициируются на каждом контроллере, и тп. Итак, мы называем их таким образом, чтобы из названия была видна их функция. Теперь у нас есть регулирующий контроллер и информационный контроллер, и снова они являются указателями в данном виртуальном контроллере. Это было легко Остальное не так сложно, но даже то, что мы уже проделали, достаточно ясно. Вам нужно просто расширить контроллер, добавить эти два указателя, и с контроллером вы закончили.
Для того чтобы установить виртуальную последовательность, нам нужно будет создать виртуальную последовательность базового типа, которая бы скрыла большую часть данных от пользователей виртуальной последовательности. Итак, мы расширяем ее, принимая за основу последовательность ОВМ. И снова, из-за того, что элементы не генерируются напрямую, нам не нужно параметризировать последовательность. В виртуальной последовательности базового типа будут находиться указатели двух контроллеров, на которых мы хотим запустить последовательности. В ней также имеется указатель виртуального контроллера, на котором она будет выполняться, и это виртуальный контроллер особого типа. В текстовой части первое, что нам нужно сделать, взять указатель m_контроллера (m_sequencer), являющегося контроллером, на котором выполняется последовательность, и перенести его в виртуальный контроллер особого типа, чтобы убедиться, что мы запускаем последовательность на контроллере верного типа. Если тип контроллера неверен, выйдет сообщение о критической ошибке и процесс остановится, потому что именно эта определенная последовательность зависит от того, что она запущена на контроллере, содержащем указатели контроллеров, на которых будут запущены её под-последовательности. Затем мы добавляем два указателя, имеющиеся в виртуальной последовательности, и указываем на контроллеры виртуальным контроллером. Регулирующий контроллер и информационный контроллер выставлены на указатели контроллеров, используемые в виртуальном контроллере.
После этого мы можем приступить к созданию последовательности, которая будет использовать эту инфраструктуру. Сделать это намного проще, потому что мы скрыли все данные, от редактора последовательностей. В тестовой последовательности мы выделяем две последовательности, которые будем инициировать: init и exec. Запускаем super.body, чтобы установить инфраструктуру, созданную в базовом типе. Создаем экземпляры дочерних последовательностей, которые будем инициировать, после чего мы просто запускаем их на двух контроллерах в тестовой последовательности. Таким образом, контроллеры будут функционировать при помощи указателей контроллеров в виртуальном контроллере. Все, что нам нужно сделать, это привязать их к определенным контроллерам в среде, в которой мы хотим их запустить. И все будет прекрасно работать Отсюда все, что вам нужно, это знать функции этих двух контроллеров.
А сейчас мы соединим эти два контроллера в операционной среде. Итак, в нашей среде мы определяем виртуальный контроллер. Мы определяем двух агентов, которых мы собираемся использовать, - регулирующий агент и информационный агент. В текстовой части соединения мы собираемся задать эти указатели. Это необходимо сделать перед собственно запуском процессов, и это напоминает модель соединения. Это, ясно, не настоящая модель линии передач, но за образец модель соединения взять можно. В текстовой части соединения задается указатель виртуального регулирующего контроллера, на контроллер регулирующего агента, и таким же образом мы устанавливаем контроллер информационного агента на указатель информационного контроллера в виртуальном контроллере. Т.к. они заданы в текстовой части соединения, когда последовательность инициируется и подключается к регулирующему и информационному контроллеру в виртуальном контроллере, это соединение будет дальше передаваться агентам.
И вот что мы делаем теперь - из среды или посредством теста просто запускаем этот контроллер так, как бы запустили любую другую последовательность. Итак, в текстовой части запуска в нашей среде мы просто создаем тестовую последовательность и затем инициируем её на виртуальном контроллере. Это выглядит так, будто мы запускаем последовательность на любом другом контроллере в операционной среде. Теперь в нашей среде имеется этот виртуальный контроллер, и все зависимости, вроде определяющих, что должно быть подключено к какому контроллеру, скрыты от редактора среды, от тестового редактора, а также от редактора последовательностей, потому что мы записываем их в базовый класс виртуальных последовательностей. Поэтому если мы создаем виртуальный контроллер, правильно соединяем его с операционной средой, запускаем тестовую последовательность, которую хотим видеть на этом виртуальном контроллере, все должно работать именно так, как мы этого хотим.
После того, как мы настроили среду, можно создавать тест. Все, о чем мы должны позаботиться при создании теста, это проследить за выбором определенного типа последовательности, которую мы хотим запустить на нашем виртуальном контроллере. Итак, мы создаем новый тест и в нем (мы должны сделать это в начале симуляции, до того, как запустятся все процессы, до того, как мы запустим сам тест), мы корректируем тип test_seq в исходном коде таким образом, чтобы когда среда пытается создать экземпляр test_seq, вместо него создавалась бы новая последовательность test_seq2. Это та самая виртуальная последовательность, которая и будет запускаться. Тест должен определить, какую именно виртуальную последовательность нужно запустить. Можно запустить две одинаковые последовательности в разном порядке, можно изменить некоторые приоритеты, можно сделать все, что вам угодно. Вам нужно проследить, что вы запускаете определенную тестовую последовательность, Эта тестовая последовательность зависит от регулирующего агента и информационного агента, и мы хотим запустить две под- последовательности на каждом из них. Теперь все детали скрыты внутри виртуального контроллера и внутри базового класса виртуальной последовательности, поэтому операционная среда и тест относительно эффективны, все, что вам нужно сделать, определить, какую виртуальную последовательность инициировать. Вот теперь мы понимаем, что собой представляют виртуальные последовательности, и мы хотим перейти на следующий уровень, где мы сможем задать многоуровневый протокол, который мы хотим использовать.
И теперь мы поговорим о том, как можно создать многоуровневые последовательности, для того чтобы моделировать подобные многоуровневые протоколы. Существует несколько схем многоуровневого расположения протоколов. Например, соотношение 1:1, в котором транзакция одного типа преобразуется в транзакцию другого типа, или, например, зарегистрированная транзакция использует логическое имя для адреса, потому что зарегистрированное имя преобразуется в определенный адрес на шине. Также возможны соотношения типа и транзакция более высокого уровня преобразуется в несколько ячеек нижнего уровня или в то, к чему обращается ваш протокол. Кроме того, возможна ситуация типа несколько соответствий:1, при которой несколько мелких транзакций объединяются в транзакцию более крупного пакета, который вы затем можете посылать. Во всех этих схемах преобразование происходит на стадии ответного сигнала, поэтому если вы используете схему 1:несколько от верхнего уровня к нижнему, вы должны снова объединить несколько ответных сигналов в сигнал верхнего уровня. Все эти многоуровневые схемы немного отличаются друг от друга, но мы будем говорить о них именно в такой последовательности. Особенностью их всех является зависимость от конкретного приложения, общий механизм, который я буду описывать, применяется к любому типу уровневых протоколов.
Итак, у нас есть операционная среда, в которой имеется стандартный агент, который в свою очередь использует контроллер и драйвер. Контроллер собирается инициировать последовательность, которая пошлет транзакцию на драйвер. У нас также есть верхний уровень, т.е. контроллер более высокого уровня, который будет инициировать последовательность на верхнем уровне, создавая транзакции верхнего уровня. Мы хотим добиться того, чтобы соединить этот контроллер с контроллером нижнего уровня, чтобы можно было при помощи другой последовательности преобразовать транзакцию верхнего уровня в транзакции нижнего уровня и затем послать её на драйвер. Ключевым моментом здесь является то, что нужно заставить контроллер верхнего уровня думать, что он обращается к драйверу. Мы можем использовать модель линии передач. Этот контроллер всего лишь обычный контроллер. Он подключается к последовательному порту драйвера и ему все равно, где находится сам драйвер. Поэтому нам просто нужно обеспечить целостность подключения. Для того, чтобы сохранить эту архитектуру агента и контроллера, нам нужно создать нечто, что мы будем называть уровневым агентом, который средой будет восприниматься так, будто он является агентом, на котором функционирует контроллер. Нам нужно будет скрыть то, что в этом агенте фактически нет драйвера, что драйвер на самом деле находится на другом агенте. Ключевым здесь является соединение между контроллером верхнего уровня и контроллером нижнего уровня. Причем мы все это хотим проделать без необходимости изменений в агенте нижнего уровня. Мы не хотим расширять этот агент и добавлять дополнительный последовательный порт, создавать соединения и тп. Мы хотим оставить этот агент в том виде, в каком он есть, но в то же время установить соединение с контроллером верхнего уровня.
Чтобы это сделать, мы создадим архитектуру, в которой контроллер верхнего уровня думает, что он обращается к драйверу. Выглядеть это будет как любой первоначальный агент. А в операционной среде, есть агент, имеющий контроллер, который запускает последовательность.
И теперь нам нужно прописать то, что мы называем «уровневым агентом ОВМ». Это расширение ОВМ, вы можете загрузить его со страницы загрузки OVMworld.org (страница дополнительных загрузок). Это то, что необходимо параметризировать типом транзакции, которая генерируется на верхнем уровне. Назовем это «агентом верхнего уровня». И если обратно возвращается отдельный тип ответного сигнала, который точно также по умолчанию параметризируется, и они одинаковы, вам просто нужно задать один из них. Теперь у нас есть прописанный уровневый агент ОВМ, и в процессе построения мы создадим агент нижнего уровня путем переработки исходного кода так, как мы это обычно делаем. Наш агент верхнего уровня мы также собираемся создать при помощи исходного кода, используя параметризированный тип ovm_layer_agent# upper, и используя обычный исходный запрос на создание. Затем мы переходим к текстовой части агента верхнего уровня - create_mapping. К этому необходимо перейти в процессе построения, и это поможет установить все необходимые нам соединения. Преобразование, во-первых, нужно для того, чтобы обозначить это преобразование таким образом, чтобы вы смогли к нему обращаться. Во-вторых, важен тип контроллера верхнего уровня. Все это запускает схему оболочки, о которой мы говорили ранее. Итак, мы определяем контроллер верхнего уровня. Задаем имя агента нижнего уровня, чтобы мы могли его впоследствии найти и знать, к чему делать привязку. Кроме того, мы задаем имя преобразующей последовательности, которая будет запущена на контроллере нижнего уровня. Все это будет запускаться автоматически, причем задачей этой последовательности будет преобразование последовательности верхнего уровня в последовательность нижнего уровня. Впоследствии мы более подробно рассмотрим этот процесс. И наконец, мы должны задать последовательность, которую мы хотим запустить в контроллере верхнего уровня. Итак, это последовательность, которая будет генерироваться из исходного кода на контроллере верхнего уровня. Она будет запускаться и будет посылать транзакции на преобразующую последовательность, после чего процесс будет продолжаться. Особенностью является то, что весь процесс управляется данными, и все, что вам нужно сделать, это в преобразовательном запросе задать типы последовательностей, агенты верхнего и нижнего уровней, а также контроллеры, после чего все будет происходить автоматически. Поэтому вам не нужно пытаться что-то расширять и вручную добавлять свой порт - все происходит без вашего участия, при помощи запроса о преобразовании.
Итак, трансляционная последовательность является ключевой. Уровневый пакет включает класс под названием ovm_translator_base, который параметризируется типом запроса верхнего уровня и порой типом ответного сигнала верхнего уровня, если он отличается, (по умолчанию одинаковы), и параметром базовой последовательности - параметризированным типом последовательности, которая инициируется на контроллере нижнего уровня. Поэтому в текстовой части «тела» задаются типы запросов и ответных сигналов верхнего уровня. Вы определяете то, что процесс super.body будет руководить всей инфраструктурой, встроенной в базовый класс. В частности таким образом создаются типы запросов и ответных сигналов для контроллера нижнего уровня. Также существует встроенный порт sequence_item_pull_. Первое, что вам нужно сделать в трансляционной последовательности, получить сообщение от контроллера верхнего уровня. Вот вы получаете запрос верхнего уровня (что напоминает функцию драйвера, если мы говорим о последовательности верхнего уровня). Вы получаете запрос верхнего уровня, создаете объект запроса - это то, что вы собираетесь послать на последовательность нижнего уровня. Вы задаете объект запроса - следствие преобразования запроса верхнего уровня. И если это единый запрос верхнего уровня, он преобразуется в несколько запросов нижнего уровня, либо несколько запросов верхнего уровня объединяются в единый запрос нижнего уровня или имеет место соотношение 1:1. Все зависит от вас и от выбора приложения. Просто вы преобразуете запрос верхнего уровня, создавая запрос нижнего уровня. Затем вы обращаетесь к call start_item за этим запросом, обращаетесь к finish_item, и по желанию к get_response в том случае, если вы хотите получить ответный сигнал. Если вы получаете ответный сигнал, вы должны обратно преобразовать этот сигнал в сигнал верхнего уровня. Это может быть соотношение 1:1, 1:несколько, несколько:1. Опять-таки, все зависит от выбора приложения и от вас. Но вот вы создаете этот ответный сигнал верхнего уровня. Обращаетесь к set_id_info и записываете ответный сигнал обратно в последовательность верхнего уровня через порт. Таким образом, последовательный порт и порт ответного сигнала управляются автоматически в базовом классе транслятора ОВМ. Как только вы обращаетесь к super.body, процесс контролируется автоматически, вы получаете объекты запроса и ответного сигнала для последовательности нижнего уровня. Вы создаете видимость наличия драйвера, получаете запрос верхнего уровня, преобразуемый в запрос нижнего уровня, запускаете его, получаете ответный сигнал, обратно преобразуемый в ответный сигнал верхнего уровня и посылается обратно. Поэтому если мы рассматриваем последовательность верхнего уровня, эта преобразовательная последовательность выглядит в точности как драйвер.
Таким образом,у нас есть операционная среда, определяющая несколько агентов, один из которых может быть обычным агентом - стандартным агентом, в котором имеется контроллер, инициирующий последовательность, которая посылает сообщения на драйвер. Другой может быть уровневым агентом, в котором имеется контроллер, соединенный с преобразующей последовательностью в агенте нижнего уровня. Таки образом, все это выглядит как агент с контроллером, причем при запуске последовательностей на уровневом агенте мы можем запустить их на agent.sequencer. Соединение между уровневым агентом и контроллером агента нижнего уровня контролируется при помощи процесса create_mapping уровневого агента ОВМ. То есть мы можем установить это соединение без необходимости что-либо менять в самом агенте. Так вот, для любого многоуровневого расположения протоколов, которое создаете, у вас есть последовательность верхнего уровня, генерирующая транзакции более высокого уровня, есть преобразующая последовательность на агенте более низкого уровня, инициируемая одновременно с другими последовательностями нижнего уровня, и генерирующая дополнительный поток обмена, получая ответный сигнал и отсылая его обратно. Эту схему можно расширить на любое нужное для вашего протокола количество уровней, причем уровневый агент сам может быть подсоединен к уровневому агенту более высокого уровня таким же способом. Итак, понимая принцип функционирования виртуальных последовательностей, принцип управления родительскими и дочерними последовательностями, и научившись при помощи последовательностей создавать многоуровневые протоколы, вы можете моделировать любой тип тестовой среды с точки зрения последовательностей, где вы создаете последовательные объекты на любом необходимом уровне абстракции, либо уровне протокола, и преобразуете их в абстракции более низкого уровня, либо протоколы более низкого уровня и наоборот. Это все, что вам нужно знать, для того чтобы правильно выстроить вашу схему, причем задача решается на соответствующем уровне абстракции или соответствующем уровне протокола. Спасибо за внимание и увидимся на следующем занятии.
