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

№ 4’2004
Мультипроцессорные решения для встроенных систем разрабатываются для обеспечения все возрастающих потребностей в вычислительных мощностях. Тем не менее для облегчения труда разработчиков прикладного ПО таких систем практически ничего не сделано. Авторы предлагают систему моделирования SimBridge (Simulation Bridge), использующую общий движок моделирования, который обрабатывает и внутрипроцессорную информацию, и межпроцессорные связи.

Мультипроцессорные решения для встроенных систем разрабатываются для обеспечения все возрастающих потребностей в вычислительных мощностях. Тем не менее для облегчения труда разработчиков прикладного ПО таких систем практически ничего не сделано. Авторы предлагают систему моделирования SimBridge (Simulation Bridge), использующую общий движок моделирования, который обрабатывает и внутрипроцессорную информацию, и межпроцессорные связи.

Введение

Появление программ для встроенных систем потребовало создания высокоэффективных DSP, чтобы соответствовать возросшим требованиям к вычислительным мощностям. Помимо всего прочего, особую важность приобретает проектирование мультипроцессорных систем на DSP и повышение уровня интеграции для достижения производительности, измеряемой в десятках и сотнях миллионов операций в секунду (MIPS). Например, у Texas Instruments есть системы TNETC4320, OMAP1510 и TMS320C5471, интегрирующие микроконтроллер и DSP на одном чипе, а также устройства типа TMS320C5421 и TMS320C5441, включающие от 2 до 4 DSP вместе с набором совместно используемых периферийных подсистем — память с контроллером прямого доступа (DMA), последовательные порты и контроллеры других устройств.

Разработчик приложения (будем использовать термин «разработчик приложения» в смысле «разработчик программного обеспечения приложения») должен понимать особенности таких архитектур, чтобы реализовать и оптимизировать свои решения. Эти особенности включают: индивидуальный набор инструкций для каждого процессора, характеристики доступа совместно используемой памяти, необходимые трансляции адресов, семантика межпроцессорного взаимодействия, использование общедоступных периферийных подсистем, обработка прерываний, режимы начальной загрузки и иерархические (master-slave) отношения. Таким образом, для того чтобы лучше понять архитектуру, исполнить проверку правильности и оптимизацию своего приложения, разработчик заинтересован в выполнении реальных прикладных программ на таких архитектурах. Также нужно обратить внимание на то, что разработчикам приложений удобнее работать на уровне команд, чем на RTL или на уровне вентилей. Это возможно при использовании высокоточных, высокопроизводительных и полнофункциональных систем моделирования, которые могут смоделировать реальный запуск приложения на определенной архитектуре, учитывая и все детали моделирования, и эффективность модели.

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

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

Текущее состояние технологии

Мультипроцессорное моделирование — проблема, уже хорошо известная в области автоматизации проектирования электронных приборов и устройств (Electronic Design Automation, EDA). Такие системы моделирования, как Seamless [9], VCC [1] и другие HDL-системы, обеспечивают нас возможностью создавать и моделировать мультипроцессорные системы. HDL-среды моделирования обычно работают на уровне RTL, что налагает большие ограничения на эффективность самого моделирования. Seamless работает лучше, позволяя связать с помощью интерфейса модели наборов команд с HDL-моделями, что с точки зрения разработчика приложения выглядит как работа на более высоком уровне инструкций. В то время как использование Seamless и ее режимов оптимизации повышает производительность, быстродействие все еще ограничивается медлительностью HDL-моделей. Seamless хорошо работает в области аппаратно-программного взаимодействия низкого уровня, но что касается общей производительности приложения, то она еще не достаточно удовлетворительна. VCC работает с различными уровнями представления системы, часто пренебрегая эффективностью в пользу точности. В то время как этот подход хорошо работает для аппаратно-программного исследования и разделения, это не лучший вариант для отладки и настройки приложений.

Существует еще несколько работ по мультипроцессорному моделированию. Большинство из них представляет критерии оценки для архитектуры памяти [5, 12, 2 и 10]. Они работают с конкретной системой команд, позволяя изменять число процессоров и архитектуру памяти. Луис Баирига [8] представил очень хороший краткий обзор различных подходов к мультипроцессорному моделированию и их относительных достоинств и недостатков.

Несколько других решений больше касается проблемы, которую мы пытаемся разрешить, но ни одно из них, кажется, не в состоянии дать готовое решение. В симуляторе SPARC [2] и Wisconsin Wind Tunnel [10] обеспечивается многопотоковая синхронизация и степени детализации при синхронизации, но они оба эти симулятора работают с одной конкретной моделью системы команд, и они не универсальны, чтобы их можно было применить в архитектурах с другими наборами команд. Pia [6] и «Иерархическая среда моделирования архитектур» [3] рассматривают системы, которые раскрывают структуру связи и ее абстрактное представление, но обе эти системы отделены от самой модели, которая и должна моделироваться. Хотя они и называются едиными системами, но приводят к разделению между самой системой и моделями для моделирования.

Ключевые моменты

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

Управление работой моделируемых процессоров

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

Рис. 1. Блочная схема мультипроцессорной системы(прямоугольники означают периферийные компоненты, линии показывают связи)
Рис. 1. Блочная схема мультипроцессорной системы (прямоугольники означают периферийные компоненты, линии показывают связи)

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

Планирование и синхронизация моделируемых компонентов

Важное значение имеет степень детализации атомарного шага моделирования: осуществляется моделирование по тактам системных часов или оно изменяется сразу на больший отрезок времени? Это влияет на выбор стратегии планирования и синхронизации.

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

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

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

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

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

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

Взаимодействие компонентов

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

Проект SimBridge

SimBridge — это система мультипроцессорного моделирования, написанная на C. Она предназначена для того, чтобы расширять существующие модели процессоров, наборов команд и совместно используемых подсистем. Это позволяет использовать ее для сбора и фиксации данных о любой мультипроцессорной системе, используя написанные на C модели различных подсистем процессора и абстрактные модели других модулей системы. Интегрируя все модели в единое однопотоковое приложение, можно получить высокопроизводительную систему.

На рис. 2 изображена общая архитектура проекта мультипроцессорной системы, разработанного в SimBridge. SimBridge располагается между уровнем пользовательского интерфейса front-end (FE) и самими моделями. Ситсема SimBridge предназначена для того, чтобы объединить («проложить мост») модели всех процессоров в мультипроцессорную систему. Во время создания такой системы формируются связи между различными подсистемами и становится возможным взаимодействие системы во времени выполнения. Весь поток управляющих данных между интерфейсом FE и моделями перехватывается и обрабатывается, обеспечивая всю необходимую функциональность и синхронизацию.

Составные части проекта

SimBridge состоит из трех модулей: менеджер исполнения, механизм обработки событий и модуль интеграции процессоров (см. рис. 2). 1. Менеджер исполнения. Этот модуль поддерживает пользовательские команды исполнения: запустить приложение (run), исполнить один шаг (step), групповое исполнение (group run) и групповой шаг (group step). Как видно на рис. 2, SimBridge охватывает все модели с обеих сторон. Это позволяет менеджеру исполнения осуществлять полный контроль над работой всей мультипроцессорной системы. Он обеспечивает следующую семантику для групповых команд выполнения (исполнение и шаг одного процессора рассматриваются как частные случаи группового исполнения и шага с размером группы, равным 1):

  • групповое исполнение: процессоры, входящие в группу, находятся в жесткой конфигурации — тактирование происходит поочередно для каждого процессора, так что сохраняется общее глобальное время. Завершение группового исполнения происходит всякий раз, когда любой процессор отрабатывает свой временной лимит, либо какой-либо процессор достигает точки останова.
  • групповой шаг: эта команда подобна команде группового исполнения за исключением того, что завершение этой команды происходит, когда все процессоры исполнят по одной команде.
  • обработки событий. Механизм обработки событий, основанный на «Основном интерфейсе системного моделирования» (Core System Simulation Interface, [4]), поддерживает работу с событиями и обеспечивает связь данных между компонентами во всей системе. Компоненты отправляют события (со специфическими для каждого события данными) в механизм обработки событий. Этот механизм, в свою очередь, отправляет уведомление о получении события всем «слушающим» его объектам. Слушающий объект считывает данные, пришедшие вместе с событием, и может в ответ инициализировать собственные события. Таким образом, никакому компоненту не нужно знать, ждут ли в данный момент информацию на его выходах другие компоненты. Механизм обработки событий гарантирует, что уведомления об отправленных событиях будут посылаться в порядке, соответствующем понятию «дельта моделирования»: все уведомления делаются только после того, как завершается текущий цикл активности. Это обеспечивает возможность высокоточного моделирования. Информация о событиях и соответствующих контактах, по которым передаются все данные, первоначально заносится в механизм обработки событий посредством модуля процессорной интеграции (см. далее). «Слушающие» компоненты (то есть те, которые ожидают появления определенных событий) также регистрируют себя в этом механизме, указывая, о каких событиях их надо уведомлять. Механизм обработки событий не различает межпроцессорные и внутрипроцессорные уведомления о событиях. Таким образом, один общий механизм обработки событий обеспечивает необходимую гибкость и видимость компонентов друг для друга. 3. Модуль процессорной интеграции. SimBridge требует входную информацию о связности системы. Эта информация включает в себя список событий и контактов, используемых компонентами. SimBridge фиксирует эти «списки» через модуль процессорной интеграции, который обеспечивает механизм обработки событий списком событий и контактов, используемых компонентами для взаимодействия. Можно отметить, что этот модуль должен быть реализован отдельно для каждой мультипроцессорной конфигурации.
  • исполнения и тактовая синхронизация
Рис. 2. Моделирование мультипроцессора с помощью SimBridge
Рис. 2. Моделирование мультипроцессора с помощью SimBridge

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

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

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

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

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

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

Изучение примера и результаты по производительности

Оценка работы SimBridge проводилась на двух примерах: тест, копирующий поведение моделей процессоров, и модель, основанная на TMS320C54x.

Экспериментальная установка

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

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

На рис. 3 показана зависимость времени моделирования от увеличения числа процессоров. Все процессоры были синхронизированы при одинаковой скорости выполнения и моделирование длилось 5 миллионов циклов.

«Идеальная» линия была получена простым масштабированием времени работы одного процессора на число процессоров вне экспериментальной установки SimBridge.

Рис. 3. Время моделирования/число процессоров
Рис. 3. Время моделирования/число процессоров
Рис. 4. Время моделирования/изменяющаяся тактовая частота
Рис. 4. Время моделирования/изменяющаяся тактовая частота

Линейная экстраполяция SimBridge была получена масштабированием времени работы одного процессора на число процессоров в экспериментальной установке SimBridge. Фактическая погрешность — это различие результата SimBridge и «идеального» результата. Линейная погрешность — рассчитанная погрешность для одного процессора. Понятно, что погрешность SimBridge не увеличивается с ростом числа процессоров.

На рис. 4 показано отношение «время моделирования/изменяющаяся тактовая частота» в конфигурации с двумя процессорами. Моделирование длилось 5 миллионов циклов (для процессора самой высокой тактовой частоты). Кривая показывает, что время моделирования уменьшается с увеличением частоты. Это происходит потому, что при увеличении частоты случается все меньше тиков для процессоров с меньшей частотой, и из-за этого системе требуется меньше ресурсов для синхронизации. Таким образом, общая производительность стремится к производительности процессора с самой высокой частотой. Из-за дополнительной стоимости реализации таких двухпроцессорных систем результирующая производительность будет несколько ниже идеальной.

Поскольку SimBridge был оптимизирован для эффективного планирования и синхронизации, из-за его универсальности может теряться производительность моделирования. Для ее повышения был внесен ряд поправок (используя данные о тактовых частотах и числе процессоров). Эффективность полученной системы сравнивалась с идеальной системой, которую мы назвали «автономная». Таблица 1 показывает, что погрешности моделирования могут быть значительно снижены при использовании конкретных подходов для каждой области разработки.

Моделирование установки на основе TMS320C54X

Установка на основе TMS320C54X включает точные написанные на C модели ЦПУ TMS320C54X вместе с памятью на чипе и вне чипа, таймерами и последовательными портами [11]. Чтобы измерить реальную производительность моделирования, модель запускалась 3 раза и была интегрирована в SimBridge, чтобы смоделировать реальное поведение мультипроцессорной системы. Данные получены при выполнении идентичных копий матричной прикладной программы на всех указанных моделях.

Таблица 1. Сравнение эффективности универсальной, специально настроенной и автономной установок (все время в секундах)
Таблица 1. Сравнение эффективности универсальной,специально настроенной и автономной установок (все время в секундах)
Таблица 2. Эффективность моделирования TMS320C54x
Таблица 2. Эффективность моделирования TMS320C54x

Таблица 2 показывает, что SimBridge достаточно эффективно моделирует мультипроцессорные системы — порядка нескольких сотен kcps (cps — cycles per second, циклов в секунду). В то время как однопроцессорная система работает с некоторыми потерями в производительности, варианты с двумя и тремя процессорами показывают, что SimBridge очень эффективно интегрирует процессоры, работая при этом с очень небольшими затратами на синхронизацию. Данные демонстрируют, что вполне реально осуществить моделирование работы приложения на мультипроцессорной системе, используя точные модели на C.

Заключение

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

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

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

Литература

  1. Cadence Virtual Component Codesign Environemt. http://www.cadence.com/ datasheets/vcaanvironmenthtm L
  2. Sunada D., Glasco D., Flynn M. ABSS v2.0: a SPARC Simulator. Technical Report CSL-TR-98-755. Comp. Systems Laboratory. Stanford Unit. April 1998.
  3. Howell F. W., Williams R., Ibbett R. N.,
  4. Architecture Design and Simulation Environment», Dept. of Computer Science, Unit. of Edinburgh.
  5. Ish Kumar Dham. Towards extending cycle accurate CPU Instruction Set Simulator to Chip Level Simulator a case study. TI India Technical Conference. May 1998.
  6. Veenstra J. E., Fowler R. J. MINT Tutorial and User Manual. Technical Report TR-452. The Unit. of Rochester. Comp. Sci. Dept. June 1993.
  7. Hines K. Pia: A Framework for Embedded System Co-simulation with Dynamic Communication Support. Unit. of Washington. 1996.
  8. Lamport L. Time, Clocks, and the Ordering of Events in a Distributed System. Comm. of the ACM. Vol. 21. No. 7. July 1978.
  9. Barriga L., Ayani R. Towards Efficient Simulation of Parallel Architectures. Technical Report TRiTA-iT R 94:07. Dept of Teleinformatics. Royal Institute of Technology. Stockholm, Sweden. Marct 1994.
  10. Seamless Hardware/Software Co-Verification. http://www.mentor.com/seamless/datasheets/.
  11. Mukherjee S. S. et. al. Wisconsin Wind Tunnel II: A Fast and Portable Parallel Architecture Simulator. Workshop on Performance Analysis and Its Impact on Design (PAID). June 1997.
  12. TMS320C54X, TMS320LC54X, TMS320VC54X Fixed-point digital signal processors. Texas Instruments. Literature Number: SPRS039C. February, 1996.
  13. Pia V. S. et. al. RSIM: An Execution-Driven Simulator for ILP-Based Shared-Memory Multiprocessors and Uniprocessors. Dept. Of Electrical and Comp. Engg. Rice University. 1997.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *