Шины.PCI,.USB.и.FireWire

Таблица 18.5 (продолжение)

Обработка ошибок и механизм повторов

Успешному выполнению асинхронных транзакций может помешать ряд причин:

занятость целевого узла (заполнение его входных и выходных очередей);

заблокированность целевого узла (он находится в процессе выполнения бло$ кированной транзакции от другого узла);

ошибки при передаче пакетов.

Уровень транзакций предоставляет драйверам надежные сервисы, уведомляющие драйвер об успехе или неуспехе транзакции. Однако средства IEEE 1394 (уровень транзакций) обеспечивают автоматические повторы только для случая занятости целевого узла.

Протоколы повторов при занятости

Для организации повторов из$за занятости используется один из двух протоко$ лов, который выбирает целевое (занятое) устройство: однофазный или двухфаз$ ный. Первая попытка посылки пакета (запроса или ответа) выполняется всегда одинаково: в заголовке пакета поле rt = 00. Если на этот пакет приходит квитан$ ция с одним из кодов, означающим занятость — 4 (ack_busy_x), 5 (ack_busy_A) или 6 (ack_busy_B), то узел организует последующие попытки передачи этого па$ кета, устанавливая в поле rt значение: 01 (Retry_x), 10 (Retry_A) или 11 (Retry_B) соответственно. Попытки повторов выполняются с обычным (справедливым) ар$ битражем, «предел терпения» определяется в зависимости от используемого про$ токола повторов.

Протокол однофазных повторов (Single Phase Retry) использует только код кви$ тирования 4 (ack_busy_x), в ответ на который повторные попытки передачи дела$ ются с кодом rt = 01 (Retry_x). Максимальное число повторов одного пакета ог$ раничено 4$битным полем retry_limit регистра BUSY_TIMEOUT (смещение 210h в пространстве регистров CSR, рис. 18.7). По достижении этого лимита повторные попытки прекращаются, и уровень транзакций сообщает драйверу о невозможно$ сти посылки данного пакета из$за занятости адресуемого узла.

Рис. 18.7. Формат регистра BUSY_TIMEOUT

Протокол двухфазных повторов (Dual Phase Retry) позволяет несколько упорядо$ чить обслуживание занятым (перегруженным) узлом пакетов разных транзакций. Для этого вводится чередование двух фаз — фазы A и фазы B. Если занятый узел получает пакет первой попытки (rt = 00), он на него отвечает кодом квитирова$ ния 5 (ack_busy_A) и ожидает его повторного прихода с кодом rt = 10 (Retry_A). Теперь этот узел находится в фазе A и будет пытаться обслуживать только пакеты с rt = 10. На все первые попытки других транзакций узел будет отвечать кодом квитирования 6 (ack_busy_B), что заставит узлы, их посылающие, делать попытки повторов с rt = 11 (Retry_B), в данной фазе не обслуживаемые. Только после того, как наш узел сумеет обслужить пакет с rt = 10 и в течение четырех подряд интер$ валов справедливости не будет получать другие пакеты с rt = 10 (Retry_A), он перейдет в фазу B и начнет обслуживать пакеты с rt = 11 (Retry_B). При этом на новые первичные пакеты он будет отвечать кодом квитирования 5 (ack_busy_A). После обслуживания пакетов фазы B узел снова перейдет в фазу A — получается подобие игры в пинг$понг. Предел «терпения» узла, посылающего повторные па$ кеты по двухфазному протоколу, определяется уже по времени: ограничивается время, отсчитываемое от момента первой попытки передачи. Это время не должно превышать значение, заданное полями seconds_limit и cycle_limit в том же регистре BUSY_TIMEOUT. 13$битный счетчик, соответствующий полю cycle_limit, считает по модулю 8000 (полный оборот за 1 секунду).

Обработка ошибок передачи

Для обеспечения надежных транзакций достоверность передачи заголовков и по$ лей данных пакетов контролируются CRC$кодами. Пакеты запросов и ответов, принятые с обнаруженной ошибкой в заголовке, игнорируются (достоверной ин$ формации об их источнике и адресате назначения нет). Об остальных ошибках узел, которому адресован пакет запроса или ответа, сообщает его источнику указа$ нием соответствующего кода в пакете квитирования (табл. 18.5). Пакеты$квитан$ ции контролируются проще (по двоичному дополнению кода ответа), неверные квитанции игнорируются. Обработкой ошибок занимается прикладной драйвер, которому уровень транзакций сообщает результат выполнения. Канальный уро$

вень принятые пакеты только проверяет на корректность формата и CRC; он пере$ дает уровню транзакций все пакеты, адресованные данному узлу, но с соответству$ ющими признаками корректности или ошибки.

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

Пакет запроса пришел к адресованному узлу с ошибкой CRC данных:

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

действия узла запросчика: канальный уровень принимает эту квитанцию и пе$ редает ее код уровню транзакций, который информирует прикладной драйвер о неудаче. Какая на это последует реакция — зависит от приложения, которое знает, что до ответчика запрос не дошел.

Пакет запроса пришел нормально, но пакет квитирования «потерялся» (каналь$ ный уровень запросчика не дождался корректной квитанции):

действия узла запросчика: канальный уровень посылает об этом уведомление своему уровню транзакций, который сообщит прикладному драйверу об отсут$ ствии квитанции. Реакция опять же зависит от приложения, но состояние от$ ветчика (пришел к нему запрос или нет) ему неизвестно.

Пакет ответа пришел к запросчику с ошибкой CRC данных:

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

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

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

Пакет ответа пришел нормально, но пакет квитированиия «потерялся». Об этом уведомляется драйвер ответчика, который обрабатывает эту ситуацию в зависи$ мости от приложения. Дошел ли при этом ответ до запросчика — неизвестно.

Взаимодействие драйвера с уровнем транзакций

Уровень транзакций взаимодействует с прикладным драйвером четырьмя прими$ тивами сервисов:

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

код типа транзакции (Read, Write, Lock с указанием операции);

адрес получателя;

длина данных;

данные (для Write и Lock);

скорость передачи.

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

Индикация (indication), уведомляющая ответчика о приходе запроса. Драйверу ответчика передается:

код типа транзакции (Read, Write, Lock с указанием операции);

адрес узла$запросчика (получателя для данной субакции);

длина данных;

данные (для Write и Lock);

метка транзакции;

код повтора;

скорость передачи.

Ответ (response), используемый ответчиком для получения состояния или данных запроса, запускающий субакцию ответа. В ответе передается:

код типа транзакции;

адрес запросчика (получателя);

длина данных;

данные (для Read и Lock);

код ответа;

метка транзакции;

скорость передачи.

Подтверждение (confirmation), уведомляющее запросчика о завершении тран$ закции. В нем прикладному драйверу передается:

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

код ответа (завершение или ошибка данных);

данные и их длина (для Read и Lock).

Организация потоковых передач и изохронный обмен

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

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

асинхронные потоковые передачи выполняются в оставшееся время цикла. Для них у диспетчера изохронных ресурсов запрашивается только номер канала. По$ лоса пропускания асинхронного потокового канала не нормируется.

Пакеты изохронных передач передаются широковещательно и физически адресу$ ются по номеру канала (0–63), указанному в заголовке пакетов.

Получение номера канала и выделение полосы пропускания осуществляется об$ ращениями узла к регистрам диспетчера изохронных ресурсов CHANNEL_AVAILABLE и BANDWIDTH_AVAILABLE (см. главу 21). Если канал и полосу получить не удалось, узел может периодически повторять запросы. Когда изохронный обмен становит$ ся ненужным узлу, он должен освободить свою полосу и номер канала, чтобы эти$ ми ресурсами смогли воспользоваться другие устройства. Обмен управляющей информацией с диспетчером производится асинхронными транзакциями.

Для выполнения изохронных обменов прикладной драйвер пользуется сервисами LINK уровня:

Запрос изохронной передачи (Link Isochronous Request), в котором драйвер пе$ редает:

номер канала;

длину данных;

данные;

скорость;

тег, определяющий формат данных;

код синхронизации (специфичен для приложений).

Индикация изохронной передачи (Link Isochronous Indication), в которой драй$ вер получает те же данные. LINK$уровень будет давать индикацию только при приеме пакетов с требуемыми номерами каналов;

Мастер циклов регулярно (с периодом 125 мкс) передает пакеты начала цикла (рис. 18.8, б). В каждом таком пакете мастер циклов передает значение 32$битного счетчика времени (CYCLE_TIME), инкрементируемого с частотой 24,576 МГц. Мет$ ки времени нужны каждому узлу, поддерживающему изохронный обмен. Если к моменту подачи очередного пакета начала цикла шина оказывается занятой пе$ редачей, то пакет начала цикла задерживается до момента освобождения шины. В поле данных cycle_time_data передается значение регистра CYCLE_TIME мас$ тера циклов на момент его фактической передачи, так что точная синхронизация узлов обеспечивается и при опозданиях пакета. Пакет передается во время асинх$ ронной части цикла, но с коротким зазором арбитража, что обеспечивает приори$ тетность данных пакетов. Пакет передается широковещательно (destination_ID = = 3Fh), его принимают все узлы, интересующиеся изохронными передачами. В поле destination_offset указывается адрес регистра CYCLE_TIME (смещение 200h в пространстве регистров CSR). Поле tl не используется (ответов не предусматри$ вается), rt = = 00 (без квитирования). Поле source_ID содержит номер шины и идентификатор корневого узла, который и должен быть мастером циклов.

Организация изохронных соединений

Для установления логических связей между источниками и приемниками изо$ хронных потоков служат регистры управления входными и выходными штекера ми — PCR (Plug Control Register), описанные ниже. Штекер (Plug) в 1394 — это метафора разъема, по которому передавался бы аудио$ или видеосигнал в аналого$ вой системе. В 1394 штекеры, которыми соединяются между собой источники и приемники изохронных данных, отображаются регистрами PCR. Эти регистры используются для организации двухточечных и широковещательных соединений.

Для изохронных передач могут быть установлены соединения одного из трех основ$ ных типов:

точка$точка (point$to$point) — соединение, явно видимое в PCR$регистрах уча$ стников: один из регистров OUTPUT_PLUG передающего узла и один из регистров INPUT_PLUG принимающего узла содержат одинаковый номер канала channel и у обоих ненулевые значения поля point_to_point;

широковещательная передача (broadcast out), ведущаяся без каких$либо при$ знаков «слушателей». В регистре OUTPUT_PLUG передающего узла устанавлива$ ется бит b — признак широковещания и указывается номер канала channel;

широковещательный прием (broadcast in), ведущийся без индикации присут$ ствия передатчика. В регистре INPUT_PLUG передающего узла устанавливается бит b — признак широковещания и указывается номер канала channel.

Для каждого штекера может быть установлено несколько соединений точка$точка (или ни одного); широковещательное соединение может быть только одно (или ни одного). Эти типы соединений могут независимо сосуществовать на одном штеке$ ре. Установление нового двухточечного соединения увеличивает значение поля point_to_point, разрыв соединения — уменьшает (в пределе до нуля).

Номер канала при установлении широковещательной передачи для штекера, не имеющего двухточечного соединения, определяется номером штекера и базовым адресом для данного узла (полем broadcast_base регистра OUTPUT_MASTER_PLUG). Если broadcast_base ≠ 63, то номер канала будет суммой (по модулю 64) базово$ го адреса и номера штекера, иначе устанавливается номер канала 63.

Приемник и передатчик изохронных данных могут соединяться двояко, различия касаются прав на разрыв соединения:

двухточечным соединением, установленным в каждом из них. Это соединение может разорвать только тот, кто его устанавливал;

установлением широковещательной передачи в одном узле и широковещатель$ ного приема в другом. Это соединение может разорвать любой из участников.

Регистры управления штекерами (PCR)

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

общий регистр выходных штекеров OUTPUT_MASTER_PLUG (0900h, рис. 18.9, а) определяет общие характеристики узла как изохронного передатчика. Поле output_plugs определяет количество выходных штекеров (0–31). Поле spd задает максимальную скорость передачи по любому из штекеров (0 — S100, 1 — S200, 2 — S400, 3 — S800). Поле broadcast_base задает базовый номер широ$ ковещательного канала (см. главу 26). Поля persistent_ext, nonpersistent_ext

иr зарезервированы. Этот регистр должен быть у узлов, поддерживающик как изохронную передачу, так и прием;

регистры выходных штекеров OUTPUT_PLUG (0904–097Ch, рис. 18.9, б) присут$ ствуют только у узлов, способных вести изохронную передачу. Присутствующие регистры (их число определяется регистра OUTPUT_MASTER_PLUG) располагаются по смежным адресам. Каждый из этих регистров описывает широковещатель$ ную или двухточечную передачу потока, исходящего от узла через соответству$ ющий штекер. Бит o (online) указывает на возможность конфигурирования

ииспользования данного штекера для передачи (o=0 — передача невозможна). Поле channel определяет номер канала, фигурирующий в качестве адреса ис$ ходящих изохронных пакетов. Бит b (broadcast) указывает на наличие широко$ вещательного соединения для данного штекера. Поле point_to_point опреде$ ляет число двухточечных соединений, установленных для данного штекера. Поле spd задает скорость передачи пакетов (0 — S100, 1 — S200, 2 — S400, 3 — S800). Поле payload задает максимальный размер поля данных изохронного пакета в квадлетах (0 соответствует 1024 квадлетам). Поле overhead позволяет более точно вычислить запрашиваемое значение полосы пропускания bw, за$

Арбитраж и распределение времени шины IEEE 1394

Арбитраж определяет, какому из узлов, запрашивающих передачу, предоставля$ ется это право. Арбитраж обеспечивает гарантированную пропускную способность для изохронных передач и справедливое предоставление доступа узлам для асин$ хронных транзакций. Арбитраж на шине IEEE 1394 выполняется перед посылкой любого пакета запроса (синхронного или изохронного) или ответа. Исключением является соединенная (concatenated) форма выполнения транзакций (см. главу 18). Пакеты квитирования посылаются без арбитража — право на их передачу разыг$ рывать не надо, поскольку квитанцию посылает только тот единственный узел, к которому адресовался подтверждаемый пакет запроса или ответа.

Арбитражем занимается физический уровень каждого узла шины. Арбитраж вы$ полняется распределенно иерархически: им занимаются все узлы, «верховным» арбитром является корневой узел (root node), автоматически выбираемый на эта$ пе конфигурирования шины.

Физический уровень (PHY) предоставляет канальному уровню (LINK) следую$ щие сервисы арбитража, перечисленные в порядке нарастания приоритетности:

справедливый арбитраж (fair arbitration service), используемый для передачи обычных асинхронных пакетов;

приоритетный арбитраж (priority arbitration service), используемый для пере$ дачи пакетов начала цикла и приоритетных асинхронных пакетов;

немедленный арбитраж (immediate arbitration service), используемый для пе$ редачи пакетов квитирования;

изохронный арбитраж (isochronous arbitration service), используемый для пе$ редачи изохронных пакетов.

Приоритет в арбитраже на шине IEEE 1394 определяется длительностью зазора арбитража (arbitration gap) — временем, в течение которого узел наблюдает по$ кой шины перед началом передачи запроса арбитража. Чем меньше этот зазор, тем больше шансов у узла получить право на передачу. Исходная схема арбитража 1394 усовершенствовалась дважды: в 1394a были введены механизмы ускоренного ар$ битража, а в 1394b с его дуплексными соединениями был введен новый механизм —