Шина IEEE 1394 — FireWire

Шина IEEE 1394 — FireWire

Специальные регистры последовательной шины

Специальные регистры последовательной шины (Serial Bus Dependent Registers) расположены во втором 512-байтном блоке, специально отведенном в CSR под шинно-зависимые регистры.

Регистры синхронизации изохронных передач Cycle_Time (200h) и Bus_Time (204h) задают время, измеряемое в секундах, циклах (125 мкс) и тиках (частота 24,576 МГц). Запись в эти регистры влияет только на поле second_count_hi, автоматически инкрементируемое каждые 128 с.

Регистры мониторинга питания (необязательные) позволяют осуществлять предупреждение об угрозе пропадания питания. Узел, обнаруживший угрозу пропадания питания, посылает широковещательное сообщение — выполняет запись в регистр POWER_FAIL_IMMINENT (208h, рис. 1, а). В этом сообщении единица в pfi_flag указывает на действительность остальных полей. Поле pfi_delay содержит ожидаемое время до пропадания (в сотнях микросекунд); поле pfi_source — идентификатор узла, пославшего сообщение. Регистр POWER_SOURCE (20Ch, рис. 1, б) в поле power_source содержит идентификатор узла, сообщения от которого принимаются во внимание.

Регистр тайм-аута повторов по занятости целевого узла BUSY_TIMEOUT (210h) определяет предел времени или количество попыток повторов. По сбросу устанавливается время ожидания 25 мс и 0 попыток повторов.

Регистр идентификатора диспетчера шины BUS_MANAGER_ID (21Ch) должен присутствовать у любого узла, претендующего на роль диспетчера изохронных ресурсов. В нем у выбранного диспетчера изохронных ресурсов будет значение идентификатора диспетчера шины (в младших 6 битах) или признак отсутствия диспетчера — 3Fh (значение, устанавливаемое по начальному сбросу). Этот регистр должен поддерживать блокированную транзакцию (условную запись) для выбора диспетчера шины.

Регистры доступной пропускной способности BANDWIDTH_AVAILABLE (220h) и каналов CHANNELS_AVAILABLE (224h и 228h) должны быть у диспетчера изохронных ресурсов. Эти регистры должны поддерживать блокированную транзакцию (условную запись) для выделения изохронных ресурсов.

Служебные регистры MAINT_CONTROL (22Ch) и MAINT_UTILITY (230h) служат для отладочных целей. Запись в регистр MAINT_UTILITY не вызывает никаких побочных действий в узле, чтение возвращает результат последней записи. Для проверки связи и протоколов обработки ошибок можно обращаться к этому регистру любого узла, проверяя достоверность обмена (сравнивая данные чтения и записи) и вводя различные ошибки. Регистр MAINT_CONTROL (см. рисунок ниже) позволяет принудительно вводить ошибки передачи пакетов:

  • e_hcrc — искажение CRC заголовка;
  • e_dcrc — искажение CRC поля данных;
  • no_pkt — запрет генерации следующего пакета;
  • f_ack — подмена нормального ответа (квитанции) на поле ack;
  • no_ack — запрет посылки пакета квитанции;
  • ack — подставляемое значение кода ответа (если f_ack = 1).

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

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

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

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

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

  • узел, который собирается отправить пакет, дожидается покоя шины (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

Последовательный интерфейс подключает к однопортовому узлу с интегрированным портом, называемому 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

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

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

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

Формат управляющих регистров асинхронных контекстов

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

Код События Контексты
00 evt_no_status, нет индикации события AT, AR, IT, IR
01 reserved  
02 evt_long_packet, длина данных в принятом пакете больше, чем размер буфера IR
03 evt_missing_ack, потерян пакет подтверждения ack AT
04 evt_underrun, недостаточно данных в FIFO, переданный пакет усечен AT
05 evt_overrun, переполнение FIFO при изохронном приеме IR
06 evt_descriptor_read, неисправимая ошибка при чтении дескриптора контроллером AT, AR, IT, IR
07 evt_data_read, неисправимая ошибка при чтении контроллером из памяти данных для передачи AT, IT
08 evt_data_write, неисправимая ошибка при записи данных в память хоста AR, IR, IT
09 evt_bus_reset, признак приема пакета, синтезированного по обнаружении сброса на шине AR
0A evt_timeout, не удалась своевременно отправка пакета асинхронного ответа или изохронный контекст не смог записать число пропущенных циклов AT, IT
0B evt_tcode_err, неверный код транзакции в принятом пакете AT, IT
0C-0D Резерв  
0E evt_unknown, неизвестная ошибка AT, AR, IT, IR
0F evt_flushed, пакет был отброшен из-за сброса шины AT
10 Резерв  
11 ack_complete, пакет запроса или ответа от хоста успешнопринят узлом назначения и на этом транзакция завершена. Для пакетов, не требующих подтверждений, этот признак устанавливается автоматически AT, AR, IT, IR
12 ack_pending, пакет запроса от хоста принят успешно узлом назначения, субакция ответа последует позже AT, AR
13 Резерв  
14 ack_busy_X, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_X AT
15 ack_busy_A, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_A AT
16 ack_busy_B, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_B AT
17-1A Резерв  
1B ack_tardy, узел назначения не может принять пакет, поскольку его LINK приостановлен (в состоянии suspended) AT
1C Резерв  
1D ack_data_error, AT-контекст принял пакет ack_data_error или изохронный контекст обнаружил ошибку CRC или длины данных (при приеме каждого пакета в отдельный буфер) AT, IR
1E ack_type_error, недопустимый тип транзакции AT, AR
1F Резерв  

Регистр 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.

Яндекс.Метрика