Индикация событий управления шиной

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Управление шиной IEEE 1394

Локальное приложение узла получает следующие сообщения об особых событиях, происходящих на шине и в данном узле:

• нарушение соглашений о времени занятия шины (регистр MAX_BUS_OCCUPANCY, переименованный в MAX_DATA_TIME в IEEE 1394a);
• начало сброса шины;
• завершение сброса шины (выполнен сброс, идентификация дерева и самоидентификация всех узлов). При этом сообщается ряд параметров и признаков:
       -----идентификаторы данного узла, корня, мастера циклов, диспетчеров шины и изохронных ресурсов;
       -----ошибки тайм-аута конфигурирования, топологии, самоидентификации, определения зазора, перегрузки питания;
       -----значение зазора арбитража;
       -----значение остатка полосы (bandwidth set-aside);
• слишком длинный цикл (только для диспетчеров);
• понижение питания в кабеле (ниже 7,5 В);
• обнаружение дублирования номеров изохронных каналов;
• обнаружение ошибки CRC-кода заголовка;
• обнаружение ошибки CRC-кода данных;
• отсутствие квитанции на переданный пакет ответа;
• получение квитанции с указанием на ошибку данных в пакете ответа;
• ошибка формата ответа (получен пакет квитирования с указанием неверного типа ответа);
• ошибка повтора ответа (исчерпан предел повторов или ожидания);
• обнаружен неожиданный канал (диспетчер изохронных ресурсов услышал пакет не выделенного им канала);
• обнаружен неизвестный код транзакции (не поддерживаемой данным узлом);
• обнаружен приход ответа, не ожидаемого данным узлом (проверяется по метке транзакции).

Механизм арбитража

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Физический уровень шины IEEE 1394

В фазе нормальной работы шины (после самоидентификации) механизм арбитража работает следующим образом:

• узел, который собирается отправить пакет, дожидается покоя шины (Bus Idle, [Z Z]), длящегося в течение определенного интервала (соответствующего приоритетности данного пакета), и посылает через свой p-порт сигнал запроса передачи TX_REQUEST;
• промежуточные узлы-ветки доводят этот запрос до корня, если этому не помешает запрос от другого узла, появившийся раньше;
• корневой узел принимает запрос и отвечает на него сигналом TX_GRANT;
• сигнал TX_GRANT доводится до источника запроса;
• источник запроса посылает во все свои порты сигнал префикса данных, после которого начинается передача пакета;
• все промежуточные узлы, получившие префикс данных, начинают транслировать его (а затем и собственно данные) во все свои порты.

Сигналы арбитража распространяются промежуточными узлами шины. Запрос передается «вверх» сигналом TX_REQUEST (через p-порт); он достигает c-порта соседнего узла сигналом RX_REQUEST («переворачиваясь» в кабеле). Сигнал запроса, обнаруженный на c-порте, узел обязан транслировать к корню, если к этому моменту он уже не транслирует запрос от другого порта или же не запрашивает передачу сам. Таким образом, запрос арбитража от какого-либо узла достигает корня.

Корневой узел посылает сигнал предоставления (TX_GRANT) на тот свой порт, запрос с которого обнаружен первым (или порту с меньшим номером, если запросы обнаружены одновременно). На остальные порты посылается сигнал префикса данных (DATA_PREFIX), который указывает на занятость шины.

Промежуточный узел-ветка, получивший «сверху» предоставление (сигнал RX_GRANT), транслирует его «вниз» (сигналом TX_GRANT) на тот порт, чей запрос был им принят; на остальные порты посылается сигнал префикса данных (DATA_PREFIX). Если узел сам является источником запроса, он на все свои c-порты передает сигнал префикса данных. Таким образом, сигнал предоставления достигает узла-источника запроса, награждая его правом передачи пакета. Узел, который во время передачи сигнала TX_REQUEST получает сверху префикс данных, должен прекратить подачу запроса и транслировать вниз префикс данных. Если этот узел сам является источником запроса, он «понимает», что в данном случае арбитраж им проигран и попытку получения доступа придется повторить позже.

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

Последовательный интерфейс PIL-FOP

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Взаимодействие с физическим уровнем шины IEEE 1394

Последовательный интерфейс подключает к однопортовому узлу с интегрированным портом, называемому PIL (Port Integrated Link), физический разветвитель FOP (Fan-Out PHY). Схема подключения с использованием этого интерфейса приведена на паервом рисунке. Узел PIL содержит один бета-порт, соединяемый с разветвителем FOP двумя дифференциальными однонаправленными сигнальными парами. В этих сигнальных парах может присутствовать и гальваническая развязка (конденсаторная или трансформаторная). Дополнительно от FOP должен передаваться сигнал LinkON, управляющий включением LINK-уровня по приему соответствующего пакета. Узел PIL и разветвитель FOP могут находиться в разных доменах питания. Внешние порты разветвителя FOP могут быть как бета-портами, так и универсальными, поддерживающими DS-сигнализацию.

Логически уровень PHY комбинации PIL-FOP выглядит как один многопортовый PHY, число его портов равно числу портов разветвителя с учетом дополнительного порта, обращенного к PIL. Этому порту назначается самый большой номер; он никогда не представляется как активный порт и его нельзя перевести в режим Standby. В пакетах самоидентификации этот порт отмечается как отсутствующий, удаленное обращение к его регистрам дает тот же результат, как обращение к отсутствующему порту.

PHY, предназначенный для роли FOP, может и не подключаться к PIL, а играть роль автономного повторителя-разветвителя (с отсутствующим LINK’ом). При этом порт, предназначенный для подключения PIL, может работать в традиционном, бета- или «двуязычном» режиме.

PIL и FOP обнаруживают присутствие (включение) друг друга, согласуют скорости и устанавливают синхронизацию так же, как и пара обычных бета-портов. В посылках согласования скоростей FOP будет передавать бит FOP_Capable, а порт интегрированного узла — бит PIL_Capable. Протокол согласования позволяет установить им друг с другом правильные взаимоотношения.

Для того чтобы порты FOP и PIL логически связались в единый набор портов многопортового узла, в интерфейсе PIL-FOP определен специальный двухточечный протокол обмена со своими специальными P2P-пакетами (point-to-point). Пакеты P2P передаются только по интерфейсу между PIL и FOP, на общую шину они не выходят. Пакеты P2P передаются между пакетами основного трафика шины. Если во время передачи пакета P2P требуется передача основного трафика, то пакеты P2P прерываются, а пакеты основного трафика передаются беспрепятственно. Формат пакетов P2P приведен на рисунке ниже, назначение полей приведено ниже:

• PP1 и PP2 — байты-префиксы пакетов (00011xx1 и 00111xx1 соответственно);
• D1 — байт, определяющий операцию:
   -0000xxxx — нет операции;
   -0001aaaa — запись в регистр FOP, aaaa — адрес, D2 содержит данные;
   -0010aaaa — чтение регистра aaaa;
   -0011aaaa — неожидаемое (для PIL) чтение регистра aaaa, D2 содержит считанные данные;
   -0100aaaa — ожидаемые (для PIL) результаты чтение регистра aaaa, D2 содержит считанные данные;
   -0101iiii — уведомление о прерывании от FOP, iiii — код прерывания (0001 — прерывание от физического уровня, остальные коды пока не определены);
   -0110xxxx — Cycle Start Due, если в FOP установлен бит enab_accel, PIL посылает это уведомление после начала каждого изохронного периода (по своим часам);
   -0111xxxx — Restore_Notify, уведомление восстановления, посылает FOP, начинающий восстановление как «племянник»;
   -10000000 — 11111111 — резерв;
• D2 — данные записи или чтения (присутствуют не во всех пакетах);
• DE1, DE2 — маркеры конца данных DATA_END.

Каждый байт пакета на рисунке представлен в виде одного символа, который после кодирования 8B/10B представляется десятью битами сигнала на шине. Пакеты P2P могут быть прерваны в любом месте управляющими символами префикса данных или кода скорости, что означает начало пакета основного трафика, передаваемого по шине. Если пакет прерывается до DE1, то он повторяется передатчиком и игнорируется приемником. Пакет, прерванный после DE1, используется по назначению, поскольку все его содержательные поля и разделитель уже переданы.

Контексты DMA

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: «Открытый» хост-контроллер IEEE 1394 — OHCI

Контекст DMA, образующий независимый канал DMA, состоит из контекстной программы и регистров контроллера. Контекстная программа — это список команд, отрабатываемых контроллером для передачи и приема пакетов данных. Каждый контекст DMA представлен в контроллере своим блоком регистров, в который входят регистры ContextControl (управление и состояние) и CommandPtr (указатель на команду). В дополнение к этому контексты изохронного приема имеют свои регистры шаблонов совпадений ContextMatch и общий регистр масок мультиканального приема. В последующем описании указывается смещение регистров относительно начального адреса своего блока регистров.

Управляющий регистр ContextControl контекста представлен парой регистров ContextControlSet (+0h) и ContextControlClear (+4h), обеспечивающих установку, сброс и чтение битов и полей. Формат регистра для асинхронных контекстов приведен на рисунке ниже, форматы регистров для изохронных контекстов описаны в соответствующем разделе. Назначение полей, используемых в регистрах всех контекстов, приведено далее:

• run — программное разрешение (1) и запрет (0) отработки дескрипторов;
• wake — семафор, установкой которого программа уведомляет о добавлении нового дескриптора в контекст. Хост-контроллер обнуляет бит после выборки каждого дескриптора;
• dead — хост-контроллер устанавливает этот бит, обнаружив фатальную ошибку. Программный сброс бита run сбрасывает и этот бит;
• active — признак обработки дескрипторов (управляется хост-контроллером);
• spd — скорость, на которой был принят пакет (только для контекстов приема). Значение некорректно, если установлен бит wake или active;
• event_code — код события, раскрытый в таблице ниже.

Таблица. Коды событий для контекстов DMA

Регистр CommandPtr (+Ch) содержит указатель на блок дескрипторов (старшие 28 бит адреса в поле descriptorAddress) и индикатор длины этого блока (поле Z). Длина (поле Z) указывается в 16-байтных блоках; дескрипторы выровнены по границе параграфа (младшие 4 бита — нулевые). Индикатор Z = 0 означает недействительность указателя — признак окончания контекстной программы. Допустимое число блоков в дескрипторе зависит от типа контекста. При инициализации контекста в регистр заносится указатель на начальный блок дескрипторов и их число в блоке. Дальнейшая программная модификация регистра допустима лишь при нулевом значении признаков run и active. Чтение регистра, в зависимости от состояния признаков run, dead, active и wake, дает различные значения указателей:

• указывает на последний исполненный, текущий или следующий дескриптор;
• указывает на блок с Z = 0, вызвавший прекращение активности контекста или блок, вызвавший фатальную ошибку.

Инициализация контекста начинается с проверки состояния — биты run, active и dead должны быть сброшены. При этом условии в регистр CommandPtr помещается указатель на блок дескрипторов (и длина блока), после чего можно программно установить бит run.

Добавление дескрипторов в список возможно в любое время. Для этого в памяти формируется дескриптор или связанный список дескрипторов, и указатель на него (и поле Z) помещается в адрес перехода, находящийся в последнем дескрипторе прежнего списка. После этого необходимо программно установить бит wake — указать контроллеру на обновление списка.

Остановка контекста выполняется программным сбросом бита wake, но это может и не привести к немедленной остановке. Признаком остановки контекста после сброса run является обнуленный бит active.