Диссертация (1150736), страница 10
Текст из файла (страница 10)
Отсутствие этихкомпонент приводит к уменьшению расхода энергии.Реализация среды управляемого исполнения на устройстве требует дополнительных ресурсов, что приводит к опасению о неэффективности такого решения по сравнению с традиционными. Действительно, существуют причины в архитектуре средств управляемого исполнения, приводящие к некоторойнеэффективности:∙ Строгая типизация требует дополнительных проверок во время исполнения, которые в языках С, С++ остаются на совести программиста. Современные компиляторы позволяют проводить эти проверки однократно, вынося их из циклов, что делает их влияние на скорость работыпрограммы незаметной. Наличие строгой типизации и отсутствие небезопасных указателей во многих случаях позволяет компиляторам выполнять более агрессивные операции, например, связанные с векторизациейциклов.∙ Для эффективной сборки мусора размер кучи должен превосходить размер динамически размещаемых в памяти данных в 2 раза [57].
Длявстроенных применений, связанных с цифровой обработкой сигналов,это не является серьезной проблемой, поскольку большинство данныхразмещается в памяти статически.52∙ Сборка мусора может приводить к задержкам. Использование инкрементальных алгоритмов, таких как Метроном [58] или инкрементальнаяконкурентная разметка и очистка, позволяет добиться контролируемойдетерминированной задержки, не превышающей единиц миллисекунд.Критические к задержкам части кода в любом случае традиционно неиспользуют динамическое распределение памяти.∙ Внутренние структуры данных для обеспечения типизации, рефлексиии обработки исключений занимают дополнительную память и вычислительные ресурсы. Рефлексия и неограниченная обработка исключенийявляется неотъемлимой частью языков Java и C#.
Поскольку эти возможности не используются для систем реального времени, то они могутне поддерживаться в специализированных реализациях.Таким образом, использование сред управляемого исполнения для системного программирования не представляет непреодолимых препятствий. В исключительных случаях для повышения эффективности управляемая программа может вызывать внешние неуправляемые библиотеки через интерфейсвнешних функций.
Даже в этом случае среда управляемого исполнения обеспечивает большую защиту от ошибок, поскольку ошибки часто локализованыво вновь написанном интеграционном коде, а не в библиотеках.Для использования во встраиваемых устройствах сейчас доступны технологии Sunspot [59] и Micro.NET [60]. Последняя технология доступна под открытой лицензией APL [61], что позволяет портировать ее под любые процессорные архитектуры. Она может использоваться на устройствах с минимальной оперативной памятью 300Кб, что сопоставимо с типичными требованиями операционных систем без поддержки страничной памяти.1.11Формальная верификация как средство повышения энергоэффективностиНаличие ошибок в программах, в том числе в программах для синтеза аппаратуры, приводит к необходимости механизмов их обработки на программ53ном и аппаратном уровне.
Гарантии отсутствия ошибок обеспечивают возможность удаления этих механизмов и экономии энергии. Наиболее сложными для обнаружения являются ошибки синхронизации и родственные ошибки,связанные с переполнением очередей при асинхронном взаимодействии. Возможность наличия таких ошибок приводит к необходимости переноса механизмов синхронизации в программные компоненты устройства, где они могутбыть исправлены после производства аппаратной части или внесения в аппаратную часть механизмов контроля длины очереди и остановки вычисленийдля разгрузки очереди. Это приводит к существенным накладным расходам иросту энергопотребления.Следует обратить внимание, что ошибки могут возникать и при изготовлении устройства, поэтому верификация проекта не исключает необходимостимеханизмов обнаружения ошибок изготовления, таких как схемы встроенногосамотестирования (Built-In Self-Test) [62].Для гарантирования отсутствия ошибок синхронизации в некоторых случаях возможно привести программу к циклостатическому виду, построивдля ее выполнения фиксированное расписание.
Аналогичный подход используется для автоматической конвейеризации логических схем средствами автоматического логического синтеза [63]. Для разработки более сложныхустройств предложена реактивная модель программирования и семейство языков для синхронного программирования потоков данных такие как Lustre [64],Estrel [65], Streamit [66]. Этот подход работает для сравнительно простых программ и плохо применим к программам со сложной управляющей логикой,не сводимым эффективным образом к потоку данных. Кроме того, требуетсяпереписывание программы в другой модели по сравнению с обычными императивными языками C, C++.
Это затрудняет разбиение задачи на аппаратные ипрограммные компоненты. Эти причины привели к тому, что подход не нашелширокого промышленного применения.Другой, более универсальный подход к синхронизации на основе сетей Кана [67] и асинхронного обмена сообщениями часто применяется в индустрии,например, при синтезе схем в CatapultC. В общем случае подход требует бесконечной памяти для гарантий отсутствия ошибок синхронизации, что является не реализуемым в аппаратуре. В некоторых случаях может быть построено54статическое расписание, но размер памяти может быть очень большим. Крометого, модель сетей Кана существенно ограничивает использование синхронных механизмов событий, таких как прерывания.Таким образом, востребованы средства формальной проверки программына наличие ошибок синхронизации в рамках промышленно используемых моделей разработки аппаратуры и программирования, таких как С++ и SystemC.Использование таких средств может позволить существенно сократить энергопотребление малопотребляющих специализированных полупроводниковыхустройств.Задача тестирования и отладки ошибок синхронизации является одной изосновных проблем в разработке программного обеспечения.
Для последовательных программ, для которых синхронизация не требуется, необходимыйуровень качества может быть достигнут при помощи полного покрытия кода модульными тестами. Для параллельных программ это не так, поскольку небольшие изменения в окружении исполнения непредсказуемо влияют нарасписание исполнения и приводят к воспроизведению не воспроизводимыхранее ошибок [68].Для программно-аппаратных систем проблема приобретает еще большеезначение.
Такие системы имеют большую сложность по сравнению с чистоаппаратными системами и большее количество связей между программнымии аппаратными компонентами по сравнению с системами на основе процессоров общего применения. Для экономии ресурсов программное обеспечениеможет работать без операционной системы и с ограниченными возможностями отладки и протоколирования ошибок. В случае, если ошибка синхронизации затрагивает аппаратные компоненты, ее исправление требует изготовления партии кристаллов новой версии. Использование средств высокоуровневого синтеза уменьшает трудности разработки программно-аппаратных систем,что позволяет разрабатывать системы с более сложной аппаратной частью вкороткие сроки.
Это, в свою очередь, увеличивает риск появления ошибоксинхронизации а аппаратных компонентах.Обычно выделяют три типа ошибок синхронизации:551. Тупик, когда система или ее часть приходит в состояние вечного ожидания невозможного события без использования вычислительных ресурсов;2.
Повисание, когда система или ее часть находится в состоянии вечногоцикла без выполнения полезной работы;3. Конкурентная модификация данных, когда несколько компонент системы в результате нарушения порядка записи данных нарушают их целостность.В общем случае, при наличии бесконечной памяти задача обнаруженияошибок синхронизации является алгоритмически неразрешимой [69]. На конечной памяти задача имеет в худшем случае экспоненциальную сложность.Существует 4 основных подхода к автоматической проверке правильностипрограмм.1.
Подходы на основе автоматического доказательства теорем;2. Проверка на моделях;3. Подходы на основе статического анализа;4. Подходы на основе динамической проверки (инструментации и запуска).Эти подходы обладают различным балансом точности, полноты и вычислительной сложности.
Подходы на основе проверки на моделях и доказательства правильности в общем случае абсолютно точны и полны, но вычислительная сложность ограничивает их применение к большим проектам или требует ручного извлечения сокращенной модели или ручного наложения ограничений и контрактов, что приводит к дополнительным затратам труда и рискуошибки.Динамический подход обладает в общем случае наименьшей вычислительной сложностью за счет уменьшения полноты и точности, поскольку полностью зависит от полноты внешнего тестового покрытия.С целью автоматического обнаружения ошибок синхронизации при участии автора была разработана система “Aegis for SystemC” на основе стати56ческого анализа и эвристических шаблонов корректных моделей синхронизации SystemC.
Этот подход позволяет за счет применения эвристик объединения состояний системы добиться практически реализуемой сложности дажедля больших систем. Уменьшение сложности достигается за счет уменьшенияточности анализа, то есть могут происходить ложные срабатывания.В первой версии был реализован подход, обычно применяемый в для программного обеспечения, на основе анализа порядка вызовов синхронизационных примитивов wait, notify [20]. Данный подход позволяет обнаруживатьтолько тупики и не применим к синхронно-асинхронным системам, включающим тактируемую модель аппаратуры и асинхронное программное обеспечение, управляемое событиями из-за экспоненциального роста сложности.В дальнейшем был разработан универсальный подход на основе анализадостижимости операторов в модели корректной программы на SystemC [21].Данный подход позволяет обнаруживать все 3 типа ошибок синхронизации иприменим к синхронным и асинхронным моделям и их комбинации.Для уменьшения вычислительной сложности условия задачи были ограничены.
Рассматривалась синхронно-асинхронная модель с набором стохастических тестов. Целью было обнаружение только тех ошибок, которые могутбыть воспроизведены системой тестов. Таким образом, система “Aegis forSystemC” может быть рассмотрена как расширение тестового покрытия системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
