Лекция 4. Системные языки описания и моделирования аппаратных средств

Системные языки описания и моделирования аппаратных средств (обзор). SystemC, System-Verilog.

Почему SystemC является подходящим языком для спецификации, моделирования, проектирования и верификации SiP схем и систем? Рассмотрим свойства и преимущества этого языка в свете описанных выше требований.

SystemC основан на С++ и построен на основе расширения библиотек и ядра симуляции, написанном на С++. Следовательно, он способен интегрировать все основанные на С++ модели, включая симуляторы систем команд, программные модели, аппаратные модели и результаты работы средств моделирования на высоком уровне, генерирующих С или С++ код.

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

SystemC поддерживает модели на всех уровнях абстракции и использует, в рамках инициативы OSCI (Open SystemC Initiative), стандартную семантику на уровне транзакций и API, что гарантирует возможность совместной работы моделей.

Язык SystemC основан на С++, который, в свою очередь, основан на С. Хотя, возможно, C/C++ и не совсем знаком некоторым специалистам по HW, большинство разработчиков и экспертов в аппаратной области, программной, области алгоритмов и системной области более менее знакомы с C/C++. Редкий выпускник технического вуза сейчас не встречался с C/C++ во время обучения. SystemC основан на широко известном языке.

SystemC поддерживает современные методологии верификации с помощью многоуровневой библиотеки верификации SystemC (SCV — SystemC Verification library). SCV поддерживает создание тестовых платформ, запись транзакций (входные сигналы, мониторы, проверка откликов), рандомизацию переменных, наложение ограничений/связей, а также применение новых методологий верификации на основе транзакций.

SystemC создан в расчете на проектирование на базе IP-блоков и повторное использование проектных и верификационных компонентов, на основе С++ и OSCI стандартов по взаимодействию компонентов на уровне транзакций. SystemC «спроектирован для повторного использования».

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

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

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

В тоже время в течение последних двух лет разгорелась значительная дискуссия и даже возникла некоторая путаница по поводу ролей, занимаемых различными уже существующими, а также новыми, либо модифицированными языками проектирования. Если мы захотим составить список языков, используемых в проектировании сложных систем или SiP проекте, получится примерно следующее: в большинстве SiP проектов присутствует хотя бы один программируемый процессор. Поэтому нам, скорее всего, придется работать с симулятором набора инструкций (ISS), подсистемой памяти и шиной (например, ARM+AMBA), и все это может быть смоделировано в SystemC. На самом деле весьма вероятно наличие двух процессоров, RISC-типа и DSP, каждый со своей подсистемой моделирования и ISS.

На этих процессорах будут выполняться какие-то встроенные программы - системные и прикладные аппаратно-зависимое SW(HdS), прикладное и посредническое SW. Добавляем соответственно языки С, С++ и/или Java.

Команда разработчиков может создавать либо модифицировать цифровые IP блоки - некоторые из них (например, блоки обработки сигналов/изображений или кодирования/декодирования) моделируются в Matlab/Simulink (потоки данных), а некоторые - в Verilog или VHDL.

В наши дни редкий SiP проект обходится без цифровых IP блоков, приобретенных со стороны, которые описываются на языках Verilog или VHDL.

Во многих SiP проектах есть блоки AMS (analogue/mixed-signal) интерфейсов или тактовые генераторы на основе PLL (phase-locked loop), приобретенные со стороны либо созданные проектными командами, - они моделируются на Spice, либо на Verilog или VHDL варианте в случае AMS интерфейсов (Verilog-A, VHDL-AMS) для того, чтобы AMS интерфейсы могли быть протестированы в рамках общего проекта SiP путем подключения их моделей к симулятору смешанного моделирования.

Также необходимо создать тестовые платформы (testbench) и тесты для верификации проекта. Хотя для этого обычно используются HDL языки, в последнее время растет интерес к специализированным языкам аппаратной верификации (Hardware Verification Languages - HVLs), таким как Vera от Synopsys, Open Verification Library (OVL) на основе HDL, а также создаваемым в данный момент языкам SystemVerilog и Verilog-2005. Конечно, для этих целей может использоваться и новая библиотека верификации SystemC - SystemC Verification Library (SCV).

Утверждения - Ассёрты (assertions) и верификация на основе ассертов представляют собой новый способ спецификации проектных характеристик, как в случае формальной (статической) верификации, так и динамической (на базе симуляции). Для этих целей могут быть использованы такие языки как Open \fera Assertions (OVA), Accellera Property Specification Language (PSL), основанный на Sugar от IBM, и ассерты языка SystemVerilog. В реальном проекте IP блоки, приобретенные от различных поставщиков, могут содержать ассерты, заданные на всех перечисленных выше языках.

Если мы теперь подсчитаем все языки и системы обозначений, используемые в проекте, то получим как минимум девять, и как максимум, может быть, даже 16 или 17 различных форматов!

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

При рассмотрении широкой области проектирования на системном уровне очевидно, что SystemC является языком системного проектирования, покрывающим наиболее важные уровни абстракции в проектировании на системном уровне, от не- временного (untimed) функционального моделирования HW-SW платформ на уровне транзакций до реализации на уровне RTL. Он позволяет проектным командам моделировать и верифицировать проекты на действительно системных уровнях абстракции, а затем детализировать эти проекты, отражая детали реализации, и, в конце концов, связать системную модель с реализацией и верификацией аппаратного проекта. В SystemC можно создать модель-прототип проектной платформы на уровне транзакций, что позволяет быстро верифицировать тестовые платформы на системном уровне перед тем, как переходить к дальнейшей детализации. SystemC является естественным моделирующим языком для решения всех проблем, возникающих в системах и платформах со смешанной аппаратной и программной частью.

Основные уровни абстракции и модели использования SystemC:

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

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

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

Недавние добавления к SystemC на тему верификации: библиотека верификации SystemC.

С одной стороны, SystemC не является оптимальным языком для HDL и проектирования на вентильном уровне, с другой стороны, Verilog-2005 (и SystemVerilog) плохо подходят для моделирования на системном уровне и создания высокопроизводительных системных прототипов. Именно взаимодействие различных языков позволяет создать высокопродуктивные маршруты проектирования с минимумом риска.

Учитывая это, необходимо помнить о том, что и язык SystemC ограничен сверху. Хотя новая версия 3.0 скорее всего будет содержать возможности моделирования и планирования программ, она не станет платформой по разработке программного обеспечения. Продвижения в мире моделирования программ с помощью UML дают надежду на появление в этом году UML версии 2.0, которая обещает значительно улучшенные возможности по моделированию системных программ и генерации кода, особенно в случае встроенных систем реального времени. Одной из многообещающих областей для будущей методологической работы является создание мира трех языков, в котором программы, заданные и смоделированные в UML, могут генерировать оптимизированный под платформу код, который, в свою очередь, может быть симулирован на уровне транзакций в рамках платформенной модели на основе SystemC с использованием соответствующих моделей ОС. Аппаратная часть проекта будет верифицироваться и реализовываться с помощью Verilog-2005 или VHDL с использованием созданных ранее функциональных прототипов. Такой подход является одной из моделей использования (контекстом) SystemC в проектировании на системном уровне. Конечно, SystemC можно также использовать для построения не временных (untimed) функциональных аппаратных моделей, затем трансформируя их в реализацию на уровне регистровых передач (RTL), и далее синтезировать или транслировать вручную в реализацию с помощью Verilog или VHDL. Это также интересная модель использования SystemC в качестве языка системного проектирования.

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

Перечислим распространенные методы проектирования, использующие разные уровни моделирования: объединение модели уровня детальной реализации (например, RTL) верифицируемого проекта с абстрактной моделью тестовой платформы, генерирующей тестовые импульсы и отслеживающей отклики; использование более абстрактной модели отдельного IP блока с целью ускорения симуляции или защиты интеллектуальной собственности блока; детализация одного блока с уровня спецификации на уровень транзакций и далее в RTL модель, и последующее объединение данного блока в единую системную модель с другими блоками, оставшимися на уровне спецификации.

Точность моделирования

Как и в случае VSIA (Virtual SiPket Interface Alliance) классификации проектных моделей системного уровня, при изучении любой модели и ее сравнении с конечной реализацией мы можем измерить точность модели по нескольким независимым направлениям. Сюда входит структурная точность: степень различия между моделью и фактической реализацией структуры. Модель может быть точным поведенческим представлением функциональности модуля и его внешнего интерфейса, но при этом ее внутренняя структура может сильно отличаться от структуры конечной реализации IP блока или модуля. Например, модуль может содержать аппаратные и программные подсистемы, но при этом абстрактная функциональная модель может не отражать любую из этих внутренних структур. Аппаратно реализованный IP блок будет иметь детальный интерфейс выводов (pins) на основе сигналов, но структура модели интерфейса может использовать абстрактный интерфейс с более сложными типами данных с целью более эффективного выполнения модели.

Временная точность системных моделей может очень сильно меняться. Вначале временная точность может быть просто на уровне упорядочивания событий

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

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

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

Модели вычислений

Модель вычислений (model of computation - МоС) является фундаментальным понятием в проектировании на системном уровне. Модель вычислений неформально можно представить как конкретный стиль моделирования, лучше всего соответствующий данному проекту или прикладной области и при этом обладающий свойствами, полезными в симуляции, синтезе и/или анализе. Например, системную модель многих приложений по обработке сигналов и изображений можно создать с помощью модели потока данных, точнее, одного из ее вариантов – SDF (synchronous data flow - синхронный поток данных). Если системная модель соответствует SDF принципам, то можно создать эффективные симуляционные модели и планы реализации. Другие МоС могут поддерживать некоторые методы формального анализа.

Более формально модель вычислений можно задать тремя определениями:

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

- взаимодействие процессов между собой. Семантика событий, объектов, токенов и передачи данных от одного процесса к другому;

- условия активации или »запуска» процесса (иногда называемые «правилами запуска процесса»). В модели потока данных, например, процесс запускается при условии наличия определенного количества токенов на входах.

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

Язык SystemC поддерживает многие возможные модели вычислений, и его открытость позволяет больше экспериментировать. Было успешно проведено много экспериментов, например, сети процессов и потоков данных (сети процессов Кана (Kahn)), аппаратное моделирование на уровне RTL, сетевое моделирование, связывание симуляционного ядра SystemC с непрерывным временным моделированием и симулированием (для AMS проектов) и сетевые симуляторы.

Функциональное моделирование

Функциональные модели системы также известны как исполняемые спецификации. В общем, это проектные спецификации и требования, транслированные в SystemC модель или иерархию моделей. Предполагается, что эти функциональные модели совершенно не связаны с возможной реализацией. Однако обычно в функциональные модели, в их разбиение на части и структуру уже заложены некоторые представления проектировщика о том, как модель может быть реализована хотя бы на одной платформе. Например, хотя в теории модель кодирования или декодирования данных может быть одним процессом, независимым от любого разделения проектной спецификации на аппаратную и программную компоненты, проектировщик, заранее представляющий себе, как алгоритм может быть реализован, возможно на основе предыдущего опыта с похожими алгоритмами в других системах, может создать модель, состоящую из двух или более последовательных процессов, некоторые из которых явно предназначены для аппаратной реализации, а некоторые – для выполнения на RISC или DSP процессоре. Поэтому довольно трудно настаивать на исполняемых спецификациях, которые полностью независимы от реализации; иногда опыт проектирования, отраженный в структуре функциональной модели, является слишком ценным, чтобы им пренебречь.

Функциональные модели могут быть временными (timed) или невременными (untimed). Так как мы имеем дело с функциональной спецификацией, то в процессе нисходящего проектирования (top-down) имеет смысл начать с невременной функциональной модели и затем добавить информацию о задержках в процессе детализации. Однако, так как функциональная модель не зависит от реализации, эта информация о задержках не должна рассматриваться как часть детальной реализации, это просто временные ограничения, которые должны быть переданы процессу реализации, - требования к минимальной производительности системы, наложенные проектируемой системой и ее характеристиками.

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

Для моделирования алгоритмов очень часто используется такой тип функционального моделирования, как поток данных (dataflow), особенно в прикладных областях обработки сигналов и изображений. Наиболее общей моделью вычислений является сеть процессов Кана (Kahn), специальные случаи которой — статическая и динамическая модели потоков данных. Такие алгоритмические функциональные модели отображают с помощью акторов (actors) входные потоки токенов данных в выходные потоки преобразованных данных. SystemC обеспечивает эффективные способы реализации сетей процессов и моделей потоков данных, используя потоки, FIFO каналы и методы блокировки чтения/записи. К таким функциональным моделям легко можно добавить временные задержки.

Для общего управления очень часто используются конечные автоматы. Они могут взаимодействовать с моделями потоков данных; а временные и невременные модели также могут взаимодействовать с помощью FIFO каналов.

Моделирование на уровне транзакций

Моделирование на уровне транзакций позволяет абстрагировать взаимодействие между модулями, так что функции модулей определяются точно, а взаимодействие между ними оптимизировано для ускорения симуляции. Эта оптимизация достигается с помощью использования абстрактных типов данных для описания передаваемой между модулями информации вместо индивидуальных битовых сигналов, определяемых индивидуальными событиями, а также с помощью интерфейсных методов вместо сигнальных событий. В общем, симуляция на уровне сигналов и выводов заменяется эффективными методами обращений, которые передают целые структуры данных. Это позволяет увеличить скорость симуляции в 100-1000 раз по сравнению с симуляцией на RTL. Вдобавок к этому при моделировании на уровне транзакций некоторые транзакции вначале могут вообще игнорироваться. Из полного набора транзакций шины некоторые транзакции ошибок или аварийной остановки могут не моделироваться вообще, или моделироваться только на следующем этапе с целью концентрации начальных усилий на ключевых транзакциях передачи данных (передача слов и пакетные чтение/запись), поддерживаемых моделью шины. Стадия арбитража (выяснение приоритетов доступа к шине) может игнорироваться в начальном моделировании и будет добавлена на следующем этапе, либо в процессе детализации на основе подстановки (из библиотеки).

У специалистов, связанных с OSCI (Open SystemC Initiative), существует большой интерес в определении стандартного набора типов транзакций с целью их использования в системном моделировании и в обеспечении взаимодействия разных IP моделей, включая транзакции, как с точки зрения SW программиста ("программная модель"), так и с точки зрения аппаратного проектировщика ("аппаратная модель с точностью до такта"). Методы детализации на основе библиотечной подстановки могут поддерживать использование таких транзакционных моделей на указанных уровнях на основе стандартного набора API интерфейсов.

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

Уровень RTL и связь с реализацией

Язык SystemC позволяет детализировать существующую модель или создать новые модели и точно определить степень синтезабельности RTL моделей в VHDL или Verilog.

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

В маршруте проектирования нет необходимости в детализации SystemC модели до RTL уровня, разве что по соображениям удобства. Возможность взаимодействия с программами HW симуляции позволяет объединить вместе модели на SystemC и HDL; поведенческий синтез позволяет избежать SystemC моделей на RTL уровне; также возможна трансляция подмножества SystemC в конструкции RTL.

Верификационные расширения

Библиотека верификации SystemC (SCV) [7, 8] предлагает SystemC сообществу много новых возможностей тестирования, она была создана как библиотека расширений на основе SystemC и базовых библиотек SystemC.

SCV позволяет создавать верификационные IP-блоки, которые можно рассматривать и как IP для проектирования SiP, и как IP для повторного использования в других проектах. Учитывая, насколько много усилий (в процессе проектирования) уходит на верификацию (по неформальным оценкам - 50-70 %), возможность создания верифицированного IP становится очень важной.

В основные верификационные возможности SCV библиотеки входит:

- самодиагностика (introspection) данных и возможность манипулировать элементами данных произвольных типов. На базе этого SCV может манипулировать заданными пользователем типами и ссылаться на них - например, структуры, отображающие пакеты и фреймы. Это обеспечивает возможность PLI (Programming Language Interface - Verilog) доступа к таким объектам и позволяет определить все атрибуты или характеристики этих типов;

- запись транзакций, что делает верификацию на основе транзакций (TBV) дополняющей частью моделирования систем на уровне транзакций. При этом TBV с помощью маркировки набора событий как одной «транзакции» позволяет записать симуляцию на уровне отдельных событий и абстрагировать результат на уровень общих транзакций тестовой платформы, а также позволяет маркировать и записывать транзакции на этом уровне абстракции. SCV позволяет группировать связанные транзакции в потоки, что дает возможность проведения поиска по результатам симуляции, создания верификационных транзакций высокого уровня, а также наблюдающих и контролирующих программ;

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

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

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

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