Моделирование на языке SystemC в процессе разработки протоколов передачи данных Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.057.4

В. Л. Оленев

МОДЕЛИРОВАНИЕ НА ЯЗЫКЕ SystemC В ПРОЦЕССЕ РАЗРАБОТКИ ПРОТОКОЛОВ ПЕРЕДАЧИ ДАННЫХ

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

Ключевые слова: моделирование, протокол, SystemC, верификация.

Abstract. Modelling takes more important role in the development process as a solution to perform detailed check of the specification and project verification to a stage of physical realization. Modelling could be applied to the different stages of system design and a number of different languages and modeling platforms can be used. The models could have different structures and internal logic. This article describes a role of modeling inside the systems development course, discuss the advantages and tricky points that the developer can face while using modeling approach. Besides, the article describes SystemC modelling language, which is a good solution for making models of the embedded networks.

Keywords: modelling, protocol, SystemC, verification.

Введение

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

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

1 Проектирование протоколов передачи данных

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

- концептуальное проектирование: выбор направления разработки, исследование и анализ существующих средств и протоколов, разработка драфтовой версии спецификации;

- спецификация: получение финальной спецификации протокола, а также его моделей на языках высокого уровня (обычно на SystemC/SDL);

- логическое проектирование: трансформация исполняемой спецификации проекта на уровень регистровых передач (на языках Verilog/VHDL) и далее на вентильный уровень;

Рис. 1 Общий маршрут проектирования

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

- физическое проектирование: начинается от выбора технологического и библиотечного базиса и заканчивается получением финального устройства, способного работать по данному протоколу [1].

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

2 Моделирование в процессе спецификации

Основной целью в процессе спецификации протокола является определение и спецификация основных его функций, а также создание исполняемой модели. Эта модель используется для верификации корректности работы протокола с функциональной точки зрения, а также для определения необходимых аппаратных ресурсов для его работы. Также ведется проверка самих механизмов и подходов, реализованных в спецификации, на корректность и совместимость [1]. Общий маршрут проектирования на данном этапе приведен на рис. 2.

Спецификация проекта

Функциональное планирование протокола Определение сценариев работы Создание общих моделей протокола

Функциональная спецификация

Создание исполняемой модели Разработка алгоритмов Функциональное моделирование

Исследование проекта

Разделение проекта Анализ архитектуры Анализ требуемых ресурсов, производительности и т.п.

Уточнение спецификации

Проверка описаний протокола Описание интерфейсов Схемы арбитража

Рис. 2 Маршрут спецификации протокола

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

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

3 Моделирование в процессе верификации

Метод верификации моделей (или проверки на модели) применяется для верификации систем с конечным числом состояний. Обычно процедура верификации заключается в исчерпывающем обходе пространства состояний системы, для того чтобы выяснить, выполняется ли спецификация. При наличии достаточных ресурсов эта процедура всегда завершается ответом «да» или «нет». Более того, она может быть реализована достаточно эффективным алгоритмом, способным работать на вычислительных машинах невысокого класса. Метод верификации моделей применим ко многим важным классам вычислительных систем, к каким относятся и коммуникационные протоколы [2].

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

- анализ производительности и других системных параметров проектируемых протоколов;

- возможность совместной разработки и верификации аппаратуры и встроенного программного обеспечения;

- единая среда проектирования;

- наличие библиотек и высокоуровневых конструкций для функциональных блоков и коммуникационных каналов;

- средства управления данными и документирования проектов.

На высших уровнях представления используются языки C/C++/ SystemC. Для моделирования кода C/C++ используется встроенное ядро моделирования, которое осуществляет планирование и исполнение модели в соответствии со структурой и поведенческими функциями проекта вместе с программными объектами [1].

4 Моделирование в процессе тестирования устройств

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

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

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

Примером подобного тестера служит программное окружение, разработанное для тестирования стандарта SpaceWire (рис. 3,а). Данный Тестер предназначен для генерации и внесения ошибок в информацию, проходящую через уровни модели. Таким образом, исследуется реакция удаленной стороны на различные ошибки и проверяются механизмы обработки ошибок [3].

Другим примером может служить Тестер, разрабатываемый для тестирования протоколов в Nokia (рис. 3,б). Он разработан для тестирования SystemC модели протокола и подсоединенного к нему устройства. Здесь, в отличие от предыдущего примера, введены промежуточные уровни, через которые ведется управление и контроль. Эти уровни имеют сервисные точки доступа как к самим уровням протокола, так и к тестеру [4]. За счет этих промежуточных уровней Тестер способен не только генерировать ошибки, но и управлять слоями, тестировать каждый слой отдельно и контролировать данные, проходящие между ними.

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

5 Язык SystemC и его преимущества

Моделирование с использованием SystemC в последнее время становится одним из наиболее эффективных методов для изучения, анализа или построения сложных систем, таких как стеки протоколов, сети с большим количеством узлов или системы на кристалле. SystemC - это C++ библиотека, которая используется для моделирования параллельных систем. Она дает возможность реализовать распределенное во времени моделирование за счет работы с событиями и сигналами времени.

Тестер

Direct D, S forcing

it tt і і і і

Il и_____________44 II

Физический уровень

jar...............ТГТ

Сигнальный уровень

Ошибка генерации бита________________

Символьный уровень

Генерация дополнительн ого символа

Уровень обмена

Ошибки

RMAP

STP

ругие транспортные протоколы

1RPW 1RF

а)

Генератор тестов

API генератора тестов

Тестовый механизм

Конфигурационный Сокет API

АР]

- гМ

ф (<l L2_L3 Промежуточный уровень

ОЛ

<

уся/

0\

Рис. 3 Различные реализации Тестеров

L1_L2 Промежуточный уровень

SAP

Уровень 1 Тестер

б)

№ 4 (12), 2009 Технические науки. Информатика, вычислительная техника

Таким образом, эта библиотека позволяет описывать сложные системы и программные компоненты и объяснять их работу. Ядро SystemC определяет типы данных, такие как битовые, векторные типы и типы с фиксированной запятой. Также присутствуют элементы ядра, такие как модули, процессы, события и каналы. Для реализации механизмов взаимодействия между параллельными объектами созданы такие элементарные каналы, как сигналы, или стек FIFO [5].

SystemC является подходящим языком для спецификации, моделирования, проектирования и верификации систем, поскольку существует ряд преимуществ этого языка:

- SystemC основан на С++ и построен с использованием расширения библиотек и ядра симуляции, написанных на С++;

- он способен интегрировать все основанные на С++ модели;

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

- SystemC поддерживает модели на всех уровнях абстракции и использует стандартную семантику на уровне транзакций и API, что гарантирует возможность совместной работы моделей;

- большинство разработчиков и экспертов в аппаратной, системной, программной областях и области алгоритмов более или менее знакомы с C/C++, что облегчает совместную работу;

- SystemC поддерживает современные методологии верификации с помощью многоуровневой библиотеки верификации SCV (SystemC Verification library);

- SystemC создан в расчете на проектирование на базе IP-блоков и повторное использование проектных и верификационных компонентов;

- SystemC поддерживает моделирование аппаратной части и детализацию проекта до RTL уровня;

- SystemC естественным образом поддерживает все основные требования к языку проектирования и верификации [6].

Важно отметить, что библиотека верификации SCV вносит в SystemC много новых возможностей для тестирования. SCV позволяет создавать верификационные IP-блоки, которые можно повторно использовать и в других проектах. Основными верификационными возможностями SCV библиотеки являются: самодиагностика, верификация на основе транзакций, рандомизация [7, 8].

Таким образом, SystemC является наиболее подходящим средством для моделирования в процессе разработки, спецификации и верификации.

6 Применимость SystemC для нужд моделирования

Рассмотрим основные уровни абстракции и модели использования SystemC. Сюда входят:

- функциональное моделирование системных алгоритмов;

- моделирование системных архитектур на уровне транзакций;

- моделирование на уровне RTL и привязка SystemC к маршрутам реализации;

- недавние добавления к 8у81ешС на тему верификации: библиотека верификации 8у81ешС [6].

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

Однако при написании программного обеспечения для тестового окружения использование 8у81ешС ограничено, поскольку 8у81ешС не предназначен для написания приложений. Хотя новая версия 3.0 будет содержать возможности моделирования и планирования программ, она не станет платформой по разработке программного обеспечения [6].

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

Также часто 8у81ешС используется для тестирования работы двух протоколов, работающих один «поверх» другого. В этом случае реализуются модель протокола передачи данных и модель прикладного уровня, описывается их взаимодействие и производится тестирование работы протокола прикладного уровня поверх протокола передачи данных. С помощью 8у81ешС легко описать структуры, отвечающие за конфигурирование нижележащей модели под нужды вышележащей, а также задать различные варианты конфигурации и функционирования «верхнего» протокола. Пример архитектуры такой модели приведен на рис. 4.

Уровень 1

Рис. 4 Пример работы протокола камеры поверх абстрактного протокола передачи данных

7 Результаты

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

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

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

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

Заключение

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

Список литературы

1. Бухтеев, А. Методы и средства проектирования систем на кристалле / А. Бух-теев // CHIP NEWS. - 2003. - № 4 (77). - Апрель. - С. 4-14.

2. Кларк, Э. Верификация моделей программ: Model Checking / Э. Кларк, О. Грамберг, Д. Пелед. - М. : Московский центр непрерывного математического образования, 2002. - 416 с.

3. Суворова, Е. A Methodology and the Tool for Testing SpaceWire Routing Switches / Е. Суворова // SpaceWire : материалы Первой Международной конференции. - Данди, 2007. - Режим доступа: http://spacewire.computing.dundee.ac.uk/ proceedings/Papers/Test%20and%20Verification%202/suvorova2.pdf.

4. Gillet, M. Hardware/software co-simulation for conformance testing of embedded networks / M. Gillet // Finnish-Russian University Cooperation in Telecommunications (FRUCT) : материалы шестого семинара. - Тампере, 2008. - Режим доступа: http://fruct.org/index.php?option=com_content&view=article&id=68&Itemid=73.

5. Оленев, В. Методы межмодульного взаимодействия при моделировании протоколов встроенных систем / В. Оленев, Л. Онищенко, А. Еганян // Научная сессия ГУАП. - СПб. : СПб ГУАП, 2008. - С. 98-99.

6. Немудров, В. Системы на кристалле. Проблемы проектирования и развития /

В. Немудров, Г. Мартин. - М. : Техносфера, 2004. - 212 с.

7. Swan, S. A Tutorial Introduction to the SystemC TLM Standard / S. Swan. - 2003. -

Режим доступа: http://www-ti.informatik.uni-tuebingen.de/~systemc/Documents/ Pres-entation-13-OSCI_2_swan.pdf.

8. Ro se, J. SCV Randomization / J. Rose, S. Swan. - Cadence Design Systems, 2003. -Режим доступа: http://www.openverificationfoundation.org/docs/scv_randomiza-

tion.pdf

Оленев Валентин Леонидович

аспирант, магистр техники и технологии, Санкт-Петербургский государственный университет аэрокосмического приборостроения

Olenev Valentin Leonidovich Postgraduate student, master of engineering, Saint-Petersburg State University of Aerospace Instrumentation

E-mail: [email protected]

УДК 004.057.4 Оленев, В. Л.

Моделирование на языке SystemC в процессе разработки протоколов передачи данных / В. Л. Оленев // Известия высших учебных заведений. Поволжский регион. Технические науки. - 2009. - № 4 (12). - С. б0-б9.