Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Системы реального времени. Методическое пособие
.pdf
этом случае выход будет заперт сразу после перехода входного сигнала в нуль. Несложно предложить и другие формы использования
для борьбы с гонками сведений о минимально возможной задержке
или о наибольшей возможной кратности максимального и минимального значений задержки.
По возможностям применения этого метода борьбы с гонками
разработчики, использующие различную элементную
базу, находятся в неодинаковых условиях. В лучшем положении обычно находятся разработчики схем, предназначенных для реализации на поверхности кристалла. Результирующая задержка элементов на кристалле
определяется длиной и шириной проводников межэлементных связей и временем переключения транзисторов, которое, в свою очередь, зависит от геометрических размеров элементов его маски.
На
все эти размеры разработчик схемы кристалла может влиять, что позволяет ему в случаях, когда это важно, делать задержку одной группы элементов гарантированно больше задержки другой группы.
Правда, по мере роста числа элементов, размещаемых на одном кристалле, разработчик логических схем все реже допускается к воздействию на геометрические
размеры элементов маски. Технология автоматизированного проектирования схем на перспективных матричных кристаллах разрешает схемотехнику лишь соединять между собой проводниками стандартной ширины уже размещенные на кристалле стандартные транзисторы или логические элементы. Однако и
здесь положение разработчика все-таки лучше, чем того, который
использует отдельные микросхемы, поскольку задержки однотипных
элементов, расположенных на одном кристалле, существенно между
собой коррелируют, чего нельзя сказать о микросхемах даже одной
закупочной партии, одного изготовителя. Эта корреляция позволяет
изготовителю кристаллов после проведения соответствующих исследований постулировать для схемотехника максимально возможную
кратность задержек элементов, расположенных на одном кристалле
данного типа. С точки зрения борьбы с гонками это
во многих случаях не хуже, чем знание минимально возможной задержки. Поэтому
внутри интегральных схем метод борьбы с гонками за счет назначения параллельными путями таких соотношений задержек, при которых опасные гонки невозможны, используется, особенно при построении небольших узлов типа триггеров, счетчиков и т. п.
В худшем положении
находится разработчик, использующий готовые микросхемы, поскольку юридического документа о минимальном значении задержки он чаще всего не имеет. Правда, и тут
81
опытный инженер может утверждать, что при использовании любой
современной серии элементов и при любом их сочетании пробег сигнала по цепочке из, скажем, 64 элементов длится «наверняка» дольше, чем пробег сигнала по параллельной ветви из одного элемента.
На сегодня нет серий, задержка элементов внутри которых отличалась бы в 64 раза. И
в 32 раза тоже нет. И в 16, пожалуй, не найдется.
Относительно восьми можно задуматься, в защиту четырех большинство специалистов серьезно спорить уже не станут, а отклонение
времени задержки вдвое встретится в большинстве серий. Таким образом, если отсутствие гонок обосновывается большой кратностью
числа элементов параллельных путей, то нужно отдавать себе
отчет в
том, чт.е. зоны явно допустимых решений (например, кратность 64) и
зоны явно недопустимых (кратность 2), а граница между ними не
определена. Каждый разработчик определяет ее для себя индивидуально в зависимости от опыта, соотношения поощрения за экономичную схему и наказания за сбои в ней из-за гонок. Проблема из
технической становится психологической, организационной. В инженерной практике пользуются этим приемом и строят схемы, в которых в принципе, юридически, гонки возможны, но по утверждению разработчика их «наверняка» не будет.
В последние годы растет интерес к еще одному методу борьбы с
гонками – построению самосинхронизирующихся схем. Рабочие узлы
в этом
случае строятся непротивогоночными, но они дополняются
специальными схемами, которые обнаруживают факт окончания переходных процессов и вырабатывают разрешающий сигнал для следующих схем, играющий в каком-то смысле роль «асинхронного синхросигнала». Это направление рассматривается как весьма перспективное для построения БИС и особенно сверхБИС, где применение
обычной синхронизации встречает ряд
трудностей. Однако в схемах и
микросхемах обычного размера и технологии это направление пока
не находит применения ввиду как сложности построения такого рода
схем, так и, приблизительно, удвоения их аппаратурных затрат.
Проблема гонок в цифровой схемотехнике является очень серьезной. Большинство трудно обнаруживаемых и удивительно разнообразно проявляющихся ошибок в функциональных
схемах связано с
гонками, возможности появления которых разработчик не заметил.
Основная причина – ограниченность поля внимания человека. При
разработке сложной схемы все внимание поглощается конструированию главного пути распространения сигнала, непосредственно ре-
82
шающего поставленную задачу. При этом побочные, не нужные для
дела пути выпадают из поля зрения, а в них и «таится погибель».
Гонки во вновь разработанной схеме нужно искать специально.
Если есть такая возможность, то наиболее надежным и простым методом является моделирование работы схемы с помощью специальных программ. При поиске
гонок «вручную» сначала нужно выявить
все подозрительные места и затем методически их исследовать. Обнаружению таких мест способствуют специально предпринимаемые
просмотры схемы, нацеленные на выявление всех возможных параллельных путей распространения сигнала. Полезен анализ временных
диаграмм, в которых зоны неопределенности указывают на возможность появления ложных сигналов.
В борьбе с
гонками наряду с излагаемым подходом, ориентированным на гарантированную работу даже при наиболее неблагоприятном сочетании задержек, существуют менее строгие походы, в основе которых лежит утверждение, что худший случай встречается
редко, поэтому для оценки задержки схемы можно брать некоторое
вероятностное значение, меньшее, чем максимально возможное время задержки. Подобные подходы
, против которых в принципе возражать нельзя, для цифровой техники оказываются плодотворными,
только если есть возможность провести абсолютно полное тестирование готового устройства во всех возможных режимах и условиях
окружающей среды.
Если же надежность работы устройства основывается лишь на
статистической правильности работы отдельных его цепей, то, когда
цепей много, что
типично для цифровой техники, даже небольшое
уменьшение надежности срабатывания элементов приводит к резкому снижению надежности всего устройства. Можно подсчитать, что
если в каждой цепочке допустить вероятность помехи из-за гонок
всего в 1 %, то вероятность работоспособности устройства, содержащего 100 таких цепочек, будет около 37 %. В среднем из каждых
трех устройств два будут
неработоспособны. Поэтому приемами,
приносящими в жертву надежность срабатывания отдельных цепочек, в цифровой технике пользоваться не следует.
3. Гонки по входу
Гонки по входу возникают, когда ветвящийся сигнал поступает на
элементы, имеющие разброс по уровню срабатывания (рис. 2.15, а), а
фронт этого сигнала излишне пологий (рис. 2.15, б). Если длитель-
83
ность фронта входного сигнала заметно больше времени срабатывания элементов, то где-то в середине фронта будет существовать отрезок времени, когда с точки зрения одного элемента входной сигнал
уже равен 1, а с точки зрения другого – еще равен 0. Элементы будут
реагировать на один и тот же сигнал как на два различных
, а такая
ситуация при проектировании схемы ее алгоритмом не предусматривается. В результате схема в течение этого времени может выработать ложные сигналы. Это явление и называют «гонки по входу».
Гонки по входу не наблюдаются, если логическая схема собрана на
элементах одной серии микросхем. Потенциально опасны схемы,
собранные из элементов
различных серий, имеющих одинаковый
уровень сигналов, но существенно различные времена задержек и
фронтов. Гонки по входу возникают в схемах некоторых БИС, если
их межэлементные связи сильно заваливают фронты. Опасностью
возникновения гонок по входу объясняются ограничения на максимальную длительность фронтов входных сигналов, приводимые в
паспортах многих микросхем.
Рис. 2.15. Гонки по входу: иллюстрация условий их возникновения
Если нет возможности увеличить крутизну фронта, то единственным средством борьбы с гонками по входу остается тактирование,
поскольку в тактированном устройстве выходной сигнал схемы не
используется до тех пор, пока в этой схеме не окончатся абсолютно
все переходные процессы независимо от их физической природы.
Однако тактирование не спасает от гонок по
самому тактирующему
входу. Поэтому если крутизна фронтов синхросигналов мала, то
нужно применять такие синхронные триггеры, в которых гонки по
входу не возникают.
Контрольные вопросы и задания
1. Дайте характеристику статическому и динамическому переме-
щению при выделении ресурсов.
84
2. Какие способы структуризации виртуального адресного про-
странства Вы знаете?
3. Какие подходы используются при преобразовании виртуальных
адресов в физические?
4. Сравните методы управления, используемые в СРВ и много-
пользовательских системах с разделением времени.
5. Из чего слагается задержка логической схемы?
6. В чем сложность учета задержек?
7. От чего зависит задержка каждого конкретного
элемента?
8. Какие средства анализа переходных процессов в логических
схемах Вы знаете?
9. Дайте характеристику гонкам. В чем суть гонок?
10. Какие методы борьбы с гонками Вы знаете?
11. Дайте характеристику методу тактирования.
12. Какие схемы называются противогоночными? Дайте их харак-
теристику.
13. Дайте характеристику самосинхронизирующимся схемам.
14. Когда возникают гонки по входу?
85
3. ОПЕРАЦИОННЫЕ СИСТЕМЫ
РЕАЛЬНОГО ВРЕМЕНИ
3.1. Архитектура систем реального времени
1. Основные параметры и механизмы операционных систем ре-
ального времени.
2. Базовые концепции построения операционных систем реально-
го времени.
3. Монолитная архитектура.
4. Модульная архитектура на основе микроядра.
5. Объектная архитектура на основе объектов – микроядер.
1. Основные параметры и механизмы операционных
систем реального времени
Одно из коренных внешних отличий систем реального времени от
систем
и систем исполнения. Система исполнения операционных системах
реального времени – набор инструментов (ядро, драйверы, исполняемые модули), обеспечивающих функционирование приложения
реального времени.
ного времени поддерживают целый спектр аппаратных архитектур,
на которых работают системы исполнения (Intel, Motorola,
RISC,MIPS, PowerPC, и другие). Это объясняется тем
паратных средств является частью комплекса реального времени и
аппаратура должна быть также адекватна решаемой задаче. Поэтому
ведущие операционные системы реального времени перекрывают
целый ряд наиболее популярных архитектур, чтобы удовлетворить
самым разным требованиям по части аппаратуры. Систему исполнения операционных системах реального времени и компьютер, на котором
тема разработки – это набор средств, обеспечивающих создание и
отладку приложения реального времени.
пространенных ОС, таких как UNIX. Кроме того, многие операционные системы реального времени имеют и так называемые резидентные средства разработки, исполняющиеся в среде самой
ной системы реального времени – особенно это относится к операционным системам реального времени класса «ядра».
86
общего назначения – четкое разграничение систем разработки
Большинство современных ведущих операционных систем реаль-
, что набор ап-
она исполняется, называют «целевой» (target) системой. Сис-
Системы разработки работают, как правило, в популярных и рас-
операцион-
Функционально средства разработки операционных систем реального времени отличаются от привычных систем разработки, таких,
например, как Developers Studio, TaskBuilder, так как часто они содержат средства удаленной отладки, средства профилирования (измерение времен выполнения отдельных участков кода), средства эмуляции целевого процессора, специальные средства отладки взаимодействующих задач, а иногда и средства моделирования. Рассмотрим
ос-
новные параметры операционных системах реального времени.
Время реакции системы. Практически все производители систем
реального времени приводят такой параметр, как время реакции системы на прерывание (interrupt latency). Если главным для системы
реального времени является ее способность вовремя отреагировать
на внешние события, то такой параметр, как время реакции системы,
является ключевым.
настоящее время нет общепринятых методологий измерения
В
этого параметра, поэтому он является полем битвы маркетинговых
служб производителей систем реального времени. Но уже появился
проект сравнения операционных систем реального времени, который
включает в себя в том числе и разработку методологии тестирования.
Рассмотрим времена, которые необходимо знать для того, чтобы
предсказать время реакции системы
. События, происходящие на
объекте, регистрируются датчиками, данные с датчиков передаются
в модули ввода-вывода (интерфейсы) системы. Модули вводавывода, получив информацию от датчиков и преобразовав ее, генерируют запрос на прерывание в управляющем компьютере, подавая
ему тем самым сигнал о том, что на объекте произошло событие. Получив сигнал от
модуля ввода-вывода, система должна запустить
программу обработки этого события. Интервал времени – от события
на объекте до выполнения первой инструкции в программе обработки этого события – и является временем реакции системы на события. Проектируя систему реального времени, разработчики должны
уметь вычислять этот интервал и знать из чего он складывается.
выполнения цепочки действий – от события на объекте до
Время
генерации прерывания – не зависит от операционных систем реального времени и целиком определяется аппаратурой, а интервал времени – от возникновения запроса на прерывание до выполнения первой инструкции обработчика – определяется целиком свойствами
операционной системы и архитектурой компьютера. Причем это
время нужно уметь
оценивать в худшей для системы ситуации, т.е. в
предположении, что процессор загружен, что в это время могут про-
87
исходить другие прерывания, что система может выполнять какие-то
действия, блокирующие прерывания.
Основанием для оценки времен реакции системы могут служить
результаты тестирования с подробным описанием архитектуры целевой системы, в которой проводились измерения с точным указанием,
какие промежутки времени измерялись. Некоторые производители
операционных систем реального времени результаты такого тестирования предоставляют
.
Время переключения контекста. В операционные системы реального времени заложен параллелизм, возможность одновременной
обработки нескольких событий. Поэтому все операционные системы
реального времени являются многозадачными (многопроцессными,
многонитиевыми). Чтобы уметь оценивать накладные расходы системы при обработке параллельных событий, необходимо знать время, которое система затрачивает на передачу управления от процесса
процессу (от задачи к задаче, от нити к нити), т.е. время переклю-
к
чения контекста.
Размеры системы. Для систем реального времени важным параметром является размер системы исполнения, а именно суммарный
размер минимально необходимого для работы приложения системного
набора (ядро, системные модули, драйверы и т.д.). С течением времени значение
этого параметра уменьшается, тем не менее он остается
важным и производители систем реального времени стремятся к тому,
чтобы размеры ядра и обслуживающих модулей системы были невелики. Примеры: размер ядра операционной системы реального времени OS-9 на микропроцессорах МС68xxx – 22 Kб, VxWorks – 16 Kб.
Возможность исполнения системы из ПЗУ (ROM). Это свойст-
во операционных систем
реального времени – одно из базовых. Оно
позволяет создавать компактные встроенные СРВ повышенной надежности, с ограниченным энергопотреблением, без внешних накопителей.
Важным параметром при оценке операционных систем реального
времени является набор инструментов, механизмов реального времени, предоставляемых системой.
Механизмы систем реального времени. Процесс проектирования конкретной системы реального времени начинается
с тщательного изучения объекта. Разработчики проекта исследуют объект, изучают возможные события на нем, определяют критические сроки реакции системы на каждое событие и разрабатывают алгоритмы обра-
88
ботки этих событий. Затем следует процесс проектирования и разработки программных приложений.
У разработчиков СРВ введено понятие «идеальная операцион-
ная система реального времени», в которой приложения реального
времени разрабатываются на языке событий объекта. Такая система
имеет свое название, хотя и существует только в теории. Называется
она: «система, управляемая критическими сроками
». Разработка
приложений реального времени в этой системе сводится к описанию
возможных событий на объекте. В каждом описателе события указывается два параметра:
1) временной интервал – критическое время обслуживания данно-
го события;
2) адрес подпрограммы его обработки.
Всю дальнейшую заботу о том, чтобы подпрограмма обработки
события стартовала до истечения критического интервала времени,
берет на себя операционная система.
Но это теоретически возможный предел. В реальности разработчик должен перевести язык событий объекта в сценарий многозадачной работы приложений операционных систем реального времени,
стараясь оптимально использовать предоставленные ему специальные механизмы и оценить времена реакций системы на внешние события при этом сценарии.
Рассмотрим механизмы
, используемые в операционных системах
реального времени, которые делают предсказуемой.
Система приоритетов и алгоритмы диспетчеризации. Базовыми инструментами разработки сценария работы системы являются
система приоритетов процессов (задач) и алгоритмы планирования
(диспетчеризации) операционных систем реального времени.
В многозадачных ОС общего назначения используются, как правило, различные модификации алгоритма круговой диспетчеризации,
основанные на
понятии непрерывного кванта времени («time slice»),
предоставляемого процессу для работы. Планировщик по истечении
каждого кванта времени просматривает очередь активных процессов
и принимает решение, кому передать управление, основываясь на
приоритетах процессов (численных значениях, им присвоенных).
Приоритеты могут быть фиксированными или меняться со временем.
Это зависит от алгоритмов планирования в данной ОС. Но рано
или
поздно процессорное время получат все процессы в системе.
Алгоритмы круговой диспетчеризации неприменимы в чистом
виде в операционных системах реального времени. Основной недос-
89
таток – непрерывный квант времени («time slice»), в течение которого процессором владеет только один процесс. Планировщики же
операционных систем реального времени имеют возможность сменить процесс до истечения кванта времени, если в этом возникла необходимость. Один из возможных алгоритмов планирования при
этом – алгоритм «приоритетный с вытеснением». Мир операционных
систем реального времени отличается
богатством различных алгоритмов планирования: динамические, приоритетные, монотонные,
адаптивные и пр., цель же всегда преследуется одна – предоставить
инструмент, позволяющий в нужный момент времени исполнять
именно тот процесс, который необходим.
Механизмы межзадачного взаимодействия. Другой набор ме-
ханизмов реального времени относится к средствам синхронизации
процессов и передачи данных между ними. Для операционных
систем реального времени характерна развитость этих механизмов. К
таким механизмам относятся: семафоры, мьютексы, события, сигналы, средства для работы с разделяемой памятью, каналы данных
(pipes), очереди сообщений. Многие из подобных механизмов используются и в ОС общего назначения, но их реализация в операционных системах реального времени имеет свои особенности.
В ОСРВ
время исполнения системных вызовов почти не зависит от состояния
системы, и в каждой ОСРВ есть по крайней мере один быстрый механизм передачи данных от процесса к процессу.
Средства для работы с таймерами. Такие инструменты, как
средства работы с таймерами, необходимы для систем с жестким
временным регламентом, поэтому развитость
средств работы с таймерами – необходимый атрибут операционных систем реального
времени. Эти средства позволяют:
– измерять и задавать различные промежутки времени (от 1 мкс и
выше);
– генерировать прерывания по истечении временных интервалов;
– создавать разовые и циклические будильники.
В лекции были рассмотрены только базовые, обязательные меха-
низмы, использующиеся в ОСРВ. Кроме того
, почти в каждой операционной системе реального времени присутствует целый набор дополнительных, специфических только для нее механизмов, касающихся системы ввода-вывода, управления прерываниями, работы с
памятью. Каждая система содержит также ряд средств, обеспечивающих ее надежность: встроенные механизмы контроля целостности кодов, инструменты для работы с таймерами.
90
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]