Смешков А. С. Автореферат по теме магистерской работы

ДонНТУ > Портал магистров

Rus Eng

Индивидуальное задание

Автореферат выпускной работы магистра

Тема магистерской диссертации:

"Интерактивный вспомогательный модуль (TLM Wizard) для генерации начального кода цифровых устройств, базирующихся на технологии transaction level modeling (TLM)"

Актуальность проблемы:

В последние годы в мире наблюдается стремительное развитие электронных технологий, созданы языки описания цифровых устройств и методы эффективного тестирования при минимальных затратах. В настоящее время мы наблюдаем повсеместный переход на методику Transaction Level Modeling (TLM), позволяющую работать со сверхсложными однокристальными системами на новом уровне абстракции. В отличие от RTL-моделирования (Register Transfer Level), традиционно использующегося для реализации аппаратных средств, моделирование уровня транзакций предназначено для системной интеграции внутрикристальных компонентов и создания оптимизированных архитектурных решений, что существенно облегчает тестирование разработанных цифровых устройств.

Цель работы

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

Предполагаемая научная новизна:

Технология Transaction Level Modeling хоть и получила широкое распространение, но нашла свое отражение лишь в нескольких языках, таких как SystemC и SystemVerilog. В данной работе будет сделана попытка рассмотрение данных языков как набора шаблонов, выделение общих и отличительных характерностей, предположение о развитии технологии как таковой. Это даст возможность создать универсальный визуальный редактор кода цифровых устройств, основанного на технологии TLM.

Обзор существующих исследований и разработок:

Язык описания цифровых устройств SystemC

SystemC - это набор классов, которые свободно распространяются и позиционируются как средство моделирования цифровых схем с помощью любого компилятора C (в первую очередь GCC и MSVC, также существует портирование на C++Builder).

Преимущества SystemC в том, что можно моделировать сложные схемы, описанные как классы, производные от класса SC_MODULE из библиотеки SystemC, просто компилируя их в .exe файлы без использования ModelSim или Riviera/ActiveHDL. Также преимуществом является то, что при моделировании возможно использование всех средства языка C/C++ (функции, объекты и т.д.).

В SystemC модно выделить принципиальные недостатки: во-первых, описание схемы на языке C - является несколько странным и экзотическим. А во-вторых - практически нет средств синтеза с SystemC. Точнее средства есть, но они либо недоступны для скачивания, либо их разработка свернута (SystemC в Cocentric). Поэтому синтез схем лучше осуществлять с помощью VHDL/Verilog.

Таким образом SystemC может быть полезен разработчикам в качестве мощного средства моделирования схем.

Transaction Level Modeling в SystemC

Адам Роз, Mentor Graphics; Стюарт Сван, Джон Пирс, Жан-Михаил Фернандез, Cadence Design Systems

Краткий обзор

Во введении описана причина, по которой мы решили предложить использование стандарта Transaction Level Modeling. В данном разделе мы сосредоточились на основных случаях использования технологии и увеличения производительности. В разделе 2 подробно описано ядро tlm. Раздел 3 показывает обработку single master / single slave в отличие от технологии rtl. В разделе 4 рассмотрено, как создать объекты TLM типа централизованных маршрутизаторов, арбитров, каналов, и децентрализованного использования схем расшифровки. Раздел 5 показывает, как объединять основные компоненты из раздела 4, для исследования и создания различных видов переключателей.

В первом приложении рассмотрены примеры использования sc_export. Во втором приложении кратко рассмотрены некоторые основные эффективные и безопасные принципы использования OSCI TLM в среде SystemC. В заключительном приложении приведен список всех интерфейсов tlm.

Исходные коды примеров, содержащиеся в данном документе доступны в OSCI TLM комплекте на сайте www.systemc.org.

1. Введение

Создание технологии Transaction Level Modeling (TLM) мотивировано множеством практических проблем. Они включают:

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

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

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

Начиная с выхода версии 2.0, стало возможным использовать TLM в SystemC. Однако, нехватка установленных стандартов и методологий означала, что каждое изменение TLM должно было привести к изменению методологии и API. В дополнение, все эти методологии отличались между собой, делая затруднительным обмен данными с помощью IP сетей.

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

2. Предложение TLM

2.1 Ключевые Понятия

Есть три ключевых понятия, которые нужно понять для понимания всей технологии TLM.

Интерфейсы
Блокируемые и неблокируемые
Двунаправленные и однонаправленные

2.1.1 Интерфейсы

Акцент стоит на интерфейсах, а не на реализации, потому как SystemC является C++ библиотекой, а C++ (при использовании должным образом) является объектно-ориентированным языком. Сначала мы должны строго определить ключевые интерфейсы, а лишь затем продолжить обсуждение различных способов, с помощью которых они могут быть осуществлены в проекте TLM. Важно понять, что классы интерфейсов TLM формируют основу стандарта TLM, и что выполнение тех или иных интерфейсов (например tlm_fifo) не является столь важным. В SystemC, все интерфейсы должны наследоваться от класса sc_interface.

2.1.2 Блокируемые и неблокируемые интерфейсы

В SystemC есть два основных вида процессов: SC_THREAD и SC_METHOD. Ключевое различие между этими двумя - то, что возможно приостановить выполнение процесса SC_THREAD запросом wait(.). SC_METHODs с другой стороны может быть синхронизирован, но это делает его чувствительным к внешним событиям, определенным в sc_event. Вызов wait(.) в SC_METHOD приведет к ошибке во время выполнения программы. Использование SC_THREAD в различных ситуациях более естественно, но медленнее, потому как wait(.) вызывает переключение на другой процесс в планировщике SystemC. Используя SC_METHOD более ограниченно, но более эффективно, потому как при его использовании не требуется переключение[2].

Поскольку возникнет ошибка при вызове wait изнутри SC_METHOD, каждый метод должен явно указывать, возможен ли вызов данной функции. Поэтому метод должен быть вызван из SC_THREAD, в ином случае из SC_METHOD. OSCI стандарт использует терминологию "блокируемый интерфейс" для первого случая и "неблокируемый" для второго.

OSCI TLM стандарт строго придерживается OSCI терминологии "блокируемые" и "неблокируемые". К примеру, если интерфейс TLM помечен как "неблокируемый", то его методы никогда не смогут вызвать wait().

OSCI Терминология	Содержит wait(.)	Возможно вызвать из
Блокируемый	Возможно	только SC_THREAD
Неблокируемый	Нет	SC_METHOD или SC_THREAD

2.1.3 Двунаправленная и однонаправленная передача данных

Некоторые обычные транзакции явно двунаправлены, например считывание данных с шины. Другие транзакции явно однонаправлены. В случае более сложного протокола всегда возможно разделить передачу данных на двунаправленную или однонаправленную. Например, сложная шина с адресом. Управление и фазы данных могут быть схожи с шиной чтения/записи на высшем уровне абстракции, но это можно представить как последовательность однонаправленных каналов на более детализированном уровне. Любой стандарт TLM должен иметь и двунаправленные и однонаправленные интерфейсы. Стандарт должен иметь стандартный вид и явно показывать взаимоотношения между этими интерфейсами.

2.2 Основные интерфейсы TLM

2.2.1 Однонаправленные интерфейсы

Однонаправленные интерфейсы основаны на интерфейсах sc_fifo, как описано в стандарте SystemC 2.1. Sc_fifo использовался множество лет во многих типах моделирования, так как критическим параметром во многих проектах является размер fifo. В результате fifo интерфейсы легки для понимания, и мы знаем, что они являются надежными в параллельных системах. Еще одно преимущество использования интерфейсов, основанных на sc_fifo, состоит в том, что будущие симуляторы в состоянии выполнить известную статическую оптимизацию планирования. В дополнение к этому, классы интерфейсов разделены на блокируемые, и неблокируемые классы. Неблокируемые методы отличаются от блокируемых приставкой "nb_".

Однако, для TLM мы имеем новые требования

Требуется некоторое значение свободной терминологии, так как "read" и "write" в текущих интерфейсах sc_fifo очень загружено в контексте TLM
Эти интерфейсы должны быть включены в fifo как другой канал или непосредственно конечный объект, используя sc_export.

Чтобы решить первую из этих проблем, мы перемещаем данные от инициатора к цели, назовем это "put" и когда мы передаем данные от цели до инициатора, мы называем это "get".

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

Третье требование будет выполнено при введении блокируемых, неблокируемых и комбинированных интерфейсов.

2.2.2 Однонаправленные блокируемые интерфейсы

template < typename T >
class tlm_blocking_get_if :
public virtual sc_interface
{
public:
    virtual T get( tlm_tag *t = 0 ) = 0;
    virtual void get( T &t ) { t = get(); }
};

template < typename T >
class tlm_blocking_peek_if :
public virtual sc_interface
{
public:
    virtual T peek( tlm_tag *t = 0 ) = 0;
    virtual void peek( T &t ) { t = peek(); }
};

template < typename T >
class tlm_blocking_put_if :
public virtual sc_interface
{
public:
    virtual void put( const T &t ) = 0;
};

Так как мы можем использовать функцию wait в блокируемых интерфейсах, никогда не возникнет ошибки. Для удобства, мы создали два метода get и peek, хотя, в большинстве случаев требуется только один.

2.2.3 Однонаправленные неблокируемые интерфейсы

template < typename T >
class tlm_nonblocking_get_if :
public virtual sc_interface
{
public:
    virtual bool nb_get( T &t ) = 0;
    virtual bool nb_can_get( tlm_tag *t = 0 ) const = 0;
    virtual const sc_event &ok_to_get( tlm_tag *t = 0 ) const = 0;
};

template < typename T >
class tlm_nonblocking_get_if :
public virtual sc_interface
{
public:
    virtual bool nb_peek( T &t ) = 0;
    virtual bool nb_can_peek( tlm_tag *t = 0 ) const = 0;
    virtual const sc_event &ok_to_peek( tlm_tag *t = 0 ) const = 0;
};

template < typename T >
class tlm_nonblocking_put_if :
public virtual sc_interface
{
public:
    virtual bool nb_put( const T &t ) = 0;
    virtual bool nb_can_put( tlm_tag *t = 0 ) const = 0;
    virtual const sc_event &ok_to_put( tlm_tag *t = 0 ) const = 0;
};

В неблокируемых интерфейсах может возникнуть ошибка, так как невозможно использовать функцию wait, следовательно, невозможно дождаться определенного состояния. Таким образом nb_put, nb_get и nb_peek должны возвращать bool значение, чтобы возможно было узнать когда будет доступен неблокируемый интерфейс. Существуют также методы nb_can_put, nb_can_get и nb_can_peek для того, чтобы узнать будет ли транзакция успешной.

Этих методов достаточно, чтобы осуществлять опрос методов put, get и peek. Также существуют функции, которые позволяют SC_THREAD ожидать определенного события или SC_METHOD, который будет инициирован при регистрации события. Ожидание событий позволяет прервать выполнение неблокируемого интерфейса. Однако, в общем случае, даже если требуемое событие было зарегистрировано, мы все равно должны проверить возможность использования интерфейса.

2.2.4 Двунаправленные блокируемые интерфейсы

template
class tlm_transport_if : public sc_interface
{
public:
virtual RSP transport(const REQ&) = 0;
};

Двунаправленные блокируемые интерфейсы используется для моделирования транзакций, когда соединены два объекта непосредственно друг с другом без использования других каналов связи. Данный подход является верным с точки зрения разработчиков программного обеспечения, когда, например, на вход передается адрес данных, а на выход отсылаются прочитанные данные.

Структура функции transport может быть описана как сочетание get и put функций. Таким образом, мы можем создать интерфейс tlm_transport_if, который просто вызывает соответствующие функции put(.) и get(.) из двух однонаправленных интерфейсов.

2.3 Каналы TLM

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

2.3.1 tlm_fifo

Шаблонный класс tlm_fifo включает все однонаправленные интерфейсы, описанные выше. Реализация данного канала fifo основано на реализации sc_fifo. Данные, помещенные в tlm_fifo, недоступны для считывания пока не будет выполнен следующий цикл. В дополнение к функциональным возможностям sc_fifo, tlm_fifo, размер данных может быть нолем или бесконечностью. Данные возможности подробнее рассмотрены в пункте в 4.3.1.

2.3.2 tlm_req_rsp_channel< REQ,RSP >

Класс tlm_req_rsp_channel< REQ, RSP > состоит из двух fifo - один для получения данных от инициатора и передачи к цели, второй, для передачи данных от цели до инициатора. Для обеспечения прямого доступа к этим fifo инициатор и цель экспортируют интерфейсы put и get.

Для удобства, они сгруппированы в интерфейсы master и slave, как показано ниже:

template < typename REQ , typename RSP >
class tlm_master_if :
    public virtual tlm_extended_put_if< REQ > ,
    public virtual tlm_extended_get_if< RSP > {};

template < typename REQ , typename RSP >
class tlm_slave_if :
    public virtual tlm_extended_put_if< RSP > ,
    public virtual tlm_extended_get_if< REQ > {};
};

Все fifo в tlm_req_rsp_channel могут иметь произвольный размер.

2.3.3 tlm_transport_channel< REQ, RSP >

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

RSP transport( const REQ &req ) {
    RSP rsp;

    mutex.lock();

    request_fifo.put( req );
    response_fifo.get( rsp );

    mutex.unlock();
    return rsp;

}

Эта простая функция обеспечивает ключевую связь между двунаправленными и последовательными интерфейсами как показано в transport и однонаправленными интерфейсами, как показано в tlm_fifo. Более подробно это будет рассмотрено в главах, посвященных примерам реализации интерфейсов transactor (3.4) и arbiter (4.2).

2.4 Вывод

Методы и классы, описанные в главе 2.2, показывают основные возможности OSCI TLM. На основе этого простого транспортного механизма, мы можем строить модели программного обеспечения и аппаратных средств, маршрутизаторов и арбитров, шин с различным типом каналов и пакеты основных протоколов. Мы можем моделировать на различных уровнях абстракции и с помощью каналов соединять их. Поскольку они основаны на интерфейсах к sc_fifo, они легко поняты, безопасны и эффективны.

Пользователи могут проектировать собственные каналы передачи данных, используя реализацию некоторых из этих интерфейсов, или они могут добавлять их непосредственно в объекты, используя sc_export. Функция transport особенно полезна, когда требуется быстро создать прототип модели программного обеспечения.

В дополнение к основным интерфейсам, мы определили три стандартных канала, tlm_fifo< T >, tlm_req_rsp_channel< REQ, RSP > и tlm_transport_channel< REQ, RSP >. Эти три канала могут использоваться, чтобы моделировать разнообразные системы. С помощью класса tlm_transport_channel возможно создание удобной связи между синхронными и асинхронными областями.

Язык описания цифровых устройств SystemVerilog

Основная цель разработчиков SystemVerilog была в объединении возможностей языка описания аппаратуры (Verilog), языка программирования (C++/Java++) и средства создания верификационных сред (VERA-HVL). Таким образом язык SystemVerilog является мощным универсальным средством для разработки цифровых устройств.

К сожалению на данный момент не разработано хорошего SystemVerilog-симулятора для построения поведенческой модели, что затрудняет широкое использование SystemVerilog. Для данной цели чаще всего используется SystemC.

Нерешенные проблемы:

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

Собственные результаты:

На текущий момент создана часть программы, позволяющая выполнять следующие действия:

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

Рис. 1 - Графический интерфейс будущего приложения

Заключение:

В моей магистерской работе будет представлена программа для создания шаблонов для генерации кода на любом объектно-ориентированном языке программирования, включающим в себя технологию transaction level modeling. Будут созданы шаблоны для языков SystemC и SystemVerilog, разработана система представления кода виде графических объектов.

В настоящее время (май 2006) магистерская работа находится в стадии разработки. Окончательный вариант будет в декабре 2007 г. За справками обращаться к автору или руководителю.

Литература:

Магистр ДонНТУ Смешков Александр Сергеевич