Лекция 3. Моделирование систем

Моделирование систем. Стандарты OSCI TLM 1.0/2.0, IEEE 1850 PSL, и SCE-MI 2.0.

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

Архитектурный уровень проектирования предназначен для разбивки ИМС на функциональные модули. Степень детализации должна быть достаточной для последующей реализации этих модулей на схемном уровне.

Основные виды работ:

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

- Разбиение алгоритма преобразования сигнала на функции.

- Определение режимов работы функциональных модулей.

- Модификация функциональной схемы.

- Определение параметров неидеальности функциональных модулей.

- Модификация функциональной схемы.

- Спецификация функциональных модулей.

Весь комплекс высокоуровневых средств и методологий проектирования систем, все, что находится выше уровня RTL для цифровых и схемных для аналоговых, составляет системный уровень проектирования (ESL Electronic System Level). Это средства создания алгоритмов на основе библиотечных функций, различные виды моделирования  дискретное событийное, непрерывное, моделирование статических и динамических потоков данных, создание архитектурных платформ и виртуальных прототипов для анализа производительности, пропускной способности каналов передачи данных и разработки встроенного программного обеспечения.

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

Первые два уровня относятся к спецификации системы, где основной задачей является исследование проектируемой системы и получение ее исполняемых спецификаций на языках высокого уровня (C/C++/ SystemC и др.). Вторые два можно назвать ESL-проектированием с разработкой микроархитектуры и с использованием средств высокоуровневого синтеза, трансформацией исполняемой спецификации проекта на уровень регистровых передач (получение спецификаций на языках Verilog/VHDL) для аппаратной реализации, а также с интеграцией программных и аппаратных компонентов. Верификация проекта, т.е. проверка проекта и проектных решений на соответствие исходным спецификациям и другим требованиям, производится в ходе всего процесса проектирования по мере детализации проекта.

Таблица 2.2

Уровни абстракции модели

Уровень абстракции модели (точность)	Назначение модели	Компоненты	Характеристики
Пропускная способность	Исследование архитектуры	Транзакции, функцио-нальная модель	Скорость модели-рования, сбор статистики, проверка протоколов
Латентность (ожидания)	Программная плат-форма тестирования	Функциональная модель с точной привязкой по времени и параллелизмом	Скорость модели-рования и интерфейсы регистров
Тактовая	Оптимизация, разработка микро-программ и аппаратной реалии-зации алгоритмов	Определены шины, память, регистры, параллелизм	Быстрое изменение микроархитектуры и синтез RTL
Побитовая	Интеграция и реализация	Синтезированные, разработанные блоки или готовые IP-блоки	Описания на уровне RTL, логическая верификация

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

Система проектирования ESL уровня позволяет решить задачи:

- проектирование на уровне миссии: моделирование «операционной» среды, определение статических и динамических сценариев, планирование целевых задач и моделирование среды их выполнения, тестирование сложных проектов на уровне целевых задач;

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

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

Применительно к задачам проектирования SiP на системном уровне маршрут проектирования может выглядеть следующим образом.

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

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

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

Затем производится уточнение спецификации системы, где создается более детальное описание системной архитектуры, которое передается на проектирование. Такое описание на системном уровне может содержать некоторые детали последующей реализации, но функциональная часть состоит из поведенческих моделей на языках C/C++/SystemC. Далее уже используется совместное программно-аппаратное проектирование с применением моделей конкретных процессоров и шин (функциональных моделей), блоков, описанных на языках проектирования аппаратуры VHDL/Verilog, средств высокоуровневого синтеза.

Поскольку языки программирования, и в частности, С и С++, алгоритмически последовательные, они не подходят для описания аппаратных проектов, которые явно параллельны. Написание команд одна за другой показывает, что эти инструкции должны исполняться именно в порядке их следования в коде. В связи с этим противоречием и создаются системные языки описания аппаратных средств, которые предполагают использование концепции ESL. К таким языкам относятся SysyemC, Handle-C, System-Verilog и аналогичные.

Язык SystemC был создан как дополнение стандарта С++ классами и методами, отражающими специфику построения аппаратных моделей. В язык были внесены концепции времени и параллелизма, определены новые типы данных (биты и битовые векторы, четырехзначная логика и другие) и операции над ними, новые базовые конструкции, такие как порты, интерфейсы, процессы, события и каналы. Первая версия языка SystemC полностью дублировала уровень RTL и в дальнейшем была расширена на более абстрактные уровни описания. Тем не менее, пока SystemC, в основном, остается языком разработки несинтезируемых тестовых блоков и, при использовании синтеза с SystemC, описания аппаратуры.

Язык Handel-C был разработан Oxford Hardware Compilation group на основе языков ANSI С и occam, основанного на алгебре взаимодействия последовательных процессов CSP (Communicating Sequential Processes — CSP). С внесением в язык С параллельных конструкций был создан новый язык Handel-C, где стал возможен параллелизм. Язык Handel-C разработан так, чтобы было максимально просто модифицировать программный код ANSI C для параллельной реализации в аппаратуре. Выходом компилятора Handel-C является низкоуровневое аппаратное представление. Это значит, что получить выигрыш в производительности можно за счет массового параллельного выполнения инструкций. Для написания эффективных программ принципиально важным является задание инструкций компилятору для параллельного выполнения операторов. Например, задание ключевого слова «par» перед операторными скобками будет означать, что операторы внутри этого блока должны выполняться параллельно.

Параллелизм Handel-C является реальным, а не параллельным с квантованием времени, как это делается в компьютерах. Если задается параллельное исполнение двух инструкций, эти инструкции будут выполняться одновременно двумя отдельными блоками результирующей схемы. Когда компилятор находит параллельный блок, ход выполнения алгоритма разделяется в начале параллельного блока, и каждая ветвь блока выполняется одновременно. Любая завершившаяся ветвь блока будет ожидать завершения всех других ветвей. Когда все ветви параллельного блока выполнены, исполнение продолжается с конца этого блока. Аппаратное представление алгоритма синтезируется напрямую из исходного кода Handel-C без промежуточного уровня «интерпртации». Конечную схему на уровне вентилей, которая компилируется из исходного кода, можно рассматривать как инструкции ассемблера в системе Handel-C. Этот подход делает Handel-C более языком программирования, чем языком описания аппаратуры.

В общем случае исходными компонентами проектируемой системы могут быть текстовые спецификации, программы и модели на языках C/C++, высокоуровневые аппаратные спецификации на языке SystemC, функциональные модели Matlab/Simulink, а также готовые программные и аппаратные (синтезируемый код VHDL/Verilog на уровне регистровых передач RTL) и другие блоки.

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

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

Системы и SiP построены из проектных элементов и компонентов, которые обрабатываются по-разному в разных «моделях вычислений», таких как потоки данных (dataflow), конечные автоматы, дискретные события и аналоговая/смешанная область – модели этих компонентов формулируются на основе различных вычислительных предположений. Следовательно, язык проектирования и верификации SiP должен поддерживать интеграцию различных вычислительных моделей.

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

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

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

Проектирование на базе IP-блоков и платформ требует повторного использования компонентов проектирования и верификации. Это наиболее вероятно в том случае, когда модели создаются на широко распространенных и доступных языках и в обозначениях, созданных с учетом повторного использования. Следовательно, язык проектирования и верификации SiP должен быть «спроектирован в расчете на повторное использование».

Со стороны аппаратной части надо учитывать также этап реализации SiP, а не только этапы моделирования и проектирования. Реализация цифровой аппаратной части происходит преимущественно с помощью RTL синтеза. Следовательно, язык проектирования и верификации SiP должен поддерживать детализацию реализации или синтеза до RTL уровня.

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