PersCom — Компьютерная Энциклопедия Компьютерная Энциклопедия

Косметика для девочек купить детская косметика для девочек. Подробности минеральная вата купить здесь.

Шина IEEE 1394 — FireWire

Шина IEEE 1394 — FireWire

Контексты асинхронной передачи

Контроллер асинхронной передачи работает с двумя контекстами:

  • контекст передачи асинхронных запросов, AT_Request, который используется для посылки пакетов запросов транзакций чтения, записи и блокированных, а также пакетов физического уровня;
  • контекст передачи асинхронных ответов, AT_Response, который используется для посылки пакетов ответов на запросы транзакций чтения, записи и блокированных, посланные другими узлами.

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

  • OUTPUT_MORE — не последняя команда в блоке, задающая адрес и длину буфера данных, которые следует поместить в собираемый пакет (рис. 1, а). Эта команда используется для помещения блока данных в середину пакета;
  • OUTPUT_MORE-Immediate — аналогичная команда, буфер (1 или 2 квадлета) находится в самом теле дескриптора (рис. 1, б). Эта команда используется для формирования заголовков пакетов 1394, за которыми еще следуют данные;
  • OUTPUT_LAST — последняя команда в блоке, задающая адрес и длину буфера данных, которые следует поместить в собираемый пакет, а также адрес перехода — адрес следующего блока дескрипторов в контекстной программе (рис. 1, в). Эта команда используется для помещения блока данных в конец пакета;
  • OUTPUT_LAST-Immediate — аналогичная команда, но буфер (1 или 2 квадлета) находится в самом теле дескриптора (рис. 1, г). Эта команда используется для формирования коротких пакетов фиксированной длины.

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

  • блок, состоящий из одной команды OUTPUT_LAST-Immediate (Z = 2);
  • блок, содержащий цепочку команд (Z = 4…9). Цепочка начинается с команды OUTPUT_MORE-Immediate, за которой следуют 0–5 промежуточных фрагментов OUTPUT_MORE и завершающая команда OUTPUT_LAST.

Отрабатывая команды OUTPUT_MORE-Immediate или OUTPUT_LAST-Immediate, контроллер подсчитывает и автоматически вставляет в пакет CRC-код заголовка. Отрабатывая команду OUTPUT_LAST, контроллер вставляет в пакет CRC, подсчитанный для всех фрагментов поля данных. По отработке команды контроллер помещает состояние выполнения (из регистра управления соответствующим контекстом) в дескриптор последней команды.

Назначение полей в дескрипторах команд асинхронной передачи приведено далее:

  • cmd — код команды;
  • key — ключ команды (можно рассматривать как расширение кода);
  • b (branch control) — управление переходом: 0 — нет указателя перехода, 1 и 2 — недопустимо, 3 — дескриптор содержит указатель перехода;
  • reqCount — длина буфера (в байтах);
  • dataAddress — адрес буфера данных (нет требования выравнивания);
  • timeStamp — метка времени, имеющая разное назначение:
         -----в пакете запросов (кроме ping) — время фактической отправки пакета (3 младших бита second_count и 13 бит cycle_count), устанавливаемое аппаратно при передаче;
         -----в пакетах ответов — время, позже которого пакет передавать не нужно (устанавливается программно);
         -----в пакетах ping-запросов — промежуток времени, измеренный от момента передачи последнего бита до начала приема ответа (в тактах частоты 49,152 МГц);
  • i (interupt control) — управление прерываниями: 0 — нет прерываний, 1 — прерывание только при неполучении квитанции ack_complete или ack_pending; 2 — недопустимо, 3 — прерывание по исполнении команды;
  • branchAddress — адрес перехода, указывающий на начало следующего блока дескрипторов;
  • Z — длина следующего блока дескрипторов (в 16-байтных блоках). Нулевая длина является указанием на останов контекстной программы;
  • xferStatus — состояние передачи, значения младших 16 бит регистра управления контекстом на момент завершения команды;
  • p (Ping Timing) — признак пакета ping.

Форматы данных, которые подготавливает программа хоста для посылки асинхронных пакетов, соответствуют форматам пакетов транзакций IEEE 1394, но с некоторыми особенностями:

  • заголовки и поля данных асинхронных пакетов формируются без CRC-кодов. Место под эти коды не резервируется, контроллер подсчитывает и добавляет эти коды в процессе передачи;
  • в заголовках асинхронных пакетов поля идентификаторов узлов источника и назначения поменяны местами (рис. 2, а). При этом вместо 16-битного идентификатора узла-источника подставляется поле, в котором указываются скорость передачи пакета (spd) и указание для подстановки номера шины (srcBusID: 0 — номер шины принимается 3FFh, 1 — берется из поля busNumber регистра Node_ID). Контроллер передаст пакет в формате шины 1394, подставив номер шины и физический идентификатор узла;
  • пакеты физического уровня формируются программой в соответствии с рис. 2, б. Здесь введен управляющий квадлет, определяющий скорость и тип транзакци (tcode = Eh). Первый и второй квадлеты пакета физического уровня полностью формируются программой (второй должен быть инверсией первого) и контроллером передаются без изменений, CRC не формируется. Длина передаваемого пакета будет всегда 2 квадлета, независимо от длины, указанной в дескрипторе команды. Такой особенный способ обработке дескриптора команды OUTPUT_LAST-Immediate контроллеру предписывает значение Eh кода типа транзакции.

 

Спецификации IEEE 1394

Стандарт для высокопроизводительной последовательной шины (High Performance Serial Bus), получивший официальное название IEEE 1394, был принят в 1995 году. Стандарт основан на шине FireWire, используемой фирмой Apple Computer еще с 1986 года в качестве дешевой альтернативы SCSI в своих компьютерах. Название FireWire («огненный провод») теперь применяется и к реализациям IEEE 1394, оно сосуществует с кратким обозначением: «1394». Другое название того же интерфейса — iLink, а иногда и Digital Link — используется фирмой Sony применительно к устройствам бытовой электроники. MultiMedia Connection — имя, используемое в логотипе 1394 High Performance Serial Bus Trade Association (1394TA).

К устройствам с интерфейсом IEEE 1394 относится большое количество спецификаций, описывающих не только собственно интерфейс последовательной шины, но и использование этой шины для транспортировки прикладных данных разного назначения, наборы команд и форматы данных. Основной источник информации по технологии, стандартам и продуктам — сайт ассоциации High Performance Serial Bus Trade Association (http://www.1394ta.org). Спецификация IEEE 1394 официально доступна через http://www.ieee.org (платно).

Документ IEEE 1394-1995 Standard for a High Performance Serial Bus определяет архитектуру шины, основанную на трехуровневой модели, и протоколы, обеспечивающие автоматическое конфигурирование, арбитраж и передачу изохронного и асинхронного трафика. В стандарте определены три возможные скорости передачи сигналов по кабелям: 98,304, 196,608 и 393,216 Мбит/с, которые округляют до 100, 200 и 400 Мбит/с и обозначаются как S100, S200 и S400 соответственно. Стандартизованы кабель и 6-контактный разъем, позволяющий передавать сигналы и питание.

В дополнении IEEE 1394a-2000 IEEE Standard for a High Performance Serial bus (Supplement) введен ряд усовершенствований:

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

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

Дополнения IEEE 1394b (2002 год) в основном касаются повышения скорости и дальности передачи:

  • введены скорости S800, S1600 и архитектурная поддержка S3200;
  • введен новый (для 1394) метод сигнализации и соответствующий бета-режим работы портов. Для передачи используется пара встречных однонаправленных линий и кодирование 8B/10B, широко используемое в современных коммуникационных технологиях;
  • введен новый метод арбитража (BOSS), повышающий эффективность использования пропускной способности шины за счет исключения простоев шины (зазоров арбитража);
  • введены новые типы среды передачи для бета-режима:
  1. пара пластиковых или стеклянных оптических волокон для расстояний до 50 или до 100 м;
  2. кабель UTP-5 (используются 2 пары) с разъемами RJ-45 для расстояний до 100 м с трансформаторной гальванической развязкой.
  • Введен миниатюрный 9-контактный разъем для коротких дистанций, позволяющий передавать данные со скоростью до 3,2 Гбит/с и подавать питание по шине.

Совместимость с 1394 и 1394a обеспечивается «двуязычными» уровнями PHY, способными работать с разными методами сигнализации на своих разных портах. При этом возможно построение гибридной шины, состоящей из одного или нескольких «облаков» узлов с бета-сигнализацией, связанных друг с другом фрагментами с традиционной сигнализацией.

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

В основу IEEE 1394 положен протокол запросов-ответов архитектуры регистров управления и состояния для микрокомпьютерных шин, описанной в стандарте ISO/IEC 13213:1994 Control and Status Register Architecture for Microcomputer Busses (CSR-архитектура). Ревизия этого стандарта предполагается в проекте P1212r.

Ревизия касается возможностей бесконфликтного расширения форматов содержимого памяти конфигурации, а также регистров CSR. Планируется привести спецификацию CSR в соответствие с практикой ее использования.

К управлению энергопотреблением IEEE 1394 относится спецификация 1394 TA Power Spec, состоящая из трех частей:

  • Part 1: Cable Power Distribution — описание механизма подачи питания через кабельную шину, форматы структур данных и регистров, описывающих потребности в питании и возможности поставки питания на шину;
  • Part 2: Suspend/Resume — описание механизмов приостановки и возобновления работы отдельных портов и частей кабельной шины;
  • Part 3: Power State Management — описание четырех возможных уровней потребления узла и его блоков и механизмов управления сменой уровней.

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

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

  • запрос (request), используемый запросчиком транзакции для инициирования субакции запроса. В запросе передается:
  1. код типа транзакции (Read, Write, Lock с указанием операции);
  2. адрес получателя;
  3. длина данных;
  4. данные (для Write и Lock);
  5. скорость передачи.

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

  • Индикация (indication), уведомляющая ответчика о приходе запроса. Драйверу ответчика передается:
  1. код типа транзакции (Read, Write, Lock с указанием операции);
  2. адрес узла$запросчика (получателя для данной субакции);
  3. длина данных;
  4. данные (для Write и Lock);
  5. метка транзакции;
  6. код повтора;
  7. скорость передачи.
  • Ответ (response), используемый ответчиком для получения состояния или данных запроса, запускающий субакцию ответа. В ответе передается:
  1. код типа транзакции;
  2. адрес запросчика (получателя);
  3. длина данных;
  4. данные (для Read и Lock);
  5. код ответа;
  6. метка транзакции;
  7. скорость передачи.
  • Подтверждение (confirmation), уведомляющее запросчика о завершении транзакции. В нем прикладному драйверу передается;
  1. состояние запроса: завершение (успешное), тайм$аут (отсутствие своевременного ответа), отсутствие квитанции о приеме запроса, исчерпание предела повторов, ошибка принятых данных;
  2. код ответа (завершение или ошибка данных);
  3. данные и их длина (для Read и Lock).

Информационный блок последовательной шины и корневой каталог

Информационный блок последовательной шины

Информационный блок последовательной шины (bus_info_block) занимает 4 квадлета (см. рисунок ниже). Назначение его полей:

  • bus_name — имя шины («1394» в ASCII)
  • irmc — признак способности к роли диспетчера изохронных ресурсов;
  • cmc — признак способности к роли мастера циклов;
  • isc — признак способности к изохронным передачам;
  • bmc — признак способности к роли диспетчера шины;
  • pmc — признак способности к управлению питанием (введено в 1394a);
  • cyc_clk_acc — точность генерации интервалов циклов (в миллионных долях, ppm, допустимо 0–100), только для узлов с cmc = 1;
  • max_rec — указатель максимального размера поля данных, равного 2max_rec + 1. Допустимо max_rec = 1…13 (длина пакета 4, 8, 16… 16 384 байт);
  • node_vendor_id — идентификатор производителя (то же, что и vendor_id в минимальном формате);
  • chip_id_hi, chip_id_lo — две составные части 40-битного идентификатора микросхемы LINK-уровня, который в совокупности с node_vendor_id дает глобально уникальный идентификатор узла;
  • gen — номер генерации содержимого памяти, инкрементируется с каждой его модификацией (введено в 1394a). Позволяет конфигурационному ПО сократить объем запрашиваемой информации, если считанное значение номера после сброса совпадает с предыдущим;
  • link_speed — максимальная скорость, поддерживаемая LINK-уровнем; может не совпадать со скоростью PHY, сообщаемой в пакете самоидентификации (введено в 1394a).

 

Корневой каталог

Корневой каталог содержит элементы, состоящие из двух полей:

  • key (8 бит) — ключ элемента, в котором можно выделить:
         -----key_type (2 бита) — тип ключа: 0 — непосредственный параметр, 1 — смещение (в начальном пространстве регистров), по которому находится параметр; 2 —смещение (в памяти конфигурации), по которому находится структура данных (лист); 3 — смещение, по которому находится каталог;
         -----key_value (6 бит) — значение ключа, по которому определяется назначение элемента.
  • value или offset (24 бита) — значение элемента или смещение ячейки памяти, с которой начинается данный элемент. Смещение указывается в квадлетах относительно положения данного элемента каталога.

Элементы корневого каталога приведены в таблице. Для всех узлов шины обязательны первые три элемента из приведенных в таблице. Структура элемента, содержащего уникальный 64-битный идентификатор узла, приведена на рисунке. Этот идентификатор, называемый EUI-64 (Extended Unique Identifier), состоит из идентификаторов производителя узла и идентификатора микросхемы LINKуровня. Он может использоваться для идентификации программного драйвера данного узла. В CSR определен еще и 88-битный глобальный идентификатор GUI (Globally Unique Identifier), в котором к EUI-64 в качестве старших 24 бит добавлен идентификатор Company_Id. Идентификатор GUI уникально определяет узел во всем мире всех шин, отвечающих CSR-архитектуре.

Таблица. Элементы корневого каталога

Ключ Смещение или значение
03h Module_Vendor_Id, значение идентификатора производителя модуля (может совпадать с идентификатором производителя узла)
0Ch Node_Capabilities, значение свойств узла (см. рисунок после этой таблицы):
spt — признак наличия регистра SPLIT_TIMEOUT, должен быть единичным у узла, способного участвовать в транзакциях
ms — признак наличия регистров Messaging Passing
int — признак наличия регистров Interrupt_Traget и Interrupt_Mask
ext — признак наличия регистра TEST_ARGUMENT
bas — признак наличия регистров TEST_START и TEST_STATUS
prv — признак наличия приватного пространства узла
64 — признак поддержки
64-битной адресации (в IEEE 1394 всегда установлен)
fix — признак фиксированной (а не расширенной) адресации (в IEEE 1394 всегда установлен)
lst — признак наличия бита Lost в регистрах State_Clear и State_Set
drq — признак наличия бита Dreq в регистрах State_Clear и State_Set
elog — признак наличия регистра Error_Log и бита Elog в регистрах State_Clear и State_Set
atn, off — признак наличия одноименных битов в регистрах State_Clear и State_Set
ded — узел поддерживает состояние Dead
init — узел поддерживает состояние Initializing
8Dh Node_Unique_Id_offset — смещение элементалиста с уникальным идентификатором узла. Смещение (в квадлетах) задается относительно положения данного ключа в памяти конфигурации. Формат элемента приведен на рисунок выше
82h Bus_Dependent_Info_Offset — смещение элемента информации, относящейся к шине
C2h Bus_Dependent_Info_Offset — смещение каталога информации, относящейся к шине
04h Module_Hw_Version, значение версии аппаратных средств модуля
05h Module_Spec_Id, значение идентификатора спецификации модуля
07h Module_Sw_Version, значение версии программных средств модуля
87h Module_Dependent_Info_Offset — смещение элемента информации, относящейся к модулю
C7h Module_Dependent_Info_Offset — смещение каталога информации, относящейся к модулю
08h Node_Vendor_Id, идентификатор производителя узла
09h Node_Hw_Version, значение версии аппаратных средств узла
0Ah Node_Spec_Id, значение идентификатора спецификации узла
0Bh Node_Sw_Version, значение версии программных средств узла
90h Node_Dependent_Info_Offset — смещение элемента информации, относящейся к узлу
D0h Node_Dependent_Info_Offset — смещение каталога информации, относящейся к узлу
D1h Unit_Directory_Offset — смещение каталога информации, относящейся к блоку
F0h Node_Power_Directory_Offset — относительное смещение каталога управления потреблением, относящегося к узлу (введено в 1394a)

 

Уровни потребления узла и блоков

В IEEE 1394a введены понятия уровней потребления (Power States), относящиеся к узлу в целом и отдельным его блокам. Узел и блок могут поддерживать до четырех уровней (0…3), из которых нулевой (обязательный) соответствует функционированию в самом полном объеме.

Уровни потребления узла (Node Power States) N0…N3 определяют состояния уровней PHY и LINK:

  • N0 — состояние полной дееспособности узла: PHY-уровень запитан (может принимать, посылать и транслировать пакеты и сигналы), LINK-уровень способен отвечать на транзакции, обращенные к узлу. Контекст узла (все его конфигурационные регистры CSR и PHY) действителен. При этом возможны два варианта:
         -----LINK-уровень полностью запитан — полная функциональность узла (нормальные ответы на все транзакции);
         -----LINK-уровень находится в состоянии Standby (с пониженным потреблением). Узел способен декодировать адрес обращенных к нему транзакций и ответить на них квитанцией Ack_TRDY, что вызовет повтор транзакции инициатором в следующем интервале справедливости. За это время LINKуровень узла успеет включиться, и на следующую попытку узел ответит нормальным образом;
  • N1 — состояние со включенным PHY (узел транслирует сигналы и пакеты) и отключенным LINK-уровнем. Это соответствует состоянию узла после сброса до получения пакета Link-On. Состояние контекста узла стандартом не регламентировано;
  • N2 — состояние с приостановленным (suspended) PHY и отключенным LINKуровнем. Узел не транслирует пакеты и сигналы, он может только реагировать на внешние сигналы, вызывающие возобновление (или на сигнал от своего приложения). Контекст не определен; информация, связанная с топологией, недействительна (после возобновления будет сброс);
  • N3 — полностью обесточенный узел, контекст потерян.

Уровни потребления блока (Unit Power States) D0…D3 отражают функциональность и потребление блока:

  • D0 — состояние полной функциональности и полного потребления, обязательное для всех блоков;
  • D1 — состояние пониженного потребления, контекст блока сохраняется, но функциональность может быть ограничена. Переход D1→D0 может совершаться довольно быстро;
  • D2 — состояние еще меньшего потребления, с меньшей функциональностью и, возможно, потерей контекста блока. Переход в D0 (или D1) может занимать большее время, чем D1→D0;
  • D3 — полное обесточивание блока.

Возможные состояния уровней потребления узла и входящих в него блоков связаны между собой: номер уровня потребления узла должен быть не больше, чем наименьший номер уровня потребления его блоков. Например, если в узле два блока и их текущие уровни потребления D1 и D2, то узел может находиться на уровне N0 или N1. Попытка (запрос) перевода уровня узла с N0 на N2 или N3 приведет к переводу только на уровень N1.

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